holger krekel wrote:
Hi Armin, all,
don't know if you noticed: i think that your readline/curses
hack is good enough that my good old completion module mostly
works out of the box on pypy-c. (http://codespeak.net/rlcompleter2/).
It produces slightly different output and there probably also
Laura Creighton wrote:
now would be a great time to let the pygame list know.
Laura, going back to vacation, and not going to be the person who
tells them if there is any telling that needs doing.
No, we're not. We're basically using pyglet for graphics.
:.
[EMAIL PROTECTED] wrote:
Author: arigo
Date: Mon Mar 31 10:51:44 2008
New Revision: 53194
Modified:
pypy/branch/jit-hotpath/pypy/tool/udir.py
Log:
This logic seems slightly broken - I end up with tons of different
usession names in my /tmp, not just branch names. Anyway I prefer
the
It seems that sentence on a web page saying The binding is created
using the standard (in Python 2.5) ctypes library is simply a lie :(
There is a SWIG binding laying there. There is roughly 20k lines of swig
interface code. Not sure how easy would be to wrap automatically, but
this binding is
what about making flow objspace understand xxx and XXX as global
variables that always raise XxxError() instead of exploding? would
simplify translation greatly.
:.
___
pypy-dev@codespeak.net
http://codespeak.net/mailman/listinfo/pypy-dev
Armin Rigo wrote:
Hi all,
This e-mail is about starting the discussion for ideas and plans about
the next sprints.
What we have planned at the moment:
* The next PyPy sprint is going to be a small one at PyCon
(http://us.pycon.org/2008/sprints/projects/#pypy).
* In Leysin, beginning
I feel a bit clueless about buffer protocol. Current implemntation in
pypy is purely app-level, which means it's slow, but more importantly,
one cannot get raw, C-level address of it. I've tried approaching the
problem, but it seems that there are several serious issues.
* what's the future of
Martin C. Martin wrote:
Hi,
There seems to be a lot of overhead when passing a large string (23 Meg)
to C compiled RPython code. For example, this code:
def small(text):
return 3
t = Translation(small)
t.annotate()
t.rtype()
f3 = t.compile_c()
st = time.time()
z = f3(xml)
Martin C. Martin wrote:
Hi,
I'm really impressed with the C code generated for some functions I'd
like to use in my project. You guys rock!
I've run into two problems this morning. In pypy-1.0.0, this:
import re
import os, sys
from pypy.translator.interactive import Translation
Martin C. Martin wrote:
So it's not possible for RPython to call regular, non-RPython? Is there
some wrapper I could write to let RPython call regular python code?
Not easily. You can call normal python code, provided that you run pypy
interpreter, not cpython. This means that stuff like
Laura Creighton wrote:
snip
This is slightly misleading. There *is* pypy talk (Christians about
stackless) accepted, just not this one.
Cheers,
fijal
:.
___
pypy-dev@codespeak.net
http://codespeak.net/mailman/listinfo/pypy-dev
Maciek Fijalkowski wrote:
Out of getting completely bored, I run svn blame on all .py files which
are svn blameable, excluding unicodedata and pyrepl (which is external)
in pypy directory. Results are here:
http://codespeak.net/~fijal/svnblameall.txt
A little explanation - first column
VanL wrote:
For those who are not aware, Google just launched the Google Highly Open
Participation (GHOP) project. GHOP introduces high-school-age kids to
Open Source by giving them small but meaningful tasks to do.
I have noticed at least one PyPy-related task proposal for GHOP, but I
think
Leonardo Santagada wrote:
Em 29/11/2007, às 18:52, Niko Matsakis escreveu:
Hopefully, these changes will not particularly affect anyone not
actively touching the jvm directory.
Why didn't you did all this changes on a branch, then at least people
would be knowing what you were
As a discussion regarding pypy being production-ready heats a bit, I've
go a practical question:
How useful would be to have app-level ctypes for pypy? Another question
how less useful it would be if it won't provide python-api part (which
would be as easy to provide as C-level bindings for
I've got an issue about distribution lib. I would like to do a bit more
surgery of presented traceback, which needs cutting and sticking it back
together. On top of cpython it's impossible, because this stuff is read
only (you cannot modify tb.tb_next for example). Do we have a good
reason why
Samuele Pedroni wrote:
are you sure this tweak is still correct, I cannot remember the
intention of this code but I'm sure
it was not as it was for random reasons..
I've checked in different version, which does not issue warning only,
but does not change semantics of that.
:.
Armin Rigo wrote:
Hi Fijal,
On Sun, Nov 04, 2007 at 04:01:48PM +0100, Samuele Pedroni wrote:
-thisattrvalue = frozendesc.attrcache[attr]
-except KeyError:
+thisattrvalue = frozendesc.read_attribute(attr)
+except
So, it seems many people liked the blog thing. How about we start a
general PyPy blog where we can all post? Should we try to set
something up on codespeak or just keep using blogspot? The latter
increases the chances that things are happening soon :). Any ideas for
a title?
Raj Bandyopadhyay wrote:
Hi all
Looks like I'm the one with all the complaints :) Thanks for
investigating the Windows issues!
I'm trying to compile pypy-c on a Linux/x86 machine, and running into
all sorts of errors. Following the instructions in the getting-
started document, I
Armin Rigo wrote:
Hi Elmo,
Indeed, it seems that we didn't try --tb=short with app-level tests. It
crashes for me too. Not sure I want to investigate as it seems that
nobody used --tb=short enough to notice so far... It works fine on
interp-level tests.
Armin
Here is proposed diff:
http://paste.pocoo.org/show/6990
I think it doesn't really crash anything (no tests failing), nor has any
performance impact, but who knows...
I would like someone to review that patch.
Basically, half of the time spend in inline helpers is spend in
cleanup_graph, which
Maciek Fijalkowski wrote:
Lenard Lindstrom wrote:
My guess is the pypy-c considers the current directory as its root
directory. This differs from Cpython which uses a registry entry.
The truth is that:
1. We didn't decide yet how to handle interaction with cpython library
Ondrej Certik wrote:
Ok, I'll take a look. Would be cool to have nice and working debian
package, but indeed we're not good in packaging. Also, we would like to
do 1.0 release at some point. The main blocker is some refactorings
to-be-done (some internal unification) and eventually unittest
Ondrej Certik wrote:
Awesome, thanks a lot. Let's do it soon. There are more things -
Kirill (another developer of SymPy) implemented a new feature:
http://code.google.com/p/sympy/issues/detail?id=389
the relevant file is here:
Ondrej Certik wrote:
Hi,
we are using py.test in SymPy and unfortunately, we have some bugs in
SymPy, that occurs when certain tests are run and don't occur when the
tests are run in different order. It's very time consuming to
determine which tests cause the problem (I did that several
Ondrej Certik wrote:
snip
Oh, and by the way. We've got boxed version of py.test (--box or sth,
read --help), which forks for every test, so you're sure that every test
is run in separate environment. (That doesn't solve your problem, but
helps the other way around, when tests are run ok
Elmo Mäntynen wrote:
snip
Solution to the first problem:
class BaseAppTestInheritance:
def setup_class(cls):
pass
def test_foo(self):
pass
class AppTest(BaseAppTestInheritance):
def setup_class(cls):
BaseAppTestInheritance.setup_class.im_func(cls)
Laura Creighton wrote:
It is here:
http://wiki.openmoko.org/wiki/Main_Page
On their wishlist:
http://wiki.openmoko.org/wiki/Wish_List
They say that they are looking for a scripting language. Python
is liked, but they fear it is too big.
see:
Just to let you know, I've moved some modules from rctypes to rffi.
Tests are passing, building should work, but some might encounter
strange issues when using these modules, because not everything is well
tested I think.
I plan to move some other modules, like mmap and _ssl, if noone will
Simon Burton wrote:
Well, I still want to defend this approach...
The idea is:
* ctypes is the API for interfacing with external objects
* genrffi constructs rffi objects by introspecting the ctypes objects
It has nothing to do with rctypes (although it uses ctypes_platform
to find the
As you probably have observed already, for the last few months pypy
is slowly approaching being usable state instead of having more
ultra-cool
features, as we've got enough of them to be willing to use them.
As we're moving towards maintaining pypy as an open source project I would
suggest to
Jakub Gustak wrote:
This is last scheme status report during SoC. So I will sum things up
in the end.
Summarization:
* Interactive interpreter (not RPythonic) lang/scheme/interactive.py
* Can be translated using: translation/goal/targetscheme.py
PyPy Scheme Interpreter features:
* uses
[EMAIL PROTECTED] wrote:
For backup purposes, in-progress: convert more of the os module to rtti
and try to get rid of the rllib.ros module by making the native
interfaces RPythonic. This looks quite good in my opinion - seems that
we've finally learned a reasonable way to do external
Carl Friedrich Bolz wrote:
Maciek Fijalkowski wrote:
Greg Bowyer wrote:
Taking a look at this
http://www.informationweek.com/news/showArticle.jhtml?articleID=201311330pgno=1queryText=
I wonder if the same could be done for pypy (this is just high level
thinking, nothing serious
Greg Bowyer wrote:
Taking a look at this
http://www.informationweek.com/news/showArticle.jhtml?articleID=201311330pgno=1queryText=
I wonder if the same could be done for pypy (this is just high level
thinking, nothing serious)
Look at unununium project (dead for quite a while), they
well, the above code would produce:
extern int foo(int i, int j)
{
return i+j;
}
(and perhaps an accompanying .h file)
thereby providing an interface for other C programs.
This is rffi producing rather than consuming a C interface.
Simon.
Hey Simon.
It's doable, and not
Simon Burton wrote:
On Fri, 3 Aug 2007 12:14:13 -0700
Simon Burton [EMAIL PROTECTED] wrote:
I would like to expose some functions as external
symbols when i build a .so
def foo(i, j):
return i+j
foo._expose_ = [rffi.INT, rffi.INT]
It seems like this could also enable a
http://muharem.wordpress.com/2007/07/31/erlang-vs-stackless-python-a-first-benchmark/
Christian: with a dedication for you :)
We should try pypy on this btw.
:.
___
pypy-dev@codespeak.net
http://codespeak.net/mailman/listinfo/pypy-dev
not sure, if this is of any interest:
http://partial-eval.org/pe-impl.html
list of partial evaluation implementations (mostly scheme, but also C).
Cheers,
fijal
:.
___
pypy-dev@codespeak.net
http://codespeak.net/mailman/listinfo/pypy-dev
I'm approaching how to make cache failures not crash on you every time
you import anything.
So in short, file like ll_os.py looks right now:
if cache.defined('XXX'):
TYPE = cache.inttype(...)
register_external(...)
Idea is that if any of the functions involved in creation of external
Christian Tismer wrote:
On 24.07.2007, at 18:08, Armin Rigo wrote:
Hi Fijal,
On Mon, Jul 23, 2007 at 02:38:32PM +0200, Maciek Fijalkowski wrote:
The length of the arrays in a struct utsname is unspecified; the
fields
are terminated by a null byte (?? ???).
I'm
Amaury Forgeot d'Arc wrote:
Hello,
Maciek Fijalkowski wrote:
Discovered by exarkun. following diff breaks translation
:.
Index: ../../module/posix/__init__.py
===
--- ../../module/posix/__init__.py (revision 45246
From the manpage:
The length of the arrays in a struct utsname is unspecified; the
fields
are terminated by a null byte (’’ ’).
???
I'm completely confused.
:.
___
pypy-dev@codespeak.net
Three guys who's names Jacob doesn't remember were working on flex
backend (reusing JavaScript one to be able to produce flex code and some
libraries). I've got no idea what was their progress (hopefully they're
reading pypy-dev and are able to reply :-)
Cheers,
fijal
:.
Scott Dial wrote:
Greetings Everyone,
I am going to have to stop running the win32 test suite. I am not sure
there is anyone actively correcting problems on win32, so it may be of
no consequence. If someone else is interested in running this, then I
would be more than glad to share my
It's completely unusable.
Usually you end up with Fatal RPythonError in case you try to run stuff.
This is not how we go about stuff! All error reporting should work well
not only on top of js_interactive, but actually on top of js-c as well.
Leonardo - have you even run js_interactive once
Armin Rigo wrote:
Hi Maciek,
On Sat, Jun 30, 2007 at 01:12:57PM +0200, Maciek Fijalkowski wrote:
Just a little correction - you can express c-level constant in lltype.
There is CConstant class for that.
True, although I'm not sure it works for non-integer constants (e.g.
static
Antonio Cuni wrote:
Simon Burton wrote:
I'd like to synchronize with Maciek and Antonio with regards
talking about rpython at EP this year. My talk comes right after
your rpython talk - i think we can perhaps share the burden (joy?)
of talking about rpython a bit.
Hi Simon,
I
Hum. The idea was to keep this stuff in svn in order to keep type
information to-be-copied around. If this is troublesome, I propose to
kill whole idea of having cache-per-platform, since we cannot specify
good platform key and have it in svn:ignore (or move to _cache) and just
keep it on a
Armin Rigo wrote:
Hi Simon,
(This is also a follow-up on concerns raised by Christian on #pypy
today)
On Fri, Jun 15, 2007 at 05:44:54PM -0700, Simon Burton wrote:
I hope we can do all this with rffi, but there are two really
cool things about rctypes:
1) it runs on cpython (our main
I would be very, very careful about what people talk about.
Even if they talk about RPython and speed, they really don't know what
they're talking about. There are some reasons why they use python and
not ocaml or haskell for their purposes. One of the reasons is that it's
easy to write
holger krekel wrote:
On Fri, Jun 15, 2007 at 11:11 +0200, Maciek Fijalkowski wrote:
I would be very, very careful about what people talk about.
quick question: your mail appears in my Mutt as a reply to my
previous mail (Hi Anto, all) but your mail is not meant
as relating
Armin Rigo wrote:
* In RPython, fijal worked on a more basic replacement for rctypes,
called rtti (almost finished already). It's a PyPy-specific interface
to call external functions in RPython. Calls written in this
interface can be compiled to good C code, but testing is a bit less
Maciek Fijalkowski wrote:
I know you're quite tired right now and all, but I think it would be
good to make some kind of pypy-sync next week or even the week after (we
need to decide on sprint topics anyway).
Particularly I would like to know people's opinion on pypy's scope. What
we
I know you're quite tired right now and all, but I think it would be
good to make some kind of pypy-sync next week or even the week after (we
need to decide on sprint topics anyway).
Particularly I would like to know people's opinion on pypy's scope. What
we would like to support, what we
Maciek Fijalkowski wrote:
I've found an unusual problem regarding rctypes - in implementation of
fcntl.ioctl, ioctl
can return a string containing 0 bytes, because the length is somehow
defined. Our rctypes (or implementation itself, I failed to find by now)
assume that string is null
Armin Rigo wrote:
Hi Maciek,
On Tue, May 29, 2007 at 06:44:19PM +0200, Maciek Fijalkowski wrote:
termios.tcgetattr (and others as well) use termios.error for error
reporting, which is exception which cannot be used in a translated
version.
Why not?
Armin
Because than
Is running right now :)
but on branch.
___
pypy-dev@codespeak.net
http://codespeak.net/mailman/listinfo/pypy-dev
I want to wrap termios lib, also for RPython. everything works quite
smooth except error reporting.
termios.tcgetattr (and others as well) use termios.error for error
reporting, which is exception which cannot be used in a translated
version. Hence my ll_termios_tcgetattr raises OSError
Beatrice Düring wrote:
Hi there
Back from Japan and thinking a bit about Europython 2007.
Submission deadline is closing in and I wonder if we are to do any PyPy
talks at EP 2007? I would be prepared to do one PyPy talk on the methodology
- such as an experience summary on how we worked
Alexandre Fayolle wrote:
Hi,
I know pypy builds on macos X, but has anyone tried (and succeeded) to
translate
on a powerpc running Linux? The Debian autobuilders have failed to compile it,
and I wonder if this is an issue in my package or just that this platform is
not
supported.
The
Alexandre Fayolle wrote:
Hi,
I know pypy builds on macos X, but has anyone tried (and succeeded) to
translate
on a powerpc running Linux? The Debian autobuilders have failed to compile it,
and I wonder if this is an issue in my package or just that this platform is
not
supported.
The
Armin Rigo wrote:
Hi Carl,
On Sat, Apr 28, 2007 at 07:56:11PM +0200, Carl Friedrich Bolz wrote:
If another placeof pypy still uses os.open I am strongly
for fixing that.
There is the app-level os.open(), which of course uses the interp-level
os.open(). It means that if a backend
Jakub Gustak wrote:
We can try to organize some kind of mini-sprint in Poland if you like to
introduce you. As far as I know you're living in Wroclaw, I'm passing
through Wroclaw once in a while, so we can arrange one-two days long
coding session if you find it suitable for you.
Well that
Jakub Gustak wrote:
Right now I am doing more research on the subject and getting familiar
with PyPy code base.
The main issue right now is: How to start with PyPy?
http://codespeak.net/pypy/dist/pypy/doc/getting-started.html
is a nice place to start.
I have already went through
Jakub Gustak wrote:
I think, it's about time for me to say hello!
I am in the game for Google Summer of Code. I will be working on
Scheme interpreter/front-end during this summer. Armin Rigo is my
mentor.
Right now I am doing more research on the subject and getting familiar
with PyPy code
Scott Dial wrote:
Scott Dial wrote:
Maciek Fijalkowski wrote:
There is a bug somewhere in the translator.js.test suite
All places should not do this. Hmm... Could you provide more
detailed info? Thanks for spotting.
http://scottdial.com/pypy-dev/translator.js.diff
I'm pinging
Scott Dial wrote:
Greetings,
There is a bug somewhere in the translator.js.test suite that invokes
pygame. I haven't tracked it down but I just thought I'd mention it
because I'm sure someone else will know better than me.
-Scott
All places should not do this. Hmm... Could you
I've written small command line completion to ./translate.py from
pypy/translator/goal. Note: works only from that directory (not sure how
to make in working in general case)
http://codespeak.net/svn/user/fijal/completetranslate.py
___
John Smith wrote:
Hi list,
I'm fairly new to pypy and was only doing some experimenting with the
javascript translator so far. First of all let me say that the whole
project is pretty amazing!
After translating a couple of functions I tried translating a class,
but was unsuccessful so
John Smith wrote:
I'm fairly new to pypy and was only doing some experimenting
with the
javascript translator so far. First of all let me say that the
whole
project is pretty amazing!
After translating a couple of functions I tried translating a
class,
I've implemented recently an addition, which allows to have cleanur
conftest.py setup.
Basically, conftest.py's dist_rsyncroots affects only directory where it
is located,
so in let's say pypy's parent dir you might have conftest.py with
dist_rsyncroots = ['py', 'pypy', 'lib-python']
and in
Elmo Mäntynen wrote:
Martijn Faassen wrote:
Hi there,
I've noticed for a while now that the following page is down:
http://snake.cs.uni-duesseldorf.de/pypytest/benchmark.html
It's listed here:
http://codespeak.net/pypy/dist/pypy/doc/index.html
I thought I'd post a message here in case
Niko Matsakis wrote:
As well as some of your commits have broken JS tests. I'm not totally
convinced that my attempt (returning void) is better than your (not
returning void), but please at least run JS tests and check if nothing
is broken. If you brake something, but you're totally convinced
Carl Friedrich Bolz wrote:
Maciek Fijalkowski wrote:
Niko Matsakis wrote:
As well as some of your commits have broken JS tests. I'm not totally
convinced that my attempt (returning void) is better than your (not
returning void), but please at least run JS tests and check if nothing
As well as some of your commits have broken JS tests. I'm not totally
convinced that my attempt (returning void) is better than your (not
returning void), but please at least run JS tests and check if nothing
is broken. If you brake something, but you're totally convinced that I'm
the one who
Simon Burton wrote:
Traceback (most recent call last):
File /home/simon/bin/py.test, line 4, in ?
py.test.cmdline.main()
File /home/simon/local/pypy/py/test/cmdline.py, line 17, in main
failures = session.main(args)
File /home/simon/local/pypy/py/test/terminal/terminal.py, line 34,
Right now, b'n'b JS client should be almost playable. Speed and key
granularity is still an issue, but there should be no problems with
zindex and all other problems. Enjoy.
___
pypy-dev@codespeak.net
http://codespeak.net/mailman/listinfo/pypy-dev
There were some updates recently about JS backend.
Recently:
- Added some decorator which might be usefull at declaring server-side
of AJAX communication
- Polished a little bit backend so now it is able to run richards and
pystone as soon as you cut off zeroing assumption out of
Maybe that's a little bit late, but I've got broadband finally.
I would like to thank all of pypy team for helping me with my SoC.
___
pypy-dev@codespeak.net
http://codespeak.net/mailman/listinfo/pypy-dev
I've been wondering for some time why there is no support for pure
functional types. Like function int - int. In most type inference
techniques, there is. I know, side effects. But usually we can tell that
function has no side effects at all, so it would be nice to reduce it to
lambda type,
82 matches
Mail list logo
