Dennis Lee Bieber wrote:
normally the main file of a Python program is still the plain text,
It doesn't have to be, though -- you can do 'python somefile.pyc'
and it will happily run it.
and imported
modules are retrieved from the file system as (if found) PYC pre-compiled,
otherwise the text
Dennis Lee Bieber wrote:
What is it... A Burroughs mainframe running a version of FORTH?
The Burroughs architecture is a stack architecture, so
the machine code looks like a version of Forth in some ways.
--
Greg
--
https://mail.python.org/mailman/listinfo/python-list
Loren Wilton wrote:
One concern I have is if two users both "import widget". Are they now sharing
the widget namespace? I suspect they are, and that is probably undesirable.
Yes, they will be, unless you use sub-interpreters.
I've just been looking at the current docs for sub-interpreters,
and
Loren Wilton wrote:
I've read that Python supports 'threads', and I'd assumed (maybe
incorrectly) that these were somewhat separate environments that could
be operating concurrently (modulo the GC lock).
Not really. Python threads are just a thin wrapper around
OS threads, and don't provide an
On Fri, Oct 7, 2016 at 3:06 PM, Loren Wilton wrote:
> If the thread has a current instruction pointer, then it must also know what
> function it is currently in, and therfore have a pointer (or some such) to
> the current function locals:
>
> def func1():
>ham = 0.0;
>ham += 1;// threa
I still don't understand why this has to be in the same process space as
the VM. Wouldn't it be a lot simpler to create a simple RPC layer (all
localhost of course) to interface between the VM and a Python server
that spins up multiple processes or sessions? Kind of like how Python
for a web ser
To be fair, the sharing of data between threads is no different from
other concerns about global state. The only thing threads change is
that you can have multiple functions doing stuff at once.
state = [1,2,3]
def func():
state[1] += 5
# do work
state[1] -= 5
It occurs to me that thr
From: "Paul Rubin"
I don't think Python threads are the answer. You want a separate
interpreter per user, which is annoying to do with CPython. Do you have
concrete performance expectations about the sharing of data between
interpreter sessions? Those old mainframes were very slow compared to
On 10/06/2016 07:48 PM, Chris Angelico wrote:
> If that had been your original plan, it's dead simple to enhance it to
> use per-user module names. Just do this same work, but substitute a
> different module name right at the beginning! Other
> extremely-high-level interface functions are similar.
On Fri, Oct 7, 2016 at 12:52 PM, Paul Rubin wrote:
> "Loren Wilton" writes:
>> I've read that Python supports 'threads', and I'd assumed (maybe
>> incorrectly) that these were somewhat separate environments that could
>> be operating concurrently (modulo the GC lock). I assume that data can
>> be
"Loren Wilton" writes:
> I've read that Python supports 'threads', and I'd assumed (maybe
> incorrectly) that these were somewhat separate environments that could
> be operating concurrently (modulo the GC lock). I assume that data can
> be shared between the threads,
Threads all run in the same
On Fri, Oct 7, 2016 at 12:21 PM, Loren Wilton wrote:
> The VM is a program running on Windows. The mainframe object code is just
> byte code. The VM has routines to handle every operator and each kind of
> Descriptor that they might validly use. One form of Descriptor is only used
> by the CALL in
On Fri, Oct 7, 2016 at 11:22 AM, Loren Wilton wrote:
>> Ah, that probably means you want separate interpreters, then.
>
>
> I hope not, unless I can get separate simultaneous interpreters out of one
> CPython.dll in one Windows process space. I'm guessing that I can't, but
> since I really don't k
No idea as it's still not clear what you want to accomplish exactly.
You are providing a lot of details, just not concrete ones that show how
things are currently done and how you want to change that by adding
Python to the mix.
Hum, this could take a lot of pages of text to describe how the exi
On Fri, Oct 7, 2016 at 11:03 AM, Loren Wilton wrote:
> I've read that Python supports 'threads', and I'd assumed (maybe
> incorrectly) that these were somewhat separate environments that could be
> operating concurrently (modulo the GC lock). I assume that data can be
> shared between the threads,
Ah, that probably means you want separate interpreters, then.
I hope not, unless I can get separate simultaneous interpreters out of one
CPython.dll in one Windows process space. I'm guessing that I can't, but
since I really don't know what I'm doing with Python yet, maybe I'm wrong
there.
On 10/06/2016 06:03 PM, Loren Wilton wrote:
>> So I take it that currently users access the software running in the
>> virtual mainframe over telnet or some form of serial link and that they
>> interact with it in a text terminal? This point is fairly important,
>> because if it's true, then you r
So I take it that currently users access the software running in the
virtual mainframe over telnet or some form of serial link and that they
interact with it in a text terminal? This point is fairly important,
because if it's true, then you really don't have any in-band way of
clients talking to
On Fri, Oct 7, 2016 at 9:47 AM, Loren Wilton wrote:
> I don't think my main concern here is being able to call the CPython
> interpreter routines, but instead it is to be able to provide separate
> sandboxes for the various programs ("stacks", in B6500 terminology) that
> might have their own Pyth
On 10/06/2016 04:47 PM, Loren Wilton wrote:
> The Python code is running as (I hope) a native Windows DLL, so should be
> able to access any existing Python libraries that exist on the WIndows
> machine. Obviously this Python code will be using Windows-shaped data
> objects like integers, floats
On Fri, Oct 7, 2016 at 9:09 AM, Loren Wilton wrote:
>> Okay. Before you go one micron further, answer this critical question:
>>
>> *Do you trust your users?*
>
>
> The basic answer is yes. This program amounts to a virtual machine
> implementation of a multi-processor and multi-user mainframe com
"Loren Wilton" writes:
I don't think my main concern here is being able to call the CPython
interpreter routines, but instead it is to be able to provide separate
sandboxes for the various programs ("stacks", in B6500 terminology)
that might have their own Python sessions or programs.
This is
"Loren Wilton" writes:
> I don't think my main concern here is being able to call the CPython
> interpreter routines, but instead it is to be able to provide separate
> sandboxes for the various programs ("stacks", in B6500 terminology)
> that might have their own Python sessions or programs.
Thi
the multi-user program is a virtual machine
implementation
and the programs running on the machine have resources
like variables, arrays, files, and databases
Python variables? Python arrays (lists? tuples?)? Or some other sort of
"variables" and "arrays" that exist outside of Python?
You _re
We need to understand first what the process/threading/per-user model of
the existing application is.
The program is a virtual machine for an old mainframe architecture. You
could think of a VM running a Linux implementaiton as a kind of crude mental
reference model.
The emulated mainframe i
Okay. Before you go one micron further, answer this critical question:
*Do you trust your users?*
The basic answer is yes. This program amounts to a virtual machine
implementation of a multi-processor and multi-user mainframe computer. It
runs on a Windows box of its own. It has an IO subsyst
On 06/10/16 22:40, Loren Wilton wrote:
the multi-user program is a virtual machine
implementation
That's not relevant (unless you mean each user is running in their own
VM, in which case you _really_ need to describe your execution environment).
BTW, you _really_ need to describe your execut
"Loren Wilton" writes:
> While it is certianly possible to marshall every variable access
> through IPC, it isn't real efficient. I would much perfer to avoid
> this if I possibly can.
Maybe you could use Python proxy objects accessing a shared memory
segment. Though as Chris Angelico mentions,
On Fri, Oct 7, 2016 at 7:59 AM, Jolly Good Spam
wrote:
> I have a Windows multi-user program that can be used by an arbitrary number
> of users at once. They can work independently, or they can share data at the
> file or even variable level if they want. I want to give them the ability to
> write
On 06/10/16 22:11, Paul Rubin wrote:
"Jolly Good Spam" writes:
Can someone please suggest what I should be looking at and doing to be
able to effectively run multiple independent Pythons in a single
program?
Put each Python in a separate process and communicate by IPC.
Loren says that this
"Jolly Good Spam" writes:
> Can someone please suggest what I should be looking at and doing to be
> able to effectively run multiple independent Pythons in a single
> program?
Put each Python in a separate process and communicate by IPC.
--
https://mail.python.org/mailman/listinfo/python-list
31 matches
Mail list logo
