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

[Pharo-project] bootable Pharo image

by Pavel Krivanek

Hi, I tried to prepare a bootable Pharo ISO image based on Tiny Core Linux. Namely on MicroCore (kernel 3.0.3) that was extended with WiFi support. There is standard Pharo 1.3 image with OSProcess and CommandShell installed on the Smalltalk side. The resultant image has about 37 MB. Download: http://www.windmap.cz/playground/pharo/pharo.iso If you want to add it directly to your Grub menu, you may do it without need of extra partition. To the grub.conf add something like: title Pharo root (hd0,1) kernel /boot/pharo/vmlinuz vga=791 quiet initrd /boot/pharo/tinycore.gz where vmlinuz and tinycore.gz are the only files needed from the ISO image. Remastering: unpack: zcat tinycore.gz | sudo cpio -i -H newc -d pack: find | cpio -o -H newc | gzip -2 > ../tinycore.gz better compression: advdef -z4 tinycore.gz create ISO (you need unpacked original ISO image): /bin/cp -pfr tinycore.gz boot mkdir -p newiso /bin/cp -pfr boot newiso mkisofs -l -J -R -V TC-custom -no-emul-boot -boot-load-size 4 \ -boot-info-table -b boot/isolinux/isolinux.bin \ -c boot/isolinux/boot.cat -o pharo.iso newiso Cheers, -- Pavel

Nov. 3, 2011

Re: [Pharo-project] Simple vs. Easy

by Schwab,Wilhelm K

It is a good talk - thanks for mentioning it here! At several points, I was reminded of Beck's "Lots of little pieces," which is great advice. I have mixed feelings on (what I think he meant??) using undifferentiated collections for holding data. I use dictionaries a lot, and some things really are naturally arrays - no argument there. However, there are times when "points" in some weird cross product space could be represented as arrays, but there are huge benefits from having a class that "understands" the problem-specifics (and proves it via #printOn:). Put another way, one can explore and array of arrays, or an array of objects with named aspects and helpful string representations. The resulting classes then provide natural places to add behavior. Stef, I like your list. I might tweak it just a bit: let's be easy in C integration and simple in UI building. Maybe we can layer an easy tool on top of a simple framework for the latter?? Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of StÃ©phane Ducasse [stephane.ducasse(a)inria.fr] Sent: Thursday, November 03, 2011 4:39 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Simple vs. Easy 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

Re: [Pharo-project] Simple vs. Easy

by Carlo

It's a great talk and I found him to be an engaging speaker. Out of interest, what parts don't you agree with and would it affect how we move Pharo forward? Cheers Carlo On 03 Nov 2011, at 10:21 PM, Jimmie Houchin wrote: 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.

Nov. 3, 2011

Re: [Pharo-project] Simple vs. Easy

by Nicolas Cellier

Great talk. Nicolas 2011/11/3 Jimmie Houchin <jlhouchin(a)gmail.com>: > Hello Stef, > > In the video he distinguishes and defines Simple and Easy. > I will not define them here. I will let the video speak for itself. > > Easy is what a lot of languages are. > Simple is the goal. Â Simple Made Easy is the ultimate. :) > > Simple ~= Easy > Easy ~= Simple > Simple is sometimes Easy > Easy is often not Simple > > Easy and Simple are often used interchangeably when they shouldn't be. It > can be confusing. > The video is an hour. I would encourage anyone to watch it. > The video is not about Clojure a particular language, but is more > philosophical. > > And by the way. I too would love to see Pharo Simple and Easy on your list. > :) > Or at least as Simple as possible. > > Jimmie > > On 11/3/2011 3:39 PM, StÃ©phane Ducasse wrote: >> >> 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

Re: [Pharo-project] Simple vs. Easy

by Jimmie Houchin

Hello Stef, In the video he distinguishes and defines Simple and Easy. I will not define them here. I will let the video speak for itself. Easy is what a lot of languages are. Simple is the goal. Simple Made Easy is the ultimate. :) Simple ~= Easy Easy ~= Simple Simple is sometimes Easy Easy is often not Simple Easy and Simple are often used interchangeably when they shouldn't be. It can be confusing. The video is an hour. I would encourage anyone to watch it. The video is not about Clojure a particular language, but is more philosophical. And by the way. I too would love to see Pharo Simple and Easy on your list. :) Or at least as Simple as possible. Jimmie On 11/3/2011 3:39 PM, StÃ©phane Ducasse wrote: > 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

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