Is there anywhere I can download a set of Python
binaries, of any version, that have been built
with Visual C++ 8.0?

I'm trying to hook Python up to Sketchup 7 on
Windows, and I think I'm having problems because
Sketchup is linked with msvcr80.dll.

On Feb 8, 10:51 pm, Greg Ewing <gregew> wrote:
> Is there anywhere I can download a set of Python
> binaries, of any version, that have been built
> with Visual C++ 8.0?
>
> I'm trying to hook Python up to Sketchup 7 on
> Windows, and I think I'm having problems because
> Sketchup is linked with msvcr80.dll.

I'm pretty sure 2.6.1 is compiled with 8.0. However, I think the
Visual C++ 8.0 uses msvcrt90.dll.

Take a look at this bug report to see if it's related to your issue:

http://bugs.python.org/issue4566


Carl Banks

On Mon, Feb 9, 2009 at 4:14 PM, Carl Banks <pavlovevidence> wrote:
> On Feb 8, 10:51 pm, Greg Ewing <gregew> wrote:
>> Is there anywhere I can download a set of Python
>> binaries, of any version, that have been built
>> with Visual C++ 8.0?
>>
>> I'm trying to hook Python up to Sketchup 7 on
>> Windows, and I think I'm having problems because
>> Sketchup is linked with msvcr80.dll.
>
> I'm pretty sure 2.6.1 is compiled with 8.0.

Hm, I have just run python to check: it is built with MSC v.1500,
which corresponds to VS 2008, e.g. VS 9, at least on 32 bits.

David

On 9/02/2009 5:51 PM, Greg Ewing wrote:
> Is there anywhere I can download a set of Python
> binaries, of any version, that have been built
> with Visual C++ 8.0?

IIRC, no. Python skipped that version of MSVC. I believe Python 2.5
builds easily with vc8 project files in svn though.

> I'm trying to hook Python up to Sketchup 7 on
> Windows, and I think I'm having problems because
> Sketchup is linked with msvcr80.dll.

What problems specifically? The only practical problems you should see
will arise if you try and pass a "FILE *", or allocate memory you then
ask python to free (or vice-versa) - both should be avoidable though...

Mark

Carl Banks <pavlovevidence> wrote:
>
>I'm pretty sure 2.6.1 is compiled with 8.0. However, I think the
>Visual C++ 8.0 uses msvcrt90.dll.

No, the two digits of the DLL match the version number of C++. The
confusion arises because the product is called "Visual Studio 2008", but it
includes Visual C++ 9.0, and hence msvcrt90.dll. People say "VC8" when
they really mean Visual Studio 2008.

Visual Studio 98 - VC++ 6.0
Visual Studio 2002 - VC++ 7.0
Visual Studio 2003 - VC++ 7.1
Visual Studio 2005 - VC++ 8.0
Visual Studio 2008 - VC++ 9.0

In case anyone is interested: Gideon Smeding of the University of
Utrecht has written a masters' thesis titled "An executable
operational semantics for Python". It is actually a formal semantics
for a Python subset called minpy. Per the blurb, the semantics are
described in literate Haskell that is compiled to an interpreter as
well as a formal specification. Somehow there has to be a a reference
about "unless you're Dutch" to be made about this ;-).

Further info is at:
http://gideon.smdng.nl/2009/01/an-ex...cs-for-python/

I found this link via the Haskell Weekly News, http://sequence.complete.org .

Mark Hammond wrote:

> What problems specifically? The only practical problems you should see
> will arise if you try and pass a "FILE *", or allocate memory you then
> ask python to free (or vice-versa) - both should be avoidable though...

It concerns a Ruby plugin for Sketchup that embeds a Python
interpreter and acts as a bridge between Ruby and Python.
I'm using Sketchup 7 which uses msvcrt80.dll, and includes
a Ruby dll which is presumably also linked against that
crt.

I've made some progress on the issue. One problem turned out to
be a result of allocating something with ruby_xmalloc() and
freeing it with free(), which was easy to fix.

Another one seemed to be something to do with trying to use
a global var that points to the current Ruby stack frame. I
don't really know what was happening, but I found another way
of doing things that sidestepped the issue.

I've now got it working, at first sight anyhow, using Python 2.3.

But it doesn't work properly with Python 2.5. The problem
appears to be related to compiling .py files to .pyc. The
first time I run it and try to import a module, a .pyc is
generated, but then a crash occurs when trying to call one
of the functions imported from it. If I run it a second time,
with the previously generated .pyc in place, it runs successfully.

Which makes me think it may be some kind of FILE * problem,
but I'm not sure what, since all the stdio operations on
the files concerned should be getting done by Python.

To add insult to injury, it's proving to be very difficult
to debug, because Sketchup seems to crash all on its own
when run under gdb on Windows, even when I don't load any
of my code. So I can't get a traceback of where the crash
is occurring.

There's one possibility I just thought of -- Python may
be trying to write something to stdout or stderr, in which
case it will probably be using the wrong crt to do it.
Something to look into after I've got some sleep...

Paul Rubin:
> Gideon Smeding of the University of
> Utrecht has written a masters' thesis titled "An executable
> operational semantics for Python".

A significant part of Computer Science is a waste of time and money.

Bye,
bearophile

Paul Rubin <http://phr.cx> wrote:

>In case anyone is interested: Gideon Smeding of the University of
>Utrecht has written a masters' thesis titled "An executable
>operational semantics for Python".

That's an interesting grammatical construct. I would have said either
"Executable operational semantics for Python," or "An executable
operational semantic for Python."

"A semantics" just doesn't flow.

On Feb 9, 11:34 pm, Tim Roberts <t> wrote:
> Carl Banks <pavlovevide> wrote:
>> No, the two digits of the DLL match the version number of C++.  The
> confusion arises because the product is called "Visual Studio 2008", but it
> includes Visual C++ 9.0, and hence msvcrt90.dll.  People say "VC8" when
> they really mean Visual Studio 2008.
>
>   Visual Studio 98    -  VC++ 6.0
>   Visual Studio 2002  -  VC++ 7.0
>   Visual Studio 2003  -  VC++ 7.1
>   Visual Studio 2005  -  VC++ 8.0
>   Visual Studio 2008  -  VC++ 9.0

Ah, that explains a lot.


Carl Banks