Victor Stinner wrote:
Python contains code specific to OS/2 (eg. see Modules/posixmodule.c). I read
in Wikipedia that IBM has discontinued OS/2 support in 2005. Do we still
support OS/2 or not?
As was recently discussed, what constitutes support varies in perception.
Python's source
Jeffrey Yasskin wrote:
On Fri, Mar 12, 2010 at 7:54 PM, s...@pobox.com wrote:
OS/2: http://www.andymac.org/
I can't find a modern c++ compiler for OS/2. Then again, your link
only provides python 2.4.
While the gcc used as part of the EMX toolchain is 2.8.1, there are
ports of gcc
Brett Cannon wrote:
It's up to Andrew to get the support in. While I have faith he will,
this is why we have been scaling back the support for alternative OSs
for a while and will continue to do so. I suspect the day Andrew stops
keeping up will be the day we push to have OS/2 be externally
Martin v. Löwis wrote:
Making a decision and removing the files considered unnecessary would clarify
what platforms still are/should be supported.
I think any such removal should go through the PEP 11 process. Put a
#error into the files for 3.2, and a removal notice into the PEP, then
remove
Martin v. Löwis wrote:
* if your target system doesn't have wget, download it locally,
then scp/rcp/ftp it to the target system.
All of [Free|Net|Open|Dragonfly]BSD have ftp clients that can also
retrieve HTTP URLs, though I guess many wouldn't think of that...
--
Mike Coleman wrote:
I have a program that creates a huge (45GB) defaultdict. (The keys
are short strings, the values are short lists of pairs (string, int).)
Nothing but possibly the strings and ints is shared.
The program takes around 10 minutes to run, but longer than 20 minutes
to exit (I
Mike Coleman wrote:
Andrew, this is on an (intel) x86_64 box with 64GB of RAM. I don't
recall the maker or details of the architecture off the top of my
head, but it would be something off the rack from Dell or maybe HP.
There were other users on the box at the time, but nothing heavy or
that
Andrew MacIntyre wrote:
I'll take this up with FreeBSD folk, but I'm open to ideas as to how
best to deal with the problem in the context of the test suite pending
resolution by FreeBSD.
The response I got from Jason Evans (author of the new malloc()
implementation), along
Martin v. Löwis wrote:
I haven't yet tried posting a query to a FreeBSD list, as it could simply
be a bug on amd64, but I was wondering whether there was anything (other
than deactivating tests and documenting use of ulimit -v on this
platform) that could be done to work around this behaviour.
Martin v. Lowis wrote:
(Hmm, is changing Modules/Setup enough to sort the Windows build out as
well? Or does that need a separate change to some of the Visual Studio
files?)
The latter. Whenever you add, remove, or rename an extension module, you
need to adjust the PCbuild files as well.
Christian Heimes wrote:
Memory management of ints, floats and longs
http://bugs.python.org/issue2039
http://bugs.python.org/issue2013
wrt 2039 - I would like to see the free list compaction called from
gc.collect() rather than a function in sys... something you suggested.
As I noted in the
Jeroen Ruigrok van der Werven wrote:
-On [20080309 23:59], Martin v. Löwis ([EMAIL PROTECTED]) wrote:
So this now *is* a FreeBSD/ncurses expert's question.
I don't think this is supposed to happen; newscr should
become non-NULL when initscr is called, and should remain
that way throughout.
Vladimir Marangozov wrote:
May I chime in? :-)
Please do!
Gents, the current implementation of Python's memory management
is really fine and most problems it used to have in the past
have been fixed in recent years (at least the ones I know of).
Probably the only one left, indeed, is the
Andrew MacIntyre wrote:
M.-A. Lemburg wrote:
If we're down to voting, here's my vote:
+1 on removing the freelists from ints and floats, but not the
small int sharing optimization
+1 on focusing on improving pymalloc to handle int and float
object allocations even better
-1
Christian Heimes wrote:
Andrew MacIntyre wrote:
I tested the updated patch you added to issue 2039. With the int
freelist set to 500 and the float freelist set to 100, its about the same
as the no-freelist version for my tests, but PyBench shows the simple
float arithmetic to be about 10
M.-A. Lemburg wrote:
On 2008-02-13 12:56, Andrew MacIntyre wrote:
I'm not that interested in debating the detail of exactly how big the
prospective LIFO freelists are - I just want to see the situation
resolved with maximum utilisation of memory for minimum performance
penalty. To that end
Christian Heimes wrote:
By the way objects are always aligned at 8 byte address boundaries. A 12
or 4 bytes object occupies 16 bytes.
No, with PyMalloc a 4 byte object occupies 8 bytes (see the comments at
the top of Objects/obmalloc.c).
Cheers,
Andrew.
--
[fwd as reply was intended for python-dev]
Christian Heimes wrote:
Andrew MacIntyre wrote:
I tried a LIFO stack implementation (though I won't claim to have done it
well), and found it slightly slower than no freelist at all. The
advantage of such an approach is that the known size
M.-A. Lemburg wrote:
On 2008-02-07 14:09, Andrew MacIntyre wrote:
Probably in response to the same stimulus as Christian it occurred to me
that the freelist approach had been adopted long before PyMalloc was
enabled as standard (in 2.3), and that much of the performance gains
between 2.2
M.-A. Lemburg wrote:
As you can see, Integers and floats fall into the same pymalloc size
class. What's strange in Andrew's result is that both integers
and floats use the same free list technique and fall into the same
pymalloc size class, yet the results are different.
My take is not that
Tim Peters wrote:
pymalloc ensures 8-byte alignment. This is one plausible reason to
keep the current int free list: an int object struct holds 3 4-byte
members on most boxes (type pointer, refcount, and the int's value),
and the int freelist code uses exactly 12 bytes for each on most
Christian Heimes wrote:
Andrew MacIntyre wrote:
For the int case, that patch is slower than no free list at all. For the
float case its very slightly faster (55.3s vs 55.5s) than no free list at
all. Slower than the trunk code for both cases. Did you run the test
scripts on your own
I note that in r60567 Christian checked in support for compacting the
int and float freelists.
I have no problems with the implementation, but would like to note
that I have been experimenting with an alternate approach which doesn't
require the addition of a knob to initiate the compacting.
Christian Heimes wrote:
{...}
PC/os2*/
OS2 build dirs. The files are no longer maintained.
While I haven't been visible much lately, especially in the 3.0 space,
I do have plans to continue supporting the OS/2 EMX environment (PC/os2emx).
For 3.x, the PC/os2vacpp subdirectory can go, as I
Martin v. Löwis wrote:
Cameron Laird schrieb:
Folklore that I remember so unreliably I avoid trying to repeat it here
held that Python threading had problems on BSD and allied Unixes. What's
the status of this?
The problem that people run into again and again is the stack size. The
BSDs
[EMAIL PROTECTED] wrote:
Brett So, here are the platforms I figured we should drop:
...
Brett * OS/2
I'm pretty sure Andrew MacIntyre is still maintaining the OS/2+EMX port:
http://members.pcug.org.au/~andymac/python.html
I am, although I haven't managed a binary
I just had a look at the Cygwin buildbot's test log, and noticed that
test_mailbox has failures that look very similar to those I addressed in
rev 50789 for the OS/2 EMX platform.
Hopefully this might give someone with access to Cygwin a starting point
in getting this test working on that
Anthony Baxter wrote:
On Friday 14 July 2006 22:45, Jeremy Hylton wrote:
Maybe the basic question is right, but the emphasis needs to be
changed. If we had a rule that said the final release was 90 days
after the last submission that wasn't to fix a regression, we'd ask
Is this feature
Neal Norwitz wrote:
It's June 9 in most parts of the world. The schedule calls for beta 1
on June 14. That means there's less than 4 days until the expected
code freeze. Please don't rush to get everything in at the last
minute. The buildbots should remain green to keep Anthony happy and
[EMAIL PROTECTED] wrote:
Andrew, look in your mail for a patch file.
Received, thanks.
Andrew.
-
Andrew I MacIntyre These thoughts are mine alone...
E-mail: [EMAIL PROTECTED] (pref) | Snail: PO Box 370
In reviewing the buildbot logs after committing this patch, I see 2
issues arising that I need advice about...
1. The Solaris build failure in thread.c has me mystified as I can't
find any _sysconf symbol - is this in a system header?
2. I don't know what to make of the failure of
Neal Norwitz wrote:
I moved up the 2.5 release date by a bit. Ideally, I wanted to have
the final on July 27 which corresponds to OSCON. This seems too
aggressive since I haven't updated the schedule publicly. So the new
schedule has rc1 slated for July 27.
Terry Reedy wrote:
If you checked it in (after tests pass on your ?mac?, and while being ready
to revert), wouldn't the next buildbot cycle do the testing you need?
Isn't testing on 'other' platforms what buildbot is for?
Only up to a point... In this case, I was after code review as much
Tim Peters wrote:
[Andrew MacIntyre]
Hmm... I don't appear to have explained what I meant very well :-|
{...}
This really needs an executable example. Here's my best guess about
what you mean, but I don't see any of what you're describing on WinXP
Pro SP2:
And a pretty good guess
http://www.python.org/sf/1454481
I would like to see this make it in to 2.5. To that end I was hoping to
elicit any review interest beyond Martin and Hye-Shik, both of whom I
thank for their feedback.
As I can't readily test on Windows (in particular) or Linux I would
appreciate some kind
Martin v. Löwis wrote:
It can't be that simple. Python's stdout should indeed be inherited
from cmd.exe, but that, in turn, should have obtained it from
buildbot. So even though cmd.exe closes its handle, Python's handle
should still be fine. If buildbot then closes the other end of the
Martin v. Löwis wrote:
I see three options:
1. rename sqlite3 again
2. link sqlite3 statically into _sqlite3.pyd
3. stop treating .DLL files as extension modules
I'm actually leaning towards option 3: what is the rationale
for allowing Python extension modules to be named .DLL?
A
Jim Jewett wrote:
Is OS2 still actively supported?
If you mean, is Python still actively supported on OS/2, then the answer
is yes.
-
Andrew I MacIntyre These thoughts are mine alone...
E-mail: [EMAIL
Andrew MacIntyre wrote:
Jim Jewett wrote:
Is OS2 still actively supported?
If you mean, is Python still actively supported on OS/2, then the answer
is yes.
Just to clarify, I haven't been actively monitoring other changes for
impact on the OS/2 port for the last few months (too much
[EMAIL PROTECTED] wrote:
Update of /cvsroot/python/python/dist/src/Python
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv25872
Modified Files:
Tag: release24-maint
thread_pthread.h
Log Message:
Patch #1163249 - Correctly handle _POSIX_SEMAPHORES == -1 to mean no
support for posix
On Fri, 17 Dec 2004, Raymond Hettinger wrote:
So how about a slogan like Code it Fast, with Python, or Python:
Code
Fast -- one which emphasizes the (easily defended) claim that
development
time is shorter with Python, but which at the same time manages to
associate the word fast with
41 matches
Mail list logo
