February 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Cobol is the new language to know?

by Eliot Miranda

On Tue, Feb 22, 2011 at 7:12 AM, Casimiro de Almeida Barreto < casimiro.barreto(a)gmail.com> wrote: > Em 22-02-2011 05:12, Geert Claes escreveu: > > > > csrabak wrote: > >>> Focusing in the squeak/pharo/cuis branch, I've noticed that pharo > >>> people got really concerned in > >>> aspects that can attract market interest. They're looking for > >>> funding, fighting to have "hired > >>> people" (meaning under wages) minding "hairy aspects" of development, > >>> maintenance, documentation > >>> and some sort of "standardization", etc. Collaborators also produced > >>> interesting "printed material" (books, > >>> tutorials) but IMO such material is still very academic in nature. > People > >>> in industry likes best "manual" > >>> stuff (like "foundation classes" with "methods" (messages in the > >>> case) documented, etc). IMO (again) > >>> here lies a relevant problem: there are "no foundation classes" (no > >>> "landmarks" or things that cannot be > easily changed) and it becomes > >>> apparent when people exchange ideas about "keeping this" and "getting > >>> rid of that". At least debate is going on and many issues have been > >>> addressed. > >> > >> Yes. > >> > > I don't understand what was said here? Can someone elaborate? > In order to increase acceptance of smalltalk in corporate world (and > even in academic and scientific worlds) someone (pharo/squeak/cuis > people) must come out with a solution that: > > 1) Is well documented > 2) Is supported > 3) Is stable > IMO, while important, this misses the most important features which together provide a useful platform: 1. excellent FFI (including threading support) so that the system can be integrated with other code, both as a user of libraries and as a provider of libraries 2. support for foreign files in Monticello so that Monticello can be used to manage complete projects, not just the Smalltalk assets 3. scripting and excellent file system facilities so that one can easily interact with the file system, still a vital part of the majority of software systems (the Squeak file system code is a cruel joke, still resembling the original Smalltalk-80 code from the late 70's). Without the necessary functionality people simply can't use Squeak to produce their applications and are forced to choose something else. These features, along with good web support, are what I understand by "platform". The web support is also pretty good, with Seaside, SSL, ODBC, HTTP connectivity, etc being pretty good. The community has made excellent progress over recent years. The "well documented", "supported" and stable" features are not terrible. Yes they can always be improved but on the whole that's not the fundamental block to effective use of Squeak/Pharo. Performance is also not an issue to getting started; plenty of Ruby and PHP projects sow that one can tackle performance later on. Fundamental is providing a platform and we're not there yet. 2Â¢ Eliot > To be well documented (in the sense corporate world understands it) a > smalltalk distro must: > > 1) Have a body (a set of) classes that are considered "foundation > classes". Those must be present in all versions of the distribution and > must have an unchanging set of features (in the case of smalltalk: an > unchanging set of messages,considering instance and class variables are > available through assessors). Those foundation classes must cover a > range of functionalities that makes the distro useful. > 2) These foundation classes must be documented in a way that resembles, > at least, man pages of *nix (syntax, semantics, dependencies, known > bugs, exceptions, etc) > 3) Foundation classes should be arranged in "orthogonal" packages > (meaning: if I unload one package everything that doesn't depend on it > still works). Anyways, dependencies should be documented in a very clear > and explicit way. > > Just to give an example on how lack of documentation hurts open > smalltalk, how many people gave it up for not being able to deliver > acceptable interfaces because Morphic is hideously documented? I know > several ones. In real corporate world, learning through trial and error > is not acceptable, just like blowing schedule up due to the need to > figure out by experience how ProportionalLayout works neither... > > To be supported there must be people in charge of: > > 1) Debugging and fixing it (inside a well known schedule & following an > agreed maintenance protocol) > 2) Elaborating suitable documentation (as described above) > 3) Preparing didactic material (courses, books, etc) > 4) Disseminating information of what's going on inside distro's > development (much in the way Ubuntu/Fedora/etc communities do) > > Stable is stable... > > There are other things that are important but IMO they all come after > ones I just wrote about. > >

Feb. 22, 2011

Re: [Pharo-project] Issue 3742 in pharo: MorphTreeMorph keyStroke: send Event object instead of Character

by pharo＠googlecode.com

Comment #4 on issue 3742 by camillob...(a)gmail.com: MorphTreeMorph keyStroke: send Event object instead of Character http://code.google.com/p/pharo/issues/detail?id=3742 I don't see a reason to only provide the character? if you work with anything derived from the event why not give access to the full event? Its not about breaking MorphTreeMorph users but about providing functionality. I used it to implement CMD and CTRL based actions on the MorphTreeMorph, Which is close to impossible if you just get the character in.

Feb. 22, 2011

[Pharo-project] [update 1.3] #13061

by StÃ©phane Ducasse

13061 ----- - Issue 3740: Provide Settings to directly open the full Debugger View. Thanks Camillo Bruni. - Issue 3739: Show the currently selected Category, Class, Protocol and Selector in the Browser title. Thanks Camillo Bruni. - Fixed order of worldMenu entries - Fixed setting of Transcript>>characterLimit Stef and Alain

Feb. 22, 2011

Re: [Pharo-project] Issue 3739 in pharo: Show the currently selected Category, Class, Protocol and Selector in the Browser title

by pharo＠googlecode.com

Updates: Status: Closed Comment #3 on issue 3739 by stephane...(a)gmail.com: Show the currently selected Category, Class, Protocol and Selector in the Browser title http://code.google.com/p/pharo/issues/detail?id=3739 We integrate it but we removed the package and cat because this is too long. in 13061

Feb. 22, 2011

Re: [Pharo-project] Issue 3739 in pharo: Show the currently selected Category, Class, Protocol and Selector in the Browser title

by pharo＠googlecode.com

Comment #2 on issue 3739 by stephane...(a)gmail.com: Show the currently selected Category, Class, Protocol and Selector in the Browser title http://code.google.com/p/pharo/issues/detail?id=3739 Camillo you should always update to the latest update before changing and submitting. Here we got old changes back. Stef

Feb. 22, 2011

Re: [Pharo-project] Issue 3740 in pharo: Provide Settings to directly open the full Debugger View

by pharo＠googlecode.com

Comment #2 on issue 3740 by stephane...(a)gmail.com: Provide Settings to directly open the full Debugger View http://code.google.com/p/pharo/issues/detail?id=3740 Camillo We integrated your setting in 13061. However we could not see its effect in action. We tried with Command . (we got only full). We tried with class side self error: 'zork' and there we always get the preDebug window. So could you update to 13061 and check it.

Feb. 22, 2011

Re: [Pharo-project] Issue 3742 in pharo: MorphTreeMorph keyStroke: send Event object instead of Character

by pharo＠googlecode.com

Comment #3 on issue 3742 by aplan...(a)gmail.com: MorphTreeMorph keyStroke: send Event object instead of Character http://code.google.com/p/pharo/issues/detail?id=3742 Hi Camillo, Why ? Normally the model only need the character not the event. MorphTreeMorph models are considering it as a character not as an event, so it would break all MorphTreeMorph users.

Feb. 22, 2011

Re: [Pharo-project] Issue 3743 in pharo: Fix Finder UI (add shortcuts and more commands)

by pharo＠googlecode.com

Comment #2 on issue 3743 by stephane...(a)gmail.com: Fix Finder UI (add shortcuts and more commands) http://code.google.com/p/pharo/issues/detail?id=3743 Ben can you integrate this changes? Tx

Feb. 22, 2011

Re: [Pharo-project] Issue 3724 in pharo: Finder updated

by pharo＠googlecode.com

Comment #2 on issue 3724 by stephane...(a)gmail.com: Finder updated http://code.google.com/p/pharo/issues/detail?id=3724 Benjamin can you update your fixes and integrate the ones of camillo to the latest version. We tried to integrate it with alain but we do not know if we will not break something and you know more than us on what you did.

Feb. 22, 2011

Re: [Pharo-project] Issue 3724 in pharo: Finder updated

by pharo＠googlecode.com

Updates: Labels: Milestone-1.3 Comment #1 on issue 3724 by stephane...(a)gmail.com: Finder updated http://code.google.com/p/pharo/issues/detail?id=3724 (No comment was entered for this change.)

Feb. 22, 2011