On Jan 8, 2012, at 2:05 AM, Gerry Weaver wrote: > Hello All, > > Thank you for all of your responses. They are really helping me get a better > picture of Pharo, the environment, and the community. > > > I really like the idea of a REPL type interface. If I understand correctly, > all of the functionality that deals with class/method definition is already > there. It seems like it would be a matter of writing a little server type > application that would communicate via stdin/stdout. I assume one could then > send messages to the code that evaluates methods/function definitions and > provide result feedback via stout.
Yes :) With the MTvm you can already do that: talk to the vm via a console :). > Maybe it could also understand some commands like doit and accept. Yes. A doit is somehow no more than Compiler evaluate: asString > It could be interesting to have a TCP based interface as well. How difficult > would it be to do something like this? > I may start looking into this. It seems like a good project to jump into the > deep end, start paddling, and drinking a little water (hopefully not too > much). Is the code that handles this kind of thing readily accessible? I've > started looking around a bit. > > > Thanks, > Gerry > > > -----Original Message----- >> From: "Frank Shearar" <frank.shea...@gmail.com> >> To: Pharo-project@lists.gforge.inria.fr >> Date: 01/07/12 09:28 >> Subject: Re: [Pharo-project] Misc. newbie questions >> >> 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 >> >>> There is also this recent related post which touch this subject: >>> >>> http://railsrx.com/2011/12/29/getting-back-to-smalltalk/ >> >> Amusingly, I only just finished reading that in my newsreader. I think >> _personally_ that I need to port TWM to Squeak because I'm tired of >> being the window manager, and hopefully that would solve my other >> pain, which Noel points out - the ability to see multiple methods at a >> time is _really useful_. >> >> (Trivial example: think of how clear code in ML or Haskell looks when >> pattern matching on type, versus having five browsers open on various >> subclasses' implementations of #foo.) >> >> I guess I'm saying: the rest of the world isn't automatically wrong >> because they're not using Smalltalk, and I want to bring the best >> parts of the non-Smalltalk stuff to Smalltalk (like having the >> _option_ of using my favourite version control system, text editor, >> IDE, etc.) >> >> frank >> >>> Nicolas >>> >>>> >>>>> On the other hand, in Smalltalk we have to transfer the complexity of >>>>> multi-method changes in the refactoring engines/menus when some simple >>>>> modify/replace in a file would work. >>>>> >>>>> Nicolas >>>>> >>>>>> -- >>>>>> Lukas Renggli >>>>>> www.lukas-renggli.ch >>>>>> >>>>> >>>> >>> > > > >
