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

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

Re: [Pharo-project] Network training

by Levente Uzonyi

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. > >>> 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? 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). > >> 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. Levente > >> Levente >> >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > >

Feb. 4, 2011

Re: [Pharo-project] Network training

by Igor Stasenko

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. >> 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. > 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. > Levente > > -- Best regards, Igor Stasenko AKA sig.

Feb. 4, 2011

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

by GermÃ¡n Arduino

Sorry I should have written: "Marcus", sorry. 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 > ================================================= >

Feb. 4, 2011

Re: [Pharo-project] Network training

by Levente Uzonyi

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? > 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. Eliot's threaded FFI plugin is very complex compared to (the pretty simple) SocketPlugin. Levente

Feb. 4, 2011

Re: [Pharo-project] Alien + MacVM + plugin/primitive error

by Luc Fabresse

2011/2/4 Esteban Lorenzano <estebanlm(a)gmail.com> > btw... since you are working with Alien, I just commit my refactor of > Alien-MacOS package (just in case) > is not yet fully functional, but it is "almost there" > Thanks. #Luc > > Cheers, > Esteban > > El 04/02/2011, a las 7:41p.m., Igor Stasenko escribiÃ³: > > > On 4 February 2011 23:17, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > >> oops... the answer to Luc was also for all the list... not private > >> intention, just wrong button pressed. I'm coping here again... sorry :) > >> Hi Luc, > >> cool you are willing to help :) > >> in 5.7.4 alien is integrated to the vm... so you need to download latest > >> version from here: http://gitorious.org/~estebanlm/squeak-vm/cocoa-osxand > >> should compile out of the box. The project is > >> platforms/iOS/vm/SqueakPureObjc.xcodeproj > >> there is a PharoDev 1.1.1 with every thing loaded there (under ./image) > >> To generate the files as expected, you can execute CMakeGenScripts > >> generateCocoaVM. > >> ...and that's all :) > > > > btw, Esteban, check out the latest CMakeVMMaker package. > > I trying to invent somewhat more convenient protocol for this.. help me > :) > > > > So, what i did is made each CPlatformConfig subclasses to answer > > #generate (to generate config only) > > and > > #generateWithSource (to generate vmmaker sources and then config) > > > > because it is logical, that each config knows how to generate itself > > (StackVMConfig knows which VM sources it should use etc). > > > > So, i think this script (#generateCocoaVM) should be put into > > CocoaIOSConfig or one of its subclasses >> #generateSourceFiles method > > as well as many other CMakeGenScripts >> generateXXXX, > > > > So then we could use something simple , like: > > > > CogUnixConfig generate[WithSources] > > CocoaIOSConfig generate[WithSources] > > > > i.e. pick config which you wanna use and do the rest automatically :) > > > > P.S. i hope someday we could even run builds using OSProcessPlugin > > directly from image by issuing: > > > > ABCDEblablaConfig build > > > > :) > > > > > >> btw... in my Alien-MacOS, I needed to fix some things (on the native > code, > >> not yet merged into trunk), and now -in my tests- everything looks like > >> working, but not the tests... it fails loading a library, maybe because > the > >> library is not there (as it is an integrated module)... I didn't spend > time > >> fixing the tests yet :( > >> Cheers, > >> Esteban > > > > > > > > -- > > Best regards, > > Igor Stasenko AKA sig. > > > > >

Feb. 4, 2011

Re: [Pharo-project] Alien + MacVM + plugin/primitive error

by Luc Fabresse

2011/2/4 Igor Stasenko <siguctua(a)gmail.com> > On 4 February 2011 23:17, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > oops... the answer to Luc was also for all the list... not private > > intention, just wrong button pressed. I'm coping here again... sorry :) > > Hi Luc, > > cool you are willing to help :) > > in 5.7.4 alien is integrated to the vm... so you need to download latest > > version from here: http://gitorious.org/~estebanlm/squeak-vm/cocoa-osx > and > > should compile out of the box. The project is > > platforms/iOS/vm/SqueakPureObjc.xcodeproj > > there is a PharoDev 1.1.1 with every thing loaded there (under ./image) > > To generate the files as expected, you can execute CMakeGenScripts > > generateCocoaVM. > > ...and that's all :) > > btw, Esteban, check out the latest CMakeVMMaker package. > I trying to invent somewhat more convenient protocol for this.. help me :) > > So, what i did is made each CPlatformConfig subclasses to answer > #generate (to generate config only) > and > #generateWithSource (to generate vmmaker sources and then config) > > because it is logical, that each config knows how to generate itself > (StackVMConfig knows which VM sources it should use etc). > > So, i think this script (#generateCocoaVM) should be put into > CocoaIOSConfig or one of its subclasses >> #generateSourceFiles method > as well as many other CMakeGenScripts >> generateXXXX, > > So then we could use something simple , like: > > CogUnixConfig generate[WithSources] > CocoaIOSConfig generate[WithSources] > > i.e. pick config which you wanna use and do the rest automatically :) > > P.S. i hope someday we could even run builds using OSProcessPlugin > directly from image by issuing: > > ABCDEblablaConfig build > > :) > yes and with Coral (Pharo system scripting) ;-) #Luc > > > btw... in my Alien-MacOS, I needed to fix some things (on the native > code, > > not yet merged into trunk), and now -in my tests- everything looks like > > working, but not the tests... it fails loading a library, maybe because > the > > library is not there (as it is an integrated module)... I didn't spend > time > > fixing the tests yet :( > > Cheers, > > Esteban > > > > -- > Best regards, > Igor Stasenko AKA sig. > >

Feb. 4, 2011

Re: [Pharo-project] Network training

by Luc Fabresse

2011/2/4 Levente Uzonyi <leves(a)elte.hu> > On Fri, 4 Feb 2011, Noury Bouraqadi wrote: > > >> On 4 fÃ©vr. 2011, at 12:38, jannik.laval wrote: >> >> >>> On Feb 4, 2011, at 09:48 , Igor Stasenko wrote: >>> >>> On 4 February 2011 09:19, Laval Jannik <jannik.laval(a)gmail.com> wrote: >>>> >>>>> but how can i find these ip address in pharo? >>>>> >>>>> >>>>> perhaps by writing new primitive :) >>>> >>>> Is there one already existing ? >>> >>> I don't think so. >> An alternative might be to use an Ocean-like approach and call OS features >> directly through some FFI. >> > > There is. See my previous mail in this thread. > > > >> Now, another thing, the method: NetNameResolver>>isConnected. >>> Inside there is this code: >>> >>> === >>> isConnected >>> "Dirty, but avoids fixing the plugin bug" >>> [NetNameResolver addressForName: 'www.esug.org'.] on: >>> NameLookupFailure do: [:ex| ^false]. >>> ^true >>> === >>> >>> The comment is clear... is the plugin bug fixed ? >>> >>> No. >> >> Luc and I decided that it does not worth it struggling with the plugin. >> This is why we initiated the Ocean project (plugin-free networking) >> available on SqueakSource. >> > > Plugin-free networking doesn't exist. You either use the SocketPlugin, > FFIPlugin or the plugin for Alien. > Yes, but hopefully we will be SocketPlugin free. 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. #Luc > > > Levente > > > >> We made interesting (though slow) progress so far. >> Currently we have a complete library for TCP client socket. >> For the server socket to be usable we need multithreading Alien which is >> not available yet. Hope Eliot will have time to work on this soon or may be >> we'll get NativeBoost working on all major platforms (Go Igore!!!). >> >> Instead of remaining stalled or hacking some temporary solution, we >> changed a bit our strategy in order to have (hopefully) support for TCP >> sockets ready for Pharo 1.3. Our idea is that the limitations of networking >> problem have 2 origins: The poor library and the plugin. >> >> We decided to put all our effort on the library and having it work with >> the plugin. We are re-writing it fully with tests. >> Our design is independent of the low-level network support (Bridge >> pattern). >> So, we can (didn't test yet) be able to work either with the plugin or >> with any external networking library, through Alien or other FFI. >> Once we'll be done with the library, we'll tackle the plugin issue. >> >> The Ocean is wide, we have to row a lot ;-) >> Noury >> >> >>

Feb. 4, 2011

Re: [Pharo-project] Alien + MacVM + plugin/primitive error

by Esteban Lorenzano

btw... since you are working with Alien, I just commit my refactor of Alien-MacOS package (just in case) is not yet fully functional, but it is "almost there" Cheers, Esteban El 04/02/2011, a las 7:41p.m., Igor Stasenko escribiÃ³: > On 4 February 2011 23:17, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> oops... the answer to Luc was also for all the list... not private >> intention, just wrong button pressed. I'm coping here again... sorry :) >> Hi Luc, >> cool you are willing to help :) >> in 5.7.4 alien is integrated to the vm... so you need to download latest >> version from here: http://gitorious.org/~estebanlm/squeak-vm/cocoa-osx and >> should compile out of the box. The project is >> platforms/iOS/vm/SqueakPureObjc.xcodeproj >> there is a PharoDev 1.1.1 with every thing loaded there (under ./image) >> To generate the files as expected, you can execute CMakeGenScripts >> generateCocoaVM. >> ...and that's all :) > > btw, Esteban, check out the latest CMakeVMMaker package. > I trying to invent somewhat more convenient protocol for this.. help me :) > > So, what i did is made each CPlatformConfig subclasses to answer > #generate (to generate config only) > and > #generateWithSource (to generate vmmaker sources and then config) > > because it is logical, that each config knows how to generate itself > (StackVMConfig knows which VM sources it should use etc). > > So, i think this script (#generateCocoaVM) should be put into > CocoaIOSConfig or one of its subclasses >> #generateSourceFiles method > as well as many other CMakeGenScripts >> generateXXXX, > > So then we could use something simple , like: > > CogUnixConfig generate[WithSources] > CocoaIOSConfig generate[WithSources] > > i.e. pick config which you wanna use and do the rest automatically :) > > P.S. i hope someday we could even run builds using OSProcessPlugin > directly from image by issuing: > > ABCDEblablaConfig build > > :) > > >> btw... in my Alien-MacOS, I needed to fix some things (on the native code, >> not yet merged into trunk), and now -in my tests- everything looks like >> working, but not the tests... it fails loading a library, maybe because the >> library is not there (as it is an integrated module)... I didn't spend time >> fixing the tests yet :( >> Cheers, >> Esteban > > > > -- > Best regards, > Igor Stasenko AKA sig. >

Feb. 4, 2011

Re: [Pharo-project] Alien + MacVM + plugin/primitive error

by Igor Stasenko

On 4 February 2011 23:17, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > oops... the answer to Luc was also for all the list... not private > intention, just wrong button pressed. I'm coping here again... sorry :) > Hi Luc, > cool you are willing to help :) > in 5.7.4 alien is integrated to the vm... so you need to download latest > version from here:Â http://gitorious.org/~estebanlm/squeak-vm/cocoa-osxÂ and > should compile out of the box. The project is > platforms/iOS/vm/SqueakPureObjc.xcodeproj > there is a PharoDev 1.1.1 with every thing loaded there (under ./image) > To generate the files as expected, you can executeÂ CMakeGenScripts > generateCocoaVM. > ...and that's all :) btw, Esteban, check out the latest CMakeVMMaker package. I trying to invent somewhat more convenient protocol for this.. help me :) So, what i did is made each CPlatformConfig subclasses to answer #generate (to generate config only) and #generateWithSource (to generate vmmaker sources and then config) because it is logical, that each config knows how to generate itself (StackVMConfig knows which VM sources it should use etc). So, i think this script (#generateCocoaVM) should be put into CocoaIOSConfig or one of its subclasses >> #generateSourceFiles method as well as many other CMakeGenScripts >> generateXXXX, So then we could use something simple , like: CogUnixConfig generate[WithSources] CocoaIOSConfig generate[WithSources] i.e. pick config which you wanna use and do the rest automatically :) P.S. i hope someday we could even run builds using OSProcessPlugin directly from image by issuing: ABCDEblablaConfig build :) > btw... in my Alien-MacOS, I needed to fix some things (on the native code, > not yet merged into trunk), and now -in my tests- everything looks like > working, but not the tests... it fails loading a library, maybe because the > library is not there (as it is an integrated module)... I didn't spend time > fixing the tests yet :( > Cheers, > Esteban -- Best regards, Igor Stasenko AKA sig.

Feb. 4, 2011