January 2012 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Now you can use Fuel with FileSystem

by StÃ©phane Ducasse

Mariano should not we get some fixes for FS? Stef On Jan 7, 2012, at 11:25 PM, Mariano Martinez Peck wrote: > Hi guys. Now you can use FileSystem streams for Fuel. Fuel only needs one small package 'FuelFileSystem' which has just 3 extension methods, and that's all ;) > There is also 'FuelFileSystemTests' which let's you run all fuel tests using FS. If you want to do that, change FLSerializationTest >> setUp to send #useFileSystemFileStream rather than #useStandardFileStream and that's all. > To install: > > Gofer new > squeaksource: 'MetacelloRepository'; > package: 'ConfigurationOfFuel'; > load. > > (ConfigurationOfFuel project version: #bleedingEdge) load: 'withFS'. > > An example: > > | sourceArray loadedArray serializer stream materializer | > sourceArray := > Array > with: 'a string' > with: Transcript > with: [ Transcript show: 'a string' ]. > "Create a file and serialize on it" > stream := (FSLocator imageDirectory / 'example.fuel') writeStream. > serializer := FLSerializer newDefault. > serializer serialize: sourceArray on: stream. > stream close. > "Load from the file" > stream := (FSLocator imageDirectory / 'example.fuel') readStream. > materializer := FLMaterializer newDefault. > loadedArray := (materializer materializeFrom: stream) root. > > Cheers > > -- > Mariano > http://marianopeck.wordpress.com >

Jan. 8, 2012

Re: [Pharo-project] An ideal to strive for

by StÃ©phane Ducasse

And you know the one we want :). > I love this Tony Hoare quote: > "There are two ways of constructing a software design: > One way is to make it so simple that there are obviously no deficiencies > and the other is to make it so complicated that there are no obvious > deficiencies." > > -- > View this message in context: http://forum.world.st/An-ideal-to-strive-for-tp4274780p4274780.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

Jan. 8, 2012

Re: [Pharo-project] Misc. newbie questions

by StÃ©phane Ducasse

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.shearar(a)gmail.com> >> To: Pharo-project(a)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.nice(a)gmail.com> wrote: >>> 2012/1/7 Frank Shearar <frank.shearar(a)gmail.com>: >>>> On 7 January 2012 14:14, Nicolas Cellier >>>> <nicolas.cellier.aka.nice(a)gmail.com> wrote: >>>>> 2012/1/6 Lukas Renggli <renggli(a)gmail.com>: >>>>>> On 6 January 2012 11:20, Peter Hugosson-Miller <oldmanlink(a)gmail.com> wrote: >>>>>>> On 6 jan 2012, at 06:41, "Gerry Weaver" <gerryw(a)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 >>>>>> >>>>> >>>> >>> > > > >

Jan. 8, 2012

Re: [Pharo-project] [update 1.4] #14279

by StÃ©phane Ducasse

for each bug we assess whether it is important or not for the previous version and if this is the case we batch some changes for the previous version. Now this is a lot of work and really few people help or seem concerned so we do as much as we can and it makes sense. Now I guess that this is always the case: people have to decide. Then integrating a fix for a bug that has not been discovered after 10 months does not imply anything on the stability of the system. Pharo 1.3 is stable, as 1.2 was and as 1.4 is. Stef > StÃ©phane Ducasse wrote: >> 14279 >> ----- >> >> - Issue 5157: Finder > Class > right-click > Hierarchy opens not on Class but on FinderClassNode. Tx Benjamin van Ryseghem. >> http://code.google.com/p/pharo/issues/detail?id=5157 >> >> > This was reported by me on Pharo-1.3-13315 yesterday and closed overnight, so I'm impressed with the response time. Now while this is hardly a critical issue I'm curious... now that it issue is marked closed, what is the plan to track these small fixes and roll them into a Pharo-1.3.1? Once you get the business support model up and running I would imagine this task falls to the paid engineers. (Release management is not exciting.) From a business perspective I would think that this is (almost) MORE important than the good refactoring work your doing to come out in a future version. > > There is a rule I've commonly seen in business to never use anything that is x.x.0. Wait for the "first service release" is the mantra. Seeing the versions go only from 1.3.0 to 1.4.0 to 1.5.0 does not instill business confidence in the stability of the platform. Maybe you are willing to sacrifice that image at this early stage to move faster with limited resources, but just something to consider. > > keep up the good work, > cheers, Ben >

Jan. 8, 2012

Re: [Pharo-project] Misc. newbie questions

by Frank Shearar

2012/1/8 GÃ¶ran Krampe <goran(a)krampe.se>: > On 01/08/2012 02: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 stdout. Maybe it could also >> understand some commands like doit and accept. 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. http://lists.gforge.inria.fr/mailman/listinfo/pharo-coral <-- not TCP-based, but it should be trivial to extend it to use a socket instead of stdin/out > The answer is that it is basically trivial to do and many people have > already done it in various forms - I even did a TCP server for Joe Armstrong > (one of the creators of Erlang) that does similar things: > > http://www.squeaksource.com/JoesServer.html > > ...BUT... when it comes to Joe he wanted to use Squeak from Erlang in order > to dynamically create UIs etc. So he had a reasonable use case. ;) > > ...if you just happe to "like REPLs" then you should really try to use and > learn the Squeak/Pharo IDE. Think of it as a full blown live graphic REPL > with tons of cool tools. Every text area in Pharo/Squeak is a "REPL" anyway. You should definitely learn to use the Squeak/Pharo IDE, even apart from the fact that it's the least rubbish way of writing code. The Workspace is, fair enough, a bit like a REPL. Well, no, it IS a REPL. It's just a REPL that requires you to use a GUI. The complicated part of a Smalltalk REPL is Smalltalk's syntax: it's designed to work at the method level, where some code-holding widget's entire contents holds a single method. This is why Coral and GNU Smalltalk alter the core syntax a bit, to allow marking the start and end of a method. For instance, gst has something like Foo extend [ bar [ ^ 'return!' ] ] to add a method #bar to an existing class Foo. (Or: Smalltalk syntax has no "this is the end of a method" marker, beyond the _optional_ ^ statement.) frank > > regards, GÃ¶ran >

Jan. 8, 2012

[Pharo-project] Best way for FFI in Pharo

by Udo Schneider

All, what's the best way (at the moment & in the future) to call external libraries from Pharo. I'm a bit confused at the moment will all the stuff going around FFI, NativeBoost ... Is there maybe an abstraction layer above all those native-call mechanisms somewhere? Best Regards, Udo

Jan. 8, 2012

Re: [Pharo-project] Bug in #pointsTo: ?

by Mariano Martinez Peck

> > Of course, but I'd check for the class equality first, because it's faster > (yeah, i know you turned off inlining of #class, but Cog doesn't care about > that ;)). Are you sure Cog doesn't care? I think it does. From what I can see in Cog code the entry point to inline #class is from the bytecoodes. If you see initializeBytecodeTableForClosureV3 ... #(1 199 199 genSpecialSelectorClass needsFrameNever: notMapped 0). "not mapped because it is directly inlined (for now)" ... so if you use a the normal bytecode for #class then I think #class is not inlined in machine code. At least from my tests I noticed that. Cheers > Another thing that you should add (besides tests of course) is > SmallInteger >> #pointsTo: which should return false. Also make sure that > pointer tracing tools use #pointsTo:. In Squeak I found that some of them > "reinvented" this method... > > > Levente > > > >> cheers >> >> -- >> Mariano >> http://marianopeck.wordpress.**com <http://marianopeck.wordpress.com> >> >> -- Mariano http://marianopeck.wordpress.com

Jan. 8, 2012

Re: [Pharo-project] Misc. newbie questions

by GÃ¶ran Krampe

On 01/08/2012 02: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 stdout. Maybe it could also understand some commands like doit and accept. 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. The answer is that it is basically trivial to do and many people have already done it in various forms - I even did a TCP server for Joe Armstrong (one of the creators of Erlang) that does similar things: http://www.squeaksource.com/JoesServer.html ...BUT... when it comes to Joe he wanted to use Squeak from Erlang in order to dynamically create UIs etc. So he had a reasonable use case. ;) ...if you just happe to "like REPLs" then you should really try to use and learn the Squeak/Pharo IDE. Think of it as a full blown live graphic REPL with tons of cool tools. Every text area in Pharo/Squeak is a "REPL" anyway. regards, GÃ¶ran

Jan. 8, 2012

Re: [Pharo-project] Now you can use Fuel with FileSystem

by Guido Stepken

Hi Mariano! Love it, great work! Love objects StOMPing, rSTing, Fueling around between images at runtime. Do you have examples how to realize realtime mirroring (HA) with it? tnx in advance, Guido Stepken Am 07.01.2012 23:25 schrieb "Mariano Martinez Peck" <marianopeck(a)gmail.com >: > Hi guys. Now you can use FileSystem streams for Fuel. Fuel only needs one > small package 'FuelFileSystem' which has just 3 extension methods, and > that's all ;) > There is also 'FuelFileSystemTests' which let's you run all fuel tests > using FS. If you want to do that, change FLSerializationTest >> setUp to > send #useFileSystemFileStream rather than #useStandardFileStream and > that's all. > To install: > > Gofer new > squeaksource: 'MetacelloRepository'; > package: 'ConfigurationOfFuel'; > load. > > (ConfigurationOfFuel project version: #bleedingEdge) load: 'withFS'. > > An example: > > | sourceArray loadedArray serializer stream materializer | > sourceArray := > Array > with: 'a string' > with: Transcript > with: [ Transcript show: 'a string' ]. > "Create a file and serialize on it" > stream := (FSLocator imageDirectory / 'example.fuel') writeStream. > serializer := FLSerializer newDefault. > serializer serialize: sourceArray on: stream. > stream close. > "Load from the file" > stream := (FSLocator imageDirectory / 'example.fuel') readStream. > materializer := FLMaterializer newDefault. > loadedArray := (materializer materializeFrom: stream) root. > > Cheers > > -- > Mariano > http://marianopeck.wordpress.com > >

Jan. 8, 2012

[Pharo-project] Quantities and Units

by Ben Coman

I am implementing a model defined with quantity data having {value, multiplier, unit} where multiplier is m, c, k, M, etc unit is V, A, Hz, W, etc So I am looking for what quantities/units packages are around before trying to write my own. I have downloaded [1] and had a poke around there with the tests. Are there any further examples around of how to use it and to define new units? I notice that Voltage=Joules/Columb is not defined. Is anyone have any familiar with ports of packages mentioned here [2] [3] [4] from other platforms? cheers, Ben [1] http://www.squeaksource.com/Units.html [2] http://www.cincomsmalltalk.com/publicRepository/Quantities.html [3] http://www.smalltalking.net/goodies/Dolphin/ (scroll to bottom) [4] http://comments.gmane.org/gmane.comp.lang.smalltalk.squeak.general/55894

Jan. 8, 2012