I'm happy to report that Robin Dunn, the developer of wxPython, showed
me how to solve my VPython architectural problem, using wxPython. I
attach a test program based on wxPython that has all of the properties
I was looking for (though it needs some minor cleanups, including
quitting gracefully, an
Bruce Sherwood writes:
> ...
> There's nothing wrong with the current VPython architecture, which
> does use good style, but there are two absolute, conflicting
> requirements that I have to meet.
>
> (1) The simple program API I've shown must be preserved, because there
> exist a large number of
Thanks much for the useful suggestion, and also thanks for your
sympathy and understanding of my plight!
Bruce Sherwood
On Sun, Jul 22, 2012 at 11:50 PM, Devin Jeanpierre
wrote:
> On Sun, Jul 22, 2012 at 7:14 PM, Bruce Sherwood
> wrote:
>> (2) My hand is forced by Apple no longer supporting Car
On Sun, Jul 22, 2012 at 7:14 PM, Bruce Sherwood
wrote:
> (2) My hand is forced by Apple no longer supporting Carbon. Among
> other aspects of this, Carbon can't be used with 64-bit Python, and
> more and more Mac users of VPython want to use 64-bit Python. So there
> has to be a version of VPython
On Sun, Jul 22, 2012 at 3:48 PM, Dennis Lee Bieber
wrote:
> On Sun, 22 Jul 2012 13:04:25 -0600, Bruce Sherwood
> declaimed the following in
> gmane.comp.python.general:
>
>
>> Another way of saying this is that I'm not building an app, in which
>> case I would structure things in a simple and str
On Sat, Jul 21, 2012 at 5:47 PM, Dennis Lee Bieber
wrote:
> On Sat, 21 Jul 2012 17:10:05 -0600, Bruce Sherwood
> declaimed the following in
> gmane.comp.python.general:
>
>
>> Thanks, but the problem I need to solve does not permit putting a
>> function like runner in the main program. I'm constr
Bruce Sherwood writes:
> ...
> The failure of this test case suggests that one cannot do imports
> inside secondary threads started in imported modules, something I keep
> tripping over. But I hope you'll be able to tell me that I'm doing
> something wrong!
As you know multiple threads can be dan
Bruce Sherwood writes:
> Thanks much for this suggestion. I'm not sure I've correctly
> understood the operation "start_new_thread(lambda: __import__( module>), ())". By "your module" do you mean the user program which
> imported the module that will execute start_new_thread?
By "your_module", I
On Sat, Jul 21, 2012 at 4:16 PM, Dennis Lee Bieber
wrote:
> On Sat, 21 Jul 2012 10:11:30 -0600, Bruce Sherwood
> declaimed the following in
> gmane.comp.python.general:
>
>
>>
>> ---
>> testABA.py -- execute this file
>>
>> from ABA import *
>> print('exec testABA')
>> fro
On 07/21/2012 05:35 PM, Bruce Sherwood wrote:
> On Sat, Jul 21, 2012 at 2:53 PM, Dave Angel wrote:
>>
>> For docs on the threading thing, see:
>>
>> http://docs.python.org/library/threading.html
>>
>> " ... an import should not have the side effect of spawning a new thread
>> and then waiting for
On Sat, Jul 21, 2012 at 2:53 PM, Dave Angel wrote:
> On 07/21/2012 04:36 PM, Bruce Sherwood wrote:
>> Thanks much for this clear statement. I hadn't managed to find any
>> documentation on this specific issue.
>>
>> Bruce Sherwood
>>
>> On Sat, Jul 21, 2012 at 10:26 AM, Dave Angel wrote:
>>> Two
On 07/21/2012 04:36 PM, Bruce Sherwood wrote:
> Thanks much for this clear statement. I hadn't managed to find any
> documentation on this specific issue.
>
> Bruce Sherwood
>
> On Sat, Jul 21, 2012 at 10:26 AM, Dave Angel wrote:
>> Two of the things you mustn't do during an import:
>>
>> 1) start
Thanks much for this clear statement. I hadn't managed to find any
documentation on this specific issue.
Bruce Sherwood
On Sat, Jul 21, 2012 at 10:26 AM, Dave Angel wrote:
> Two of the things you mustn't do during an import:
>
> 1) start or end any threads
> 2) import something that's already in
On 07/21/2012 10:54 AM, Bruce Sherwood wrote:
> Thanks much for this suggestion. I'm not sure I've correctly
> understood the operation "start_new_thread(lambda: __import__( module>), ())". By "your module" do you mean the user program which
> imported the module that will execute start_new_thread?
I couldn't get a simple test case to work. I append a listing of the
little test files, all in the same folder. The diagnostic statement
print('after start_new_thread\n') works, but then nothing. Originally
I tried importing testABA.py but was worried that the circular
importing (A imports B which
Thanks much for this suggestion. I'm not sure I've correctly
understood the operation "start_new_thread(lambda: __import__(), ())". By "your module" do you mean the user program which
imported the module that will execute start_new_thread? It hadn't
occurred to me to have A import B and B import A,
Bruce Sherwood writes:
> ...
> from visual import box, rate
> b = box()
> while True:
> rate(100) # no more than 100 iterations per second
> b.pos.x += .01
>
> This works because a GUI environment is invoked by the visual module
> in a secondary thread (written mainly in C++, connected to
Dieter Maurer commented the following on my question about a thread
import problem:
--
In a recent discussion in this list someone mentioned that
on module import, you should not start a thread. The reason: apparently,
Python uses some kind of locking during import which can
Bruce Sherwood writes:
> I'm trying to do something rather tricky, in which a program imports a
> module that starts a thread that exec's a (possibly altered) copy of
> the source in the original program, and the module doesn't return.
> This has to do with an attempt to run VPython in the Mac Co
I'm trying to do something rather tricky, in which a program imports a
module that starts a thread that exec's a (possibly altered) copy of
the source in the original program, and the module doesn't return.
This has to do with an attempt to run VPython in the Mac Cocoa
context, in which Cocoa is re
20 matches
Mail list logo
