headers
Kenji Yano | 1 Aug 2011 07:25
Picon

html_fibo.py’s problem.

Hi

I　found the cause of html_fibo.py at the EuroPython Hands-on.
This case, HtmlTag destructor isn’t call when the object didn’t use.
Is this garbage collection’s problem?
(pypy-trunk(1.6.0-dev) same too.)

===
def html_fibo(f):
    f.write('<ul>\n')
    try:
        for n in fibo():
            tag = HtmlTag(f, 4, 'li')
            yield n
            tag = None       # doesn’t call destructor here.
    finally:
        tag = None           # here, too.
        f.write('</ul>\n')

def write_file():
    f = open('fibo.txt', 'w')   # f.close does’nt call, too.
    for n in html_fibo(f):
        f.write('%d' % n)
        if n > 100:
            break

runing code and patch are the following link.(not pypy source code patch.)
https://gist.github.com/1117550

and is this problem in bugs.pypy.org? I can’nt found it.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Eric van Riet Paap | 1 Aug 2011 08:07
Picon

Status of ARM backend

Hi,

Can someone please give us an update on the status of the ARM backend.
Is it time already to get our iPhones and Androids out of our pockets
and start creating that killer app using PyPy?

cheers,
Eric
Permalink | Reply | 4 comments |
headers
Antonio Cuni | 1 Aug 2011 09:59
Picon
Gravatar

Re: newbie needs pypy setup help

Hi Tom,

On 31/07/11 23:05, Tom Roche wrote:
>> https://bugs.pypy.org/issue772
>
>> so the next release should resolve that problem for system wide installs.
>
> By "next release," do you mean 1.6? (BTW, to show bona fides, and since it needed done, I updated

yes, but it's also possible to download the nightly builds right now:
http://buildbot.pypy.org/nightly/trunk/

could you please check that the permission issue is actually fixed in the 
nightly tarballs?

ciao,
Anto
Permalink | Reply | 1 comment |
headers
Antonio Cuni | 1 Aug 2011 10:05
Picon
Gravatar

Re: html_fibo.py’s problem.

On 01/08/11 07:25, Kenji Yano wrote:
> Hi
>
> I　found the cause of html_fibo.py at the EuroPython Hands-on.
> This case, HtmlTag destructor isn’t call when the object didn’t use.
> Is this garbage collection’s problem?
> (pypy-trunk(1.6.0-dev) same too.)

yes.  The difference with CPython is that CPython destroys the object as soon 
as it forgets the last reference to the object (and thus it is deterministic), 
while on PyPy the objects are destroyed only the the GC runs (which is not 
deterministic).

> runing code and patch are the following link.(not pypy source code patch.)
> https://gist.github.com/1117550

your patch works but it's suboptimal and slower than it need. The proper 
solution would be to add the appropriate calls to .close() to the file and to 
the generator (possibily using the with statement) and also to provide a 
method to HtmlTag to explicitly close the tag instead of relying on the __del__.

> and is this problem in bugs.pypy.org? I can’nt found it.

it works for me:
https://bugs.pypy.org/

you need to explicitly allow our custom SSL certificate, but that's all.

ciao,
Anto
(Continue reading)

Permalink | Reply | 1 comment |
headers
Kenji Yano | 1 Aug 2011 13:03
Picon

Re: html_fibo.py’s problem.

Hi, Anto

Thanks for your reply.

2011/8/1 Antonio Cuni <anto.cuni <at> gmail.com>:
> On 01/08/11 07:25, Kenji Yano wrote:
>>
>> Hi
>>
>> I　found the cause of html_fibo.py at the EuroPython Hands-on.
>> This case, HtmlTag destructor isn’t call when the object didn’t use.
>> Is this garbage collection’s problem?
>> (pypy-trunk(1.6.0-dev) same too.)
>
> yes.  The difference with CPython is that CPython destroys the object as
> soon as it forgets the last reference to the object (and thus it is
> deterministic), while on PyPy the objects are destroyed only the the GC runs
> (which is not deterministic).

OK, I understand.

>
>> runing code and patch are the following link.(not pypy source code patch.)
>> https://gist.github.com/1117550
>
> your patch works but it's suboptimal and slower than it need. The proper
> solution would be to add the appropriate calls to .close() to the file and
> to the generator (possibily using the with statement) and also to provide a
> method to HtmlTag to explicitly close the tag instead of relying on the
> __del__.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Tom Roche | 1 Aug 2011 15:56
Picon
Favicon

issue772 install permissions fix, was: newbie needs pypy setup help


Janzert Sun, 31 Jul 2011 16:18:32 -0400
>> https://bugs.pypy.org/issue772

Antonio Cuni Mon, 01 Aug 2011 09:59:00 +0200
> could you please check that the permission issue is actually fixed in
> the nightly tarballs?

It is currently: the tail of the output from

BUILD_NAME="pypy-c-jit-latest-linux64"
BUILD_TAG="pypy-c-jit-46097-54515dec1d20-linux64"
URI="http://buildbot.pypy.org/nightly/trunk/${BUILD_NAME}.tar.bz2"
TMP_DIR_ROOT="/tmp/pypy/${BUILD_TAG}"
TARGET_DIR_ROOT="/opt/${BUILD_NAME}"
TARGET_PYPY_EXEC="${TARGET_DIR_ROOT}/bin/pypy"
USR_PYPY_EXEC="/usr/local/bin/pypy"
#  "sudo chmod -R go+rX ${TARGET_DIR_ROOT}/" \
for CMD in \
  "rm -fr $(dirname ${TMP_DIR_ROOT})" \
  "mkdir -p ${TMP_DIR_ROOT}" \
  "pushd $(dirname ${TMP_DIR_ROOT})" \
  "wget -O - ${URI} | tar xvjf -" \
  "ls -alh" \
  "popd" \
  "sudo rm -fr ${TARGET_DIR_ROOT}" \
  "sudo mkdir -p ${TARGET_DIR_ROOT}" \
  "sudo cp -r ${TMP_DIR_ROOT}/* ${TARGET_DIR_ROOT}/" \
  "sudo ln -s ${TARGET_PYPY_EXEC} ${USR_PYPY_EXEC}" \
  "which pypy" \
(Continue reading)

Permalink | Reply | 0 comments |
headers
Carl Friedrich Bolz | 2 Aug 2011 10:20
Picon
Picon
Gravatar

unroll if

hi Alex, hi all,

I don't have much time for things, about to leave on vacation. Just so
that it doesn't get lost: on the unrolling-if branch, if you use the
decorator, the JIT should *not* look inside the function if the
condition if false. even if the function doesn't contain a loop. so
maybe the decorators should be renamed to unroll_iff (too
mathematical?) or unroll_exactly_if.

Cheers,

Carl Friedrich
Permalink | Reply | 4 comments |
headers
Armin Rigo | 2 Aug 2011 11:41
Favicon

Re: unroll if

Hi Carl,

On Tue, Aug 2, 2011 at 10:20 AM, Carl Friedrich Bolz <cfbolz <at> gmx.de> wrote:
> I don't have much time for things, about to leave on vacation. Just so
> that it doesn't get lost: on the unrolling-if branch, if you use the
> decorator, the JIT should *not* look inside the function if the
> condition if false. even if the function doesn't contain a loop. so
> maybe the decorators should be renamed to unroll_iff (too
> mathematical?) or unroll_exactly_if.

Then it has nothing to do with unrolling: it should be renamed to
something like "look_inside_if".  It just happens to mean, as a
side-effect, "if the condition is true, then look inside even in case
there is a loop, thus unrolling it".

A bientôt,

Armin.
Permalink | Reply | 3 comments |
headers
Antonio Cuni | 2 Aug 2011 12:05
Picon
Gravatar

Re: unroll if

On 02/08/11 11:41, Armin Rigo wrote:
> Then it has nothing to do with unrolling: it should be renamed to
> something like "look_inside_if".  It just happens to mean, as a
> side-effect, "if the condition is true, then look inside even in case
> there is a loop, thus unrolling it".

look_inside_and_maybe_unroll_if?
Permalink | Reply | 0 comments |
headers
Carl Friedrich Bolz | 2 Aug 2011 12:00
Picon
Picon
Gravatar

Re: unroll if

On 08/02/2011 11:41 AM, Armin Rigo wrote:
> Hi Carl,
>
> On Tue, Aug 2, 2011 at 10:20 AM, Carl Friedrich Bolz<cfbolz <at> gmx.de>  wrote:
>> I don't have much time for things, about to leave on vacation. Just so
>> that it doesn't get lost: on the unrolling-if branch, if you use the
>> decorator, the JIT should *not* look inside the function if the
>> condition if false. even if the function doesn't contain a loop. so
>> maybe the decorators should be renamed to unroll_iff (too
>> mathematical?) or unroll_exactly_if.
>
> Then it has nothing to do with unrolling: it should be renamed to
> something like "look_inside_if".  It just happens to mean, as a
> side-effect, "if the condition is true, then look inside even in case
> there is a loop, thus unrolling it".

look_inside_iff then? :-)

Carl Friedrich
Permalink | Reply | 1 comment |

Gmane