From wlavrijsen at lbl.gov  Mon Apr  1 20:51:58 2013
From: wlavrijsen at lbl.gov (wlavrijsen at lbl.gov)
Date: Mon, 1 Apr 2013 11:51:58 -0700 (PDT)
Subject: [pypy-dev] prevent extension module code from being executed
 during startup?
In-Reply-To: <CAMSv6X2D1O1Oj7JGs2viZU4BZ20-bYX8MDFmajbbdV98R8Yv-Q@mail.gmail.com>
References: <alpine.LNX.2.00.1303291305570.9173@pc3a-wlav.lbl.gov>
	<CAMSv6X07rCav4N92ddEcX9t3cBu_g-Nft=vfto6RDXvX7Ann-Q@mail.gmail.com>
	<alpine.LNX.2.00.1303292302060.21230@pc3a-wlav.lbl.gov>
	<CAMSv6X3XmeDVnqCqAH-wnAajhyMKcw8rOSm9sbEirYRq3xOkmg@mail.gmail.com>
	<alpine.LNX.2.00.1303300927450.24503@pc3a-wlav.lbl.gov>
	<CAMSv6X2D1O1Oj7JGs2viZU4BZ20-bYX8MDFmajbbdV98R8Yv-Q@mail.gmail.com>
Message-ID: <alpine.LNX.2.00.1304011147020.8892@pc3a-wlav.lbl.gov>

Hi Armin,

> Uh, that's strange.  The docstrings in interpreter/module.py say
> specifically the opposite.  But the truth looks a bit more complicated
> indeed, e.g. it depends if getbuiltinmodule('cppyy') was already
> called during translation or not...

yes, that is called, and it is being called by having applevel defs, b/c
pythonify.py does an "import cppyy" at the module level.

So, the solution then, is to not do that. :) I now have a _init_pythonify
applevel def that does all setup that touches cppyy. That is then called
in startup() as you told me to do. All other references to cppyy have an
import just before them (i.e. inside the function) and the module-level
one has been removed. Looks a bit strange, but does work as I want it: now
nothing runs on ./pypy-c startup, and gbl & friends are build on import.

Thanks!

Best regards,
            Wim
-- 
WLavrijsen at lbl.gov    --    +1 (510) 486 6411    --    www.lavrijsen.net

From fijall at gmail.com  Tue Apr  2 08:28:49 2013
From: fijall at gmail.com (Maciej Fijalkowski)
Date: Tue, 2 Apr 2013 08:28:49 +0200
Subject: [pypy-dev] [pypy-commit] pypy default: unroll isinstance checks
 with old style classes
In-Reply-To: <20130402033055.7BA071C01A0@cobra.cs.uni-duesseldorf.de>
References: <20130402033055.7BA071C01A0@cobra.cs.uni-duesseldorf.de>
Message-ID: <CAK5idxQmA2RRSYQu0WnF0-EXPRgnJon0NQaygSKp_y-gnWETWQ@mail.gmail.com>

On Tue, Apr 2, 2013 at 5:30 AM, alex_gaynor <noreply at buildbot.pypy.org> wrote:
> Author: Alex Gaynor <alex.gaynor at gmail.com>
> Branch:
> Changeset: r62924:73524812269e
> Date: 2013-04-01 20:30 -0700
> http://bitbucket.org/pypy/pypy/changeset/73524812269e/
>
> Log:    unroll isinstance checks with old style classes
>
> diff --git a/pypy/module/__builtin__/abstractinst.py b/pypy/module/__builtin__/abstractinst.py
> --- a/pypy/module/__builtin__/abstractinst.py
> +++ b/pypy/module/__builtin__/abstractinst.py
> @@ -94,9 +94,8 @@
>              return w_obj.w_class.is_subclass_of(w_klass_or_tuple)
>      return _abstract_isinstance_w_helper(space, w_obj, w_klass_or_tuple)
>
> - at jit.dont_look_inside
> +
>  def _abstract_isinstance_w_helper(space, w_obj, w_klass_or_tuple):
> -
>      # -- case (anything, abstract-class)
>      check_class(space, w_klass_or_tuple,
>                  "isinstance() arg 2 must be a class, type,"
> @@ -111,7 +110,7 @@
>          return _issubclass_recurse(space, w_abstractclass, w_klass_or_tuple)
>
>
> - at jit.dont_look_inside
> + at jit.unroll_safe
>  def _issubclass_recurse(space, w_derived, w_top):
>      """Internal helper for abstract cases.  Here, w_top cannot be a tuple."""
>      if space.is_w(w_derived, w_top):
> _______________________________________________
> pypy-commit mailing list
> pypy-commit at python.org
> http://mail.python.org/mailman/listinfo/pypy-commit

That definitely requires a test_pypy_c

From alex.gaynor at gmail.com  Tue Apr  2 08:43:24 2013
From: alex.gaynor at gmail.com (Alex Gaynor)
Date: Mon, 1 Apr 2013 23:43:24 -0700
Subject: [pypy-dev] [pypy-commit] pypy default: unroll isinstance checks
 with old style classes
In-Reply-To: <CAK5idxQmA2RRSYQu0WnF0-EXPRgnJon0NQaygSKp_y-gnWETWQ@mail.gmail.com>
References: <20130402033055.7BA071C01A0@cobra.cs.uni-duesseldorf.de>
	<CAK5idxQmA2RRSYQu0WnF0-EXPRgnJon0NQaygSKp_y-gnWETWQ@mail.gmail.com>
Message-ID: <CAFRnB2WFgMLoQ47hSJ8ZRJm1Sx+TgAMdXcAtjPFuoCC7=SSrDw@mail.gmail.com>

Ok, once I have the nightly I'll do it. A bit backwards, but translating
takes like an hour.

Alex


On Mon, Apr 1, 2013 at 11:28 PM, Maciej Fijalkowski <fijall at gmail.com>wrote:

> On Tue, Apr 2, 2013 at 5:30 AM, alex_gaynor <noreply at buildbot.pypy.org>
> wrote:
> > Author: Alex Gaynor <alex.gaynor at gmail.com>
> > Branch:
> > Changeset: r62924:73524812269e
> > Date: 2013-04-01 20:30 -0700
> > http://bitbucket.org/pypy/pypy/changeset/73524812269e/
> >
> > Log:    unroll isinstance checks with old style classes
> >
> > diff --git a/pypy/module/__builtin__/abstractinst.py
> b/pypy/module/__builtin__/abstractinst.py
> > --- a/pypy/module/__builtin__/abstractinst.py
> > +++ b/pypy/module/__builtin__/abstractinst.py
> > @@ -94,9 +94,8 @@
> >              return w_obj.w_class.is_subclass_of(w_klass_or_tuple)
> >      return _abstract_isinstance_w_helper(space, w_obj, w_klass_or_tuple)
> >
> > - at jit.dont_look_inside
> > +
> >  def _abstract_isinstance_w_helper(space, w_obj, w_klass_or_tuple):
> > -
> >      # -- case (anything, abstract-class)
> >      check_class(space, w_klass_or_tuple,
> >                  "isinstance() arg 2 must be a class, type,"
> > @@ -111,7 +110,7 @@
> >          return _issubclass_recurse(space, w_abstractclass,
> w_klass_or_tuple)
> >
> >
> > - at jit.dont_look_inside
> > + at jit.unroll_safe
> >  def _issubclass_recurse(space, w_derived, w_top):
> >      """Internal helper for abstract cases.  Here, w_top cannot be a
> tuple."""
> >      if space.is_w(w_derived, w_top):
> > _______________________________________________
> > pypy-commit mailing list
> > pypy-commit at python.org
> > http://mail.python.org/mailman/listinfo/pypy-commit
>
> That definitely requires a test_pypy_c
> _______________________________________________
> pypy-dev mailing list
> pypy-dev at python.org
> http://mail.python.org/mailman/listinfo/pypy-dev
>



-- 
"I disapprove of what you say, but I will defend to the death your right to
say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
"The people's good is the highest law." -- Cicero
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20130401/ca411724/attachment.html>

From bitsjamadagni at gmail.com  Tue Apr  2 12:11:49 2013
From: bitsjamadagni at gmail.com (Amit Jamadagni)
Date: Tue, 2 Apr 2013 15:41:49 +0530
Subject: [pypy-dev] Regarding GSOC 2013
Message-ID: <CAHmaejwVbMU6SZHYBR-8UL3OY=07CAr=gHaiYXjtqem1n-mYcw@mail.gmail.com>

Hello,
           I am G.Amit Jamadagni, a student of BITS-Pilani.I am pursuing
Masters in Mathematics along with it engineering in Electronics and
Electrical Engineering.I have gone through the ideas list and have found
the idea of porting to ARM v6 interesting (since pypy can be extended to
raspberry pi).Coming to my experience I have worked around raspberry pi
(still not that much into electronics) but have written some assembly code
with some help from the web.I have some good knowledge about python and
have contributed to some open source projects.
Github Handle : amitjamadagni.
I hope I can work through this and draft a good proposal for SoC.I would
like to know if there are any patch requirements for the same.And also
about the project I referred to above in detail.Thanks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20130402/a9031ca4/attachment.html>

From fijall at gmail.com  Tue Apr  2 13:44:26 2013
From: fijall at gmail.com (Maciej Fijalkowski)
Date: Tue, 2 Apr 2013 13:44:26 +0200
Subject: [pypy-dev] Regarding GSOC 2013
In-Reply-To: <CAHmaejwVbMU6SZHYBR-8UL3OY=07CAr=gHaiYXjtqem1n-mYcw@mail.gmail.com>
References: <CAHmaejwVbMU6SZHYBR-8UL3OY=07CAr=gHaiYXjtqem1n-mYcw@mail.gmail.com>
Message-ID: <CAK5idxTaeFpc3=H90vQVpO=OdJnj71DhzhDKm_y9atUS9+RRDw@mail.gmail.com>

On Tue, Apr 2, 2013 at 12:11 PM, Amit Jamadagni <bitsjamadagni at gmail.com> wrote:
> Hello,
>            I am G.Amit Jamadagni, a student of BITS-Pilani.I am pursuing
> Masters in Mathematics along with it engineering in Electronics and
> Electrical Engineering.I have gone through the ideas list and have found the
> idea of porting to ARM v6 interesting (since pypy can be extended to
> raspberry pi).Coming to my experience I have worked around raspberry pi
> (still not that much into electronics) but have written some assembly code
> with some help from the web.I have some good knowledge about python and have
> contributed to some open source projects.
> Github Handle : amitjamadagni.
> I hope I can work through this and draft a good proposal for SoC.I would
> like to know if there are any patch requirements for the same.And also about
> the project I referred to above in detail.Thanks.

Hi

ARMv6 seems to be mostly working for what is worth. However, we can
definitely do SoC around ARM backend optimizations, if you're
interested. Pop in on #pypy on irc.freenode.net for a quick chat.

Cheers,
fijal

From fijall at gmail.com  Wed Apr  3 09:27:46 2013
From: fijall at gmail.com (Maciej Fijalkowski)
Date: Wed, 3 Apr 2013 09:27:46 +0200
Subject: [pypy-dev] 2.x -> 2 lib rename
Message-ID: <CAK5idxS0CQOMBqbPx1N+FPE_mPHyaeu38h4kNbAvihcC89RYSg@mail.gmail.com>

hello everyone

I'm incredibly unhappy about the 2.7 -> 2 lib rename. It broke
virtualenv, there is no recent virtualenv available and there is
absolutely no good reason why we did that. I'm now spending tons of
time trying to think how to update virtualenv to a TOT version a bit
everywhere.

I'm inclined to do a simple revert (or re-rename it)

Cheers,
fijal

From fijall at gmail.com  Wed Apr  3 09:36:18 2013
From: fijall at gmail.com (Maciej Fijalkowski)
Date: Wed, 3 Apr 2013 09:36:18 +0200
Subject: [pypy-dev] 2.x -> 2 lib rename
In-Reply-To: <CAK5idxS0CQOMBqbPx1N+FPE_mPHyaeu38h4kNbAvihcC89RYSg@mail.gmail.com>
References: <CAK5idxS0CQOMBqbPx1N+FPE_mPHyaeu38h4kNbAvihcC89RYSg@mail.gmail.com>
Message-ID: <CAK5idxReF4-MpYAoe2OW-H6gHKPDHHqRt8A92Z8WktqdmrtDoQ@mail.gmail.com>

On Wed, Apr 3, 2013 at 9:27 AM, Maciej Fijalkowski <fijall at gmail.com> wrote:
> hello everyone
>
> I'm incredibly unhappy about the 2.7 -> 2 lib rename. It broke
> virtualenv, there is no recent virtualenv available and there is
> absolutely no good reason why we did that. I'm now spending tons of
> time trying to think how to update virtualenv to a TOT version a bit
> everywhere.
>
> I'm inclined to do a simple revert (or re-rename it)
>
> Cheers,
> fijal

It seems virutalenv went the way that we'll break it again. No more
things like that please, it breaks software and brings no gain.

From arigo at tunes.org  Wed Apr  3 10:40:12 2013
From: arigo at tunes.org (Armin Rigo)
Date: Wed, 3 Apr 2013 10:40:12 +0200
Subject: [pypy-dev] 2.x -> 2 lib rename
In-Reply-To: <CAK5idxReF4-MpYAoe2OW-H6gHKPDHHqRt8A92Z8WktqdmrtDoQ@mail.gmail.com>
References: <CAK5idxS0CQOMBqbPx1N+FPE_mPHyaeu38h4kNbAvihcC89RYSg@mail.gmail.com>
	<CAK5idxReF4-MpYAoe2OW-H6gHKPDHHqRt8A92Z8WktqdmrtDoQ@mail.gmail.com>
Message-ID: <CAMSv6X0XmoPyGPD7WEWOP6zb3jpEcSWtJ8BoAE17FjJGZ+yVCg@mail.gmail.com>

Hi Fijal,

On Wed, Apr 3, 2013 at 9:36 AM, Maciej Fijalkowski <fijall at gmail.com> wrote:
>> I'm incredibly unhappy about the 2.7 -> 2 lib rename. It broke
>> virtualenv, (...)

As far as I'm concerned, it can be renamed back.  "It's because of
Python 3" is not really a good enough argument to start with, but if
it breaks things, then please re-rename it.


A bient?t,

Armin.

From anto.cuni at gmail.com  Wed Apr  3 13:38:41 2013
From: anto.cuni at gmail.com (Antonio Cuni)
Date: Wed, 03 Apr 2013 13:38:41 +0200
Subject: [pypy-dev] 2.x -> 2 lib rename
In-Reply-To: <CAK5idxS0CQOMBqbPx1N+FPE_mPHyaeu38h4kNbAvihcC89RYSg@mail.gmail.com>
References: <CAK5idxS0CQOMBqbPx1N+FPE_mPHyaeu38h4kNbAvihcC89RYSg@mail.gmail.com>
Message-ID: <515C14C1.4080103@gmail.com>

On 04/03/2013 09:27 AM, Maciej Fijalkowski wrote:
> hello everyone
>
> I'm incredibly unhappy about the 2.7 -> 2 lib rename. It broke
> virtualenv, there is no recent virtualenv available and there is
> absolutely no good reason why we did that. I'm now spending tons of
> time trying to think how to update virtualenv to a TOT version a bit
> everywhere.
>
> I'm inclined to do a simple revert (or re-rename it)

+1, although to jumpy to the defence of whoever did the commit, it's not 
obvious that such a change breaks virtualenv because there are not tests.
Maybe we should setup a buildbot to run virtualenv's tests with the nightly pypy?
I didn't do that when I added virtualenv support for the simple reason that at 
that time virtualenv had no tests, but maybe the situation improved nowadays?

ciao,
Anto




From g2p.code at gmail.com  Wed Apr  3 15:36:22 2013
From: g2p.code at gmail.com (Gabriel de Perthuis)
Date: Wed, 3 Apr 2013 13:36:22 +0000 (UTC)
Subject: [pypy-dev] 2.x -> 2 lib rename
References: <CAK5idxS0CQOMBqbPx1N+FPE_mPHyaeu38h4kNbAvihcC89RYSg@mail.gmail.com>
	<515C14C1.4080103@gmail.com>
Message-ID: <kjhb8l$rh1$1@ger.gmane.org>

> +1, although to jumpy to the defence of whoever did the commit, it's not
> obvious that such a change breaks virtualenv because there are not
> tests.
> Maybe we should setup a buildbot to run virtualenv's tests with the
> nightly pypy?
> I didn't do that when I added virtualenv support for the simple reason
> that at that time virtualenv had no tests, but maybe the situation
> improved nowadays?

There are unit tests and an integration test that would have caught it,
see https://github.com/pypa/virtualenv/blob/develop/.travis.yml
and https://travis-ci.org/pypa/virtualenv .

Travis doesn't have up to date PyPy nightlies, they were using a PPA
that is lagging behind: https://launchpad.net/~pypy/+archive/ppa



From fijall at gmail.com  Wed Apr  3 16:01:19 2013
From: fijall at gmail.com (Maciej Fijalkowski)
Date: Wed, 3 Apr 2013 16:01:19 +0200
Subject: [pypy-dev] 2.x -> 2 lib rename
In-Reply-To: <515C14C1.4080103@gmail.com>
References: <CAK5idxS0CQOMBqbPx1N+FPE_mPHyaeu38h4kNbAvihcC89RYSg@mail.gmail.com>
	<515C14C1.4080103@gmail.com>
Message-ID: <CAK5idxT8Wt47nZNx7aPJ6Qs8sZVJ5kvO7DLxpmO6c8+tkgr6cg@mail.gmail.com>

On Wed, Apr 3, 2013 at 1:38 PM, Antonio Cuni <anto.cuni at gmail.com> wrote:
> On 04/03/2013 09:27 AM, Maciej Fijalkowski wrote:
>>
>> hello everyone
>>
>> I'm incredibly unhappy about the 2.7 -> 2 lib rename. It broke
>> virtualenv, there is no recent virtualenv available and there is
>> absolutely no good reason why we did that. I'm now spending tons of
>> time trying to think how to update virtualenv to a TOT version a bit
>> everywhere.
>>
>> I'm inclined to do a simple revert (or re-rename it)
>
>
> +1, although to jumpy to the defence of whoever did the commit, it's not
> obvious that such a change breaks virtualenv because there are not tests.
> Maybe we should setup a buildbot to run virtualenv's tests with the nightly
> pypy?
> I didn't do that when I added virtualenv support for the simple reason that
> at that time virtualenv had no tests, but maybe the situation improved
> nowadays?
>
> ciao,
> Anto
>
>
>

In all honesty, it only breaks because virtualenv is a pile of hacks.
But this is not really enough of a reason to break things.

From wlavrijsen at lbl.gov  Thu Apr  4 01:20:51 2013
From: wlavrijsen at lbl.gov (wlavrijsen at lbl.gov)
Date: Wed, 3 Apr 2013 16:20:51 -0700 (PDT)
Subject: [pypy-dev] understanding and fixing rtyper warnings
Message-ID: <alpine.LNX.2.00.1304031618150.8892@pc3a-wlav.lbl.gov>

Hi,

say I have something like this during translation:

[rtyper:WARNING] SomeInstance(can_be_None=True, classdef=pypy.interpreter.baseobjspace.W_Root) can be null, but forcing non-null in dict key
[rtyper:WARNING] SomeInstance(can_be_None=True, classdef=pypy.interpreter.baseobjspace.W_Root) can be null, but forcing non-null in dict value
[rtyper:WARNING] SomeInstance(can_be_None=True, classdef=pypy.interpreter.baseobjspace.W_Root) can be null, but forcing non-null in dict key
[rtyper:WARNING] SomePBC(can_be_None=True, const=None, subset_of=None) can be null, but forcing non-null in dict value

what are my chances to find out whether a) my code is responsible, and b) if
there's anything that can be done about it? I.e. is there are way of getting
more information, like file name and line number?

I tried finding the locations where I do not enforce can_be_None=False and if
the result is put in a dictionary, but there's nothing that stands out.

Thanks,
      Wim
-- 
WLavrijsen at lbl.gov    --    +1 (510) 486 6411    --    www.lavrijsen.net

From alex.gaynor at gmail.com  Thu Apr  4 01:25:39 2013
From: alex.gaynor at gmail.com (Alex Gaynor)
Date: Wed, 3 Apr 2013 16:25:39 -0700
Subject: [pypy-dev] understanding and fixing rtyper warnings
In-Reply-To: <alpine.LNX.2.00.1304031618150.8892@pc3a-wlav.lbl.gov>
References: <alpine.LNX.2.00.1304031618150.8892@pc3a-wlav.lbl.gov>
Message-ID: <CAFRnB2V1_U20=YWLhVtuNAHvoTnhXzcvBZR92z2T0UuMHEYfKQ@mail.gmail.com>

Not your fault, those occur on default as well. I don't know of any way to
get better messages.

Alex


On Wed, Apr 3, 2013 at 4:20 PM, <wlavrijsen at lbl.gov> wrote:

> Hi,
>
> say I have something like this during translation:
>
> [rtyper:WARNING] SomeInstance(can_be_None=True, classdef=pypy.interpreter.
> **baseobjspace.W_Root) can be null, but forcing non-null in dict key
> [rtyper:WARNING] SomeInstance(can_be_None=True, classdef=pypy.interpreter.
> **baseobjspace.W_Root) can be null, but forcing non-null in dict value
> [rtyper:WARNING] SomeInstance(can_be_None=True, classdef=pypy.interpreter.
> **baseobjspace.W_Root) can be null, but forcing non-null in dict key
> [rtyper:WARNING] SomePBC(can_be_None=True, const=None, subset_of=None) can
> be null, but forcing non-null in dict value
>
> what are my chances to find out whether a) my code is responsible, and b)
> if
> there's anything that can be done about it? I.e. is there are way of
> getting
> more information, like file name and line number?
>
> I tried finding the locations where I do not enforce can_be_None=False and
> if
> the result is put in a dictionary, but there's nothing that stands out.
>
> Thanks,
>      Wim
> --
> WLavrijsen at lbl.gov    --    +1 (510) 486 6411    --    www.lavrijsen.net
> ______________________________**_________________
> pypy-dev mailing list
> pypy-dev at python.org
> http://mail.python.org/**mailman/listinfo/pypy-dev<http://mail.python.org/mailman/listinfo/pypy-dev>
>



-- 
"I disapprove of what you say, but I will defend to the death your right to
say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
"The people's good is the highest law." -- Cicero
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20130403/fff98a60/attachment.html>

From fijall at gmail.com  Thu Apr  4 07:38:58 2013
From: fijall at gmail.com (Maciej Fijalkowski)
Date: Thu, 4 Apr 2013 07:38:58 +0200
Subject: [pypy-dev] understanding and fixing rtyper warnings
In-Reply-To: <CAFRnB2V1_U20=YWLhVtuNAHvoTnhXzcvBZR92z2T0UuMHEYfKQ@mail.gmail.com>
References: <alpine.LNX.2.00.1304031618150.8892@pc3a-wlav.lbl.gov>
	<CAFRnB2V1_U20=YWLhVtuNAHvoTnhXzcvBZR92z2T0UuMHEYfKQ@mail.gmail.com>
Message-ID: <CAK5idxTAN5qaT0RjkDe=Tg8Lb_QHvy8wPrEiZy12xBM9oAzK0g@mail.gmail.com>

On Thu, Apr 4, 2013 at 1:25 AM, Alex Gaynor <alex.gaynor at gmail.com> wrote:
> Not your fault, those occur on default as well. I don't know of any way to
> get better messages.
>
> Alex

The problem is that in dicts (rpython dicts responsible for
W_DictObject and W_SetObject), we want to know that keys are non-null.
We already do, noone stores null there, but the annotator doesn't
know. I have a bit no clue how to find out all the places that pass
W_Root-or-None instead of W_Root as keys (or values), but I don't
care. Maybe we should just disable this warning.

>
>
> On Wed, Apr 3, 2013 at 4:20 PM, <wlavrijsen at lbl.gov> wrote:
>>
>> Hi,
>>
>> say I have something like this during translation:
>>
>> [rtyper:WARNING] SomeInstance(can_be_None=True,
>> classdef=pypy.interpreter.baseobjspace.W_Root) can be null, but forcing
>> non-null in dict key
>> [rtyper:WARNING] SomeInstance(can_be_None=True,
>> classdef=pypy.interpreter.baseobjspace.W_Root) can be null, but forcing
>> non-null in dict value
>> [rtyper:WARNING] SomeInstance(can_be_None=True,
>> classdef=pypy.interpreter.baseobjspace.W_Root) can be null, but forcing
>> non-null in dict key
>> [rtyper:WARNING] SomePBC(can_be_None=True, const=None, subset_of=None) can
>> be null, but forcing non-null in dict value
>>
>> what are my chances to find out whether a) my code is responsible, and b)
>> if
>> there's anything that can be done about it? I.e. is there are way of
>> getting
>> more information, like file name and line number?
>>
>> I tried finding the locations where I do not enforce can_be_None=False and
>> if
>> the result is put in a dictionary, but there's nothing that stands out.
>>
>> Thanks,
>>      Wim
>> --
>> WLavrijsen at lbl.gov    --    +1 (510) 486 6411    --    www.lavrijsen.net
>> _______________________________________________
>> pypy-dev mailing list
>> pypy-dev at python.org
>> http://mail.python.org/mailman/listinfo/pypy-dev
>
>
>
>
> --
> "I disapprove of what you say, but I will defend to the death your right to
> say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
> "The people's good is the highest law." -- Cicero
>
> _______________________________________________
> pypy-dev mailing list
> pypy-dev at python.org
> http://mail.python.org/mailman/listinfo/pypy-dev
>

From bokr at oz.net  Thu Apr  4 10:50:39 2013
From: bokr at oz.net (Bengt Richter)
Date: Thu, 04 Apr 2013 10:50:39 +0200
Subject: [pypy-dev] understanding and fixing rtyper warnings
In-Reply-To: <CAK5idxTAN5qaT0RjkDe=Tg8Lb_QHvy8wPrEiZy12xBM9oAzK0g@mail.gmail.com>
References: <alpine.LNX.2.00.1304031618150.8892@pc3a-wlav.lbl.gov>	<CAFRnB2V1_U20=YWLhVtuNAHvoTnhXzcvBZR92z2T0UuMHEYfKQ@mail.gmail.com>
	<CAK5idxTAN5qaT0RjkDe=Tg8Lb_QHvy8wPrEiZy12xBM9oAzK0g@mail.gmail.com>
Message-ID: <515D3EDF.4080209@oz.net>

On 04/04/2013 07:38 AM Maciej Fijalkowski wrote:
> On Thu, Apr 4, 2013 at 1:25 AM, Alex Gaynor<alex.gaynor at gmail.com>  wrote:
>> Not your fault, those occur on default as well. I don't know of any way to
>> get better messages.
>>
>> Alex
>
> The problem is that in dicts (rpython dicts responsible for
> W_DictObject and W_SetObject), we want to know that keys are non-null.
> We already do, noone stores null there, but the annotator doesn't
> know. I have a bit no clue how to find out all the places that pass
> W_Root-or-None instead of W_Root as keys (or values), but I don't
> care. Maybe we should just disable this warning.
>

PMJI without understanding your context, but if "noone stores null there,"
couldn't you turn the warning around to warn when/if someone *does*
store a null "there," and disable the current warning? (I'm naively assuming
all the places that pass W_Root-or-None pass it to/through one/few place/s that
can be monitored on the way to becoming keys (which I guess never happens?)).

Regards,
Bengt Richter


From arigo at tunes.org  Thu Apr  4 12:02:09 2013
From: arigo at tunes.org (Armin Rigo)
Date: Thu, 4 Apr 2013 12:02:09 +0200
Subject: [pypy-dev] understanding and fixing rtyper warnings
In-Reply-To: <515D3EDF.4080209@oz.net>
References: <alpine.LNX.2.00.1304031618150.8892@pc3a-wlav.lbl.gov>
	<CAFRnB2V1_U20=YWLhVtuNAHvoTnhXzcvBZR92z2T0UuMHEYfKQ@mail.gmail.com>
	<CAK5idxTAN5qaT0RjkDe=Tg8Lb_QHvy8wPrEiZy12xBM9oAzK0g@mail.gmail.com>
	<515D3EDF.4080209@oz.net>
Message-ID: <CAMSv6X0tuqW5W=JMaVSW3sgq1UP2MP_WfXK4Zokt_p5FUBcNQA@mail.gmail.com>

Hi Fijal, hi Bengt,

On Thu, Apr 4, 2013 at 10:50 AM, Bengt Richter <bokr at oz.net> wrote:
> PMJI without understanding your context, but if "noone stores null there,"
> couldn't you turn the warning around to warn when/if someone *does*
> store a null "there," and disable the current warning? (I'm naively assuming
> all the places that pass W_Root-or-None pass it to/through one/few place/s
> that can be monitored on the way to becoming keys (which I guess never
> happens?)).

Yes, we could try that.  I don't think we ever did.  Basically it
would mean crashing early at annotation whenever someone tries to
store a key or value that we know the rtyper would give such a warning
about later on.  Then we're left with adding a few "assert x is not
None" in the source code.


A bient?t,

Armin.

From fijall at gmail.com  Thu Apr  4 12:18:22 2013
From: fijall at gmail.com (Maciej Fijalkowski)
Date: Thu, 4 Apr 2013 12:18:22 +0200
Subject: [pypy-dev] understanding and fixing rtyper warnings
In-Reply-To: <CAMSv6X0tuqW5W=JMaVSW3sgq1UP2MP_WfXK4Zokt_p5FUBcNQA@mail.gmail.com>
References: <alpine.LNX.2.00.1304031618150.8892@pc3a-wlav.lbl.gov>
	<CAFRnB2V1_U20=YWLhVtuNAHvoTnhXzcvBZR92z2T0UuMHEYfKQ@mail.gmail.com>
	<CAK5idxTAN5qaT0RjkDe=Tg8Lb_QHvy8wPrEiZy12xBM9oAzK0g@mail.gmail.com>
	<515D3EDF.4080209@oz.net>
	<CAMSv6X0tuqW5W=JMaVSW3sgq1UP2MP_WfXK4Zokt_p5FUBcNQA@mail.gmail.com>
Message-ID: <CAK5idxRpxwQhv+bf4g2L-kjxNi+7dwG04Bhf7ZM+25-6qh=C5Q@mail.gmail.com>

On Thu, Apr 4, 2013 at 12:02 PM, Armin Rigo <arigo at tunes.org> wrote:
> Hi Fijal, hi Bengt,
>
> On Thu, Apr 4, 2013 at 10:50 AM, Bengt Richter <bokr at oz.net> wrote:
>> PMJI without understanding your context, but if "noone stores null there,"
>> couldn't you turn the warning around to warn when/if someone *does*
>> store a null "there," and disable the current warning? (I'm naively assuming
>> all the places that pass W_Root-or-None pass it to/through one/few place/s
>> that can be monitored on the way to becoming keys (which I guess never
>> happens?)).
>
> Yes, we could try that.  I don't think we ever did.  Basically it
> would mean crashing early at annotation whenever someone tries to
> store a key or value that we know the rtyper would give such a warning
> about later on.  Then we're left with adding a few "assert x is not
> None" in the source code.
>
>
> A bient?t,
>
> Armin.

Good luck have fun :) it was tried before. it's a mess (and definitely
not "a few", unless you add assert in space.setitem which does not
solve anything, we can as well just remove the warning)

From arigo at tunes.org  Thu Apr  4 12:27:03 2013
From: arigo at tunes.org (Armin Rigo)
Date: Thu, 4 Apr 2013 12:27:03 +0200
Subject: [pypy-dev] understanding and fixing rtyper warnings
In-Reply-To: <CAK5idxRpxwQhv+bf4g2L-kjxNi+7dwG04Bhf7ZM+25-6qh=C5Q@mail.gmail.com>
References: <alpine.LNX.2.00.1304031618150.8892@pc3a-wlav.lbl.gov>
	<CAFRnB2V1_U20=YWLhVtuNAHvoTnhXzcvBZR92z2T0UuMHEYfKQ@mail.gmail.com>
	<CAK5idxTAN5qaT0RjkDe=Tg8Lb_QHvy8wPrEiZy12xBM9oAzK0g@mail.gmail.com>
	<515D3EDF.4080209@oz.net>
	<CAMSv6X0tuqW5W=JMaVSW3sgq1UP2MP_WfXK4Zokt_p5FUBcNQA@mail.gmail.com>
	<CAK5idxRpxwQhv+bf4g2L-kjxNi+7dwG04Bhf7ZM+25-6qh=C5Q@mail.gmail.com>
Message-ID: <CAMSv6X3dXg6t9YsWqQaLOKzuv3VMAToCuih1zasyexBLZMBg9A@mail.gmail.com>

Hi Fijal,

On Thu, Apr 4, 2013 at 12:18 PM, Maciej Fijalkowski <fijall at gmail.com> wrote:
> Good luck have fun :) it was tried before. it's a mess (and definitely
> not "a few", unless you add assert in space.setitem which does not
> solve anything, we can as well just remove the warning)

That's what I had in mind.  And yes, it helps: if someone really tries
to store None as a key or value, he would get a clear message (or one
of his asserts would fail, rather than getting a segfault, or some
more extreme confusion if it doesn't segfault).


A bient?t,

Armin.

From fijall at gmail.com  Thu Apr  4 12:29:03 2013
From: fijall at gmail.com (Maciej Fijalkowski)
Date: Thu, 4 Apr 2013 12:29:03 +0200
Subject: [pypy-dev] understanding and fixing rtyper warnings
In-Reply-To: <CAMSv6X3dXg6t9YsWqQaLOKzuv3VMAToCuih1zasyexBLZMBg9A@mail.gmail.com>
References: <alpine.LNX.2.00.1304031618150.8892@pc3a-wlav.lbl.gov>
	<CAFRnB2V1_U20=YWLhVtuNAHvoTnhXzcvBZR92z2T0UuMHEYfKQ@mail.gmail.com>
	<CAK5idxTAN5qaT0RjkDe=Tg8Lb_QHvy8wPrEiZy12xBM9oAzK0g@mail.gmail.com>
	<515D3EDF.4080209@oz.net>
	<CAMSv6X0tuqW5W=JMaVSW3sgq1UP2MP_WfXK4Zokt_p5FUBcNQA@mail.gmail.com>
	<CAK5idxRpxwQhv+bf4g2L-kjxNi+7dwG04Bhf7ZM+25-6qh=C5Q@mail.gmail.com>
	<CAMSv6X3dXg6t9YsWqQaLOKzuv3VMAToCuih1zasyexBLZMBg9A@mail.gmail.com>
Message-ID: <CAK5idxQOWSkYnM+dmte35X6pjMSfxan11_iMyZp5UHonOBtYig@mail.gmail.com>

On Thu, Apr 4, 2013 at 12:27 PM, Armin Rigo <arigo at tunes.org> wrote:
> Hi Fijal,
>
> On Thu, Apr 4, 2013 at 12:18 PM, Maciej Fijalkowski <fijall at gmail.com> wrote:
>> Good luck have fun :) it was tried before. it's a mess (and definitely
>> not "a few", unless you add assert in space.setitem which does not
>> solve anything, we can as well just remove the warning)
>
> That's what I had in mind.  And yes, it helps: if someone really tries
> to store None as a key or value, he would get a clear message (or one
> of his asserts would fail, rather than getting a segfault, or some
> more extreme confusion if it doesn't segfault).
>
>
> A bient?t,
>
> Armin.

unclear - the JIT removes asserts

From arigo at tunes.org  Thu Apr  4 12:31:11 2013
From: arigo at tunes.org (Armin Rigo)
Date: Thu, 4 Apr 2013 12:31:11 +0200
Subject: [pypy-dev] understanding and fixing rtyper warnings
In-Reply-To: <CAK5idxQOWSkYnM+dmte35X6pjMSfxan11_iMyZp5UHonOBtYig@mail.gmail.com>
References: <alpine.LNX.2.00.1304031618150.8892@pc3a-wlav.lbl.gov>
	<CAFRnB2V1_U20=YWLhVtuNAHvoTnhXzcvBZR92z2T0UuMHEYfKQ@mail.gmail.com>
	<CAK5idxTAN5qaT0RjkDe=Tg8Lb_QHvy8wPrEiZy12xBM9oAzK0g@mail.gmail.com>
	<515D3EDF.4080209@oz.net>
	<CAMSv6X0tuqW5W=JMaVSW3sgq1UP2MP_WfXK4Zokt_p5FUBcNQA@mail.gmail.com>
	<CAK5idxRpxwQhv+bf4g2L-kjxNi+7dwG04Bhf7ZM+25-6qh=C5Q@mail.gmail.com>
	<CAMSv6X3dXg6t9YsWqQaLOKzuv3VMAToCuih1zasyexBLZMBg9A@mail.gmail.com>
	<CAK5idxQOWSkYnM+dmte35X6pjMSfxan11_iMyZp5UHonOBtYig@mail.gmail.com>
Message-ID: <CAMSv6X2CjZ0L2Q=c+XS8WkTfGFW9-c7AvEK8c9_Pjf3++BWGCg@mail.gmail.com>

Hi,

On Thu, Apr 4, 2013 at 12:29 PM, Maciej Fijalkowski <fijall at gmail.com> wrote:
> unclear - the JIT removes asserts

You'd hope that in badly written code, the assert triggers early
(before the first 1000 iterations).


A bient?t,

Armin.

From fijall at gmail.com  Thu Apr  4 12:32:17 2013
From: fijall at gmail.com (Maciej Fijalkowski)
Date: Thu, 4 Apr 2013 12:32:17 +0200
Subject: [pypy-dev] understanding and fixing rtyper warnings
In-Reply-To: <CAMSv6X2CjZ0L2Q=c+XS8WkTfGFW9-c7AvEK8c9_Pjf3++BWGCg@mail.gmail.com>
References: <alpine.LNX.2.00.1304031618150.8892@pc3a-wlav.lbl.gov>
	<CAFRnB2V1_U20=YWLhVtuNAHvoTnhXzcvBZR92z2T0UuMHEYfKQ@mail.gmail.com>
	<CAK5idxTAN5qaT0RjkDe=Tg8Lb_QHvy8wPrEiZy12xBM9oAzK0g@mail.gmail.com>
	<515D3EDF.4080209@oz.net>
	<CAMSv6X0tuqW5W=JMaVSW3sgq1UP2MP_WfXK4Zokt_p5FUBcNQA@mail.gmail.com>
	<CAK5idxRpxwQhv+bf4g2L-kjxNi+7dwG04Bhf7ZM+25-6qh=C5Q@mail.gmail.com>
	<CAMSv6X3dXg6t9YsWqQaLOKzuv3VMAToCuih1zasyexBLZMBg9A@mail.gmail.com>
	<CAK5idxQOWSkYnM+dmte35X6pjMSfxan11_iMyZp5UHonOBtYig@mail.gmail.com>
	<CAMSv6X2CjZ0L2Q=c+XS8WkTfGFW9-c7AvEK8c9_Pjf3++BWGCg@mail.gmail.com>
Message-ID: <CAK5idxRcPmWbZjFDgUyZknrpg1bzR18NfxH-2HXUWMUG-qePxA@mail.gmail.com>

On Thu, Apr 4, 2013 at 12:31 PM, Armin Rigo <arigo at tunes.org> wrote:
> Hi,
>
> On Thu, Apr 4, 2013 at 12:29 PM, Maciej Fijalkowski <fijall at gmail.com> wrote:
>> unclear - the JIT removes asserts
>
> You'd hope that in badly written code, the assert triggers early
> (before the first 1000 iterations).
>
>
> A bient?t,
>
> Armin.

indeed

From fijall at gmail.com  Fri Apr  5 11:08:38 2013
From: fijall at gmail.com (Maciej Fijalkowski)
Date: Fri, 5 Apr 2013 11:08:38 +0200
Subject: [pypy-dev] [pypy-commit] pypy py3k: disable interp level
	W_IntObject tests
In-Reply-To: <20130405011020.C00091C06BD@cobra.cs.uni-duesseldorf.de>
References: <20130405011020.C00091C06BD@cobra.cs.uni-duesseldorf.de>
Message-ID: <CAK5idxR-vQ83KDX7K-sTHta9ey=u_z8Fi1WjCs7ZpnjSu7jj1g@mail.gmail.com>

why is W_IntObject not used in py3k? it should just have a different typedef

On Fri, Apr 5, 2013 at 3:10 AM, pjenvey <noreply at buildbot.pypy.org> wrote:
> Author: Philip Jenvey <pjenvey at underboss.org>
> Branch: py3k
> Changeset: r63038:b0b275ecce2a
> Date: 2013-04-04 18:08 -0700
> http://bitbucket.org/pypy/pypy/changeset/b0b275ecce2a/
>
> Log:    disable interp level W_IntObject tests
>
> diff --git a/pypy/objspace/std/test/test_intobject.py b/pypy/objspace/std/test/test_intobject.py
> --- a/pypy/objspace/std/test/test_intobject.py
> +++ b/pypy/objspace/std/test/test_intobject.py
> @@ -5,8 +5,10 @@
>  from rpython.rlib.rarithmetic import r_uint, is_valid_int
>  from rpython.rlib.rbigint import rbigint
>
> +class TestW_IntObject:
>
> -class TestW_IntObject:
> +    def setup_class(cls):
> +        py.test.skip("W_IntObject was replaced w/ W_LongObject in py3k")
>
>      def _longshiftresult(self, x):
>          """ calculate an overflowing shift """
> _______________________________________________
> pypy-commit mailing list
> pypy-commit at python.org
> http://mail.python.org/mailman/listinfo/pypy-commit

From pjenvey at underboss.org  Fri Apr  5 22:26:33 2013
From: pjenvey at underboss.org (Philip Jenvey)
Date: Fri, 5 Apr 2013 13:26:33 -0700
Subject: [pypy-dev] [pypy-commit] pypy py3k: disable interp level
	W_IntObject tests
In-Reply-To: <CAK5idxR-vQ83KDX7K-sTHta9ey=u_z8Fi1WjCs7ZpnjSu7jj1g@mail.gmail.com>
References: <20130405011020.C00091C06BD@cobra.cs.uni-duesseldorf.de>
	<CAK5idxR-vQ83KDX7K-sTHta9ey=u_z8Fi1WjCs7ZpnjSu7jj1g@mail.gmail.com>
Message-ID: <AF1A8160-ACC4-4C19-BBF3-5BE221CABC00@underboss.org>

At one point it was still used like that but it was a bit of a mess

So we've killed its usage so everything works sanely around W_LongObject, then we'll need to introduce either it back without the accompanying mess, or more likely introduce a W_LongObject variant as a replacement. We already have a 'SmallLong' variant but it's a larger longlong, (SmallerLong?).

--
Philip Jenvey

On Apr 5, 2013, at 2:08 AM, Maciej Fijalkowski wrote:

> why is W_IntObject not used in py3k? it should just have a different typedef
> 
> On Fri, Apr 5, 2013 at 3:10 AM, pjenvey <noreply at buildbot.pypy.org> wrote:
>> Author: Philip Jenvey <pjenvey at underboss.org>
>> Branch: py3k
>> Changeset: r63038:b0b275ecce2a
>> Date: 2013-04-04 18:08 -0700
>> http://bitbucket.org/pypy/pypy/changeset/b0b275ecce2a/
>> 
>> Log:    disable interp level W_IntObject tests
>> 
>> diff --git a/pypy/objspace/std/test/test_intobject.py b/pypy/objspace/std/test/test_intobject.py
>> --- a/pypy/objspace/std/test/test_intobject.py
>> +++ b/pypy/objspace/std/test/test_intobject.py
>> @@ -5,8 +5,10 @@
>> from rpython.rlib.rarithmetic import r_uint, is_valid_int
>> from rpython.rlib.rbigint import rbigint
>> 
>> +class TestW_IntObject:
>> 
>> -class TestW_IntObject:
>> +    def setup_class(cls):
>> +        py.test.skip("W_IntObject was replaced w/ W_LongObject in py3k")
>> 
>>     def _longshiftresult(self, x):
>>         """ calculate an overflowing shift """
>> _______________________________________________
>> pypy-commit mailing list
>> pypy-commit at python.org
>> http://mail.python.org/mailman/listinfo/pypy-commit
> _______________________________________________
> pypy-dev mailing list
> pypy-dev at python.org
> http://mail.python.org/mailman/listinfo/pypy-dev



From alex.gaynor at gmail.com  Fri Apr  5 22:30:31 2013
From: alex.gaynor at gmail.com (Alex Gaynor)
Date: Fri, 5 Apr 2013 13:30:31 -0700
Subject: [pypy-dev] [pypy-commit] pypy py3k: disable interp level
 W_IntObject tests
In-Reply-To: <AF1A8160-ACC4-4C19-BBF3-5BE221CABC00@underboss.org>
References: <20130405011020.C00091C06BD@cobra.cs.uni-duesseldorf.de>
	<CAK5idxR-vQ83KDX7K-sTHta9ey=u_z8Fi1WjCs7ZpnjSu7jj1g@mail.gmail.com>
	<AF1A8160-ACC4-4C19-BBF3-5BE221CABC00@underboss.org>
Message-ID: <CAFRnB2V0JtKF=898D3i3SabEG7POvBDu4wu0kK7=An21GN-sfw@mail.gmail.com>

It shouldn't have a different typedef, they should just share the same
typedef, and use that indirect_method thing you created.

Alex


On Fri, Apr 5, 2013 at 1:26 PM, Philip Jenvey <pjenvey at underboss.org> wrote:

> At one point it was still used like that but it was a bit of a mess
>
> So we've killed its usage so everything works sanely around W_LongObject,
> then we'll need to introduce either it back without the accompanying mess,
> or more likely introduce a W_LongObject variant as a replacement. We
> already have a 'SmallLong' variant but it's a larger longlong,
> (SmallerLong?).
>
> --
> Philip Jenvey
>
> On Apr 5, 2013, at 2:08 AM, Maciej Fijalkowski wrote:
>
> > why is W_IntObject not used in py3k? it should just have a different
> typedef
> >
> > On Fri, Apr 5, 2013 at 3:10 AM, pjenvey <noreply at buildbot.pypy.org>
> wrote:
> >> Author: Philip Jenvey <pjenvey at underboss.org>
> >> Branch: py3k
> >> Changeset: r63038:b0b275ecce2a
> >> Date: 2013-04-04 18:08 -0700
> >> http://bitbucket.org/pypy/pypy/changeset/b0b275ecce2a/
> >>
> >> Log:    disable interp level W_IntObject tests
> >>
> >> diff --git a/pypy/objspace/std/test/test_intobject.py
> b/pypy/objspace/std/test/test_intobject.py
> >> --- a/pypy/objspace/std/test/test_intobject.py
> >> +++ b/pypy/objspace/std/test/test_intobject.py
> >> @@ -5,8 +5,10 @@
> >> from rpython.rlib.rarithmetic import r_uint, is_valid_int
> >> from rpython.rlib.rbigint import rbigint
> >>
> >> +class TestW_IntObject:
> >>
> >> -class TestW_IntObject:
> >> +    def setup_class(cls):
> >> +        py.test.skip("W_IntObject was replaced w/ W_LongObject in
> py3k")
> >>
> >>     def _longshiftresult(self, x):
> >>         """ calculate an overflowing shift """
> >> _______________________________________________
> >> pypy-commit mailing list
> >> pypy-commit at python.org
> >> http://mail.python.org/mailman/listinfo/pypy-commit
> > _______________________________________________
> > pypy-dev mailing list
> > pypy-dev at python.org
> > http://mail.python.org/mailman/listinfo/pypy-dev
>
>
> _______________________________________________
> pypy-dev mailing list
> pypy-dev at python.org
> http://mail.python.org/mailman/listinfo/pypy-dev
>



-- 
"I disapprove of what you say, but I will defend to the death your right to
say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
"The people's good is the highest law." -- Cicero
GPG Key fingerprint: 125F 5C67 DFE9 4084
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20130405/970de072/attachment.html>

From aidembb at yahoo.com  Sat Apr  6 09:05:00 2013
From: aidembb at yahoo.com (Roger Flores)
Date: Sat, 6 Apr 2013 00:05:00 -0700 (PDT)
Subject: [pypy-dev] 2GB Limit on Windows
Message-ID: <1365231900.43559.YahooMailNeo@web162201.mail.bf1.yahoo.com>

Is the 2GB limit being lifted on the Windows nightlies?? I ask because I keep bumping, painfully, into it.? I found this link:

http://doc.pypy.org/en/latest/windows.html#preping-windows-for-the-large-build

Googling more about "editbin /largeaddressaware"

http://www.velocityreviews.com/forums/t492725-how-to-make-a-32bit-application-use-more-than-2gb-ram-on-64bit-windows-2003-a.html

It appears editbin is for when you don't pass /LARGEADDRESSAWARE to the linker.? Perhaps a Windows build savvy person could add the magic flag to where ever the linker is?


Thanks,
-Roger

From matti.picus at gmail.com  Sat Apr  6 13:07:20 2013
From: matti.picus at gmail.com (matti picus)
Date: Sat, 6 Apr 2013 14:07:20 +0300
Subject: [pypy-dev] 2GB Limit on Windows
In-Reply-To: <1365231900.43559.YahooMailNeo@web162201.mail.bf1.yahoo.com>
References: <1365231900.43559.YahooMailNeo@web162201.mail.bf1.yahoo.com>
Message-ID: <CAO8bCgiS0rNU2CveT=jC9Pdh=ckQmMgc6iQ0ftE6===vMEGarg@mail.gmail.com>

I was under the impression that that link flag can cause problems for 32
bit systems, but maybe we don't care? For instance see this
http://stackoverflow.com/questions/5185406/how-does-the-large-address-aware-flag-work-for-32-bit-applications-on-64-bit-com.
Why is it a problem for you to run editbin on the exe? You need a compiler
to translate anyway, right? Or are you running out of memory in regular
usage of pypy? Too many questions, I'll stop here.
Matti

On Apr 6, 2013 10:08 AM, "Roger Flores" <aidembb at yahoo.com> wrote:
>
> Is the 2GB limit being lifted on the Windows nightlies?  I ask because I
keep bumping, painfully, into it.  I found this link:
>
>
http://doc.pypy.org/en/latest/windows.html#preping-windows-for-the-large-build
>
> Googling more about "editbin /largeaddressaware"
>
>
http://www.velocityreviews.com/forums/t492725-how-to-make-a-32bit-application-use-more-than-2gb-ram-on-64bit-windows-2003-a.html
>
> It appears editbin is for when you don't pass /LARGEADDRESSAWARE to the
linker.  Perhaps a Windows build savvy person could add the magic flag to
where ever the linker is?
>
>
> Thanks,
> -Roger
> _______________________________________________
> pypy-dev mailing list
> pypy-dev at python.org
> http://mail.python.org/mailman/listinfo/pypy-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20130406/be57694a/attachment.html>

From amauryfa at gmail.com  Sat Apr  6 16:36:48 2013
From: amauryfa at gmail.com (Amaury Forgeot d'Arc)
Date: Sat, 6 Apr 2013 16:36:48 +0200
Subject: [pypy-dev] 2GB Limit on Windows
In-Reply-To: <CAO8bCgiS0rNU2CveT=jC9Pdh=ckQmMgc6iQ0ftE6===vMEGarg@mail.gmail.com>
References: <1365231900.43559.YahooMailNeo@web162201.mail.bf1.yahoo.com>
	<CAO8bCgiS0rNU2CveT=jC9Pdh=ckQmMgc6iQ0ftE6===vMEGarg@mail.gmail.com>
Message-ID: <CAGmFidbjYER6bArj3F=9ggjM6k5yRLPVT-bT3cC00O22L1zzdg@mail.gmail.com>

2013/4/6 matti picus <matti.picus at gmail.com>

> I was under the impression that that link flag can cause problems for 32
> bit systems, but maybe we don't care? For instance see this
> http://stackoverflow.com/questions/5185406/how-does-the-large-address-aware-flag-work-for-32-bit-applications-on-64-bit-com.
> Why is it a problem for you to run editbin on the exe? You need a compiler
> to translate anyway, right? Or are you running out of memory in regular
> usage of pypy? Too many questions, I'll stop here.
>
I think the initial request was for the win32 nightly build.

The flag could cause issue for programs which assume that the high bit is
never set for pointers, and use it for another purpose.
It's not the case for pypy, because we reserve such tricks to Linux ;-)
And I guess it's the same for all other libraries we link with, since they
are also cross-platform.

-- 
Amaury Forgeot d'Arc
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20130406/a1cadaab/attachment.html>

From matti.picus at gmail.com  Sat Apr  6 19:03:08 2013
From: matti.picus at gmail.com (matti picus)
Date: Sat, 6 Apr 2013 20:03:08 +0300
Subject: [pypy-dev] 2GB Limit on Windows
In-Reply-To: <CAGmFidbjYER6bArj3F=9ggjM6k5yRLPVT-bT3cC00O22L1zzdg@mail.gmail.com>
References: <1365231900.43559.YahooMailNeo@web162201.mail.bf1.yahoo.com>
	<CAO8bCgiS0rNU2CveT=jC9Pdh=ckQmMgc6iQ0ftE6===vMEGarg@mail.gmail.com>
	<CAGmFidbjYER6bArj3F=9ggjM6k5yRLPVT-bT3cC00O22L1zzdg@mail.gmail.com>
Message-ID: <CAO8bCgjZxO14rbe=CWqwiOVrNSmXsPQ9Qb0Ri6gfbqo0uAPDng@mail.gmail.com>

I would vote -1 for adding the largeaddressaware
flag to our translation proccess for nightlies. Better to run out of memory
than to use cffi to call some random dll andhave it explode. Those who are
in the know will have a compiler or can down load a free version and DIY.
Matti

On Apr 6, 2013 5:36 PM, "Amaury Forgeot d'Arc" <amauryfa at gmail.com> wrote:
>
> I think the initial request was for the win32 nightly build.
>
> The flag could cause issue for programs which assume that the high bit is
never set for pointers, and use it for another purpose.
> It's not the case for pypy, because we reserve such tricks to Linux ;-)
> And I guess it's the same for all other libraries we link with, since
they are also cross-platform.
>
> --
> Amaury Forgeot d'Arc
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20130406/b45dcc54/attachment.html>

From aidembb at yahoo.com  Sat Apr  6 22:51:13 2013
From: aidembb at yahoo.com (Roger Flores)
Date: Sat, 6 Apr 2013 13:51:13 -0700 (PDT)
Subject: [pypy-dev] 2GB Limit on Windows
In-Reply-To: <CAGmFidbjYER6bArj3F=9ggjM6k5yRLPVT-bT3cC00O22L1zzdg@mail.gmail.com>
References: <1365231900.43559.YahooMailNeo@web162201.mail.bf1.yahoo.com>
	<CAO8bCgiS0rNU2CveT=jC9Pdh=ckQmMgc6iQ0ftE6===vMEGarg@mail.gmail.com>
	<CAGmFidbjYER6bArj3F=9ggjM6k5yRLPVT-bT3cC00O22L1zzdg@mail.gmail.com>
Message-ID: <1365281473.78647.YahooMailNeo@web162205.mail.bf1.yahoo.com>

>Why is it a problem for you to run editbin on the exe?

I'm think more about people trying to use my program.? They'll also have to find/install editbin and then run it properly on pypy.exe.? And I'll have to make directions for this extra step, and that means people won't.? It would be simpler if it just worked.

Is the flag really going to create problems?? It's not changing the code, that's why it can be changed after the fact by editbin.? It's simply a flag in the header that the Windows kernel sees and arranges it's address space to make more available.


>Better to run out of memory than to use cffi to call some random dll andhave it explode. 


I don't agree.? I know the running out of memory sucks.? The app completely dies and you loose everything.? Really, there's nothing to recommend about it.? And the random dll exploding?? I have no idea if this is real.? Does anyone actually know or is this more of a guess?? Is the top address bit reserved for CFFI purposes?? I see no allowance of that in the latest CFFI doc.



My actual preference would just be to have a 64 bit version available.? That solves the entire problem and is easy to document.? But that opens up a whole other set of issues beyond this.? Actually, is there a web page describing the problems and potential fixes?? Those issues seems at least as deserving of a web page as the largeaddressaware flag.


-Roger





________________________________
 From: Amaury Forgeot d'Arc <amauryfa at gmail.com>
To: matti picus <matti.picus at gmail.com> 
Cc: Roger Flores <aidembb at yahoo.com>; PyPy Developer Mailing List <pypy-dev at python.org> 
Sent: Saturday, April 6, 2013 7:36 AM
Subject: Re: [pypy-dev] 2GB Limit on Windows
 



2013/4/6 matti picus <matti.picus at gmail.com>

I was under the impression that that link flag can cause problems for 32 bit systems, but maybe we don't care? For instance see this http://stackoverflow.com/questions/5185406/how-does-the-large-address-aware-flag-work-for-32-bit-applications-on-64-bit-com. Why is it a problem for you to run editbin on the exe? You need a compiler to translate anyway, right? Or are you running out of memory in regular usage of pypy? Too many questions, I'll stop here.I think the initial request was for the win32 nightly build.

The flag could cause issue for programs which assume that the high bit is never set for pointers, and use it for another purpose.
It's not the case for pypy, because we reserve such tricks to Linux ;-)
And I guess it's the same for all other libraries we link with, since they are also cross-platform.

-- 
Amaury Forgeot d'Arc 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20130406/3d8d0f0a/attachment-0001.html>

From matti.picus at gmail.com  Sat Apr  6 23:49:18 2013
From: matti.picus at gmail.com (Matti Picus)
Date: Sun, 07 Apr 2013 00:49:18 +0300
Subject: [pypy-dev] 2GB Limit on Windows
In-Reply-To: <1365281473.78647.YahooMailNeo@web162205.mail.bf1.yahoo.com>
References: <1365231900.43559.YahooMailNeo@web162201.mail.bf1.yahoo.com>
	<CAO8bCgiS0rNU2CveT=jC9Pdh=ckQmMgc6iQ0ftE6===vMEGarg@mail.gmail.com>
	<CAGmFidbjYER6bArj3F=9ggjM6k5yRLPVT-bT3cC00O22L1zzdg@mail.gmail.com>
	<1365281473.78647.YahooMailNeo@web162205.mail.bf1.yahoo.com>
Message-ID: <5160985E.1090405@gmail.com>

We started a 64 bit windows port once, but it died from lack of 
interest. The port is complicated since on windows 64 bit,/longs/are 
only 32 bit. This is a problem for/PyPy/right now, since it assumes that 
a c/long/can hold a pointer
Can you ship a largeaddressaware exe with your code, or even better 
contribute to the PyPy 64 bit windows port?
Matti

On 6/04/2013 11:51 PM, Roger Flores wrote:
> My actual preference would just be to have a 64 bit version available. 
> That solves the entire problem and is easy to document.  But that 
> opens up a whole other set of issues beyond this. Actually, is there a 
> web page describing the problems and potential fixes?  Those issues 
> seems at least as deserving of a web page as the largeaddressaware flag.
>


From amauryfa at gmail.com  Sun Apr  7 10:57:31 2013
From: amauryfa at gmail.com (Amaury Forgeot d'Arc)
Date: Sun, 7 Apr 2013 10:57:31 +0200
Subject: [pypy-dev] 2GB Limit on Windows
In-Reply-To: <CAO8bCgjZxO14rbe=CWqwiOVrNSmXsPQ9Qb0Ri6gfbqo0uAPDng@mail.gmail.com>
References: <1365231900.43559.YahooMailNeo@web162201.mail.bf1.yahoo.com>
	<CAO8bCgiS0rNU2CveT=jC9Pdh=ckQmMgc6iQ0ftE6===vMEGarg@mail.gmail.com>
	<CAGmFidbjYER6bArj3F=9ggjM6k5yRLPVT-bT3cC00O22L1zzdg@mail.gmail.com>
	<CAO8bCgjZxO14rbe=CWqwiOVrNSmXsPQ9Qb0Ri6gfbqo0uAPDng@mail.gmail.com>
Message-ID: <CAGmFidbQc1G1s_4vwdAU_Hwc_2WjrUq+CNLJkV88F=4Q+qw2Ww@mail.gmail.com>

2013/4/6 matti picus <matti.picus at gmail.com>

> I would vote -1 for adding the largeaddressaware
> flag to our translation proccess for nightlies. Better to run out of
> memory than to use cffi to call some random dll andhave it explode. Those
> who are in the know will have a compiler or can down load a free version
> and DIY.
>
In the nightly distribution, pypy.exe is only 7kb.
Surely we could have another copy with the largeadressaware flag?

-- 
Amaury Forgeot d'Arc
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20130407/6c8ded32/attachment.html>

From arigo at tunes.org  Sun Apr  7 11:10:05 2013
From: arigo at tunes.org (Armin Rigo)
Date: Sun, 7 Apr 2013 11:10:05 +0200
Subject: [pypy-dev] 2GB Limit on Windows
In-Reply-To: <CAGmFidbQc1G1s_4vwdAU_Hwc_2WjrUq+CNLJkV88F=4Q+qw2Ww@mail.gmail.com>
References: <1365231900.43559.YahooMailNeo@web162201.mail.bf1.yahoo.com>
	<CAO8bCgiS0rNU2CveT=jC9Pdh=ckQmMgc6iQ0ftE6===vMEGarg@mail.gmail.com>
	<CAGmFidbjYER6bArj3F=9ggjM6k5yRLPVT-bT3cC00O22L1zzdg@mail.gmail.com>
	<CAO8bCgjZxO14rbe=CWqwiOVrNSmXsPQ9Qb0Ri6gfbqo0uAPDng@mail.gmail.com>
	<CAGmFidbQc1G1s_4vwdAU_Hwc_2WjrUq+CNLJkV88F=4Q+qw2Ww@mail.gmail.com>
Message-ID: <CAMSv6X2BPNjWsNoa+k0BKS_rTYDnGFCB8+WDv7G31fm06v5P2g@mail.gmail.com>

Hi Amaury,

On Sun, Apr 7, 2013 at 10:57 AM, Amaury Forgeot d'Arc
<amauryfa at gmail.com> wrote:
> In the nightly distribution, pypy.exe is only 7kb.
> Surely we could have another copy with the largeadressaware flag?

+1 Great idea.

Armin

From alendit at googlemail.com  Sun Apr  7 13:30:36 2013
From: alendit at googlemail.com (Dimitri Vorona)
Date: Sun, 7 Apr 2013 13:30:36 +0200
Subject: [pypy-dev] PyPy-Performance versus various other VMs
Message-ID: <CACu5ZfnBnY9KaGJN+B8VQH7AxO-hX1gJfMAcYYUweR=X7owXnw@mail.gmail.com>

Hi everyone,

just wanted to bring to your attention this blog post:
http://attractivechaos.wordpress.com/2013/04/06/performance-of-rust-and-dart-in-sudoku-solving/
.
PyPy ist compared with various dynamic and static languages.

While the perfomance is still OK (within an order of magnitude of C), it
places last by a quite big margin. I would like to know if these result
match your benchmarks or is the implementation of the sudoku solver
non-optimal for pypy (can be seen here
https://github.com/attractivechaos/plb/blob/master/sudoku/sudoku_v1.py)

Regards,

Dmytro Vorona.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20130407/b7589c65/attachment.html>

From kurskk141 at gmail.com  Sun Apr  7 16:16:12 2013
From: kurskk141 at gmail.com (=?GB2312?B?zfW64g==?=)
Date: Sun, 7 Apr 2013 22:16:12 +0800
Subject: [pypy-dev] about PyPy's sandbox
Message-ID: <CAN+vTgMKtOP_sMd0dnoDHc==6hHhVZfS4fYA-yEd8aavMq4c7g@mail.gmail.com>

Hi:
About PyPy's sandbox,I want to ask you a question:
In PyPy's sandbox ,a lot of standard libraries can not be used.If I want
use it,how could I add it in PyPy's sandbox?
(you can assume I have verify the module's safety)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20130407/8f964222/attachment.html>

From alex.gaynor at gmail.com  Sun Apr  7 18:56:44 2013
From: alex.gaynor at gmail.com (Alex Gaynor)
Date: Sun, 7 Apr 2013 09:56:44 -0700
Subject: [pypy-dev] PyPy-Performance versus various other VMs
In-Reply-To: <CACu5ZfnBnY9KaGJN+B8VQH7AxO-hX1gJfMAcYYUweR=X7owXnw@mail.gmail.com>
References: <CACu5ZfnBnY9KaGJN+B8VQH7AxO-hX1gJfMAcYYUweR=X7owXnw@mail.gmail.com>
Message-ID: <CAFRnB2Ug8L=-J8cetRVzr8vFPLMPOgfB57HDqi7jHY7hLD0BJw@mail.gmail.com>

The biggest problem with this benchmark is that it uses nested lists (read:
memory indirections), whereas the other implementations (or at least the C
one) uses flat storage.

Alex


On Sun, Apr 7, 2013 at 4:30 AM, Dimitri Vorona <alendit at googlemail.com>wrote:

> Hi everyone,
>
> just wanted to bring to your attention this blog post:
> http://attractivechaos.wordpress.com/2013/04/06/performance-of-rust-and-dart-in-sudoku-solving/ .
> PyPy ist compared with various dynamic and static languages.
>
> While the perfomance is still OK (within an order of magnitude of C), it
> places last by a quite big margin. I would like to know if these result
> match your benchmarks or is the implementation of the sudoku solver
> non-optimal for pypy (can be seen here
> https://github.com/attractivechaos/plb/blob/master/sudoku/sudoku_v1.py)
>
> Regards,
>
> Dmytro Vorona.
>
> _______________________________________________
> pypy-dev mailing list
> pypy-dev at python.org
> http://mail.python.org/mailman/listinfo/pypy-dev
>
>


-- 
"I disapprove of what you say, but I will defend to the death your right to
say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
"The people's good is the highest law." -- Cicero
GPG Key fingerprint: 125F 5C67 DFE9 4084
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20130407/220365f7/attachment.html>

From fijall at gmail.com  Sun Apr  7 22:23:06 2013
From: fijall at gmail.com (Maciej Fijalkowski)
Date: Sun, 7 Apr 2013 22:23:06 +0200
Subject: [pypy-dev] PyPy-Performance versus various other VMs
In-Reply-To: <CAFRnB2Ug8L=-J8cetRVzr8vFPLMPOgfB57HDqi7jHY7hLD0BJw@mail.gmail.com>
References: <CACu5ZfnBnY9KaGJN+B8VQH7AxO-hX1gJfMAcYYUweR=X7owXnw@mail.gmail.com>
	<CAFRnB2Ug8L=-J8cetRVzr8vFPLMPOgfB57HDqi7jHY7hLD0BJw@mail.gmail.com>
Message-ID: <CAK5idxTvBSUgMwf7+LBAp4Rnd7rk_hPUZEtm_rbaQsYnyJ7sdw@mail.gmail.com>

I think we score pretty good on this benchmark. Definitely the
competition there is tough (v8, luajit are the only other dynamic lang
implementations considered).

There is a plan to improve on *such* code, but definitely our
immediate plans are for more python-like workloads than number
crunching.

Cheers,
fijal

On Sun, Apr 7, 2013 at 6:56 PM, Alex Gaynor <alex.gaynor at gmail.com> wrote:
> The biggest problem with this benchmark is that it uses nested lists (read:
> memory indirections), whereas the other implementations (or at least the C
> one) uses flat storage.
>
> Alex
>
>
> On Sun, Apr 7, 2013 at 4:30 AM, Dimitri Vorona <alendit at googlemail.com>
> wrote:
>>
>> Hi everyone,
>>
>> just wanted to bring to your attention this blog post:
>> http://attractivechaos.wordpress.com/2013/04/06/performance-of-rust-and-dart-in-sudoku-solving/
>> . PyPy ist compared with various dynamic and static languages.
>>
>> While the perfomance is still OK (within an order of magnitude of C), it
>> places last by a quite big margin. I would like to know if these result
>> match your benchmarks or is the implementation of the sudoku solver
>> non-optimal for pypy (can be seen here
>> https://github.com/attractivechaos/plb/blob/master/sudoku/sudoku_v1.py)
>>
>> Regards,
>>
>> Dmytro Vorona.
>>
>> _______________________________________________
>> pypy-dev mailing list
>> pypy-dev at python.org
>> http://mail.python.org/mailman/listinfo/pypy-dev
>>
>
>
>
> --
> "I disapprove of what you say, but I will defend to the death your right to
> say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
> "The people's good is the highest law." -- Cicero
> GPG Key fingerprint: 125F 5C67 DFE9 4084
>
> _______________________________________________
> pypy-dev mailing list
> pypy-dev at python.org
> http://mail.python.org/mailman/listinfo/pypy-dev
>

From aidembb at yahoo.com  Sun Apr  7 23:49:32 2013
From: aidembb at yahoo.com (Roger Flores)
Date: Sun, 7 Apr 2013 14:49:32 -0700 (PDT)
Subject: [pypy-dev] 2GB Limit on Windows
In-Reply-To: <CAGmFidbQc1G1s_4vwdAU_Hwc_2WjrUq+CNLJkV88F=4Q+qw2Ww@mail.gmail.com>
References: <1365231900.43559.YahooMailNeo@web162201.mail.bf1.yahoo.com>
	<CAO8bCgiS0rNU2CveT=jC9Pdh=ckQmMgc6iQ0ftE6===vMEGarg@mail.gmail.com>
	<CAGmFidbjYER6bArj3F=9ggjM6k5yRLPVT-bT3cC00O22L1zzdg@mail.gmail.com>
	<CAO8bCgjZxO14rbe=CWqwiOVrNSmXsPQ9Qb0Ri6gfbqo0uAPDng@mail.gmail.com>
	<CAGmFidbQc1G1s_4vwdAU_Hwc_2WjrUq+CNLJkV88F=4Q+qw2Ww@mail.gmail.com>
Message-ID: <1365371372.62701.YahooMailNeo@web162201.mail.bf1.yahoo.com>

Amaury wrote:

>Surely we could have another copy with the largeadressaware flag?

I agree.? That's a smart way to proceed for now.


I'm still wondering if there is any technical reason against the flag?? Particularly the "CFFI extensions want the high bit reserved or not" issue.? 


Matt wrote:
>The port is complicated since on windows 64 bit,/longs/are only 32 bit. 
This is a problem for/PyPy/right now, since it assumes that a c/long/can
 hold a pointer

I don't want to talk much about a win 64 bit version in this thread because it's a separate and larger issue.? But I am happy to talk about it in a separate thread or off list.? I don't think people outside the core pypy developers have any idea what the issues really are, and there's no place to learn them.? For instance, why don't solutions for other projects work for pypy?? Is the problem with C code or with RPython code that generates C code?? Can you show an example problem from the source tree?? What does the fix for it look like?? How do we find all the places needing a fix?? I am happy to work with someone who knows to document all this.? No one will work on the project without this kind of information, because they don't know what they're signing up for.


Thanks,
-Roger
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20130407/f520b921/attachment-0001.html>

From jonathan at slenders.be  Mon Apr  8 09:25:40 2013
From: jonathan at slenders.be (Jonathan Slenders)
Date: Mon, 8 Apr 2013 09:25:40 +0200
Subject: [pypy-dev] about PyPy's sandbox
In-Reply-To: <CAN+vTgMKtOP_sMd0dnoDHc==6hHhVZfS4fYA-yEd8aavMq4c7g@mail.gmail.com>
References: <CAN+vTgMKtOP_sMd0dnoDHc==6hHhVZfS4fYA-yEd8aavMq4c7g@mail.gmail.com>
Message-ID: <CAKfyG3zZ3t5pN2cByVUycTKB_sNPMgoSDONfMS-BkJCjqXcdUg@mail.gmail.com>

Hi ??,

Normally you can use any library you want in the sandbox, as long as
it doesn't use C-code; all the pure-python stuff should work.
Add the library's parent directory to the virtual root in sandlib, and
make sure that pypy will search for that directory. (Add it to
sys.path in the sandbox, or use PYTHONPATH -- I think.)

There are however some things that appear not to work. I never got
datetime.datetime.now() working. Logically this would be a system call
and could have been handled by a do_ll_os...-function in sandlib.
However I never noticed any such call for retrieving the current time.
 Any ideas...?

Another known issue is that libraries which use _struct, will not
work, unless you translate the sandbox with this module included. They
say however that inclusion of this module could be dangerous. I which
for a safe version of _struct that could be used in the sandbox. Can't
we have a pure-python version of _struct? (Even with the performance
degration, it would be very helpful as quite a lot of libraries depend
on this one.)

Cheers,
Jonathan



2013/4/7 ?? <kurskk141 at gmail.com>:
> Hi:
> About PyPy's sandbox,I want to ask you a question:
> In PyPy's sandbox ,a lot of standard libraries can not be used.If I want use
> it,how could I add it in PyPy's sandbox?
> (you can assume I have verify the module's safety)
>
> _______________________________________________
> pypy-dev mailing list
> pypy-dev at python.org
> http://mail.python.org/mailman/listinfo/pypy-dev
>

From arigo at tunes.org  Mon Apr  8 11:06:02 2013
From: arigo at tunes.org (Armin Rigo)
Date: Mon, 8 Apr 2013 11:06:02 +0200
Subject: [pypy-dev] 2GB Limit on Windows
In-Reply-To: <1365371372.62701.YahooMailNeo@web162201.mail.bf1.yahoo.com>
References: <1365231900.43559.YahooMailNeo@web162201.mail.bf1.yahoo.com>
	<CAO8bCgiS0rNU2CveT=jC9Pdh=ckQmMgc6iQ0ftE6===vMEGarg@mail.gmail.com>
	<CAGmFidbjYER6bArj3F=9ggjM6k5yRLPVT-bT3cC00O22L1zzdg@mail.gmail.com>
	<CAO8bCgjZxO14rbe=CWqwiOVrNSmXsPQ9Qb0Ri6gfbqo0uAPDng@mail.gmail.com>
	<CAGmFidbQc1G1s_4vwdAU_Hwc_2WjrUq+CNLJkV88F=4Q+qw2Ww@mail.gmail.com>
	<1365371372.62701.YahooMailNeo@web162201.mail.bf1.yahoo.com>
Message-ID: <CAMSv6X0skpHWU1w=NCARTxRdqEVBpqBnX9Q_fgPEoFKd_6WVYg@mail.gmail.com>

Hi Roger,

On Sun, Apr 7, 2013 at 11:49 PM, Roger Flores <aidembb at yahoo.com> wrote:
> I'm still wondering if there is any technical reason against the flag?
> Particularly the "CFFI extensions want the high bit reserved or not" issue.

Obviously CFFI doesn't store random stuff in the high bit.  It's meant
to work on Linux to start with, so the idea never even crossed my
mind.  The reason CFFI was mentioned in this thread is that by using
it you can call arbitrary DLLs, some of which may have the historical
problem --- i.e. assume that all pointers are in the positive half.


A bient?t,

Armin.

From janzert at janzert.com  Mon Apr  8 10:03:03 2013
From: janzert at janzert.com (Janzert)
Date: Mon, 08 Apr 2013 04:03:03 -0400
Subject: [pypy-dev] PyPy-Performance versus various other VMs
In-Reply-To: <CACu5ZfnBnY9KaGJN+B8VQH7AxO-hX1gJfMAcYYUweR=X7owXnw@mail.gmail.com>
References: <CACu5ZfnBnY9KaGJN+B8VQH7AxO-hX1gJfMAcYYUweR=X7owXnw@mail.gmail.com>
Message-ID: <kjttjl$5ls$1@ger.gmane.org>

On 4/7/2013 7:30 AM, Dimitri Vorona wrote:
> Hi everyone,
>
> just wanted to bring to your attention this blog post:
> http://attractivechaos.wordpress.com/2013/04/06/performance-of-rust-and-dart-in-sudoku-solving/ .
> PyPy ist compared with various dynamic and static languages.
>
> While the perfomance is still OK (within an order of magnitude of C), it
> places last by a quite big margin. I would like to know if these result
> match your benchmarks or is the implementation of the sudoku solver
> non-optimal for pypy (can be seen here
> https://github.com/attractivechaos/plb/blob/master/sudoku/sudoku_v1.py)
>
> Regards,
>
> Dmytro Vorona.
>

One notable thing not shown is while pypy may still be ~1.5x slower than 
v8 or luajit it is already ~10x faster than cpython.

Janzert



From fijall at gmail.com  Tue Apr  9 09:30:19 2013
From: fijall at gmail.com (Maciej Fijalkowski)
Date: Tue, 9 Apr 2013 09:30:19 +0200
Subject: [pypy-dev] 2GB Limit on Windows
In-Reply-To: <1365371372.62701.YahooMailNeo@web162201.mail.bf1.yahoo.com>
References: <1365231900.43559.YahooMailNeo@web162201.mail.bf1.yahoo.com>
	<CAO8bCgiS0rNU2CveT=jC9Pdh=ckQmMgc6iQ0ftE6===vMEGarg@mail.gmail.com>
	<CAGmFidbjYER6bArj3F=9ggjM6k5yRLPVT-bT3cC00O22L1zzdg@mail.gmail.com>
	<CAO8bCgjZxO14rbe=CWqwiOVrNSmXsPQ9Qb0Ri6gfbqo0uAPDng@mail.gmail.com>
	<CAGmFidbQc1G1s_4vwdAU_Hwc_2WjrUq+CNLJkV88F=4Q+qw2Ww@mail.gmail.com>
	<1365371372.62701.YahooMailNeo@web162201.mail.bf1.yahoo.com>
Message-ID: <CAK5idxRs+csXAdgiAUoAjbH5XmVWTUoC11EX=eJXHQ12aKA7Jw@mail.gmail.com>

On Sun, Apr 7, 2013 at 11:49 PM, Roger Flores <aidembb at yahoo.com> wrote:
> Amaury wrote:
>>Surely we could have another copy with the largeadressaware flag?
>
> I agree.  That's a smart way to proceed for now.
>
>
> I'm still wondering if there is any technical reason against the flag?
> Particularly the "CFFI extensions want the high bit reserved or not" issue.
>
>
> Matt wrote:
>>The port is complicated since on windows 64 bit,/longs/are only 32 bit.
>> This is a problem for/PyPy/right now, since it assumes that a c/long/can
>> hold a pointer
>
> I don't want to talk much about a win 64 bit version in this thread because
> it's a separate and larger issue.  But I am happy to talk about it in a
> separate thread or off list.  I don't think people outside the core pypy
> developers have any idea what the issues really are, and there's no place to
> learn them.  For instance, why don't solutions for other projects work for
> pypy?  Is the problem with C code or with RPython code that generates C
> code?  Can you show an example problem from the source tree?  What does the
> fix for it look like?  How do we find all the places needing a fix?  I am
> happy to work with someone who knows to document all this.  No one will work
> on the project without this kind of information, because they don't know
> what they're signing up for.
>
>
> Thanks,
> -Roger

It's just a bunch of work. There is nothing special or magic about it,
but so far noone volunteered to spend enough effort there.

Essentially, the main problem is that sizeof(long) !=
sizeof(intptr_t), which is not a big problem per-se, it's just that
this assumption has to be removed from places in the RPython source
code. Another one is the calling convention for the JIT, which is
different than on linux. Again, nothing special, just more work.

Cheers,
fijal

From aidembb at yahoo.com  Tue Apr  9 09:47:46 2013
From: aidembb at yahoo.com (Roger Flores)
Date: Tue, 9 Apr 2013 00:47:46 -0700 (PDT)
Subject: [pypy-dev] Windows 64 bit version
In-Reply-To: <CAK5idxRs+csXAdgiAUoAjbH5XmVWTUoC11EX=eJXHQ12aKA7Jw@mail.gmail.com>
References: <1365231900.43559.YahooMailNeo@web162201.mail.bf1.yahoo.com>
	<CAO8bCgiS0rNU2CveT=jC9Pdh=ckQmMgc6iQ0ftE6===vMEGarg@mail.gmail.com>
	<CAGmFidbjYER6bArj3F=9ggjM6k5yRLPVT-bT3cC00O22L1zzdg@mail.gmail.com>
	<CAO8bCgjZxO14rbe=CWqwiOVrNSmXsPQ9Qb0Ri6gfbqo0uAPDng@mail.gmail.com>
	<CAGmFidbQc1G1s_4vwdAU_Hwc_2WjrUq+CNLJkV88F=4Q+qw2Ww@mail.gmail.com>
	<1365371372.62701.YahooMailNeo@web162201.mail.bf1.yahoo.com>
	<CAK5idxRs+csXAdgiAUoAjbH5XmVWTUoC11EX=eJXHQ12aKA7Jw@mail.gmail.com>
Message-ID: <1365493666.20723.YahooMailNeo@web162204.mail.bf1.yahoo.com>

Maciej Fijalkowski wrote:
>It's just a bunch of work. There is nothing special or magic about it,but so far noone volunteered to spend enough effort there.

Got it. I'm just trying to understand what the work is because that list hasn't been captured anywhere yet.



>Essentially, the main problem is that sizeof(long) != sizeof(intptr_t), which is not a big problem per-se, it's just that this assumption has to be removed from places in the RPython source code. 


OK. Could you find one or two of those places in the RPython source code so we can see?? And what is the fix?? Does long get changed to long long or another type or ?



>Another one is the calling convention for the JIT, which isdifferent than on linux. Again, nothing special, just more work.

Does "calling convention for the JIT" mean a function calling convention for 64 bit windows or something else?? Where is this in the code, or maybe, where is it for the Windows 32 code and where would the 64 bit version go?? There's no magic for exceptions, gc, or anything else?



Thanks for the details,
-Roger
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20130409/91714683/attachment.html>

From fijall at gmail.com  Tue Apr  9 09:52:48 2013
From: fijall at gmail.com (Maciej Fijalkowski)
Date: Tue, 9 Apr 2013 09:52:48 +0200
Subject: [pypy-dev] Windows 64 bit version
In-Reply-To: <1365493666.20723.YahooMailNeo@web162204.mail.bf1.yahoo.com>
References: <1365231900.43559.YahooMailNeo@web162201.mail.bf1.yahoo.com>
	<CAO8bCgiS0rNU2CveT=jC9Pdh=ckQmMgc6iQ0ftE6===vMEGarg@mail.gmail.com>
	<CAGmFidbjYER6bArj3F=9ggjM6k5yRLPVT-bT3cC00O22L1zzdg@mail.gmail.com>
	<CAO8bCgjZxO14rbe=CWqwiOVrNSmXsPQ9Qb0Ri6gfbqo0uAPDng@mail.gmail.com>
	<CAGmFidbQc1G1s_4vwdAU_Hwc_2WjrUq+CNLJkV88F=4Q+qw2Ww@mail.gmail.com>
	<1365371372.62701.YahooMailNeo@web162201.mail.bf1.yahoo.com>
	<CAK5idxRs+csXAdgiAUoAjbH5XmVWTUoC11EX=eJXHQ12aKA7Jw@mail.gmail.com>
	<1365493666.20723.YahooMailNeo@web162204.mail.bf1.yahoo.com>
Message-ID: <CAK5idxSk249vP-LGZ_Wgq-eYwPw1DuPkeW5u+XPV51VdzkaJcQ@mail.gmail.com>

On Tue, Apr 9, 2013 at 9:47 AM, Roger Flores <aidembb at yahoo.com> wrote:
> Maciej Fijalkowski wrote:
>>It's just a bunch of work. There is nothing special or magic about it, but
>> so far noone volunteered to spend enough effort there.
>
> Got it. I'm just trying to understand what the work is because that list
> hasn't been captured anywhere yet.
>
>
>>Essentially, the main problem is that sizeof(long) != sizeof(intptr_t),
>> which is not a big problem per-se, it's just that this assumption has to be
>> removed from places in the RPython source code.
>
> OK. Could you find one or two of those places in the RPython source code so
> we can see?  And what is the fix?  Does long get changed to long long or
> another type or ?

It depends on the context. Essentially the approach is to run tests
and figure out what's going on. Starting from rpython/translator/c

>
>
>>Another one is the calling convention for the JIT, which is different than
>> on linux. Again, nothing special, just more work.
>
> Does "calling convention for the JIT" mean a function calling convention for
> 64 bit windows or something else?  Where is this in the code, or maybe,
> where is it for the Windows 32 code and where would the 64 bit version go?
> There's no magic for exceptions, gc, or anything else?

it would go in rpython/jit/backend/x86

>
>
> Thanks for the details,
> -Roger
>
>

From max.lavrenov at gmail.com  Tue Apr  9 12:15:58 2013
From: max.lavrenov at gmail.com (Max Lavrenov)
Date: Tue, 9 Apr 2013 14:15:58 +0400
Subject: [pypy-dev] Build pypy-2.0b1
Message-ID: <CAAq2fm-=oXUUGmBhfViCd91twdd0iF=8qUXLFGgcxQ+CCzmGsQ@mail.gmail.com>

Hello

I've tried to build pypy from repository but got some compilation error.

There is a very big traceback, so i skip some parts.

Maybe i could provide some additional information?  I still have opened pdb
console with this failed compilation.

Thanks.

[platform:execute] make -j 3 in /tmp/usession-release-2.0-beta2-2/testing_1
[platform:Error] data_pypy_module_cpyext_pyobject.c:118:3: warning:
initialization from incompatible pointer type [enabled by default]
[platform:Error]    (&_PyExc_MemoryError), /* 2.value */
[platform:Error]    ^
[platform:Error] data_pypy_module_cpyext_pyobject.c:118:3: warning: (near
initialization for 'pypy_g_array_916.a.items[2].d_value') [enabled by
default]
[platform:Error] data_pypy_module_cpyext_pyobject.c:123:3: warning:
initialization from incompatible pointer type [enabled by default]
[platform:Error]    (&_PyExc_NotImplementedError), /* 3.value */
[platform:Error]    ^
[platform:Error] data_pypy_module_cpyext_pyobject.c:123:3: warning: (near
initialization for 'pypy_g_array_916.a.items[3].d_value') [enabled by
default]
[platform:Error] data_pypy_module_cpyext_pyobject.c:173:3: warning:
initialization from incompatible pointer type [enabled by default]
[platform:Error]    (&_PyExc_RuntimeError), /* 13.value */
[platform:Error]    ^
[platform:Error] data_pypy_module_cpyext_pyobject.c:173:3: warning: (near
initialization for 'pypy_g_array_916.a.items[13].d_value') [enabled by
default]
[platform:Error] data_pypy_module_cpyext_pyobject.c:238:3: warning:
initialization from incompatible pointer type [enabled by default]
[platform:Error]    (&PyWrapperDescr_Type), /* 26.value */

...... SKIPPED

[platform:Error] In file included from
/home/e-max/workspace/pypy/pypy/module/cpyext/include/Python.h:132:0,
[platform:Error]                  from structseq.c:4:
[platform:Error] ../pypy_decl.h:403:17: note: expected 'struct PyObject *'
but argument is of type 'struct PyTupleObject *'
[platform:Error]  PyAPI_FUNC(int) PyTuple_SetItem(PyObject *arg0,
Py_ssize_t arg1, PyObject *arg2);
[platform:Error]                  ^
[platform:Error] In file included from ../module_cache/module_3.c:166:0:
[platform:Error]
/home/e-max/workspace/pypy/rpython/translator/c/src/dtoa.c:131:0: warning:
"PyMem_Malloc" redefined [enabled by default]
[platform:Error]  #define PyMem_Malloc malloc
[platform:Error]  ^
[platform:Error] In file included from
/home/e-max/workspace/pypy/pypy/module/cpyext/include/Python.h:117:0,
[platform:Error]                  from ../module_cache/module_3.c:34:
[platform:Error]
/home/e-max/workspace/pypy/pypy/module/cpyext/include/pymem.h:8:0: note:
this is the location of the previous definition
[platform:Error]  #define PyMem_Malloc PyMem_MALLOC
[platform:Error]  ^
[platform:Error] In file included from ../module_cache/module_3.c:166:0:
[platform:Error]
/home/e-max/workspace/pypy/rpython/translator/c/src/dtoa.c:132:0: warning:
"PyMem_Free" redefined [enabled by default]
[platform:Error]  #define PyMem_Free free
[platform:Error]  ^
[platform:Error] In file included from
/home/e-max/workspace/pypy/pypy/module/cpyext/include/Python.h:117:0,
[platform:Error]                  from ../module_cache/module_3.c:34:
[platform:Error]
/home/e-max/workspace/pypy/pypy/module/cpyext/include/pymem.h:9:0: note:
this is the location of the previous definition
[platform:Error]  #define PyMem_Free  PyMem_FREE
[platform:Error]  ^
[platform:Error] Traceback (most recent call last):
[platform:Error]   File "app_main.py", line 52, in run_toplevel
[platform:Error]   File
"/home/e-max/workspace/pypy/rpython/translator/c/gcc/trackgcroot.py", line
2029, in <module>
[platform:Error]     tracker.process(f, g, filename=fn)
[platform:Error]   File
"/home/e-max/workspace/pypy/rpython/translator/c/gcc/trackgcroot.py", line
1922, in process
[platform:Error]     tracker = parser.process_function(lines, filename)
[platform:Error]   File
"/home/e-max/workspace/pypy/rpython/translator/c/gcc/trackgcroot.py", line
1437, in process_function
[platform:Error]     table = tracker.computegcmaptable(self.verbose)
[platform:Error]   File
"/home/e-max/workspace/pypy/rpython/translator/c/gcc/trackgcroot.py", line
59, in computegcmaptable
[platform:Error]     self.findframesize()
[platform:Error]   File
"/home/e-max/workspace/pypy/rpython/translator/c/gcc/trackgcroot.py", line
270, in findframesize
[platform:Error]     self.walk_instructions_backwards(walker, insn, 0)
[platform:Error]   File
"/home/e-max/workspace/pypy/rpython/translator/c/gcc/trackgcroot.py", line
355, in walk_instructions_backwards
[platform:Error]     for prevstate in walker(insn, state):
[platform:Error]   File
"/home/e-max/workspace/pypy/rpython/translator/c/gcc/trackgcroot.py", line
261, in walker
[platform:Error]     "inconsistent frame size at instruction %s" % (insn,))
[platform:Error] AssertionError: inconsistent frame size at instruction
InsnCopyLocal(%rbx, %rax) --- None
[platform:Error] make: *** [pypy_module__cffi_backend_ctypefunc.gcmap]
Error 1
[platform:Error] make: *** Waiting for unfinished jobs....
[5dd8a] translation-task}
[Timer] Timings:
[Timer] annotate                       ---  587.2 s
[Timer] rtype_lltype                   --- 1194.4 s
[Timer] pyjitpl_lltype                 --- 1057.4 s
[Timer] backendopt_lltype              ---  215.8 s
[Timer] stackcheckinsertion_lltype     ---  127.2 s
[Timer] database_c                     ---  310.0 s
[Timer] source_c                       ---  347.3 s
[Timer] compile_c                      ---  882.0 s
[Timer] ===========================================
[Timer] Total:                         --- 4721.3 s
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20130409/d059fba2/attachment.html>

From arigo at tunes.org  Tue Apr  9 12:31:30 2013
From: arigo at tunes.org (Armin Rigo)
Date: Tue, 9 Apr 2013 12:31:30 +0200
Subject: [pypy-dev] Build pypy-2.0b1
In-Reply-To: <CAAq2fm-=oXUUGmBhfViCd91twdd0iF=8qUXLFGgcxQ+CCzmGsQ@mail.gmail.com>
References: <CAAq2fm-=oXUUGmBhfViCd91twdd0iF=8qUXLFGgcxQ+CCzmGsQ@mail.gmail.com>
Message-ID: <CAMSv6X3U1Qpx86TaWfOmu482K3nMn3dhJzxyNPspqRfoTWeLRw@mail.gmail.com>

Hi Max,

On Tue, Apr 9, 2013 at 12:15 PM, Max Lavrenov <max.lavrenov at gmail.com> wrote:
> [platform:Error]     "inconsistent frame size at instruction %s" % (insn,))

We have seen this error reported already (it occurred with gcc 4.8,
but that may not be strictly related).  Assuming it's the same, I
fixed it in trunk.  Can you try to download the latest version of the
file rpython/translator/c/gcc/trackgcroot.py from this url:
https://bitbucket.org/pypy/pypy/raw/default/rpython/translator/c/gcc/trackgcroot.py
(or just switch to hg "default" if you got a hg repository)?  Then you
can type "make" in the directory
/tmp/usession-release-2.0-beta2-2/testing_1 to restart the final part.


A bient?t,

Armin.

From max.lavrenov at gmail.com  Tue Apr  9 15:32:58 2013
From: max.lavrenov at gmail.com (Max Lavrenov)
Date: Tue, 9 Apr 2013 17:32:58 +0400
Subject: [pypy-dev] Build pypy-2.0b1
In-Reply-To: <CAMSv6X3U1Qpx86TaWfOmu482K3nMn3dhJzxyNPspqRfoTWeLRw@mail.gmail.com>
References: <CAAq2fm-=oXUUGmBhfViCd91twdd0iF=8qUXLFGgcxQ+CCzmGsQ@mail.gmail.com>
	<CAMSv6X3U1Qpx86TaWfOmu482K3nMn3dhJzxyNPspqRfoTWeLRw@mail.gmail.com>
Message-ID: <CAAq2fm-SYzeFUqhRosGChJqDBZs2yQTrhDTj52gyWOiSKqccFQ@mail.gmail.com>

It works.  Thanks Armin!

Best regards,
Max


On Tue, Apr 9, 2013 at 2:31 PM, Armin Rigo <arigo at tunes.org> wrote:

> Hi Max,
>
> On Tue, Apr 9, 2013 at 12:15 PM, Max Lavrenov <max.lavrenov at gmail.com>
> wrote:
> > [platform:Error]     "inconsistent frame size at instruction %s" %
> (insn,))
>
> We have seen this error reported already (it occurred with gcc 4.8,
> but that may not be strictly related).  Assuming it's the same, I
> fixed it in trunk.  Can you try to download the latest version of the
> file rpython/translator/c/gcc/trackgcroot.py from this url:
>
> https://bitbucket.org/pypy/pypy/raw/default/rpython/translator/c/gcc/trackgcroot.py
> (or just switch to hg "default" if you got a hg repository)?  Then you
> can type "make" in the directory
> /tmp/usession-release-2.0-beta2-2/testing_1 to restart the final part.
>
>
> A bient?t,
>
> Armin.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20130409/70703c45/attachment.html>

From max.lavrenov at gmail.com  Tue Apr  9 15:36:55 2013
From: max.lavrenov at gmail.com (Max Lavrenov)
Date: Tue, 9 Apr 2013 17:36:55 +0400
Subject: [pypy-dev] Build pypy-2.0b1
In-Reply-To: <CAAq2fm-SYzeFUqhRosGChJqDBZs2yQTrhDTj52gyWOiSKqccFQ@mail.gmail.com>
References: <CAAq2fm-=oXUUGmBhfViCd91twdd0iF=8qUXLFGgcxQ+CCzmGsQ@mail.gmail.com>
	<CAMSv6X3U1Qpx86TaWfOmu482K3nMn3dhJzxyNPspqRfoTWeLRw@mail.gmail.com>
	<CAAq2fm-SYzeFUqhRosGChJqDBZs2yQTrhDTj52gyWOiSKqccFQ@mail.gmail.com>
Message-ID: <CAAq2fm8Kaf4KvR28sPSmQcgAFwO7RqNtKEhW89G4DAr8uyTWfw@mail.gmail.com>

And one more question about packaging.

[e-max at e-max release]$ ~/workspace/pypy_59920/bin/pypy package.py ../../..
pypy-63131
Traceback (most recent call last):
  File "app_main.py", line 52, in run_toplevel
  File "app_main.py", line 541, in run_it
  File "<string>", line 1, in <module>
  File "/home/e-max/workspace/pypy/lib_pypy/_sqlite3.py", line 262, in
<module>
    if _has_load_extension():
  File "/home/e-max/workspace/pypy/lib_pypy/_sqlite3.py", line 259, in
_has_load_extension
    unverified_lib = unverified_ffi.dlopen('sqlite3')
  File "/home/e-max/workspace/pypy/lib_pypy/cffi/api.py", line 111, in
dlopen
    lib, function_cache = _make_ffi_library(self, name, flags)
  File "/home/e-max/workspace/pypy/lib_pypy/cffi/api.py", line 362, in
_make_ffi_library
    path = ctypes.util.find_library(name)
  File "/home/e-max/workspace/pypy/lib-python/2.7/ctypes/util.py", line
213, in find_library
    return _findSoname_ldconfig(name) or _get_soname(_findLib_gcc(name))
  File "/home/e-max/workspace/pypy/lib-python/2.7/ctypes/util.py", line
202, in _findSoname_ldconfig
    f = os.popen('/sbin/ldconfig -p 2>/dev/null')
OSError: [Errno 12] Cannot allocate memory
Traceback (most recent call last):
  File "app_main.py", line 52, in run_toplevel
  File "package.py", line 185, in <module>
    package(*args, **kw)
  File "package.py", line 69, in package
    subprocess.check_call([str(pypy_c), '-c', 'import _sqlite3'])
  File "/home/e-max/workspace/pypy_59920/lib-python/2.7/subprocess.py",
line 511, in check_call
    raise CalledProcessError(retcode, cmd)
CalledProcessError: Command
'['/home/e-max/workspace/pypy/pypy/goal/pypy-c', '-c', 'import _sqlite3']'
returned non-zero exit status 1


On Tue, Apr 9, 2013 at 5:32 PM, Max Lavrenov <max.lavrenov at gmail.com> wrote:

> It works.  Thanks Armin!
>
> Best regards,
> Max
>
>
> On Tue, Apr 9, 2013 at 2:31 PM, Armin Rigo <arigo at tunes.org> wrote:
>
>> Hi Max,
>>
>> On Tue, Apr 9, 2013 at 12:15 PM, Max Lavrenov <max.lavrenov at gmail.com>
>> wrote:
>> > [platform:Error]     "inconsistent frame size at instruction %s" %
>> (insn,))
>>
>> We have seen this error reported already (it occurred with gcc 4.8,
>> but that may not be strictly related).  Assuming it's the same, I
>> fixed it in trunk.  Can you try to download the latest version of the
>> file rpython/translator/c/gcc/trackgcroot.py from this url:
>>
>> https://bitbucket.org/pypy/pypy/raw/default/rpython/translator/c/gcc/trackgcroot.py
>> (or just switch to hg "default" if you got a hg repository)?  Then you
>> can type "make" in the directory
>> /tmp/usession-release-2.0-beta2-2/testing_1 to restart the final part.
>>
>>
>> A bient?t,
>>
>> Armin.
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20130409/d3f4e50d/attachment-0001.html>

From p.j.a.cock at googlemail.com  Tue Apr  9 18:45:21 2013
From: p.j.a.cock at googlemail.com (Peter Cock)
Date: Tue, 9 Apr 2013 17:45:21 +0100
Subject: [pypy-dev] OSError not ImportError from 'import sqlite3' on Windows
Message-ID: <CAKVJ-_6n-REN46zuhW-MzauEQq6zPD_ba6dsF0LcZOMVmujOsA@mail.gmail.com>

Hello all,

I've downloaded and unzipped pypy-2.0-beta2-win32.zip but
fairly early on in my testing ran into this puzzle:

C:\>c:\pypy-2.0\pypy.exe
Python 2.7.3 (3eef596df459, Apr 06 2013, 12:40:10)
[PyPy 2.0.0-beta2 with MSC v.1500 32 bit] on win32
Type "help", "copyright", "credits" or "license" for more information.
And now for something completely different: ``the zen attitude to programming:
reducing the oopses in your life''
>>>> import sqlite3
Traceback (most recent call last):
  File "<console>", line 1, in <module>
  File "c:\pypy-2.0\lib-python\2.7\sqlite3\__init__.py", line 24, in <module>
    from dbapi2 import *
  File "c:\pypy-2.0\lib-python\2.7\sqlite3\dbapi2.py", line 27, in <module>
    from _sqlite3 import *
  File "c:\pypy-2.0\lib_pypy\_sqlite3.py", line 262, in <module>
    if _has_load_extension():
  File "c:\pypy-2.0\lib_pypy\_sqlite3.py", line 259, in _has_load_extension
    unverified_lib = unverified_ffi.dlopen('sqlite3')
  File "c:\pypy-2.0\lib_pypy\cffi\api.py", line 111, in dlopen
    lib, function_cache = _make_ffi_library(self, name, flags)
  File "c:\pypy-2.0\lib_pypy\cffi\api.py", line 364, in _make_ffi_library
    raise OSError("library not found: %r" % (name,))
OSError: library not found: 'sqlite3'
>>>> quit()

While I would of course hope sqlite3 would work, the fact that
I get an OSError not an ImportError is preventing my code
catching this exception and handling as I would on other
platforms (like Jython) lacking this module.

I'm running this on Windows XP SP3 (32bit).

What more information can I share about this?

Thanks,

Peter

From pjenvey at underboss.org  Tue Apr  9 20:35:06 2013
From: pjenvey at underboss.org (Philip Jenvey)
Date: Tue, 9 Apr 2013 11:35:06 -0700
Subject: [pypy-dev] OSError not ImportError from 'import sqlite3' on
	Windows
In-Reply-To: <CAKVJ-_6n-REN46zuhW-MzauEQq6zPD_ba6dsF0LcZOMVmujOsA@mail.gmail.com>
References: <CAKVJ-_6n-REN46zuhW-MzauEQq6zPD_ba6dsF0LcZOMVmujOsA@mail.gmail.com>
Message-ID: <CAJUk6tsXDvVAtL_JmV8ajkg+CdktmpkN+NVfik9WiA9RudZOhg@mail.gmail.com>

This was fixed yesterday, see: https://bugs.pypy.org/issue1440
On Apr 9, 2013 9:45 AM, "Peter Cock" <p.j.a.cock at googlemail.com> wrote:

> Hello all,
>
> I've downloaded and unzipped pypy-2.0-beta2-win32.zip but
> fairly early on in my testing ran into this puzzle:
>
> C:\>c:\pypy-2.0\pypy.exe
> Python 2.7.3 (3eef596df459, Apr 06 2013, 12:40:10)
> [PyPy 2.0.0-beta2 with MSC v.1500 32 bit] on win32
> Type "help", "copyright", "credits" or "license" for more information.
> And now for something completely different: ``the zen attitude to
> programming:
> reducing the oopses in your life''
> >>>> import sqlite3
> Traceback (most recent call last):
>   File "<console>", line 1, in <module>
>   File "c:\pypy-2.0\lib-python\2.7\sqlite3\__init__.py", line 24, in
> <module>
>     from dbapi2 import *
>   File "c:\pypy-2.0\lib-python\2.7\sqlite3\dbapi2.py", line 27, in <module>
>     from _sqlite3 import *
>   File "c:\pypy-2.0\lib_pypy\_sqlite3.py", line 262, in <module>
>     if _has_load_extension():
>   File "c:\pypy-2.0\lib_pypy\_sqlite3.py", line 259, in _has_load_extension
>     unverified_lib = unverified_ffi.dlopen('sqlite3')
>   File "c:\pypy-2.0\lib_pypy\cffi\api.py", line 111, in dlopen
>     lib, function_cache = _make_ffi_library(self, name, flags)
>   File "c:\pypy-2.0\lib_pypy\cffi\api.py", line 364, in _make_ffi_library
>     raise OSError("library not found: %r" % (name,))
> OSError: library not found: 'sqlite3'
> >>>> quit()
>
> While I would of course hope sqlite3 would work, the fact that
> I get an OSError not an ImportError is preventing my code
> catching this exception and handling as I would on other
> platforms (like Jython) lacking this module.
>
> I'm running this on Windows XP SP3 (32bit).
>
> What more information can I share about this?
>
> Thanks,
>
> Peter
> _______________________________________________
> pypy-dev mailing list
> pypy-dev at python.org
> http://mail.python.org/mailman/listinfo/pypy-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20130409/88297a16/attachment.html>

From p.j.a.cock at googlemail.com  Tue Apr  9 21:03:45 2013
From: p.j.a.cock at googlemail.com (Peter Cock)
Date: Tue, 9 Apr 2013 20:03:45 +0100
Subject: [pypy-dev] OSError not ImportError from 'import sqlite3' on
	Windows
In-Reply-To: <CAJUk6tsXDvVAtL_JmV8ajkg+CdktmpkN+NVfik9WiA9RudZOhg@mail.gmail.com>
References: <CAKVJ-_6n-REN46zuhW-MzauEQq6zPD_ba6dsF0LcZOMVmujOsA@mail.gmail.com>
	<CAJUk6tsXDvVAtL_JmV8ajkg+CdktmpkN+NVfik9WiA9RudZOhg@mail.gmail.com>
Message-ID: <CAKVJ-_622XgeQa1oyTmtKg3WydVv93jQJUDwxPKDybWvXN7R2w@mail.gmail.com>

On Tue, Apr 9, 2013 at 7:35 PM, Philip Jenvey <pjenvey at underboss.org> wrote:
> This was fixed yesterday, see: https://bugs.pypy.org/issue1440
>

Thanks! The bug report doesn't auto-link to the repository,
so for anyone else the changeset is here and looks easy
enough to apply manually to try it on Windows without
having to wait for the next release and/or compile locally:
https://bitbucket.org/pypy/pypy/commits/341a34c7d62f

Cheers,

Peter

From matti.picus at gmail.com  Tue Apr  9 21:11:41 2013
From: matti.picus at gmail.com (Matti Picus)
Date: Tue, 09 Apr 2013 22:11:41 +0300
Subject: [pypy-dev] OSError not ImportError from 'import sqlite3' on
	Windows
In-Reply-To: <CAKVJ-_622XgeQa1oyTmtKg3WydVv93jQJUDwxPKDybWvXN7R2w@mail.gmail.com>
References: <CAKVJ-_6n-REN46zuhW-MzauEQq6zPD_ba6dsF0LcZOMVmujOsA@mail.gmail.com>
	<CAJUk6tsXDvVAtL_JmV8ajkg+CdktmpkN+NVfik9WiA9RudZOhg@mail.gmail.com>
	<CAKVJ-_622XgeQa1oyTmtKg3WydVv93jQJUDwxPKDybWvXN7R2w@mail.gmail.com>
Message-ID: <516467ED.5020501@gmail.com>

Note that patch is incomplete, it is missing an "import os" (thanks bdk) 
that was added in a later changeset.
Matti
On 9/04/2013 10:03 PM, Peter Cock wrote:
> On Tue, Apr 9, 2013 at 7:35 PM, Philip Jenvey <pjenvey at underboss.org> wrote:
>> This was fixed yesterday, see: https://bugs.pypy.org/issue1440
>>
> Thanks! The bug report doesn't auto-link to the repository,
> so for anyone else the changeset is here and looks easy
> enough to apply manually to try it on Windows without
> having to wait for the next release and/or compile locally:
> https://bitbucket.org/pypy/pypy/commits/341a34c7d62f
>
> Cheers,
>
> Peter
> _______________________________________________
> pypy-dev mailing list
> pypy-dev at python.org
> http://mail.python.org/mailman/listinfo/pypy-dev


From amirouche.boubekki at gmail.com  Tue Apr  9 21:20:12 2013
From: amirouche.boubekki at gmail.com (Amirouche Boubekki)
Date: Tue, 9 Apr 2013 21:20:12 +0200
Subject: [pypy-dev] Redis clone
Message-ID: <CAL7_Mo_darrXY5uOEBk7UmNBik7fn5DfK=io_vD23eGATcKiXg@mail.gmail.com>

H?llo,

I'm working on porting a redis clone to pypy-stm [1].

I did some benchmark, the interesting code is [2]. it runs 5 thread both on
sides client/server, it might be much, what do you think ? I have 4 cores.

(memo-stm)amirouche at funfev13 ~/src/Memo/client (pypy-stm*) $ time python
test_client_threaded.py
start training
training done
start spellchecking
1181 out of 4236

real    34,81s
user    12,76s
sys    0,40s

(memo-stm)amirouche at funfev13 ~/src/Memo/client (pypy-stm*) $ time python
test_client.py
start training
training done
start spellchecking
1181 out of 4234

real    61,22s
user    5,69s
sys    0,87s

I'm thinking about implementing other algorithms; no sure what yet probably
bloom filters or bit arrays but I don't have right now a usecase in mind.

I also started Graph database [3] which AFAIK should work and which also
has even if MVCC some atomic call to be used, the test I'm aiming with this
one is loading a wikipedia.

How can I help you better ?


Thanks.


Amirouche


[1] https://github.com/amirouche/Memo/tree/pypy-stm
[2] a simple suggestion algorithm:
https://github.com/amirouche/Memo/blob/pypy-stm/server/memo/structures/suggest.py
[3] http://blog-amirouche.dotcloud.com/notes/projects/graphitidb.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20130409/4feff3b9/attachment-0001.html>

From p.j.a.cock at googlemail.com  Tue Apr  9 21:23:41 2013
From: p.j.a.cock at googlemail.com (Peter Cock)
Date: Tue, 9 Apr 2013 20:23:41 +0100
Subject: [pypy-dev] OSError not ImportError from 'import sqlite3' on
	Windows
In-Reply-To: <516467ED.5020501@gmail.com>
References: <CAKVJ-_6n-REN46zuhW-MzauEQq6zPD_ba6dsF0LcZOMVmujOsA@mail.gmail.com>
	<CAJUk6tsXDvVAtL_JmV8ajkg+CdktmpkN+NVfik9WiA9RudZOhg@mail.gmail.com>
	<CAKVJ-_622XgeQa1oyTmtKg3WydVv93jQJUDwxPKDybWvXN7R2w@mail.gmail.com>
	<516467ED.5020501@gmail.com>
Message-ID: <CAKVJ-_75JnViw9OQ-DXCmvtrvpTZ-TbHfsj+k=8pVmoPSA42UA@mail.gmail.com>

On Tue, Apr 9, 2013 at 8:11 PM, Matti Picus <matti.picus at gmail.com> wrote:
> Note that patch is incomplete, it is missing an "import os" (thanks bdk)
> that was added in a later changeset.
> Matti

I'd probably have managed but thanks - one less surprise
for me tomorrow :)

I was wondering if this was a symptom of a larger issue where
importing cffi libraries can fail with OSError rather than ImportError?

Regards,

Peter

From amauryfa at gmail.com  Tue Apr  9 23:54:47 2013
From: amauryfa at gmail.com (Amaury Forgeot d'Arc)
Date: Tue, 9 Apr 2013 23:54:47 +0200
Subject: [pypy-dev] OSError not ImportError from 'import sqlite3' on
	Windows
In-Reply-To: <CAKVJ-_75JnViw9OQ-DXCmvtrvpTZ-TbHfsj+k=8pVmoPSA42UA@mail.gmail.com>
References: <CAKVJ-_6n-REN46zuhW-MzauEQq6zPD_ba6dsF0LcZOMVmujOsA@mail.gmail.com>
	<CAJUk6tsXDvVAtL_JmV8ajkg+CdktmpkN+NVfik9WiA9RudZOhg@mail.gmail.com>
	<CAKVJ-_622XgeQa1oyTmtKg3WydVv93jQJUDwxPKDybWvXN7R2w@mail.gmail.com>
	<516467ED.5020501@gmail.com>
	<CAKVJ-_75JnViw9OQ-DXCmvtrvpTZ-TbHfsj+k=8pVmoPSA42UA@mail.gmail.com>
Message-ID: <CAGmFidYGSP7BLXM9XbN3UDLCM_GUKcVcHK08k973ks9Ss0APPw@mail.gmail.com>

2013/4/9 Peter Cock <p.j.a.cock at googlemail.com>

> On Tue, Apr 9, 2013 at 8:11 PM, Matti Picus <matti.picus at gmail.com> wrote:
> > Note that patch is incomplete, it is missing an "import os" (thanks bdk)
> > that was added in a later changeset.
> > Matti
>
> I'd probably have managed but thanks - one less surprise
> for me tomorrow :)
>
> I was wondering if this was a symptom of a larger issue where
> importing cffi libraries can fail with OSError rather than ImportError?
>

cffi functions may fail in various ways: cannot parse declarations, cannot
verify with the compiler, library or function not found...
At cffi level it makes sense to have different kinds of errors.

Now, at the library level that's another thing.
_sqlite3.py should catch common errors and raise ImportError instead,
but only for errors related to the machine installation.

-- 
Amaury Forgeot d'Arc
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20130409/a1a23b54/attachment.html>

From anto.cuni at gmail.com  Wed Apr 10 11:42:35 2013
From: anto.cuni at gmail.com (Antonio Cuni)
Date: Wed, 10 Apr 2013 10:42:35 +0100
Subject: [pypy-dev] [pypy-commit] pypy default: make looking up
 encodings free with the JIT
In-Reply-To: <20130410025328.9B3601C30E8@cobra.cs.uni-duesseldorf.de>
References: <20130410025328.9B3601C30E8@cobra.cs.uni-duesseldorf.de>
Message-ID: <5165340B.7040807@gmail.com>

Hi Alex,

could we have a test_pypy_c test for this please?

On 10/04/13 03:53, alex_gaynor wrote:
> Author: Alex Gaynor <alex.gaynor at gmail.com>
> Branch:
> Changeset: r63186:c514bbc4c086
> Date: 2013-04-09 19:53 -0700
> http://bitbucket.org/pypy/pypy/changeset/c514bbc4c086/
>
> Log:	make looking up encodings free with the JIT
>
> diff --git a/pypy/module/_codecs/interp_codecs.py b/pypy/module/_codecs/interp_codecs.py
> --- a/pypy/module/_codecs/interp_codecs.py
> +++ b/pypy/module/_codecs/interp_codecs.py
> @@ -1,10 +1,18 @@
> +from rpython.rlib import jit
> +from rpython.rlib.objectmodel import we_are_translated
> +from rpython.rlib.rstring import UnicodeBuilder
> +
>   from pypy.interpreter.error import OperationError, operationerrfmt
>   from pypy.interpreter.gateway import interp2app, unwrap_spec, WrappedDefault
> -from rpython.rlib.rstring import UnicodeBuilder
> -from rpython.rlib.objectmodel import we_are_translated
> +
> +
> +class VersionTag(object):
> +    pass
>
>
>   class CodecState(object):
> +    _immutable_fields_ = ["version?"]
> +
>       def __init__(self, space):
>           self.codec_search_path = []
>           self.codec_search_cache = {}
> @@ -14,6 +22,7 @@
>           self.encode_error_handler = self.make_encode_errorhandler(space)
>
>           self.unicodedata_handler = None
> +        self.modified()
>
>       def _make_errorhandler(self, space, decode):
>           def call_errorhandler(errors, encoding, reason, input, startpos,
> @@ -86,9 +95,20 @@
>               self.unicodedata_handler = UnicodeData_Handler(space, w_getcode)
>               return self.unicodedata_handler
>
> +    def modified(self):
> +        self.version = VersionTag()
> +
> +    def get_codec_from_cache(self, key):
> +        return self._get_codec_with_version(key, self.version)
> +
> +    @jit.elidable
> +    def _get_codec_with_version(self, key, version):
> +        return self.codec_search_cache.get(key, None)
> +
>       def _cleanup_(self):
>           assert not self.codec_search_path
>
> +
>   def register_codec(space, w_search_function):
>       """register(search_function)
>
> @@ -115,11 +135,12 @@
>           "lookup_codec() should not be called during translation"
>       state = space.fromcache(CodecState)
>       normalized_encoding = encoding.replace(" ", "-").lower()
> -    w_result = state.codec_search_cache.get(normalized_encoding, None)
> +    w_result = state.get_codec_from_cache(normalized_encoding)
>       if w_result is not None:
>           return w_result
>       return _lookup_codec_loop(space, encoding, normalized_encoding)
>
> +
>   def _lookup_codec_loop(space, encoding, normalized_encoding):
>       state = space.fromcache(CodecState)
>       if state.codec_need_encodings:
> @@ -143,6 +164,7 @@
>                       space.wrap("codec search functions must return 4-tuples"))
>               else:
>                   state.codec_search_cache[normalized_encoding] = w_result
> +                state.modified()
>                   return w_result
>       raise operationerrfmt(
>           space.w_LookupError,
> _______________________________________________
> pypy-commit mailing list
> pypy-commit at python.org
> http://mail.python.org/mailman/listinfo/pypy-commit
>
	

From cfbolz at gmx.de  Wed Apr 10 14:55:21 2013
From: cfbolz at gmx.de (Carl Friedrich Bolz)
Date: Wed, 10 Apr 2013 14:55:21 +0200
Subject: [pypy-dev] [pypy-commit] pypy default: make looking up
	encodings free with the JIT
In-Reply-To: <5165340B.7040807@gmail.com>
References: <20130410025328.9B3601C30E8@cobra.cs.uni-duesseldorf.de>
	<5165340B.7040807@gmail.com>
Message-ID: <9e66fc22-1ee3-496b-a80d-d8ca598e3b3e@email.android.com>

Hi Alex, 

I agree with Anto. Also, this has happened a few times now :-). I know that it's inconvenient to do a local translation or a branch. Can we think of another way to make this less annoying/prevent it from being forgotten? 

Cheers, 

Carl Friedrich 

Antonio Cuni <anto.cuni at gmail.com> wrote:

>Hi Alex,
>
>could we have a test_pypy_c test for this please?
>
>On 10/04/13 03:53, alex_gaynor wrote:
>> Author: Alex Gaynor <alex.gaynor at gmail.com>
>> Branch:
>> Changeset: r63186:c514bbc4c086
>> Date: 2013-04-09 19:53 -0700
>> http://bitbucket.org/pypy/pypy/changeset/c514bbc4c086/
>>
>> Log:	make looking up encodings free with the JIT
>>
>> diff --git a/pypy/module/_codecs/interp_codecs.py
>b/pypy/module/_codecs/interp_codecs.py
>> --- a/pypy/module/_codecs/interp_codecs.py
>> +++ b/pypy/module/_codecs/interp_codecs.py
>> @@ -1,10 +1,18 @@
>> +from rpython.rlib import jit
>> +from rpython.rlib.objectmodel import we_are_translated
>> +from rpython.rlib.rstring import UnicodeBuilder
>> +
>>   from pypy.interpreter.error import OperationError, operationerrfmt
>>   from pypy.interpreter.gateway import interp2app, unwrap_spec,
>WrappedDefault
>> -from rpython.rlib.rstring import UnicodeBuilder
>> -from rpython.rlib.objectmodel import we_are_translated
>> +
>> +
>> +class VersionTag(object):
>> +    pass
>>
>>
>>   class CodecState(object):
>> +    _immutable_fields_ = ["version?"]
>> +
>>       def __init__(self, space):
>>           self.codec_search_path = []
>>           self.codec_search_cache = {}
>> @@ -14,6 +22,7 @@
>>           self.encode_error_handler =
>self.make_encode_errorhandler(space)
>>
>>           self.unicodedata_handler = None
>> +        self.modified()
>>
>>       def _make_errorhandler(self, space, decode):
>>           def call_errorhandler(errors, encoding, reason, input,
>startpos,
>> @@ -86,9 +95,20 @@
>>               self.unicodedata_handler = UnicodeData_Handler(space,
>w_getcode)
>>               return self.unicodedata_handler
>>
>> +    def modified(self):
>> +        self.version = VersionTag()
>> +
>> +    def get_codec_from_cache(self, key):
>> +        return self._get_codec_with_version(key, self.version)
>> +
>> +    @jit.elidable
>> +    def _get_codec_with_version(self, key, version):
>> +        return self.codec_search_cache.get(key, None)
>> +
>>       def _cleanup_(self):
>>           assert not self.codec_search_path
>>
>> +
>>   def register_codec(space, w_search_function):
>>       """register(search_function)
>>
>> @@ -115,11 +135,12 @@
>>           "lookup_codec() should not be called during translation"
>>       state = space.fromcache(CodecState)
>>       normalized_encoding = encoding.replace(" ", "-").lower()
>> -    w_result = state.codec_search_cache.get(normalized_encoding,
>None)
>> +    w_result = state.get_codec_from_cache(normalized_encoding)
>>       if w_result is not None:
>>           return w_result
>>       return _lookup_codec_loop(space, encoding, normalized_encoding)
>>
>> +
>>   def _lookup_codec_loop(space, encoding, normalized_encoding):
>>       state = space.fromcache(CodecState)
>>       if state.codec_need_encodings:
>> @@ -143,6 +164,7 @@
>>                       space.wrap("codec search functions must return
>4-tuples"))
>>               else:
>>                   state.codec_search_cache[normalized_encoding] =
>w_result
>> +                state.modified()
>>                   return w_result
>>       raise operationerrfmt(
>>           space.w_LookupError,
>> _______________________________________________
>> pypy-commit mailing list
>> pypy-commit at python.org
>> http://mail.python.org/mailman/listinfo/pypy-commit
>>
>	
>_______________________________________________
>pypy-dev mailing list
>pypy-dev at python.org
>http://mail.python.org/mailman/listinfo/pypy-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20130410/cdb562a8/attachment.html>

From alex.gaynor at gmail.com  Wed Apr 10 16:51:13 2013
From: alex.gaynor at gmail.com (Alex Gaynor)
Date: Wed, 10 Apr 2013 07:51:13 -0700
Subject: [pypy-dev] [pypy-commit] pypy default: make looking up
 encodings free with the JIT
In-Reply-To: <9e66fc22-1ee3-496b-a80d-d8ca598e3b3e@email.android.com>
References: <20130410025328.9B3601C30E8@cobra.cs.uni-duesseldorf.de>
	<5165340B.7040807@gmail.com>
	<9e66fc22-1ee3-496b-a80d-d8ca598e3b3e@email.android.com>
Message-ID: <CAFRnB2W3Gb4C7tvYntpRD7dAEN8ULup_zEtm94HUFkMZcyT8+w@mail.gmail.com>

Hi guys,

I just wrote a JIT test for this, I haven't actually run it since I don't
have a local translation, however I'll kick the buildbot and review the
results.

Alex


On Wed, Apr 10, 2013 at 5:55 AM, Carl Friedrich Bolz <cfbolz at gmx.de> wrote:

> Hi Alex,
>
> I agree with Anto. Also, this has happened a few times now :-). I know
> that it's inconvenient to do a local translation or a branch. Can we think
> of another way to make this less annoying/prevent it from being forgotten?
>
> Cheers,
>
> Carl Friedrich
>
>
> Antonio Cuni <anto.cuni at gmail.com> wrote:
>>
>> Hi Alex,
>>
>> could we have a test_pypy_c test for this please?
>>
>> On 10/04/13 03:53, alex_gaynor wrote:
>>
>>> Author: Alex Gaynor <alex.gaynor at gmail.com>
>>> Branch:
>>> Changeset: r63186:c514bbc4c086
>>> Date: 2013-04-09 19:53 -0700
>>> http://bitbucket.org/pypy/pypy/changeset/c514bbc4c086/
>>>
>>> Log: make looking up encodings free with the JIT
>>>
>>> diff --git a/pypy/module/_codecs/interp_codecs.py b/pypy/module/_codecs/interp_codecs.py
>>> --- a/pypy/module/_codecs/interp_codecs.py
>>> +++ b/pypy/module/_codecs/interp_codecs.py
>>> @@ -1,10 +1,18 @@
>>> +from rpython.rlib import jit
>>> +from rpython.rlib.objectmodel
>>> import we_are_translated
>>> +from rpython.rlib.rstring import UnicodeBuilder
>>> +
>>> from pypy.interpreter.error import OperationError, operationerrfmt
>>> from pypy.interpreter.gateway import interp2app, unwrap_spec, WrappedDefault
>>> -from rpython.rlib.rstring import UnicodeBuilder
>>> -from rpython.rlib.objectmodel import we_are_translated
>>> +
>>> +
>>> +class VersionTag(object):
>>> +    pass
>>>
>>>
>>> class CodecState(object):
>>> +    _immutable_fields_ = ["version?"]
>>> +
>>> def __init__(self, space):
>>> self.codec_search_path = []
>>> self.codec_search_cache = {}
>>> @@ -14,6 +22,7 @@
>>> self.encode_error_handler = self.make_encode_errorhandler(space)
>>>
>>> self.unicodedata_handler = None
>>> +        self.modified()
>>>
>>> def _make_errorhandler(self, space, decode):
>>> def call_errorhandler(errors, encoding, reason, input, startpos,
>>> @@ -86,9 +95,20 @@
>>> self.unicodedata_handler = UnicodeData_Handler(space, w_getcode)
>>> return self.unicodedata_handler
>>>
>>> +    def modified(self):
>>> +        self.version = VersionTag()
>>> +
>>> +    def get_codec_from_cache(self, key):
>>> +        return self._get_codec_with_version(key, self.version)
>>> +
>>> +    @jit.elidable
>>> +    def _get_codec_with_version(self, key, version):
>>> +        return self.codec_search_cache.get(key, None)
>>> +
>>> def _cleanup_(self):
>>> assert not self.codec_search_path
>>>
>>> +
>>> def register_codec(space, w_search_function):
>>> """register(search_function)
>>>
>>> @@ -115,11 +135,12 @@
>>> "lookup_codec() should not be called during translation"
>>> state = space.fromcache(CodecState)
>>> normalized_encoding = encoding.replace(" ", "-").lower()
>>> -    w_result = state.codec_search_cache.get(normalized_encoding, None)
>>> +    w_result = state.get_codec_from_cache(normalized_encoding)
>>> if w_result is not None:
>>> return w_result
>>> return _lookup_codec_loop(space, encoding,
>>> normalized_encoding)
>>>
>>> +
>>> def _lookup_codec_loop(space, encoding, normalized_encoding):
>>> state = space.fromcache(CodecState)
>>> if state.codec_need_encodings:
>>> @@ -143,6 +164,7 @@
>>> space.wrap("codec search functions must return 4-tuples"))
>>> else:
>>> state.codec_search_cache[normalized_encoding] = w_result
>>> +                state.modified()
>>> return w_result
>>> raise operationerrfmt(
>>> space.w_LookupError,
>>> ------------------------------
>>>
>>> pypy-commit mailing list
>>> pypy-commit at python.org
>>> http://mail.python.org/mailman/listinfo/pypy-commit
>>>
>>
>>
>> ------------------------------
>>
>> pypy-dev mailing list
>> pypy-dev at python.org
>> http://mail.python.org/mailman/listinfo/pypy-dev
>>
>>
> _______________________________________________
> pypy-dev mailing list
> pypy-dev at python.org
> http://mail.python.org/mailman/listinfo/pypy-dev
>
>


-- 
"I disapprove of what you say, but I will defend to the death your right to
say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
"The people's good is the highest law." -- Cicero
GPG Key fingerprint: 125F 5C67 DFE9 4084
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20130410/50ddaae1/attachment.html>

From amirouche.boubekki at gmail.com  Wed Apr 10 17:03:25 2013
From: amirouche.boubekki at gmail.com (Amirouche Boubekki)
Date: Wed, 10 Apr 2013 17:03:25 +0200
Subject: [pypy-dev] =?utf-8?q?Redis_=C2=ABclone=C2=BB_using_pypy_stm-threa?=
	=?utf-8?q?d-2_=28Was=3A_Redis_clone=29?=
Message-ID: <CAL7_Mo--Vt0LNRd24DkcKrdFzPeVnkeQPAny4YWywGd9dpnuWw@mail.gmail.com>

H?llo again,

2013/4/9 Amirouche Boubekki <amirouche.boubekki at gmail.com>

> H?llo,
>
> I'm working on porting a redis clone to pypy-stm [1].
>
> I did some benchmark, the interesting code is [2]. it runs 5 thread both
> on sides client/server, it might be much, what do you think ? I have 4
> cores.
>
> (memo-stm)amirouche at funfev13 ~/src/Memo/client (pypy-stm*) $ time python
> test_client_threaded.py
> start training
> training done
> start spellchecking
> 1181 out of 4236
>
> real    34,81s
> user    12,76s
> sys    0,40s
>
> (memo-stm)amirouche at funfev13 ~/src/Memo/client (pypy-stm*) $ time python
> test_client.py
> start training
> training done
> start spellchecking
> 1181 out of 4234
>
> real    61,22s
> user    5,69s
> sys    0,87s
>
> I'm thinking about implementing other algorithms; no sure what yet
> probably bloom filters or bit arrays but I don't have right now a usecase
> in mind.
>
> I also started Graph database [3] which AFAIK should work and which also
> has even if MVCC some atomic call to be used, the test I'm aiming with this
> one is loading a wikipedia.
>
> How can I help you better ?
>
>
> Thanks.
>
>
> Amirouche
>
>
> [1] https://github.com/amirouche/Memo/tree/pypy-stm
> [2] a simple suggestion algorithm:
> https://github.com/amirouche/Memo/blob/pypy-stm/server/memo/structures/suggest.py
> [3] http://blog-amirouche.dotcloud.com/notes/projects/graphitidb.html
>

I did another benchmark with 2 thread both sides, numbers are... different:

(memo-stm)amirouche at funfev13 ~/src/Memo/client (pypy-stm*) $ time python
test_client_threaded.py
start training
training done
start spellchecking
1181 out of 4236

real    14,66s
user    5,79s
sys    0,60s

(memo-stm)amirouche at funfev13 ~/src/Memo/client (pypy-stm*) $ time python
test_client.py
start training
training done
start spellchecking
1181 out of 4234

real    12,63s
user    5,49s
sys    0,66s

Also even if I've written it's redis clone, it's not quite as useful as
Redis but I though that it could be useful to test pypy stm,

HTH,

Amirouche
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20130410/fe89a967/attachment-0001.html>

From anto.cuni at gmail.com  Wed Apr 10 17:07:58 2013
From: anto.cuni at gmail.com (Antonio Cuni)
Date: Wed, 10 Apr 2013 16:07:58 +0100
Subject: [pypy-dev] [pypy-commit] pypy default: make looking up
 encodings free with the JIT
In-Reply-To: <CAFRnB2W3Gb4C7tvYntpRD7dAEN8ULup_zEtm94HUFkMZcyT8+w@mail.gmail.com>
References: <20130410025328.9B3601C30E8@cobra.cs.uni-duesseldorf.de>
	<5165340B.7040807@gmail.com>
	<9e66fc22-1ee3-496b-a80d-d8ca598e3b3e@email.android.com>
	<CAFRnB2W3Gb4C7tvYntpRD7dAEN8ULup_zEtm94HUFkMZcyT8+w@mail.gmail.com>
Message-ID: <5165804E.2010103@gmail.com>

On 10/04/13 15:51, Alex Gaynor wrote:
> Hi guys,
>
> I just wrote a JIT test for this, I haven't actually run it since I don't have
> a local translation, however I'll kick the buildbot and review the results.

well, my point is that you should not commit a JIT optimization if you are not 
sure it actually improves the code. It's too easy to make a small mistake and 
make it useless.

I agree it's inconvenient, but what I usually do is to do a translation on 
tannit, check the generated code, and then commit both the change and the 
pypy_c test.

ciao,
Anto


From fijall at gmail.com  Thu Apr 11 11:46:07 2013
From: fijall at gmail.com (Maciej Fijalkowski)
Date: Thu, 11 Apr 2013 11:46:07 +0200
Subject: [pypy-dev] Fwd: Windows 64 bit version
In-Reply-To: <1365620550.27979.YahooMailNeo@web162203.mail.bf1.yahoo.com>
References: <1365231900.43559.YahooMailNeo@web162201.mail.bf1.yahoo.com>
	<CAO8bCgiS0rNU2CveT=jC9Pdh=ckQmMgc6iQ0ftE6===vMEGarg@mail.gmail.com>
	<CAGmFidbjYER6bArj3F=9ggjM6k5yRLPVT-bT3cC00O22L1zzdg@mail.gmail.com>
	<CAO8bCgjZxO14rbe=CWqwiOVrNSmXsPQ9Qb0Ri6gfbqo0uAPDng@mail.gmail.com>
	<CAGmFidbQc1G1s_4vwdAU_Hwc_2WjrUq+CNLJkV88F=4Q+qw2Ww@mail.gmail.com>
	<1365371372.62701.YahooMailNeo@web162201.mail.bf1.yahoo.com>
	<CAK5idxRs+csXAdgiAUoAjbH5XmVWTUoC11EX=eJXHQ12aKA7Jw@mail.gmail.com>
	<1365493666.20723.YahooMailNeo@web162204.mail.bf1.yahoo.com>
	<CAK5idxSk249vP-LGZ_Wgq-eYwPw1DuPkeW5u+XPV51VdzkaJcQ@mail.gmail.com>
	<1365620550.27979.YahooMailNeo@web162203.mail.bf1.yahoo.com>
Message-ID: <CAK5idxRHRmBzuePT+fVzq7katRDrt9OA-WYBdjnDPSc3NgyidA@mail.gmail.com>

windows 64 patches that I got, can someone have a look?


---------- Forwarded message ----------
From: Roger Flores <aidembb at yahoo.com>
Date: Wed, Apr 10, 2013 at 9:02 PM
Subject: Re: Windows 64 bit version
To: Maciej Fijalkowski <fijall at gmail.com>


OK, sorry this is going to be long.  The short version is I have
attached a diff for C files in rpython/translator/c handling long !=
ptr except for three files.




>It depends on the context. Essentially the approach is to run tests and figure out what's going on. Starting from rpython/translator/c

OK, looking around rpython/translator/c I see that there are C files.
Looking through there, I see cases where void * is being cast to
(long).  I started scoping out the extent of the change and realized
it was a finite set, not too huge.  So I decided to just make the
changes and send you diff so we can all just stop talking about it.
Then I realized that there were (unsigned long) cases.  And then
ulong.  And ULONG.  And ULLONG.  And so on.  Yes, I got sucked in.  In
the end I reviewed ALL cases involving "long", caseless.

The approach:
At first I quickly changed (long) to (long long).  Then I realized
that long long is 64 bits on 32 bit builds.  Either we need to 1)
conditionally compile each line of code based on the platform or 2)
use a type that we magically change once based on the platform.  Then
I noticed that ptrdiff_t is an existing type that is magically sized
correctly for all platforms.  So now (long) is (ptrdiff_t) with no
header changes.

The diff covers all C files.  It's not big.  I don't know the command
to run tests there so I didn't even check linux builds, let alone
win64, which I'm extremely reluctant to set up.  But what I changed
should be largely obvious.  In particular please review stack.c and
stacklet.c which used unsigned long and that might be an issue.

The three files I did not change are thread_pthread.c, dtoa.c and
obmalloc.c.  The changes are small but I didn't have high confidence.
obmalloc makes it's own ulong for some reason.


There are also python files.  I examined them for Long usage but
couldn't find a clear pattern.  Can you point out one example of what
needs changing?


>it would go in rpython/jit/backend/x86

I looked around but I'm going to need more direction.  I was
specifically looking for the linux and win32 portions to compare and
again, figure out the size of the change.  All I found though were
register descriptions and code to emit assembly instructions.



-Roger


________________________________
From: Maciej Fijalkowski <fijall at gmail.com>
To: Roger Flores <aidembb at yahoo.com>
Cc: Amaury Forgeot d'Arc <amauryfa at gmail.com>; matti picus
<matti.picus at gmail.com>; PyPy Developer Mailing List
<pypy-dev at python.org>
Sent: Tuesday, April 9, 2013 12:52 AM
Subject: Re: Windows 64 bit version

On Tue, Apr 9, 2013 at 9:47 AM, Roger Flores <aidembb at yahoo.com> wrote:
> Maciej Fijalkowski wrote:
>>It's just a bunch of work. There is nothing special or magic about it, but
>> so far noone volunteered to spend enough effort there.
>
> Got it. I'm just trying to understand what the work is because that list
> hasn't been captured anywhere yet.
>
>
>>Essentially, the main problem is that sizeof(long) != sizeof(intptr_t),
>> which is not a big problem per-se, it's just that this assumption has to be
>> removed from places in the RPython source code.
>
> OK. Could you find one or two of those places in the RPython source code so
> we can see?  And what is the fix?  Does long get changed to long long or
> another type or ?

It depends on the context. Essentially the approach is to run tests
and figure out what's going on. Starting from rpython/translator/c

>
>
>>Another one is the calling convention for the JIT, which is different than
>> on linux. Again, nothing special, just more work.
>
> Does "calling convention for the JIT" mean a function calling convention for
> 64 bit windows or something else?  Where is this in the code, or maybe,
> where is it for the Windows 32 code and where would the 64 bit version go?
> There's no magic for exceptions, gc, or anything else?

it would go in rpython/jit/backend/x86

>
>
> Thanks for the details,
> -Roger
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ptr_diff
Type: application/octet-stream
Size: 4748 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20130411/d77327ae/attachment.obj>

From amauryfa at gmail.com  Thu Apr 11 12:23:59 2013
From: amauryfa at gmail.com (Amaury Forgeot d'Arc)
Date: Thu, 11 Apr 2013 12:23:59 +0200
Subject: [pypy-dev] Fwd: Windows 64 bit version
In-Reply-To: <CAK5idxRHRmBzuePT+fVzq7katRDrt9OA-WYBdjnDPSc3NgyidA@mail.gmail.com>
References: <1365231900.43559.YahooMailNeo@web162201.mail.bf1.yahoo.com>
	<CAO8bCgiS0rNU2CveT=jC9Pdh=ckQmMgc6iQ0ftE6===vMEGarg@mail.gmail.com>
	<CAGmFidbjYER6bArj3F=9ggjM6k5yRLPVT-bT3cC00O22L1zzdg@mail.gmail.com>
	<CAO8bCgjZxO14rbe=CWqwiOVrNSmXsPQ9Qb0Ri6gfbqo0uAPDng@mail.gmail.com>
	<CAGmFidbQc1G1s_4vwdAU_Hwc_2WjrUq+CNLJkV88F=4Q+qw2Ww@mail.gmail.com>
	<1365371372.62701.YahooMailNeo@web162201.mail.bf1.yahoo.com>
	<CAK5idxRs+csXAdgiAUoAjbH5XmVWTUoC11EX=eJXHQ12aKA7Jw@mail.gmail.com>
	<1365493666.20723.YahooMailNeo@web162204.mail.bf1.yahoo.com>
	<CAK5idxSk249vP-LGZ_Wgq-eYwPw1DuPkeW5u+XPV51VdzkaJcQ@mail.gmail.com>
	<1365620550.27979.YahooMailNeo@web162203.mail.bf1.yahoo.com>
	<CAK5idxRHRmBzuePT+fVzq7katRDrt9OA-WYBdjnDPSc3NgyidA@mail.gmail.com>
Message-ID: <CAGmFidZsMwZyN1BbE__gXWkNmaZBJD+w45OFMR_VbGY=kKDZkQ@mail.gmail.com>

2013/4/11 Maciej Fijalkowski <fijall at gmail.com>

> windows 64 patches that I got, can someone have a look?


This patch won't have any effect

- linuxmemchk is not used on windows.
- the changes in obmalloc, stack.c, stacklet.c are not necessary,
differences between stack addresses won't overflow 32bit.
- in thread_nt.c, RPyThreadSetStackSize should take a long, or
maybe an unsigned (_beginthread takes an unsigned)
- in thread_nt.c, _beginthread returns uintptr_t, so maybe rv should be
changed to this type;



-- 
Amaury Forgeot d'Arc
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20130411/f61c7e95/attachment.html>

From max.lavrenov at gmail.com  Thu Apr 11 14:39:56 2013
From: max.lavrenov at gmail.com (Max Lavrenov)
Date: Thu, 11 Apr 2013 16:39:56 +0400
Subject: [pypy-dev] OSError: [Errno 12] Cannot allocate memory from 'import
 sqlite3' on linux
Message-ID: <CAAq2fm_njrJBTK9m2RrmJL=wYQQumx0r2_Jh=0ZbWoa-fWRBOA@mail.gmail.com>

Hello all,

I've built pypy from trunk today, but seems there is some problem with
sqlite3 module.


[e-max at e-max release]$ /home/e-max/workspace/pypy/pypy/goal/pypy-c
Python 2.7.3 (948f362bd750, Apr 11 2013, 10:44:18)
[PyPy 2.0.0-beta2 with GCC 4.8.0] on linux2
Type "help", "copyright", "credits" or "license" for more information.
And now for something completely different: ``pypy is more stable than
debian''
>>>> import sqlite3
Traceback (most recent call last):
  File "<console>", line 1, in <module>
  File "/home/e-max/workspace/pypy/lib-python/2.7/sqlite3/__init__.py",
line 24, in <module>
    from dbapi2 import *
  File "/home/e-max/workspace/pypy/lib-python/2.7/sqlite3/dbapi2.py", line
27, in <module>
    from _sqlite3 import *
  File "/home/e-max/workspace/pypy/lib_pypy/_sqlite3.py", line 268, in
<module>
    if _has_load_extension():
  File "/home/e-max/workspace/pypy/lib_pypy/_sqlite3.py", line 265, in
_has_load_extension
    unverified_lib = unverified_ffi.dlopen(libname)
  File "/home/e-max/workspace/pypy/lib_pypy/cffi/api.py", line 111, in
dlopen
    lib, function_cache = _make_ffi_library(self, name, flags)
  File "/home/e-max/workspace/pypy/lib_pypy/cffi/api.py", line 362, in
_make_ffi_library
    path = ctypes.util.find_library(name)
  File "/home/e-max/workspace/pypy/lib-python/2.7/ctypes/util.py", line
213, in find_library
    return _findSoname_ldconfig(name) or _get_soname(_findLib_gcc(name))
  File "/home/e-max/workspace/pypy/lib-python/2.7/ctypes/util.py", line
202, in _findSoname_ldconfig
    f = os.popen('/sbin/ldconfig -p 2>/dev/null')
OSError: [Errno 12] Cannot allocate memory

Is there any additional information which i can provide about this problem?

Thank,
Max
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20130411/c7fe4cfb/attachment.html>

From aidembb at yahoo.com  Thu Apr 11 18:49:30 2013
From: aidembb at yahoo.com (Roger Flores)
Date: Thu, 11 Apr 2013 09:49:30 -0700 (PDT)
Subject: [pypy-dev] Fwd: Windows 64 bit version
In-Reply-To: <CAGmFidZsMwZyN1BbE__gXWkNmaZBJD+w45OFMR_VbGY=kKDZkQ@mail.gmail.com>
References: <1365231900.43559.YahooMailNeo@web162201.mail.bf1.yahoo.com>
	<CAO8bCgiS0rNU2CveT=jC9Pdh=ckQmMgc6iQ0ftE6===vMEGarg@mail.gmail.com>
	<CAGmFidbjYER6bArj3F=9ggjM6k5yRLPVT-bT3cC00O22L1zzdg@mail.gmail.com>
	<CAO8bCgjZxO14rbe=CWqwiOVrNSmXsPQ9Qb0Ri6gfbqo0uAPDng@mail.gmail.com>
	<CAGmFidbQc1G1s_4vwdAU_Hwc_2WjrUq+CNLJkV88F=4Q+qw2Ww@mail.gmail.com>
	<1365371372.62701.YahooMailNeo@web162201.mail.bf1.yahoo.com>
	<CAK5idxRs+csXAdgiAUoAjbH5XmVWTUoC11EX=eJXHQ12aKA7Jw@mail.gmail.com>
	<1365493666.20723.YahooMailNeo@web162204.mail.bf1.yahoo.com>
	<CAK5idxSk249vP-LGZ_Wgq-eYwPw1DuPkeW5u+XPV51VdzkaJcQ@mail.gmail.com>
	<1365620550.27979.YahooMailNeo@web162203.mail.bf1.yahoo.com>
	<CAK5idxRHRmBzuePT+fVzq7katRDrt9OA-WYBdjnDPSc3NgyidA@mail.gmail.com>
	<CAGmFidZsMwZyN1BbE__gXWkNmaZBJD+w45OFMR_VbGY=kKDZkQ@mail.gmail.com>
Message-ID: <1365698970.94579.YahooMailNeo@web162202.mail.bf1.yahoo.com>

OK, I reworked (and attached) the patch for the suggestions to nt_threads.[ch].? You had no comments for dtoa.c.

This is great.? From inspection, there doesn't seem to be any other changes needed to the C code in rpython/translator/c for Windows 64 support.? I am assuming the 'gcc' folder there does not matter.


1. Are there any other directories where C code needs to be reviewed to support Windows 64?? 


2. That still leaves the rpython code in rpython/translator/c.? Can you show an example of where that needs fixing (regarding sizeof(long)) so I can use that as a pattern for the remaining code?

3. rpython/jit/backend/x86: it's still not clear what part needed work here


Thanks,
-Roger



________________________________
 From: Amaury Forgeot d'Arc <amauryfa at gmail.com>
To: Maciej Fijalkowski <fijall at gmail.com> 
Cc: PyPy Developer Mailing List <pypy-dev at python.org> 
Sent: Thursday, April 11, 2013 3:23 AM
Subject: Re: [pypy-dev] Fwd: Windows 64 bit version
 

2013/4/11 Maciej Fijalkowski?<fijall at gmail.com>

windows 64 patches that I got, can someone have a look?

This patch won't have any effect
?- linuxmemchk is not used on windows.
- the changes in obmalloc, stack.c, stacklet.c are not necessary, differences between stack addresses won't overflow 32bit.
- in thread_nt.c, RPyThreadSetStackSize should take a long, or maybe?an?unsigned (_beginthread takes an unsigned)

- in thread_nt.c, _beginthread returns?uintptr_t, so maybe rv should be changed to this type;



-- 
Amaury Forgeot d'Arc 
_______________________________________________
pypy-dev mailing list
pypy-dev at python.org
http://mail.python.org/mailman/listinfo/pypy-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20130411/6c5ec36d/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ptr_diff2
Type: application/octet-stream
Size: 1499 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20130411/6c5ec36d/attachment.obj>

From fijall at gmail.com  Thu Apr 11 18:58:46 2013
From: fijall at gmail.com (Maciej Fijalkowski)
Date: Thu, 11 Apr 2013 18:58:46 +0200
Subject: [pypy-dev] Fwd: Windows 64 bit version
In-Reply-To: <1365698970.94579.YahooMailNeo@web162202.mail.bf1.yahoo.com>
References: <1365231900.43559.YahooMailNeo@web162201.mail.bf1.yahoo.com>
	<CAO8bCgiS0rNU2CveT=jC9Pdh=ckQmMgc6iQ0ftE6===vMEGarg@mail.gmail.com>
	<CAGmFidbjYER6bArj3F=9ggjM6k5yRLPVT-bT3cC00O22L1zzdg@mail.gmail.com>
	<CAO8bCgjZxO14rbe=CWqwiOVrNSmXsPQ9Qb0Ri6gfbqo0uAPDng@mail.gmail.com>
	<CAGmFidbQc1G1s_4vwdAU_Hwc_2WjrUq+CNLJkV88F=4Q+qw2Ww@mail.gmail.com>
	<1365371372.62701.YahooMailNeo@web162201.mail.bf1.yahoo.com>
	<CAK5idxRs+csXAdgiAUoAjbH5XmVWTUoC11EX=eJXHQ12aKA7Jw@mail.gmail.com>
	<1365493666.20723.YahooMailNeo@web162204.mail.bf1.yahoo.com>
	<CAK5idxSk249vP-LGZ_Wgq-eYwPw1DuPkeW5u+XPV51VdzkaJcQ@mail.gmail.com>
	<1365620550.27979.YahooMailNeo@web162203.mail.bf1.yahoo.com>
	<CAK5idxRHRmBzuePT+fVzq7katRDrt9OA-WYBdjnDPSc3NgyidA@mail.gmail.com>
	<CAGmFidZsMwZyN1BbE__gXWkNmaZBJD+w45OFMR_VbGY=kKDZkQ@mail.gmail.com>
	<1365698970.94579.YahooMailNeo@web162202.mail.bf1.yahoo.com>
Message-ID: <CAK5idxRbpTRmXy6-69y7PwSqHAQJx09-vZqvoA4BHvCS91cnqA@mail.gmail.com>

On Thu, Apr 11, 2013 at 6:49 PM, Roger Flores <aidembb at yahoo.com> wrote:
> OK, I reworked (and attached) the patch for the suggestions to
> nt_threads.[ch].  You had no comments for dtoa.c.
>
> This is great.  From inspection, there doesn't seem to be any other changes
> needed to the C code in rpython/translator/c for Windows 64 support.  I am
> assuming the 'gcc' folder there does not matter.
>
> 1. Are there any other directories where C code needs to be reviewed to
> support Windows 64?
>
> 2. That still leaves the rpython code in rpython/translator/c.  Can you show
> an example of where that needs fixing (regarding sizeof(long)) so I can use
> that as a pattern for the remaining code?
>
> 3. rpython/jit/backend/x86: it's still not clear what part needed work here
>
>
> Thanks,
> -Roger

Hi Roger.

Seriously, while there might be any pattern there, I would *strongly*
suggest you start running tests and see what breaks.

Cheers,
fijal

From amauryfa at gmail.com  Thu Apr 11 19:58:35 2013
From: amauryfa at gmail.com (Amaury Forgeot d'Arc)
Date: Thu, 11 Apr 2013 19:58:35 +0200
Subject: [pypy-dev] Fwd: Windows 64 bit version
In-Reply-To: <1365698970.94579.YahooMailNeo@web162202.mail.bf1.yahoo.com>
References: <1365231900.43559.YahooMailNeo@web162201.mail.bf1.yahoo.com>
	<CAO8bCgiS0rNU2CveT=jC9Pdh=ckQmMgc6iQ0ftE6===vMEGarg@mail.gmail.com>
	<CAGmFidbjYER6bArj3F=9ggjM6k5yRLPVT-bT3cC00O22L1zzdg@mail.gmail.com>
	<CAO8bCgjZxO14rbe=CWqwiOVrNSmXsPQ9Qb0Ri6gfbqo0uAPDng@mail.gmail.com>
	<CAGmFidbQc1G1s_4vwdAU_Hwc_2WjrUq+CNLJkV88F=4Q+qw2Ww@mail.gmail.com>
	<1365371372.62701.YahooMailNeo@web162201.mail.bf1.yahoo.com>
	<CAK5idxRs+csXAdgiAUoAjbH5XmVWTUoC11EX=eJXHQ12aKA7Jw@mail.gmail.com>
	<1365493666.20723.YahooMailNeo@web162204.mail.bf1.yahoo.com>
	<CAK5idxSk249vP-LGZ_Wgq-eYwPw1DuPkeW5u+XPV51VdzkaJcQ@mail.gmail.com>
	<1365620550.27979.YahooMailNeo@web162203.mail.bf1.yahoo.com>
	<CAK5idxRHRmBzuePT+fVzq7katRDrt9OA-WYBdjnDPSc3NgyidA@mail.gmail.com>
	<CAGmFidZsMwZyN1BbE__gXWkNmaZBJD+w45OFMR_VbGY=kKDZkQ@mail.gmail.com>
	<1365698970.94579.YahooMailNeo@web162202.mail.bf1.yahoo.com>
Message-ID: <CAGmFidah4esZaMX=DKrUqKMjj_BJuu4o2ETA7zVreMxVNsN3ng@mail.gmail.com>

2013/4/11 Roger Flores <aidembb at yahoo.com>

> 1. Are there any other directories where C code needs to be reviewed to
> support Windows 64?


Well, not C only code. There are 140 occurrences of "cast_adr_to_int" in
RPython code...

-- 
Amaury Forgeot d'Arc
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20130411/e0afcdbb/attachment.html>

From matti.picus at gmail.com  Thu Apr 11 21:51:54 2013
From: matti.picus at gmail.com (Matti Picus)
Date: Thu, 11 Apr 2013 22:51:54 +0300
Subject: [pypy-dev] Fwd: Windows 64 bit version
In-Reply-To: <CAK5idxRbpTRmXy6-69y7PwSqHAQJx09-vZqvoA4BHvCS91cnqA@mail.gmail.com>
References: <1365231900.43559.YahooMailNeo@web162201.mail.bf1.yahoo.com>
	<CAO8bCgiS0rNU2CveT=jC9Pdh=ckQmMgc6iQ0ftE6===vMEGarg@mail.gmail.com>
	<CAGmFidbjYER6bArj3F=9ggjM6k5yRLPVT-bT3cC00O22L1zzdg@mail.gmail.com>
	<CAO8bCgjZxO14rbe=CWqwiOVrNSmXsPQ9Qb0Ri6gfbqo0uAPDng@mail.gmail.com>
	<CAGmFidbQc1G1s_4vwdAU_Hwc_2WjrUq+CNLJkV88F=4Q+qw2Ww@mail.gmail.com>
	<1365371372.62701.YahooMailNeo@web162201.mail.bf1.yahoo.com>
	<CAK5idxRs+csXAdgiAUoAjbH5XmVWTUoC11EX=eJXHQ12aKA7Jw@mail.gmail.com>
	<1365493666.20723.YahooMailNeo@web162204.mail.bf1.yahoo.com>
	<CAK5idxSk249vP-LGZ_Wgq-eYwPw1DuPkeW5u+XPV51VdzkaJcQ@mail.gmail.com>
	<1365620550.27979.YahooMailNeo@web162203.mail.bf1.yahoo.com>
	<CAK5idxRHRmBzuePT+fVzq7katRDrt9OA-WYBdjnDPSc3NgyidA@mail.gmail.com>
	<CAGmFidZsMwZyN1BbE__gXWkNmaZBJD+w45OFMR_VbGY=kKDZkQ@mail.gmail.com>
	<1365698970.94579.YahooMailNeo@web162202.mail.bf1.yahoo.com>
	<CAK5idxRbpTRmXy6-69y7PwSqHAQJx09-vZqvoA4BHvCS91cnqA@mail.gmail.com>
Message-ID: <5167145A.50100@gmail.com>

An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20130411/b622448f/attachment.html>

From arigo at tunes.org  Fri Apr 12 09:48:31 2013
From: arigo at tunes.org (Armin Rigo)
Date: Fri, 12 Apr 2013 09:48:31 +0200
Subject: [pypy-dev] OSError: [Errno 12] Cannot allocate memory from
 'import sqlite3' on linux
In-Reply-To: <CAAq2fm_njrJBTK9m2RrmJL=wYQQumx0r2_Jh=0ZbWoa-fWRBOA@mail.gmail.com>
References: <CAAq2fm_njrJBTK9m2RrmJL=wYQQumx0r2_Jh=0ZbWoa-fWRBOA@mail.gmail.com>
Message-ID: <CAMSv6X1rAHeTs=jLcgRngVN=307Wq83HGOH1ciPjSaJxVdi9SQ@mail.gmail.com>

Hi Max,

On Thu, Apr 11, 2013 at 2:39 PM, Max Lavrenov <max.lavrenov at gmail.com> wrote:
>   File "/home/e-max/workspace/pypy/lib_pypy/_sqlite3.py", line 265, in
> _has_load_extension
>     unverified_lib = unverified_ffi.dlopen(libname)
>   (...)
>     f = os.popen('/sbin/ldconfig -p 2>/dev/null')
> OSError: [Errno 12] Cannot allocate memory

Ah, mess.  It crashes obscurely in ctypes.util when doing the dlopen()
call from cffi.  I don't know why, but also I don't fully care :-/
Can you try to simply not use ctypes.util, by doing this change: in
lib_pypy/_sqlite3.py line 265, replace

    unverified_lib = unverified_ffi.dlopen(libname)

with

    unverified_lib = unverified_ffi.dlopen("/usr/lib/libsqlite3.so")

?  Assuming "/usr/lib/libsqlite3.so" is the path on your system.


Thanks for the report,

Armin.

From arigo at tunes.org  Fri Apr 12 10:01:01 2013
From: arigo at tunes.org (Armin Rigo)
Date: Fri, 12 Apr 2013 10:01:01 +0200
Subject: [pypy-dev] [pypy-commit] pypy default: make looking up
 encodings free with the JIT
In-Reply-To: <5165804E.2010103@gmail.com>
References: <20130410025328.9B3601C30E8@cobra.cs.uni-duesseldorf.de>
	<5165340B.7040807@gmail.com>
	<9e66fc22-1ee3-496b-a80d-d8ca598e3b3e@email.android.com>
	<CAFRnB2W3Gb4C7tvYntpRD7dAEN8ULup_zEtm94HUFkMZcyT8+w@mail.gmail.com>
	<5165804E.2010103@gmail.com>
Message-ID: <CAMSv6X0T1oVnyLYpkhFSNqy9uYHKRhgfFnBe+BkBgbvDKQ3Yug@mail.gmail.com>

Hi all,

Another way to write the test_pypy_c: you add the test with the input,
and write some rough approximation of the output you expect --- maybe
with comments explaining what you roughly expect.  Then you check this
in together with the changes in the jit.  It will fail in the next
(nightly or manual) build, but then you should know what you really
got.  You can then check and fix the test.  I think it's a situation
where it's ok to check in a test that we know is failing, and we're
going to fix it soon.  This works assuming there are enough
information on the buildbot page; if not, well, improve the
test_pypy_c/model.py file too :-)


A bient?t,

Armin.

From arigo at tunes.org  Fri Apr 12 10:12:38 2013
From: arigo at tunes.org (Armin Rigo)
Date: Fri, 12 Apr 2013 10:12:38 +0200
Subject: [pypy-dev]
	=?iso-8859-1?q?Redis_=ABclone=BB_using_pypy_stm-thread?=
	=?iso-8859-1?q?-2_=28Was=3A_Redis_clone=29?=
In-Reply-To: <CAL7_Mo--Vt0LNRd24DkcKrdFzPeVnkeQPAny4YWywGd9dpnuWw@mail.gmail.com>
References: <CAL7_Mo--Vt0LNRd24DkcKrdFzPeVnkeQPAny4YWywGd9dpnuWw@mail.gmail.com>
Message-ID: <CAMSv6X0pBr7WZH2JKc47gRv7+9h9-=Ukwfq7+Rn0DzQHKQAAWg@mail.gmail.com>

Hi Amirouche,

On Wed, Apr 10, 2013 at 5:03 PM, Amirouche Boubekki
<amirouche.boubekki at gmail.com> wrote:
>> I'm working on porting a redis clone to pypy-stm [1].

Great, thanks for the effort!

Looking at the source code, what you're doing is adding thread support
to the Python version of a Redis-like clone.  You do this based on
"with atomic" instead of acquiring and releasing some locks.  Am I
correct?


A bient?t,

Armin.

From cfbolz at gmx.de  Fri Apr 12 10:20:01 2013
From: cfbolz at gmx.de (Carl Friedrich Bolz)
Date: Fri, 12 Apr 2013 10:20:01 +0200
Subject: [pypy-dev] [pypy-commit] pypy default: make looking up
 encodings free with the JIT
In-Reply-To: <CAMSv6X0T1oVnyLYpkhFSNqy9uYHKRhgfFnBe+BkBgbvDKQ3Yug@mail.gmail.com>
References: <20130410025328.9B3601C30E8@cobra.cs.uni-duesseldorf.de>
	<5165340B.7040807@gmail.com>
	<9e66fc22-1ee3-496b-a80d-d8ca598e3b3e@email.android.com>
	<CAFRnB2W3Gb4C7tvYntpRD7dAEN8ULup_zEtm94HUFkMZcyT8+w@mail.gmail.com>
	<5165804E.2010103@gmail.com>
	<CAMSv6X0T1oVnyLYpkhFSNqy9uYHKRhgfFnBe+BkBgbvDKQ3Yug@mail.gmail.com>
Message-ID: <5167C3B1.7030708@gmx.de>

On 04/12/2013 10:01 AM, Armin Rigo wrote:
> Hi all,
>
> Another way to write the test_pypy_c: you add the test with the input,
> and write some rough approximation of the output you expect --- maybe
> with comments explaining what you roughly expect.  Then you check this
> in together with the changes in the jit.  It will fail in the next
> (nightly or manual) build, but then you should know what you really
> got.  You can then check and fix the test.  I think it's a situation
> where it's ok to check in a test that we know is failing, and we're
> going to fix it soon.  This works assuming there are enough
> information on the buildbot page; if not, well, improve the
> test_pypy_c/model.py file too :-)

I like this approach, because at least then the commit mail shows that
the person doing the change has thought about testing, and things don't
get lost.

Cheers,

Carl Friedrich

From arigo at tunes.org  Fri Apr 12 10:23:44 2013
From: arigo at tunes.org (Armin Rigo)
Date: Fri, 12 Apr 2013 10:23:44 +0200
Subject: [pypy-dev]
	=?iso-8859-1?q?Redis_=ABclone=BB_using_pypy_stm-thread?=
	=?iso-8859-1?q?-2_=28Was=3A_Redis_clone=29?=
In-Reply-To: <CAMSv6X0pBr7WZH2JKc47gRv7+9h9-=Ukwfq7+Rn0DzQHKQAAWg@mail.gmail.com>
References: <CAL7_Mo--Vt0LNRd24DkcKrdFzPeVnkeQPAny4YWywGd9dpnuWw@mail.gmail.com>
	<CAMSv6X0pBr7WZH2JKc47gRv7+9h9-=Ukwfq7+Rn0DzQHKQAAWg@mail.gmail.com>
Message-ID: <CAMSv6X1X1bqN-pUo=f4JWRUN1ToAaKWXjO3nD7EyoQU5Pp_UnQ@mail.gmail.com>

Re-hi,

I'm asking because I can think of another rather different approach,
which would be more in-line with pypy-stm's ultimate goals.  Your
module is defining a database-like structure that works like an
in-memory key-value store -- some kind of generalized dictionary.  So
the "hard" question, from the point of view of STM, is what occurs if
user code runs transactions that each want to access or modify
different keys.

In other words, what if there are multiple threads that all run in a
"with atomic" statement, and that try to change different keys of the
same database?  What we would like to occur is that the multiple
threads all succeed; what is likely to occur instead is that most of
them will conflict and rollback.  But it's probably possible to
redesign the internals of the database to avoid this, at least most of
the time.

How to do this exactly is not clear, and depends on the context.
Also, we could argue that it would be great if regular python
dictionaries had this property too: writing or accessing different
keys should not cause a transaction to rollback (which comes with a
few hard questions like what to do with __eq__/__hash__).


A bient?t,

Armin.

From arigo at tunes.org  Fri Apr 12 10:43:58 2013
From: arigo at tunes.org (Armin Rigo)
Date: Fri, 12 Apr 2013 10:43:58 +0200
Subject: [pypy-dev]
	=?iso-8859-1?q?Redis_=ABclone=BB_using_pypy_stm-thread?=
	=?iso-8859-1?q?-2_=28Was=3A_Redis_clone=29?=
In-Reply-To: <CAMSv6X1X1bqN-pUo=f4JWRUN1ToAaKWXjO3nD7EyoQU5Pp_UnQ@mail.gmail.com>
References: <CAL7_Mo--Vt0LNRd24DkcKrdFzPeVnkeQPAny4YWywGd9dpnuWw@mail.gmail.com>
	<CAMSv6X0pBr7WZH2JKc47gRv7+9h9-=Ukwfq7+Rn0DzQHKQAAWg@mail.gmail.com>
	<CAMSv6X1X1bqN-pUo=f4JWRUN1ToAaKWXjO3nD7EyoQU5Pp_UnQ@mail.gmail.com>
Message-ID: <CAMSv6X0UN7HX77MHBQzxGajdYxmFtcA5wSNCW7Fb5uigT2w8=A@mail.gmail.com>

Re,

...and of course there is the fundamental question: what is the link
between STM transactions and database transactions?  How do we write
programs that use large-scale "with atomic" statements and that want
to access an ACID database subsystem?  Do you or anyone know of a
paper that explores this?


A bient?t,

Armin.

From arigo at tunes.org  Fri Apr 12 10:47:45 2013
From: arigo at tunes.org (Armin Rigo)
Date: Fri, 12 Apr 2013 10:47:45 +0200
Subject: [pypy-dev] OSError: [Errno 12] Cannot allocate memory from
 'import sqlite3' on linux
In-Reply-To: <CAMSv6X1rAHeTs=jLcgRngVN=307Wq83HGOH1ciPjSaJxVdi9SQ@mail.gmail.com>
References: <CAAq2fm_njrJBTK9m2RrmJL=wYQQumx0r2_Jh=0ZbWoa-fWRBOA@mail.gmail.com>
	<CAMSv6X1rAHeTs=jLcgRngVN=307Wq83HGOH1ciPjSaJxVdi9SQ@mail.gmail.com>
Message-ID: <CAMSv6X180Zs2sRwHqGoZNyGKHgRjDjUTiU+HwaUeTjgsOqETQg@mail.gmail.com>

Re-hi,

On Fri, Apr 12, 2013 at 9:48 AM, Armin Rigo <arigo at tunes.org> wrote:
>>     f = os.popen('/sbin/ldconfig -p 2>/dev/null')
>> OSError: [Errno 12] Cannot allocate memory

This said it would also be useful to understand this error -- why does
os.popen() complain?  Can you try to run a different script that does
only "os.popen('ls')"?  Can you try to reproduce the error in any
simple way?


A bient?t,

Armin.

From max.lavrenov at gmail.com  Fri Apr 12 11:54:10 2013
From: max.lavrenov at gmail.com (Max Lavrenov)
Date: Fri, 12 Apr 2013 13:54:10 +0400
Subject: [pypy-dev] OSError: [Errno 12] Cannot allocate memory from
 'import sqlite3' on linux
In-Reply-To: <CAMSv6X180Zs2sRwHqGoZNyGKHgRjDjUTiU+HwaUeTjgsOqETQg@mail.gmail.com>
References: <CAAq2fm_njrJBTK9m2RrmJL=wYQQumx0r2_Jh=0ZbWoa-fWRBOA@mail.gmail.com>
	<CAMSv6X1rAHeTs=jLcgRngVN=307Wq83HGOH1ciPjSaJxVdi9SQ@mail.gmail.com>
	<CAMSv6X180Zs2sRwHqGoZNyGKHgRjDjUTiU+HwaUeTjgsOqETQg@mail.gmail.com>
Message-ID: <CAAq2fm8sxTjr3SgKzxM4jqu9x7V1q3Q1N1JrLDV4ppJJgwG0xw@mail.gmail.com>

Hi Armin

No, i can't reproduce the error in simple way.  Even
ctypes.util.find_library('sqlite3.so') works fine.
Actually it is very strange.

I can reproduce this error this way
>>>> from cffi.api import FFI
>>>> ffi = FFI()
>>>> ffi.dlopen('sqlite3.so')
Traceback (most recent call last):
  File "<console>", line 1, in <module>
  File "/home/e-max/workspace/pypy/lib_pypy/cffi/api.py", line 111, in
dlopen
    lib, function_cache = _make_ffi_library(self, name, flags)



But method dlopen in class FFI looks like

    def dlopen(self, name, flags=0):
        assert isinstance(name, basestring) or name is None
        lib, function_cache = _make_ffi_library(self, name, flags)
        ....

and traceback show that error throws at line   lib, function_cache =
_make_ffi_library(self, name, flags)

Strange thing is that if i do something like

>>>> from cffi.api import FFI, _make_ffi_library
>>>> ffi = FFI()
>>>> _make_ffi_library(ffi, 'sqlite3.so', 0)
(<cffi.api.FFILibrary_sqlite3.so object at 0x0000000004892950>, {})

it just works.




On Fri, Apr 12, 2013 at 12:47 PM, Armin Rigo <arigo at tunes.org> wrote:

> Re-hi,
>
> On Fri, Apr 12, 2013 at 9:48 AM, Armin Rigo <arigo at tunes.org> wrote:
> >>     f = os.popen('/sbin/ldconfig -p 2>/dev/null')
> >> OSError: [Errno 12] Cannot allocate memory
>
> This said it would also be useful to understand this error -- why does
> os.popen() complain?  Can you try to run a different script that does
> only "os.popen('ls')"?  Can you try to reproduce the error in any
> simple way?
>
>
> A bient?t,
>
> Armin.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20130412/e2b49a05/attachment.html>

From amirouche.boubekki at gmail.com  Fri Apr 12 13:42:04 2013
From: amirouche.boubekki at gmail.com (Amirouche Boubekki)
Date: Fri, 12 Apr 2013 13:42:04 +0200
Subject: [pypy-dev]
	=?utf-8?q?Redis_=C2=ABclone=C2=BB_using_pypy_stm-threa?=
	=?utf-8?q?d-2_=28Was=3A_Redis_clone=29?=
In-Reply-To: <CAMSv6X0pBr7WZH2JKc47gRv7+9h9-=Ukwfq7+Rn0DzQHKQAAWg@mail.gmail.com>
References: <CAL7_Mo--Vt0LNRd24DkcKrdFzPeVnkeQPAny4YWywGd9dpnuWw@mail.gmail.com>
	<CAMSv6X0pBr7WZH2JKc47gRv7+9h9-=Ukwfq7+Rn0DzQHKQAAWg@mail.gmail.com>
Message-ID: <CAL7_Mo9NLtHSeF9_yo8uC24_mYSjDqp+9fu_kOE1_cZd9jTTFQ@mail.gmail.com>

Hi ARmin

2013/4/12 Armin Rigo <arigo at tunes.org>

> Hi Amirouche,
>
> On Wed, Apr 10, 2013 at 5:03 PM, Amirouche Boubekki
> <amirouche.boubekki at gmail.com> wrote:
> >> I'm working on porting a redis clone to pypy-stm [1].
>
> Great, thanks for the effort!
>
> Looking at the source code, what you're doing is adding thread support
> to the Python version of a Redis-like clone.  You do this based on
> "with atomic" instead of acquiring and releasing some locks.  Am I
> correct?
>

Yes. Plus the fact that with pypy-stm threads are taking advantage of
several cores/CPU.

That said, old version of Memo is monothread because I was thinking that
there is no use of being multithread if the processing can't happen in
parallel because of the GIL. Redis is monothread and use an eventloop
which, I think, only improves the number of connection it can accept and
also probably help implement publish/subscribe. There is no
publish/subscribe in Memo yet.


>
> A bient?t,
>
> Armin.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20130412/2a4f06f1/attachment.html>

From aidembb at yahoo.com  Fri Apr 12 19:59:23 2013
From: aidembb at yahoo.com (Roger Flores)
Date: Fri, 12 Apr 2013 10:59:23 -0700 (PDT)
Subject: [pypy-dev] Fwd: Windows 64 bit version
In-Reply-To: <CAGmFidah4esZaMX=DKrUqKMjj_BJuu4o2ETA7zVreMxVNsN3ng@mail.gmail.com>
References: <1365231900.43559.YahooMailNeo@web162201.mail.bf1.yahoo.com>
	<CAO8bCgiS0rNU2CveT=jC9Pdh=ckQmMgc6iQ0ftE6===vMEGarg@mail.gmail.com>
	<CAGmFidbjYER6bArj3F=9ggjM6k5yRLPVT-bT3cC00O22L1zzdg@mail.gmail.com>
	<CAO8bCgjZxO14rbe=CWqwiOVrNSmXsPQ9Qb0Ri6gfbqo0uAPDng@mail.gmail.com>
	<CAGmFidbQc1G1s_4vwdAU_Hwc_2WjrUq+CNLJkV88F=4Q+qw2Ww@mail.gmail.com>
	<1365371372.62701.YahooMailNeo@web162201.mail.bf1.yahoo.com>
	<CAK5idxRs+csXAdgiAUoAjbH5XmVWTUoC11EX=eJXHQ12aKA7Jw@mail.gmail.com>
	<1365493666.20723.YahooMailNeo@web162204.mail.bf1.yahoo.com>
	<CAK5idxSk249vP-LGZ_Wgq-eYwPw1DuPkeW5u+XPV51VdzkaJcQ@mail.gmail.com>
	<1365620550.27979.YahooMailNeo@web162203.mail.bf1.yahoo.com>
	<CAK5idxRHRmBzuePT+fVzq7katRDrt9OA-WYBdjnDPSc3NgyidA@mail.gmail.com>
	<CAGmFidZsMwZyN1BbE__gXWkNmaZBJD+w45OFMR_VbGY=kKDZkQ@mail.gmail.com>
	<1365698970.94579.YahooMailNeo@web162202.mail.bf1.yahoo.com>
	<CAGmFidah4esZaMX=DKrUqKMjj_BJuu4o2ETA7zVreMxVNsN3ng@mail.gmail.com>
Message-ID: <1365789563.7846.YahooMailNeo@web162201.mail.bf1.yahoo.com>

Amaury wrote:
>Well, not C only code. There are 140 occurrences of "cast_adr_to_int" in RPython code...

OK, this is really helpful.? It's exactly the kind of info I was hoping to hear when starting this thread, and what I was looking for on the web site before that.

I the spirit of getting all this info accessible on the web site, I'm going to try and summarize it.? I originally went looking for this at http://doc.pypy.org/en/latest/windows.html so maybe you can add this there.? I also suggest, since you want Windows volunteers, you add a greyed out win 64 entry to http://pypy.org/download.html#default-with-a-jit-compiler like you did for the Linux ARM version, but add a link titled "Needs your help" to this info as well.? The curious will click.

This took more emails than I expected to figure this out, so thanks to everyone who spent the time and provided the needed details.


-Roger


Windows 64

The Windows 64 build is not working because of a couple of issues.

1. The size of long is different on Linux versus Windows, and that affects code that moves eight byte pointers to longs or back (see http://en.wikipedia.org/wiki/64_bit#64-bit_data_models).? Most of the C code has been reviewed and fixed by replacing the affected longs with ptrdiff_t.? 

The RPython code has the same issue.? If you search *py files for cast_adr_to_int and cast_ptr_to_int, and their inverses cast_int_to_add, cast_int_to_ptr, there are over a hundred cases, although half are in test code.? There are even more cast_int* matches, some of which might need changing.? You'll need to run the tests, make some changes, and then run the tests again to verify the change .? You'll want to start with rpython before doing pypy.

2. rpython/jit/backend/x86: this jit code might need some adjustment to how win64 handles frames.


Running tests will be something like "~/pypy$ py.test rpython" (http://doc.pypy.org/en/latest/getting-started-dev.html#running-pypy-s-unit-tests).

So it's download, get the dependencies (including pytest), translate (build), test, and then you're on your way.



If you'd like something simpler to get started, have a look at http://buildbot.pypy.org/summary?builder=own-win-x86-32.? Fixing these helps both the win32 and the win64 builds!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20130412/eb9670d5/attachment.html>

From amirouche.boubekki at gmail.com  Sat Apr 13 08:10:17 2013
From: amirouche.boubekki at gmail.com (Amirouche Boubekki)
Date: Sat, 13 Apr 2013 08:10:17 +0200
Subject: [pypy-dev]
	=?utf-8?q?Redis_=C2=ABclone=C2=BB_using_pypy_stm-threa?=
	=?utf-8?q?d-2_=28Was=3A_Redis_clone=29?=
In-Reply-To: <CAMSv6X1X1bqN-pUo=f4JWRUN1ToAaKWXjO3nD7EyoQU5Pp_UnQ@mail.gmail.com>
References: <CAL7_Mo--Vt0LNRd24DkcKrdFzPeVnkeQPAny4YWywGd9dpnuWw@mail.gmail.com>
	<CAMSv6X0pBr7WZH2JKc47gRv7+9h9-=Ukwfq7+Rn0DzQHKQAAWg@mail.gmail.com>
	<CAMSv6X1X1bqN-pUo=f4JWRUN1ToAaKWXjO3nD7EyoQU5Pp_UnQ@mail.gmail.com>
Message-ID: <CAL7_Mo-cT4mg8iZ0TAtbPJLydo64GwJNcN5og=vgD47XB4fSkA@mail.gmail.com>

If I understand correctly a ?with atomic? is a STM transaction, I call it
ST for short in what follows and DBT for database transaction.

So far my understanding is: two concurrent transaction like:

with atomic:
    v1 = self.dict['k1']

Always succeed aka. don't neet to rollback to commit again.

The following concurrent always succeed:

with atomic:
    v1 = self.dict['k1']

with atomic:
    v2 = self.dict['k2']

The following concurrent always succeed:

with atomic:
    self.dict['k1'] = v1

with atomic:
    self.dict['k2'] = v2

The following read and another write succeed:

with atomic:
    v1 =self.dict['k]

with atomic:
    self.dict['k'] = v2

And that this succeed only if there isn't a parallele write on the same key:

with atomic:
    self.dict['k1'] = self.dict['k1'] + 1



I'm asking because I can think of another rather different approach,
> which would be more in-line with pypy-stm's ultimate goals.  Your
> module is defining a database-like structure that works like an
> in-memory key-value store -- some kind of generalized dictionary.  So
> the "hard" question, from the point of view of STM, is what occurs if
> user code runs transactions that each want to access or modify
> different keys.
>
> In other words, what if there are multiple threads that all run in a
> "with atomic" statement, and that try to change different keys of the
> same database?  What we would like to occur is that the multiple
> threads all succeed; what is likely to occur instead is that most of
> them will conflict and rollback.


Well, this is a bit confusing I'm not sure I understand how it works.

The API of ?suggest? works like this:

- SUGGESTADD(key, value): possibly create ?key? and add ?value? as valid
word, this is *at least* two ST one for adding the key, and several for
adding the trigrams say you have the word ALAMBRA it will do one ST for
each trigrams ALA, LAM, AMB etc... plus the initial key creation which is
another ST
- SEARCH(key, value): suggest a list of words for ?value? this is only one
read hence one ?with atomic? hence one ST to read

Regarding ST vs DBT: In the case of Memo DBT are STs (or are though to be).

 But it's probably possible to
> redesign the internals of the database to avoid this, at least most of
> the time.
>

I'm not sure how.


> How to do this exactly is not clear, and depends on the context.
> Also, we could argue that it would be great if regular python
> dictionaries had this property too: writing or accessing different
> keys should not cause a transaction to rollback (which comes with a
> few hard questions like what to do with __eq__/__hash__).
>

I'm not sure either how this can be embedded in a dict class because
sometimes one needs to use
?with atomic? as a DBT for instance if you move a value between two keys.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20130413/5adea7e0/attachment-0001.html>

From amirouche.boubekki at gmail.com  Sat Apr 13 08:37:48 2013
From: amirouche.boubekki at gmail.com (Amirouche Boubekki)
Date: Sat, 13 Apr 2013 08:37:48 +0200
Subject: [pypy-dev]
	=?utf-8?q?Redis_=C2=ABclone=C2=BB_using_pypy_stm-threa?=
	=?utf-8?q?d-2_=28Was=3A_Redis_clone=29?=
In-Reply-To: <CAMSv6X0UN7HX77MHBQzxGajdYxmFtcA5wSNCW7Fb5uigT2w8=A@mail.gmail.com>
References: <CAL7_Mo--Vt0LNRd24DkcKrdFzPeVnkeQPAny4YWywGd9dpnuWw@mail.gmail.com>
	<CAMSv6X0pBr7WZH2JKc47gRv7+9h9-=Ukwfq7+Rn0DzQHKQAAWg@mail.gmail.com>
	<CAMSv6X1X1bqN-pUo=f4JWRUN1ToAaKWXjO3nD7EyoQU5Pp_UnQ@mail.gmail.com>
	<CAMSv6X0UN7HX77MHBQzxGajdYxmFtcA5wSNCW7Fb5uigT2w8=A@mail.gmail.com>
Message-ID: <CAL7_Mo-_TSmf0tbsn23HeRxDhkSXjwyzY6uqnVM5SS9e6SJtqg@mail.gmail.com>

2013/4/12 Armin Rigo <arigo at tunes.org>

> Re,
>
> ...and of course there is the fundamental question: what is the link
> between STM transactions and database transactions?  How do we write
> programs that use large-scale "with atomic" statements and that want
> to access an ACID database subsystem?


In the case of graphitidb, it's a MVCC which aims to avoid locks hence
?with atomic?. A DBT is considered commited if it can be read by other
transaction (aka. can read the modifications done by the transaction) and
this is possible when its transaction id is put in the in memory
transaction store. So you need a ?with atomic? to update the transaction
store and you need ?with atomic?s to update the MVCC graph hence the DBT is
not directly related to ?with atomic? transactions and of course DBT can
fail even whatever the actual behavior of ?with atomic?s.

Regarding the usecase you present a ?with atomic? that does modification of
an ACID database, the ?atomic? rollback of ?with atomic? must be overriden
to rollback the database and must commit the ACID database when the ?with
atomic? suceeeds. Also what happens if the DBT fails ? the ST should also
be rolledback and be tried again. I think this is a usecase for two phase
commit aka. 2PC [1] used in distributed DB settings.


> Do you or anyone know of a paper that explores this?
>

No. Except I think it's a usecase for 2PC, I'm not sure how this related to
python transaction module.

HTH,

Amirouche

[1] https://en.wikipedia.org/wiki/Two-phase_commit_protocol
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20130413/9e2c984b/attachment.html>

From fijall at gmail.com  Sat Apr 13 19:24:40 2013
From: fijall at gmail.com (Maciej Fijalkowski)
Date: Sat, 13 Apr 2013 19:24:40 +0200
Subject: [pypy-dev] [pypy-commit] pypy default: preallocate list to hold
 the locations of arguments to a call
In-Reply-To: <20130413161312.327CA1C0250@cobra.cs.uni-duesseldorf.de>
References: <20130413161312.327CA1C0250@cobra.cs.uni-duesseldorf.de>
Message-ID: <CAK5idxRq6E4HaPoGgcYb_ereG5CqeHnVpDv2zBxMH7=rsAsjBQ@mail.gmail.com>

There is an optimization that does it for you FYI (or just use newlist_hint)

On Sat, Apr 13, 2013 at 6:13 PM, bivab <noreply at buildbot.pypy.org> wrote:
> Author: David Schneider <david.schneider at picle.org>
> Branch:
> Changeset: r63312:1bd588482153
> Date: 2013-04-13 18:00 +0200
> http://bitbucket.org/pypy/pypy/changeset/1bd588482153/
>
> Log:    preallocate list to hold the locations of arguments to a call
>
> diff --git a/rpython/jit/backend/arm/regalloc.py b/rpython/jit/backend/arm/regalloc.py
> --- a/rpython/jit/backend/arm/regalloc.py
> +++ b/rpython/jit/backend/arm/regalloc.py
> @@ -554,10 +554,9 @@
>          return self._prepare_call(op)
>
>      def _prepare_call(self, op, force_store=[], save_all_regs=False):
> -        args = []
> -        args.append(None)
> +        args = [None] * (op.numargs()+1)
>          for i in range(op.numargs()):
> -            args.append(self.loc(op.getarg(i)))
> +           args[i+1] = self.loc(op.getarg(i))
>          # spill variables that need to be saved around calls
>          self.vfprm.before_call(save_all_regs=save_all_regs)
>          if not save_all_regs:
> _______________________________________________
> pypy-commit mailing list
> pypy-commit at python.org
> http://mail.python.org/mailman/listinfo/pypy-commit

From arigo at tunes.org  Sat Apr 13 23:13:05 2013
From: arigo at tunes.org (Armin Rigo)
Date: Sat, 13 Apr 2013 23:13:05 +0200
Subject: [pypy-dev] [pypy-commit] pypy default: preallocate list to hold
 the locations of arguments to a call
In-Reply-To: <CAK5idxRq6E4HaPoGgcYb_ereG5CqeHnVpDv2zBxMH7=rsAsjBQ@mail.gmail.com>
References: <20130413161312.327CA1C0250@cobra.cs.uni-duesseldorf.de>
	<CAK5idxRq6E4HaPoGgcYb_ereG5CqeHnVpDv2zBxMH7=rsAsjBQ@mail.gmail.com>
Message-ID: <CAMSv6X2HcGPV0cX1MuE3=6kAkOdRK7feMFCb7Qsx+vUxbcAzCA@mail.gmail.com>

Hi Fijal,

On Sat, Apr 13, 2013 at 7:24 PM, Maciej Fijalkowski <fijall at gmail.com> wrote:
> There is an optimization that does it for you FYI (or just use newlist_hint)

I doubt it works in this case: there is a None appended before the
loop.  As for newlist_hint, it doesn't have the whole effect: here we
want to get a non-resizable RPython list.


A bient?t,

Armin.

From slayer-gurgen at yandex.ru  Sun Apr 14 08:13:57 2013
From: slayer-gurgen at yandex.ru (Evgeny Startsev)
Date: Sun, 14 Apr 2013 12:13:57 +0600
Subject: [pypy-dev] Control flow graph for method
Message-ID: <516A4925.4090801@yandex.ru>

I am interesting in control-flow graph generation for python projects 
using python. I read 
http://doc.pypy.org/en/latest/translation.html#flow-model and studied 
how to investigate cfg for function.
Is there any way to generate cfg for method using pypy?

From arigo at tunes.org  Sun Apr 14 09:28:26 2013
From: arigo at tunes.org (Armin Rigo)
Date: Sun, 14 Apr 2013 09:28:26 +0200
Subject: [pypy-dev] Control flow graph for method
In-Reply-To: <516A4925.4090801@yandex.ru>
References: <516A4925.4090801@yandex.ru>
Message-ID: <CAMSv6X3utQ4dfFZ_A=bvgmCKm+S4jNt_owUdja_9u8rEykXdXQ@mail.gmail.com>

Hi,

On Sun, Apr 14, 2013 at 8:13 AM, Evgeny Startsev
<slayer-gurgen at yandex.ru> wrote:
> I am interesting in control-flow graph generation for python projects using
> python. I read http://doc.pypy.org/en/latest/translation.html#flow-model and
> studied how to investigate cfg for function.
> Is there any way to generate cfg for method using pypy?

In rpython/bin/translatorshell.py, instead of calling
Translation(func, [int]) you call Translation(Class.method.im_func,
[Class, int]).

This comes with the usual warnings: PyPy doesn't contain any tool that
gives you the cfg of a Python function or method, but only contains
tools that give the cfg of *RPython* function or methods.


A bient?t,

Armin.

From arigo at tunes.org  Sun Apr 14 09:46:41 2013
From: arigo at tunes.org (Armin Rigo)
Date: Sun, 14 Apr 2013 09:46:41 +0200
Subject: [pypy-dev] Fwd: Windows 64 bit version
In-Reply-To: <1365789563.7846.YahooMailNeo@web162201.mail.bf1.yahoo.com>
References: <1365231900.43559.YahooMailNeo@web162201.mail.bf1.yahoo.com>
	<CAO8bCgiS0rNU2CveT=jC9Pdh=ckQmMgc6iQ0ftE6===vMEGarg@mail.gmail.com>
	<CAGmFidbjYER6bArj3F=9ggjM6k5yRLPVT-bT3cC00O22L1zzdg@mail.gmail.com>
	<CAO8bCgjZxO14rbe=CWqwiOVrNSmXsPQ9Qb0Ri6gfbqo0uAPDng@mail.gmail.com>
	<CAGmFidbQc1G1s_4vwdAU_Hwc_2WjrUq+CNLJkV88F=4Q+qw2Ww@mail.gmail.com>
	<1365371372.62701.YahooMailNeo@web162201.mail.bf1.yahoo.com>
	<CAK5idxRs+csXAdgiAUoAjbH5XmVWTUoC11EX=eJXHQ12aKA7Jw@mail.gmail.com>
	<1365493666.20723.YahooMailNeo@web162204.mail.bf1.yahoo.com>
	<CAK5idxSk249vP-LGZ_Wgq-eYwPw1DuPkeW5u+XPV51VdzkaJcQ@mail.gmail.com>
	<1365620550.27979.YahooMailNeo@web162203.mail.bf1.yahoo.com>
	<CAK5idxRHRmBzuePT+fVzq7katRDrt9OA-WYBdjnDPSc3NgyidA@mail.gmail.com>
	<CAGmFidZsMwZyN1BbE__gXWkNmaZBJD+w45OFMR_VbGY=kKDZkQ@mail.gmail.com>
	<1365698970.94579.YahooMailNeo@web162202.mail.bf1.yahoo.com>
	<CAGmFidah4esZaMX=DKrUqKMjj_BJuu4o2ETA7zVreMxVNsN3ng@mail.gmail.com>
	<1365789563.7846.YahooMailNeo@web162201.mail.bf1.yahoo.com>
Message-ID: <CAMSv6X3+=aKTRN6oN5CViWbwdoDgLOeS8_4exxYxbtQC+3O7Ug@mail.gmail.com>

Hi Roger,

On Fri, Apr 12, 2013 at 7:59 PM, Roger Flores <aidembb at yahoo.com> wrote:
> OK, this is really helpful.  It's exactly the kind of info I was hoping to
> hear when starting this thread, and what I was looking for on the web site
> before that.

I'm afraid to add that this list is not complete at all.  It merely
shows the points that we believe are the most sticky ones.

> 1. The size of long is different on Linux versus Windows, and that affects
> code that moves eight byte pointers to longs or back (see
> http://en.wikipedia.org/wiki/64_bit#64-bit_data_models).  Most of the C code
> has been reviewed and fixed by replacing the affected longs with ptrdiff_t.

The issue here is not really to fix the static C code (although we can
discuss if ptrdiff_t is really appropriate or ssize_t or intptr_t
would be better).  The issue is fundamentally that the RPython int
type should map down to a C type that is as large as a pointer.  It's
easy to change the C code generator to write "ptrdiff_t" instead of
"long" everywhere.  It's harder to convince all the places before, and
all the tests, that some number which is too large to fit the Python
type "int" should still be regarded as a 64-bit int.  This is because
we're going to run all this on top of a host Python which will
initially be CPython --- on which the "int" type is only 32 bits.  And
we assume left and right that the distinction between the CPython
types "int" and "long" is relevant, where in fact it is not.

For example, Christian Tismer started a few years back to do some of
the first changes; look e.g. at rpython.rlib.rarithmetic.intmask, and
the comments and docstrings before.  While I may disagree about a few
comments, he writes them, which is better than most :-)  I think that
the goal should be that the RPython program always considers the
Python types "int" and "long" as completely interchangeable (as if
we'd be running on Python 3), and uses if necessary rarithmetic.maxint
rather than sys.maxint.

> So it's download, get the dependencies (including pytest), translate
> (build), test, and then you're on your way.

That's wrong.  It's download, maybe get some dependencies (but *not*
pytest, which is included), and certainly *don't attempt to translate*
(no chance to get a useful result).  Just start running tests.  Don't
even attempt to translate the full PyPy until most tests pass (say,
most of the same ones that pass on Win32).


A bient?t,

Armin.

From slayer-gurgen at yandex.ru  Sun Apr 14 08:52:39 2013
From: slayer-gurgen at yandex.ru (Evgeny Startsev)
Date: Sun, 14 Apr 2013 12:52:39 +0600
Subject: [pypy-dev] Control flow graph for method
In-Reply-To: <CAMSv6X3utQ4dfFZ_A=bvgmCKm+S4jNt_owUdja_9u8rEykXdXQ@mail.gmail.com>
References: <516A4925.4090801@yandex.ru>
	<CAMSv6X3utQ4dfFZ_A=bvgmCKm+S4jNt_owUdja_9u8rEykXdXQ@mail.gmail.com>
Message-ID: <516A5237.4030802@yandex.ru>

On 14.04.2013 13:28, Armin Rigo wrote:
> Hi,
>
> On Sun, Apr 14, 2013 at 8:13 AM, Evgeny Startsev
> <slayer-gurgen at yandex.ru> wrote:
>> I am interesting in control-flow graph generation for python projects using
>> python. I read http://doc.pypy.org/en/latest/translation.html#flow-model and
>> studied how to investigate cfg for function.
>> Is there any way to generate cfg for method using pypy?
> In rpython/bin/translatorshell.py, instead of calling
> Translation(func, [int]) you call Translation(Class.method.im_func,
> [Class, int]).
>
> This comes with the usual warnings: PyPy doesn't contain any tool that
> gives you the cfg of a Python function or method, but only contains
> tools that give the cfg of *RPython* function or methods.
>
>
> A bient?t,
>
> Armin.
Thank you very much for your response! It helps me to better understand 
situation.

Best regards, Evgeny Startsev.


From can at howyoucod.in  Sun Apr 14 14:02:59 2013
From: can at howyoucod.in (Can Ibanoglu)
Date: Sun, 14 Apr 2013 15:02:59 +0300
Subject: [pypy-dev] GSoC Application Process
Message-ID: <F5B0B7F2-C828-43AB-AB72-7C462AA40DA0@howyoucod.in>

Hello,

My name is Can Ibanoglu and I'm an industrial engineering student. I would like to get involved with the PyPy project, within the context of GSoC initially and hopefully beyond that. 

I have been interested in programming since I was 15 years old but I can't really say that I have been learning since then. I have always had some contact with programming since then but since the last two years I have been studying Python nonstop and trying to keep myself up to date with recent developments. I have learned about the PyPy project through Alex Gaynor's tweets and whole project is fascinating to me. 

Among the proposed ideas the ARM v6 Support project and the tkinter project strike me as the most interesting ones. I would like to somehow get started on my application process but I don't quite now where to start. 

I would really appreciate if anyone could point me in the right directions and give me some advice. 

Thank you very much in advance.

Regards,

Can Ibanoglu

From rharishan at gmail.com  Mon Apr 15 08:14:49 2013
From: rharishan at gmail.com (Hareesan)
Date: Mon, 15 Apr 2013 11:44:49 +0530
Subject: [pypy-dev] Further details regarding the GSOC 2013 project idea
Message-ID: <CAEtYqJmKkJb5igMr6YZ-=5Mu1-UwbqERQosnUv7xWroiHvF98Q@mail.gmail.com>

Hi there,
I'm Hareesan, An undergraduate from University of Moratuwa, Sri Lanka.
I have gone through the GSOC 2013 ideas from pypy. I'm much interested in
working on the project "New JitViewer infrastructure".
I have cloned the source and gone through pypy jitviewer introduction
paper.<http://people.cs.uct.ac.za/~tmullins/work/writeup.pdf> To start
up working with the project, it would be great if anyone could direct me
with further details such as what limitations exists, and what are the
features to be implemented what improvements required in the existing
product.

Thank you
-- 
*Hareesan R
Undergraduate
Department of Computer Science And Engineering
University Of Morat**uwa
Sri Lanka****
*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20130415/2c7ea9f0/attachment.html>

From grudypv at gmail.com  Mon Apr 15 09:11:28 2013
From: grudypv at gmail.com (gmail)
Date: Mon, 15 Apr 2013 02:11:28 -0500
Subject: [pypy-dev] ARM v6 GSOC
Message-ID: <516BA820.9040806@gmail.com>

My name is William Alumbaugh, a second year Computer Science Student 
transferring to Missouri University of Science and Technology.   I'm 
interested in the project to improve the Arm backend.   I have 
experience in C, Python,  and coincidentally, tinker with a Raspberry 
Pi.   I would be very happy to be directed to further details on the 
scope and desired experience to participate in this project.

Thanks,
William Andrew Alumbaugh

From fijall at gmail.com  Mon Apr 15 15:05:13 2013
From: fijall at gmail.com (Maciej Fijalkowski)
Date: Mon, 15 Apr 2013 15:05:13 +0200
Subject: [pypy-dev] GSoC Application Process
In-Reply-To: <F5B0B7F2-C828-43AB-AB72-7C462AA40DA0@howyoucod.in>
References: <F5B0B7F2-C828-43AB-AB72-7C462AA40DA0@howyoucod.in>
Message-ID: <CAK5idxQqMFCM8MuvEzH9h2HLZq3E6OXZnkW0AC2rA4xiEfjebw@mail.gmail.com>

On Sun, Apr 14, 2013 at 2:02 PM, Can Ibanoglu <can at howyoucod.in> wrote:
> Hello,
>
> My name is Can Ibanoglu and I'm an industrial engineering student. I would like to get involved with the PyPy project, within the context of GSoC initially and hopefully beyond that.
>
> I have been interested in programming since I was 15 years old but I can't really say that I have been learning since then. I have always had some contact with programming since then but since the last two years I have been studying Python nonstop and trying to keep myself up to date with recent developments. I have learned about the PyPy project through Alex Gaynor's tweets and whole project is fascinating to me.
>
> Among the proposed ideas the ARM v6 Support project and the tkinter project strike me as the most interesting ones. I would like to somehow get started on my application process but I don't quite now where to start.
>
> I would really appreciate if anyone could point me in the right directions and give me some advice.
>
> Thank you very much in advance.
>
> Regards,
>
> Can Ibanoglu

Hi Can.

Surprisingly enough, both of those projects has been done, however,
there is plenty of work to be done in both the area of GUI (say
gobject?) and JIT (especially on ARM), like optimizing ARM, setting up
buildbot etc.

We do however require people to make a small contribution to the
project before accepting their application. I must also warn you that
PyPy is not the easiest project out there, so if you're looking for a
free ticket through SoC, this is not the best choice.

That said, our main communication channel is #pypy on freenode. As a
start, get the pypy tests going on your raspberry pi and pop in to the
channel, we'll find you some small task

Cheers,
fijal

From fijall at gmail.com  Mon Apr 15 15:07:16 2013
From: fijall at gmail.com (Maciej Fijalkowski)
Date: Mon, 15 Apr 2013 15:07:16 +0200
Subject: [pypy-dev] Further details regarding the GSOC 2013 project idea
In-Reply-To: <CAEtYqJmKkJb5igMr6YZ-=5Mu1-UwbqERQosnUv7xWroiHvF98Q@mail.gmail.com>
References: <CAEtYqJmKkJb5igMr6YZ-=5Mu1-UwbqERQosnUv7xWroiHvF98Q@mail.gmail.com>
Message-ID: <CAK5idxRgzeaAdkgBe_PJmqpFUHBSJS9mjxqSvb_QYKetNTC9Vw@mail.gmail.com>

Hi Hareesan

There is a whole lot that can be done with the jitviewer. One obvious
thing would be to merge this info with say oprofile or improve the UI
or provide some UI for more overview than just per-loop or provide an
upload and a hosted version. There are tons of ideas around.

Pop in to #pypy on freenode if you want to discuss, IRC is our main
communication channel. Also feel free to provide more background about
yourself and your interests.

Cheers,
fijal

On Mon, Apr 15, 2013 at 8:14 AM, Hareesan <rharishan at gmail.com> wrote:
> Hi there,
> I'm Hareesan, An undergraduate from University of Moratuwa, Sri Lanka.
> I have gone through the GSOC 2013 ideas from pypy. I'm much interested in
> working on the project "New JitViewer infrastructure".
> I have cloned the source and gone through pypy jitviewer introduction paper.
> To start up working with the project, it would be great if anyone could
> direct me with further details such as what limitations exists, and what are
> the features to be implemented what improvements required in the existing
> product.
>
> Thank you
> --
> Hareesan R
> Undergraduate
> Department of Computer Science And Engineering
> University Of Moratuwa
> Sri Lanka
>
> _______________________________________________
> pypy-dev mailing list
> pypy-dev at python.org
> http://mail.python.org/mailman/listinfo/pypy-dev
>

From fijall at gmail.com  Mon Apr 15 15:35:47 2013
From: fijall at gmail.com (Maciej Fijalkowski)
Date: Mon, 15 Apr 2013 15:35:47 +0200
Subject: [pypy-dev] ARM v6 GSOC
In-Reply-To: <516BA820.9040806@gmail.com>
References: <516BA820.9040806@gmail.com>
Message-ID: <CAK5idxQymfzCf-eXJkp=qG4nqb78P8o4mhycT1pcq643Z-P1BA@mail.gmail.com>

Hi William

Surprisingly, ARMv6 support for PyPy has been done already. There is
however tons and tons of stuff you can do with the ARM backend, like
optimize it.

So far the next big step would be to get our benchmark infrastructure
running and see what's going on and how we fare against CPython.

Are you interested in other ARM-related activities?

Please write something about yourself and your interests.

Cheers,
fijal


On Mon, Apr 15, 2013 at 9:11 AM, gmail <grudypv at gmail.com> wrote:
> My name is William Alumbaugh, a second year Computer Science Student
> transferring to Missouri University of Science and Technology.   I'm
> interested in the project to improve the Arm backend.   I have experience in
> C, Python,  and coincidentally, tinker with a Raspberry Pi.   I would be
> very happy to be directed to further details on the scope and desired
> experience to participate in this project.
>
> Thanks,
> William Andrew Alumbaugh
> _______________________________________________
> pypy-dev mailing list
> pypy-dev at python.org
> http://mail.python.org/mailman/listinfo/pypy-dev

From dje.gcc at gmail.com  Mon Apr 15 17:31:22 2013
From: dje.gcc at gmail.com (David Edelsohn)
Date: Mon, 15 Apr 2013 11:31:22 -0400
Subject: [pypy-dev] GSoC Application Process
In-Reply-To: <CAK5idxQqMFCM8MuvEzH9h2HLZq3E6OXZnkW0AC2rA4xiEfjebw@mail.gmail.com>
References: <F5B0B7F2-C828-43AB-AB72-7C462AA40DA0@howyoucod.in>
	<CAK5idxQqMFCM8MuvEzH9h2HLZq3E6OXZnkW0AC2rA4xiEfjebw@mail.gmail.com>
Message-ID: <CAGWvnym8Q1mVwFq-99QzDtrLd+TZvhnj-w-ZpzmZZ5jbkcuuUw@mail.gmail.com>

On Mon, Apr 15, 2013 at 9:05 AM, Maciej Fijalkowski <fijall at gmail.com> wrote:

> Surprisingly enough, both of those projects has been done, however,
> there is plenty of work to be done in both the area of GUI (say
> gobject?) and JIT (especially on ARM), like optimizing ARM, setting up
> buildbot etc.

Hi, Can

Another opportunity is working on the PPC port -- updating for recent
changes in the infrastructure, matching the ARM port.  Access to
public PPC systems is available to developers contributing to PyPy.

Thanks, David

From dje.gcc at gmail.com  Mon Apr 15 17:32:32 2013
From: dje.gcc at gmail.com (David Edelsohn)
Date: Mon, 15 Apr 2013 11:32:32 -0400
Subject: [pypy-dev] ARM v6 GSOC
In-Reply-To: <CAK5idxQymfzCf-eXJkp=qG4nqb78P8o4mhycT1pcq643Z-P1BA@mail.gmail.com>
References: <516BA820.9040806@gmail.com>
	<CAK5idxQymfzCf-eXJkp=qG4nqb78P8o4mhycT1pcq643Z-P1BA@mail.gmail.com>
Message-ID: <CAGWvnyko8jsGCM76828mv_PWxcG+G5Zw1uh_wq0ea7TxeVj=nQ@mail.gmail.com>

On Mon, Apr 15, 2013 at 9:35 AM, Maciej Fijalkowski <fijall at gmail.com> wrote:

> Surprisingly, ARMv6 support for PyPy has been done already. There is
> however tons and tons of stuff you can do with the ARM backend, like
> optimize it.

Hi, William

Another opportunity is working on the PPC port -- updating for recent
changes in the infrastructure, matching the ARM port.  Access to
public PPC systems is available to developers contributing to PyPy.

Thanks, David

From arigo at tunes.org  Mon Apr 15 22:30:04 2013
From: arigo at tunes.org (Armin Rigo)
Date: Mon, 15 Apr 2013 22:30:04 +0200
Subject: [pypy-dev] OSError: [Errno 12] Cannot allocate memory from
 'import sqlite3' on linux
In-Reply-To: <CAAq2fm8sxTjr3SgKzxM4jqu9x7V1q3Q1N1JrLDV4ppJJgwG0xw@mail.gmail.com>
References: <CAAq2fm_njrJBTK9m2RrmJL=wYQQumx0r2_Jh=0ZbWoa-fWRBOA@mail.gmail.com>
	<CAMSv6X1rAHeTs=jLcgRngVN=307Wq83HGOH1ciPjSaJxVdi9SQ@mail.gmail.com>
	<CAMSv6X180Zs2sRwHqGoZNyGKHgRjDjUTiU+HwaUeTjgsOqETQg@mail.gmail.com>
	<CAAq2fm8sxTjr3SgKzxM4jqu9x7V1q3Q1N1JrLDV4ppJJgwG0xw@mail.gmail.com>
Message-ID: <CAMSv6X0k74cxGDyu0EwWA9mK_xrpqibkyfXLyvqDE4e9YTFCNw@mail.gmail.com>

Hi Max,

On Fri, Apr 12, 2013 at 11:54 AM, Max Lavrenov <max.lavrenov at gmail.com> wrote:
> [PyPy 2.0.0-beta2 with GCC 4.8.0] on linux2
...
> OSError: [Errno 12] Cannot allocate memory

We fixed this issue today.  It is caused very indirectly by GCC 4.8.
We had to disable a specific new aggressive optimization.


A bient?t,

Armin.

From max.lavrenov at gmail.com  Tue Apr 16 14:59:53 2013
From: max.lavrenov at gmail.com (Max Lavrenov)
Date: Tue, 16 Apr 2013 16:59:53 +0400
Subject: [pypy-dev] OSError: [Errno 12] Cannot allocate memory from
 'import sqlite3' on linux
In-Reply-To: <CAMSv6X0k74cxGDyu0EwWA9mK_xrpqibkyfXLyvqDE4e9YTFCNw@mail.gmail.com>
References: <CAAq2fm_njrJBTK9m2RrmJL=wYQQumx0r2_Jh=0ZbWoa-fWRBOA@mail.gmail.com>
	<CAMSv6X1rAHeTs=jLcgRngVN=307Wq83HGOH1ciPjSaJxVdi9SQ@mail.gmail.com>
	<CAMSv6X180Zs2sRwHqGoZNyGKHgRjDjUTiU+HwaUeTjgsOqETQg@mail.gmail.com>
	<CAAq2fm8sxTjr3SgKzxM4jqu9x7V1q3Q1N1JrLDV4ppJJgwG0xw@mail.gmail.com>
	<CAMSv6X0k74cxGDyu0EwWA9mK_xrpqibkyfXLyvqDE4e9YTFCNw@mail.gmail.com>
Message-ID: <CAAq2fm_7EX67hEnV7EqP5AB8xYyjz776OCNmfoVx7eJgAXWcyg@mail.gmail.com>

Thanks, Armin!


On Tue, Apr 16, 2013 at 12:30 AM, Armin Rigo <arigo at tunes.org> wrote:

> Hi Max,
>
> On Fri, Apr 12, 2013 at 11:54 AM, Max Lavrenov <max.lavrenov at gmail.com>
> wrote:
> > [PyPy 2.0.0-beta2 with GCC 4.8.0] on linux2
> ...
> > OSError: [Errno 12] Cannot allocate memory
>
> We fixed this issue today.  It is caused very indirectly by GCC 4.8.
> We had to disable a specific new aggressive optimization.
>
>
> A bient?t,
>
> Armin.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20130416/46f68c91/attachment.html>

From raajjya at gmail.com  Wed Apr 17 01:41:21 2013
From: raajjya at gmail.com (Jayakrishnan Rajagopalasarma)
Date: Wed, 17 Apr 2013 05:11:21 +0530
Subject: [pypy-dev] [GSOC: PyPy] -Generate wxPython Bindings for cffi
Message-ID: <CAEniZViyXJ_NbF+3trzbSp6Zr70hKAacLDsOm0C=R50Qk6Sn=Q@mail.gmail.com>

hi,
I am final year undergraduate from University of Moratuwa, SriLanka, worked
with python for the last eight months for my internship.
Interested to work with PyPy in Google Summer of code, on the subjected
project to make wxPython work with PyPy.
Expecting mentors to move on.

.y




*"Think big, Start Small, Move Fast"*

Thanks && Regards..
R. Jayakrishnan



<https://www.facebook.com/raajjya>  <http://ithayamozhy.blogspot.com/>
<https://plus.google.com/u/0/114501383949013359988/posts>
  <https://plus.google.com/u/0/114501383949013359988/posts>
<http://www.linkedin.com/profile/view?id=92231015&trk=tab_pro>
  <http://www.gmail.com>  <https://twitter.com/#!/raajjya>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20130417/44a57dfc/attachment.html>

From daniel.strauss8 at gmail.com  Wed Apr 17 01:30:26 2013
From: daniel.strauss8 at gmail.com (Daniel Strauss)
Date: Tue, 16 Apr 2013 16:30:26 -0700
Subject: [pypy-dev] Tips to Improve Your Memory - Follow up
Message-ID: <2RWHRZP-O7U8-XVFW-H8BH-7T6T3EFMJ0K6@gmail.com>

Hi,

Just getting in touch with you about your website - http://bugs.python.org/issue15490 - again. I haven't heard from you since my last email and wanted to make sure this conversation didn't get lost in translation. Hope to hear from you soon.

Best,
Daniel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20130416/80a54384/attachment.html>

From matti.picus at gmail.com  Wed Apr 17 12:23:30 2013
From: matti.picus at gmail.com (matti picus)
Date: Wed, 17 Apr 2013 13:23:30 +0300
Subject: [pypy-dev] own-windows-x86-32
Message-ID: <CAO8bCghz3FJBR4W-jaVjWwUKnaMQkG9oi5gYkaA6kzAjaiZv_Q@mail.gmail.com>

We finally have a buidlbot up and running own-windows-x86-32 tests.
The page at http://buildbot.pypy.org/summary?builder=own-win-x86-32 is
clogged with old results, could someone with superpowers please erase all
build runs before 16.4.2013 ?
Thanks,
Matti
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20130417/94dc80d4/attachment.html>

From williamandrewalumbaugh at gmail.com  Sat Apr 20 09:10:46 2013
From: williamandrewalumbaugh at gmail.com (william)
Date: Sat, 20 Apr 2013 02:10:46 -0500
Subject: [pypy-dev] Fwd: Re:  ARM v6 GSOC
In-Reply-To: <CAGWvnynoLNbux=8NVavy6rBJux8yX+VxKc718cDWPZULC=CvCg@mail.gmail.com>
References: <CAGWvnynoLNbux=8NVavy6rBJux8yX+VxKc718cDWPZULC=CvCg@mail.gmail.com>
Message-ID: <51723F76.2000701@gmail.com>




-------- Original Message --------
Subject: 	Re: [pypy-dev] ARM v6 GSOC
Date: 	Wed, 17 Apr 2013 23:39:28 -0400
From: 	David Edelsohn <dje.gcc at gmail.com>
To: 	william <williamandrewalumbaugh at gmail.com>



On Wed, Apr 17, 2013 at 9:41 PM, william
<williamandrewalumbaugh at gmail.com> wrote:

> What would be a good way to propose either of these as a project?

If you want to discuss it, we can move the conversation back to pypy-dev.

The next step is submitting an application for the project to GSoC.

Thanks, David



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20130420/1c2b1929/attachment.html>

From fijall at gmail.com  Sat Apr 20 10:58:51 2013
From: fijall at gmail.com (Maciej Fijalkowski)
Date: Sat, 20 Apr 2013 10:58:51 +0200
Subject: [pypy-dev] Fwd: Re: ARM v6 GSOC
In-Reply-To: <51723F76.2000701@gmail.com>
References: <CAGWvnynoLNbux=8NVavy6rBJux8yX+VxKc718cDWPZULC=CvCg@mail.gmail.com>
	<51723F76.2000701@gmail.com>
Message-ID: <CAK5idxQNs_nSP_Jvid+WccpokRbcpK0h8ZbiBn-+caMUUZvnjg@mail.gmail.com>

On Sat, Apr 20, 2013 at 9:10 AM, william
<williamandrewalumbaugh at gmail.com>wrote:

>
>
>
> -------- Original Message --------  Subject: Re: [pypy-dev] ARM v6 GSOC  Date:
> Wed, 17 Apr 2013 23:39:28 -0400  From: David Edelsohn <dje.gcc at gmail.com><dje.gcc at gmail.com>  To:
> william <williamandrewalumbaugh at gmail.com><williamandrewalumbaugh at gmail.com>
>
> On Wed, Apr 17, 2013 at 9:41 PM, william<williamandrewalumbaugh at gmail.com> <williamandrewalumbaugh at gmail.com> wrote:
>
> > What would be a good way to propose either of these as a project?
>
> If you want to discuss it, we can move the conversation back to pypy-dev.
>
> The next step is submitting an application for the project to GSoC.
>
> Thanks, David
>
>
>
>
> _______________________________________________
> pypy-dev mailing list
> pypy-dev at python.org
> http://mail.python.org/mailman/listinfo/pypy-dev
>
>
Hi William

I suppose I'm missing some context.

Few things:

* feel free to propose *anything* that you find interesting and is related
to pypy as a project (I'll update the wiki to say that), the list of
projects is just an example

* we generally expect people to show up some pypy-related activity before
accepting their proposal, pick a ticket, find a problem in documentation,
write a blog post explaining some pypy detail that's not documented enough,
try pypy and run benchmarks, whatever

* we can probably help you review your proposal. generally the closer you
work with us, the easier it is to get through. we never accepted a proposal
out of the blue, where we did not have any contact with the student before
the decision making deadline

Cheers,
fijal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20130420/9310a5d0/attachment.html>

From dje.gcc at gmail.com  Sat Apr 20 22:33:06 2013
From: dje.gcc at gmail.com (David Edelsohn)
Date: Sat, 20 Apr 2013 16:33:06 -0400
Subject: [pypy-dev] Fwd: Re: ARM v6 GSOC
In-Reply-To: <CAK5idxQNs_nSP_Jvid+WccpokRbcpK0h8ZbiBn-+caMUUZvnjg@mail.gmail.com>
References: <CAGWvnynoLNbux=8NVavy6rBJux8yX+VxKc718cDWPZULC=CvCg@mail.gmail.com>
	<51723F76.2000701@gmail.com>
	<CAK5idxQNs_nSP_Jvid+WccpokRbcpK0h8ZbiBn-+caMUUZvnjg@mail.gmail.com>
Message-ID: <CAGWvnynGk9m0aAAsA96ehGLzA2kmsFvyPHprFkX6CpQgRvkWUg@mail.gmail.com>

On Sat, Apr 20, 2013 at 4:58 AM, Maciej Fijalkowski <fijall at gmail.com>wrote:

>
> I suppose I'm missing some context.
>
> Few things:
>
> * feel free to propose *anything* that you find interesting and is related
> to pypy as a project (I'll update the wiki to say that), the list of
> projects is just an example
>
> * we generally expect people to show up some pypy-related activity before
> accepting their proposal, pick a ticket, find a problem in documentation,
> write a blog post explaining some pypy detail that's not documented enough,
> try pypy and run benchmarks, whatever
>
> * we can probably help you review your proposal. generally the closer you
> work with us, the easier it is to get through. we never accepted a proposal
> out of the blue, where we did not have any contact with the student before
> the decision making deadline
>

Maciej,

William is thinking about working on the PPC port of RPython and wants to
understand the next steps.  I explained a little about the current status,
hardware resources available and tasks involved, and I pointed him at the
current PPC backend branch.

Thanks, David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20130420/8ab167f3/attachment.html>

From fijall at gmail.com  Mon Apr 22 11:13:48 2013
From: fijall at gmail.com (Maciej Fijalkowski)
Date: Mon, 22 Apr 2013 11:13:48 +0200
Subject: [pypy-dev] [GSOC: PyPy] -Generate wxPython Bindings for cffi
In-Reply-To: <CAEniZViyXJ_NbF+3trzbSp6Zr70hKAacLDsOm0C=R50Qk6Sn=Q@mail.gmail.com>
References: <CAEniZViyXJ_NbF+3trzbSp6Zr70hKAacLDsOm0C=R50Qk6Sn=Q@mail.gmail.com>
Message-ID: <CAK5idxTAj=+eH8dXE2ZwnnC8mttmSHeN2ZQGwb2RKs-XbUJghw@mail.gmail.com>

Hi Jayakrishnan

Thanks for considering PyPy for your SoC.

Can you explain a bit about yourself and why the wxPython project? What are
your interests? And why PyPy?

Cheers,
fijal


On Wed, Apr 17, 2013 at 1:41 AM, Jayakrishnan Rajagopalasarma <
raajjya at gmail.com> wrote:

> hi,
> I am final year undergraduate from University of Moratuwa, SriLanka,
> worked with python for the last eight months for my internship.
> Interested to work with PyPy in Google Summer of code, on the subjected
> project to make wxPython work with PyPy.
> Expecting mentors to move on.
>
> .y
>
>
>
>
> *"Think big, Start Small, Move Fast"*
>
> Thanks && Regards..
> R. Jayakrishnan
>
>
>
> <https://www.facebook.com/raajjya>  <http://ithayamozhy.blogspot.com/> <https://plus.google.com/u/0/114501383949013359988/posts>
>   <https://plus.google.com/u/0/114501383949013359988/posts> <http://www.linkedin.com/profile/view?id=92231015&trk=tab_pro>
>   <http://www.gmail.com>  <https://twitter.com/#!/raajjya>
>
>
>
> _______________________________________________
> pypy-dev mailing list
> pypy-dev at python.org
> http://mail.python.org/mailman/listinfo/pypy-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20130422/41ce99e1/attachment.html>

From jonathan at slenders.be  Mon Apr 22 17:41:53 2013
From: jonathan at slenders.be (Jonathan Slenders)
Date: Mon, 22 Apr 2013 17:41:53 +0200
Subject: [pypy-dev] translating with --sandbox fails on latest "default"
	branch.
Message-ID: <CAKfyG3z73bm9p+2pCZ0D4YUqwtacWUkLg62PjkFb0Tce2SEQ2A@mail.gmail.com>

Hi. Is it possible that the latest default branch does not translate a
sandboxed pypy:?

I do:
python rpython/bin/rpython -O2  --sandbox pypy/goal/targetpypystandalone.py

And get the traceback below after a bit of mandelbrot.
Do we consider "default" the most stable branch? It is because I also
have a fork (with the await-keyword), and I'd like to keep it
up-to-date with the latest stable.

Thanks!
Jonathan



[translation:ERROR] Error:
[translation:ERROR]  Traceback (most recent call last):
[translation:ERROR]    File
"/home/jonathan/hg/pypy-april/pypy/rpython/translator/goal/translate.py",
line 317, in main
[translation:ERROR]     drv.proceed(goals)
[translation:ERROR]    File
"/home/jonathan/hg/pypy-april/pypy/rpython/translator/driver.py", line
733, in proceed
[translation:ERROR]     return self._execute(goals, task_skip =
self._maybe_skip())
[translation:ERROR]    File
"/home/jonathan/hg/pypy-april/pypy/rpython/translator/tool/taskengine.py",
line 114, in _execute
[translation:ERROR]     res = self._do(goal, taskcallable, *args, **kwds)
[translation:ERROR]    File
"/home/jonathan/hg/pypy-april/pypy/rpython/translator/driver.py", line
284, in _do
[translation:ERROR]     res = func()
[translation:ERROR]    File
"/home/jonathan/hg/pypy-april/pypy/rpython/translator/driver.py", line
464, in task_database_c
[translation:ERROR]     database = cbuilder.build_database()
[translation:ERROR]    File
"/home/jonathan/hg/pypy-april/pypy/rpython/translator/c/genc.py", line
175, in build_database
[translation:ERROR]     db.complete()
[translation:ERROR]    File
"/home/jonathan/hg/pypy-april/pypy/rpython/translator/c/database.py",
line 306, in complete
[translation:ERROR]     add_dependencies(node.enum_dependencies(), node)
[translation:ERROR]    File
"/home/jonathan/hg/pypy-april/pypy/rpython/translator/c/database.py",
line 294, in add_dependencies
[translation:ERROR]     self.get(value, parent and parent._funccodegen_owner)
[translation:ERROR]    File
"/home/jonathan/hg/pypy-april/pypy/rpython/translator/c/database.py",
line 226, in get
[translation:ERROR]     node = self.getcontainernode(container)
[translation:ERROR]    File
"/home/jonathan/hg/pypy-april/pypy/rpython/translator/c/database.py",
line 160, in getcontainernode
[translation:ERROR]     node = nodefactory(self, T, container, **buildkwds)
[translation:ERROR]    File
"/home/jonathan/hg/pypy-april/pypy/rpython/translator/c/node.py", line
844, in __init__
[translation:ERROR]     self.make_funcgens()
[translation:ERROR]    File
"/home/jonathan/hg/pypy-april/pypy/rpython/translator/c/node.py", line
851, in make_funcgens
[translation:ERROR]     self.funcgens =
select_function_code_generators(self.obj, self.db, self.name)
[translation:ERROR]    File
"/home/jonathan/hg/pypy-april/pypy/rpython/translator/c/node.py", line
968, in select_function_code_generators
[translation:ERROR]     return sandbox_transform(fnobj, db)
[translation:ERROR]    File
"/home/jonathan/hg/pypy-april/pypy/rpython/translator/c/node.py", line
944, in sandbox_transform
[translation:ERROR]     graph =
rsandbox.get_external_function_sandbox_graph(fnobj, db)
[translation:ERROR]    File
"/home/jonathan/hg/pypy-april/pypy/rpython/translator/sandbox/rsandbox.py",
line 166, in get_external_function_sandbox_graph
[translation:ERROR]     ann.finish()
[translation:ERROR]    File
"/home/jonathan/hg/pypy-april/pypy/rpython/rtyper/annlowlevel.py",
line 241, in finish
[translation:ERROR]     self.finish_annotate()
[translation:ERROR]    File
"/home/jonathan/hg/pypy-april/pypy/rpython/rtyper/annlowlevel.py",
line 267, in finish_annotate
[translation:ERROR]     (graph, s_result, s_real_result))
[translation:ERROR]  Exception: wrong annotation for the result of
<FunctionGraph of
(rpython.translator.sandbox.rsandbox:147)sandboxed_ll_os.ll_os_execve__star_3
at 0x28526bcc>:
[translation:ERROR] originally specified: SomeImpossibleValue()
[translation:ERROR]  found by annotating: SomePBC(can_be_None=True,
const=None, subset_of=None)

From wlavrijsen at lbl.gov  Mon Apr 22 19:39:47 2013
From: wlavrijsen at lbl.gov (wlavrijsen at lbl.gov)
Date: Mon, 22 Apr 2013 10:39:47 -0700 (PDT)
Subject: [pypy-dev] getting cppyy enabled by default in the next release?
Message-ID: <alpine.LNX.2.00.1304221024120.4022@pc3a-wlav.lbl.gov>

Hi,

what are my chances of getting cppyy enabled by default in the next (beta)
release of pypy?

The code has been cleaned so that no external libraries are needed when
builing pypy-c, and none will be needed at run-time until "import cppyy".

There is, however, an increase of 1.5MB in size of the pypy-c executable,
but that should decrease when I can find more/better ways of reusing the
code in _cfff_backend as-is.

Currently, I'm working on updating the documentation and providing a tar
file with Reflex in there. Other than that, I need to find a way to get
at least some tests to run (right now all are disabled if genreflex is
not found). I'm thinking of a "dummy" backend. Anything else?

Thanks,
      Wim

P.S.: I'm figuring that if one can load a reflex library dynamically, the
code can also manage multiple of them, simply by keeping track from which
backend the reflection info came from. With that in place, several backends
could be used simultaneously, and allow tight integration since objects can
easily be shared among them. It should then not be too hard to extend e.g.
SWIG to be used in the same way.

-- 
WLavrijsen at lbl.gov    --    +1 (510) 486 6411    --    www.lavrijsen.net

From dje.gcc at gmail.com  Mon Apr 22 21:36:50 2013
From: dje.gcc at gmail.com (David Edelsohn)
Date: Mon, 22 Apr 2013 15:36:50 -0400
Subject: [pypy-dev] Fwd: Re: ARM v6 GSOC
In-Reply-To: <51723F76.2000701@gmail.com>
References: <CAGWvnynoLNbux=8NVavy6rBJux8yX+VxKc718cDWPZULC=CvCg@mail.gmail.com>
	<51723F76.2000701@gmail.com>
Message-ID: <CAGWvnyk1wQk4VN7ftmGdRa=ZSUMC5F38Tof65gfpoR3WKhyxqQ@mail.gmail.com>

On Sat, Apr 20, 2013 at 3:10 AM, william
<williamandrewalumbaugh at gmail.com>wrote:

> On Wed, Apr 17, 2013 at 9:41 PM, william<williamandrewalumbaugh at gmail.com> <williamandrewalumbaugh at gmail.com> wrote:
>
> > What would be a good way to propose either of these as a project?
>
> If you want to discuss it, we can move the conversation back to pypy-dev.
>
> The next step is submitting an application for the project to GSoC.
>
> Thanks, David
>
>
William,

If you are interested, I would suggest that you create a draft proposal in
GSoC and then discuss it / iterate it with me and the rest of the PyPy
community, especially in the #pypy IRC channel.

As Maciej said, the PyPy community generally wants to see involvement in
the PyPy community from someone proposing a GSoC project because PyPy
itself has a learning curve and the community wants to assess if the person
will be able to accomplish the project.

Thanks, David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20130422/befec782/attachment.html>

From fijall at gmail.com  Tue Apr 23 12:03:22 2013
From: fijall at gmail.com (Maciej Fijalkowski)
Date: Tue, 23 Apr 2013 12:03:22 +0200
Subject: [pypy-dev] Fwd: Re: ARM v6 GSOC
In-Reply-To: <CAGWvnyk1wQk4VN7ftmGdRa=ZSUMC5F38Tof65gfpoR3WKhyxqQ@mail.gmail.com>
References: <CAGWvnynoLNbux=8NVavy6rBJux8yX+VxKc718cDWPZULC=CvCg@mail.gmail.com>
	<51723F76.2000701@gmail.com>
	<CAGWvnyk1wQk4VN7ftmGdRa=ZSUMC5F38Tof65gfpoR3WKhyxqQ@mail.gmail.com>
Message-ID: <CAK5idxSTyLbXGnqjXMjKYkEtUS6dNKyQ=nVuHJVvJkuUoXvY9g@mail.gmail.com>

On Mon, Apr 22, 2013 at 9:36 PM, David Edelsohn <dje.gcc at gmail.com> wrote:
> On Sat, Apr 20, 2013 at 3:10 AM, william <williamandrewalumbaugh at gmail.com>
> wrote:
>>
>> On Wed, Apr 17, 2013 at 9:41 PM, william
>> <williamandrewalumbaugh at gmail.com> wrote:
>>
>> > What would be a good way to propose either of these as a project?
>>
>> If you want to discuss it, we can move the conversation back to pypy-dev.
>>
>> The next step is submitting an application for the project to GSoC.
>>
>> Thanks, David
>
>
> William,
>
> If you are interested, I would suggest that you create a draft proposal in
> GSoC and then discuss it / iterate it with me and the rest of the PyPy
> community, especially in the #pypy IRC channel.
>
> As Maciej said, the PyPy community generally wants to see involvement in the
> PyPy community from someone proposing a GSoC project because PyPy itself has
> a learning curve and the community wants to assess if the person will be
> able to accomplish the project.
>
> Thanks, David

It's less about ability and more about involvement. I believe anyone
dedicated enough can go through SoC. However, no matter how skilled
you're if you're not willing to work, you won't get anywhere and pypy
is by far not the easiest-to-get-through project for SoC. That's why
we don't require people to do significant work, but we require them to
do *some* work.

Cheers,
fijal

From fijall at gmail.com  Tue Apr 23 12:01:43 2013
From: fijall at gmail.com (Maciej Fijalkowski)
Date: Tue, 23 Apr 2013 12:01:43 +0200
Subject: [pypy-dev] getting cppyy enabled by default in the next release?
In-Reply-To: <alpine.LNX.2.00.1304221024120.4022@pc3a-wlav.lbl.gov>
References: <alpine.LNX.2.00.1304221024120.4022@pc3a-wlav.lbl.gov>
Message-ID: <CAK5idxSr03RFPZfvL4yDeXpKJZ-NBVQJ=ugubEPjRyY2LRvYxQ@mail.gmail.com>

On Mon, Apr 22, 2013 at 7:39 PM,  <wlavrijsen at lbl.gov> wrote:
> Hi,
>
> what are my chances of getting cppyy enabled by default in the next (beta)
> release of pypy?
>
> The code has been cleaned so that no external libraries are needed when
> builing pypy-c, and none will be needed at run-time until "import cppyy".
>
> There is, however, an increase of 1.5MB in size of the pypy-c executable,
> but that should decrease when I can find more/better ways of reusing the
> code in _cfff_backend as-is.
>
> Currently, I'm working on updating the documentation and providing a tar
> file with Reflex in there. Other than that, I need to find a way to get
> at least some tests to run (right now all are disabled if genreflex is
> not found). I'm thinking of a "dummy" backend. Anything else?
>
> Thanks,
>      Wim
>
> P.S.: I'm figuring that if one can load a reflex library dynamically, the
> code can also manage multiple of them, simply by keeping track from which
> backend the reflection info came from. With that in place, several backends
> could be used simultaneously, and allow tight integration since objects can
> easily be shared among them. It should then not be too hard to extend e.g.
> SWIG to be used in the same way.
>
> --
> WLavrijsen at lbl.gov    --    +1 (510) 486 6411    --    www.lavrijsen.net
> _______________________________________________
> pypy-dev mailing list
> pypy-dev at python.org
> http://mail.python.org/mailman/listinfo/pypy-dev

I don't see a reason why not. If 1.5M were an issue, we should kill multimethods

Cheers,
fijal

From ygc.1989guang at qq.com  Tue Apr 23 13:36:29 2013
From: ygc.1989guang at qq.com (=?gb18030?B?0anAxw==?=)
Date: Tue, 23 Apr 2013 19:36:29 +0800
Subject: [pypy-dev] about PyPy sandbox
Message-ID: <tencent_4D3E6677692E71072E6E8DD9@qq.com>

Hi All,
I have study PyPy's sandbox for some time.But as my limited ability,I can't understand the detail about the PyPy's sandbox.
And I want to discuss something with you:
  
 1.Cuted Modules
What are the reasons to cut some standard modules?
(I mean the modules which in 'working_modules' but not in 'default_modules'.'working_modules' and 'default_modules' are defined in /pypy/config/pypyoption.py)
when generate C code,you use "excute" function's graph to replace the original function's graph,implement the function's replace.
I am confused why not use this method in these cuted modules like "_socket".Is there any secrity problem? you have used this method in os/posix module.
 I could understand the reason about "thread" module,because of stdin/stdout.But other modules,I can't understand.
If all dangerous function are replced to send request to controller process,Is there still any secrity problem?
 
2.sandbox_transform/sandbox_stub
This two functions are defined in /pypy/translator/c/node.py, what's the difference between them? just because the function "Not Implemented"? 
In addition,I found you have sandbox_transform() about 100+ functions in sandboxed interpreter,most of them are start with 'll_os',But in controller process,the sandlib.py only implemented about 20+ fucntions.why left others?
  
 3.which fuction need sandbox_transform()/replace function's graph attribute?
This problem I have not got a clue.Through the source code,I think it is related with 'llexternal' function, 'register_external' function,functon object's graph attribute??
 but I don't know the details about the judgement.
Can you explain it?
  
 Furthermore,Besides the webpage:"http://doc.pypy.org/en/latest/sandbox.html" ,do you have any more documents about the PyPy's sandbox? The content in that webpage is really a little less.
Maybe there are more documents/infomation in the site:"http://morepypy.blogspot.com" ,But as the GFW in China,I can't access this site.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20130423/d8d95f45/attachment.html>

From zcx3354488 at 126.com  Tue Apr 23 13:48:12 2013
From: zcx3354488 at 126.com (zcx)
Date: Tue, 23 Apr 2013 19:48:12 +0800 (CST)
Subject: [pypy-dev] about PyPy's sandbox
Message-ID: <a928e78.fa07.13e36b8f8ca.Coremail.zcx3354488@126.com>

Hi All,
I have study PyPy's sandbox for some time.But as my limited ability,I can't understand the detail about the PyPy's sandbox.
And I want to discuss something with you:
 
1.Cuted Modules
What are the reasons to cut some standard modules?
(I mean the modules which in 'working_modules' but not in 'default_modules'.'working_modules' and 'default_modules' are defined in /pypy/config/pypyoption.py)
when generate C code,you use "excute" function's graph to replace the original function's graph,implement the function's replace.
I am confused why not use this method in these cuted modules like "_socket".Is there any secrity problem? you have used this method in os/posix module.
I could understand the reason about "thread" module,because of stdin/stdout.But other modules,I can't understand.
If all dangerous function are replced to send request to controller process,Is there still any secrity problem?

2.sandbox_transform/sandbox_stub
This two functions are defined in /pypy/translator/c/node.py, what's the difference between them? just because the function "Not Implemented"?
In addition,I found you have sandbox_transform() about 100+ functions in sandboxed interpreter,most of them are start with 'll_os',But in controller process,the sandlib.py only implemented about 20+ fucntions.why left others?
 
3.which fuction need sandbox_transform()/replace function's graph attribute?
This problem I have not got a clue.Through the source code,I think it is related with 'llexternal' function, 'register_external' function,functon object's graph attribute??
but I don't know the details about the judgement.
Can you explain it?
 
Furthermore,Besides the webpage:"http://doc.pypy.org/en/latest/sandbox.html" ,do you have any more documents about the PyPy's sandbox? The content in that webpage is really a little less.
Maybe there are more documents/infomation in the site:"http://morepypy.blogspot.com" ,But as the GFW in China,I can't access this site.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20130423/c3c7567f/attachment-0001.html>

From _kfj at yahoo.com  Tue Apr 23 17:12:55 2013
From: _kfj at yahoo.com (Kay F. Jahnke)
Date: Tue, 23 Apr 2013 17:12:55 +0200
Subject: [pypy-dev] numpypy buffer interface for slices different from numpy
Message-ID: <5176A4F7.1020607@yahoo.com>

Hi group!

I stumbled upon a difference in numpypy's ndarray buffer interface. If I 
take the address of the data of a slice in numpy, I get a pointer to the 
first element in the slice. In numpypy I get a pointer to the data I 
took the slice from. I wonder if this is a bug or deliberate? If it's a 
bug, it's probably merely an omission of adding the offset to the data 
pointer. Here's what I observed:

$ pypy
Python 2.7.3 (aa7b56060ddd, Apr 22 2013, 22:03:12)
[PyPy 2.0.0-beta2 with GCC 4.4.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
And now for something completely different: ``PyPy 1.2 released -
http://pypy.org/''
 >>>> import numpypy as np
 >>>> a=np.zeros(10)
 >>>> a.__array_interface__['data'][0]
-1220095968
 >>>> a[2:].__array_interface__['data'][0]
-1220095968                                 <<<<<<<< same value

$ python
Python 2.7.3 (default, Apr 10 2013, 05:46:21)
[GCC 4.6.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
 >>> import numpy as np
 >>> a=np.zeros(10)
 >>> a.__array_interface__['data'][0]
162282152
 >>> a[2:].__array_interface__['data'][0]
162282168                                  <<<<<<<<<<< different value

with regards
Kay F. Jahnke

From fijall at gmail.com  Tue Apr 23 22:25:29 2013
From: fijall at gmail.com (Maciej Fijalkowski)
Date: Tue, 23 Apr 2013 22:25:29 +0200
Subject: [pypy-dev] [pypy-commit] pypy default: Add an alternative
 method to detect main cpu model and size using different
In-Reply-To: <20130423160820.B7E411C154E@cobra.cs.uni-duesseldorf.de>
References: <20130423160820.B7E411C154E@cobra.cs.uni-duesseldorf.de>
Message-ID: <CAK5idxRS4=r4VttxMh31fAXve_YHv0brvv=g3NjTg4-4JRtExA@mail.gmail.com>

Maybe it's worth noting that IA64 (intel itanium) is an entirely
different architecture than x86_64 and we do not support it. Please
remove chekcing for this code.

Cheers,
fijal

On Tue, Apr 23, 2013 at 6:08 PM, bivab <noreply at buildbot.pypy.org> wrote:
> Author: David Schneider <david.schneider at picle.org>
> Branch:
> Changeset: r63566:1891968c05e4
> Date: 2013-04-23 18:06 +0200
> http://bitbucket.org/pypy/pypy/changeset/1891968c05e4/
>
> Log:    Add an alternative method to detect main cpu model and size using
>         different compiler macros, useful for cross-compilation builds.
>
> diff --git a/rpython/jit/backend/detect_cpu.py b/rpython/jit/backend/detect_cpu.py
> --- a/rpython/jit/backend/detect_cpu.py
> +++ b/rpython/jit/backend/detect_cpu.py
> @@ -2,12 +2,40 @@
>  Processor auto-detection
>  """
>  import sys, os
> +from rpython.rtyper.tool.rffi_platform import getdefined
> +from rpython.translator.platform import is_host_build
>
>
>  class ProcessorAutodetectError(Exception):
>      pass
>
> +
> +def detect_main_model_and_size_from_platform():
> +    # based on http://sourceforge.net/p/predef/wiki/Architectures/
> +    mapping = {
> +            ('x86', '64'): [
> +                '__amd64__', '__amd64', '__x86_64__', '__x86_64',  # AMD64
> +                '__ia64__', '_IA64', '__IA64__'                    # Intel Itanium (IA-64)
> +                ],
> +            ('arm', '32'): ['__arm__', '__thumb__'],
> +            ('x86', '32'): ['i386', '__i386', '__i386__', '__i686__',],
> +            ('ppc', '64'): ['__powerpc64__'],
> +    }
> +    for k, v in mapping.iteritems():
> +        for macro in v:
> +            if not getdefined(macro, ''):
> +                continue
> +            return k
> +    raise ProcessorAutodetectError, "Cannot detect processor using compiler macros"
> +
> +
> +def detect_main_model_from_platform():
> +    return detect_main_model_and_size_from_platform()[0]
> +
> +
>  def autodetect_main_model():
> +    if not is_host_build():
> +        return detect_main_model_from_platform()
>      mach = None
>      try:
>          import platform
> @@ -40,6 +68,8 @@
>          return mach
>
>  def autodetect_main_model_and_size():
> +    if not is_host_build():
> +        return detect_main_model_and_size_from_platform()
>      model = autodetect_main_model()
>      if sys.maxint == 2**31-1:
>          model += '_32'
> diff --git a/rpython/jit/backend/test/test_detect_cpu.py b/rpython/jit/backend/test/test_detect_cpu.py
> --- a/rpython/jit/backend/test/test_detect_cpu.py
> +++ b/rpython/jit/backend/test/test_detect_cpu.py
> @@ -26,3 +26,8 @@
>      else:
>          from rpython.jit.backend.model import AbstractCPU
>          assert issubclass(cpu, AbstractCPU)
> +
> +
> +def test_detect_main_model_and_size_from_platform():
> +    info = detect_main_model_and_size_from_platform()
> +    assert detect_main_model_and_size_from_platform() == info
> diff --git a/rpython/translator/platform/__init__.py b/rpython/translator/platform/__init__.py
> --- a/rpython/translator/platform/__init__.py
> +++ b/rpython/translator/platform/__init__.py
> @@ -347,3 +347,6 @@
>          global host
>          host = platform
>
> +
> +def is_host_build():
> +    return host == platform
> diff --git a/rpython/translator/platform/test/test_platform.py b/rpython/translator/platform/test/test_platform.py
> --- a/rpython/translator/platform/test/test_platform.py
> +++ b/rpython/translator/platform/test/test_platform.py
> @@ -172,3 +172,13 @@
>      assert X() == X()
>      assert Y(3) == Y(3)
>      assert Y(2) != Y(3)
> +
> +
> +def test_is_host_build():
> +    from rpython.translator import platform
> +    assert platform.host == platform.platform
> +
> +    assert platform.is_host_build()
> +    platform.set_platform('maemo', None)
> +    assert platform.host != platform.platform
> +    assert not platform.is_host_build()
> _______________________________________________
> pypy-commit mailing list
> pypy-commit at python.org
> http://mail.python.org/mailman/listinfo/pypy-commit

From fijall at gmail.com  Wed Apr 24 19:45:51 2013
From: fijall at gmail.com (Maciej Fijalkowski)
Date: Wed, 24 Apr 2013 19:45:51 +0200
Subject: [pypy-dev] numpypy buffer interface for slices different from
	numpy
In-Reply-To: <5176A4F7.1020607@yahoo.com>
References: <5176A4F7.1020607@yahoo.com>
Message-ID: <CAK5idxTYfLLZDGu8nV531ps5X-yz4FCfO4SPSN_Kap0o_0X+kQ@mail.gmail.com>

On Tue, Apr 23, 2013 at 5:12 PM, Kay F. Jahnke <_kfj at yahoo.com> wrote:
> Hi group!
>
> I stumbled upon a difference in numpypy's ndarray buffer interface. If I
> take the address of the data of a slice in numpy, I get a pointer to the
> first element in the slice. In numpypy I get a pointer to the data I took
> the slice from. I wonder if this is a bug or deliberate? If it's a bug, it's
> probably merely an omission of adding the offset to the data pointer. Here's
> what I observed:

it's a bug, please file in a bug on bugs.pypy.org so we don't forget
(even better submit a patch, but a bug is good too)

Cheers,
fijal

>
> $ pypy
> Python 2.7.3 (aa7b56060ddd, Apr 22 2013, 22:03:12)
> [PyPy 2.0.0-beta2 with GCC 4.4.3] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
> And now for something completely different: ``PyPy 1.2 released -
> http://pypy.org/''
>>>>> import numpypy as np
>>>>> a=np.zeros(10)
>>>>> a.__array_interface__['data'][0]
> -1220095968
>>>>> a[2:].__array_interface__['data'][0]
> -1220095968                                 <<<<<<<< same value
>
> $ python
> Python 2.7.3 (default, Apr 10 2013, 05:46:21)
> [GCC 4.6.3] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
>>>> import numpy as np
>>>> a=np.zeros(10)
>>>> a.__array_interface__['data'][0]
> 162282152
>>>> a[2:].__array_interface__['data'][0]
> 162282168                                  <<<<<<<<<<< different value
>
> with regards
> Kay F. Jahnke
> _______________________________________________
> pypy-dev mailing list
> pypy-dev at python.org
> http://mail.python.org/mailman/listinfo/pypy-dev

From fijall at gmail.com  Fri Apr 26 09:04:51 2013
From: fijall at gmail.com (Maciej Fijalkowski)
Date: Fri, 26 Apr 2013 09:04:51 +0200
Subject: [pypy-dev] [pypy-commit] pypy default: Inline into ll_setslice
 (which is really just an ll_arraycopy). Fixed a bug in the heapcache that
 it revealed.
In-Reply-To: <20130426042345.010EB1C02DA@cobra.cs.uni-duesseldorf.de>
References: <20130426042345.010EB1C02DA@cobra.cs.uni-duesseldorf.de>
Message-ID: <CAK5idxQKD45Nb52ATM=pzJpkY5yj9_HEC-xm3G0CbXn19W=ENg@mail.gmail.com>

How about a test? Especially for the heapcache

On Fri, Apr 26, 2013 at 6:23 AM, alex_gaynor <noreply at buildbot.pypy.org> wrote:
> Author: Alex Gaynor <alex.gaynor at gmail.com>
> Branch:
> Changeset: r63627:23defdb27411
> Date: 2013-04-25 21:22 -0700
> http://bitbucket.org/pypy/pypy/changeset/23defdb27411/
>
> Log:    Inline into ll_setslice (which is really just an ll_arraycopy).
>         Fixed a bug in the heapcache that it revealed.
>
> diff --git a/rpython/jit/codewriter/support.py b/rpython/jit/codewriter/support.py
> --- a/rpython/jit/codewriter/support.py
> +++ b/rpython/jit/codewriter/support.py
> @@ -203,7 +203,6 @@
>  _ll_2_list_append = rlist.ll_append
>  _ll_2_list_extend = rlist.ll_extend
>  _ll_3_list_insert = rlist.ll_insert_nonneg
> -_ll_4_list_setslice = rlist.ll_listsetslice
>  _ll_2_list_delslice_startonly = rlist.ll_listdelslice_startonly
>  _ll_3_list_delslice_startstop = rlist.ll_listdelslice_startstop
>  _ll_2_list_inplace_mul = rlist.ll_inplace_mul
> diff --git a/rpython/jit/metainterp/heapcache.py b/rpython/jit/metainterp/heapcache.py
> --- a/rpython/jit/metainterp/heapcache.py
> +++ b/rpython/jit/metainterp/heapcache.py
> @@ -125,7 +125,7 @@
>                      for descr, cache in self.heap_array_cache.iteritems():
>                          for idx, cache in cache.iteritems():
>                              for frombox in cache.keys():
> -                                if frombox not in self.new_boxes:
> +                                if not self.new_boxes.get(frombox, False):
>                                      del cache[frombox]
>                      return
>              else:
> diff --git a/rpython/jit/metainterp/test/test_list.py b/rpython/jit/metainterp/test/test_list.py
> --- a/rpython/jit/metainterp/test/test_list.py
> +++ b/rpython/jit/metainterp/test/test_list.py
> @@ -128,10 +128,10 @@
>          res = self.interp_operations(f, [], listops=True)
>          assert res == 10
>
> -    def test_arraycopy_bug(self):
> +    def test_arraycopy_bug(self):
>          def f():
>              l = [1, 2, 3, 4]
> -            l2 = [1, 2, 3, 4]
> +            l2 = [1, 2, 3, 5]
>              l[2] = 13
>              l2[0:len(l2)] = l[:]
>              return l2[0] + l2[1] + l2[2] + l2[3]
> diff --git a/rpython/rtyper/rlist.py b/rpython/rtyper/rlist.py
> --- a/rpython/rtyper/rlist.py
> +++ b/rpython/rtyper/rlist.py
> @@ -955,7 +955,7 @@
>                   "setslice cannot resize lists in RPython")
>      # XXX ...but it would be easy enough to support if really needed
>      ll_arraycopy(l2, l1, 0, start, count)
> -ll_listsetslice.oopspec = 'list.setslice(l1, start, stop, l2)'
> +
>
>  # ____________________________________________________________
>  #
> _______________________________________________
> pypy-commit mailing list
> pypy-commit at python.org
> http://mail.python.org/mailman/listinfo/pypy-commit

From abrenon at wyplay.com  Fri Apr 26 09:53:13 2013
From: abrenon at wyplay.com (Alexis BRENON)
Date: Fri, 26 Apr 2013 09:53:13 +0200
Subject: [pypy-dev] Pypy MIPS port
Message-ID: <517A3269.6050605@wyplay.com>

Hi,

I'm doing an internship into the Wyplay company. My internship subject 
is to try to port pypy to MIPS architecture, to make it run on their boxes.

I see that there was somebody who launched this idea two years ago, but 
nothing was done... I would like to relaunch it today.

If I understand the Pypy project architecture, all I have to do, is 
modifying the 'rpython/jit' directory, adding a 'backend/mips' 
directory, able to generate the JIT compiler for MIPS architecture, I 
don't ?
There is, after, a tiny modification to generate the mips options in the 
makefile, for the C file compilation.

Am I right ? If not, anyone can explain me what I misunderstood ?

Regards.
Alexis BRENON, for Wyplay <http://www.wyplay.com/>

From alex.gaynor at gmail.com  Fri Apr 26 10:31:26 2013
From: alex.gaynor at gmail.com (Alex Gaynor)
Date: Fri, 26 Apr 2013 03:31:26 -0500
Subject: [pypy-dev] [pypy-commit] pypy default: Inline into ll_setslice
 (which is really just an ll_arraycopy). Fixed a bug in the heapcache that
 it revealed.
In-Reply-To: <CAK5idxQKD45Nb52ATM=pzJpkY5yj9_HEC-xm3G0CbXn19W=ENg@mail.gmail.com>
References: <20130426042345.010EB1C02DA@cobra.cs.uni-duesseldorf.de>
	<CAK5idxQKD45Nb52ATM=pzJpkY5yj9_HEC-xm3G0CbXn19W=ENg@mail.gmail.com>
Message-ID: <CAFRnB2XCJbeOfwbGLeyNM6-V6u16ri5xTjcf4PLM4aLEVghNew@mail.gmail.com>

There was a test in rlist.py that caught the error, I'll add a unittest for
heapcache though.

Alex


On Fri, Apr 26, 2013 at 2:04 AM, Maciej Fijalkowski <fijall at gmail.com>wrote:

> How about a test? Especially for the heapcache
>
> On Fri, Apr 26, 2013 at 6:23 AM, alex_gaynor <noreply at buildbot.pypy.org>
> wrote:
> > Author: Alex Gaynor <alex.gaynor at gmail.com>
> > Branch:
> > Changeset: r63627:23defdb27411
> > Date: 2013-04-25 21:22 -0700
> > http://bitbucket.org/pypy/pypy/changeset/23defdb27411/
> >
> > Log:    Inline into ll_setslice (which is really just an ll_arraycopy).
> >         Fixed a bug in the heapcache that it revealed.
> >
> > diff --git a/rpython/jit/codewriter/support.py
> b/rpython/jit/codewriter/support.py
> > --- a/rpython/jit/codewriter/support.py
> > +++ b/rpython/jit/codewriter/support.py
> > @@ -203,7 +203,6 @@
> >  _ll_2_list_append = rlist.ll_append
> >  _ll_2_list_extend = rlist.ll_extend
> >  _ll_3_list_insert = rlist.ll_insert_nonneg
> > -_ll_4_list_setslice = rlist.ll_listsetslice
> >  _ll_2_list_delslice_startonly = rlist.ll_listdelslice_startonly
> >  _ll_3_list_delslice_startstop = rlist.ll_listdelslice_startstop
> >  _ll_2_list_inplace_mul = rlist.ll_inplace_mul
> > diff --git a/rpython/jit/metainterp/heapcache.py
> b/rpython/jit/metainterp/heapcache.py
> > --- a/rpython/jit/metainterp/heapcache.py
> > +++ b/rpython/jit/metainterp/heapcache.py
> > @@ -125,7 +125,7 @@
> >                      for descr, cache in
> self.heap_array_cache.iteritems():
> >                          for idx, cache in cache.iteritems():
> >                              for frombox in cache.keys():
> > -                                if frombox not in self.new_boxes:
> > +                                if not self.new_boxes.get(frombox,
> False):
> >                                      del cache[frombox]
> >                      return
> >              else:
> > diff --git a/rpython/jit/metainterp/test/test_list.py
> b/rpython/jit/metainterp/test/test_list.py
> > --- a/rpython/jit/metainterp/test/test_list.py
> > +++ b/rpython/jit/metainterp/test/test_list.py
> > @@ -128,10 +128,10 @@
> >          res = self.interp_operations(f, [], listops=True)
> >          assert res == 10
> >
> > -    def test_arraycopy_bug(self):
> > +    def test_arraycopy_bug(self):
> >          def f():
> >              l = [1, 2, 3, 4]
> > -            l2 = [1, 2, 3, 4]
> > +            l2 = [1, 2, 3, 5]
> >              l[2] = 13
> >              l2[0:len(l2)] = l[:]
> >              return l2[0] + l2[1] + l2[2] + l2[3]
> > diff --git a/rpython/rtyper/rlist.py b/rpython/rtyper/rlist.py
> > --- a/rpython/rtyper/rlist.py
> > +++ b/rpython/rtyper/rlist.py
> > @@ -955,7 +955,7 @@
> >                   "setslice cannot resize lists in RPython")
> >      # XXX ...but it would be easy enough to support if really needed
> >      ll_arraycopy(l2, l1, 0, start, count)
> > -ll_listsetslice.oopspec = 'list.setslice(l1, start, stop, l2)'
> > +
> >
> >  # ____________________________________________________________
> >  #
> > _______________________________________________
> > pypy-commit mailing list
> > pypy-commit at python.org
> > http://mail.python.org/mailman/listinfo/pypy-commit
> _______________________________________________
> pypy-dev mailing list
> pypy-dev at python.org
> http://mail.python.org/mailman/listinfo/pypy-dev
>



-- 
"I disapprove of what you say, but I will defend to the death your right to
say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
"The people's good is the highest law." -- Cicero
GPG Key fingerprint: 125F 5C67 DFE9 4084
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20130426/c4f84914/attachment.html>

From fijall at gmail.com  Fri Apr 26 11:04:49 2013
From: fijall at gmail.com (Maciej Fijalkowski)
Date: Fri, 26 Apr 2013 11:04:49 +0200
Subject: [pypy-dev] Pypy MIPS port
In-Reply-To: <517A3269.6050605@wyplay.com>
References: <517A3269.6050605@wyplay.com>
Message-ID: <CAK5idxRYbXO-oS5sn=oQpJ6sX19PjJp75BCV_hqKmN6b65dy=A@mail.gmail.com>

On Fri, Apr 26, 2013 at 9:53 AM, Alexis BRENON <abrenon at wyplay.com> wrote:
> Hi,
>
> I'm doing an internship into the Wyplay company. My internship subject is to
> try to port pypy to MIPS architecture, to make it run on their boxes.
>
> I see that there was somebody who launched this idea two years ago, but
> nothing was done... I would like to relaunch it today.
>
> If I understand the Pypy project architecture, all I have to do, is
> modifying the 'rpython/jit' directory, adding a 'backend/mips' directory,
> able to generate the JIT compiler for MIPS architecture, I don't ?
> There is, after, a tiny modification to generate the mips options in the
> makefile, for the C file compilation.
>
> Am I right ? If not, anyone can explain me what I misunderstood ?
>
> Regards.
> Alexis BRENON, for Wyplay <http://www.wyplay.com/>
> _______________________________________________
> pypy-dev mailing list
> pypy-dev at python.org
> http://mail.python.org/mailman/listinfo/pypy-dev

Hi Alexis.

It's very cool, MIPS is certainly one of the missing ports.

In fact, it's less than that. Most of the rpython/jit directory does
not have to be modified. It's 'just' rpython/jit/backend/mips and some
support code in rpython/jit/backend/llsupport and that's it.

The good starting point would be to add an empty MIPS backend and try
running test_runner.py (like in backend/x86/test/test_runner.py or
ARM). Are you familiar with ARM or x86 assembler? That would be a very
good starting point to see how the current backends are implemented.

Feel free to pop in on #pypy on irc.freenode.net, we're very
irc-based. Is the part of the plan to contribute the MIPS backend to
the pypy repo?

Cheers,
fijal

From abrenon at wyplay.com  Fri Apr 26 11:50:04 2013
From: abrenon at wyplay.com (Alexis BRENON)
Date: Fri, 26 Apr 2013 11:50:04 +0200
Subject: [pypy-dev] Pypy MIPS port
In-Reply-To: <CAK5idxRYbXO-oS5sn=oQpJ6sX19PjJp75BCV_hqKmN6b65dy=A@mail.gmail.com>
References: <517A3269.6050605@wyplay.com>
	<CAK5idxRYbXO-oS5sn=oQpJ6sX19PjJp75BCV_hqKmN6b65dy=A@mail.gmail.com>
Message-ID: <517A4DCC.4090900@wyplay.com>

Le 26/04/2013 11:04, Maciej Fijalkowski a ?crit :
> On Fri, Apr 26, 2013 at 9:53 AM, Alexis BRENON <abrenon at wyplay.com> wrote:
>> Hi,
>>
>> I'm doing an internship into the Wyplay company. My internship subject is to
>> try to port pypy to MIPS architecture, to make it run on their boxes.
>>
>> I see that there was somebody who launched this idea two years ago, but
>> nothing was done... I would like to relaunch it today.
>>
>> If I understand the Pypy project architecture, all I have to do, is
>> modifying the 'rpython/jit' directory, adding a 'backend/mips' directory,
>> able to generate the JIT compiler for MIPS architecture, I don't ?
>> There is, after, a tiny modification to generate the mips options in the
>> makefile, for the C file compilation.
>>
>> Am I right ? If not, anyone can explain me what I misunderstood ?
>>
>> Regards.
>> Alexis BRENON, for Wyplay <http://www.wyplay.com/>
>> _______________________________________________
>> pypy-dev mailing list
>> pypy-dev at python.org
>> http://mail.python.org/mailman/listinfo/pypy-dev
> Hi Alexis.
>
> It's very cool, MIPS is certainly one of the missing ports.
>
> In fact, it's less than that. Most of the rpython/jit directory does
> not have to be modified. It's 'just' rpython/jit/backend/mips and some
> support code in rpython/jit/backend/llsupport and that's it.
>
> The good starting point would be to add an empty MIPS backend and try
> running test_runner.py (like in backend/x86/test/test_runner.py or
> ARM). Are you familiar with ARM or x86 assembler? That would be a very
> good starting point to see how the current backends are implemented.
>
> Feel free to pop in on #pypy on irc.freenode.net, we're very
> irc-based. Is the part of the plan to contribute the MIPS backend to
> the pypy repo?
>
> Cheers,
> fijal

Of course, if I managed to make a good MIPS backend, I'll be pride to 
merge it with the default branch of the pypy repo. Even if I don't reach 
my goal, I'll commit all my work on the repo, to anybody interesting in 
this port can continue it.

I did some assembler, 3 years ago, during my studies, but it was with a 
very simple instruction set (I don't remember which processor we used), 
and with the assembler directives, not the hexadecimal representation, 
as I can see in the pypy code :-p

There is a lot of people on the IRC channel yet, and I'm pride to join 
you, as alex-dit-sean.

Regards,
Alexis

From arigo at tunes.org  Sat Apr 27 10:25:29 2013
From: arigo at tunes.org (Armin Rigo)
Date: Sat, 27 Apr 2013 10:25:29 +0200
Subject: [pypy-dev] about PyPy's sandbox
In-Reply-To: <a928e78.fa07.13e36b8f8ca.Coremail.zcx3354488@126.com>
References: <a928e78.fa07.13e36b8f8ca.Coremail.zcx3354488@126.com>
Message-ID: <CAMSv6X3064Ndw5NMRxZjGdxM_y6n=J9C1Gm+2GvDnqdykEmJ=A@mail.gmail.com>

Hi,

On Tue, Apr 23, 2013 at 1:48 PM, zcx <zcx3354488 at 126.com> wrote:
> I have study PyPy's sandbox for some time.But as my limited ability,I can't
> understand the detail about the PyPy's sandbox.

Sorry, PyPy's sandbox is not officially supported for now.  We'd
welcome someone who was interested in really developing it and
maintaining it.

> What are the reasons to cut some standard modules?

The reason is a question of level.  Most standard modules would not
translate.  This is because the sandboxing occurs at a certain level,
namely extdef() as seen for example in rpython.rtyper.module.ll_os;
but most standard modules don't use this, and instead directly call C
functions with llexternal().

It may be possible to change the level and apply sandboxing at the
level of llexternal functions.

> 2.sandbox_transform/sandbox_stub
> This two functions are defined in /pypy/translator/c/node.py, what's the
> difference between them?

sandbox_stub() is used in various cases, including the case I
described above of llexternal functions, and in some cases that are
present only for historical reasons and should be changed.  Over the
long history of PyPy we used to experiment with a number of different
ways to call C functions from RPython, before we eventually settled
for llexternal().

> In addition,I found you have sandbox_transform() about 100+ functions in
> sandboxed interpreter,most of them are start with 'll_os',But in controller
> process,the sandlib.py only implemented about 20+ fucntions.why left others?

No reason.  All other functions are just not written in sandlib.py
because nobody needed them so far.  It's all experimental and was
never seriously completed.


A bient?t,

Armin.

From evento at miltons-shirts.com  Mon Apr 29 16:17:53 2013
From: evento at miltons-shirts.com (Smart Business Evento)
Date: Mon, 29 Apr 2013 16:17:53 +0200
Subject: [pypy-dev] Invito Esclusivo per l'IMPRENDITORE
Message-ID: <MTkyMTc5NwAC407540Y16BAMTM2NzI0NTA3MzEzMjQx@www.miltons-shirts.com>

Caro Imprenditore,

Questa mail ti raggiunge per 
INVITARTI ad un EVENTO ESCLUSIVO
DEDICATO AI SOLI IMPRENDITORI
che abbiamo organizzato a Palermo il 9 Maggio 2013,
DEDICATO A TE e alla TUA AZIENDA.

--------- CLICCA QUI ( http://www.smartbusinesslab.com/evento ) --------- 
per scoprire di cosa si tratta.

PS: Non ci conosci (Ancora) e ricevi 
questa mail perch? ABBIAMO ACQUISTATO 
da liste pubbliche il tuo contatto. 
Se vuoi, puoi disiscriverti da questa lista 
cliccando qui (
http://www.miltons-shirts.com/leads/index.php?subid=407540&option=com_acymailing&ctrl=user&task=out&mailid=16&key=202c460b0eb1b2ecf7e4cb62d095320c ); 

per cortesia visiona prima l'invito.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20130429/95950e5d/attachment.html>

From gamcat at gmail.com  Tue Apr 30 05:26:49 2013
From: gamcat at gmail.com (cat street)
Date: Tue, 30 Apr 2013 11:26:49 +0800
Subject: [pypy-dev] Pypy is slower than Python
Message-ID: <CA+o6pZYewSpU5uLiS+ocrTnoKU5VCTZR=qVzPOVckY=_f+c9ng@mail.gmail.com>

You can test this code:

import time

def test(n):
    m = 10
    vals = []
    keys = []
    for i in xrange(m):
        vals.append(i)
        keys.append('a%s'%i)
    d = None
    for i in xrange(n):
        d = dict(zip(keys, vals))
    return d

if __name__ == '__main__':
    st = time.time()
    print test(1000000)
    print 'use:', time.time() - st

-- 
HomePage: cat.appspot.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20130430/cfc3f0c2/attachment.html>

From arigo at tunes.org  Tue Apr 30 11:25:47 2013
From: arigo at tunes.org (Armin Rigo)
Date: Tue, 30 Apr 2013 11:25:47 +0200
Subject: [pypy-dev] translating with --sandbox fails on latest "default"
	branch.
In-Reply-To: <CAKfyG3z73bm9p+2pCZ0D4YUqwtacWUkLg62PjkFb0Tce2SEQ2A@mail.gmail.com>
References: <CAKfyG3z73bm9p+2pCZ0D4YUqwtacWUkLg62PjkFb0Tce2SEQ2A@mail.gmail.com>
Message-ID: <CAMSv6X2M-0FBfacmsMtJtXYBaXKazD4wwHdWmnDjwSbDQv2AgA@mail.gmail.com>

Hi Jonathan,

On Mon, Apr 22, 2013 at 5:41 PM, Jonathan Slenders <jonathan at slenders.be> wrote:
> Hi. Is it possible that the latest default branch does not translate a
> sandboxed pypy:?

Indeed, fixed in 5af6563cf284.


Armin

From jonathan at slenders.be  Tue Apr 30 15:26:24 2013
From: jonathan at slenders.be (Jonathan Slenders)
Date: Tue, 30 Apr 2013 15:26:24 +0200
Subject: [pypy-dev] translating with --sandbox fails on latest "default"
	branch.
In-Reply-To: <CAMSv6X2M-0FBfacmsMtJtXYBaXKazD4wwHdWmnDjwSbDQv2AgA@mail.gmail.com>
References: <CAKfyG3z73bm9p+2pCZ0D4YUqwtacWUkLg62PjkFb0Tce2SEQ2A@mail.gmail.com>
	<CAMSv6X2M-0FBfacmsMtJtXYBaXKazD4wwHdWmnDjwSbDQv2AgA@mail.gmail.com>
Message-ID: <CAKfyG3z-OikK_QFJxBZLKsho9gvV2sVAzVpQYiBURHxORTcZ2A@mail.gmail.com>

Thank you Armin!

2013/4/30 Armin Rigo <arigo at tunes.org>:
> Hi Jonathan,
>
> On Mon, Apr 22, 2013 at 5:41 PM, Jonathan Slenders <jonathan at slenders.be> wrote:
>> Hi. Is it possible that the latest default branch does not translate a
>> sandboxed pypy:?
>
> Indeed, fixed in 5af6563cf284.
>
>
> Armin

From arigo at tunes.org  Tue Apr 30 18:51:08 2013
From: arigo at tunes.org (Armin Rigo)
Date: Tue, 30 Apr 2013 18:51:08 +0200
Subject: [pypy-dev] Pypy is slower than Python
In-Reply-To: <CA+o6pZYewSpU5uLiS+ocrTnoKU5VCTZR=qVzPOVckY=_f+c9ng@mail.gmail.com>
References: <CA+o6pZYewSpU5uLiS+ocrTnoKU5VCTZR=qVzPOVckY=_f+c9ng@mail.gmail.com>
Message-ID: <CAMSv6X2xjTZNWqZrSJC8PF8a=dWh=4wyu1nGb868cD=Z5v7ibA@mail.gmail.com>

Hi,

On Tue, Apr 30, 2013 at 5:26 AM, cat street <gamcat at gmail.com> wrote:
> You can test this code:
> (...)

For no good reason it seems that on this example CPython is quite a
bit faster on Linux64 than on Linux32.  PyPy is also a bit faster on
Linux64 but not by such a large margin.  In my tests (PyPy vs CPython)
it ends up the same on Linux32, and on Linux64 PyPy is a bit slower
(20%?).  I think it's good enough given the type of code (completely
unoptimizable as far as I can tell, unless we go for "we can kill the
whole loop in this benchmark", which is usually a bit pointless in
real code).  If others want to look in detail at JIT traces, feel free
to.


A bient?t,

Armin.