SMServer beta online

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

SMServer beta online

Chris Cunnington-3
http://box4.squeak.org:9971/seaside/ss

Here's a beta to replace map.squeak.org. Not all of the features work (Join, New Proejct, Save in the Your Project form). I didn't see much point in doing everything until qmail is installed on box4. 

It's Seaside2.8 and SS2. (Well, I've removed Magritte and re-installed SSTableReport, so perhaps I'm hacking SS2Retro). I'll save SS2Retro to its own repo. I'll then push SMServer to the SqueakServices repo. 

Chris 


Reply | Threaded
Open this post in threaded view
|

Re: [Box-Admins] SMServer beta online

Chris Muller-3
Cool Chris.  The existing SM catalog server _really_ needs replaced
badly.  It cannot even be ported to a closure image because some of
the methods are too long.  It uses HttpView which is a novel idea but
unfortunately for a domain as rich as SqueakMap the code is almost
impossible to debug.  I hated working on it, but it was worth it the
functionality for publishing projects easily from the image.

It will be some work to see this all the way through, though.  The
SMServer has several good features which are used.  Are you still
working on squeak.org too?


On Mon, Mar 31, 2014 at 11:07 AM, Chris Cunnington <[hidden email]> wrote:

> http://box4.squeak.org:9971/seaside/ss
>
> Here's a beta to replace map.squeak.org. Not all of the features work (Join,
> New Proejct, Save in the Your Project form). I didn't see much point in
> doing everything until qmail is installed on box4.
>
> It's Seaside2.8 and SS2. (Well, I've removed Magritte and re-installed
> SSTableReport, so perhaps I'm hacking SS2Retro). I'll save SS2Retro to its
> own repo. I'll then push SMServer to the SqueakServices repo.
>
> Chris

Reply | Threaded
Open this post in threaded view
|

Re: [Webteam] Re: [Box-Admins] SMServer beta online

Chris Cunnington-3

On Mar 31, 2014, at 3:41 PM, Chris Muller <[hidden email]> wrote:

> Cool Chris.

Thanks.

>  The existing SM catalog server _really_ needs replaced
> badly.  It cannot even be ported to a closure image because some of
> the methods are too long.  It uses HttpView which is a novel idea but
> unfortunately for a domain as rich as SqueakMap the code is almost
> impossible to debug.  I hated working on it, but it was worth it the
> functionality for publishing projects easily from the image.
>
> It will be some work to see this all the way through, though.

Yup, some of the features in the old one are missing: categories, pages for each user, storing files on a Squeak server.
As soon as I get the code untangled and into appropriate packages, I'll make it publicly available.

>  The
> SMServer has several good features which are used.  Are you still
> working on squeak.org too?

Sure.

Chris

>
> On Mon, Mar 31, 2014 at 11:07 AM, Chris Cunnington <[hidden email]> wrote:
>> http://box4.squeak.org:9971/seaside/ss
>>
>> Here's a beta to replace map.squeak.org. Not all of the features work (Join,
>> New Proejct, Save in the Your Project form). I didn't see much point in
>> doing everything until qmail is installed on box4.
>>
>> It's Seaside2.8 and SS2. (Well, I've removed Magritte and re-installed
>> SSTableReport, so perhaps I'm hacking SS2Retro). I'll save SS2Retro to its
>> own repo. I'll then push SMServer to the SqueakServices repo.
>>
>> Chris
> _______________________________________________
> Webteam mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/webteam


Reply | Threaded
Open this post in threaded view
|

Re: [Webteam] Re: [Box-Admins] SMServer beta online

Hannes Hirzel
On 3/31/14, Chris Cunnington <[hidden email]> wrote:
>
> On Mar 31, 2014, at 3:41 PM, Chris Muller <[hidden email]> wrote:
>
>> Cool Chris.

+1

....
>
> Yup, some of the features in the old one are missing: categories, pages for
> each user, storing files on a Squeak server.
> As soon as I get the code untangled and into appropriate packages, I'll make
> it publicly available.

Are you using Altitude for this as well?

>>  The
>> SMServer has several good features which are used.  Are you still
>> working on squeak.org too?
>
> Sure.
>

--Hannes

Reply | Threaded
Open this post in threaded view
|

Re: [Webteam] Re: [Box-Admins] SMServer beta online

Chris Cunnington-3

On Mar 31, 2014, at 11:45 PM, H. Hirzel <[hidden email]> wrote:

> On 3/31/14, Chris Cunnington <[hidden email]> wrote:
>>
>> On Mar 31, 2014, at 3:41 PM, Chris Muller <[hidden email]> wrote:
>>
>>> Cool Chris.
>
> +1
>
> ....
>>
>> Yup, some of the features in the old one are missing: categories, pages for
>> each user, storing files on a Squeak server.
>> As soon as I get the code untangled and into appropriate packages, I'll make
>> it publicly available.
>
> Are you using Altitude for this as well?


As you pointed out on the box-admins list it's Seaside. Seaside2.8/SqueakSource2.
It doesn't look like SS2 much, as I used Twitter Bootstrap css again.

Chris

>
>>> The
>>> SMServer has several good features which are used.  Are you still
>>> working on squeak.org too?
>>
>> Sure.
>>
>
> --Hannes
> _______________________________________________
> Webteam mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/webteam


Reply | Threaded
Open this post in threaded view
|

Environments question Binding>>objectForDataStream:

David T. Lewis
Currently we have this:

Binding>>objectForDataStream: refStream
        "It's not yet clear how serialization should work in the presence of environments"
        self shouldBeImplemented.

A Binding seems to be a simple object. Does it really need special handling
when serializing?

If no special handling is required, then we could remove this method,
which would permit projects to be saved to disk again
(http://bugs.squeak.org/view.php?id=7814).

I think that we have a number of other issues related to saving projects
and loading them back into the image. I don't know the scope of the issues,
but I'm hoping that serializing a Binding may be straightforward.

Dave


Reply | Threaded
Open this post in threaded view
|

Re: Environments question Binding>>objectForDataStream:

Colin Putney-3



On Tue, Apr 1, 2014 at 6:49 AM, David T. Lewis <[hidden email]> wrote:
Currently we have this:

Binding>>objectForDataStream: refStream
        "It's not yet clear how serialization should work in the presence of environments"
        self shouldBeImplemented.

A Binding seems to be a simple object. Does it really need special handling
when serializing?

It does. If you write a binding out to disk and then read it back in, you should have the same instance you started with, and not a copy. That part is fairly straight-forward: we include just the key in the data stream, and then when reading it back in we fetch the binding using the key.

For now, the simple thing is just to use "Environment current" when we need to lookup a binding. At some point we'll need a way to specify which environment to use when reading objects from disk, but that needn't stand in the way of getting this working again. 

Colin


Reply | Threaded
Open this post in threaded view
|

Re: Environments question Binding>>objectForDataStream:

Nicolas Cellier

2014-04-01 16:02 GMT+02:00 Colin Putney <[hidden email]>:



On Tue, Apr 1, 2014 at 6:49 AM, David T. Lewis <[hidden email]> wrote:
Currently we have this:

Binding>>objectForDataStream: refStream
        "It's not yet clear how serialization should work in the presence of environments"
        self shouldBeImplemented.

A Binding seems to be a simple object. Does it really need special handling
when serializing?

It does. If you write a binding out to disk and then read it back in, you should have the same instance you started with, and not a copy. That part is fairly straight-forward: we include just the key in the data stream, and then when reading it back in we fetch the binding using the key.

For now, the simple thing is just to use "Environment current" when we need to lookup a binding. At some point we'll need a way to specify which environment to use when reading objects from disk, but that needn't stand in the way of getting this working again. 

Colin


 

That's just what we would need to store: a reference to an {environment. variableName} pair, instead of a variableName.

This will raise following question : how do we refer to a specific environment?
Are environment registered uniquely by name, or is there another kind of known path to reach it from default environment?