Smalltalk › Squeak › Squeak - Dev

Bootstrap logic in recent Tweak-Core (?)

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

12 messages Options

Nikolay Suslov

Bootstrap logic in recent Tweak-Core (?)

Hello,

It seems to be, that bootstrap logic does not work anymore in new Tweak-Core package, running on top of Squeak 4.1
For example: "CWorldPlayer run" fails, as CWorldPlayer instance could not be properly initialized.

What could be the problem with this?

Thanks for any insights
Nikolay

John McKeon

Re: Bootstrap logic in recent Tweak-Core (?)

Hello Nicolay,

I use CProjectMorph open: AnyCPLayerSubclass

John

On Tue, Jul 27, 2010 at 7:10 PM, Nikolay Suslov <[hidden email]> wrote:

Hello,

It seems to be, that bootstrap logic does not work anymore in new Tweak-Core package, running on top of Squeak 4.1
For example: "CWorldPlayer run" fails, as CWorldPlayer instance could not be properly initialized.

What could be the problem with this?

Thanks for any insights
Nikolay

--
http://john-mckeon.us/seaside

Andreas.Raab

Re: Bootstrap logic in recent Tweak-Core (?)

In reply to this post by Nikolay Suslov

On 7/27/2010 4:10 PM, Nikolay Suslov wrote:
> Hello,
>
> It seems to be, that bootstrap logic does not work anymore in new
> Tweak-Core package, running on top of Squeak 4.1
> For example: "CWorldPlayer run" fails, as CWorldPlayer instance could
> not be properly initialized.
>
> What could be the problem with this?

Some of this stuff got broken and I just didn't find the energy to fix
it. Can you say a little more what concretely you're trying to make
work? There may be easier way to do things now.

Cheers,
- Andreas

Nikolay Suslov

Re: Bootstrap logic in recent Tweak-Core (?)

Andreas,

I am trying to get an old pure Croquet 1.0.18 code working on the latest Squeak 4.1 image.

So, loading the latest FFI, CroquetGL, Tweak-Core, Matthew's Croquet-Kernel changes , and almost all code from an old Croquet-1.0.18 image, I managed finally to run the demos, yes!
But, the demos like SimpleDemo or KATDemo uses Tweak and it's bootstrap logic for initialization.

I have prepared an image to try (based on updated Squeak4.2-10160-alpha):
http://www.krestianstvo.ru/sdk/Croquet-Squeak4.1-image.zip
and "image with all needed content":
http://www.krestianstvo.ru/sdk/CroquetSDK-1.0.18-Squeak4.1.zip

To run into the error, you should uncomment "self runTweakCycle, in #step (CroquetParticipantWithMenu).

I know that Matthew is using the new Tweak logic for getting Open Cobalt to work, but the idea is to have an old bootstrap code also working, as it should be and have a backward compatibility.

Is it possible to achieve?

Thanks,
Nikolay

On Wed, Jul 28, 2010 at 7:37 AM, Andreas Raab <[hidden email]> wrote:

On 7/27/2010 4:10 PM, Nikolay Suslov wrote:

Hello,

It seems to be, that bootstrap logic does not work anymore in new
Tweak-Core package, running on top of Squeak 4.1
For example: "CWorldPlayer run" fails, as CWorldPlayer instance could
not be properly initialized.

What could be the problem with this?

Some of this stuff got broken and I just didn't find the energy to fix it. Can you say a little more what concretely you're trying to make work? There may be easier way to do things now.

Cheers,
- Andreas

Andreas.Raab

Re: Bootstrap logic in recent Tweak-Core (?)

(2nd try with smaller attachment)

On 7/28/2010 2:53 AM, Nikolay Suslov wrote:
> I have prepared an image to try (based on updated Squeak4.2-10160-alpha):
> http://www.krestianstvo.ru/sdk/Croquet-Squeak4.1-image.zip
> and "image with all needed content":
> http://www.krestianstvo.ru/sdk/CroquetSDK-1.0.18-Squeak4.1.zip
>
> To run into the error, you should uncomment "self runTweakCycle, in
> #step (CroquetParticipantWithMenu).

Ah, thank you so much! This was just what I need to find this particular
bug. It turns out that the bootstrap was indeed badly broken due to a
change in the way events are handled. The fix is trivial and not only
addresses your problem but also makes the long standing test errors in
TweakToolBuildTests go away!

The fix is in the TweakCore repository and can be installed via:

(Installer ss project: 'TweakCore') install: 'Scripting'.

(hm ... someone should a #merge: option for Installer)

> I know that Matthew is using the new Tweak logic for getting Open Cobalt
> to work, but the idea is to have an old bootstrap code also working, as
> it should be and have a backward compatibility.
>
> Is it possible to achieve?

Looking good right now. After installing the above and fixing a
non-boolean in CDefaultWidgetLibrary by executing:

CDefaultWidgetLibrary classPool at: #ImparaColors put: false.

(I'll fix that in the repository tonight) and uncommenting the code in
#step I was able to run a SimpleDemoMaster just fine (see screenshot).

Thanks for your help!

Cheers,
- Andreas

SDMasterSmall4.1.jpg (97K) Download Attachment

Bert Freudenberg

Re: Bootstrap logic in recent Tweak-Core (?)

On 28.07.2010, at 12:25, Andreas Raab wrote:

> was able to run a SimpleDemoMaster just fine (see screenshot).

Great!

On a slightly related note, I chatted with Matthew (and Julian) at Squeakfest about tile scripting for 3D objects in Open Cobalt. I seem to remember we once experimented with "remote-controlling" Croquet objects using a locally-run Tweak project. But this was some time ago so I'm hazy on the details. Do you have an idea what would be needed for actual scripting of croquet objects using a 2D Tweak tile interface?

- Bert -

Andreas.Raab

Re: Bootstrap logic in recent Tweak-Core (?)

On 7/28/2010 7:32 PM, Bert Freudenberg wrote:
> On 28.07.2010, at 12:25, Andreas Raab wrote:
>
>> was able to run a SimpleDemoMaster just fine (see screenshot).
>
> Great!
>
> On a slightly related note, I chatted with Matthew (and Julian) at Squeakfest about tile scripting for 3D objects in Open Cobalt. I seem to remember we once experimented with "remote-controlling" Croquet objects using a locally-run Tweak project. But this was some time ago so I'm hazy on the details. Do you have an idea what would be needed for actual scripting of croquet objects using a 2D Tweak tile interface?

You have two options:

1) Create a local proxy for the replicated object and have it control
the replicated target. This has the advantage that you don't need to
replicate the script but the disadvantage that the script is
disassociated from the object and won't persist if the local user drops out.

2) Replicate the script into the island and run it there. This is
obviously more in line with the ideas of Croquet but the thought of all
the things that could go wrong led me to never go down this path.

Cheers,
- Andreas

David Faught

Re: Bootstrap logic in recent Tweak-Core (?)

In reply to this post by Nikolay Suslov

On 7/29/2010, Andreas Raab wrote:
>On 7/28/2010 7:32 PM, Bert Freudenberg wrote:
>> On 28.07.2010, at 12:25, Andreas Raab wrote:

>>> was able to run a SimpleDemoMaster just fine (see screenshot).

>> Great!
>>
>> On a slightly related note, I chatted with Matthew (and Julian) at Squeakfest about tile scripting for 3D objects in Open Cobalt.
>> I seem to remember we once experimented with "remote-controlling" Croquet objects using a locally-run Tweak project. But
>> this was some time ago so I'm hazy on the details. Do you have an idea what would be needed for actual scripting of croquet
>> objects using a 2D Tweak tile interface?

>You have two options:
>
>1) Create a local proxy for the replicated object and have it control
>the replicated target. This has the advantage that you don't need to
>replicate the script but the disadvantage that the script is
>disassociated from the object and won't persist if the local user drops out.
>
>2) Replicate the script into the island and run it there. This is
>obviously more in line with the ideas of Croquet but the thought of all
>the things that could go wrong led me to never go down this path.

Option number 2 is what I used in the MockTurtle demo. This project
only used a code editor in the local proxy instead of tile scripting,
and when the edit was accepted the script text was first locally
syntax checked and then sent to the associated replicated object.
This was actually lots of fun, but needed to have some "future"s
handcoded in the edited source as I recall. Some keystrokes in the
harness directed to the target replicated object caused editing or
script execution to start. In my isolated testing, this worked just
fine.

Cheers,
Dave

Andreas.Raab

Re: Bootstrap logic in recent Tweak-Core (?)

On 7/29/2010 5:08 AM, David Faught wrote:

> On 7/29/2010, Andreas Raab wrote:
>> 1) Create a local proxy for the replicated object and have it control
>> the replicated target. This has the advantage that you don't need to
>> replicate the script but the disadvantage that the script is
>> disassociated from the object and won't persist if the local user drops out.
>>
>> 2) Replicate the script into the island and run it there. This is
>> obviously more in line with the ideas of Croquet but the thought of all
>> the things that could go wrong led me to never go down this path.
>
> Option number 2 is what I used in the MockTurtle demo. This project
> only used a code editor in the local proxy instead of tile scripting,
> and when the edit was accepted the script text was first locally
> syntax checked and then sent to the associated replicated object.
> This was actually lots of fun, but needed to have some "future"s
> handcoded in the edited source as I recall. Some keystrokes in the
> harness directed to the target replicated object caused editing or
> script execution to start. In my isolated testing, this worked just
> fine.

How did you deal with persistence and replication? One of the main
issues with the approach is having to include compiled methods in the
island snapshot. Or did you have an explicit "code sync" step before
replicating the island contents?

Cheers,
- Andreas

David Faught

Re: Bootstrap logic in recent Tweak-Core (?)

In reply to this post by Nikolay Suslov

>On 7/29/2010 5:08 AM, David Faught wrote:
>> On 7/29/2010, Andreas Raab wrote:
>>> 1) Create a local proxy for the replicated object and have it control
>>> the replicated target. This has the advantage that you don't need to
>>> replicate the script but the disadvantage that the script is
>>> disassociated from the object and won't persist if the local user drops out.
>>>
>>> 2) Replicate the script into the island and run it there. This is
>>> obviously more in line with the ideas of Croquet but the thought of all
>>> the things that could go wrong led me to never go down this path.

>> Option number 2 is what I used in the MockTurtle demo. This project
>> only used a code editor in the local proxy instead of tile scripting,
>> and when the edit was accepted the script text was first locally
>> syntax checked and then sent to the associated replicated object.
>> This was actually lots of fun, but needed to have some "future"s
>> handcoded in the edited source as I recall. Some keystrokes in the
>> harness directed to the target replicated object caused editing or
>> script execution to start. In my isolated testing, this worked just
>> fine.

>How did you deal with persistence and replication? One of the main
>issues with the approach is having to include compiled methods in the
>island snapshot. Or did you have an explicit "code sync" step before
>replicating the island contents?

I guess that I cheated by ignoring persistence and took a very simple
minded approach. By choice there were no compiled methods. And yes,
that limited its usefulness, but it was still lots of fun. The
locally edited code was sent to the target replicated object as a text
string and the replicated object saved it in a single instance
variable, so each replicated object could have exactly one script.
When the target object was triggered to run the code, it essentially
did a "doIt" on the string. There wasn't anything more to it than
that.

Cheers,
Dave

David Faught

Re: Bootstrap logic in recent Tweak-Core (?)

On Thu, Jul 29, 2010 at 3:10 PM, David Faught <[hidden email]> wrote:

>>On 7/29/2010 5:08 AM, David Faught wrote:
>>> On 7/29/2010, Andreas Raab wrote:
>>>> 1) Create a local proxy for the replicated object and have it control
>>>> the replicated target. This has the advantage that you don't need to
>>>> replicate the script but the disadvantage that the script is
>>>> disassociated from the object and won't persist if the local user drops out.
>>>>
>>>> 2) Replicate the script into the island and run it there. This is
>>>> obviously more in line with the ideas of Croquet but the thought of all
>>>> the things that could go wrong led me to never go down this path.
>
>>> Option number 2 is what I used in the MockTurtle demo. This project
>>> only used a code editor in the local proxy instead of tile scripting,
>>> and when the edit was accepted the script text was first locally
>>> syntax checked and then sent to the associated replicated object.
>>> This was actually lots of fun, but needed to have some "future"s
>>> handcoded in the edited source as I recall. Some keystrokes in the
>>> harness directed to the target replicated object caused editing or
>>> script execution to start. In my isolated testing, this worked just
>>> fine.
>
>>How did you deal with persistence and replication? One of the main
>>issues with the approach is having to include compiled methods in the
>>island snapshot. Or did you have an explicit "code sync" step before
>>replicating the island contents?
>
> I guess that I cheated by ignoring persistence and took a very simple
> minded approach. By choice there were no compiled methods. And yes,
> that limited its usefulness, but it was still lots of fun. The
> locally edited code was sent to the target replicated object as a text
> string and the replicated object saved it in a single instance
> variable, so each replicated object could have exactly one script.
> When the target object was triggered to run the code, it essentially
> did a "doIt" on the string. There wasn't anything more to it than
> that.

I never made any claims about this being a clever and elegant
implementation, but it worked and was lots of fun and interesting to
play with. I found out some things I never knew before, such as how
to do recursion in a single "doIt" string. It was a simple enough
case to experiment with some of the basic ideas. And I haven't seen
or heard of anyone who has completed a similar or better version of
this, outside of some discussion of the concepts. Here is my virtual
gauntlet being thrown to the floor. I will gladly yield to anyone
with a serious challenge.

> Cheers,
> Dave

David Faught

Re: Bootstrap logic in recent Tweak-Core (?)

On Fri, Jul 30, 2010 at 7:07 AM, David Faught <[hidden email]> wrote:

> On Thu, Jul 29, 2010 at 3:10 PM, David Faught <[hidden email]> wrote:
>>>On 7/29/2010 5:08 AM, David Faught wrote:
>>>> On 7/29/2010, Andreas Raab wrote:
>>>>>
>>>>> 2) Replicate the script into the island and run it there. This is
>>>>> obviously more in line with the ideas of Croquet but the thought of all
>>>>> the things that could go wrong led me to never go down this path.
>>
>>>> Option number 2 is what I used in the MockTurtle demo. This project
>>>> only used a code editor in the local proxy instead of tile scripting,
>>>> and when the edit was accepted the script text was first locally
>>>> syntax checked and then sent to the associated replicated object.
>>>> This was actually lots of fun, but needed to have some "future"s
>>>> handcoded in the edited source as I recall. Some keystrokes in the
>>>> harness directed to the target replicated object caused editing or
>>>> script execution to start. In my isolated testing, this worked just
>>>> fine.
>>
>>>How did you deal with persistence and replication? One of the main
>>>issues with the approach is having to include compiled methods in the
>>>island snapshot. Or did you have an explicit "code sync" step before
>>>replicating the island contents?
>>
>> I guess that I cheated by ignoring persistence and took a very simple
>> minded approach. By choice there were no compiled methods. And yes,
>> that limited its usefulness, but it was still lots of fun. The
>> locally edited code was sent to the target replicated object as a text
>> string and the replicated object saved it in a single instance
>> variable, so each replicated object could have exactly one script.
>> When the target object was triggered to run the code, it essentially
>> did a "doIt" on the string. There wasn't anything more to it than
>> that.
>
> I never made any claims about this being a clever and elegant
> implementation, but it worked and was lots of fun and interesting to
> play with. I found out some things I never knew before, such as how
> to do recursion in a single "doIt" string. It was a simple enough
> case to experiment with some of the basic ideas. And I haven't seen
> or heard of anyone who has completed a similar or better version of
> this, outside of some discussion of the concepts. Here is my virtual
> gauntlet being thrown to the floor. I will gladly yield to anyone
> with a serious challenge.

Hhmm, now that I think about it, there was a project at U. of
Minnesota dealing with robots or NPCs, but I don't recall that project
actually did any interactive scripting.

>> Cheers,
>> Dave