On 18 January 2012 10:29, Serge Stinckwich <[email protected]> wrote: > On Sat, Jan 7, 2012 at 10:28 PM, Frank Shearar <[email protected]> > wrote: >> On 7 January 2012 15:11, Nicolas Cellier >> <[email protected]> wrote: >>> 2012/1/7 Frank Shearar <[email protected]>: >>>> On 7 January 2012 14:14, Nicolas Cellier >>>> <[email protected]> wrote: >>>>> 2012/1/6 Lukas Renggli <[email protected]>: >>>>>> On 6 January 2012 11:20, Peter Hugosson-Miller <[email protected]> >>>>>> wrote: >>>>>>> On 6 jan 2012, at 06:41, "Gerry Weaver" <[email protected]> wrote: >>>>>>> >>>>>>> 2. There appear to be some tool choices in the Pharo image. I would >>>>>>> like to >>>>>>> be able to create a class and it's methods in an editor in one go. I >>>>>>> like >>>>>>> being able to see all of the class code at once. Is there a way to do >>>>>>> this? >>>>>>> I just want to be able to type it all in and accept (evaluate?) all at >>>>>>> once. >>>>>>> >>>>>>> This is an interesting question to me personally. After 15 years of >>>>>>> working >>>>>>> exclusively in Smalltalk I've recently been forced to start programming >>>>>>> in >>>>>>> Java, where the source code is always (as far as I know) arranged in >>>>>>> the way >>>>>>> you describe. >>>>>>> >>>>>>> This organization just emphasizes the dead and compiled nature of Java >>>>>>> (and >>>>>>> similar languages), compared to the living objects of Smalltalk, where >>>>>>> even >>>>>>> methods are objects, created by sending messages to other objects. >>>>>>> Source >>>>>>> code is relegated to being a mere artifact, which can be saved and >>>>>>> organized >>>>>>> in any way one wishes, and preferably never shows its ugly face to the >>>>>>> coder >>>>>>> :-p >>>>>> >>>>>> Which of course is no argument why Smalltalk code could not be >>>>>> displayed in a more programmer friendly way as a continuous block of >>>>>> text. There is no technical reason why source ranges in text box >>>>>> couldn't correspond to life method objects. Compared to other >>>>>> languages it is extremely tedious in Smalltalk to get an overview over >>>>>> a project, a package, or even a single class or to navigate between >>>>>> entities. >>>>>> >>>>>>> And yes, I really *really* miss a good, object oriented class browser! >>>>>> >>>>>> Eclipse is pretty good, especially with the Java Browsing Perspective. >>>>>> >>>>>> Lukas >>>>>> >>>>> >>>>> As soon as you would display the code for many methods in a single text >>>>> pane, >>>>> you will find file-based-educated people making large refactorings in >>>>> a single pass... >>>>> Imagine this leads to many syntax errors, they will soon be willing to >>>>> save their changes for a later rework... >>>>> This would be a complete change in programming flow and if we really >>>>> want to support this, we would have to: >>>>> - add a way to save syntactically incorrect code >>>>> - let IDE tools work on partially correct code (syntax highlighting, >>>>> navigation, etc...) >>>>> >>>>> IMHO, these features add a lot of complexity... Is it really worth? >>>>> I like the discipline of focusing on a single method until it is at >>>>> least syntactically correct. >>>> >>>> The Pharo community has extremely limited resources so it seems quite >>>> fair to me for Pharo to say "yes, but it's up to you because we have >>>> no time". It _is_ very useful to be able to see and edit long reams of >>>> text: my favourite text editor's been beaten on since the late 70s. It >>>> is now very, very good at manipulating text, in multiple programming >>>> languages, in multiple human languages, on many platforms. That I >>>> can't use this text editor to manipulate a textual representation of >>>> my favourite language is extremely annoying! >>>> >>>> frank >>> >>> Yeah, but my take was that re-inventing a very narrow subset of these >>> 40 years old text editors in Smalltalk would likely be a failure... >>> (or a big project) >> >> It would be a fairlly big piece of work although we do have lots of >> pieces lying around: >> * Coral's working on a scripting/REPL-like interface, >> * the Common Lisp community has been using SLIME to provide a REPL to >> a running image for years while also using files to store their code, >> * we have Gitocello (which also translates Squeak/Pharo to gst), >> * we have LanguageBoxes (*) allowing us to permit craziness like >> storing code outside the image in one format without affecting the >> entire language (letting us store Smalltalk code in something other >> than chunk format) >> >> (*) watch this space: I'm making progress on breaking up the Helvetia >> image into a bootstrappable bunch of packages > > Did you commit your code somewhere ?
Not yet: what I have at the moment is a Squeak Installer script to bootstrap a vanilla 4.3 image up to the point where I can start loading Cutie-Helvetia, the first of the LanguageBoxes packages, dependency-wise, together with a few shims necessary to add some Pharo-specific bits to Squeak. Those shims are as yet unpublished, just because I haven't taken the time to put them anywhere. It's still very much in hack form, but you can see what I have so far at https://gist.github.com/1632449. Right now I'm trying to figure out how to load Cutie-Helvetia: it occurred to me late last night that Monticello can't load the non-Smalltalk methods because it's trying to use the image's compiler rather than the class-specific parser. I don't yet have a solution: I need the class-side methods compiled and loaded before I can try compile the instance-side methods, and right now Monticello compiles everything before installing anything. I guess a custom loader's what I need. frank > > Regards, > -- > Serge Stinckwich > UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam > Matsuno Laboratory, Kyoto University, Japan (until 12/2011) > http://www.mechatronics.me.kyoto-u.ac.jp/ > Every DSL ends up being Smalltalk > http://doesnotunderstand.org/ >
