Slot questions

The Slot work looks great!  For now, I have these questions:
1) Will a slot be able to enforce the notion of privacy, such that the
slot can only be called by self?  The current implementation of the
'pvt' prefix doesn't seem to work for me.
2) The 'Flexible Object Layouts' paper in listing 4, doesn't smell right
for ManySlot>>initializeInstance: which has a super call which is not
#initializeInstance:

-Paul

On 2013-04-04, at 17:42, Paul Davidowitz <[hidden email]> wrote:

> The Slot work looks great!  For now, I have these questions:
> 1) Will a slot be able to enforce the notion of privacy, such that the
> slot can only be called by self?  

well full privacy is going to be difficult, but using unique symbols (aka Strings)
as identifiers combined with strong equality, you can get something close to private
slots.

> The current implementation of the
> 'pvt' prefix doesn't seem to work for me.

Which image did you use?

> 2) The 'Flexible Object Layouts' paper in listing 4, doesn't smell right
> for ManySlot>>initializeInstance: which has a super call which is not
> #initializeInstance:

yes that should be a self send, since it is not overwritten anywhere else in
the hierarchy.

> Message: 5
> Date: Thu, 4 Apr 2013 17:58:42 +0200
> From: Camillo Bruni <[hidden email]>
> To: A friendly place where any question about pharo is welcome
> <[hidden email]>
> Subject: Re: [Pharo-users] Slot questions
> Message-ID: <[hidden email]>
> Content-Type: text/plain; charset=us-ascii
>
...
>
> > The current implementation of the
> > 'pvt' prefix doesn't seem to work for me.
>
> Which image did you use?

I'm using Pharo2.0 Latest update: #20589.  
I inspect:
PjdTest1 new pvt1
and get #q, for this fileout:
~~~~~
'From Pharo2.0 of 7 March 2013 [Latest update: #20589] on 4 April 2013
at 1:42:57 pm'!
Object subclass: #PjdTest1
        instanceVariableNames: ''
        classVariableNames: ''
        poolDictionaries: ''
        category: ''!

!PjdTest1 methodsFor: 'as yet unclassified' stamp: 'PaulDavidowitz
4/4/2013 11:27'!
pvt1

        ^#q! !
~~~~~

Also, is there a good technique for responding to questions in this
email forum, other than the clumsy copy/pasting/editing of the prior
post?

On 2013-04-04, at 19:51, Paul Davidowitz <[hidden email]> wrote:


2.0 doesn't have slots by default. So where did you get the
slot image from? I am bit confused :)

Most of the people use the mailinglist directly, so I cannot answer that :)

On Apr 4, 2013, at 7:54 PM, Camillo Bruni <[hidden email]> wrote:
>
> 2.0 doesn't have slots by default. So where did you get the
> slot image from? I am bit confused :)

The pvt* stuff is something that we removed from Pharo… it was not used
and quite strangely implemented.

To Camillo Bruni:  
I'm not using any slot image (I only looked over the paper). According
to the Pharo book, 'pvt' should be implemented in the mainstream image.

To Marcus Denker:
There are actually several methods in the image with the 'pvt' prefix.
Please update the doc (Pharo book) to remove talking about 'pvt'.  It
would have saved me a little headache :)

On Apr 4, 2013, at 8:15 PM, Paul Davidowitz <[hidden email]> wrote:

> To Camillo Bruni:  
> I'm not using any slot image (I only looked over the paper). According
> to the Pharo book, 'pvt' should be implemented in the mainstream image.
>
The Pharo book is about a version of Pharo from many years ago.

> To Marcus Denker:
> There are actually several methods in the image with the 'pvt' prefix.
> Please update the doc (Pharo book) to remove talking about 'pvt'.  It
> would have saved me a little headache :)
>
The pharo book is very old… yes, we need to update it. What should I not
do to have time for that?

        Marcus

On 04 Apr 2013, at 20:21, Marcus Denker <[hidden email]> wrote:

Documentation, of any kind, always comes back to haunt you.
This is a real problem, even a class or method comments quickly gets out of sync as software evolves.
Maybe, just like in code, the key is to write as little as possible in an elegant non repetitive way.

Sven


--
Sven Van Caekenberghe
Proudly supporting Pharo
http://pharo.org
http://association.pharo.org
http://consortium.pharo.org

> The pharo book is very old… yes, we need to update it. What should I not
> do to have time for that?

Maybe just putting a banner or some unavoidable visual feedback
stating that the book refers to a previous version of Pharo, and the
new version is on its way (if it is, otherwise I'd just leave the
first part :))

Regards!

On Thu, 04 Apr 2013 19:25:35 +0100, Sven Van Caekenberghe <[hidden email]>  
wrote:

That's fine if you never want to have new people pick up your project and  
get started. Otherwise I would say that an undocumented API may as well  
never have been built. Look at Morphic. That's about all you can do with  
it if you've got a full time job that's not Smalltalk related - look at  
it. The documentation is about zilch and what there is consists of layers  
and layers of material relating to varying systems of varying ages.

The answer to Marcus' question "what should I not do to have time for  
that" is "anything". Nothing is more important than accurate  
documentation. Even a system that is broken will get fixed quicker if  
there is documentation which allows new hands to be added to the task of  
fixing it.

Incorrect documentation is WORSE than no documentation; would anyone  
really suggest that Pharo would be a viable system without any  
documentation?

My experience of several large Open Source projects (and many Closed  
Source ones) is that the people involved in the projects get familiar with  
the APIs and methods and can fail to see just how hard it has become for  
outsiders to break in.

This is why I'm worried about slots. At the moment I can at least learn  
about Smalltalk generically and pick up Pharo and, with a lot of effort,  
get to the point that I can do something useful. If new concepts are added  
to the language *and then used by the in-group to get on with the things  
they're interested in* without good documentation then all that has  
happened is that the tool has become more specialized for the work of the  
contributing group while becoming harder to access for others.

I'm *not* really that worried about slots in and of themselves if they can  
be added cleanly; I'm more worried about the gap between what  
documentation there is and how the system *actually* works growing ever  
wider.

I'm also not attempting to say that those who are very active with Pharo  
are bad programmers because documentation has become problematical - if  
they are then I'm a bad programmer too - I just want to point out that a  
system has even more need of documentation than a completed application  
and *if it's possible* (and I know that finance is an issue in the real  
world) then I think that updating the Pharo book(s) to a point where they  
describe the current Pharo 2.0 state is FAR more important than work on  
Pharo 3.0.

Well, that's my view, anyway as a professional programmer who has  
struggled to get to grips with Pharo in my spare time.

Thomas Worthington

On Apr 6, 2013, at 7:00 PM, "Thomas Worthington" <[hidden email]> wrote:
>  Look at Morphic.

Morphic is a mess of epic proportion. The ideas are good (the basic ones), but the implementation is beyond hope.

> That's about all you can do with it if you've got a full time job that's not Smalltalk related -

Morphic is unmaintanable and unusable for everyone.

>
> The answer to Marcus' question "what should I not do to have time for that" is "anything".

Anything is a bit of a hard thing.. e.g. Morphic does not need to be documented, it needs to be thrown away and
reimplemented. It's just  a pile of crap.


> I'm also not attempting to say that those who are very active with Pharo are bad programmers because documentation has become problematical - if they are then I'm a bad programmer too - I just want to point out that a system has even more need of documentation than a completed application and *if it's possible* (and I know that finance is an issue in the real world) then I think that updating the Pharo book(s) to a point where they describe the current Pharo 2.0 state is FAR more important than work on Pharo 3.0.


We need both. Documentation is important, but just documenting a system that nobody needs makes no sense, either.

        Marcus

On Sat, 06 Apr 2013 18:10:26 +0100, Marcus Denker <[hidden email]>  
wrote:
I would agree. I don't think that Pharo2.0 counts as a system that nobody  
needs, though. I'm paid to develop for Moodle, a vast PHP-based e-learning  
project and I can assure you that the world is full of people who need a  
proper OO development system!

Obviously there's a balance to be had, but I don't think that it's too  
radical to suggest that a major version bump should be followed by a  
period of consolidation in the documentation before proceeding.

TW

If I may give my unsolicited two cents as well, I agree, the biggest barrier to adoption is the roadblock of not understanding a system. And pharo and smalltalk are large complex systems that deviate from the average programming environment norm.

For those that aren't paid to research, free time and energy to explore and accidentally gain an understanding of pharo is sparse and costly.

Documentation is the only thing that can alleviate that problem. If good documentation allows for more people to use the system then you will have more developers helping out on the next iterations of pharo.

Victor Stan

Marcus

I think that we improve Morphic a lot and we will continue.
I do not think that this is wise to bash the only graphical system we have except if you want to use a web based solution.
For me I still think that there is a good value in Morphic but that we should continue to improve it.
And of course this is not an easy task.

Stef

On Apr 6, 2013, at 7:10 PM, Marcus Denker <[hidden email]> wrote:

Thomas

I suggest you not to stress. Did you see the introduction of FileSystem?
We did it perfect and you get a documentation.

So focus on what you want to do and do not stress about the rest.
I can tell you that we know what we are doing and we certainly care more about the system that many other people.
Pharo systematically improves and its documentation too.
Now if you have a couple of hundred of thousand of dollars we can fix such situation fast, else it will just get slowler.


Stef

As usual, though, a lot of interesting ideas emerge from this.

If we were to do documentation in a "Smalltalky" way, then what would it look like?

Perhaps something like Doug Engelbart's NLS system, in outlines, but each element of the outline would have an associative history to it. That would mean breaking the process of description down to familiar component parts. Selecting a version of the software would flow through the outline, calling up the appropriate historical elements. That would enable comparative documentation.

Or is it possible to find some kind of self documentation that would be better than the useful but a little crude class comments?

It seems like such a basic thing to get right, but really very little work has been done on it.

Hi All,

I'm getting tired of Pharo 4 beta freezing.  It happens whenever a
exception occurs while in the debugger.

Funny that I don't remember any of the Pharo 4 development images freezing.

Which image can I use that won't do this?

Craig

well… pharo4 is not a beta :)
weird that no one else reports same bug… can you give us a way to reproduce the problem? Instead telling you which image does not have a problem I was not aware, I would like more to give you a bugfix :)

Esteban

Sure thing.

To see the bug, file the code below into a clean image and run the
example.  The when the debugger pops, step over each line in the
method.  I'm doing this on a Windows OS.

Object subclass: #Cooler
     instanceVariableNames: ''
     classVariableNames: ''
     poolDictionaries: ''
     category: 'ImageFreeze'!

!Cooler methodsFor: 'as yet unclassified' stamp: 'CraigJohnson 6/1/2015
23:31'!
runMe
     |  a |
     self halt.
     self except.
     a := 1.! !

"-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- "!

Cooler class
     instanceVariableNames: ''!

!Cooler class methodsFor: 'as yet unclassified' stamp: 'CraigJohnson
6/1/2015 23:16'!
example
     self new runMe ! !



On 2015/06/01 11:00 PM, Esteban Lorenzano wrote: