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 contai
Jeffrey Yasskin wrote:
On Fri, Mar 12, 2010 at 7:54 PM, 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 3.3.5 and 4.4.x us
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 mai
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 t
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:
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
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 g
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 wi
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.
There are 2 disparate approaches to clearing/compacting free lists for
basic types:
- APIs of the form Py_ClearFreeList() called from gc.collect()
[class, frame, method, tuple & unicode types];
- APIs of the form Py_CompactFreeList() called from
sys._compact_freelists() [int & float types];
Martin v. Lo"wis 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. (tech
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 th
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 thro
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
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 h
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.
--
-
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 pe
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
>
[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
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 te
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 th
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
>
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 perform
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.
Prob
Brett Cannon wrote:
{...}
> Noticing that sqlite 3.5.5 was recently available I had MacPorts
> update. Unfortunately this didn't fix things. I narrowed things down
> to running test_ctypes before test_sqlite as the trigger. In order to
> debug I wanted to use a version of sqlite that I had compil
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
[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 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 platform
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 feat
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 an
[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 3
Tim Peters wrote:
> #if THREAD_STACK_MIN < PTHREAD_STACK_MIN
>
> assumes that the expansion of PTHREAD_STACK_MIN acts like a
> compile-time constant expression, but there's no such guarantee.
>
>http://cvs.opensolaris.org/source/xref/on/usr/src/head/limits.h
>
> shows that, on one version o
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 test_thread
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.
>
> http://www.python.org
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
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 muc
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 soul(
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 d
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 fo
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
Michael Hudson wrote:
> Suleiman Souhlal <[EMAIL PROTECTED]> writes:
>
>>While investigating why the script used in http://docs.freebsd.org/
>>cgi/getmsg.cgi?fetch=148191+0+current/freebsd-stable used so much
>>system time on FreeBSD 5, I noticed that python is continually
>>calling sigprocmas
Martin v. Löwis wrote:
Andrew MacIntyre wrote:
This change has broken the build on FreeBSD 4.x for me:
gcc -pthread -c -fno-strict-aliasing -DNDEBUG -g -O3 -Wall
-Wstrict-prototypes -
I. -I./Include -DPy_BUILD_CORE -o Python/thread.o Python/thread.c
In file included from Python/thread.c:101
[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 sem
Fredrik Lundh wrote:
it could be worth expanding them to
"if x == 1 or x == 2 or x == 3:"
though...
C:\>timeit -s "a = 1" "if a in (1, 2, 3): pass"
1000 loops, best of 3: 0.11 usec per loop
C:\>timeit -s "a = 1" "if a == 1 or a == 2 or a == 3: pass"
1000 loops, best of 3: 0.0691 usec pe
On Sat, 18 Dec 2004, Tim Peters wrote:
> [Raymond, says test_glob and test_urllib fail on WinME now]
>
> [Andrew MacIntyre]
> >> I don't see any possible way for those checkins to affect any platform
> >> other than OS/2.
> >>
> >> 2 of the file
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 wor
On Fri, 17 Dec 2004, Raymond Hettinger wrote:
> The Dec 12th check-ins break tests on WinME:
>
>
> test_glob.py
>
> Traceback (most recent call last):
> File "test_glob.py", line 78, in test_glob_one_directory
> eq(self.glob('a*'), map(self.norm, ['a', 'aab', 'aaa']))
> File "
49 matches
Mail list logo
