Re: [Pharo-dev] context mirror primitives

[Tudor Girba]

Hi,

In summary, it seems we should integrate this one.

I resolved the issue to "Resolved (Fix Review Needed)”, but it seems that the 
Monkey is still on holidays :). Does anyone know if there is a problem with it?

Cheers,
Doru


> On Jan 4, 2016, at 5:42 PM, Tudor Girba  wrote:
> 
> Hi,
> 
> The VM (both Cog and Spur) supports basic manipulation of objects without 
> relying on sending messages to those objects. These primitives are meant to 
> be handled by methods in Context. Eliot provided a changeset with these 
> methods, and they are not yet in Pharo:
> 
> object: anObject basicAt: index
> object: anObject basicAt: index put: value
> object: anObject eqeq: anOtherObject
> object: anObject instVarAt: anIndex
> object: anObject instVarAt: anIndex put: aValue
> object: anObject perform: selector withArguments: argArray inClass: 
> lookupClass
> objectClass: anObject
> objectSize: anObject
> 
> I added an issue and the slice:
> https://pharo.fogbugz.com/f/cases/17313/Missing-primitive-methods-in-Context
> 
> As I note in the issue, I think it is certainly interesting to have a more 
> powerful mirrors mechanism, but until then we should still be able to use 
> what the VM already provides.
> 
> I would like to use these primitives now to make the GT Inspector and 
> Debugger be able to work with ProtoObject. I thought these methods were 
> supposed to be in the Spur version of Pharo, but it seems they are not. So, I 
> am wondering if maybe I am not missing something. Am I missing something or 
> should we integrate these methods?
> 
> Cheers,
> Doru
> 
> --
> www.tudorgirba.com
> www.feenk.com
> 
> "Problem solving efficiency grows with the abstractness level of problem 
> understanding."
> 
> 
> 
> 

--
www.tudorgirba.com
www.feenk.com

"We are all great at making mistakes."

Re: [Pharo-dev] context mirror primitives

[Marcus Denker]

> On 05 Jan 2016, at 21:04, stepharo  wrote:
> 
> All the Inria integration got a problem and this is restarting to work.
> So we will get there.
> 

Something is still broken:

https://ci.inria.fr/pharo/

all slaves are blocked with threads that are dead.

Marcus

Re: [Pharo-dev] context mirror primitives

[Christophe Demarey]

Le 6 janv. 2016 à 08:11, Marcus Denker a écrit :

> 
>> On 05 Jan 2016, at 21:04, stepharo  wrote:
>> 
>> All the Inria integration got a problem and this is restarting to work.
>> So we will get there.
>> 
> 
> Something is still broken:
> 
> https://ci.inria.fr/pharo/
> 
> all slaves are blocked with threads that are dead.

It looks like Jenkins is mess up with a job number.
I need to find the job causing that and I think I could fix that

smime.p7s
Description: S/MIME cryptographic signature

Re: [Pharo-dev] context mirror primitives

[stepharo]

All the Inria integration got a problem and this is restarting to work.
So we will get there.

Stef

Le 5/1/16 20:38, Tudor Girba a écrit :

Hi,

In summary, it seems we should integrate this one.

I resolved the issue to "Resolved (Fix Review Needed)”, but it seems that the 
Monkey is still on holidays :). Does anyone know if there is a problem with it?

Cheers,
Doru



On Jan 4, 2016, at 5:42 PM, Tudor Girba  wrote:

Hi,

The VM (both Cog and Spur) supports basic manipulation of objects without 
relying on sending messages to those objects. These primitives are meant to be 
handled by methods in Context. Eliot provided a changeset with these methods, 
and they are not yet in Pharo:

object: anObject basicAt: index
object: anObject basicAt: index put: value
object: anObject eqeq: anOtherObject
object: anObject instVarAt: anIndex
object: anObject instVarAt: anIndex put: aValue
object: anObject perform: selector withArguments: argArray inClass: lookupClass
objectClass: anObject
objectSize: anObject

I added an issue and the slice:
https://pharo.fogbugz.com/f/cases/17313/Missing-primitive-methods-in-Context

As I note in the issue, I think it is certainly interesting to have a more 
powerful mirrors mechanism, but until then we should still be able to use what 
the VM already provides.

I would like to use these primitives now to make the GT Inspector and Debugger 
be able to work with ProtoObject. I thought these methods were supposed to be 
in the Spur version of Pharo, but it seems they are not. So, I am wondering if 
maybe I am not missing something. Am I missing something or should we integrate 
these methods?

Cheers,
Doru

--
www.tudorgirba.com
www.feenk.com

"Problem solving efficiency grows with the abstractness level of problem 
understanding."





--
www.tudorgirba.com
www.feenk.com

"We are all great at making mistakes."

Re: [Pharo-dev] context mirror primitives

[Tudor Girba]

Ok. No problem. Please let me know if I can help.

Doru


> On Jan 5, 2016, at 10:04 PM, stepharo  wrote:
> 
> All the Inria integration got a problem and this is restarting to work.
> So we will get there.
> 
> Stef
> 
> Le 5/1/16 20:38, Tudor Girba a écrit :
>> Hi,
>> 
>> In summary, it seems we should integrate this one.
>> 
>> I resolved the issue to "Resolved (Fix Review Needed)”, but it seems that 
>> the Monkey is still on holidays :). Does anyone know if there is a problem 
>> with it?
>> 
>> Cheers,
>> Doru
>> 
>> 
>>> On Jan 4, 2016, at 5:42 PM, Tudor Girba  wrote:
>>> 
>>> Hi,
>>> 
>>> The VM (both Cog and Spur) supports basic manipulation of objects without 
>>> relying on sending messages to those objects. These primitives are meant to 
>>> be handled by methods in Context. Eliot provided a changeset with these 
>>> methods, and they are not yet in Pharo:
>>> 
>>> object: anObject basicAt: index
>>> object: anObject basicAt: index put: value
>>> object: anObject eqeq: anOtherObject
>>> object: anObject instVarAt: anIndex
>>> object: anObject instVarAt: anIndex put: aValue
>>> object: anObject perform: selector withArguments: argArray inClass: 
>>> lookupClass
>>> objectClass: anObject
>>> objectSize: anObject
>>> 
>>> I added an issue and the slice:
>>> https://pharo.fogbugz.com/f/cases/17313/Missing-primitive-methods-in-Context
>>> 
>>> As I note in the issue, I think it is certainly interesting to have a more 
>>> powerful mirrors mechanism, but until then we should still be able to use 
>>> what the VM already provides.
>>> 
>>> I would like to use these primitives now to make the GT Inspector and 
>>> Debugger be able to work with ProtoObject. I thought these methods were 
>>> supposed to be in the Spur version of Pharo, but it seems they are not. So, 
>>> I am wondering if maybe I am not missing something. Am I missing something 
>>> or should we integrate these methods?
>>> 
>>> Cheers,
>>> Doru
>>> 
>>> --
>>> www.tudorgirba.com
>>> www.feenk.com
>>> 
>>> "Problem solving efficiency grows with the abstractness level of problem 
>>> understanding."
>>> 
>>> 
>>> 
>>> 
>> --
>> www.tudorgirba.com
>> www.feenk.com
>> 
>> "We are all great at making mistakes."
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
> 
> 

--
www.tudorgirba.com
www.feenk.com

"When people care, great things can happen."

[Pharo-dev] context mirror primitives

[Tudor Girba]

Hi,

The VM (both Cog and Spur) supports basic manipulation of objects without 
relying on sending messages to those objects. These primitives are meant to be 
handled by methods in Context. Eliot provided a changeset with these methods, 
and they are not yet in Pharo:

object: anObject basicAt: index
object: anObject basicAt: index put: value
object: anObject eqeq: anOtherObject
object: anObject instVarAt: anIndex
object: anObject instVarAt: anIndex put: aValue
object: anObject perform: selector withArguments: argArray inClass: lookupClass
objectClass: anObject
objectSize: anObject

I added an issue and the slice:
https://pharo.fogbugz.com/f/cases/17313/Missing-primitive-methods-in-Context

As I note in the issue, I think it is certainly interesting to have a more 
powerful mirrors mechanism, but until then we should still be able to use what 
the VM already provides.

I would like to use these primitives now to make the GT Inspector and Debugger 
be able to work with ProtoObject. I thought these methods were supposed to be 
in the Spur version of Pharo, but it seems they are not. So, I am wondering if 
maybe I am not missing something. Am I missing something or should we integrate 
these methods?

Cheers,
Doru

--
www.tudorgirba.com
www.feenk.com

"Problem solving efficiency grows with the abstractness level of problem 
understanding."

Re: [Pharo-dev] context mirror primitives

[Eliot Miranda]

Hi Doru,

> On Jan 4, 2016, at 7:42 AM, Tudor Girba  wrote:
> 
> Hi,
> 
> The VM (both Cog and Spur) supports basic manipulation of objects without 
> relying on sending messages to those objects. These primitives are meant to 
> be handled by methods in Context. Eliot provided a changeset with these 
> methods, and they are not yet in Pharo:
> 
> object: anObject basicAt: index
> object: anObject basicAt: index put: value
> object: anObject eqeq: anOtherObject
> object: anObject instVarAt: anIndex
> object: anObject instVarAt: anIndex put: aValue
> object: anObject perform: selector withArguments: argArray inClass: 
> lookupClass
> objectClass: anObject
> objectSize: anObject
> 
> I added an issue and the slice:
> https://pharo.fogbugz.com/f/cases/17313/Missing-primitive-methods-in-Context
> 
> As I note in the issue, I think it is certainly interesting to have a more 
> powerful mirrors mechanism, but until then we should still be able to use 
> what the VM already provides.

Note that a more powerful mirror implementation is still built upon these same 
primitives.  Newspeak has a rich mirror implementation, but underneath it still 
uses these primitives to reach u side of objects without sending them messages.

> I would like to use these primitives now to make the GT Inspector and 
> Debugger be able to work with ProtoObject. I thought these methods were 
> supposed to be in the Spur version of Pharo, but it seems they are not. So, I 
> am wondering if maybe I am not missing something. Am I missing something or 
> should we integrate these methods?

I can see no reason for delay.  Remember that they should be used not only in 
low level inspectors but in Context's execution simulation machinery.  Squeak 
can be used as a model, although in squeak there is still the 
ContextPart/MethodContext split.

> Cheers,
> Doru

Happy new year!

> www.tudorgirba.com
> www.feenk.com
> 
> "Problem solving efficiency grows with the abstractness level of problem 
> understanding."

_,,,^..^,,,_ (phone)

Re: [Pharo-dev] context mirror primitives

[Tudor Girba]

Hi,

> On Jan 4, 2016, at 7:42 PM, Clément Bera  wrote:
> 
> 
> 
> 2016-01-04 17:35 GMT+01:00 Tudor Girba :
> Hi,
> 
> > On Jan 4, 2016, at 6:30 PM, Clément Bera  wrote:
> >
> > Hello,
> >
> > This is unrelated to Spur / SqueakV3 memory manager. The VM support has 
> > been there and stable for a long time now.
> >
> > I tried to add those primitives in Pharo but the problem is that the 
> > debugger in Pharo uses EyeInspector whereas the inspectors are done with 
> > Glamour.
> >
> > Hence, to add support for ProtoObject debugging you need:
> > - to make interpretation implemented in Context compliant
> > - to make EyeInspector compliant (for the inspector in the debugger)
> > - to make GTInspector compliant.
> 
> I am not sure I understand what you mean by " interpretation implemented in 
> Context compliant”. Could you explain?
> 
> The generic idea is that in the debugger part of the execution is done using 
> an in-image interpreter instead of the VM. The in-image interpreter should 
> use the mirror primitives to be able to interpret correctly the code.
> 
> For example:
> 
> Context>>pushReceiverVariable: offset 
>   self push: (self receiver instVarAt: offset + 1)
> 
> should be rewritten:
> 
> Context>>pushReceiverVariable: offset 
>   self push: (self object: self receiver instVarAt: offset + 1)
> 
> Else operations such as "over" or "into" in the debugger would crash if the 
> receiver is a protoobject as they would use this code which sends a message 
> to a protoobject instead of using the mirror primitives.

Yep, I got this one. I was just not sure if there is maybe something else 
involved.

I even did an analysis of what needs to be rewritten in this sense :)
http://www.humane-assessment.com/blog/evaluating-the-reimplementation-of-key-context-methods-in-pharo

Cheers,
Doru



>  
> 
> I already made GTInspector and GTDebugger work with ProtoObject once. I lost 
> the changes in the meantime :), but I will redo them. The only thing I needed 
> were these primitives. But, maybe I missed something.
> 
> 
> This is good news. I believe such inspectors are really important if one want 
> to experiment with the kernel. The next steps would be to see if one can 
> inspect an object which class directly inherit from nil and an object which 
> has itself as a class (a prototype).
> 
>  
> Cheers,
> Doru
> 
> 
> > Cheers !
> >
> > Clement
> >
> >
> > 2016-01-04 16:42 GMT+01:00 Tudor Girba :
> > Hi,
> >
> > The VM (both Cog and Spur) supports basic manipulation of objects without 
> > relying on sending messages to those objects. These primitives are meant to 
> > be handled by methods in Context. Eliot provided a changeset with these 
> > methods, and they are not yet in Pharo:
> >
> > object: anObject basicAt: index
> > object: anObject basicAt: index put: value
> > object: anObject eqeq: anOtherObject
> > object: anObject instVarAt: anIndex
> > object: anObject instVarAt: anIndex put: aValue
> > object: anObject perform: selector withArguments: argArray inClass: 
> > lookupClass
> > objectClass: anObject
> > objectSize: anObject
> >
> > I added an issue and the slice:
> > https://pharo.fogbugz.com/f/cases/17313/Missing-primitive-methods-in-Context
> >
> > As I note in the issue, I think it is certainly interesting to have a more 
> > powerful mirrors mechanism, but until then we should still be able to use 
> > what the VM already provides.
> >
> > I would like to use these primitives now to make the GT Inspector and 
> > Debugger be able to work with ProtoObject. I thought these methods were 
> > supposed to be in the Spur version of Pharo, but it seems they are not. So, 
> > I am wondering if maybe I am not missing something. Am I missing something 
> > or should we integrate these methods?
> >
> > Cheers,
> > Doru
> >
> > --
> > www.tudorgirba.com
> > www.feenk.com
> >
> > "Problem solving efficiency grows with the abstractness level of problem 
> > understanding."
> >
> >
> >
> >
> >
> >
> 
> --
> www.tudorgirba.com
> www.feenk.com
> 
> "Things happen when they happen,
> not when you talk about them happening."

--
www.tudorgirba.com
www.feenk.com

"To lead is not to demand things, it is to make them happen."

Re: [Pharo-dev] context mirror primitives

[Clément Bera]

2016-01-04 17:35 GMT+01:00 Tudor Girba :

> Hi,
>
> > On Jan 4, 2016, at 6:30 PM, Clément Bera  wrote:
> >
> > Hello,
> >
> > This is unrelated to Spur / SqueakV3 memory manager. The VM support has
> been there and stable for a long time now.
> >
> > I tried to add those primitives in Pharo but the problem is that the
> debugger in Pharo uses EyeInspector whereas the inspectors are done with
> Glamour.
> >
> > Hence, to add support for ProtoObject debugging you need:
> > - to make interpretation implemented in Context compliant
> > - to make EyeInspector compliant (for the inspector in the debugger)
> > - to make GTInspector compliant.
>
> I am not sure I understand what you mean by " interpretation implemented
> in Context compliant”. Could you explain?
>

The generic idea is that in the debugger part of the execution is done
using an in-image interpreter instead of the VM. The in-image interpreter
should use the mirror primitives to be able to interpret correctly the code.

For example:

Context>>pushReceiverVariable: offset
self push: (self receiver instVarAt: offset + 1)

should be rewritten:

Context>>pushReceiverVariable: offset
self push: (*self object:* self receiver instVarAt: offset + 1)

Else operations such as "over" or "into" in the debugger would crash if the
receiver is a protoobject as they would use this code which sends a message
to a protoobject instead of using the mirror primitives.



>
> I already made GTInspector and GTDebugger work with ProtoObject once. I
> lost the changes in the meantime :), but I will redo them. The only thing I
> needed were these primitives. But, maybe I missed something.
>
>
This is good news. I believe such inspectors are really important if one
want to experiment with the kernel. The next steps would be to see if one
can inspect an object which class directly inherit from nil and an object
which has itself as a class (a prototype).



> Cheers,
> Doru
>
>
> > Cheers !
> >
> > Clement
> >
> >
> > 2016-01-04 16:42 GMT+01:00 Tudor Girba :
> > Hi,
> >
> > The VM (both Cog and Spur) supports basic manipulation of objects
> without relying on sending messages to those objects. These primitives are
> meant to be handled by methods in Context. Eliot provided a changeset with
> these methods, and they are not yet in Pharo:
> >
> > object: anObject basicAt: index
> > object: anObject basicAt: index put: value
> > object: anObject eqeq: anOtherObject
> > object: anObject instVarAt: anIndex
> > object: anObject instVarAt: anIndex put: aValue
> > object: anObject perform: selector withArguments: argArray inClass:
> lookupClass
> > objectClass: anObject
> > objectSize: anObject
> >
> > I added an issue and the slice:
> >
> https://pharo.fogbugz.com/f/cases/17313/Missing-primitive-methods-in-Context
> >
> > As I note in the issue, I think it is certainly interesting to have a
> more powerful mirrors mechanism, but until then we should still be able to
> use what the VM already provides.
> >
> > I would like to use these primitives now to make the GT Inspector and
> Debugger be able to work with ProtoObject. I thought these methods were
> supposed to be in the Spur version of Pharo, but it seems they are not. So,
> I am wondering if maybe I am not missing something. Am I missing something
> or should we integrate these methods?
> >
> > Cheers,
> > Doru
> >
> > --
> > www.tudorgirba.com
> > www.feenk.com
> >
> > "Problem solving efficiency grows with the abstractness level of problem
> understanding."
> >
> >
> >
> >
> >
> >
>
> --
> www.tudorgirba.com
> www.feenk.com
>
> "Things happen when they happen,
> not when you talk about them happening."
>
>
>

Re: [Pharo-dev] context mirror primitives

[Tudor Girba]

Hi,

> On Jan 4, 2016, at 6:30 PM, Clément Bera  wrote:
> 
> Hello,
> 
> This is unrelated to Spur / SqueakV3 memory manager. The VM support has been 
> there and stable for a long time now.
> 
> I tried to add those primitives in Pharo but the problem is that the debugger 
> in Pharo uses EyeInspector whereas the inspectors are done with Glamour.
> 
> Hence, to add support for ProtoObject debugging you need:
> - to make interpretation implemented in Context compliant
> - to make EyeInspector compliant (for the inspector in the debugger)
> - to make GTInspector compliant.

I am not sure I understand what you mean by " interpretation implemented in 
Context compliant”. Could you explain?

I already made GTInspector and GTDebugger work with ProtoObject once. I lost 
the changes in the meantime :), but I will redo them. The only thing I needed 
were these primitives. But, maybe I missed something.

Cheers,
Doru


> Cheers !
> 
> Clement
> 
> 
> 2016-01-04 16:42 GMT+01:00 Tudor Girba :
> Hi,
> 
> The VM (both Cog and Spur) supports basic manipulation of objects without 
> relying on sending messages to those objects. These primitives are meant to 
> be handled by methods in Context. Eliot provided a changeset with these 
> methods, and they are not yet in Pharo:
> 
> object: anObject basicAt: index
> object: anObject basicAt: index put: value
> object: anObject eqeq: anOtherObject
> object: anObject instVarAt: anIndex
> object: anObject instVarAt: anIndex put: aValue
> object: anObject perform: selector withArguments: argArray inClass: 
> lookupClass
> objectClass: anObject
> objectSize: anObject
> 
> I added an issue and the slice:
> https://pharo.fogbugz.com/f/cases/17313/Missing-primitive-methods-in-Context
> 
> As I note in the issue, I think it is certainly interesting to have a more 
> powerful mirrors mechanism, but until then we should still be able to use 
> what the VM already provides.
> 
> I would like to use these primitives now to make the GT Inspector and 
> Debugger be able to work with ProtoObject. I thought these methods were 
> supposed to be in the Spur version of Pharo, but it seems they are not. So, I 
> am wondering if maybe I am not missing something. Am I missing something or 
> should we integrate these methods?
> 
> Cheers,
> Doru
> 
> --
> www.tudorgirba.com
> www.feenk.com
> 
> "Problem solving efficiency grows with the abstractness level of problem 
> understanding."
> 
> 
> 
> 
> 
> 

--
www.tudorgirba.com
www.feenk.com

"Things happen when they happen,
not when you talk about them happening."

Re: [Pharo-dev] context mirror primitives

[Clément Bera]

Hello,

This is unrelated to Spur / SqueakV3 memory manager. The VM support has
been there and stable for a long time now.

I tried to add those primitives in Pharo but the problem is that the
debugger in Pharo uses EyeInspector whereas the inspectors are done with
Glamour.

Hence, to add support for ProtoObject debugging you need:
- to make interpretation implemented in Context compliant
- to make EyeInspector compliant (for the inspector in the debugger)
- to make GTInspector compliant.

Cheers !

Clement


2016-01-04 16:42 GMT+01:00 Tudor Girba :

> Hi,
>
> The VM (both Cog and Spur) supports basic manipulation of objects without
> relying on sending messages to those objects. These primitives are meant to
> be handled by methods in Context. Eliot provided a changeset with these
> methods, and they are not yet in Pharo:
>
> object: anObject basicAt: index
> object: anObject basicAt: index put: value
> object: anObject eqeq: anOtherObject
> object: anObject instVarAt: anIndex
> object: anObject instVarAt: anIndex put: aValue
> object: anObject perform: selector withArguments: argArray inClass:
> lookupClass
> objectClass: anObject
> objectSize: anObject
>
> I added an issue and the slice:
>
> https://pharo.fogbugz.com/f/cases/17313/Missing-primitive-methods-in-Context
>
> As I note in the issue, I think it is certainly interesting to have a more
> powerful mirrors mechanism, but until then we should still be able to use
> what the VM already provides.
>
> I would like to use these primitives now to make the GT Inspector and
> Debugger be able to work with ProtoObject. I thought these methods were
> supposed to be in the Spur version of Pharo, but it seems they are not. So,
> I am wondering if maybe I am not missing something. Am I missing something
> or should we integrate these methods?
>
> Cheers,
> Doru
>
> --
> www.tudorgirba.com
> www.feenk.com
>
> "Problem solving efficiency grows with the abstractness level of problem
> understanding."
>
>
>
>
>
>

Re: [Pharo-dev] context mirror primitives

[Esteban A. Maringolo]

Thank you Doru!

When do you guess it is going to be integrated in the main codebase?
Esteban A. Maringolo


2016-01-04 12:42 GMT-03:00 Tudor Girba :
> Hi,
>
> The VM (both Cog and Spur) supports basic manipulation of objects without 
> relying on sending messages to those objects. These primitives are meant to 
> be handled by methods in Context. Eliot provided a changeset with these 
> methods, and they are not yet in Pharo:
>
> object: anObject basicAt: index
> object: anObject basicAt: index put: value
> object: anObject eqeq: anOtherObject
> object: anObject instVarAt: anIndex
> object: anObject instVarAt: anIndex put: aValue
> object: anObject perform: selector withArguments: argArray inClass: 
> lookupClass
> objectClass: anObject
> objectSize: anObject
>
> I added an issue and the slice:
> https://pharo.fogbugz.com/f/cases/17313/Missing-primitive-methods-in-Context
>
> As I note in the issue, I think it is certainly interesting to have a more 
> powerful mirrors mechanism, but until then we should still be able to use 
> what the VM already provides.
>
> I would like to use these primitives now to make the GT Inspector and 
> Debugger be able to work with ProtoObject. I thought these methods were 
> supposed to be in the Spur version of Pharo, but it seems they are not. So, I 
> am wondering if maybe I am not missing something. Am I missing something or 
> should we integrate these methods?
>
> Cheers,
> Doru
>
> --
> www.tudorgirba.com
> www.feenk.com
>
> "Problem solving efficiency grows with the abstractness level of problem 
> understanding."
>
>
>
>
>