Rocco Moretti | 4 May 22:17 2003
Picon

Extending the ObjectSpace Concept


I think it may be worthwhile to extend the concept of Object Spaces to the 
bytecode and sourcecode levels. (Provisional names: BytecodeSpace and 
SyntaxSpace.) Just as an ObjectSpace embokdies the abstract concept of the 
semantics of objects and their interactions, a Bytecode space embodies the 
concept of the bytecode and its effect on execution flow control. 
Likewise, a SyntaxSpace embodies the abstract concept of the textual 
program and its mapping onto bytecode and object definitons.

Now, these spaces are distinct, but they are not independant. The 
SyntaxSpace needs to know which BytecodeSpace and ObjectSpace to use to 
output functions and objects, a BytecodeSpace needs to know what 
ObjectSpace to use to implement object interactions, and an ObjectSpace 
needs to have some idea about SyntaxSpaces and Bytecode spaces so that it 
can compile strings and execute functions.

As I imagine it currently, the ObjectSpace will be the controlling space. 
A string or file is given to the ObjectSpace to execute. It passes the 
string to the SyntaxSpace, which then compiles it into a number of 
ObjectSpace objects, including module, function and code objects. The 
object space then executes those functions by passing them to the 
appropriate BytecodeSpace. In the process of execution, the BytecodeSpace 
then calls back to the ObjectSpace to implement the object semantics.

Note that there is a distinction between BytecodeSpaces and the an 
ExecutionContext, in that each BytecodeSpace would have singleton 
semantics, but there can be multiple different ExecutionContexts. (Perhaps 
it could be as simple as a class/instance distinction.) Perhaps the 
Bytecode/Syntax Spaces don't need to be actual entities, but could stay as 
abstract concepts.
(Continue reading)

Michael Hudson | 5 May 20:41 2003
Picon

Re: Extending the ObjectSpace Concept

roccomoretti <at> netscape.net (Rocco Moretti) writes:

[...]
> Which sort of leads me to the reason I got on this train of thought. Over 
> the past couple of weeks I've been trying to fix the remaining bugs in the 
> trivial object space. Some of them seem to stem (at least in part) to the 
> lack of a separate sys/builtins module for the application level code. (As 
> was mentioned earlier by mwh). I've attempted to fix it by special casing 
> the builtin __import__(). However, in order to do so, __import__() needs 
> to be able to call out to interpreter level python functions. With the 
> current TrivialObjectSpace, that's impossible as all python functions are 
> run through the pypy interpreter.

Yes!  I ran into this a few weeks back but then forgot exactly what
the issue was :-(

[...]
> Does any of this sound reasonable? I tried to explain it well, but I'm 
> quite sure I failed, so if you have any questions, please ask. 

No, your description of the problem and solution made much sense over
here.

Are you coming to the sprint in May?

Cheers,
M.

--

-- 
  I also fondly recall Paris because that's where I learned to
(Continue reading)

Armin Rigo | 6 May 15:58 2003

Linking to the web page

Hello,

I've had feedback from someone not finding Pypy's web pages. He says the 
mailing list page is showing up in a Yahoo search but not the 
http://codespeak.net/pypy/. Can someone please add a link to the latter from 
the former ? Thanks !

Armin
_______________________________________________
pypy-dev <at> codespeak.net
http://codespeak.net/mailman/listinfo/pypy-dev

Armin Rigo | 6 May 19:00 2003

Re: Extending the ObjectSpace Concept

Hello Rocco,

(Firstly, sorry for the lack of answers to your contributions; you seem to be
the most active person on pypy right now...)

On Sun, May 04, 2003 at 04:17:34PM -0400, Rocco Moretti wrote:
> I think it may be worthwhile to extend the concept of Object Spaces to the 
> bytecode and sourcecode levels. (Provisional names: BytecodeSpace and 
> SyntaxSpace.)

Ok. It makes sense. I should write a bit more about what I intended to use
ObjectSpaces for, though, and see how explicit Bytecode/Syntax spaces fit in
the picture. I promize I'll. In particular, I don't think about ObjectSpaces
as controlling spaces, as you do, so there is some idea matching to do there
:-)

> If accepted, one change that should be made is to shift the function call 
> semantics in the object space to have an explicit execution context as a 
> parameter, so that it is clear that the ObjectSpace is controling 
> execution.

That's not clear, because almost any other operation could indirectly do a 
function call (e.g. hash() calling the class' __hash__() method).

> (...) __import__(). However, in order to do so, __import__() needs 
> to be able to call out to interpreter level python functions. With the 
> current TrivialObjectSpace, that's impossible as all python functions are 
> run through the pypy interpreter.

Yes; we miss a way to call interpreter-level functions from
(Continue reading)

Grégoire Weber | 7 May 12:08 2003

PyPy and Zope3-Sprints before Europython

Hi people,

I'm organizing (wich Godefroid, gotcha AT pop.swing DOT be) the Zope3 
sprint hold in parallel to your PyPy sprint before the europython 
conference.

Can somebody confirm the dates you planed the sprints:

   22 of June to the 24 of june 2003 ?

Thanks!

Gregoire

P.S.: Godefroid will be your contact in the next two and a half weeks,
      as I have to go to my yearly military service.
_____________________________________
Grégoire Weber
Rigistr. 31
CH-8006 Zürich
Switzerland
phone:  +41-(0)1-361 66 11
mobile: +41-(0)79-44 11 457
mailto:gregoire.weber <at> switzerland.org

_______________________________________________
pypy-dev <at> codespeak.net
http://codespeak.net/mailman/listinfo/pypy-dev

(Continue reading)

Godefroid Chapelle | 15 May 09:39 2003
Picon

EuroPython 2003 sprints

Hi all,

Two sprints (Pypy and Zope3) will be organised on June 22-24 in 
Louvain-la-Neuve, very near Charleroi.

I send you this information so that you can make your rooms reservations.

The classrooms are still not definitely confirmed but there should be no 
problems to get free access to the classrooms on those Sunday, Monday and 
Tuesday.

Still, if you have any money problem, make sure you can cancel without too 
much expenses.

You will find any needed information at
http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/EuroPython2003Sprint

Gregoire Weber is taking the lead of the Zope3 sprint organization. I'll be 
the contact till he comes back from military service at the end of this month.

I'd appreciate if the Pypy sprint leader(s) could contact me.
--

Godefroid Chapelle

BubbleNet sprl
rue Victor Horta, 18 / 202
1348 Louvain-la-Neuve
Belgium

(Continue reading)

Rocco Moretti | 20 May 05:15 2003
Picon

Re: Extending the ObjectSpace Concept

Michael Hudson <mwh <at> python.net> wrote:

>roccomoretti <at> netscape.net (Rocco Moretti) writes:
>
>[...]
>> Which sort of leads me to the reason I got on this train of thought. Over 
>> the past couple of weeks I've been trying to fix the remaining bugs in the 
>> trivial object space. Some of them seem to stem (at least in part) to the 
>> lack of a separate sys/builtins module for the application level code. (As 
>> was mentioned earlier by mwh). I've attempted to fix it by special casing 
>> the builtin __import__(). However, in order to do so, __import__() needs 
>> to be able to call out to interpreter level python functions. With the 
>> current TrivialObjectSpace, that's impossible as all python functions are 
>> run through the pypy interpreter.
>
>Yes!  I ran into this a few weeks back but then forgot exactly what
>the issue was :-(

Although I don't know exacally the problems you had with your 
implementation, there are two somewhat different issues that I came 
across. The first is that any Python function called by interpreted code 
is also interpreted. This means we can never "escape" to the interpreter 
level python code. The second is that even if it was possible to call 
interpreter level functions, an application level __import__() would not 
have any references to those functions anyway, and so would not be able to call them in the first place. 

>Are you coming to the sprint in May?

Unfortunately, due to my schedule, I cannot. But I wish the best of luck 
to those who can.
(Continue reading)

Rocco Moretti | 20 May 06:04 2003
Picon

Re: Extending the ObjectSpace Concept

Armin Rigo <arigo <at> tunes.org> wrote:

>On Sun, May 04, 2003 at 04:17:34PM -0400, Rocco Moretti wrote:
>> I think it may be worthwhile to extend the concept of Object Spaces to the 
>> bytecode and sourcecode levels. (Provisional names: BytecodeSpace and 
>> SyntaxSpace.)
>
>Ok. It makes sense. I should write a bit more about what I intended to use
>ObjectSpaces for, though, and see how explicit Bytecode/Syntax spaces fit
>in the picture. I promize I'll. In particular, I don't think about
>ObjectSpaces as controlling spaces, as you do, so there is some idea 
>matching to do there
>:-)

I think I may have not been clear on this point. I now think "controlling" is too strong a word. What I meant to
imply is that the Spaces are the codification of abstrace concepts, and are on a somewhat equal footing in
that regards. However, in an inheratance fashion, the ObjectSpaces are somewhat "superior" to either
the Bytecode or SynataxSpaces in that you can swap out the Bytecode or SyntaxSpace without much change, if
any, to the ObjectSpace, but if you rewrite the ObjectSpace, the Bytecode and SyntaxSpaces need updating
to accomidate the change.

Where "control" comes in can somewhat be seen in the bootstrapping of the intrpreter. This is how I imagine
it working (in pseudocode - method names are descriptive only):

#script is a file containing the script to run
w_str = ObjectSpace.to_string(script.read())

#ObjectSpace contains a reference to a SyntaxSpace to use to compile
# the string
w_code = ObjectSpace.compile(w_str)
(Continue reading)

Laura Creighton | 20 May 14:46 2003

we need an irc meeting about the Göteborg Sprint soon.

Tomorrow at 1900?

Laura
_______________________________________________
pypy-dev <at> codespeak.net
http://codespeak.net/mailman/listinfo/pypy-dev

holger krekel | 20 May 14:52 2003
Picon

Re: [pypy-dev] we need an irc meeting about the Göteborg Sprint soon.

[Laura Creighton Tue, May 20, 2003 at 02:46:34PM +0200]
> Tomorrow at 1900?

If you want to use the sprint list just drop me the list
of participants and i'll set it up today. We should do this
for the Belgium-sprint anyway. 

    holger
_______________________________________________
pypy-dev <at> codespeak.net
http://codespeak.net/mailman/listinfo/pypy-dev


Gmane