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

Re: [Pharo-project] Running Dyla at ecoop

by Damien Cassou

Salut Alex, On Tue, Dec 6, 2011 at 1:38 PM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > ECOOP will be in China next year. I am wondering whether some of you plan to attend. > I am thinking to run the Dyla workshop there, and I am looking for co-organizers. > > The website of last year edition is http://scg.unibe.ch/wiki/events/dyla2011 si tu veux de mon aide, je suis prÃªt Ã Ãªtre co-organiser. @++ -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry

Dec. 7, 2011

Re: [Pharo-project] Loading MCZ freezes, but loading the source.st works?

by Stefan Marr

Hi: On 06 Dec 2011, at 15:55, Mariano Martinez Peck wrote: > On Mon, Dec 5, 2011 at 4:21 PM, Stefan Marr <pharo(a)stefan-marr.de> wrote: >> I got here a Monticello package that does not properly load using the Metacello configuration. The image freezes and cmd+. does not pop up a debugger anymore. >> >> However, if I extract the source.st contained in the package and file it in manually, it does not freeze the image. > > It is likely you broke DataStream, and hence #loadDefinitions or friends is looping. I debugged the problem a bit. Stepping through the whole loading step. #loadDefinitions is already executed during opening and showing the package in the browser. It needs it, I think, for instance to show the commit message. And that is not the problem. Stepping through MCFileRepositoryInspector>>#load reveals that the image freezes on installing the method additions. (methodAdditions do: [:each | each installMethod].) There are for instance changes in Behavior and TPureBehavior. In general there is a dependency between changes, and a wrong order can easily break things. So, I checked whether the order in methodAdditions actually reflects what is in the change set. And the order is not consistent. So, what ever the approach is to decide on the order in the source.st, it is more stable/reliable in this case than what is in the binary snapshot. Any ideas to make these things consistent? Thanks Stefan -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525

Dec. 7, 2011

[Pharo-project] [update 1.4] #14248

by Marcus Denker

14248 ----- Issue 5066: Sync VM version from image side http://code.google.com/p/pharo/issues/detail?id=5066 Issue 5065: [ENH]: Clean up Mail code (Part 2) http://code.google.com/p/pharo/issues/detail?id=5065 Issue 4994: Two failing test in ProcessTest http://code.google.com/p/pharo/issues/detail?id=4994 -- Marcus Denker -- http://marcusdenker.de

Dec. 7, 2011

Re: [Pharo-project] UIManager

by Henrik Sperre Johansen

On 06.12.2011 18:42, Pavel Krivanek wrote: > On Tue, Dec 6, 2011 at 12:30 PM, Henrik Sperre Johansen > <henrik.s.johansen(a)veloxit.no> wrote: >> On 06.12.2011 11:46, Henrik Sperre Johansen wrote: >>> Is it just me, or is UIManager gradually turning into a new >>> SystemDictionary/Project? >>> >>> Cheers, >>> Henry >> And by that I mean equivalent to those classes in purity of purpose and >> simplicity; >> UIManager used to have a clear purpose - Provide a polymorphic interface for >> accessing common GUI dialogs for code which doesn't care which GUI framework >> is in use. >> >> Right now, MorphicUIMananger also has methods for >> - Component building (a poor mans ToolBuilder, basically) >> - Global state accessor, not polymorphic (world and uiProcess handling ) >> - Debugger components building (!) >> - Accessing common Smalltalk tools (not necessarily a bad thing, but >> shouldn't that be the responsibility of ToolRegistry? IE a UIManager should >> install a proper ToolRegistry when activated, not provide an extra layer of >> indirection you HAVE to use if you say, want your app to work headlessly) >> - something called interactiveParserFor: I have no idea what means. > this method resolves if the UIManager is able to process questions > from the parser/compiler on user (like warnings about unimplemented > callss, undeclared instance variables etc.). > > -- Pavel > I assume that means these are not cases where input is not critical, and the compiler always has a backup path? Would that mean it might be an idea to instead use Notifications here, and let the caller handle them if necessary/appropriate? Cheers, Henry

Dec. 7, 2011

[Pharo-project] How to resurrect an unrepsonsive image?

by Norbert Hartl

I have a headless image that was running for a couple of days. Now it is not responding anymore. The image was running still but the sockets for http and vnc were closed and restarting the image just brings it up without any sockets opened. Injecting something via script does not work either. I copied the image to my desktop and tried a few things but no success. What would be a good way to get a glimpse of what is causing problems? I had Scheduler running that saved the image every hour. And the image itself issues http request to the outside world every 10 minutes. thanks, Norbert

Dec. 7, 2011

Re: [Pharo-project] Having a shared package-cache Re: MCDirectoryRepository defaultDirectoryName ignored?

by Mariano Martinez Peck

On Wed, Dec 7, 2011 at 2:48 AM, Sean P. DeNigris <sean(a)clipperadams.com>wrote: > > Mariano Martinez Peck wrote > > > > MCCachedRepository >> marianoDefaultWithDirectory: aDirectory > > self checkCacheDirectory. > > ^ default ifNil: [default := self new directory: aDirectory] > > > I don't think you need to do all this (the checkCacheDirectory and ifNil: > checks are on the old value you're throwing away). How about: > > MCCacheRepository>>default: aFileDirectory > > default := self new directory: aFileDirectory. > > Then you won't need to do the reset, and it's general enough to include in > the image w/o extension methods. A setting would be nice too :) I'll rename > my other setting to avoid confusion (I already created an issue). > > Issue 5067: Make package cache location changeable > http://code.google.com/p/pharo/issues/detail?id=5067 > > I added #default: but not the setting > > Yes, and you can also directly execute: MCCacheRepository default directory: (FileDirectory on: '/Users/mariano/Pharo/sharedRepo'). > -- > View this message in context: > http://forum.world.st/Having-a-shared-package-cache-Re-MCDirectoryRepositor… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > -- Mariano http://marianopeck.wordpress.com

Dec. 7, 2011

Re: [Pharo-project] Why CompiledMethod print string shows #identityHah ?

by Marcus Denker

On Dec 6, 2011, at 5:15 PM, Mariano Martinez Peck wrote: > > So...my question is, is there any reason why it makes so much sense to print the identityHash of a CompiledMethod ? I use it to see if a method has been recompiled. (if it is different to the one before). Marcus -- Marcus Denker -- http://marcusdenker.de

Dec. 7, 2011

Re: [Pharo-project] Having a shared package-cache Re: MCDirectoryRepository defaultDirectoryName ignored?

by Sean P. DeNigris

Mariano Martinez Peck wrote > > MCCachedRepository >> marianoDefaultWithDirectory: aDirectory > self checkCacheDirectory. > ^ default ifNil: [default := self new directory: aDirectory] > I don't think you need to do all this (the checkCacheDirectory and ifNil: checks are on the old value you're throwing away). How about: MCCacheRepository>>default: aFileDirectory default := self new directory: aFileDirectory. Then you won't need to do the reset, and it's general enough to include in the image w/o extension methods. A setting would be nice too :) I'll rename my other setting to avoid confusion (I already created an issue). Issue 5067: Make package cache location changeable http://code.google.com/p/pharo/issues/detail?id=5067 I added #default: but not the setting -- View this message in context: http://forum.world.st/Having-a-shared-package-cache-Re-MCDirectoryRepositor… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Dec. 7, 2011

Re: [Pharo-project] Squeak/Pharo in Fedora

by Mariano Martinez Peck

On Tue, Dec 6, 2011 at 10:38 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > can you open a ticket mariano? > With fix in inbox. http://code.google.com/p/pharo/issues/detail?id=5066 > Tx > > > On Dec 6, 2011, at 10:26 PM, Mariano Martinez Peck wrote: > > > > > > > How so? My latest version is SVN > http://www.squeakvm.org/svn/squeak/branches/Cog/ r2519. Monticello > package http://source.squeak.org/VMMaker/VMMaker.oscog-eem.139. > > > > But where is such information stored? > > Then, the VMMaker package version says nothing, because to buiyld the VM > you need more packages than VMMaker, so you have to guess which version to > use. > > Moreoever, there is also ANOTHER version in VM which is VMMaker > class>>versionString which is different from that. > > Then from the image or from a log we get: VM: Mac OS - intel - 1068 - > Croquet Closure Cog VM [CoInterpreter VMMaker.oscog-eem.78] Croquet Cog > 3.0.0 > > so where it is the svn version? > > > > (1007 to: 1009) collect: [:n| Smalltalk getSystemAttribute: n] > > > > #('CoInterpreter VMMaker.oscog-eem.138 uuid: > f9a63bdf-7bbc-4ae5-9634-ecd6fd814c9d Nov 18 2011' > > 'StackToRegisterMappingCogit VMMaker.oscog-eem.139 uuid: > c2849383-9768-4948-b9b2-a5c22d482b07 Nov 18 2011' > > 'r2519 http://www.squeakvm.org/svn/squeak/branches/Cog') > > > > Good enough? > > > > Better. So I guess that at least in Pharo this method deserves an update: > > > > version > > "Return the version number string of the Virtual machine built" > > " > > Smalltalk vm version > > " > > > > ^(self getSystemAttribute: 1004), ' ', ((self getSystemAttribute: > 1009) ifNil: ['']) > > > > > > > > > > > > In fact, only the last is required since the VM and plugin source is > included in http://www.squeakvm.org/svn/squeak/branches/Cog/src. > > > > > > So...all in all, I think that indeed, it is quite a mess. But it is also > complicated to manage and I don't really know what to suggest. > > With ConfigurationOfCog at least with one number we group all image side > related packages. > > Then we only need svn/git version. Moreover, we can store this svn/git > as the description in each version of ConfigurationOfCog. That way, you > know *exactly* what do you need. > > > > Cheers > > > > > > > > > > Cheers, > > -- Pavel > > > > > > > > > > -- > > best, > > Eliot > > > > > > > > > > -- > > Mariano > > http://marianopeck.wordpress.com > > > > > > > > > > -- > > best, > > Eliot > > > > > > > > > > -- > > Mariano > > http://marianopeck.wordpress.com > > > > > -- Mariano http://marianopeck.wordpress.com

Dec. 6, 2011

Re: [Pharo-project] Squeak/Pharo in Fedora

by Pavel Krivanek

2011/12/6 Eliot Miranda <eliot.miranda(a)gmail.com>: > > > On Tue, Dec 6, 2011 at 1:27 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com> > wrote: >> >> On Tue, Dec 6, 2011 at 9:58 PM, Eliot Miranda <eliot.miranda(a)gmail.com> >> wrote: >> > >> > >> > On Tue, Dec 6, 2011 at 12:56 PM, Pavel Krivanek >> > <pavel.krivanek(a)gmail.com> >> > wrote: >> >> >> >> Hi Eliot, >> >> >> >> On Tue, Dec 6, 2011 at 9:38 PM, Eliot Miranda <eliot.miranda(a)gmail.com> >> >> wrote: >> >> > >> >> > >> >> > On Tue, Dec 6, 2011 at 11:05 AM, Pavel Krivanek >> >> > <pavel.krivanek(a)gmail.com> >> >> > wrote: >> >> >> >> >> >> Hi, >> >> >> >> >> >> I want make a little report about progress with making of Fedora >> >> >> pakcages for Smalltalk related projects (StackVM, CogVM, Pharo...) >> >> >> by >> >> >> Jaroslav Å karvada. >> >> >> >> >> >> Currently there are three packages in Fedora repositories - >> >> >> squeak-vm, >> >> >> squeak-image and squeak-vm-nonXOplugins (that contains plugins like >> >> >> OSProcess). It uses resources from the Squeak site. >> >> >> >> >> >> Red Hat has quite restrictive demands on packages and it is a small >> >> >> miracle that they tolerate current squeak packages :-). The >> >> >> conditions >> >> >> simply do expect that a program is a set of source codes and not a >> >> >> system of communicating objects. One problem is that Squeak VM is >> >> >> one >> >> >> of few metacircular packages that are needed for their own building. >> >> >> Because binary executables are prohibited, it would require a >> >> >> special >> >> >> bureaucratically problematic exception. Fortunately for virtual >> >> >> machine generation we may use the current squeak packages - more >> >> >> precisely their updated versions. The next issue for virtual machine >> >> >> generation may be the fact, that some packages used for VM >> >> >> generation >> >> >> are in repositories with public read&write permissions. >> >> >> >> >> >> Because image can be likened to *.jar files that are prohibited and >> >> >> must be recompiled during package generation, we are lucky that >> >> >> squeak-image package is currently accepted. If someone starts >> >> >> tinkering, we are in big trouble. >> >> >> >> >> >> There is a little issue with *.sources placement. The current VM >> >> >> package contains symlinks from VM path to sources files that are >> >> >> present in package with the image. This is really ugly solution. >> >> >> Squeak and Pharo uses this sequence for sources lookup: vm path, >> >> >> image >> >> >> path, current path. So I think that the best solution will be to >> >> >> have >> >> >> sources file in the image package, do not have symlinks in vm >> >> >> package >> >> >> and to create symlink to sources together with changes in the image >> >> >> path via mysqueak initialization script. >> >> >> >> >> >> Btw., Jaroslav told me that he saw a lot of creepy projects but >> >> >> nothing like Squeak VM :-) >> >> >> >> >> >> And there is a mess in VM versioning. What is the latest >> >> >> CogVM/StackVM >> >> >> version number? >> >> > >> >> > >> >> > How so? Â My latest version is SVN >> >> > http://www.squeakvm.org/svn/squeak/branches/Cog/ r2519. Â Monticello >> >> > package >> >> > http://source.squeak.org/VMMaker/VMMaker.oscog-eem.139. >> >> >> >> What is the relation between this SVN repository and Git repository >> >> used by the CI server (https://git.gitorious.org/cogvm/blessed.git)? >> > >> > >> > Not anything to do with me. >> >> It is in hands of Esteban. Strange, I thought that the Cog development >> is not splitted. The Git version uses cmake. SVN version autotools? > > > yes. > >> >> >> >> What is the reason to exclude fbdev? >> > >> > >> > What's fbdev? >> >> framebuffer display device. > > > It wasn't used at Qwaq/Teleplace and as things evolved it was easier to > leave it behind. Â Do you want it back? It does not stem from any current practical needs however with fbdev, OSProcess and NativeBoost there may be done cool things ;-) >> >> >> >> >> >> >> -- Pavel >> >> >> >> >> Cheers, >> >> >> -- Pavel >> >> >> >> >> > >> >> > >> >> > >> >> > -- >> >> > best, >> >> > Eliot >> >> > >> >> >> > >> > >> > >> > -- >> > best, >> > Eliot >> > >> > > > > -- > best, > Eliot >

Dec. 6, 2011