Nick Maclaren schrieb:
>> py> x=-0.0
>> py> y=0.0
>> py> x,y
>
> Nobody is denying that SOME C90 implementations distinguish them,
> but it is no part of the standard - indeed, a C90 implementation is
> permitted to use ANY criterion for deciding when to display -0.0 and
> 0.0. C99 is ambiguous t
Alastair Houghton schrieb:
> On 3 Oct 2006, at 17:47, James Y Knight wrote:
>
>> On Oct 3, 2006, at 8:30 AM, Martin v. Löwis wrote:
>>> As Michael Hudson observed, this is difficult to implement, though:
>>> You can't distinguish between -0.0 and +0.0 easily,
Neal Norwitz schrieb:
> Is there an easy to fix this sort of problem so it doesn't happen in
> the future (other than revoke my checkin privileges :-) ?
Sure: Don't make changes after a release candidate. That files are
missing can only be detected by actually producing the installer and
testing w
Alastair Houghton schrieb:
> AFAIK few systems have floating point traps enabled by default (in fact,
> isn't that what IEEE 754 specifies?), because they often aren't very
> useful. And in the specific case of the Python interpreter, why would
> you ever want them turned on?
That reasoning is ir
Kristján V. Jónsson schrieb:
> Hm, doesn´t seem to be so for my regular python.
>
> maybe it is 2.3.3, or maybe it is stackless from back then.
It's because you are using Windows. The way -0.0 gets rendered
depends on the platform. As Tim points out, try
math.atan2(0.0, -0.0) vs math.atan2(0.0, 0
Kristján V. Jónsson schrieb:
> the VisualStudio8 64 bit build of 2.5 doesn't compile clean. We have a
> number of warnings of truncation from 64 bit to 32:
> Often it is a question of doing an explicit cast, but sometimes we are
> using "int" for results from strlen and such.
>
> Is there any in
Tim Peters schrieb:
> I just noticed that the bsddb portion of Python fails to compile on
> the 2.4 Windows buildbots, but for some reason the buildbot machinery
> doesn't notice the failure:
It's been a while that a failure to build some extension modules doesn't
cause the "compile" step to fail;
Tim Peters schrieb:
> [Martin v. Löwis]
>> It's been a while that a failure to build some extension modules doesn't
>> cause the "compile" step to fail; this just happened with the _ssl.pyd
>> module before.
>
> I'm guessing only on the release2
Raymond Hettinger schrieb:
>> the slightly obscure bit that requires some getting used to is
>> that all these flags don't really mean "I have such and such
>> feature" but just "I could have such and such
>> feature, if the corresponding tp_xxx field were set".
>
> I would like to see that clea
Barry Warsaw schrieb:
> Why can't we get buildbot to do most or all of this?
Very easy. Because somebody has to set it up. I estimate
a man month or so before it works.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.pytho
Anthony Baxter schrieb:
> Mostly it is easy for me, with the one huge caveat. As far as I know, the Mac
> build is a single command to run for Ronald, and the Doc build similarly for
> Fred. I don't know what Martin has to do for the Windows build.
Actually, for 2.3.x, I wouldn't do the Windows
Fredrik Lundh schrieb:
> ideally, releasing (earlier release + well-defined patch set) should be
> fairly trivial, compared to releasing (new release from trunk). what do
> we have to do to make it easier to handle that case?
For the Windows release, I doubt there is much one can do. The
time-con
Kristján V. Jónsson schrieb:
> This is an improvement of another 3.5 %.
> In all, we have a performance increase of more than 10%.
> Granted, this is from a single set of runs, but I think we should start
> considering to make PCBuild8 a "supported" build.
What do you mean by that? That Python 2.5
Alexey Borzenkov schrieb:
> Should I submit it to sourceforge as a patch, or someone can review it as is?
Please consider also exposing _wspawnvp, depending on whether path
argument is a Unicode object or not. See PEP 277 for guidance.
Since this would go into 2.6, support for Windows 95 isn't man
Gregory P. Smith schrieb:
> three macs with some virtual machines could take care of this (damn
> apple for not allowing their stupid OS to be virtualized). that said,
> i'm not volunteering to setup an automated system for this but i've
> got good ideas how to do it if i ever find time or someone
Alexey Borzenkov schrieb:
> On 10/13/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
>> Please consider also exposing _wspawnvp, depending on whether path
>> argument is a Unicode object or not. See PEP 277 for guidance.
>> Since this would go into 2.6, s
Gregory P. Smith schrieb:
> i read that as just suggesting that updates should be checked into the
> release25-maint tree to get PCBuild8 working out of the box for anyone
> who wants to build python from source with vs2005.
That's passive voice ("should be checked"). I think it is unrealistic
to
Dave Abrahams schrieb:
> The only problem here is that there appears to be a lag in the release of
> ActivePython after Python itself is released.
>
> Is there any chance of putting up just the debugging libraries a little
> earlier?
I may be out of context here: what is the precise problem in p
David Abrahams schrieb:
> At the moment I have too weak a server to provide those files, but
> that will change very soon. All that said, the Python and ActiveState
> teams need to be aware of each and every Python release and go through
> a standard release procedure anyway, whereas -- except fo
Alexey Borzenkov schrieb:
> On 10/13/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
>> > Umm... do you mean that spawn*p* on python 2.5 is an absolute no?
>> Yes. No new features can be added to Python 2.5.x; Python 2.5 has
>> already been released.
>
David Abrahams schrieb:
>> I'm not sure whether you are requesting these for yourself or for
>> somebody else. If for somebody else, that somebody else should seriously
>> consider building Python himself, and publishing the result.
>
> I'm requesting it for the many Boost.Python (heck, all Python
Steve Holden schrieb:
>>> The other thing to watch out for is that I (or whoever) can still do local
>>> work on a bunch of different files
>>
>> the point of my previous post is that you *shouldn't* have to edit a
>> bunch of different files to make a new release.
>>
> Indeed. I seem to remember
Thomas Heller schrieb:
> Yes. But I've switched machines since I last build an installer, and I do not
> have all of the needed software installed any longer, for example the Wise
> Installer.
Ok. So we are technically incapable of producing the Windows binaries of
another 2.3.x release, then?
Tim Peters schrieb:
> FYI, I still have the Wise Installer. But since my understanding is
> that the "Unicode buffer overrun" thingie is a non-issue on Windows,
> I've got no interest in wrestling with a 2.3.6 for Windows.
In 2.3.6, there wouldn't just be that change, but also a few other
changes
Josiah Carlson schrieb:
> I've got a build setup for 2.3.x, but I lack the Wise Installer. It may
> be possible to use the 2.4 or 2.5 .msi creation tools, if that was
> sufficient.
I don't think that would be appropriate. There are differences in usage
which might be significant to some users, e.
Anthony Baxter schrieb:
> Subsequent release. This is still largely a manual process - I search for all
> the references to the previous release, update them, then read through it for
> missed bits. I then update the text bits that need to be changed. There's all
> sorts of minor variations ther
ocean schrieb:
> Hello. I noticed VisualC++6 support came back. I'm glad with that,
> but still it seems incomplete. (for example, _sqlite3 support) Maybe
> does this patch help process?
These changes were all contributed by Larry Hastings. For some reason,
I missed/forgot about your patch. Can yo
Fredrik Lundh schrieb:
> but given that the format *has* been stable for many years, surely it
> would make more sense to just codify that fact, rather than developing
> Yet Another Serialization Format instead?
There have been minor changes over time, e.g. r26146 (gvanrossum)
introduced TYPE_TR
In Python 2.5.0 and earlier, it is not possible to modify
the time stamps of a directory (mtime and atime) on Windows.
The reason is that you cannot "open" (CreateFile) a
directory.
On W9x, it isn't possible, period. On WNT+, it's possible
if you pass FILE_FLAG_BACKUP_SEMANTICS to CreateFile.
I ju
Kristján V. Jónsson schrieb:
> I must confess that I am not familiar with the buildbots.
The challenge and work-load is primarily initially in setting it
up; in this case (for PCbuild8), there is work for both the master
and the slave sides (probably, new scripts in Tools/buildbot will
have to b
Kristján V. Jónsson schrieb:
> Okay, a buildbot then doesn't sound quite that scary. Any info
> somewhere on how to set one up on a windows box?
Sure. See
http://wiki.python.org/moin/BuildbotOnWindows
Feel free to make changes if you find the instructions need to be
enhanced.
> I Also wasn't s
Raymond Hettinger schrieb:
> My colleague got an odd result today that is reproducible on his build
> of Python (RedHat's distribution of Py2.4.2) but not any other builds
> I've checked (including an Ubuntu Py2.4.2 built with a later version of
> GCC). I hypothesized that this was a bug in the un
Brian Warner schrieb:
> To be precise, you have have as many build procedures per slave as you like,
> but if the procedure depends upon running on a particular platform, then it
> is unlikely that a single slave can accomodate multiple platforms.
Ah, right, I can have multiple builders per slave.
Grig Gheorghiu schrieb:
> OK, I deleted the checkout directory on one of my buidslaves and
> re-ran the build steps. The tests passed. So my conclusion is that a
> full rebuild is needed for the tests to pass after the last checkins
> (which included files such as configure and configure.in).
Inde
Grig Gheorghiu schrieb:
>> > Maybe the makefiles should be modified so that a full rebuild is
>> > triggered when the configure and configure.in files are changed?
>>
>> The makefiles already do that: if configure changes, a plain
>> "make" will first re-run configure.
>
> Well, that didn't trigge
Thomas Heller schrieb:
> I would prefer to merge these changes into release25-maint, because I want to
> also release the standalone ctypes packages from this branch (using it with
> svn:externals from somewhere else).
That's not a good reason for back-porting. If you want a "maintenance"
branch f
Grig Gheorghiu schrieb:
> Here are the steps that led to the unit test failures, after your
> checkin of configure and configure.in.
>
> svn update:
> http://www.python.org/dev/buildbot/community/all/x86%20Ubuntu%20Breezy%20trunk/builds/55/step-svn/0
>
> configure:
> http://www.python.org/dev/b
Grig Gheorghiu schrieb:
> FYI -- can't do svn checkouts/updates from the trunk at this point.
>
> starting svn operation
> svn update --revision HEAD
> in dir /home/twistbot/pybot/trunk.gheorghiu-x86/build (timeout 1200 secs)
> svn: PROPFIND request failed on '/projects/python/trunk'
> svn: PROPF
Larry Hastings schrieb:
> I've significantly enhanced my string-concatenation patch, to the point
> where that name is no longer accurate. So I've redubbed it the "lazy
> strings" patch.
It's not clear to me what you want to achieve with these patches,
in particular, whether you want to see them
[EMAIL PROTECTED] schrieb:
> That is, can I change stdin from text to binary this way or is it destined
> to always be in text mode?
You can call _setmode on the file descriptor.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://m
Thomas Heller schrieb:
> The official Python-2.5.amd64.msi does *not* contain ctypes, so
> the official Python-2.5.x.amd64.msi should also not contain ctypes (I assume).
That would be good, yes.
> Not many people (I assume again) are running 64-bit windows, and use the
> 64-bit Python
> version
Larry Hastings schrieb:
> Anyway, it was my intent to post the patch and see what happened. Being
> a first-timer at this, and not having even read the core development
> mailing lists for very long, I had no idea what to expect. Though I
> genuinely didn't expect it to be this brusque.
I cou
[EMAIL PROTECTED] schrieb:
> >> Anyway, it was my intent to post the patch and see what happened.
> >> Being a first-timer at this, and not having even read the core
> >> development mailing lists for very long, I had no idea what to
> >> expect. Though I genuinely didn't expect it
Larry Hastings schrieb:
> Am I correct in understanding that changing the Python minor revision
> number (2.5 -> 2.6) requires external modules to recompile? (It
> certainly does on Windows.)
There is an ongoing debate on that. The original intent was that you
normally *shouldn't* have to recompi
Mike Krell schrieb:
>> Based on the behaviour of str and the fact that overriding unicode.__repr__
>> works just fine, I'd say file a bug on SF.
>
> Done. This is item 1583863.
Of course, it would be even better if you could also include a patch.
Regards,
Martin
Travis E. Oliphant schrieb:
> The datatype is an object that specifies how a certain block of
> memory should be interpreted as a basic data-type.
>
> >>> datatype(float)
> datatype('float64')
I can't speak on the specific merits of this proposal, or whether this
kind of func
Steven Bethard schrieb:
> Jack Howarth asked about creating universal binaries for OS X that
> would support 32-bit or 64-bit on both PPC and x86. Ronald Oussoren
> pointed out that the 32-bit part of this was already supported, but
> indicated that adding 64-bit support simultaneously might be mor
Travis E. Oliphant schrieb:
> In this case, the 'kind' does not specify how large the data-type is.
> You can have 'u1', 'u2', 'u4', etc.
>
> The same is true with Unicode. You can have 10-character unicode
> elements, 20-character, etc. But, we have to be clear about what a
> "character" is
Georg Brandl schrieb:
> I wonder if it's possible that the build bot notification mails that go
> to python-checkins include the last 10-15 lines from the log. This would
> make it much easier to decide whether a buildbot failure is an old,
> esoteric one (e.g.
It should be possible to implement t
Travis E. Oliphant schrieb:
> What is needed is a definitive way to describe data and then have
>
> array
> struct
> ctypes
>
> all be compatible with that same method.That's why I'm proposing the
> PEP. It's a unification effort not yet-another-method.
As I unification mechanism, I think
Travis E. Oliphant schrieb:
> How to handle unicode data-formats could definitely be improved.
As before, I'm doubtful what the actual needs are. For example, is
it desired to support generation of ID3v2 tags with such a data
format? The tag is specified here:
http://www.id3.org/id3v2.4.0-struct
Travis E. Oliphant schrieb:
> I'm proposing to add this object to Python so that the buffer protcol
> has a fast and efficient way to share #3. That's really all I'm after.
I admit that I don't understand this objective. Why is it desirable to
support such an extended buffer protocol? What spec
Travis E. Oliphant schrieb:
>> As I unification mechanism, I think it is insufficient. I doubt it
>> can express all the concepts that ctypes supports.
>>
>
> Please clarify what you mean.
>
> Are you saying that a single object can't carry all the information
> about binary data that ctypes all
Robert Kern schrieb:
>> As I unification mechanism, I think it is insufficient. I doubt it
>> can express all the concepts that ctypes supports.
>
> What do you think is missing that can't be added?
I can factually only report what is missing. Whether it can be added,
I don't know. As I just wrot
Anthony Baxter schrieb:
> A better solution (awaiting sufficient round-tuits) would be to add an option
> to regrtest that's used by the buildslaves that uses particularly markup
> around success/fail indications. The buildmaster can pick those up, and keep
> track of existing pass/fails. Then i
Paul Moore schrieb:
> Here's an example. PIL handles images (in various formats) in memory,
> as blocks of binary image data. NumPy provides methods for
> manipulating in-memory blocks of data. Now, if I want to use NumPy to
> manipulate that data in place (for example, to cap the red component
> a
Josiah Carlson schrieb:
> One could also toss wxPython, VTK, or any one of the other GUI libraries
> into the mix for visualizing those images, of which wxPython just
> acquired no-copy display of PIL images, and being able to manipulate
> them with numpy (of which some wxPython built in classes us
Travis Oliphant schrieb:
> Function pointers are "supported" with the void data-type and could be
> more specifically supported if it were important. People typically
> don't use the buffer protocol to send function-pointers around in a way
> that the void description wouldn't be enough.
As I
Travis Oliphant schrieb:
> So, the big difference is that I think data-formats should be
> *instances* of a single type.
This is nearly the case for ctypes as well. All layout descriptions
are instances of the type type. Nearly, because they are instances
of subtypes of the type type:
py> type(c
Travis E. Oliphant schrieb:
> But, there are distinct disadvantages to this approach compared to what
> I'm trying to allow. Martin claims that the ctypes approach is
> *basically* equivalent but this is just not true.
I may claim that, but primarily, my goal was to demonstrate that the
propos
Travis Oliphant schrieb:
> The big difference, however, is that by going this route you are forced
> to use the "type object" as your data-format "instance".
Since everything is an object (an "instance) in Python, this is not
such a big difference.
> This is
> fitting a square peg into a round
Stephan Tolksdorf schrieb:
> While Travis' proposal encompasses the data format functionality within
> the struct module and overlaps with what ctypes has to offer, it does
> not aim to replace ctypes.
This discussion could have been a lot shorter if he had said so.
Unfortunately (?) he stated t
Travis Oliphant schrieb:
> I think it actually is. Perhaps I'm wrong, but a type-object is still a
> special kind of an instance of a meta-type. I once tried to add
> function pointers to a type object by inheriting from it. But, I was
> told that Python is not set up to handle that. Maybe I
Travis E. Oliphant schrieb:
> Several extensions to Python utilize the buffer protocol to share
> the location of a data-buffer that is really an N-dimensional
> array. However, there is no standard way to exchange the
> additional N-dimensional array information so that the data-b
Paul Jimenez schrieb:
> I submitted patch 1462525 awhile back to
> solve the problem described even longer ago in
> http://mail.python.org/pipermail/python-dev/2005-November/058301.html
> and I'm wondering what my appropriate next steps are. Honestly, I don't
> care if you take my patch or someone
Bill Baxter schrieb:
> Basically in my code I want to be able to take the binary data descriptor and
> say "give me the 'r' field of this pixel as an integer".
>
> Is either one (the PEP or c-types) clearly easier to use in this case? What
> would the code look like for handling both formats gene
Travis E. Oliphant schrieb:
> What if we look at this from the angle of trying to communicate
> data-formats between different libraries (not change the way anybody
> internally deals with data-formats).
ISTM that this is not the right approach. If the purpose of the datatype
object is just to c
Travis E. Oliphant schrieb:
>> Or, if it does have uses independent of the buffer extension: what
>> are those uses?
>
> So that NumPy and ctypes and audio libraries and video libraries and
> database libraries and image-file format libraries can communicate about
> data-formats using the same e
Travis E. Oliphant schrieb:
> I was too hasty. There are some things actually missing from ctypes:
I think Thomas can correct me if I'm wrong: I think endianness is
supported (although this support seems undocumented). There seems
to be code that checks for the presence of a _byteswapped_ attribu
Travis Oliphant schrieb:
>>> r_field = PyDict_GetItemString(dtype,'r');
>>>
> Actually it should read PyDict_GetItemString(dtype->fields).The
> r_field is a tuple (data-type object, offset). The fields attribute is
> (currently) a Python dictionary.
Ok. This seems to be missing in the PE
Alexander Belopolsky schrieb:
> I would also like to mention one more difference between NumPy datatypes
> and ctypes that I did not see discussed. In ctypes arrays of different
> shapes are represented using different types. As a result, if the object
> exporting its buffer is resized, the datat
Travis E. Oliphant schrieb:
>> 2. Should primitive type codes be characters or integers (from an enum) at
>> C level?
>> - I prefer integers
>
>> 3. Should size be expressed in bits or bytes?
>> - I prefer bits
>>
>
> So, you want an integer enum for the "kind" and an integer for the
> b
Andrew Dalke schrieb:
> >>> import urlparse
> >>> urlparse.urljoin("hello", "/world")
> '/world'
> >>> urlparse.urljoin("hello", "slash/world")
> 'slash/world'
> >>> urlparse.urljoin("hello", "slash//world")
> 'slash//world'
> >>>
>
> It does not make sense to me that these should be diffe
Alexander Belopolsky schrieb:
> Multi-segment buffers are only dead because standard library modules
> do not support them.
That, in turn, is because nobody has contributed code to make that work.
My guess is that people either don't need it, or find it too difficult
to implement.
In any case, it
Paul Chiusano schrieb:
> I was looking for a good pairing_heap implementation and came across
> one that had apparently been checked in a couple years ago (!).
Have you looked at the heapq module? What application do you have
for a pairing heap that you can't do readily with the heapq module?
Any
Robert schrieb:
> Would it be a possibilty in next Python to have the lock separate for
> each Interpreter instance. Thus: have *interpreter_lock separate in
> each PyThreadState instance and only threads of same Interpreter have
> same GIL? Separation between Interpreters seems to be enough. The
Patch #1346572 proposes to also search for .pyc when OptimizeFlag
is set, and for .pyo when it is not set. The author argues this is
for consistency, as the zipimporter already does that.
This reasoning is somewhat flawed, of course: to achieve consistency,
one could also change the zipimporter in
Fredrik Lundh schrieb:
>> However, I find the proposed behaviour reasonable: Python already
>> automatically imports the .pyc file if .py is not given and vice
>> versa. So why not look for .pyo if the .pyc file is not present?
>
> well, from a performance perspective, it would be nice if Python l
Paul Chiusano schrieb:
> To support this, the insert method needs to return a reference to an
> object which I can then pass to adjust_key() and delete() methods.
> It's extremely difficult to have this functionality with array-based
> heaps because the index of an item in the array changes as item
Greg Ewing schrieb:
> Fredrik Lundh wrote:
>
>> well, from a performance perspective, it would be nice if Python looked
>> for *fewer* things, not more things.
>
> Instead of searching for things by doing a stat call
> for each possible file name, would it perhaps be
> faster to read the content
Andrew Dalke schrieb:
> I have looked at the spec, and can't figure out how its explanation
> matches the observed urljoin results. Steve's excerpt trimmed out
> the strangest example.
Unfortunately, you didn't say which of these you want explained.
As it is tedious to write down even a single on
Aahz schrieb:
> Maybe so, but I recently dealt with a painful bottleneck in Python code
> caused by excessive stat() calls on a directory with thousands of files,
> while the os.listdir() function was bogging things down hardly at all.
> Granted, Python bytecode was almost certainly the cause of mu
Andrew Dalke schrieb:
urlparse.urljoin("http://blah.com/";, "..")
> 'http://blah.com/'
urlparse.urljoin("http://blah.com/";, "../")
> 'http://blah.com/../'
urlparse.urljoin("http://blah.com/";, "../..")
> 'http://blah.com/'
>
> Does the result make sense to you? Does it make
> sens
Greg Ewing schrieb:
>> That should never be better: the system will cache the directory
>> blocks, also, and it will do a better job than Python will.
>
> If that's really the case, then why do discussions
> of how improve Python startup speeds seem to focus
> on the number of stat calls made?
A
Andrew Dalke schrieb:
>> I find there is a difference between "urllib behaves
>> non-intuitively" and "urllib gives result A for parameters B and C,
>> but should give result D instead". Can you please add specific examples
>> to your report that demonstrate the difference between implemented
>> an
Andrew Dalke schrieb:
> Hence I would say to just grab their library. And perhaps update the
> naming scheme.
Unfortunately, this is not an option. *You* can just grab their library;
the Python distribution can't. Doing so would mean to fork, and history
tells that forks cause problems in the lon
Armin Rigo schrieb:
> My strong opinion on the matter is that importing a .pyc file if the .py
> file is not present is wrong in the first place.
There is, of course, an important use case (which you are addressing
with a different approach): people want to ship only byte code, not
source code, be
Fredrik Lundh schrieb:
>> urlparse.urljoin("http://blah.com/";, "../")
>>
>> should also give 'http://blah.com/'.
>
> make that: could also give 'http://blah.com/'.
How so? If that would implement RFC 3986, you can
get only a single outcome, if urljoin is meant
to implement section 5 of that RFC.
Wolfgang Langner schrieb:
> Why not only import *.pyc files and no longer use *.pyo files.
>
> It is simpler to have one compiled python file extension.
> PYC files can contain optimized python byte code and normal byte code.
So what would you do with the -O option of the interpreter?
Regards,
M
Greg Ewing schrieb:
> I think I'd be happy with having to do that explicitly.
> I expect the vast majority of Python programs don't
> need to track changes to the set of importable modules
> during execution. The exceptions would be things like
> IDEs, and they could do a cache flush before reloadi
Herman Geza schrieb:
> Here python reads from an already-freed memory area, right?
It looks like it, yes. Of course, it could be a flaw in valgrind, too.
To find out, one would have to understand what the memory block is,
and what part of PyObject_Free accesses it.
Regards,
Martin
___
Neal Norwitz schrieb:
> at 0x44FA06: Py_ADDRESS_IN_RANGE (obmalloc.c:1741)
>
> Note that the free is inside qsort. The memory freed under qsort
> should definitely not be the bases which we allocated under
> PyType_Ready. I'll file a bug report with valgrind to help determine
> if this is a pr
Herman Geza schrieb:
>> So figure out which line of code valgrind is complaining about
>> (doesn't valgrind usually produce that?). If it's coming from the
>> expansion of Py_ADDRESS_IN_RANGE, it's not worth more thought.
>
> Hmm. I don't think that way. What if free() does other things?
It can't
Ronald Oussoren schrieb:
> This is on a 10.4.8 box with a recent version of subversion. It turns
> out this is caused by a testcase file: decimal-c/new_dt contains both
> remainderNear.decTest and remaindernear.decTest (the filenames differ by
> case only). It this intentional?
I don't think so. T
Herman Geza schrieb:
>> It can't. In brk, you can only manage memory in chunks of "one page"
>> (i.e. 4kiB on x86). Since we only access memory on the same page,
>> access is guaranteed to succeed.
> Yes, I'm aware of it. But logically, it is possible, isn't it?
No, it isn't.
> At malloc(), libc
Greg Ewing schrieb:
> One thing I should add is that if you try to import
> a module that wasn't there before, the interpreter will
> notice this and has the opportunity to update its idea
> of what's on the disk.
How will it notice that it wasn't there before? The
interpreter will see that it has
Grig Gheorghiu schrieb:
> One of the Pybots buildslaves running x86 Ubuntu Edgy has been failing
> the unit test step for the trunk, specifically the test_ucn test.
Something is wrong with the machine. I forced a clean rebuild, and
now it crashes in test_doctest2:
http://www.python.org/dev/buildb
Greg Ewing schrieb:
> Martin v. Löwis wrote:
>
>> a) the directory cache is out of date, and you should
>>re-read the directory
>> b) the module still isn't there, but is available in
>>a later directory on sys.path (which hasn't yet
>>bee
Patch #841454 takes a stab at cross-compilation
(for MingW32 on a Linux system, in this case),
and proposes to use SCons instead of setup.py
to compile extension modules. Usage of SCons
would be restricted to cross-compilation (for
the moment).
What do you think?
Regards,
Martin
_
Anthony Baxter schrieb:
> So we'd now have 3 places to update when things change (setup.py, PCbuild
> area, SCons)? How does this deal with the problems that autoconf has with
> cross-compilation? It would seem to me that just fixing the extension module
> building is a tiny part of the problem.
1701 - 1800 of 5277 matches
Mail list logo
