- Pharo-dev - lists.pharo.org

Re: [Pharo-project] [sbe-discussion] 1.3, PBE and lab setups

by Serge Stinckwich

2011/12/15 stephane ducasse <stephane.ducasse(a)free.fr>: > > On Dec 15, 2011, at 2:24 AM, Serge Stinckwich wrote: > >> 2011/12/15 Dave Mason <dmason(a)mason-rose.ca>: >>> I am trying to get our local admins to set up labs so students can use the >>> latest Pharo. >>> >>> Currently we have 1.2 and PBE .image files and by removing the field in the >>> INI file that specified the image, if you clicked on Pharo, you'd get a >>> dialogue asking which image you wanted. Â All of these are on read-only >>> mounts, so if you want to save to the image, you need to copy the image to >>> your home directory and then you could navigate to that image file on >>> startup. Â Dropping an image on the executable works fine, though. >>> >>> Additionally, the PBE book doesn't play well with 1.3 (things that the book >>> says die when you try them). Â Apparently you can't open the PBE image from >>> the 1.3 binary without it crashing, either. >>> >>> So I have 3 questions: >>> >>> 1) is 1.3 the system to use, or will 1.4 be stable soon? >>> >>> 2) is the PBE book getting updated to work with a vanilla 1.3/1.4 image? >> >> There is no plan at the moment to do that, but you could help adapt >> the Pharo Book to the new images. >> All the contents of the book is here: >> https://github.com/SquareBracketAssociates/PharoByExample-english >> >> Maybe we can have branches for each version of Pharo ? pharo1.2, >> pharo1.3, etc â¦ > > yes this would be really good to have a branch Ok, who is willing to help for adapting the Pharo by Example book to Pharo 1.4 ? I could add a branch for Pharo 1.0 for the old version and we could use master branch for Pharo 1.4. Regards, -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Matsuno Laboratory, Kyoto University, Japan (until 12/2011) http://www.mechatronics.me.kyoto-u.ac.jp/ Every DSL ends up being Smalltalk http://doesnotunderstand.org/

Dec. 22, 2011

Re: [Pharo-project] Zinc (bug?) - multiple default servers

by Sven Van Caekenberghe

Name: Zinc-HTTP-SvenVanCaekenberghe.233 Author: SvenVanCaekenberghe Time: 22 December 2011, 12:54:05 pm UUID: 8dd541c9-2890-4a8f-b5cb-d6ac2e9341af Ancestors: Zinc-HTTP-SvenVanCaekenberghe.232 Rewrote ZnServer and subclasses's class methods #startDefaultOn: and #defaultOn: to treat the default instance like a singleton by reusing/restarting/reconfiguring existing instances; expanded comments; Changed the implementation of ZnServer>>#start to automagically register the default instance; Changed the implementation of ZnServer>>#stop to always unregister; added ZnServer>>#stop: with an option to control the unregistering so that it does not happen when shutting down the image ---- Name: Zinc-Tests-SvenVanCaekenberghe.121 Author: SvenVanCaekenberghe Time: 22 December 2011, 12:56:23 pm UUID: c1396284-0787-4c42-bedd-fb6ae918c68d Ancestors: Zinc-Tests-SvenVanCaekenberghe.120 added ZnServerTests>>#testDefault to test the new semantics of ZnServer class>>#startDefaultOn: --- ZnServerTests>>#testDefault | server | ZnServer stopDefault. self assert: ZnServer default isNil. server := ZnServer startDefaultOn: 1701. self assert: ZnServer default notNil. self assert: ZnServer default == server. self assert: ZnServer default port = 1701. self assert: ZnServer default isRunning. self assert: (ZnServer managedServers includes: server). ZnServer stopDefault. self assert: ZnServer default isNil. self deny: server isRunning. self deny: (ZnServer managedServers includes: server). server := ZnServer startDefaultOn: 1701. "Starting the default again is actually a restart" ZnServer startDefaultOn: 1701. self assert: ZnServer default == server. ZnServer stopDefault On 21 Dec 2011, at 08:26, Sven Van Caekenberghe wrote: > Sean, > > On 21 Dec 2011, at 04:40, Sean P. DeNigris wrote: > >> If you evaluate "ZnServer startDefaultOn: aPortNumber" several times, you end >> up with that many instances of the default server class. Is that the >> intended behavior? #default usually = singleton, so I expected all the calls >> to operate on the same instance. > > ZnServer>>#defaultOn: aNumber > "Create a new Default instance on a given port, > stopping any previously running Default and replacing it. > Register the new instance." > > Default ifNotNil: [ Default stop ]. > ^ Default := (self on: aNumber) > register; > yourself > > Hmm, I never looked at it that way, but now that you mention it, a clearer singleton behavior might make more sense. Note that in any case, only one instance was running. But it might make more sense to really maintain a singleton, the comments should be adapted as well. > > Thanks for bringing this to my attention. > > Regards, > > Sven

Dec. 22, 2011

Re: [Pharo-project] External web browser

by Alexander LazareviÄ

Hilaire, on Linux the ExternalWebBrowser package, as it is, depends on a helper program (e.g. xdg-open) to open a url in the default browser. The helper program is executed using the system() function of the standard C library. This is defined in ExternalWebBrowser>>*system:* string "system() executes a command specified in string by calling /bin/sh -c string, and returns after the command has been completed." <*apicall:* short 'system' (char*) *module:* 'c'> ^self externalCallFailed The problem is, that the VM is unable to find that 'c' module/library as you can see when you evaluate ExternalWebBrowserUnix isCLibAvailable The VM is actively looking for a library file before it will use the dynamic linker to actually load it. The VM uses permutations of well known library locations (e.g. /lib) with library pre- (e.g. lib) and postfixes (e.g. .so) to find the file. So for example it will look for /lib/libc.so (among many others see [1] on a related matter) But even back at the time I started the ExternalWebBrowser package, the Linux distributions that I used (Debian, Ubuntu) didn't provide such a file, but /lib/libc.so.6. And the VM would not look for such a file. So to make it work I used a hack that Andreas Raab used with his OpenGL package to change the module name of the FFI definitions on the fly. In isCLibAvailable I try to use the generic module name 'c' and if that fails I try it again with the specific module name 'libc.so.6'. This (hack) worked as long as there was such a file. Now it seems that on newer Linux distributions even this file disappeared and it all depends on the dynamic linker to find the right shared library file. One could extend the list of module names to try by '/lib/i386-linux-gnu/libc.so.6' as on my system, but that would most probably not work with 64bit systems and so on. A better solution would be to adapt the way tries to find/load shared libraries. In the special case of handling URLs by external programs, I think Bert Freudenberg suggested that the/a VM/VM-Module should provide such a functionality. Alex [1] http://forum.world.st/OpenGL-in-4-1-or-later-td3794639.html#a4214041 2011/12/21 Hilaire Fernandes <hilaire.fernandes(a)edu.ge.ch>: > Hello, > > What is the status of external web browser use. > Last time I checked several months ago I can't use it with Linux. > Anyone using it successfully recently? > > Thanks > > Hilaire > > -- > Dr. Geo -- http://www.drgeo.eu > >

Dec. 22, 2011

Re: [Pharo-project] web site relocation Re: Newbie observations on use of Metacello

by Mariano Martinez Peck

On Wed, Dec 21, 2011 at 3:56 PM, Ben Coman <btc(a)openinworld.com> wrote: > Thanks for the tip. I was aware of the rename to DBXTalk, but not the > change to ConfigurationOfOpenDBXDriver. > The new site [1] says "Welcome to SqueakDBX", and [2] refers only to > ConfigurationOfSqueakDBX. > > Well, it is NOT a new site, it is just a backup of the previous in the meanwhile until we have the new one. The new website (for DBXTalk is in progress and we will ANN it soon) > Further offtopic but perhaps of interest to others... > The DBXTalk site was difficult to find. For me google results only show > it on the second page. I lament for your sake the loss of the > squeakdbx.org domain. You may have had better better results holding on > to it for a couple of years coupled with a 301 redirect [3][4]. As well as > losing the immediate redirects from the existing links on other web sites, > including your own [5], the cybersquatter now on squeakdbx.org may > compromise the ranking of your new site, along with additional "content > duplication/spam" reasons discussed at [3]. > > Thanks Ben for the advice. Unfortunately it is too late :( > [1] http://dbxtalk.smallworks.com.**ar/<http://dbxtalk.smallworks.com.ar/> > [2] http://dbxtalk.smallworks.com.**ar/Installation<http://dbxtalk.smallworks.com.ar/Installation> > [3] http://www.bigoakinc.com/seo-**articles/301-direct-Google.php<http://www.bigoakinc.com/seo-articles/301-direct-Google.php> > [4] http://support.google.com/**webmasters/bin/answer.py?hl=** > en&answer=93633<http://support.google.com/webmasters/bin/answer.py?hl=en&answer=93633> > [5] http://marianopeck.wordpress.**com/tag/dbxtalk/<http://marianopeck.wordpress.com/tag/dbxtalk/> > > cheers, Ben > > Mariano Martinez Peck wrote: > >> Hi Ben. Some offtopic, but be aware that ConfigurationOfSqueakDBX is >> deprecated. The whole project has been renamed to DBXTalk and what was >> SqueakDBX is now DBXTalkOpenDBXDriver. You can find >> ConfigurationOfOpenDBXDriver in DBXTalk repo or MetacelloRepository. >> >> On Mon, Dec 19, 2011 at 6:11 PM, StÃ©phane Ducasse < >> stephane.ducasse(a)inria.fr >> >> >>> wrote: >>> >>> >> >> >> >>> On Dec 19, 2011, at 5:04 PM, Ben Coman wrote: >>> >>> >>> >>>> StÃ©phane Ducasse wrote: >>>> >>>> >>>>> ben thanks for your feedback. >>>>> >>>>> Normally we should use the monticello repository browser and just click >>>>> >>>>> >>>> on a ConfigurationOf >>> >>> >>>> I've been lurking this mail list for 6 - 9 months and had not picked >>>> >>>> >>> that up. That is a big miss. I'm not usually so slow. Can you point me >>> to >>> the documentation that describes that process? >>> >>> >>> The problem is that we did not push it to the point the repository for >>> 1.0, contains only 1.0 configuration. >>> We will check that when esteban will arrive. >>> >>> >>> >>>> In the meantime, I unzip a fresh Pharo-1.3-OneClick, open Monticello >>>> >>>> >>> Browser and look for ConfigurationOfSqueakDBX. I can't see it. I >>> expected >>> to since you seemed to indicate it was that simple. >>> >>> >>>> So I GUESS* my way through. I <Open> the >>>> >>>> >>> http://www.squeaksource.com/**MetacelloRepository<http://www.squeaksource.com/MetacelloRepository>repository >>> >>> >>>> (which actually requires a bit of fore knowledge about the url - which >>>> >>>> >>> not all newbies will have) >>> >>> >>>> This did show ConfigurationOfSqueakDBX but the are many versions and so >>>> >>>> >>> many buttons to choose from. A bit scary for a newbie. >>> >>> >>>> Anyhow, I'll ASSUME* to select the latest one >>>> >>>> >>> ConfigurationOfSqueakDBX-**MarianoMartinezPeck.27 and click <Load>. >>> >>> >>>> I still can't see any SqueakDBX or OpenDBX classes in System Browser. >>>> Do I need to follow up manually doing "ConfigurationOfSqueakDBX project >>>> >>>> >>> latestVersion load." ? >>> >>> >>>> A mixed procedure part GUI and part non-GUI is not the best - and I've >>>> >>>> >>> not seen it documented anywhere. >>> >>> >>>> I would have liked to have loaded the package with "just a single click >>>> >>>> >>> on a ConfigurationOf" but there seems to be more to it than that. >>> >>> >>>> The following still seems easier: >>>> >>>> >>>>> Metacello package: 'SqueakDBX' load >>>>> >>>>> >>>> or perhaps some alternatives using existing tools... >>>> 1. To the Monticello Browser add a <Metacello> button that opens >>>> >>>> >>> http://www.squeaksource.com/**MetacelloRepository<http://www.squeaksource.com/MetacelloRepository>. >>> If Metacello is "THE" >>> package management tool then it should have a higher profile than just >>> one >>> of the 23 listed repositories, of which two others have "Metacello" in >>> their title. >>> >>> >>>> 2. To the World Menu, add a <Metacello Browser> item that jumps straight >>>> >>>> >>> to the Monticello Repository Browser for >>> http://www.squeaksource.com/**MetacelloRepository<http://www.squeaksource.com/MetacelloRepository> >>> . >>> >>> >>>> 3. The Welcome Text of a fresh pharo-oneclick image should describe how >>>> >>>> >>> to do either 1. or 2. above. >>> >>> >>>> cheers, Ben >>>> >>>> >>>>> than did you read the forthcoming chapter? >>>>> https://gforge.inria.fr/frs/**download.php/28462/Metacello.**pdf<https://gforge.inria.fr/frs/download.php/28462/Metacello.pdf>(old >>>>> >>>>> >>>> version) >>> >>> >>>> >>>>> >>>> Yes I refer to it in point 4 below. Can you point me to where in that >>>> >>>> >>> pdf it specifically describes that loading procedure using Monticello >>> Browser. All the examples I can see are code b> below, except using >>> (Smalltalk at:.....) rather than the class itself. >>> >>> >>>> Further, the Pharo-1.3-OneClick opening documentation says to execute >>>> >>>> >>> the following line... >>> >>> >>>> DEVImageWorkspaces openExternalProjectWorkspace. >>>>> >>>>> >>>> which shows several examples all of the same form as the code b> below. >>>> >>>> Also, from memory the examples given throughout this mail list tend to >>>> >>>> >>> be of the same form as code b> below - rather than directing people to >>> the >>> GUI Monticello Browser - or I probably would have picked that up sooner. >>> >>> >>>> Stef >>>>> >>>>> >>>>> >>>>> On Dec 19, 2011, at 5:15 AM, Ben Coman wrote: >>>>> >>>>> >>>>> >>>>> >>>>>> Some observations from the perspective of as a newbie on Pharo Package >>>>>> >>>>>> >>>>> Management. I'm likely to me missing in the philosophy of the design, >>> but >>> from the narrow view of my own usage.... >>> >>> >>>> 1. When I read about Metacello being the package management system, I >>>>>> >>>>>> >>>>> expected there to be a "command"(*) Metacallo but instead I see Gopher >>> being used. This is a mixed message that lowers my comfort level >>> feeling >>> I understand the system as I'm trying to pick up a bundle of new ideas. >>> As >>> I now understand it Metacello is more about a system of backend >>> configuration than a front end user interface. I am now more comfortable >>> using Gopher direct - but I reflect on how I felt the first time. >>> >>> >>>> (*) While technically a "command" is like a verb, and Gopher is like >>>>>> >>>>>> >>>>> a noun rather than a verb - I can't yet completely disengage my prior >>> learning that considers the first part of the statement to be a >>> "command" - >>> and I expect other newbies might find the same. >>> >>> >>>> 2. The strong convention of naming things ConfigurationOfXXXX is >>>>>> >>>>>> >>>>> somewhat redundant from a user perspective. >>> >>> >>>> 3. If copy-paste into the Workspace from a web site a sample package >>>>>> >>>>>> >>>>> load (for example b> below) and then highlight the whole thing and >>> execute, >>> it tells me >>> >>> >>>> "Unknown variable: ConfigurationOfSqueakDBX, please correct, or >>>>>> >>>>>> >>>>> cancel" Duh! What? Oh, I need to execute it in two parts. No one >>> wrote >>> that down anywhere.... >>> >>> >>>> The alternative "(Smalltalk at: #ConfigurationOfSqueakDBX)" adds >>>>>> >>>>>> >>>>> further complexity in the eyes of a newbie. >>> >>> >>>> Based on the above points, it would be nice to have... >>>>>> >>>>>> a> Metacello configuration: 'SqueakDBX' load >>>>>> >>>>>> rather than... >>>>>> >>>>>> b> Gofer new >>>>>> b> squeaksource: 'MetacelloRepository'; >>>>>> b> package: 'ConfigurationOfSqueakDBX'; >>>>>> b> load. >>>>>> b> ConfigurationOfSqueakDBX project latestVersion load. >>>>>> While only a small saving in typing, I think it significant for >>>>>> >>>>>> >>>>> newbies in terms of polish and the marketing message that Metacello >>> really >>> is the chosen package management system. >>> >>> >>>> A very rough implementation (with much of the syntax likely wrong) >>>>>> >>>>>> >>>>> might be just... >>> >>> >>>> c> Metacello class >> package: aPackage >>>>>> c> | packageConfig | >>>>>> c> packageConfig := 'ConfigurationOf', aPackage; >>>>>> c> Gopher new c> squeaksource: >>>>>> >>>>>> >>>>> 'MetacelloRepository'; >>> >>> >>>> c> package: packageConfig >>>>>> c> load >>>>>> c> ^((Smalltalk at: (packageConfig asSymbol)) >>>>>> >>>>>> >>>>>> Now after I've written the above I contemplate that there must have >>>>>> >>>>>> >>>>> been an early design decision to not implement a separate Metacello >>> class >>> to avoid duplication/overlap with Monticello. However perhaps now that >>> the >>> system is implemented as it is, a thin shim can be put over the top to >>> assist getting the ConfigurationOfXXX files downloaded. Additional >>> things >>> this Metacello class might later provide: a. Improved reliability by >>> downloading from a system of package repository mirrors. SqueakSource >>> was >>> having some issues and I found [1] a fortunate backup. b. A GUI for >>> browsing package versions >>> >>> >>>> c. A GUI for browsing compatibility tables from a continuous >>>>>> >>>>>> >>>>> integration system that tries different permutations of Montecello >>> packages >>> together. >>> >>> >>>> 4. It seems that every ConfigurationOfXXX has its own category in the >>>>>> >>>>>> >>>>> SystemBrowser. Each of these categories has only one class. This >>> seems to >>> me like unneeded clutter of the System Browser. It would be neater if >>> Metacello specified its configurations to be grouped under a single >>> category "MetacelloConfigurations" or similar. >>> >>> >>>> 5. The sample Metacello PBE is very good in the detail for developers >>>>>> >>>>>> >>>>> to provide configurations. However there is not much directed clearly >>> at a >>> 'mere' user. Even though Smalltalk makes us all developers, newbies all >>> start as mere users while exploring the system. [1] Gofer new url: ' >>> http://dsal.cl/squeaksource/**MonticelloRedirect<http://dsal.cl/squeaksource/MonticelloRedirect>'; >>> package: >>> 'MontiRedirect'; load. MRManager redirectFrom: ' >>> http://www.squeaksource.com/' to: 'http://dsal.cl/squeaksource/'**. >>> >>> >>>> Cheers, Ben >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>> >>> >>> >> >> >> >> > > > -- Mariano http://marianopeck.wordpress.com

Dec. 22, 2011

Re: [Pharo-project] gtinspector

by Mariano Martinez Peck

On Thu, Dec 22, 2011 at 12:28 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi, > > On 21 Dec 2011, at 12:15, Mariano Martinez Peck wrote: > > > > > > > On Wed, Dec 21, 2011 at 9:01 AM, Tudor Girba <tudor(a)tudorgirba.com> > wrote: > > Hi, > > > > Just out of curiosity: Does any of you use the GTInspector? > > > > I used to use it for my images. And it was pretty nice. Problem was the > amount of dependencies it had, the time it took me to install it, and > moreover, that since it depends on several dependencies it was always > complicated to successfully install it. Apart from that, I really like it. > > Thanks. What do you mean by complicated to install it? That each time I tried I found a problem. I don't remember exactly now. First, it was a problem with RB (which was used from Grease I think) which was not even loading in the image. Then it was the Keymappings which was broken and annoying ;) I like the GTInspector and I like Glamour and all its related tools, but I always wondered the same: isn't there a way to use Glamour just for the development part? What I mean is that in this example of the GTInspector, it would be nice if you can generate from Glamour a plain standalone Morphic UI that we can just load. Say I have developed using glamour and all its nice features and then as an output I get a running morphic. Then of course, there will be people who will always want the glamour version because they change the code or whatever. Anyway, does it sound crazy to have a way to "deploy" Glamour? Where did you encounter problems? > > Cheers, > Doru > > -- > www.tudorgirba.com > > "Speaking louder won't make the point worthier." > > > -- Mariano http://marianopeck.wordpress.com

Dec. 22, 2011

Re: [Pharo-project] Crashes: Pharo 1.3 + Cog VM 13307

by Sven Van Caekenberghe

On 21 Dec 2011, at 22:51, Esteban Lorenzano wrote: > btw... the bug was present also on other platforms, so... latest vm from unix would be: > > https://ci.lille.inria.fr/pharo/view/VM/job/Cog-Unix/lastSuccessfulBuild/ar… > > I can create a pharo branded build (like I did for mac) for saturday. Yeah, I like it better when I can say ./pharo pharo-1.3.image and when that appears in the ps tables ;-) But it is not a deal breaker. Sven

Dec. 22, 2011

Re: [Pharo-project] Crashes: Pharo 1.3 + Cog VM 13307

by Francois Stephany

Sorry to annoy you with yet another stupid question but how can I know from which CogVM the current Cocoa one is based on? I'd like to know if the VM I use on my development machine (a mac) is close to the one I have on my linux servers. Or should I use the same Eliot VMs on both environments to avoid surprises ? On 21/12/11 14:44, Esteban Lorenzano wrote: > Hi, > > I'm means: "it should be version 6.0, but I'm still not confortable declaring it a production version"... so is a "pre-release". :P > > and yes, I know what you feel about version numbers... we (guys working with vm) should find an unique versioning number. But is hard, right now we have this different numbering: > > 1) Eliot has his own version number (I think based on svn commit version) > 2) Each platform (Linux, Windows and Mac) has his own versioning too. > 3) There are also 4.x versions alive (for mac, at least) > > I also don't know what does each version means (3.8 for unix, etc.). I named cocoa versions 6.x because older versions based on carbon where 5.x, so I thought: changing from carbon to cocoa is important enough to have a new major version... but I dunno. > > And I don't know how can be merged anytime soon... :( > > best, > Esteban > > El 21/12/2011, a las 7:28p.m., Francois Stephany escribiÃ³: > >> Hi Esteban, >> >> Looks nice ! >> I'm wondering however what does version "Pharo VM 6.0-pre" mean (see screenshot). >> >> I'm (again) lost in all those version numbers. >> >> >> >> On 21/12/11 13:41, Esteban Lorenzano wrote: >>> I also don't know how to update site :( but latest working vm (with pharo icons :) is here: >>> >>> https://ci.lille.inria.fr/pharo/view/VM/job/Pharo-Mac-Cocoa/lastSuccessfulB… >>> >>> cheers, >>> Esteban >>> >>> El 21/12/2011, a las 6:35p.m., StÃ©phane Ducasse escribiÃ³: >>> >>>> I do not know how to update the web site. >>>> Now do you have a link on the working vm because we can add it to the forge and link to it. >>>> >>>> Stef >>>> >>>> On Dec 21, 2011, at 10:09 PM, Esteban Lorenzano wrote: >>>> >>>>> yes... that version is old, and it has a bug who is fixed now. >>>>> Maybe we should update pharo site. >>>>> >>>>> cheers, >>>>> Esteban >>>>> >>>>> El 21/12/2011, a las 6:05p.m., StÃ©phane Ducasse escribiÃ³: >>>>> >>>>>> thanks johan >>>>>> >>>>>> doing what? >>>>>> on which platform? mac? >>>>>> Did you try the latest version on jenkins because esteban merged changes? >>>>>> >>>>>> Stef >>>>>> >>>>>> On Dec 21, 2011, at 9:04 PM, Johan Brichau wrote: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> I have been running Pharo 1.3 (#13315) with a pre-built Cog VM's downloaded from Eliot's site in a reliable manner (i.e. very few crashes) for many months. >>>>>>> >>>>>>> Just last week, I decided to try the Cog VM that is served from the Pharo website (Cog VM Mac-13307) and I am experiencing continuous crashes of the image. I am attaching a dump to this email. >>>>>>> >>>>>>> Once I switched back to the latest VM served on Eliot's site (VM.r2522), I stopped experiencing these crashes. >>>>>>> >>>>>>> If I experience this, probably other are tooâ¦ >>>>>>> >>>>>>> cheers, >>>>>>> Johan >>>>>>> >>>>>>> <crash.dmp> >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> >> -- >> http://tulipemoutarde.be >> BE: +32 (0)65 709 131 >> CA: +1 778 558 3225 >> > > -- http://tulipemoutarde.be BE: +32 (0)65 709 131 CA: +1 778 558 3225

Dec. 22, 2011

Re: [Pharo-project] Crashes: Pharo 1.3 + Cog VM 13307

by Esteban Lorenzano

Thanks for the explanation, Chris. I was thinking on using some of the eliot versions with my own builds, like this: 2222.01, and maybe unix/windows guys could do the same, so we need a prefix, something like 2222.M01 for mac, U01 for unix, W01 for windows... ... or something like that. Anyway... this discussion borns in pharo list, but concerns more to vm-dev list. I'm copying email there :) cheers, Esteban El 21/12/2011, a las 9:28p.m., Chris Cunningham escribiÃ³: > On Wed, Dec 21, 2011 at 2:44 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> Hi, >> >> and yes, I know what you feel about version numbers... we (guys working with vm) should find an unique versioning number. But is hard, right now we have this different numbering: >> >> 1) Eliot has his own version number (I think based on svn commit version) >> 2) Each platform (Linux, Windows and Mac) has his own versioning too. >> 3) There are also 4.x versions alive (for mac, at least) >> >> I also don't know what does each version means (3.8 for unix, etc.). I named cocoa versions 6.x because older versions based on carbon where 5.x, so I thought: changing from carbon to cocoa is important enough to have a new major version... but I dunno. >> > > The old numbering system came from pre-Pharo days, when the VM was > just for Squeak. In those days, the VM number was meant to sync with > the current Squeak image release - so vm 3.8 for Unix was the VM that > accompanied the Squeak 3.8 release, compiled for the Unix platform. > Each platform (and, indeed, each variant - such as Cocoa/Carbon) would > use the same main version number, but with some other distinction > built on (and these did change by platform). > > Eliot's VM now supports a wide range of roughly compatible Smalltalks > (or near smalltalks), such as Pharo, Squeak, Croquet, Cuis, Newspeak, > and probably others. In that environment, with each near-smalltalk > having their own numbering schemes, the old numbering convention just > doesn't make sense. So, his using the apparent SVN commit number > makes as much sense as anything - probably a lot more than some. > > As for what you should call the Pharo branded and tweaked versions, > that is obviously up to you. I would suggest finding something that > makes it easy for us users to figure out which version of the PharoVM > works with which Pharo image, if possible. > > -Chris >

Dec. 22, 2011

Re: [Pharo-project] Crashes: Pharo 1.3 + Cog VM 13307

by Chris Cunningham

On Wed, Dec 21, 2011 at 2:44 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > Hi, > > and yes, I know what you feel about version numbers... we (guys working with vm) should find an unique versioning number. But is hard, right now we have this different numbering: > > 1) Eliot has his own version number (I think based on svn commit version) > 2) Each platform (Linux, Windows and Mac) has his own versioning too. > 3) There are also 4.x versions alive (for mac, at least) > > I also don't know what does each version means (3.8 for unix, etc.). I named cocoa versions 6.x because older versions based on carbon where 5.x, so I thought: changing from carbon to cocoa is important enough to have a new major version... but I dunno. > The old numbering system came from pre-Pharo days, when the VM was just for Squeak. In those days, the VM number was meant to sync with the current Squeak image release - so vm 3.8 for Unix was the VM that accompanied the Squeak 3.8 release, compiled for the Unix platform. Each platform (and, indeed, each variant - such as Cocoa/Carbon) would use the same main version number, but with some other distinction built on (and these did change by platform). Eliot's VM now supports a wide range of roughly compatible Smalltalks (or near smalltalks), such as Pharo, Squeak, Croquet, Cuis, Newspeak, and probably others. In that environment, with each near-smalltalk having their own numbering schemes, the old numbering convention just doesn't make sense. So, his using the apparent SVN commit number makes as much sense as anything - probably a lot more than some. As for what you should call the Pharo branded and tweaked versions, that is obviously up to you. I would suggest finding something that makes it easy for us users to figure out which version of the PharoVM works with which Pharo image, if possible. -Chris

Dec. 22, 2011

Re: [Pharo-project] Crashes: Pharo 1.3 + Cog VM 13307

by Francois Stephany

Ow ok ! I didn't know the numbering scheme and was wondering where the "6" came from. Thanks for the overview :) Anyway, thanks for your work on the VMs! We just need to get better at public relations ;) On 21/12/11 14:44, Esteban Lorenzano wrote: > Hi, > > I'm means: "it should be version 6.0, but I'm still not confortable declaring it a production version"... so is a "pre-release". :P > > and yes, I know what you feel about version numbers... we (guys working with vm) should find an unique versioning number. But is hard, right now we have this different numbering: > > 1) Eliot has his own version number (I think based on svn commit version) > 2) Each platform (Linux, Windows and Mac) has his own versioning too. > 3) There are also 4.x versions alive (for mac, at least) > > I also don't know what does each version means (3.8 for unix, etc.). I named cocoa versions 6.x because older versions based on carbon where 5.x, so I thought: changing from carbon to cocoa is important enough to have a new major version... but I dunno. > > And I don't know how can be merged anytime soon... :( > > best, > Esteban > > El 21/12/2011, a las 7:28p.m., Francois Stephany escribiÃ³: > >> Hi Esteban, >> >> Looks nice ! >> I'm wondering however what does version "Pharo VM 6.0-pre" mean (see screenshot). >> >> I'm (again) lost in all those version numbers. >> >> >> >> On 21/12/11 13:41, Esteban Lorenzano wrote: >>> I also don't know how to update site :( but latest working vm (with pharo icons :) is here: >>> >>> https://ci.lille.inria.fr/pharo/view/VM/job/Pharo-Mac-Cocoa/lastSuccessfulB… >>> >>> cheers, >>> Esteban >>> >>> El 21/12/2011, a las 6:35p.m., StÃ©phane Ducasse escribiÃ³: >>> >>>> I do not know how to update the web site. >>>> Now do you have a link on the working vm because we can add it to the forge and link to it. >>>> >>>> Stef >>>> >>>> On Dec 21, 2011, at 10:09 PM, Esteban Lorenzano wrote: >>>> >>>>> yes... that version is old, and it has a bug who is fixed now. >>>>> Maybe we should update pharo site. >>>>> >>>>> cheers, >>>>> Esteban >>>>> >>>>> El 21/12/2011, a las 6:05p.m., StÃ©phane Ducasse escribiÃ³: >>>>> >>>>>> thanks johan >>>>>> >>>>>> doing what? >>>>>> on which platform? mac? >>>>>> Did you try the latest version on jenkins because esteban merged changes? >>>>>> >>>>>> Stef >>>>>> >>>>>> On Dec 21, 2011, at 9:04 PM, Johan Brichau wrote: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> I have been running Pharo 1.3 (#13315) with a pre-built Cog VM's downloaded from Eliot's site in a reliable manner (i.e. very few crashes) for many months. >>>>>>> >>>>>>> Just last week, I decided to try the Cog VM that is served from the Pharo website (Cog VM Mac-13307) and I am experiencing continuous crashes of the image. I am attaching a dump to this email. >>>>>>> >>>>>>> Once I switched back to the latest VM served on Eliot's site (VM.r2522), I stopped experiencing these crashes. >>>>>>> >>>>>>> If I experience this, probably other are tooâ¦ >>>>>>> >>>>>>> cheers, >>>>>>> Johan >>>>>>> >>>>>>> <crash.dmp> >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> >> -- >> http://tulipemoutarde.be >> BE: +32 (0)65 709 131 >> CA: +1 778 558 3225 >> > > -- http://tulipemoutarde.be BE: +32 (0)65 709 131 CA: +1 778 558 3225

Dec. 21, 2011