Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
User with non-standard search paths should edit Modules/Setup.
--
nosy: +loewis
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
Looking at the message id, this came in through email. I have now
trained this as spam in spambayes (which unfortunately also means that
user:5 gets associated with being spam; we'll have to watch this and
train pote
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
Fredrik, can you take a look?
--
assignee: -> effbot
nosy: +effbot, loewis
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.py
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
> I don't see any changes to s# and t# in your patch. Do you plan to do it
> later or do you think this part should be dropped?
It's implemented. When bf_releasebuffer is not NULL, convertbuffer will
complain "
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
> But t# uses bf_getcharbuffer(), which does not seem to lock anything.
Indeed. I think we can safely drop support for passing buffer objects
into t# which have getbuffer/releasebuffer, so the check for
releasebuffer being NULL
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
Installation of PatternGrammar pickle is now fixed in r65368 and r65369.
HWJ, please don't report multiple problems in a single tracker issue;
instead, create separate tracker issues for independent problems.
--
no
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
Amaury, I think the issue of thread-safety of the io library should be
decoupled from this issue. I don't think it is release-critical that the
io library is thread-safe (and even if it is release-critical, the
problem should be t
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
I have now updated the patch to fix the socket bug, and the rejects
bytearray for t#.
As for making Py_buffer own a reference to the object: what should be
the semantics for PyObject_ReleaseBuffer? I see the following options:
Changes by Martin v. Löwis <[EMAIL PROTECTED]>:
Removed file: http://bugs.python.org/file10969/s_star.diff
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
I don't think the proposed patch (file11012) makes it thread-safe, and I
believe you cannot get it thread-safe without using thread synchronization.
For example, if two threads simultaneously determine that there is still
space
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
> I don't know, is there supposed to be a semantic difference between
> PyObject_ReleaseBuffer and PyBuffer_Release? If not, I'd say drop it.
There are existing callers of it which would need to be changed, perhaps
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
> I should have precised that in the context of this issue, "thread-safe" does
> not
> mean "produces perfectly correct output" but simply "does not raise exceptions
> when using the same buffe
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
On Windows, case-insensitivity is part of the API, not of the file
system. NTFS itself is case-sensitive, and there are case-sensitive
subsystems on top of it (e.g. the POSIX subsystem, Interix). Win32, when
calling the file system, as
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
> Well, if that resolution is prefered, I think it should be integrated to
> the builtin print function, rather than forcing users to monkeypatch it
> (but a debugging facility directly calling sys.stdout.write or
> equi
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
Thanks for the patch, committed as r65399, r65400, and r65401.
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.
Changes by Martin v. Löwis <[EMAIL PROTECTED]>:
--
resolution: -> fixed
status: open -> closed
versions: +Python 2.6, Python 3.0
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.p
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
I dislike this change, not because of the potential slowdown, but
because of the added code complexity.
How plausible is it that you want to join a list of bytes objects, and
the list has more than one item, yet all but one item are
Changes by Martin v. Löwis <[EMAIL PROTECTED]>:
--
nosy: +loewis
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3497>
___
__
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
> I am still very much confused, how change in print statement changes
> order in which items are removed from a set. I presumed it to be
> undefined but deterministic (similar to dict()): while I cannot tell
> which order
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
That's a bug in the Win32 extensions. They shouldn't use string.letters,
but string.ascii_letters, in particular when they check for valid
identifier chars.
Closing this report as "won't fix".
--
nos
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
When classifying stuff as spam, please also check for attachments that
might have been included in the email message, and show up as files -
files and messages are treated separately in the tracker.
--
nosy: +georg.brandl,
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
The interpreter holds onto sys.exc_traceback even after the except
block. This refers to the frame, which refers to the file object.
--
nosy: +loewis
___
Python tracker <[EMAIL PROTECTE
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
> Hmm, when exception occurs in some frame, its reference will be
> retained even after exiting function?
Correct. When a traceback is produced, all frames get linked, be
able to print later the traceback with source code infor
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
The patch is fine, please apply (also to the 2.5 and 3.0 branches).
Don't forget a Misc/NEWS entry.
--
assignee: loewis -> schuppenies
resolution: -> accepted
___
Pytho
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
I cannot quite see why the problem is serious: even though the memory is
not returned to the system, it will be swapped out to the swap file, so
it doesn't consume any real memory (just swap space).
I don't think Python sh
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
>> Instead, Python's own memory allocate (obmalloc) should be changed to
>> directly use the virtual memory interfaces of the operating system (i.e.
>> mmap), bypassing the malloc of the C library.
>
>
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
No, getpreferredencoding should always produce an encoding name. If the
application had an idea what to use, it wouldn't have to ask. So I favor
(3), or, perhaps given that OSX uses UTF-8 in many places,
(5) re
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
Are you sure you are using the correct compiler (i.e. from the XCode
release relevant for your operating system version)?
--
nosy: +loewis
___
Python tracker <[EMAIL PROTECTE
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
I recommend to use binascii.hexlify; this works in all Python version
(since 2000 or so).
I'm -1 for this patch.
--
nosy: +loewis
___
Python tracker <[EMAIL PROTECTED]>
<ht
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
> * However, it is *very* obscure. I've been using Python for a year and I
> didn't know about it.
Hmm. There are probably many modules that you haven't used yet.
> * And, it requires importing binascii.
Changes by Martin v. Löwis <[EMAIL PROTECTED]>:
--
versions: +Python 3.1 -Python 3.0
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
> You did the 3.1 thing again! We can accept a new feature like this
> before 3.0b3, can we not?
Not without explicit approval by the release manager, no (or by BDFL
pronouncement).
The point of the betas is that *only* bugs ge
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
This might be a duplicate of issue 1099. Can you try building with
--enable-universalsdk ?
__eprintf should have been defined in libgcc, or else assert() should
not call it. To investigate this further, you should determine how many
Changes by Martin v. Löwis <[EMAIL PROTECTED]>:
--
resolution: -> works for me
status: open -> closed
versions: +3rd party -Python 3.0
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
Can you please try XCode 2.5? See issue 3533 for a report that says that
upgrading solved the problem.
--
nosy: +loewis
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
What Python version exactly are you using? This might have been fixed in
2.5.2, with r60117.
--
nosy: +loewis
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
> The last beta is arriving soon. We need to go ahead on this, or retarget
> it for 2.7/3.1.
I'll look into it tomorrow.
Regards,
Martin
___
Python tracker <[EMAIL PROTECTED]>
Changes by Martin v. Löwis <[EMAIL PROTECTED]>:
--
assignee: -> loewis
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3542>
___
___
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
Lists of possible string encodings are here:
http://developer.apple.com/documentation/CoreFoundation/Reference/CFStringRef/Reference/reference.html#//apple_ref/c/tdef/CFStringBuiltInEncodings
and
http://developer.apple.com/documen
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
I like to challenge the view what "correct" behavior is here. If I
pickle an array of 32-bit integer values on one system, and unpickle it
as an array of 64-bit integer values on a different system, is that
correct, or
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
I have now committed the patch to 2.6 as r65654, adding changes for the
bz2module.
I also decided to make the Py_buffer structure own its reference, as I
was running out of arguments why not to. In the process, I r
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
I also started working on porting it to 3.0, but couldn't complete that
port yet - the memoryview object doesn't play nicely.
___
Python tracker <[EMAIL PROTECTED]>
<http://
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
As you must be building your own Python DLL, anyway, can't you just
simply remove that code if you don't want it?
--
nosy: +loewis
___
Python tracker <[EMAIL PROTECTED]>
&
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
> 2) We have to remember to do this change every time we upgrade to a
> newer version of Python.
Every new MSVC release brings new problems, as far back as I remember.
Did you actually try to turn it off? Did it work? What if
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
> I've seen your recent merge and I don't know if you have finished with
> it.
Indeed, I'm done, r65654. Unless there are actual bugs in these patches
(in the sense that they don't fix the reported problem,
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
Ok, now that we have established that the user's encoding is supposed to
be mac-celtic, I think I understand the problem: there simply isn't any
IANA charset name for the mac-celtic encoding, so
CFStringConvertEncodingT
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
0x27==39. It's all fine.
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3362>
___
_
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
I think changing the array constructor is fairly easy: just pick a set
of codes that are defined to be platform-neutral (i.e. for each size two
codes, one for each endianness). For example, the control characters
(\0..\x1F) could be u
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
Sure. Feel free to commit any further changes to these build files directly.
--
status: open -> closed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.py
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
> I have not yet seen any examples where the are erroneous assertions.
Please take a look at the code in signalmodule.c. The MS CRT asserts
that the signal number is supported (i.e. among a fixed list of signal
numbers), even th
Changes by Martin v. Löwis <[EMAIL PROTECTED]>:
--
resolution: -> wont fix
status: open -> closed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
I couldn't reproduce the problem (and apparently, many of the buildbots
can't, either). It depends on whether you have openssl available, i.e.
whether hashlib can be built. I explicitly disabled use of OpenSSL on my
syst
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
> I'm a bit confused. In the PyBuffer_Release implementation you
> committed, there is no DECREF at all.
Oops, I meant to make the reference own by Py_buffer, but actually
forgot to implement that. Fixed in r65677, r65678.
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
The patch is really trivial, and attached.
Added file: http://bugs.python.org/file4/refcount.diff
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
> By the way, even without that patch, there is a memory leak:
With the patch, this memory leak goes away.
Regards,
Martin
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.py
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
The patch looks fine (as far as it goes).
I do think the same should be done to the reader: IO libraries typically
provide a promise that concurrent threads can read, and will get the
complete stream in an overlapped manner (i.e. each
New submission from Martin v. Löwis <[EMAIL PROTECTED]>:
It appears that test_unicode::test_raiseMemError was meant to produce a
MemoryError. Unfortunately, on my machine (Linux 2.6.25, 32-bit
processor, 1GiB main memory, plenty swap), allocation *succeed*, and
then brings the machine to
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
> It doesn't happen with bytearrays, so I suspect it's that you only
> DECREF when releasebuffer method exists:
Thanks, that was indeed the problem; this is now fixed in r65683 and r65685.
My initial observation tha
Changes by Martin v. Löwis <[EMAIL PROTECTED]>:
--
resolution: -> fixed
status: open -> closed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
> So are you saying that if I had libopenssl (or whatever the name is)
> installed and linked with Python, it would bypass the use of _md5 and
> _sha1, and call the hash functions in libopenssl instead?
Correct. Those modu
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
Thanks for the report. Fixed in r65690.
--
nosy: +loewis
resolution: -> fixed
status: open -> closed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
Why is this a "critical" bug?
--
nosy: +loewis
___
Python tracker <[EMAIL PROTECTED]>
<http://
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
I still don't think such a change should be made, hence I reject this
report as "won't fix". Discussion shouldn't start again on this matter
until there is an actual patch to review.
--
resolu
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
> Because it should be fixed before 3.0 final?
And why should that be done? IMO, this can still
be fixed in 3.1, or not a fixed at all - I fail to
see the true bug (apart from the minor r
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
> I've filed this as critical because it is a new API and, if we change
> it, we'd better change it before 3.0 is released.
I don't think it is API. The structure may be defined in a public
header, but it is not i
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
Please try out the file at
https://www.dcl.hpi.uni-potsdam.de/home/loewis/python-2.6.14106.msi
and report whether it fixes the issue.
___
Python tracker <[EMAIL PROTECTED]>
<http://
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
Please try out the file at
http://www.dcl.hpi.uni-potsdam.de/home/loewis/python-2.6.14106.msi
and report whether it fixes the issue.
___
Python tracker <[EMAIL PROTECTED]>
<http://
Changes by Martin v. Löwis <[EMAIL PROTECTED]>:
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2271>
___
___
Python-bugs-list mailing list
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
> 1. [TARGETDIR] will stay on the path. I think that is fine, since the
> python.exe will be gone, so will never be executed. Do you agree?
Completely disagree. Adding something to PATH is nearly unacceptable
clutter
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
Ok, so it seems there is no memory leak. Changing the title accordingly.
--
title: memory leak in make test (in "test list"), 2.5.2 not 2.5.1, Linux 64bit
-> test_list uses unreasonable amounts of mem
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
> 2. Rename "tostring" and "fromstring" methods to "tobytes" and
> "frombytes". I think this is quite important as the value being returned
> can no longer be described as a &
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
Thanks for the report. This is now fixed in r65709.
The right approach is to use the MS "wide string" API whereever
possible, e.g. invoke MsiSummarySetPropertyInfoW (instead of
MsiSummarySetPropertyInfo, as
Changes by Martin v. Löwis <[EMAIL PROTECTED]>:
--
resolution: -> fixed
status: open -> closed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
> I wonder if it might be most effective to make a _testcapi interface to
> PyErr_NoMemory.
How would that work in this case? (I actually don't know what the test
purpose of this test is.)
_
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
> Can you test with that patch?
I personally can't test it for the next three weeks, sorry.
___
Python tracker <[EMAIL PROTECTED]>
<http://bu
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
Since this is marked "release blocker", I'll provide a shallow comment:
I don't think it should be a release blocker. It's a bug in the compile
function, and there are various work-arounds (such as saving th
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
> As for treating Latin-1 as a raw encoding, how can that be theoretically
> okay if the parser assumes UTF-8 and Latin-1 is not a superset of Latin-1?
The parser doesn't assume UTF-8, but "ascii+", i.e. it passe
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
I don't think this codec should be named IA-5. IA-5 is specified in
ITU-T Rec. T.50 (International Alphabet No. 5), recently renamed to
"International Reference Alphabet", and it does *not* specify that the
character
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
I think the patch is fairly incomplete. "i" still stays at uint, so if
numarenas would ever overflow uint, the loop would never reach
numarenas, and all arenas would get discarded.
Likewise, maxarenas still stays at uint, s
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
> In my humble opinion it should be safe to limit the amount of arenas to
> UINT_MAX instead of PY_SIZE_MAX. 4,294,967,295 arenas should be more
> than sufficient for the next decade or two. Do you concur?
It is certainl
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
> This is my first excursion into cyclic garbage collector
> implementations, so please review carefully.
If you don't implement a tp_clear function, you should leave
a comment why not. I think it's ok, since the unde
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
I'm not sure this is a bug. sys.getsizeof doesn't take padding in the
malloc implementation into account, either, so a long object that
accounts to 22 bytes (such as the number 1) uses at least 24 bytes,
also. In any case, I
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
The intention is that different interpreters have distinct, separate
instances of the type objects. This is desirable in case of class
variables, and standard for Python-defined types. Clearly, 3.0 won't
provide that separation
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
> I will try to do that patch in coming weeks (obmalloc mostly allocates
> some 256KB arenas so it should nearly always use mmap).
Exactly so. If you can, please also consider supporting Windows, in the
same way.
Anything in o
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
Also, can you please attach your config.log?
--
nosy: +loewis
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
Why do you think this is a bug in Python? It sounds like a bug in the
operating system to me.
(actually, it's two bugs - please use separate bug reports in the future:
one is that Solaris doesn't implement wchgat, and the o
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
The patch looks fine to me, please apply.
--
assignee: -> amaury.forgeotdarc
keywords: -needs review
nosy: +loewis
resolution: -> accepted
___
Python tracker <[EMAIL PR
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
> OTOH, if for some compelling reason it's believed Python knows better
> than platform vendors, then obmalloc should be uglied-up on all paths to
> make the enlightened choice.
I'm proposing that obmalloc is ch
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
Ah, now I see the problem. This is ctypes-specific, and ctypes requires
gcc on Solaris. Closing as "won't fix".
--
resolution: -> wont fix
status: open -> closed
___
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
> I filed that as a bug against Python 2.6, because in 2.5.2, the curses
> modules could be built just fine.
So would you like to work on a patch?
___
Python tracker <[EMAIL PR
New submission from Martin v. Löwis <[EMAIL PROTECTED]>:
This is a patch to update the Unicode database. It's mostly the imported
data, but there were two code changes:
- 5.1 changes the "mirrored" property for a character (U+0F3A), and the
delta-to-3.2 code did not support
Changes by Martin v. Löwis <[EMAIL PROTECTED]>:
--
keywords: +patch -needs review
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3811>
___
Changes by Martin v. Löwis <[EMAIL PROTECTED]>:
--
keywords: +needs review
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3811>
___
_
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
I don't think this needs to be resolved before 2.6, not without a
pronouncement from a lawyer advising the PSF. Layman's analyses of legal
issues are void.
Thus lowering the priority.
--
nosy: +loewis
priority:
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
Closing it as fixed then.
--
resolution: -> fixed
status: open -> closed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
Closing as a duplicate of issue3628
--
nosy: +loewis
resolution: -> duplicate
status: open -> closed
superseder: -> IDLE does not run with Py30b3
___
Python tracker <[EMAIL
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
Did you install it for all users, or just for yourself?
--
nosy: +loewis
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
Ah, it seems that this installer is lacking the MS CRT. This should be
fixed in the release candidate.
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
> Rather than arguing about the necessity of including the license
> of a 3rd party file that we intend to include in a wide-spread
> software release, wouldn't it be easier to just add the file
> and be done with it,
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
There is a stand-alone installer for it, but I don't have the time to
google for it right now (it was announced in earlier alpha releases,
when the CRT wasn't included - it has "redistributable" in its name).
Not
1301 - 1400 of 4778 matches
Mail list logo
