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 <pdavidow@fastmail.fm> 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 <marcus.denker@inria.fr> wrote:
On Apr 4, 2013, at 8:15 PM, Paul Davidowitz <pdavidow@fastmail.fm> 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
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
On Thu, 04 Apr 2013 19:25:35 +0100, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 04 Apr 2013, at 20:21, Marcus Denker <marcus.denker@inria.fr> wrote:
On Apr 4, 2013, at 8:15 PM, Paul Davidowitz <pdavidow@fastmail.fm> 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
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.
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" <thomas@technouveau.co.uk> 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 <marcus.denker@inria.fr> wrote:
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.
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 On Apr 6, 2013 2:35 PM, "Thomas Worthington" <thomas@technouveau.co.uk> wrote:
On Sat, 06 Apr 2013 18:10:26 +0100, Marcus Denker <marcus.denker@inria.fr> wrote:
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.
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
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 <marcus.denker@inria.fr> wrote:
On Apr 6, 2013, at 7:00 PM, "Thomas Worthington" <thomas@technouveau.co.uk> 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
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
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
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. -- View this message in context: http://forum.world.st/Slot-questions-tp4679631p4829738.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
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
On 01 Jun 2015, at 22:31, Craig Johnson <craig@hivemind.net> wrote:
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
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:
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
On 01 Jun 2015, at 22:31, Craig Johnson <craig@hivemind.net> wrote:
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
2015-06-01 23:44 GMT+02:00 Craig Johnson <craig@hivemind.net>:
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 ! !
This worked until pharo 40245 -> it looks like phase4 in issue 11996 <https://pharo.fogbugz.com/default.asp?11996> Wrong exception handler problem introduced this behavior.
On 2015/06/01 11:00 PM, Esteban Lorenzano wrote:
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
On 01 Jun 2015, at 22:31, Craig Johnson <craig@hivemind.net> wrote:
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
Yes, indeed⦠Knuthâs Literary Programming was one radical (yet very static and Book-Like) try. We added the tutorials, that is already better than just the class comment, but they are then not âconnectedâ with the code⦠So indeed: a lot of open space for research + practical improvements. For Slots I will stay very old fashioned and write a Tutorial. Marcus
On 01 Jun 2015, at 11:44, tsl4 <scott@hnn.bz> wrote:
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.
-- View this message in context: http://forum.world.st/Slot-questions-tp4679631p4829738.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
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!
participants (11)
-
Craig Johnson -
Esteban A. Maringolo -
Esteban Lorenzano -
Marcus Denker -
Nicolai Hess -
Paul Davidowitz -
stephane ducasse -
Sven Van Caekenberghe -
Thomas Worthington -
tsl4 -
Victor Stan