Loading VMMaker into latest Pharo

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Loading VMMaker into latest Pharo

Igor Stasenko
 
There are multiple issues, when loading VMMaker into closure-aware
image (10292).

two #needsToRegenerateInterpreterFile methods
storing into block args. Fix is easy and quick.

But what to do with this??

Compiler reporting 'stack including temps is too deep'.

GeniePlugin>>primSameClassAbsoluteStrokeDistanceMyPoints: myPointsOop
otherPoints: otherPointsOop myVectors: myVectorsOop otherVectors:
otherVectorsOop mySquaredLengths: mySquaredLengthsOop
otherSquaredLengths: otherSquaredLengthsOop myAngles: myAnglesOop
otherAngles: otherAnglesOop maxSizeAndReferenceFlag: maxSizeAndRefFlag
rowBase: rowBaseOop rowInsertRemove: rowInsertRemoveOop
rowInsertRemoveCount: rowInsertRemoveCountOop

(yes, this is a method's message pattern) :)

i stopped trying to load VMMaker at this method.

It would be nice to have VMMaker loaded in image+closures running
under VM+closures :)

--
Best regards,
Igor Stasenko AKA sig.
Reply | Threaded
Open this post in threaded view
|

Re: Loading VMMaker into latest Pharo

Eliot Miranda-2
 


On Thu, Apr 30, 2009 at 8:43 AM, Igor Stasenko <[hidden email]> wrote:

There are multiple issues, when loading VMMaker into closure-aware
image (10292).

two #needsToRegenerateInterpreterFile methods
storing into block args. Fix is easy and quick.

But what to do with this??

Compiler reporting 'stack including temps is too deep'.

GeniePlugin>>primSameClassAbsoluteStrokeDistanceMyPoints: myPointsOop
otherPoints: otherPointsOop myVectors: myVectorsOop otherVectors:
otherVectorsOop mySquaredLengths: mySquaredLengthsOop
otherSquaredLengths: otherSquaredLengthsOop myAngles: myAnglesOop
otherAngles: otherAnglesOop maxSizeAndReferenceFlag: maxSizeAndRefFlag
rowBase: rowBaseOop rowInsertRemove: rowInsertRemoveOop
rowInsertRemoveCount: rowInsertRemoveCountOop

(yes, this is a method's message pattern) :)

i stopped trying to load VMMaker at this method.

The workaround for this is just to change the code in generate: so one can proceed from the error and still define the method. The method doesn't need to be run, only translated so there's no harm in that.  Some time some kind soul should refactor this method  into an outer and an inner or I should change the large context sizes.

It would be nice to have VMMaker loaded in image+closures running
under VM+closures :)

Just do the workaround and you'll have just that.

 


--
Best regards,
Igor Stasenko AKA sig.

Reply | Threaded
Open this post in threaded view
|

Re: Loading VMMaker into latest Pharo

Eliot Miranda-2
 


On Thu, Apr 30, 2009 at 8:52 AM, Eliot Miranda <[hidden email]> wrote:


On Thu, Apr 30, 2009 at 8:43 AM, Igor Stasenko <[hidden email]> wrote:

There are multiple issues, when loading VMMaker into closure-aware
image (10292).

two #needsToRegenerateInterpreterFile methods
storing into block args. Fix is easy and quick.

But what to do with this??

Compiler reporting 'stack including temps is too deep'.

GeniePlugin>>primSameClassAbsoluteStrokeDistanceMyPoints: myPointsOop
otherPoints: otherPointsOop myVectors: myVectorsOop otherVectors:
otherVectorsOop mySquaredLengths: mySquaredLengthsOop
otherSquaredLengths: otherSquaredLengthsOop myAngles: myAnglesOop
otherAngles: otherAnglesOop maxSizeAndReferenceFlag: maxSizeAndRefFlag
rowBase: rowBaseOop rowInsertRemove: rowInsertRemoveOop
rowInsertRemoveCount: rowInsertRemoveCountOop

(yes, this is a method's message pattern) :)

i stopped trying to load VMMaker at this method.

The workaround for this is just to change the code in generate: so one can proceed from the error and still define the method. The method doesn't need to be run, only translated so there's no harm in that.  Some time some kind soul should refactor this method  into an outer and an inner or I should change the large context sizes.

It would be nice to have VMMaker loaded in image+closures running
under VM+closures :)

Just do the workaround and you'll have just that.

and  I should say we'll sort out a proper solution soon :)
 

 


--

Best regards,
Igor Stasenko AKA sig.


Reply | Threaded
Open this post in threaded view
|

Re: Loading VMMaker into latest Pharo

Igor Stasenko
In reply to this post by Eliot Miranda-2

2009/4/30 Eliot Miranda <[hidden email]>:

>
>
>
> On Thu, Apr 30, 2009 at 8:43 AM, Igor Stasenko <[hidden email]> wrote:
>>
>> There are multiple issues, when loading VMMaker into closure-aware
>> image (10292).
>>
>> two #needsToRegenerateInterpreterFile methods
>> storing into block args. Fix is easy and quick.
>>
>> But what to do with this??
>>
>> Compiler reporting 'stack including temps is too deep'.
>>
>> GeniePlugin>>primSameClassAbsoluteStrokeDistanceMyPoints: myPointsOop
>> otherPoints: otherPointsOop myVectors: myVectorsOop otherVectors:
>> otherVectorsOop mySquaredLengths: mySquaredLengthsOop
>> otherSquaredLengths: otherSquaredLengthsOop myAngles: myAnglesOop
>> otherAngles: otherAnglesOop maxSizeAndReferenceFlag: maxSizeAndRefFlag
>> rowBase: rowBaseOop rowInsertRemove: rowInsertRemoveOop
>> rowInsertRemoveCount: rowInsertRemoveCountOop
>>
>> (yes, this is a method's message pattern) :)
>>
>> i stopped trying to load VMMaker at this method.
>
> The workaround for this is just to change the code in generate: so one can proceed from the error and still define the method. The method doesn't need to be run, only translated so there's no harm in that.  Some time some kind soul should refactor this method  into an outer and an inner or I should change the large context sizes.

Changing the code in #generate: will buy us nothing, because this
error thrown when MC loads a package in image, and naturally, tries to
compile & install all methods from it :)

>>
>> It would be nice to have VMMaker loaded in image+closures running
>> under VM+closures :)
>
> Just do the workaround and you'll have just that.
>
>>
>> --
>> Best regards,
>> Igor Stasenko AKA sig.
>
>
>



--
Best regards,
Igor Stasenko AKA sig.
Reply | Threaded
Open this post in threaded view
|

Re: Loading VMMaker into latest Pharo

Eliot Miranda-2
 


On Thu, Apr 30, 2009 at 8:59 AM, Igor Stasenko <[hidden email]> wrote:

2009/4/30 Eliot Miranda <[hidden email]>:
>
>
>
> On Thu, Apr 30, 2009 at 8:43 AM, Igor Stasenko <[hidden email]> wrote:
>>
>> There are multiple issues, when loading VMMaker into closure-aware
>> image (10292).
>>
>> two #needsToRegenerateInterpreterFile methods
>> storing into block args. Fix is easy and quick.
>>
>> But what to do with this??
>>
>> Compiler reporting 'stack including temps is too deep'.
>>
>> GeniePlugin>>primSameClassAbsoluteStrokeDistanceMyPoints: myPointsOop
>> otherPoints: otherPointsOop myVectors: myVectorsOop otherVectors:
>> otherVectorsOop mySquaredLengths: mySquaredLengthsOop
>> otherSquaredLengths: otherSquaredLengthsOop myAngles: myAnglesOop
>> otherAngles: otherAnglesOop maxSizeAndReferenceFlag: maxSizeAndRefFlag
>> rowBase: rowBaseOop rowInsertRemove: rowInsertRemoveOop
>> rowInsertRemoveCount: rowInsertRemoveCountOop
>>
>> (yes, this is a method's message pattern) :)
>>
>> i stopped trying to load VMMaker at this method.
>
> The workaround for this is just to change the code in generate: so one can proceed from the error and still define the method. The method doesn't need to be run, only translated so there's no harm in that.  Some time some kind soul should refactor this method  into an outer and an inner or I should change the large context sizes.

Changing the code in #generate: will buy us nothing, because this
error thrown when MC loads a package in image, and naturally, tries to
compile & install all methods from it :)

Once you have it in the image Monticello won't try and recompile it if it doesn't change.  This is a one-time pain per image.

Another workaround is just to move the GeniePlugin somewhere else.
 


>>
>> It would be nice to have VMMaker loaded in image+closures running
>> under VM+closures :)
>
> Just do the workaround and you'll have just that.
>
>>
>> --
>> Best regards,
>> Igor Stasenko AKA sig.
>
>
>



--
Best regards,
Igor Stasenko AKA sig.

Reply | Threaded
Open this post in threaded view
|

Re: Loading VMMaker into latest Pharo

Andreas.Raab
 
Eliot Miranda wrote:
> Once you have it in the image Monticello won't try and recompile it if
> it doesn't change.  This is a one-time pain per image.
>
> Another workaround is just to move the GeniePlugin somewhere else.

That's what we've done for our images.

Cheers,
   - Andres
Reply | Threaded
Open this post in threaded view
|

Re: Loading VMMaker into latest Pharo

Igor Stasenko

2009/4/30 Andreas Raab <[hidden email]>:
>
> Eliot Miranda wrote:
>>
>> Once you have it in the image Monticello won't try and recompile it if it
>> doesn't change.  This is a one-time pain per image.
>>
>> Another workaround is just to move the GeniePlugin somewhere else.
>
To trash?
As to me, this plugin is quite useless. Just a single bloated
primitive, trying to do something .. can't guess what.
Is it interface to some kind of device/ library?

> That's what we've done for our images.
>
> Cheers,
>  - Andres
>



--
Best regards,
Igor Stasenko AKA sig.
Reply | Threaded
Open this post in threaded view
|

Re: Loading VMMaker into latest Pharo

David T. Lewis
In reply to this post by Igor Stasenko
 
On Thu, Apr 30, 2009 at 06:43:00PM +0300, Igor Stasenko wrote:
>  
> There are multiple issues, when loading VMMaker into closure-aware
> image (10292).
>
> two #needsToRegenerateInterpreterFile methods
> storing into block args. Fix is easy and quick.

The easy and quick fix is in VMMaker-dtl.121 on SqS.

Dave

Reply | Threaded
Open this post in threaded view
|

Re: Loading VMMaker into latest Pharo

Andreas.Raab
 
Excellent, thanks David!

   - A.

David T. Lewis wrote:

>  
> On Thu, Apr 30, 2009 at 06:43:00PM +0300, Igor Stasenko wrote:
>>  
>> There are multiple issues, when loading VMMaker into closure-aware
>> image (10292).
>>
>> two #needsToRegenerateInterpreterFile methods
>> storing into block args. Fix is easy and quick.
>
> The easy and quick fix is in VMMaker-dtl.121 on SqS.
>
> Dave
>