Thanks for doing this, Robert. A couple of suggestions:
I'd use omniORB (omniorb.sourceforge.net, LGPL/GPL) instead of Fnorb.
It's a very well-done piece of software, it's Open Group certified,
it's been updated more recently (by better than a year), and includes
more tools. In addition, the omn
On Apr 11, 2005, at 4:12 PM, Russell E. Owen wrote:
Robert Kern <[EMAIL PROTECTED]> wrote:
MacEnthon is the OS X counterpart to the popular "Enthought Edition"
of
Python: a convenient bundling of a number of packages geared for the
scientific community. Right now, it targets the Apple-installed Py
Tom Pollard wrote:
Actually, I was wondering how safe it would be to install MacEnthon if I
already had a significant number of these packages installed?
Everything I have was either built locally against the standard system
Python 2.3 or installed from one of Bob Ippolito's binary packages.
> This looked promising, so I tested it - for about five minutes. This
> beast is less ergonomic than standard Emacs and less ergonomic than
It does look like it is an attempt at "emacs for mac users" which is
very different than "mac-emacs for emacs users". Your review makes
it very clear why I
[Someday, I'll figure out how to work a mail program. Sorry for the
repeats, Russell.]
Russell E. Owen wrote:
> In article <[EMAIL PROTECTED]>, Robert Kern <[EMAIL PROTECTED]>
wrote:
>
>
>> MacEnthon is the OS X counterpart to the popular "Enthought Edition"
>> of Python: a convenient bundling o
In article <[EMAIL PROTECTED]>, Robert Kern <[EMAIL PROTECTED]>
wrote:
> MacEnthon is the OS X counterpart to the popular "Enthought Edition" of
> Python: a convenient bundling of a number of packages geared for the
> scientific community. Right now, it targets the Apple-installed Python
> 2.3
In article <[EMAIL PROTECTED]>,
Charles Hartman <[EMAIL PROTECTED]> wrote:
> That is really, really helpful. I've been using Custom Key Bindings for
> this, because my first attempt to make a keymap file didn't work well.
> This is much cleaner (though it has the temporary disadvantage that
>
On Apr 11, 2005, at 12:15 PM, has wrote:
Bob wrote:
- OSA uses Component Manager - not Apple events - to communicate
with language components, so the MacPythonOSA component would need
to handle each OSA call, stuff its arguments into an IPC message,
send the message to the script daemon to proce
Bob wrote:
>>- OSA uses Component Manager - not Apple events - to communicate with
>>language components, so the MacPythonOSA component would need to handle each
>>OSA call, stuff its arguments into an IPC message, send the message to the
>>script daemon to process and wait for its response. (T
On Apr 11, 2005, at 10:03 AM, Arthur Elsenaar wrote:
On Apr 10, 2005, at 23:07, Jack Jansen wrote:
On 2-apr-05, at 17:24, J. Devaney wrote:
I'm working on a python project that requires audio I/O (via the
soundcard) - I basically just need a stream that can be analyzed in
real-time and stored to a
On Apr 10, 2005, at 23:07, Jack Jansen wrote:
On 2-apr-05, at 17:24, J. Devaney wrote:
I'm working on a python project that requires audio I/O (via the
soundcard) - I basically just need a stream that can be analyzed in
real-time and stored to a file. I've looked into various options -
such as por
On Apr 11, 2005, at 5:06 AM, has wrote:
Bob wrote:
A multi-process model would be a lot more robust overall. [...] If
you [...] communicate with existing Python interpreters
exclusively, it would probably be much better overall (though much
more work).
Yep, removing Python from the component wou
Bob wrote:
>>>A multi-process model would be a lot more robust overall. [...] If you [...]
>>>communicate with existing Python interpreters exclusively, it would probably
>>>be much better overall (though much more work).
>>
>>Yep, removing Python from the component would require quite a lot mor
13 matches
Mail list logo
