Interesting - is it possible that the same technique could be used to
hide differences in character width? Specifically, if I concatenate an
ascii string with a UTF-32 string, can the up-conversion to UTF-32 also
be done lazily? If that could be done efficiently, it would resolve some
outstandi
Larry Hastings wrote:
> I knocked out a prototype of this last week, emailed Mr. Lundh about it,
> then forgot about it.
It's on my TODO list, so I haven't forgotten about it, but I've been (as
usual) busy with other stuff. I'll get there, sooner or later.
Posting this to the patch tracker an
Following up on my earlier post...
I svn up'd both my g5 and my g4 powerbook (both running OSX 10.4.8, gcc
4.0.0 apple build 5026), built and tested both. The test suite completed
fine on my powerbook, failed on the g5. I tried running regrtest.py twice
more on the g5 with the -r flag. It faile
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.
The major new feature is that string *slices* are also represented with
a lazy-evaluation placeholder for the actual string, just as
co
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
I'm setting up a buildbot slave for sqlalchemy on one of my Macs at home.
When it builds and tests Python's test suite the sqlite test fails. When I
ran it alone like this:
./python.exe Lib/test/test_sqlite.py
and
./python.exe Lib/test/regrtest.py test_sqlite
it succeeded. When I ran
Sorry for the off-topic post. I figured someone here would know the answer
and I don't have access to Windows to check experimentally.
The ocrad program opens its input like so:
if ( std::strcmp( infile_name, "-" ) == 0 )
infile = stdin;
else
infile = std::fopen( infile_
Martin v. Löwis schrieb:
> Thomas Heller schrieb:
[I was talking about patches to make ctypes work on 64-bit windows]
>> 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 fr
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
On 10/20/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> 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
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:
>> > 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
On 10/19/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> 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
[Resent after subscribing to python-dev with this new email address,
sorry if it appears twice]
Thomas Heller schrieb (this was before Python 2.5 had been released):
> > The _ctypes extension module does currently not even build on Win64.
> >
> > I'm (slowly) working on this (for AMD64, not for i
Thomas Heller schrieb (this was before Python 2.5 had been released):
> The _ctypes extension module does currently not even build on Win64.
>
> I'm (slowly) working on this (for AMD64, not for itanium), but it may
> take a good while before it is stable - It is not even fully implemented
> curren
15 matches
Mail list logo
