On 18 January 2012 11:07, Frank Shearar <frank.shea...@gmail.com> wrote: > On 18 January 2012 10:29, Serge Stinckwich <serge.stinckw...@gmail.com> wrote: >> On Sat, Jan 7, 2012 at 10:28 PM, Frank Shearar <frank.shea...@gmail.com> >> wrote: >>> On 7 January 2012 15:11, Nicolas Cellier >>> <nicolas.cellier.aka.n...@gmail.com> wrote: >>>> 2012/1/7 Frank Shearar <frank.shea...@gmail.com>: >>>>> On 7 January 2012 14:14, Nicolas Cellier >>>>> <nicolas.cellier.aka.n...@gmail.com> wrote: >>>>>> 2012/1/6 Lukas Renggli <reng...@gmail.com>: >>>>>>> On 6 January 2012 11:20, Peter Hugosson-Miller <oldmanl...@gmail.com> >>>>>>> wrote: >>>>>>>> On 6 jan 2012, at 06:41, "Gerry Weaver" <ger...@compvia.com> 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.
Update: I've made a dumping ground for all my interim work - http://ss3.gemstone.com/ss/Scratchpad-fbs - which _should_ be exhaustive. I have yet to solve the loading problem I mentioned, though. > 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/ >>
