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 a
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.
:.
Beatrice During wrote:
> Hi there
>
> Just checking to see how things went with the sprint
> plans?
>
> Cheers
>
> Bea
>
The didn't
:.
___
pypy-dev@codespeak.net
http://codespeak.net/mailman/listinfo/pypy-dev
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 i
[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 pref
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, b
[EMAIL PROTECTED] wrote:
>
> Hi,
>
>
>
> The question I was going to ask is “are you working with Thomas Heller
> on the ctypes port?” It seems to me he would be able to sort out a lot
> of you lifetime / conversion questions very quickly? Have you tried to
> contact him before?
>
>
>
> Chee
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:
> In RPython, you can't call into other libraries, be they C or Python.
> Also, calling RPython from Python is "pretty unofficial and
> unsupported." Given that much of modern programming centers around
> connecting various libraries together, this makes RPython a poor c
> Thanks, but I'm not trying to write a standalone program, I need to
> call some 3rd party libraries. For example, the string comes from one
> of a couple dozen of socket connections, managed by Twisted. So I
> just want my inner loop in RPython. The inner loop turns XML into a
> MySQL sta
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
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 lik
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 Translati
Laura Creighton wrote:
>
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
Christian Tismer wrote:
> Maciek Fijalkowski wrote:
>> 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 di
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 e
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
:.
___
pypy-dev@codespeak
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
>
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
Martijn Faassen wrote:
> Maciek Fijalkowski wrote:
>
>> 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 usef
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 CPy
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
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)
>>> +
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.
:.
> It's probably a bit much for a four week project, but both Anto Cuni
> (the author of the CLI backend and general PyPy contributor) and me
> could mentor you a bit, if you feel like it.
>
> Anyway, that's just one idea, we can also think of others, if you tell
> us a bit more about your inter
> 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? pypy.blogspo
Raj Bandyopadhyay wrote:
> Hmm, I have installed the gc already, but maybe the library path is
> not set correctly. lemme try changing that & I'll let you guys know
> what happens.
>
> Thanks
> Raj
Libgc might be there, but header aren't (developement version of lib)
:.
Raj Bandyopadhyay wrote:
> Ok, the compilation failed after quite a while. I have attached the
> output file of the compilation process. It seems to have failed on
> some simple C undeclared-variable error.
>
> Thanks
> Raj
>
You don't have boehm (devel version) installed. Install it, go to
/tmp
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,
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 y
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
(use the same place, use different place,
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
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
>
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 unit
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:
>
> http://sympy.googlecode.com/svn/trunk/sympy/utilities/p
Ondrej Certik wrote:
>
>
>
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 o
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
Elmo Mäntynen wrote:
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)
(im_func i
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: http://wiki.openmoko.org/wiki/Wish_
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
sto
> Hi friends,
>
> to what extent has this been discussed?
> If this change is not commonly approved,
> then I'm asking you to change it to a proposed
> addition to the cleanup list, but open for
> discussion.
> This is public information, and before things
> are decided upon, I dislike to see misl
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
I'll be probably completely offline for like next 4 weeks, starting from
monday.
Cheers,
fijal
:.
___
pypy-dev@codespeak.net
http://codespeak.net/mailman/listinfo/pypy-dev
Simon Burton wrote:
> On Thu, 23 Aug 2007 19:13:26 +0200
> Maciek Fijalkowski <[EMAIL PROTECTED]> wrote:
>
>
>> You need to create the structure which you push by hand. As well as
>> array argument.
>>
>
> No, structure comes from a call t
Simon Burton wrote:
> On Wed, 22 Aug 2007 15:23:40 -0700
> Simon Burton <[EMAIL PROTECTED]> wrote:
>
>
>> Following some hints from Samuele, I am trying to wrap such functions in
>> another function that does some casting.
>>
>
> Here is the latest:
>
>
> def softwrapper(funcptr, arg_tps):
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:
[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 func
Carl Friedrich Bolz wrote:
> Maciek Fijalkowski wrote:
>> Greg Bowyer wrote:
>>> Taking a look at this
>>> http://www.informationweek.com/news/showArticle.jhtml?articleID=201311330&pgno=1&queryText=
>>>
>>>
>>>
>>&g
Greg Bowyer wrote:
> Taking a look at this
> http://www.informationweek.com/news/showArticle.jhtml?articleID=201311330&pgno=1&queryText=
>
> 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),
> 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 doabl
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
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
Can we move jit tests to the end of nightly test run?
It'll help quick-checking whether there are no breakages spread all around.
Cheers,
fijal
:.
___
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
(c
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
>>> fi
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
http://codespeak.net/mailman/listinfo/pypy-
Amaury Forgeot d'Arc wrote:
> Hello again,
>
>> Author: fijal
>> Date: Mon Jul 23 13:52:26 2007
>> New Revision: 45269
>>
>> Modified:
>>pypy/dist/pypy/rpython/module/ll_os.py
>>pypy/dist/pypy/rpython/module/test/test_posix.py
>> Log:
>> Add os.uname. RPython level. segfaults ll2ctypes in s
>
>> Lastly, what is the easy approach to I/O and external functions?
>>
>
> the easy approach is to forward the external functions to the backend,
> which will take care of rendering them as appropriate (usually by
> calling an helper function written in java). This approach is already
> u
Amaury Forgeot d'Arc wrote:
> Hello,
>
> Maciek Fijalkowski wrote:
>> Discovered by exarkun. following diff breaks translation
>>
>> :.
>>
>>
>> Index: ../../module/posix/__init__.py
>> =
Discovered by exarkun. following diff breaks translation
:.
Index: ../../module/posix/__init__.py
===
--- ../../module/posix/__init__.py (revision 45246)
+++ ../../module/posix/__init__.py (working copy)
@@ -83,6 +83,9 @@
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 m
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 bef
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 no
Jakub Gustak wrote:
> I that case error messages from pylint:
> E:142:add_lst.: Using unavailable keyword 'lambda'
> E:145:mul_lst.: Using unavailable keyword 'lambda'
>
> Causes only confusion.
>
>
I would not trust pylint too much. being rpython is quite complex issue.
and trying to be rpytho
Armin Rigo wrote:
> Hi Richard,
>
> On Wed, Jun 27, 2007 at 01:55:13PM -0700, Richard Emslie wrote:
>
bytecode that genllvm produces would then call the helper functions
instead of calling directly the external C API. Shouldn't be a
performance problem as llvm will inline the hel
Martijn Faassen wrote:
> Hi there,
>
> I posted this to a longer thread the other day but have received no
> answers to it whatsoever. Perhaps it got lost, so I'll do a repost. I
> spent a bit of time writing this post, and I ask some questions in it
> that I think should be answered. Perhaps by
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.
>>
>
>
> H
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 pla
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 cpytho
Simon Burton wrote:
> On Thu, 14 Jun 2007 18:45:54 +0200
> Armin Rigo <[EMAIL PROTECTED]> wrote:
>
>
>> Any comments or objections? Are there people that already make heavy
>> use of rctypes, or the extension compiler?
>>
>
> Indeed. Mainly rctypes.
>
> As well as an ever expanding use of
Martijn Faassen wrote:
> Maciek Fijalkowski wrote:
>
>> 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.
>>
>
> I understa
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&qu
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 well-wo
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 les
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 opin
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 would
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.
&g
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
Is running right now :)
but on branch.
___
pypy-dev@codespeak.net
http://codespeak.net/mailman/listinfo/pypy-dev
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 terminated. The unusual thing about
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
instead
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 wor
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.
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.
Carl Friedrich Bolz wrote:
> Hi Anto!
>
> Antonio Cuni wrote:
> > I agree, and this is why I mentioned the problem :-).
> >
> > I think there are two ways to make it working:
> >
> > 1) write a dummy CliFile (or JvmFile) subclass of stream, then
> > special-case that class in the backend to
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
Also a note from my side:
Would be cool to have config option to turn off weakrefs (and some
functionallity provided by them, like subclasses). I trimmed (same as
Antonio) weakref from the interpreter and shouldn't be hard and maybe
will allow to translate whole pypy on js backend (well, not re
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.
>
> Wel
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 alrea
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 Py
Scott Dial wrote:
> Maciek Fijalkowski wrote:
>> Ok, I'm coming back to issue. I didn't find on windows status page
>> any failures related to that :-(
>>
>> Could you point me to some?
>> Also seems that examples doesn't work on windows. Bad.
&g
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.
>
Scott Dial wrote:
> Armin Rigo wrote:
>
>>> Tentatively checked in, though it's not my area of expertise :-)
>>>
>> Uh, I just realized that many tests fail after the use_pdb argument is
>> removed, because they try to pass one anyway. Could you provide a more
>> complete patch? Thanks!
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 yo
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
___
pypy-dev@codesp
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
1 - 100 of 116 matches
Mail list logo
