- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Issue 3620 in pharo: Settings: OCompletion settings appear twice

by pharo＠googlecode.com

Comment #4 on issue 3620 by marcus.d...(a)gmail.com: Settings: OCompletion settings appear twice http://code.google.com/p/pharo/issues/detail?id=3620 yes

Feb. 5, 2011

Re: [Pharo-project] Network training

by jannik.laval

Maybe I can do a try. Do you have sources ? Jannik On Feb 5, 2011, at 08:47 , Marcus Denker wrote: > > On Feb 5, 2011, at 8:42 AM, jannik.laval wrote: > >> Hi Levente, >> >> Thank you for the answer, but it is not clear for me where is this source code. >> You are saying that the VM includes already something like that, does the 5.7 (non-cog) includes it ? >> And how can I find the source code ? I will try to search on eToys image. >> >> Why was in included in removed from Pharo ? >> > Because it did not work and we did not have the resources to debug it. > > Marcus > > -- > Marcus Denker -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > >

Feb. 5, 2011

[Pharo-project] Pharocasts: StringCalculator Kata

by laurent laffont

This is the first Kata proposed by the 12meses12katas<http://www.12meses12katas.com/> (12 months 12 katas) initiative. You will learn: Test-Driven Development, the Pharo way. Recorded and edited by Rafael Luque <http://vimeo.com/user1627267> (big thank you!). Here: http://www.pharocasts.com/2011/02/stringcalculator-kata.html Laurent Laffont - @lolgzs <http://twitter.com/#!/lolgzs> Pharo Smalltalk Screencasts: http://www.pharocasts.com/ Blog: http://magaloma.blogspot.com/

Feb. 5, 2011

Re: [Pharo-project] Network training

by Marcus Denker

On Feb 5, 2011, at 8:42 AM, jannik.laval wrote: > Hi Levente, > > Thank you for the answer, but it is not clear for me where is this source code. > You are saying that the VM includes already something like that, does the 5.7 (non-cog) includes it ? > And how can I find the source code ? I will try to search on eToys image. > > Why was in included in removed from Pharo ? > Because it did not work and we did not have the resources to debug it. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

Feb. 5, 2011

Re: [Pharo-project] Network training

by jannik.laval

Hi Levente, Thank you for the answer, but it is not clear for me where is this source code. You are saying that the VM includes already something like that, does the 5.7 (non-cog) includes it ? And how can I find the source code ? I will try to search on eToys image. Why was in included in removed from Pharo ? Jannik On Feb 4, 2011, at 13:24 , Levente Uzonyi wrote: > On Fri, 4 Feb 2011, jannik.laval wrote: > >> Hi, >> >> I am playing with Network package. >> I am giving a practical work to my students, in Java :( >> And I am doing the same in Pharo to understand the Network package :))) >> >> A first question: >> I use "NetNameResolver localHostAddress" to retrieve my network address. Now in computers, there are multiple addresses. >> I do not find a method to retrieve a collection of my address and it seems to be not possible, because it uses primLocalAddress, which is a primitive returning one local address. >> >> Does it exist something to have all my ip address? > > Yes. The network changes that were introduced in Pharo 1.1 and were reverted before the release contained such methods. In theory both the VM side and client side code is ready for this (Etoys uses it on OLPC), but some VMs (e.g. Cog) don't have the latest plugin versions, so the primitives don't work there. > > > Levente > >> >> Thank you, >> >> >> >> --- >> Jannik Laval >> >> >> >

Feb. 5, 2011

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

by Marcus Denker

On Feb 5, 2011, at 12:16 AM, GermÃ¡n Arduino wrote: > Sorry I should have written: "Marcus", sorry. > I attach the complete script used for building 1.2 as the builder.sh stiches it together: > 2011/2/4 GermÃ¡n Arduino <garduino(a)gmail.com>: >> Thanks by the explanations Dale. >> >> Thanks Guillermo and Markus by the points. >> >> Until moment any way of installation I tried failed with different >> sort of messages. >> >> By now I downloaded the ready image pointed by Markus but would like >> to build my own. >> >> Thanks! >> >> >> 2011/2/4 Dale Henrichs <dhenrich(a)vmware.com>: >>> Sure: >>> >>> http://gemstonesoup.wordpress.com/2011/01/17/metacello-1-0-beta-28-unearthe… >>> >>> Be sure to look at the section of development cycle ... and tools support, too... >>> >>> Dale >>> >>> On Feb 4, 2011, at 6:37 AM, Guillermo Polito wrote: >>> >>> Dale, Is there a place where I can read how to configure the symbolic versions? >>> >>> Thx! >>> Guille :) >>> >>> On Fri, Feb 4, 2011 at 11:29 AM, Dale Henrichs <dhenrich(a)vmware.com<mailto:dhenrich@vmware.com>> wrote: >>> ConfigurationOfPharo should have a #stable symbolic version defined that specifies the version that should be used in 1.2, 1.1, and 1.0 ... then one just loads the #stable version: >>> >>> (ConfigurationOfPharo project version: #stable) load >>> >>> and you'll get the right version loaded for the platform version ... even though the version is under development I think it is valid to specify a #stable symbolic version for Pharo1.2, just so folks don't have to ask this question over and over again ... Don't let the name 'stable' scare you ... >>> >>> The intent is that the #stable symbolic version specifies the version that should be loaded .... the developer decides which versions are #stable for each platform version and when a new version becomes "the version to use" the developer updates the specification. >>> >>> The users of a configuration shouldn't have to think ... remember in the past the recommended pattern was: >>> >>> ConfigurationOfPharo project latestVersion load >>> >>> and that worked fine until Pharo1.1 and Pharo1.2 were introduced. The expression: >>> >>> (ConfigurationOfPharo project version: #stable) load >>> >>> is intended to replace the use of #latestVersion because it makes it possible to explicitly specify the "latest version" on a platform by platform and platform version basis... >>> >>> Sorry if I appear to be ranting ... I'm just trying to get the message out:) >>> >>> Dale >>> >>> On Feb 4, 2011, at 6:01 AM, Guillermo Polito wrote: >>> >>> I'm Using '1.2-beta2'. >>> >>> Should we remove invalid and unused versions? I'll add a few comments at lunch time ;) >>> >>> On Fri, Feb 4, 2011 at 10:53 AM, GermÃ¡n Arduino <garduino(a)gmail.com<mailto:garduino@gmail.com><mailto:garduino@gmail.com<mailto:garduino@gmail.com>>> wrote: >>> I tried the 2 latest Beta and fail, also the 1.1 version fail. >>> >>> Which ConfigurationOfPharo I should use with Pharo 1.2 ? >>> >>> Cheers. >>> >>> >>> >>> >>> >>> >>> >>> >> >> >> >> -- >> ================================================= >> GermÃ¡n S. Arduino <gsa @ arsol.net> Twitter: garduino >> Arduino Software & Web Hosting http://www.arduinosoftware.com >> PasswordsPro http://www.passwordspro.com >> ================================================= >> > -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

Feb. 5, 2011

[Pharo-project] Smalltalk for engineers

by Geert Claes

James Robertson spotted this post: http://unhandledexpression.com/2011/02/04/smalltalk-for-engineers/ I was especially interested in the statement "you donât understand what you can/should do ..." -- View this message in context: http://forum.world.st/Smalltalk-for-engineers-tp3261551p3261551.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Feb. 5, 2011

Re: [Pharo-project] Network training

by Levente Uzonyi

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. > 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

Re: [Pharo-project] Network training

by Igor Stasenko

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? :) Levente, when is the last time you checked the meaning of word 'development' in dictionary? >> >>>> 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 :) > 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 :) >> >>> 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. 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. 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. 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 well written and well documented multithreaded library for serving socket connections. > > Levente > -- Best regards, Igor Stasenko AKA sig.

Feb. 5, 2011

Re: [Pharo-project] [COTDC] MCFileRepositoryInspector

by Guillermo Polito

Let's give it a try: I am a Monticello Tool used to inspect the packages and their versions and version summary, for a given repository. I underline the packages you already loaded, and highlight the ones you don't have updated to the last version. I also highlight the versions you did not load yet. On Fri, Feb 4, 2011 at 6:41 PM, laurent laffont <laurent.laffont(a)gmail.com>wrote: > 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