Re: [pypy-dev] Poor performance for Krakatau

Hi Robert, On 10 November 2014 at 05:27, Maciej Fijalkowski wrote: > I've been looking at krakatau performance for a while, it's almost > exclusively warmup time. We are going to address it, I hope rather > sooner than later :-) We added Krakatau to the official benchmark suite. It turns out no

Re: [pypy-dev] Experiments with PyPy and libgccjit

Hi, On 13 December 2014 at 13:59, Maciej Fijalkowski wrote: > * Can libgcc tell us where on stack are GC roots? (also necessary) This constraint can be relaxed nowadays: it's enough e.g. if we tell gcc to reserve register %rbp to contain the jitframe object. That's the only GC root that's reall

Re: [pypy-dev] Getting rid of "prebuilt instance X has no attribute Y" warnings

Hi Timothy, On 9 December 2014 at 06:01, Timothy Baldridge wrote: > I'm getting a ton of these sort of warnings. They seem to go away when I > either a) type hint the object via assert (gross) or b) access the attribute > via a getter method. Is there a better way? Would there be a problem with >

[pypy-dev] Some work on virtualenv

Hi all, Some work started on the virtualenv refactoring that some people here might be interested to hear about: https://github.com/pypa/virtualenv/pull/691 A bientôt, Armin. ___ pypy-dev mailing list pypy-dev@python.org https://mail.python.org/mailm

Re: [pypy-dev] minor question about configure.Works()

Hi Matti, Do you mean ./rtyper/tool/rffi_platform.py, class Works? A bientôt, Armin. ___ pypy-dev mailing list pypy-dev@python.org https://mail.python.org/mailman/listinfo/pypy-dev

[pypy-dev] Fwd: [Python-Dev] More compact dictionaries with faster iteration

Hi all, About ordered dictionaries: -- Forwarded message -- From: Armin Rigo Date: 3 January 2015 at 17:39 Subject: Re: [Python-Dev] More compact dictionaries with faster iteration To: Maciej Fijalkowski Cc: Serhiy Storchaka , "" Hi all, On 1 January 2015 at 14:

Re: [pypy-dev] Thank You Matti Picus AND I may have some new questions —— bitpeach from china

Hi, On 14 December 2014 at 08:52, 思 <958816...@qq.com> wrote: > (1) I check the VirtualEnv version list and the 1.11.6 is the latest > by this URL . There > is no newer version than that. It means that 1.11.6 version is the newest > and no v

[pypy-dev] Ordered dict in PyPy

Hi all, The all-ordered-dicts branch is not quite ready for merging, but getting there. In one word, it makes all dicts ordered by default, by a subtle change of the internal model which also makes them *more* compact. An annoying detail is the OrderedDict subclass. We can simplify it a lot in P

Re: [pypy-dev] Ordered dict in PyPy

Hi Laura, On 11 January 2015 at 19:57, Laura Creighton wrote: > Can we talk the CPython developers into raising RunTimeError for > concurrent modifications? No, we can't expect them to change that: http://bugs.python.org/issue19414 shows they have no plan to have well-defined behavior (either Ru

Re: [pypy-dev] can_enter_jit - what is it and did something change?

Hi Yuriy, On 11 January 2015 at 23:38, Yuriy Taraday wrote: > - Did something change wrt can_enter_jit since that code had been written? I > mean besides check that raises that error [3]. No. There are probably cases where that check fails but the code was still correct; I bet it was the case i

Re: [pypy-dev] Ordered dict in PyPy

Hi all, Thanks for the feedback. It looks like the general opinion is to raise RuntimeError when detecting changes. I'll do that then. About '__reversed__', I suppose it should be implemented the same way, with an RPython-provided iterator which raises RuntimeError too. A bientôt, Armin. ___

Re: [pypy-dev] can_enter_jit - what is it and did something change?

Hi Yuriy, See the old explanation about our JIT here: rpython/doc/jit/pyjitpl5.rst. What changed from this old explanation is that if no can_enter_jit is found in the source code, one is automatically inserted just before the jit_merge_point. About your other questions: > - Is it correct to not

[pypy-dev] Next sprint in Leysin, Switzerland (20-28 Feb 2015)

t least one EU-format power strip. ---- Armin Rigo ___ pypy-dev mailing list pypy-dev@python.org https://mail.python.org/mailman/listinfo/pypy-dev

Re: [pypy-dev] Sudden failures during compile-c

Hi Timothy, On 20 January 2015 at 15:59, Timothy Baldridge wrote: > I find this odd as it works just fine without the JIT, and compiles fine on > OS X. The code in question is basically a copy-and-paste from PyPy's code: > https://github.com/pixie-lang/pixie/blob/master/pixie/vm/threads.py#L90 M

Re: [pypy-dev] Sudden failures during compile-c

Re-hi, On 20 January 2015 at 16:04, Armin Rigo wrote: > Maybe related: there is a copy mistake in after_external_call(). It > should not call the get/set_saved_errno() functions. Also, did you mean "_cleanup_()" instead of "__

Re: [pypy-dev] Numpy Topics

Hi Dan, On 21 January 2015 at 03:19, Dan Stromberg wrote: > It includes a pure-python version of timsort, among others. There is one in PyPy too. Kind of obvious, in fact: we need one for implementing `list.sort()`. I think the original question was instead very numpy-specific: it refers, I gu

Re: [pypy-dev] Sudden failures during compile-c

Hi Timothy, On 21 January 2015 at 02:07, Timothy Baldridge wrote: > I switched all builds to use shadowstack and the > build error goes away. So I guess that was the issue. Can you tell us how to reproduce anyway? It's strange that you get this problem, because a "void pypy_g_do_yield_thread_re

[pypy-dev] OrderedDict.move_to_end()

Hi all, About the new OrderedDict and how to support `move_to_end(last=False)` in the py3k branch: an implementation of the correct complexity is possible. It would piggy-back on the part of `lookup_function_no` that acts as counter for how many entries at the start are known to be deleted. This

Re: [pypy-dev] Numpy Topics

Hi Steven, On 21 January 2015 at 13:00, Steven Jackson wrote: > Am I right in assuming that I should checkout "default," make my own branch, > write failing test cases, make the test cases succeed (occasionally merging > in default) and then... Yes, you're right up to here :-) The point is that

[pypy-dev] errno and GetLastError in RPython

Hi all, I recently merged the "errno-again" branch. This branch moves the reading/saving of errno (and on Windows Get/SetLastError) closer to the actual function call. It should avoid bugs about rarely getting the wrong value for errno, in case "something special" happened: for example, it was n

Re: [pypy-dev] RFC: Copy-on-write list slices

Hi Mike, On 20 January 2015 at 05:26, Mike Kaplinskiy wrote: > https://bitbucket.org/mikekap/pypy/commits/b774ae0be11b2012852a175f4bae44841343f067 > has an implementation of list slicing that copies the data on write. (The > third idea from http://doc.pypy.org/en/latest/project-ideas.html .) One

Re: [pypy-dev] rpython and pep 484

Hi, On 25 January 2015 at 00:05, Ho33e5 wrote: > What is your view on the new typing/mypy things that are happening on > python-dev > (pep 484)? What I mean is will this make the typing system of rpython evolve? > Could > RTyper be adapted to work on pep 484 annotations (would it actually be >

Re: [pypy-dev] starting 2.5 release cycle, help needed with macos

Hi all, On 29 January 2015 at 06:22, Matti Picus wrote: > We have a persistent crash with macos nightly builds in the _continuation > module, help is needed to track it down I am willing to look into this bug provided someone provides an OS/X machine where I can log in and run gdb. It just happ

Re: [pypy-dev] PyPy improving generated machine code

Hi Richard, On 31 January 2015 at 10:51, Richard Plangger wrote: > By using the PEP 484 proposal I think this opens up new possibilities. The short answer is - no, it doesn't make sense. User-supplied type annotations wouldn't help at all if they must still be checked, like PEP 484 says. Or, a

Re: [pypy-dev] pickle in pypy is slow

Hi, On 31 January 2015 at 20:43, Luciano Ramalho wrote: > On Sat, Jan 31, 2015 at 4:32 PM, Gelin Yan wrote: >> I noticed pickle in pypy is slower than cPickle in python (faster than >> pickle in python). >> >> Is it a feature? > > the feature is that nobody had to write it in C, yet i

Re: [pypy-dev] how to register to sprint in Leysin, Switzerland

Hi Sik, On 2 February 2015 at 15:46, Sik wrote: > A friend of mine and I would like to join during the sprint in Leysin. We > are researchers in computer vision (with a background in computer science) > who happen live to be close enough to join the sprint. Welcome ! The sprint is turning out t

Re: [pypy-dev] how to register to sprint in Leysin, Switzerland

Hi Sik, On 2 February 2015 at 17:50, Sik wrote: > We live close, but not that much ;) I guess that we'll try to find a place > at the Chalet. (In this manner we can jump early out of bed to go for > skimo). > We were waiting to see if we could come. Now I think is time to book the > room ;) Other

Re: [pypy-dev] PyPy improving generated machine code

Hi Richard, On 2 February 2015 at 17:56, Richard Plangger wrote: > Sorry to bother again. I did not get any response yet. The problem is > that I need a better picture about a topic I could work on for my thesis > and I really would like to contribute to pypy. In this week I would like > to decid

Re: [pypy-dev] Windows: pypyw.exe?

Hi, On 4 February 2015 at 20:04, Matti Picus wrote: > When you say "it is just a hassle" that leads me to believe you already know > how to fix it (Hint: |cl /subsystem:windows|) It's probably as easy as tweaking the generated Makefile, to call once "cl" and once "cl /subsystem:windows" to make

Re: [pypy-dev] A question about RPython's JIT in scheduler

Hi, For future reference: we discussed this question on IRC yesterday, Feb 4th (see logs). Let me repeat here the main answer: the JIT works well because you're using a scheme where some counter is decremented (and the soft-thread interrupted when it reaches zero) only once in each app-level loop

Re: [pypy-dev] Windows: pypyw.exe?

Hi, On 6 February 2015 at 11:15, Amaury Forgeot d'Arc wrote: > This has other implications. > For example, sys.stdout points to an invalid file descriptor, > and I remember that old versions of pythonw.exe used to freeze after > printing 8192 characters. I'm not finding anything special done wit

Re: [pypy-dev] [pypy-commit] pypy default: Rename the --output option to --really-force-output, and document it

Hi Fijal, On 6 February 2015 at 09:54, Maciej Fijalkowski wrote: > This change breaks places that recommend you to use --output (e.g. > check that you're not translating with the same executable) Grepping for "--output", I can find only translate.py that says "use --output=..." so I'll guess you

[pypy-dev] Fwd: [pypy-commit] pypy default: Rename the --output option to --really-force-output, and document it

Hi Tobias, (answering an off-list-by-mistake mail) On 6 February 2015 at 13:50, Tobias Pape wrote: > So this is changed in rpython for a pypy issue? Yes, someone else made the same point on IRC. I have now reverted this change, and added a check to "targetpypystandalone.py" that you don't try

[pypy-dev] Another idea for improving warm-up times

Hi all, Here's an idea that came up today on irc (thanks the_drow_) while discussing again saving the generated assembler into files and reloading it on the next run. As you know we categorize this idea as "can never work", but now I think that there is a variant that could work, unless I'm missi

Re: [pypy-dev] Playing with PyPy and Django

Hi Tin, Also, not an answer, but unlike what your mail implies we didn't release a new version of PyPy 3 the other day --- only PyPy 2. It's not an answer because it should not be much slower. The problem is probably with some PyPy-3-specific optimizations that are lagging behind PyPy 2's (altho

Re: [pypy-dev] Another idea for improving warm-up times

Re-hi, In fact, after more discussion on irc, it seems that we can (almost or completely) decide "we can reuse this saved trace" like this: "if we trace it again, we follow the same path in the jitcodes". Indeed, this path implicitly encodes all the relevant information, like which Python opcodes

[pypy-dev] Leysin Sprint location

Hi all, If you're coming back to Leysin for the sprint at the end of February: warning, the main entrance to the two chalets Ermina was moved from the upper chalet to the lower chalet. In case you need it, here's a map showing how to go to the lower chalet (red marker) when you're standing in fro

Re: [pypy-dev] numpy installation

Hi Yichao, On 11 February 2015 at 14:09, Yichao Yu wrote: > Also from here[1] > Which includes the fix you have to do for system installation. > > [1] https://bitbucket.org/pypy/numpy Ah, thanks. I'll add the mention of the fix to the pypy.org/install.html page and clarify what you get by click

Re: [pypy-dev] could it be that cpyext is faster than python + cffi?

Hi Matti, On 13 February 2015 at 14:46, Matti Picus wrote: > I am close to releasing a blog post about numpy.linalg A comment: saying "In order to test it out, download PyPy 2.5.0 or later, and install the pypy version of numpy" in the conclusion is, in my opinion, both too late and not precise

Re: [pypy-dev] could it be that cpyext is faster than python + cffi?

Hi Matti, On 14 February 2015 at 17:44, Matti Picus wrote: > That makes sense, thanks. I will see if I can easily reuse the c code as a > shared object rather than a module, and what effect that has on timing. Note that it's what ffi.verify() is for: you add any amount of custom C code there.

Re: [pypy-dev] GSoC 2015

Hi Rohan, On 15 February 2015 at 21:23, Rohan Goel wrote: > I am Rohan Goel , Computer Science undergraduate at BITS Pilani , India > and am interested in working for your organization in GSoC 2015. As I am a > beginner in open source coding , it would be great help if you guide me > where to s

Re: [pypy-dev] Fwd: pypy memory test

Hi Christian, On 15 February 2015 at 21:36, Christian Walder wrote: > I seem to be running into a problem with freeing memory. The problem you have, as I understand it, is that the OS-visible size of the process goes up but not down. This is expected. I don't really know why OS/X versus Linux

Re: [pypy-dev] contribute in the project

Hi! On 17 February 2015 at 17:16, Ahmed Abdalrahman wrote: > my name is Ahmed , > i want to join u and i am interested in open > source what ever your will join google summer of code or not > i want to coding , trying to learn and help you if i can please tell me, W

Re: [pypy-dev] Vectorizing numpy traces

Hi Bengt, On 25 February 2015 at 15:20, Bengt Richter wrote: > Maybe it's worth a re-think, if only to say "no, we really mean no" in the > FAQ ;-) It's unclear to me if you're suggesting something more than adding a checkpointing system to stop and restart the process. It's a hack that might w

Re: [pypy-dev] GSoC 15 vectorizing traces

what we say in general to people that want to contribute to PyPy. We can move on to discuss GSoC only after we have seen concrete results from this first step. Armin Rigo ___ pypy-dev mailing list pypy-dev@python.org https://mail.python.org/mailman/lis

Re: [pypy-dev] trsnslating pypy to another language besides C

Hi Joonas, To make sense out of it, you would need an "ootype" backend, as opposed to a "lltype" backend which generates C-like code. Google for Antonio's thesis "High performance implementation of Python for CLI/.NET with JIT compiler generation for dynamic languages". But we killed support for

Re: [pypy-dev] trsnslating pypy to another language besides C

Hi Ryan, On 4 March 2015 at 19:48, Ryan Gonzalez wrote: > Not necessarily. I figured that a C++ target might look a tad nicer because > it has built-in objects and exception handling. Yes, this might be true for the static backend. However, the JIT integration would be extremely painful. To ha

Re: [pypy-dev] [pypy-commit] pypy vmprof: uh

Hi Fijal, On 9 March 2015 at 09:21, Maciej Fijalkowski wrote: > uh, I really don't think this checkin is correct (it was meant to seek > to the end, not 2 bytes) >> -ec.code_info_file.seek(2, 0) >> +ec.code_info_file.seek(0, 2) Sorry, I may be missing something, but it seems to

Re: [pypy-dev] culling non-functional build slaves

Hi Yuriy, Looking at the situation Matti describes where some buildslaves have not been running for months, it seems that nobody was really interested in looking at the results enough to care about sending a mail to their owners... So while we do appreciate some buildslaves, and they are not a bu

Re: [pypy-dev] Language Parser Ontology

Hi, On 16 March 2015 at 12:01, anatoly techtonik wrote: > Yes, but developing a new language in RPython requires choosing a > parser first, no? No. Some of RPython's interpreters are only interpreters, without any parser. I'm not saying yours must be too, but in general we tend not to be too i

Re: [pypy-dev] GSoC 2015: Implement copy-on-write list slicing

Hi Tushar, In the past few years, we have found GSoC to be tricky to handle. As a result of this, we're likely to have a high bar for student acceptance this year. The main criteria will be whether you have already contributed to PyPy in a significant way. If you only come up with a GSoC propos

Re: [pypy-dev] Specialization for app level types

Hi Timothy, On 21 March 2015 at 01:43, Timothy Baldridge wrote: > I'd like to add some optimization to app level types in Pixie. What I'm > thinking of is something like this (in app level PyPy code): There was some experiment in the PyPy branch 'type-specialized-instances' (in 2011-2013). The

Re: [pypy-dev] Compiling PyPy interpreter without GC

Hi Kunshan, On 20 March 2015 at 04:16, Kunshan Wang wrote: > (...) Others (including PyPy) build a whole new VM, > doing everything from scratch. There are many "high-performance VM" > projects like PyPy (LuaJIT, v8, JavaScriptCore, HHVM to name a few), but > the most important low-level parts (J

Re: [pypy-dev] UTF8 string passing in cffi and PyPy internal string optimizations

Hi, On 18 March 2015 at 15:49, Amaury Forgeot d'Arc wrote: > 2015-03-17 18:27 GMT+01:00 Eleytherios Stamatogiannakis : >> Right now when PyPy receives a utf8 string (from a C function) it has to >> do 2 copies: >> >> 1. convert the cdata string to a pypy byte string via ffi.string >> 2. convert f

Re: [pypy-dev] Release 2.5.1 is close, please help test

Hi, On 22 March 2015 at 13:31, anatoly techtonik wrote: > Looks like there is a regression in pypy-2.5.0 since 2.4.0 in virtualenv > https://github.com/pypa/virtualenv/issues/725 That's because pypy comes with a shared library since 2.5. I'll leave it to virtualenv people to decide if they need

Re: [pypy-dev] Mod typing error

Hi Timothy, hi Ryan, On 28 March 2015 at 00:00, Ryan Gonzalez wrote: > I don't know much about RPython internals, but PyPy calls > rpython.rtyper.lltypesystem.module.ll_math.math_fmod for modulus operations > on floats. Yes, "%" on floats is not supported. You should use math.fmod() in RPython.

[pypy-dev] Allegro64 buildslave disappeared

Hi all, The allegro64 buildslave seems to have definitely disappeared last week, with no warning to most of us. It used to run the nightly 64-bit Linux translations and tests. Do we have another Linux machine available? Armin ___ pypy-dev mailing lis

Re: [pypy-dev] gcc recommendation for pypy 2.5.0

Hi Roshan, On 6 April 2015 at 05:44, Roshan Cherian wrote: > Could I know the > recommended gcc version for building pypy 2.5.0. Any version that is not seriously outdated would do. I guess 4.1 is too old. We don't specifically try out every single old version of gcc so I can't be more precise

Re: [pypy-dev] FAQ entry

Hi Yuriy, (2) cannot be done in Python without major changes in semantics. User code that makes no use of threads, for example, certainly doesn't expect to be careful about multithreading in the __del__ methods. (1) is hard too. What is hard is to decide when acquiring a lock in a __del__ is sa

Re: [pypy-dev] FAQ entry

Hi Maciej, On 6 April 2015 at 21:08, Maciej Fijalkowski wrote: > My question stands - should we add this short explanation (maybe with > a link to the blog post) to FAQ as to why you should not use locks in > dels? My problem with the blog post is that, after it correctly diagnoses the problem,

Re: [pypy-dev] FAQ entry

Hi Yuriy, On 7 April 2015 at 16:00, Yuriy Taraday wrote: >> We can't even be sure that an actual deadlock situation encountered in >> a __del__ is really a deadlock; maybe a different thread will come >> along and release that lock soon... I think this is a problem that is >> just as hard as the

Re: [pypy-dev] FAQ entry

Hi Fijal, On 7 April 2015 at 20:14, Maciej Fijalkowski wrote: > Are you sure this is true for the case where object is found inside a > cycle? (these days, they're run, not sure if in 2.7 or 3.x) Ah, you're right. There is always the case where objects are reachable from a cycle (even if they a

Re: [pypy-dev] FAQ entry

Hi Yuriy, It seems that now you've understood the problems, so please re-read my previous answers :-) In particular, I try to give a situation where even what looks like a deadlock might not be one (because any thread can release any lock), and why we can't always run finalizers in a separate thr

Re: [pypy-dev] FAQ entry

Hi Yuriy, On 8 April 2015 at 10:47, Yuriy Taraday wrote: > will end up executing them. So my argument is: why not make it clear that > __del__ will run in a separate thread instead of trying to pretend that it's > something more predictable than that? For example, because it would break this cla

Re: [pypy-dev] FAQ entry

Hi, On 8 April 2015 at 11:43, Yuriy Taraday wrote: > It's already broken if it's used in multithreaded app. For single-threaded > apps we can make an exception and keep things running as they are now, i.e. > keep it single-threaded. This will also prevent unnecessary multithreading > initializati

Re: [pypy-dev] FAQ entry

Hi, On 8 April 2015 at 13:35, Yuriy Taraday wrote: > That would be creating new references to self in __del__ which is bad (at > least docs say so). And after that these references will be gone once again > and __del__ will be called again. No, in PyPy it is fine, but indeed it is a problem in C

[pypy-dev] EuroPython?

Hi all, I'm preparing a EuroPython submission about STM and/or about CFFI, and wondering if someone else also planned to submit a talk. If not, I'll include a general "status of PyPy" part in my submission. Armin ___ pypy-dev mailing list pypy-dev@pyth

Re: [pypy-dev] EuroPython?

Hi, On 11 April 2015 at 11:29, Antonio Cuni wrote: > my plan was to submit a talk about profiling/optimizing, possibly together > with fijal if he comes (but I didn't do yet :)). > Probably the talk which suits best for talking about the general status is > Romain's one? I just submitted http://

Re: [pypy-dev] PyPy translation on Xeon Phi (pka MIC)

Hi Ajit, On 11 April 2015 at 20:00, Ajit Dingankar wrote: > It failed due to a "safety check" related to asserts at the end of > the translate module. We can't help from this vague description. Please give at least the complete error message. Officially, supported platforms are Linux, Windows

Re: [pypy-dev] http://speed.pypy.org/timeline/ -- show the code?

Hi Laura, On 12 April 2015 at 14:46, Laura Creighton wrote: > I thought there was a way to show the code that was actually run to get > the results. Maybe I am confusing things with the pshootout site. Have > I just forgotten how to do this? Yes, there is a way: from a page that shows one grap

Re: [pypy-dev] Which pypy with >=3.3 Python compatibility

Hi Ludovic, On 13 April 2015 at 19:03, Ludovic Gasc wrote: > FYI, I'm trying to implement monotonic timer in PyPy3.3 during PyCON sprint > code, Benoît Chesneau finds me an example: Fwiw, clock_gettime() and similar functions are already present in PyPy2 in the module ``__pypy__.time``. I didn'

Re: [pypy-dev] Porting PyPy/rpython to Python 3

Hi, I have kept quiet on this issue, but I'd like to mention that I'm not looking forward at all --but would accept it anyway if others deemed it a good idea-- to have to write all my code in all of "rpython/" in the restricted style of 2+3 mixed-mode code bases. This might create a source of fri

Re: [pypy-dev] Porting PyPy/rpython to Python 3

Hi VanL, On 17 April 2015 at 23:50, VanL wrote: > I am not trying to force you (or anyone) to use Py3. I have been working on > this in a private branch for a little bit, and I am happy to continue to do > so. As I said earlier in the thread, I had gotten the impression that these > changes would

Re: [pypy-dev] Porting PyPy/rpython to Python 3

Hi Ronan, On 19 April 2015 at 19:49, Ronan Lamy wrote: > Well, I think that the only sane way to port something as big as RPython is > to do it incrementally - by getting tests to pass on 3 one subpackage at a > time. The parts that are ported will have to be written in mixed 2/3 style, > but hav

Re: [pypy-dev] Porting PyPy/rpython to Python 3

Hi Laura, On 20 April 2015 at 11:53, Laura Creighton wrote: > I worry that this will be slow. Slow at which level? The final speed of some translated PyPy should not be influenced, but maybe translation itself can become slower. But then it would be good motivation to do performance improvement

Re: [pypy-dev] Porting PyPy/rpython to Python 3

Hi Laura, On 20 April 2015 at 12:18, Laura Creighton wrote: > I was worried about translation speed. Ok. Then yes, I think there should be little intrinsic reason for it to be slower (apart from some bytes/unicodes changes, which should not be too important in this case), and it would be a good

Re: [pypy-dev] Porting PyPy/rpython to Python 3

Hi Laura, On 20 April 2015 at 12:45, Laura Creighton wrote: > Sounds to me as if you are talking youself into it. ;) I'm not. I'm talking myself into thinking it would be the most approachable route (which can of course be wrong). But I'm not looking forward to what would come next: once we ha

Re: [pypy-dev] [pypy-commit] pypy default: Detect objects with h_tid==-42

Hi Maciej, On 22 April 2015 at 08:59, Maciej Fijalkowski wrote: > Are you sure this is unsigned? IMO I've seen '0xffd5' or something > like that. As far as I can tell, the C code contains the declaration "Signed h_tid;". So I would guess that hdr['h_tid'] returns a signed integer. The next

Re: [pypy-dev] [pypy-commit] pypy default: Detect objects with h_tid==-42

Hi Alex, On 22 April 2015 at 19:31, Alex Stewart wrote: > Sorry, I couldn't help noticing this: > >> if sys.maxsize < 2**32: >> offset = tid & 0x # 32bit > > 0x is not 32 bit, it's 16 bit.. Should that be 0x instead? No, this "32bit" comment mean

Re: [pypy-dev] Allegro64 buildslave disappeared

Hi, On 25 April 2015 at 01:32, Maciej Fijalkowski wrote: > This can be resolved on the slave level, not on master level Yes, you can stop (disconnect) the slave, and then restart it. I never really understood the "Stop" buttons on the buildbot web pages, because some of them seem to have no eff

Re: [pypy-dev] How to embed PyPy when there's no filesystem?

Hi Tom, On 25 April 2015 at 01:32, Maciej Fijalkowski wrote: > On Sat, Apr 25, 2015 at 1:13 AM, wrote: >> Thanks for the idea. I played with the sandboxed version and it looks like >> it has potential. It's not necessarily the only option. A sandboxed process comes with a lot of other constr

Re: [pypy-dev] How to embed PyPy when there's no filesystem?

Hi Tom, On 27 April 2015 at 18:10, wrote: > We can't hard-code the scripts into the binary becuase their purpose is to > adapt behavior to new configurations. Because of this the scripts will be > read from an external source and then executed. This is what makes the the > stdin/stdout streami

Re: [pypy-dev] How to embed PyPy when there's no filesystem?

Hi Tom, On 28 April 2015 at 19:56, wrote: > Correction: " non-functional without the *peer* class > VirtualizedSandboxedProc" Modern PyPy versions try to get some environ variables, at least as documented in rpython/doc/logging.rst. It makes the do_ll_os__ll_os_getenv() method necessary (undef

Re: [pypy-dev] How to embed PyPy when there's no filesystem?

Hi Tom, On 30 April 2015 at 00:21, wrote: > 1) Am I correct in assuming that these are imports? Yes. > 2) Can these be eliminated? These opens are problematic in the absence of a > file system. Try running pypy with the -s option. Likely, it doesn't remove them all; you have to provide the

Re: [pypy-dev] (no subject)

Hi Laura, hi all, On 4 May 2015 at 05:27, Steven D'Aprano wrote: >> Mario Reingart has been trying to internationalise CPython >> since at least 2012. Fwiw, I found a 2012 text that says "since 2010". I'm absolutely +1 on the idea. I recall my own experience as a child: learning new keywords i

Re: [pypy-dev] PyPy on Windows 7: Icon file for pypy.exe

Hi Eun, On 4 May 2015 at 09:58, Eun Che wrote: > I wished to contribute via Bitbucket fork, but i'm so new to that, don't > know how to do. So I had to send this mail. Thanks! Can you give us a link that explains how to embed this icon inside pypy.exe? Maybe it's just a command-line option of

Re: [pypy-dev] PyPy on Windows 7: Icon file for pypy.exe

Hi all, On 4 May 2015 at 16:44, Ryan Gonzalez wrote: > You can use rcedit: I found the official way described here: http://doc.qt.io/qt-4.8/appicon.html . Interestingly, Windows looks like the simplest of all the platforms described there. The "rc" tool (unlike "rcedit") comes preinstalled tog

Re: [pypy-dev] Internationalization Proposal (was Re: (no subject))

Hi Mariano, On 5 May 2015 at 09:57, Mariano Reingart wrote: > I'll try to clone PyPy too, I think it could be even easier to > internationalize, as it is pure python and no C API should be changed, but > please correct me if I'm wrong. It's easier in some ways, but harder in others, because ther

Re: [pypy-dev] Internationalization Proposal (was Re: (no subject))

Hi Mariano, On 5 May 2015 at 20:21, Mariano Reingart wrote: > Or using a pure python implementation already in the stdlib? > > https://hg.python.org/cpython/file/2.7/Lib/gettext.py Ah, yes. This comes with potential performance issues, but let's not focus on performance to start with, as it is

Re: [pypy-dev] [pypy-commit] pypy default: The gdbm library is not thread-safe. Add a global lock.

Hi Fijal, On 6 May 2015 at 23:15, Maciej Fijalkowski wrote: > I was thinking, maybe instead we can add a feature to cffi "don't > release the GIL" and use that there? (it would be faster for example) It would not work here: one problem is that gdbm_*() functions set the global variable gdbm_errn

[pypy-dev] PyXxx_Malloc() in cpyext

Hi all (mostly Amaury :-), Some C extension modules don't compile with cpyext because it is missing some of the functions like PyObject_Malloc (it has got PyMem_Malloc). I'm thinking about adding them but also simplifying the indirections and having all PyObject_Malloc(), PyMem_Malloc(), etc. jus

Re: [pypy-dev] How to convert python string to C char*?

Hi Yicong, (CC to the cffi mailing list) On 14 May 2015 at 05:02, Yicong Huang wrote: > We had a python function that return a string value. The function will > callback in C code. > The below is an example of the code: > > @ffi.callback("char *(char *, char *)") > def strconcat(x, y): > x1

Re: [pypy-dev] operror-value: ('Unknown character', ('c callback', 1, 1, '\x08\n', 0))

Hi Yicong, On 12 May 2015 at 11:48, Yicong Huang wrote: > The program I wrote is simple: it read python code from a local file to > char*, and pass char* to pypy_execute_source(). It works for us, so please give a complete example: ideally, a C program that can show the problem when executed (in

Re: [pypy-dev] How to get the return value from pypy function for C code

Hi Yicong, On 13 May 2015 at 11:10, Amaury Forgeot d'Arc wrote: >> Does pypy have similar API? > > But don't you have it already? the func(3) above should return the integer 6! I would guess so too. The point of the PyPy "API" is that it is completely minimal. You have to do everything with CF

Re: [pypy-dev] Be on my podcast

Hi Michael, On 11 May 2015 at 19:10, Michael Kennedy wrote: > Hi guys, does that time work? Just so you know, your mails are being sent to the general pypy-dev mailing list too. We can't tell when "that time" is, probably because you have used a different channel to set it up privately. Fijal

Re: [pypy-dev] pypy + cProfile

Hi Stanislav, On 14 May 2015 at 08:37, Stanislav Bohm wrote: > I have tried some standard benchmarks and my other python programs, and > cProfile makes things slower. > Hence, Aislinn is the only program where I can reproduce the weird behavior. Then it looks likely to be a "randomness" issue: d

Re: [pypy-dev] How to convert python string to C char*?

Hi Yicong, On 14 May 2015 at 11:33, Yicong Huang wrote: > To my understanding, "ALL_RESULTS" is used to prevent pypy GC the pointing > buffer. > And thus, it is the C callback function's responsibility to free the buffer. > Am I right? No. In my example I just keep storing ffi.new("char[]") obj

Re: [pypy-dev] pypy + cProfile

Hi Leonardo, On 14 May 2015 at 21:51, Leonardo Santagada wrote: > I'm thinking that maybe the JIT is trying to compile some trace and then > throw it away, by using cprofile it is not even trying... that's why it is > actually slower than cpython to begin with. Can this be the case Armin? That's

Re: [pypy-dev] Could PyPy be embeded running in sanbox?

Hi Yicong, No, PyPy cannot be embedded running sandbox. The way we present embedding is by using the cffi module on the Python code; but this module is not available at all in a sandboxed PyPy (as it allows random invalid things to occur). If you really want to use the sandbox, you need to consi

Re: [pypy-dev] Could PyPy be embeded running in sanbox?

Hi Yicong, On 16 May 2015 at 07:42, Yicong Huang wrote: > I quite agree with you that cfii is very powerful and should not include in > sandbox. > However, could we consider include a small subset of cffi? No. Anything that cffi enables lets you read random memory, or write random memory, or ca

<    5   6   7   8   9   10   11   12   13   14   >