- Pharo-dev - lists.pharo.org

Re: [Pharo-project] relation to squeak

by Frank Shearar

On 3 November 2011 19:41, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > >> Hello! >> >> One thing is not clear to me. How is Pharo related to standard Squeak? I know Pharo is a fork with its own mission, but is the development related? Do fixes in Pharo propagate upstream to Squeak? Is Squeak even considered "upstream"? Do fixes in Squeak propagate into Pharo? Automatically or manually? Or have they started being developed completely independently from some point in time? > > We do not really look at squeak. No time for that. Now if people having time mentioned that we have an interesting fix then we will be inclined to include it in pharo. Well, I guess it depends on what you mean by "we" - "we" as an Official Pharo Official, sure, I can understand - rightly so - that you're concentrating on what Pharo needs. "We" as a vocal subcommunity of Pharo also work with Squeak, trying to pull the two codebases back together. And that's a good thing, that there are both forces. Pharo the Official Direction is cutting new ground in a particular direction, and the Pharo+Squeak folk try to make sure that there isn't too much duplication of effort. There are few enough Smalltalkers in the two communities: we ought to try leverage off each other as much as we can. frank > Let me restate our vision and why we decided to make Pharo. > Our goal and vision behind Pharo is to twofold: > Â Â Â Â - make sure that people can make money and create their own wealth in Smalltalk. Provide the best environment we can for that (and this is not easy) > Â Â Â Â This is really important for us. A part of the team here is working on setting up a company around tools build on top of Pharo. > Â Â Â Â We are really happy when we hear that people are using Pharo for making business (net style, nextPlan, b9, pinesoft)â¦. > Â Â Â Â This is really great. > > Â Â Â Â - bring Smalltalk to the next level: > Â Â Â Â Â Â Â Â - first class variables > Â Â Â Â Â Â Â Â - small core > Â Â Â Â Â Â Â Â - may be new mop > Â Â Â Â Â Â Â Â - powerful tools and abstractions > Â Â Â Â The idea is to have a solid infrastructure to be able to invent the next generation smalltalkish system because smalltalk lacks a lot and innovation stopped a while ago. > Â Â Â Â Â Â Â Â (real sandboxing, real minimal kernel with pluggable uiâ¦) > > It will take time but we will get there. > > Stef >

Nov. 3, 2011

Re: [Pharo-project] Simple vs. Easy

by StÃ©phane Ducasse

We are easy in debugging. Now I would like to be easy in C interaction C embedding UI building File manipulation Stef > Hello, > > I watched a video presentation by Rich Hickey, the creator of Clojure, on Simple Made Easy. > www.infoq.com/presentations/Simple-Made-Easy > > It is a very interesting video. I don't necessarily agree with everything he says. But I believe he makes some valuable distinctions between simple and easy. > > Where are we in Pharo simple? > Where are we easy? > > What can we do to move things from easy to simple? > > I am not qualified to answer his challenge to object oriented languages. But I feel that Smalltalk is the most functional OO language I've seen. And I don't necessarily mean functional in the programming methodology sense, but I don't rule it out either. I don't believe that C++ and Java will provide the best OO or programming experience. > > Watch the video. > I would love to hear some opinions from the community. > > How can we move Pharo to be a better answer to Simple vs. Easy? > > Thanks. > > Jimmie >

Nov. 3, 2011

[Pharo-project] Simple vs. Easy

by Jimmie Houchin

Hello, I watched a video presentation by Rich Hickey, the creator of Clojure, on Simple Made Easy. www.infoq.com/presentations/Simple-Made-Easy It is a very interesting video. I don't necessarily agree with everything he says. But I believe he makes some valuable distinctions between simple and easy. Where are we in Pharo simple? Where are we easy? What can we do to move things from easy to simple? I am not qualified to answer his challenge to object oriented languages. But I feel that Smalltalk is the most functional OO language I've seen. And I don't necessarily mean functional in the programming methodology sense, but I don't rule it out either. I don't believe that C++ and Java will provide the best OO or programming experience. Watch the video. I would love to hear some opinions from the community. How can we move Pharo to be a better answer to Simple vs. Easy? Thanks. Jimmie

Nov. 3, 2011

Re: [Pharo-project] Comment Syntax

by Jimmie Houchin

On 10/31/2011 3:12 PM, Sean P. DeNigris wrote: > Would it be difficult/valuable to create an alternate comment syntax? I often > find myself wanting to comment a large block itself containing comments. It > would be nice to have something like C++'s /* */. I feel like this may have > been brought up before, but couldn't find it searching the lists. > > Sean My favorite string and comment handling is Lua. In Lua you can create strings as in many languages with quoting via ' or ". Lua also provides string creation via double square brackets, ie: [[ a string ]] Everything between [[]] is a string. These are there standard conventions. Then they also allow user created delimiters. Any string can be created with [=[ a string ]=] You may place any number of = characters between the two open brackets and an equal number between the two closing brackets. This makes for string creation which automatically allows for inclusion in the string any of the normal string delimiters. The reason I mention this in this thread is that they do similar for comments. Lua comments are single line -- this is a comment Or multiline --[[ this is a multiline comment --]] or --[=[ another multiline comment with user defined delimiters -]=] I don't know if anything like this can be brought into Pharo.* But I think it is an awesome and very convenient way to do strings and comments. *no requirement to use these specific delimiter choices. I never liked the limitations imposed in Smalltalk's string and comment creation. Just a few thoughts. Jimmie

Nov. 3, 2011

Re: [Pharo-project] relation to squeak

by StÃ©phane Ducasse

> Hello! > > One thing is not clear to me. How is Pharo related to standard Squeak? I know Pharo is a fork with its own mission, but is the development related? Do fixes in Pharo propagate upstream to Squeak? Is Squeak even considered "upstream"? Do fixes in Squeak propagate into Pharo? Automatically or manually? Or have they started being developed completely independently from some point in time? We do not really look at squeak. No time for that. Now if people having time mentioned that we have an interesting fix then we will be inclined to include it in pharo. Let me restate our vision and why we decided to make Pharo. Our goal and vision behind Pharo is to twofold: - make sure that people can make money and create their own wealth in Smalltalk. Provide the best environment we can for that (and this is not easy) This is really important for us. A part of the team here is working on setting up a company around tools build on top of Pharo. We are really happy when we hear that people are using Pharo for making business (net style, nextPlan, b9, pinesoft)â¦. This is really great. - bring Smalltalk to the next level: - first class variables - small core - may be new mop - powerful tools and abstractions The idea is to have a solid infrastructure to be able to invent the next generation smalltalkish system because smalltalk lacks a lot and innovation stopped a while ago. (real sandboxing, real minimal kernel with pluggable uiâ¦) It will take time but we will get there. Stef

Nov. 3, 2011

Re: [Pharo-project] FS Quirks

by StÃ©phane Ducasse

Thanks somebody has to take some times and go over them, write some tests and some fixes. I noticed that the chapter has some code that does not work anymore with the latest version. stef On Nov 3, 2011, at 4:23 PM, Sean P. DeNigris wrote: > I noticed a few things about FS, but I don't understand it well enough yet to > know if they are bugs: > * there are #basicXxx methods scattered around with no corresponding #xxx > method. It seems like these should be renamed to #xxx > * FSFileSystem has #open:writable which does not call #basicOpen:writable, > which exists > * FSReference>>rename:as:, but FSFilePluginPrims>>rename:to: (to: sounds > better to me) > > -- > View this message in context: http://forum.world.st/FS-Quirks-tp3986296p3986296.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

Nov. 3, 2011

Re: [Pharo-project] [Pharo-users] Brainstorming on the roadmap for first Pharo Consortium Engineer :)

by Igor Stasenko

On 3 November 2011 17:16, Max Leske <maxleske(a)gmail.com> wrote: > :-D > I said: "In MY opinion" > > Ok, so the .changes file serves as a backup. But shouldn't the file be optional? e.g. the source code is in the image and changes are backed up to an extra file to guard against crashes. But I think, the image should not depend on that file. > Does this make more sense? > It is. > Max > > > On 03.11.2011, at 16:12, Sean P. DeNigris wrote: > >> >> Frank Shearar-3 wrote: >>> >>> I'm tempted to say that if you've never had to use your .changes file >>> to recover, you're not working hard enough :) >> >> Oh my, how my *ss has been saved by the .changes file. Especially while >> doing dangerous but important things (e.g testing bleeding edge cog vms). I >> can't count the hours... >> >> -- >> View this message in context: http://forum.world.st/Brainstorming-on-the-roadmap-for-first-Pharo-Consorti… >> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >> > > > -- Best regards, Igor Stasenko.

Nov. 3, 2011

Re: [Pharo-project] [Pharo-users] Brainstorming on the roadmap for first Pharo Consortium Engineer :)

by Max Leske

:-D I said: "In MY opinion" Ok, so the .changes file serves as a backup. But shouldn't the file be optional? e.g. the source code is in the image and changes are backed up to an extra file to guard against crashes. But I think, the image should not depend on that file. Does this make more sense? Max On 03.11.2011, at 16:12, Sean P. DeNigris wrote: > > Frank Shearar-3 wrote: >> >> I'm tempted to say that if you've never had to use your .changes file >> to recover, you're not working hard enough :) > > Oh my, how my *ss has been saved by the .changes file. Especially while > doing dangerous but important things (e.g testing bleeding edge cog vms). I > can't count the hours... > > -- > View this message in context: http://forum.world.st/Brainstorming-on-the-roadmap-for-first-Pharo-Consorti… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

Nov. 3, 2011

Re: [Pharo-project] relation to squeak

by Frank Shearar

On 3 November 2011 15:05, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > While there is no official relationship, it seems to me that the communities > are becoming very friendly and symbiotic, after the initial tension that > always accompanies a "break up" ;-) There were lively, fun, interesting > dinners including key members of both at ESUG this year. Fixes are > propagated both ways if the devs think they are valuable. Much of the API > seems to still be the same, as the major focus so far seems to be clean up. > During this process, Pharo has been much more aggressive about removing > ugly/dirty code because backward compatibility is not as primary to the > mission as it is in Squeak. Also, there are many exciting fundamental > projects underway in Pharo (new filesystem, compiler, browser, on and on), > so the forks may diverge quite a bit in the near future. There are also a number of folks spending time in both communities: I wouldn't be surprised to see many of those exciting new projects being ported to Squeak. frank > > HTH, > Sean > > -- > View this message in context: http://forum.world.st/relation-to-squeak-tp3986029p3986229.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > >

Nov. 3, 2011

[Pharo-project] FS Quirks

by Sean P. DeNigris

I noticed a few things about FS, but I don't understand it well enough yet to know if they are bugs: * there are #basicXxx methods scattered around with no corresponding #xxx method. It seems like these should be renamed to #xxx * FSFileSystem has #open:writable which does not call #basicOpen:writable, which exists * FSReference>>rename:as:, but FSFilePluginPrims>>rename:to: (to: sounds better to me) -- View this message in context: http://forum.world.st/FS-Quirks-tp3986296p3986296.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Nov. 3, 2011