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

Re: [Pharo-project] [update 1.3] #13183

by laurent laffont

hÃ©hÃ©, now DecompilerTests are run and some fail https://pharo-ic.lille.inria.fr/hudson/view/Pharo/job/Pharo%20Core%201.3/la… Laurnt On Thu, May 5, 2011 at 10:26 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > thanks laurent! > > Stef > > On May 5, 2011, at 8:13 PM, laurent laffont wrote: > > > 13183 > > ----- > > > > Issue #4132: > > > > - LongTest are run by default (so they will be run by Hudson) > > - Add a setting in System / Run Long Test to enable / disable them > > - Comment > > > > Laurent > > >

May 5, 2011

Re: [Pharo-project] [update 1.3] #13183

by StÃ©phane Ducasse

thanks laurent! Stef On May 5, 2011, at 8:13 PM, laurent laffont wrote: > 13183 > ----- > > Issue #4132: > > - LongTest are run by default (so they will be run by Hudson) > - Add a setting in System / Run Long Test to enable / disable them > - Comment > > Laurent

May 5, 2011

Re: [Pharo-project] [squeak-dev] Personalized systems with Treated

by Miguel CobÃ¡

El jue, 05-05-2011 a las 14:17 -0500, Chris Muller escribiÃ³: > >> I'm more interested to know the answers to these questions: > >> > >> - How does one deploy an application on Pharo that requires a > >> one-line change to a core system method that is not acceptable to the > >> Pharo gods? > > > > The same tha squeak for changes that aren't accepted/belongs to/are too > > specific to an application. You include them as an *mypackage extension > > in some package of yours and then when the mcz is installed, the > > extension is installed too. That is just monticello as always. > > I'm talking about an override not an extension. Can't see the difference. Your package just have a method that overrides one method in a core system class. Or am I missing something? > > >> - How does one deploy an application on Pharo that loads code from > >> external web-sites? > > > > Using doIts if necessary. > > Right, dropping down into straight load-script and doing it. Got it! :) Yes, because is the last resort. But most scripts are just pulling dependencies, not resources so if you advocate the scripts just for the fraction of special uses instead of a reified tool, that is a personal decision not really an argument. > > >> - How does one deploy an application on Pharo that requires external > >> graphics, videos, XML or other resources? > > > > Idem. > > Often specific _versions_ of resources go with each specific version > of an application. Now I am maintaining those separately, in separate > places using separate tools. You can have as many doits as you want (they are methods) and each version loaded by the configuration can invoke a given doit to load specific version of your resources. > > I want something to expand the metaphor of an object being > "encapsulated behavior + state" into my deployment system, so it will > be "encapsulated behaviors + resources". Thankfully, even Pharo 1.3 > still supports .SAR files, but no nice GUI to load them, just the > file-manager. :( > > >> - How does one deploy an application on Pharo that requires an > >> object-graph to be loaded internally into the image that was pre-built > >> using another tool (e.g., NOT generated via code)? > > > > Don't understand the example > > A better example. What if I just want something that strips my image > down of lots of code and objects, without leaving any new code loaded? > > It's a rhetorical question, I already know the answer: Create a > Metacello config to host only a load-script (doIt). But I wonder > whether said doIt would be able to "unload itself" when it was done? > Probably could. This is a very specific scenario that most surely is not needed by the 90% of users that metacello is aiming to be useful to. The 10% that need some very restricted loading scenario can have a script that does everything that need. > > > I think it does those things, maybe a second look at the existings > > configurations can clear a lot of doubts. > > The picture seems to be, as long as my app is all just "clean-loading > MC packages", then I can use Metacello within its normal bounds. (OR, > I could just use the standard "lighter-weight" SCM tools; Monticello + > MonticelloConfigurations + Gofer). Yes, but for most maintainers that "clean-loading MC packages" is what we need. For example magma. Is a complex project and even so it doesn't use any of the spoken features so metacello is good enought to load it in Pharo. This argument about scripts vs metacello is like saying that just because you can do the same with assembler when iterating over a list of string you don't need a OrderedCollection. yes you can do the same, but the advantages are greater when working with full objects that with plain text. > > However, if an application requires anything additional: overrides, > resources or special-configurations, then I drop down to the "ultimate > flexbility" afforded by doIt's - which is just load-scripting. Even > then, the resources are not encapsulated as I already said. > > SqueakMap is a repository that hosts load-scripts encasulated with or > without resources. It's perfectly complimentary to all of the other > tools. > > I'm exhausted of talking about this.. Ok, then lets rest it now. Regards -- Miguel CobÃ¡ http://twitter.com/MiguelCobaMtz http://miguel.leugim.com.mx

May 5, 2011

Re: [Pharo-project] Preferred way of removing slice from Inbox

by StÃ©phane Ducasse

On May 5, 2011, at 9:00 PM, laurent laffont wrote: > Hi, > > Once a SLICE is integrated in PharoCore, how do you remove it from PharoInbox ? via boring click click click squeaksource interface :( > > Laurent

May 5, 2011

Re: [Pharo-project] Popularity of Smalltalk in Software Industry

by StÃ©phane Ducasse

Thanks Jimmie Thanks to kick our asses like that! I would love to have that too in Pharo. Stef > Thanks, > > I have no knowledge of either the knowledge or the challenges involved in using external libraries in Pharo or Squeak. I have no knowledge of FFI/Alien or using C/C++/C# or compilers. > > However, this is my experience in Python. > > Navigate to the directory containing the script makepy.py or if it is a part of your Python's sys.path, execute the script. It generates a Python module which is on > > It pops up a dialogue which prompts you to select the library you wish to interface. > > Then to use in a script simply > import Dispatch > self.mylib = Dispatch("MyLibrary") > > This will expose all the functionality of the library. > > All provided by the python win32 extensions. It was very successful for my needs. I do not know what limitations it may or may not have. > > Very easy for non-expert programmers. I would love this level of ability to interface outside libraries in Squeak. But I have no idea the effort required to automate the generation of a class or classes which interface the external library. > > In my particular instance this is obviously for a Windows library. I don't know if Python has anything comparable for Linux or OSX. > > In this particular instance, Python was enabling for me, for which I am grateful. Otherwise I might be stuck writing my app in VisualBasic. But despite my gratefulness, I spend as little time in Python as possible. Despite Python not requiring a compiler, I really hate going to an editor and writing code. Then to an interpreter to run code. Hit my stacktrace. Go back to the editor. Reload the module in the interpreter and run again, and if that doesn't succeed due to the reload not really reloading the new code, open in a new interpreter. Ugh!!! Where's my Smalltalk. Give my live object system. :) > > Jimmie > >

May 5, 2011

Re: [Pharo-project] Popularity of Smalltalk in Software Industry

by Jimmie Houchin

On 5/5/2011 12:21 PM, Igor Stasenko wrote: > On 5 May 2011 18:57, Jimmie Houchin<jlhouchin(a)gmail.com> wrote: [Big Snip] > Well said. > Except that i'm not sharing your view that its hard to interface with > foreign libraries. > Its not hard at all. Of course to connect two different worlds, you > need to have knowledge > in both of them. But this requirement not a bit different when you > take any other pair of languages and try to > connect them. Thanks, I have no knowledge of either the knowledge or the challenges involved in using external libraries in Pharo or Squeak. I have no knowledge of FFI/Alien or using C/C++/C# or compilers. However, this is my experience in Python. Navigate to the directory containing the script makepy.py or if it is a part of your Python's sys.path, execute the script. It generates a Python module which is on It pops up a dialogue which prompts you to select the library you wish to interface. Then to use in a script simply import Dispatch self.mylib = Dispatch("MyLibrary") This will expose all the functionality of the library. All provided by the python win32 extensions. It was very successful for my needs. I do not know what limitations it may or may not have. Very easy for non-expert programmers. I would love this level of ability to interface outside libraries in Squeak. But I have no idea the effort required to automate the generation of a class or classes which interface the external library. In my particular instance this is obviously for a Windows library. I don't know if Python has anything comparable for Linux or OSX. In this particular instance, Python was enabling for me, for which I am grateful. Otherwise I might be stuck writing my app in VisualBasic. But despite my gratefulness, I spend as little time in Python as possible. Despite Python not requiring a compiler, I really hate going to an editor and writing code. Then to an interpreter to run code. Hit my stacktrace. Go back to the editor. Reload the module in the interpreter and run again, and if that doesn't succeed due to the reload not really reloading the new code, open in a new interpreter. Ugh!!! Where's my Smalltalk. Give my live object system. :) Jimmie

May 5, 2011

Re: [Pharo-project] Popularity of Smalltalk in Software Industry

by Casimiro de Almeida Barreto

Good evening Roy. One thing that always amazes me a lot is that so many experienced solution providers (ie. people who develop solutions either to be sold as OTSCS or embedded as a more or less autonomous part of a bigger system) mind about if something is "mainstream" or something else. For several reasons extensively discussed in this forum, smalltalk didn't "hit the market" like java did. It has nothing to do regarding to smalltalk qualities or lack of them. It has to do with good marketing vs. bad marketing, shorter learning curve for things like java and the fact that java was more apt to be used in personal computers of the 1990ies. Besides that, large part of smalltalk community at that time had the "king inside their bellies" and that just made the technology less attractive to outsiders (look: 1990ies language wars). Smalltalk is a really nice technology supporting fast development of complex (and performative) solutions and demanding much smaller teams to do so. It has evident advantages in the fields of code testing, profiling, maintenance and reuse. Most common families of smalltalk like pharo/squeak/Cincom VW/ are cross platform (Windows, Linux, OS X, iOS). Important families of smalltalk are open source (pharo, squeak, gnu smalltalk and dedicated derivatives like OpenCobalt). Smalltak is far from dead. If you investigate you'll see that pharo (for instance) is supported by important universities (listed among 100 best universities in world). In recent years we have witnessed amazing things in smalltalk world. For reasons that can be summarized as immature product adoption in the 1990ies and ugly commercial practices by suppliers, smalltalk is not as popular as java or python. IMHO time will correct this situation. Now, if you want to deploy solutions you have no reason to fear smalltalk except by the fact that it's highly addictive: you start producing and do it fast and clean and just don't want to stop... but, like any d-dealer would say: "don't trust me, you just have to try it... just once... and look: first time is for free !!!" Ok, enough kidding: if you want to deploy solutions you'll see that for the same investment (time & material resources) you do more with smalltalk. You'll loose much less time debugging things, documenting things, figuring out what other people did before... you'll spend much less money in debuggers, profilers, testers, etc... You'll see that reusing and integrating things is just pleasant. And you'll be amazed by performance. That are my 2Â¢ CdAB

May 5, 2011

Re: [Pharo-project] [squeak-dev] Personalized systems with Treated

by Chris Muller

>> I'm more interested to know the answers to these questions: >> >> Â - How does one deploy an application on Pharo that requires a >> one-line change to a core system method that is not acceptable to the >> Pharo gods? > > The same tha squeak for changes that aren't accepted/belongs to/are too > specific to an application. You include them as an *mypackage extension > in some package of yours and then when the mcz is installed, the > extension is installed too. That is just monticello as always. I'm talking about an override not an extension. >> Â - How does one deploy an application on Pharo that loads code from >> external web-sites? > > Using doIts if necessary. Right, dropping down into straight load-script and doing it. Got it! :) >> Â - How does one deploy an application on Pharo that requires external >> graphics, videos, XML or other resources? > > Idem. Often specific _versions_ of resources go with each specific version of an application. Now I am maintaining those separately, in separate places using separate tools. I want something to expand the metaphor of an object being "encapsulated behavior + state" into my deployment system, so it will be "encapsulated behaviors + resources". Thankfully, even Pharo 1.3 still supports .SAR files, but no nice GUI to load them, just the file-manager. :( >> Â - How does one deploy an application on Pharo that requires an >> object-graph to be loaded internally into the image that was pre-built >> using another tool (e.g., NOT generated via code)? > > Don't understand the example A better example. What if I just want something that strips my image down of lots of code and objects, without leaving any new code loaded? It's a rhetorical question, I already know the answer: Create a Metacello config to host only a load-script (doIt). But I wonder whether said doIt would be able to "unload itself" when it was done? Probably could. > I think it does those things, maybe a second look at the existings > configurations can clear a lot of doubts. The picture seems to be, as long as my app is all just "clean-loading MC packages", then I can use Metacello within its normal bounds. (OR, I could just use the standard "lighter-weight" SCM tools; Monticello + MonticelloConfigurations + Gofer). However, if an application requires anything additional: overrides, resources or special-configurations, then I drop down to the "ultimate flexbility" afforded by doIt's - which is just load-scripting. Even then, the resources are not encapsulated as I already said. SqueakMap is a repository that hosts load-scripts encasulated with or without resources. It's perfectly complimentary to all of the other tools. I'm exhausted of talking about this.. Regards, Chris

May 5, 2011

[Pharo-project] Preferred way of removing slice from Inbox

by laurent laffont

Hi, Once a SLICE is integrated in PharoCore, how do you remove it from PharoInbox ? Laurent

May 5, 2011

Re: [Pharo-project] Popularity of Smalltalk in Software Industry

by Toon Verwaest

> Yes, but it affects the way how you design your applications and frameworks. > In image-based setup you tend to do things in a way, that things > should be always available > at any moment (wanna create an instance of me? - feel free to do it). > > In C and other languages which having compile& run cycle it is > totally different. > Things are available for you not instantly, but only after you restart > everything from scratch, > reinitialize everything and then repeat exactly same steps to meet the > same point as before. > This is often tedious, time consuming and frustrating. > > And this difference in approaches leads to fatal flaws in design, like > on Windows OS, which requires you to reboot machine every time you > install new driver(s) Ok, I do agree on that. It's probably not an intrinsic flaw of the system, it just makes you think differently. However, suppose that C would have a REPL which gives you an inspector... then you'd already be more inclined to build systems like Smalltalk has. I don't say Smalltalk and its philosophy isn't great, I'm just saying that the image isn't a requirement. I'm sure that if someone would build a more flexible version of C that people would get used to it and want nothing else... even expect it. But whatever :)

May 5, 2011