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

[Pharo-project] "Error: No content to install" starting Pharo 1.2 on Windows - bug or feature?

by Joachim Geidel

I ran into an error when starting a Pharo 1.2RC2 (build 119) image on Windows XP. What I did was: - on Mac OS X, create a new directory "Pharo-1.2-build119" - copy the image, changes file, and sources file from the one-click app to this directory - started the image, saved it as "jniport20.image", and worked a bit with it - started Windows XP under Parallels, opened an explorer on Pharo-1.2-build119 - placed a link to squeak.exe in the directory which points to Y:\Entwicklung\Pharo\PharoOneClick1.2.app\Contents\Windows\Squeak.exe and has Y:\Entwicklung\Pharo\Pharo-1.2-build119 as the working directory - dropped jniport20.image on the link. The image starts okay, but immediately opens an error notifier with an "Error: No content to install" in CodeLoader>>installSourceFile:. The CodeLoader's sourceFiles instvar hold an Array(a HTTPDownloadRequest), where the HTTPDownloadRequest has 'Y:\Entwicklung\Pharo\Pharo-1.2-build119\PharoOneClick1.2.image' as its URL. I have seen issue 3595 "problem starting up with a script on windows" which has been closed, apparently because it was not considered a bug. However, that seems to be something different involving startup scripts. What am I doing wrong? Or is it a bug? Regards, Joachim Geidel -- View this message in context: http://forum.world.st/Error-No-content-to-install-starting-Pharo-1-2-on-Win… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Feb. 5, 2011

Re: [Pharo-project] Comparing collections, default behavior?

by Noury Bouraqadi

On 4 fÃ©vr. 2011, at 17:06, Igor Stasenko wrote: > Since Collection includes #difference: protocol, > > i just thought that the default equality could be expressed like following: > > Collection>>= otherCollection > ^ (self difference: otherCollection) isEmpty > > In other words, if two things having no differences, then they are equal. No? :) > Need to check the species too. I believe an array is different from a set even if they contain the same elements. Noury

Feb. 5, 2011

Re: [Pharo-project] [ANN] Alien on Pharo 1.2

by Luc Fabresse

2011/2/5 Joachim Geidel <joachim.geidel(a)onlinehome.de> > > > Luc Fabresse wrote: > > > > I just committed new versions of Alien on squeaksource to make it run on > > 1.2 > > I also modified the ConfigurationOfAlien to easily load it: > > > > Unfortunately, your new version of Alien-LibC is broken. It only works in > Pharo, not in Squeak. Squeak does not include the methods > isMacOS/isUnix/isWindows which are now used in LibCLibrary>>libraryName. > You > should use "Smalltalk os platformName = ..." instead, which is portable > between Pharo and Squeak. > > Does ConfigurationOfAlien work in Squeak 4.1 and 4.2? > Arg you are probably right! To make it work fast, you can modify the ConfigurationOfAlien to introduce squeak versions and fix it to load the previous version of LibC? spec for: #squeak do: [ ... ] Soon, I will try to provide an updated cross-plateform version of LibC. #Luc > > Regards, > Joachim Geidel > > -- > View this message in context: > http://forum.world.st/ANN-Alien-on-Pharo-1-2-tp3247073p3261616.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > >

Feb. 5, 2011

Re: [Pharo-project] [ANN] Alien on Pharo 1.2

by Joachim Geidel

Luc Fabresse wrote: > > I just committed new versions of Alien on squeaksource to make it run on > 1.2 > I also modified the ConfigurationOfAlien to easily load it: > Unfortunately, your new version of Alien-LibC is broken. It only works in Pharo, not in Squeak. Squeak does not include the methods isMacOS/isUnix/isWindows which are now used in LibCLibrary>>libraryName. You should use "Smalltalk os platformName = ..." instead, which is portable between Pharo and Squeak. Does ConfigurationOfAlien work in Squeak 4.1 and 4.2? Regards, Joachim Geidel -- View this message in context: http://forum.world.st/ANN-Alien-on-Pharo-1-2-tp3247073p3261616.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Feb. 5, 2011

Re: [Pharo-project] Network training

by StÃ©phane Ducasse

luc and levente @luc: you are a newbie with 6 years or more of smalltalk so a kind a strange one. I understand the points of levente - if the plugin code would be nice (documented, cleaned) and if we would have build server to recompile everything without warning every line then this is probably true that recompiling the plugin is easier for a new platform. This is a valid argument. - now I understand luc, noury, igor idea. Minimize truck factor. Now the key point is to see if threaded FFI is there, working and maintainable. So levente no need to bash them. I think that this is an interesting experience and I want more: - I want a new api and design of network that can work on the plugin or not - I want a VM that compile every times we commit a change to pharo - I want plugin code and VM to be be cleaned: using abstraction instead of bitAnd: everywhere and no warning. This is the only way that in 5 years from now (when eliot will be turned into a Javascript Virtual machine guru and andreas gone to android business or whatever and ), the community can continue to have good tools and I HATE to think that in 5 years I should think: "SHIT the code rot during all that time and if only we would have invested in cleaning and maintaining it". So let us do it NOW! When do we start to think about process, tools and artefacts that will survive us. Stef

Feb. 5, 2011

Re: [Pharo-project] [COTDC] MCFileRepositoryInspector

by StÃ©phane Ducasse

magic power of reuse :) Indeed puzzling but just reusing super behavior: good exercise for refactoring. > On Fri, Feb 4, 2011 at 9:01 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Ok after some investigations.... > > I'm a monticello tool composed of three panes to browse repositories and the packages they contain. You get an instance > of me when you click on a repository and press open. My left pane presents the packages, my right one their versions and the > bottom one the commit log of the selected package versions. > > > Indeed I don't understand why MCFileRepositoryInspector is a subclass of MCVersionInspector. MCVersionInspector is a tool to work on one version of a package, while MCFileRepositoryInspector is a browser of all packages and repositories. > > Seems to me that MCFileRepositoryInspector should be a subclass of MCTool directly. > > Laurent > > > > Stef > > > On Feb 4, 2011, at 7:57 PM, laurent laffont wrote: > > > ** 1st Comment Of The Day Contest - One Day One Comment ** > > Rules: Each day a not commented class is elected. Each day the best comment will be integrated with name of the author(s). > > > > The first round is for: MCFileRepositoryInspector > > > > GO GO !! > > > > Laurent Laffont - @lolgzs > > > > Pharo Smalltalk Screencasts: http://www.pharocasts.com/ > > Blog: http://magaloma.blogspot.com/ > > >

Feb. 5, 2011

[Pharo-project] [Enh] Simple equality

by Noury Bouraqadi

Hi, Each time I have to explain to my students that to when overriding = they should override hash, I find it awkward. Now I got the idea to ease this process and avoid having to implement = and hash in simple cases. To make instances of some class comparable, simply make the class use one trait (TEquality). For most other cases, simply one method need to be overridden (valuesToCompareForEquality). I put the code (with tests) on the issue tracker http://code.google.com/p/pharo/issues/detail?id=3657 Note that for the default implementation of hash, I reused the code from SequenceableCollection. Feedback is as usual welcome :-) Noury

Feb. 5, 2011

Re: [Pharo-project] Which ConfigurationOfPharo should use in Pharo 1.2 ?

by Sven Van Caekenberghe

On 05 Feb 2011, at 08:31, Marcus Denker wrote: > I attach the complete script used for building 1.2 as the builder.sh stiches it together: > > > <Pharo-1.2.st> It would be really cool if this were an artifact as well, so that those interested in certain builds can see exactly how they were produced. Sven PS: the things you are doing with the CI server are really coola ans useful.

Feb. 5, 2011

[Pharo-project] Issue 3657 in pharo: [Enh] Simple EqualityTest

by pharo＠googlecode.com

Status: New Owner: ---- New issue 3657 by bouraq...(a)gmail.com: [Enh] Simple EqualityTest http://code.google.com/p/pharo/issues/detail?id=3657 Simple solution to ease implementing = and hash. To make instances of some class comparable, simply make the class use the TEquality trait. TEquality relies on message valuesToCompareForEquality sent to objects for both = and hash. The default implmentation of this message is provided by Object. Override ONLY valuesToCompareForEquality method for custom equality check. Paste or attach stack trace if applicable (look at the file PharoDebug.log located in the same directory as your image): Attachments: Equals-NouryBouraqadi.1.mcz 3.3 KB

Feb. 5, 2011

Re: [Pharo-project] Network training

by Luc Fabresse

2011/2/5 Levente Uzonyi <leves(a)elte.hu> > On Sat, 5 Feb 2011, Igor Stasenko wrote: > > On 5 February 2011 00:53, Levente Uzonyi <leves(a)elte.hu> wrote: >> >>> On Sat, 5 Feb 2011, Igor Stasenko wrote: >>> >>> On 5 February 2011 00:12, Levente Uzonyi <leves(a)elte.hu> wrote: >>>> >>>>> >>>>> On Fri, 4 Feb 2011, Luc Fabresse wrote: >>>>> >>>>> Yes, but hopefully we will be SocketPlugin free. >>>>>> >>>>> >>>>> Is SocketPlugin buggy? >>>>> If yes, where's the bug report? >>>>> If not, what's the problem with it? >>>>> >>>>> Just one: it is highly resistant to evolution and changes. As well as >>>> everything else in VM. >>>> >>> >>> Does the Socket API change often? No. I'm sure all my 10 years old >>> network >>> code (written in C) would compile and run on the first try. >>> >>> >> I can tell you more: >> Does C syntax changes often? No. So, then why there so many silly >> people wasting their time writing own compilers for it? >> Or why people inventing new languages? Isn't C enough? :) >> > > Why do you compare APIs wrapping the OS's socket API to programming > languages? I don't see how is the two similar at all. > > > >> Levente, when is the last time you checked the meaning of word >> 'development' in dictionary? >> > > I can tell you what's not developement: Throwing away working solutions > without a reason, then writing something similar. That's reinventing the > wheel + optional NIH syndrome. > > > >> >>>> At the end, "There can be only one" (FFI or Alien or NB or a better >>>>>> one) >>>>>> ;-) >>>>>> IMHO, plugins are a pain to understand, maintain, integrate in the >>>>>> latest >>>>>> VM... >>>>>> so let's kill them as much as possible. >>>>>> >>>>> >>>>> Maintaining SocketPlugin (or reimplementing for a new plaform) is a lot >>>>> easier than doing the same with FFI or Alien. >>>>> >>>> >>>> I wouldn't say so. >>>> >>> >>> Why? >>> >>> >> Because coding in smalltalk much easier than in C. >> Including cases, when you need to communicate with external library using >> C ABI. >> >> Otherwise, why would i be sitting here? And why VM written in >> smalltalk?.. For same reason, bro :) >> > > That's not an anwser to my question, but I see your point. > > > >> Couldn't you reimplement SocketPlugin from scratch without looking at the >>> current implementation in at most a few days? I could, so I'm sure you >>> could >>> do that too. The same is not true for FFI or Alien (at least not for me). >>> >>> >> So you have something to learn left in this world :) >> > > Lol... > > > >> >>>> Eliot's threaded FFI plugin is >>>>> very complex compared to (the pretty simple) SocketPlugin. >>>>> >>>>> >>>>> It could be simple too. But just not fast enough :) >>>> There's always a lot of tradeoffs to consider. >>>> >>> >>> It could be, but it's not. >>> >>> >> You will never know if you don't try. >> > > I'm talking about Eliot's FFI implementation, while you're talking about > something else. > > > >> And besides, what is your point? >> People learning network by implementing own network layer. Exploring >> something new and trying to adopt design >> to their own vision/mindset. >> > > There's nothing wrong with that, until they don't start saying that the > plugin sucks without telling what's the problem with it. Hi Levente, Why I am doing Ocean with Noury is: 1) Network never worked fine for me (NetNameResolver ,...). The API (Image side) is not OO (All concerns in Socket: IPV4, IPV6, TCD, UDP, ...). We first try to write unit tests and then we planned to redesign the API. But it implies to understand well the primitives and it is not EASY at all. Some are said old in comments (IPV4 primitives?), some are new (IPV6?),... So it is a too HARD to understand this code without doc or explanations (and you are right I am also a poor newbie). 2) I do not want to hear this sentence anymore: "Oh yes, you use a VM with an old version of the socket plugin. You should recompile the VM." NO! I CAN'T DO THAT BECAUSE (until recently) RECOMPILING THE VM REQUIRE DEEP KNOWLEDGE AND SOME BLACK MAGIC. (Thanks to Igor, Esteban and all others to prepare a simple process for newbies like me such as checkout and compile). 3) Ocean idea: pull up the network stuff on the image side. use an FFI to call OS libs. With this approach I am able to: load new versions of the network without changing the VM, in the future directly call the new OS API (Grand Central on OSX for asynchronous sockets, --yes network libs evolve--...), write more high level code and it is a little bit easier to debug it. Ocean is our vision, perhaps it is wrong but I can not do better. It is not as complete as the plugin yet. We also plan to use either Alien+OS lib or the plugin as a backend for Ocean so the plugin will still be there at the end for those who want it. And for this last part, we will certainly need some explanations on the primitives in SocketPlugin code. So if you know it well, feel free to educate me. #Luc > Now you came and saying "you are on the losing side, because A, B, C".. >> Do, you think people should learn SocketPlugin instead? Been there did >> that. Frankly, don't want to touch it again or teach people about it. >> I seen much more cleaner and robust socket library OO wrappers. Not in >> smalltalk though. >> > > And you're doing the same now. You say it sucks, but you don't tell what's > wrong with it. > > > >> P.S. Don't take me wrong. Yes there is a lot to learn from >> SocketPlugin. But you would better spend time learning/reading other >> > > I didn't say that anyone should learn from SocketPlugin. Forget the plugin. > People should learn how the API works that SocketPlugin provides. Not many > people know how to use it according to my earlier discussions on this list > about networking. > > > well written and well documented multithreaded library for serving >> socket connections. >> > > Without pointing to those better libraries and the things they do better > than the current solution, this is just an empty phrase. > > > Levente > > > >> >> >>> Levente >>> >>> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> >> >

Feb. 5, 2011