How to globals that are NOT classes or traits?

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

How to globals that are NOT classes or traits?

Mariano Martinez Peck
Hi guys. In Fuel, we need to identity which globals present in Smalltalk globals are NOT classes or traits, because we need to manage them as globals. So far we have a hardcoded list:

defaultGlobalSymbols

    ^ #(#Smalltalk #SourceFiles #Transcript #Undeclared #Display #TextConstants #ActiveWorld #ActiveHand #ActiveEvent #Sensor #Processor #ImageImports #SystemOrganization #World)

So...as every hardcoded stuff, this is not nice because as soon as globals change, we need to fix this. So it would be nice if the system (pharo) can provide us this information.

What do you think?

--
Mariano
http://marianopeck.wordpress.com

Reply | Threaded
Open this post in threaded view
|

Re: How to globals that are NOT classes or traits?

Tobias Pape

Am 2012-04-17 um 12:50 schrieb Mariano Martinez Peck:

> Hi guys. In Fuel, we need to identity which globals present in Smalltalk globals are NOT classes or traits, because we need to manage them as globals. So far we have a hardcoded list:
>
> defaultGlobalSymbols
>
>     ^ #(#Smalltalk #SourceFiles #Transcript #Undeclared #Display #TextConstants #ActiveWorld #ActiveHand #ActiveEvent #Sensor #Processor #ImageImports #SystemOrganization #World)
>
> So...as every hardcoded stuff, this is not nice because as soon as globals change, we need to fix this. So it would be nice if the system (pharo) can provide us this information.
>
> What do you think?

What about just asking whether the Associaction values are Behavior:

defaultGlobalSymbols

    ^ (self environment "or 'Smalltalk globals' or 'Smalltalk', to your taste"
        select: [:g | g isBehavior not]) keys

In my Squeak4.3 this yields

 #(#SourceFiles #Display #Processor #World #Smalltalk #Sensor #ImageImports #ActiveEvent #ScheduledControllers #ScriptingSystem #ActiveHand #Undeclared #ActiveWorld #CustomEventsRegistry #TextConstants #References #Transcript #SystemOrganization)


Bes
        -Tobias

PS: for the interested ones, here with values:
#ActiveEvent->[keystroke '<Cmd-p>']
#ActiveHand->a HandMorph(3216)
#ActiveWorld->a PasteUpMorph(1622) [world]
#CustomEventsRegistry->an IdentityDictionary( "stuff" )
#Display->DisplayScreen(800x600x32)
#ImageImports->a Dictionary()
#Processor->a ProcessorScheduler
#References->an IdentityDictionary()
#ScheduledControllers->nil
#ScriptingSystem->a StandardScriptingSystem
#Sensor->an EventSensor
#Smalltalk->Smalltalk
#SourceFiles->an ExpandedSourceFileArray( "stuff" )
#SystemOrganization->( "stuff" )
#TextConstants->a Dictionary(size 107)
#Transcript->a TranscriptStream ''
#Undeclared->a Dictionary()
#World->a PasteUpMorph(1622) [world]


Reply | Threaded
Open this post in threaded view
|

Re: How to globals that are NOT classes or traits?

Guillermo Polito
Be careful that #isBehavior is false for Traits :).  To fix I think.

On Tue, Apr 17, 2012 at 1:41 PM, Tobias Pape <[hidden email]> wrote:

Am 2012-04-17 um 12:50 schrieb Mariano Martinez Peck:

> Hi guys. In Fuel, we need to identity which globals present in Smalltalk globals are NOT classes or traits, because we need to manage them as globals. So far we have a hardcoded list:
>
> defaultGlobalSymbols
>
>     ^ #(#Smalltalk #SourceFiles #Transcript #Undeclared #Display #TextConstants #ActiveWorld #ActiveHand #ActiveEvent #Sensor #Processor #ImageImports #SystemOrganization #World)
>
> So...as every hardcoded stuff, this is not nice because as soon as globals change, we need to fix this. So it would be nice if the system (pharo) can provide us this information.
>
> What do you think?

What about just asking whether the Associaction values are Behavior:

defaultGlobalSymbols

   ^ (self environment "or 'Smalltalk globals' or 'Smalltalk', to your taste"
       select: [:g | g isBehavior not]) keys

In my Squeak4.3 this yields

 #(#SourceFiles #Display #Processor #World #Smalltalk #Sensor #ImageImports #ActiveEvent #ScheduledControllers #ScriptingSystem #ActiveHand #Undeclared #ActiveWorld #CustomEventsRegistry #TextConstants #References #Transcript #SystemOrganization)


Bes
       -Tobias

PS: for the interested ones, here with values:
#ActiveEvent->[keystroke '<Cmd-p>']
#ActiveHand->a HandMorph(3216)
#ActiveWorld->a PasteUpMorph(1622) [world]
#CustomEventsRegistry->an IdentityDictionary( "stuff" )
#Display->DisplayScreen(800x600x32)
#ImageImports->a Dictionary()
#Processor->a ProcessorScheduler
#References->an IdentityDictionary()
#ScheduledControllers->nil
#ScriptingSystem->a StandardScriptingSystem
#Sensor->an EventSensor
#Smalltalk->Smalltalk
#SourceFiles->an ExpandedSourceFileArray( "stuff" )
#SystemOrganization->( "stuff" )
#TextConstants->a Dictionary(size 107)
#Transcript->a TranscriptStream ''
#Undeclared->a Dictionary()
#World->a PasteUpMorph(1622) [world]



Reply | Threaded
Open this post in threaded view
|

Re: How to globals that are NOT classes or traits?

Tobias Pape

Am 2012-04-17 um 15:20 schrieb Guillermo Polito:

> Be careful that #isBehavior is false for Traits :).  To fix I think.

oO
I did not expect that.
However, I think Traits should respond with true to traits.
Well then…
1) send isTrait, if applicable

defaultGlobalSymbols
 ^ (self environment "or 'Smalltalk globals' or 'Smalltalk', to your taste"
       reject: [:g | (g isBehavior) or: [
              (g respondsTo: #isTrait) and: [
                  g isTrait]]]) keys

or 2) make Traits respond true to isBehavior ;)

Best
        -Tobias


Reply | Threaded
Open this post in threaded view
|

Re: How to globals that are NOT classes or traits?

Eliot Miranda-2
In reply to this post by Mariano Martinez Peck


On Tue, Apr 17, 2012 at 3:50 AM, Mariano Martinez Peck <[hidden email]> wrote:
Hi guys. In Fuel, we need to identity which globals present in Smalltalk globals are NOT classes or traits, because we need to manage them as globals. So far we have a hardcoded list:

defaultGlobalSymbols

    ^ #(#Smalltalk #SourceFiles #Transcript #Undeclared #Display #TextConstants #ActiveWorld #ActiveHand #ActiveEvent #Sensor #Processor #ImageImports #SystemOrganization #World)

So...as every hardcoded stuff, this is not nice because as soon as globals change, we need to fix this. So it would be nice if the system (pharo) can provide us this information.

What do you think?

What I think is that the set of globals depends on usage.  Some time I might actually want to serialize the SourceFiles Array, sometimes I might not want to.  So this should be configurable, with a sensible default.  Just as when one serializes a set of classes, references to classes outside the set are not serialized, serializing some subset of global objects in Smalltalk should serialize those objects, not references.  So design some convenient API that allows one to specify which objects are not globals, and have the default be e.g. all global objects in Smalltalk.
 


--
Mariano
http://marianopeck.wordpress.com




--
best,
Eliot

Reply | Threaded
Open this post in threaded view
|

Re: How to globals that are NOT classes or traits?

Igor Stasenko
I think that we missing a way to determine to which package some
global belongs to.
When you loading a package it can declare new global, but there is no
reflective mechanisms in system to tell, to which package it belongs.
If we could have that, then clearly, if you serialize the package, you
would want to serialize its globals as well,
and if not, you can just leave a reference to it, which will be
rewired at materialization.

On 17 April 2012 18:20, Eliot Miranda <[hidden email]> wrote:

>
>
> On Tue, Apr 17, 2012 at 3:50 AM, Mariano Martinez Peck
> <[hidden email]> wrote:
>>
>> Hi guys. In Fuel, we need to identity which globals present in Smalltalk
>> globals are NOT classes or traits, because we need to manage them as
>> globals. So far we have a hardcoded list:
>>
>> defaultGlobalSymbols
>>
>>     ^ #(#Smalltalk #SourceFiles #Transcript #Undeclared #Display
>> #TextConstants #ActiveWorld #ActiveHand #ActiveEvent #Sensor #Processor
>> #ImageImports #SystemOrganization #World)
>>
>> So...as every hardcoded stuff, this is not nice because as soon as globals
>> change, we need to fix this. So it would be nice if the system (pharo) can
>> provide us this information.
>>
>> What do you think?
>
>
> What I think is that the set of globals depends on usage.  Some time I might
> actually want to serialize the SourceFiles Array, sometimes I might not want
> to.  So this should be configurable, with a sensible default.  Just as when
> one serializes a set of classes, references to classes outside the set are
> not serialized, serializing some subset of global objects in Smalltalk
> should serialize those objects, not references.  So design some convenient
> API that allows one to specify which objects are not globals, and have the
> default be e.g. all global objects in Smalltalk.
>
>>
>>
>>
>> --
>> Mariano
>> http://marianopeck.wordpress.com
>>
>
>
>
> --
> best,
> Eliot
>



--
Best regards,
Igor Stasenko.

Reply | Threaded
Open this post in threaded view
|

Re: How to globals that are NOT classes or traits?

Eliot Miranda-2


On Tue, Apr 17, 2012 at 10:11 AM, Igor Stasenko <[hidden email]> wrote:
I think that we missing a way to determine to which package some
global belongs to.
When you loading a package it can declare new global, but there is no
reflective mechanisms in system to tell, to which package it belongs.
If we could have that, then clearly, if you serialize the package, you
would want to serialize its globals as well,
and if not, you can just leave a reference to it, which will be
rewired at materialization.

+1.  Some construct that defines a module, analogous to a class definition?
 

On 17 April 2012 18:20, Eliot Miranda <[hidden email]> wrote:
>
>
> On Tue, Apr 17, 2012 at 3:50 AM, Mariano Martinez Peck
> <[hidden email]> wrote:
>>
>> Hi guys. In Fuel, we need to identity which globals present in Smalltalk
>> globals are NOT classes or traits, because we need to manage them as
>> globals. So far we have a hardcoded list:
>>
>> defaultGlobalSymbols
>>
>>     ^ #(#Smalltalk #SourceFiles #Transcript #Undeclared #Display
>> #TextConstants #ActiveWorld #ActiveHand #ActiveEvent #Sensor #Processor
>> #ImageImports #SystemOrganization #World)
>>
>> So...as every hardcoded stuff, this is not nice because as soon as globals
>> change, we need to fix this. So it would be nice if the system (pharo) can
>> provide us this information.
>>
>> What do you think?
>
>
> What I think is that the set of globals depends on usage.  Some time I might
> actually want to serialize the SourceFiles Array, sometimes I might not want
> to.  So this should be configurable, with a sensible default.  Just as when
> one serializes a set of classes, references to classes outside the set are
> not serialized, serializing some subset of global objects in Smalltalk
> should serialize those objects, not references.  So design some convenient
> API that allows one to specify which objects are not globals, and have the
> default be e.g. all global objects in Smalltalk.
>
>>
>>
>>
>> --
>> Mariano
>> http://marianopeck.wordpress.com
>>
>
>
>
> --
> best,
> Eliot
>



--
Best regards,
Igor Stasenko.




--
best,
Eliot

Reply | Threaded
Open this post in threaded view
|

Re: How to globals that are NOT classes or traits?

Frank Shearar-3
On 17 April 2012 18:52, Eliot Miranda <[hidden email]> wrote:

>
>
> On Tue, Apr 17, 2012 at 10:11 AM, Igor Stasenko <[hidden email]> wrote:
>>
>> I think that we missing a way to determine to which package some
>> global belongs to.
>> When you loading a package it can declare new global, but there is no
>> reflective mechanisms in system to tell, to which package it belongs.
>> If we could have that, then clearly, if you serialize the package, you
>> would want to serialize its globals as well,
>> and if not, you can just leave a reference to it, which will be
>> rewired at materialization.
>
>
> +1.  Some construct that defines a module, analogous to a class definition?

+1. I haven't had a chance to look yet, but it's possible Michael van
der Gulik's SecureSqueak does this already, or has taken steps towards
doing it:

* http://securesqueak.blogspot.co.uk/2011/05/now-where-was-i.html
* http://gulik.pbworks.com/
* http://gulik.pbworks.com/SecureSqueak

Michael's said he'd need to cut a new release if I (we) wanted to make
use of it.

frank

>> On 17 April 2012 18:20, Eliot Miranda <[hidden email]> wrote:
>> >
>> >
>> > On Tue, Apr 17, 2012 at 3:50 AM, Mariano Martinez Peck
>> > <[hidden email]> wrote:
>> >>
>> >> Hi guys. In Fuel, we need to identity which globals present in
>> >> Smalltalk
>> >> globals are NOT classes or traits, because we need to manage them as
>> >> globals. So far we have a hardcoded list:
>> >>
>> >> defaultGlobalSymbols
>> >>
>> >>     ^ #(#Smalltalk #SourceFiles #Transcript #Undeclared #Display
>> >> #TextConstants #ActiveWorld #ActiveHand #ActiveEvent #Sensor #Processor
>> >> #ImageImports #SystemOrganization #World)
>> >>
>> >> So...as every hardcoded stuff, this is not nice because as soon as
>> >> globals
>> >> change, we need to fix this. So it would be nice if the system (pharo)
>> >> can
>> >> provide us this information.
>> >>
>> >> What do you think?
>> >
>> >
>> > What I think is that the set of globals depends on usage.  Some time I
>> > might
>> > actually want to serialize the SourceFiles Array, sometimes I might not
>> > want
>> > to.  So this should be configurable, with a sensible default.  Just as
>> > when
>> > one serializes a set of classes, references to classes outside the set
>> > are
>> > not serialized, serializing some subset of global objects in Smalltalk
>> > should serialize those objects, not references.  So design some
>> > convenient
>> > API that allows one to specify which objects are not globals, and have
>> > the
>> > default be e.g. all global objects in Smalltalk.
>> >
>> >>
>> >>
>> >>
>> >> --
>> >> Mariano
>> >> http://marianopeck.wordpress.com
>> >>
>> >
>> >
>> >
>> > --
>> > best,
>> > Eliot
>> >
>>
>>
>>
>> --
>> Best regards,
>> Igor Stasenko.
>>
>
>
>
> --
> best,
> Eliot
>

Reply | Threaded
Open this post in threaded view
|

Re: How to globals that are NOT classes or traits?

drush66
In reply to this post by Igor Stasenko
Igor Stasenko wrote
I think that we missing a way to determine to which package some
global belongs to.
When you loading a package it can declare new global, but there is no
reflective mechanisms in system to tell, to which package it belongs.
If we could have that, then clearly, if you serialize the package, you
would want to serialize its globals as well,
and if not, you can just leave a reference to it, which will be
rewired at materialization.
For what is worth and as reference, Dolphin Smalltalk packages includes a list of globals that belong to it

Davorin Rusevljan

Reply | Threaded
Open this post in threaded view
|

Re: How to globals that are NOT classes or traits?

HwaJong Oh
In reply to this post by Mariano Martinez Peck
Mariano,

Rejecting all classes and traits might give you global variables.

Smalltalk globals size. "2188"

(Smalltalk globals copyWithoutAll: Smalltalk allClasses) size. "95"

((Smalltalk globals copyWithoutAll: Smalltalk allClasses) copyWithoutAll: Smalltalk allTraits) size. "14"

Regards,
HwaJong
Reply | Threaded
Open this post in threaded view
|

Re: How to globals that are NOT classes or traits?

Stéphane Ducasse
In reply to this post by Eliot Miranda-2
>
> I think that we missing a way to determine to which package some
> global belongs to.
> When you loading a package it can declare new global, but there is no
> reflective mechanisms in system to tell, to which package it belongs.
> If we could have that, then clearly, if you serialize the package, you
> would want to serialize its globals as well,
> and if not, you can just leave a reference to it, which will be
> rewired at materialization.
>
> +1.  Some construct that defines a module, analogous to a class definition?

Yes something that contains definitions.
We will start to work on that after first class instance variables



>  
>
> On 17 April 2012 18:20, Eliot Miranda <[hidden email]> wrote:
> >
> >
> > On Tue, Apr 17, 2012 at 3:50 AM, Mariano Martinez Peck
> > <[hidden email]> wrote:
> >>
> >> Hi guys. In Fuel, we need to identity which globals present in Smalltalk
> >> globals are NOT classes or traits, because we need to manage them as
> >> globals. So far we have a hardcoded list:
> >>
> >> defaultGlobalSymbols
> >>
> >>     ^ #(#Smalltalk #SourceFiles #Transcript #Undeclared #Display
> >> #TextConstants #ActiveWorld #ActiveHand #ActiveEvent #Sensor #Processor
> >> #ImageImports #SystemOrganization #World)
> >>
> >> So...as every hardcoded stuff, this is not nice because as soon as globals
> >> change, we need to fix this. So it would be nice if the system (pharo) can
> >> provide us this information.
> >>
> >> What do you think?
> >
> >
> > What I think is that the set of globals depends on usage.  Some time I might
> > actually want to serialize the SourceFiles Array, sometimes I might not want
> > to.  So this should be configurable, with a sensible default.  Just as when
> > one serializes a set of classes, references to classes outside the set are
> > not serialized, serializing some subset of global objects in Smalltalk
> > should serialize those objects, not references.  So design some convenient
> > API that allows one to specify which objects are not globals, and have the
> > default be e.g. all global objects in Smalltalk.
> >
> >>
> >>
> >>
> >> --
> >> Mariano
> >> http://marianopeck.wordpress.com
> >>
> >
> >
> >
> > --
> > best,
> > Eliot
> >
>
>
>
> --
> Best regards,
> Igor Stasenko.
>
>
>
>
> --
> best,
> Eliot
>


Reply | Threaded
Open this post in threaded view
|

Re: How to globals that are NOT classes or traits?

Stéphane Ducasse
In reply to this post by HwaJong Oh
we should try to reduce their number. I like newspeak solution to this regard.

Stef