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

[Pharo-project] [update 1.4] #14079
by StÃ©phane Ducasse Aug. 9, 2011

Aug. 9, 2011

14079 ----- - Issue 4550: methodSymbol is a bad name for selector. Couple more fixes - Fix methodClass of RGMethodDefinition Stef

1 0

[Pharo-project] PharoCore 1.3: Implementors browser broken
by Lukas Renggli Aug. 9, 2011

Aug. 9, 2011

I just noticed that the implementors browser in Pharo Core 1.3 does not show any kind of warning if a variable is not declared. Also parse errors result in the fatal SyntaxError window. I thought I report it here before I forget it again, because the bug tracker is in read-only mode right now. Lukas -- Lukas Renggli www.lukas-renggli.ch

2 2

[Pharo-project] Shout in Pharo 1.3
by Lukas Renggli Aug. 9, 2011

Aug. 9, 2011

Does anybody has a version of Shout that correctly works in the traditional tools in Pharo 1.3? I tried various versions of Shout, but could not find one that worked correctly in the traditional tools. The problem I see is that Shout is not properly setup/updated anymore, i.e. it does not callback to the model (#shoutAboutToStyle:). When the browser/debugger changes the method/definition/comment highlighting is not enabled/disabled and the context is not changed. Does anybody have a working version of Shout and/or knows how to easily make it work? It works in OB because I subclassed 3 editor classes and undone the "new" way of how highlighting works. I thought I bring this up again, because as far as I see there is still the same problem ... Lukas -- Lukas Renggli www.lukas-renggli.ch

2 2

[Pharo-project] [Cog] New builds available on Jenkins server
by Igor Stasenko Aug. 9, 2011

Aug. 9, 2011

Hello, during last couple of weeks i was busy migrating migrating VM jobs from Hudson server to more up to date Jenkins server and creating a jobs for running tests on newly built VMs. The new location for built VMs are https://ci.lille.inria.fr/pharo/view/Cog/ I disabled the old jobs on Hudson server (https://pharo-ic.lille.inria.fr/hudson/view/Cog/) and also put a comment where they moved. So, from now all VMs which are built on Jenkins server will be automatically tested. If you go to jenkins page, you could see that each job , like StackVM-Unix has a parallel job named StackVM-Unix Tests , which runs tests after successful build of corresponding VM. The image which is used to run tests is Pharo 1.4. latest build (can be found on same server - https://ci.lille.inria.fr/pharo/view/Pharo%201.4/job/Pharo%201.4/) So, in this way we have a streamlined continuous integration setup, which tests every possible combination(s) of VMs and latest Pharo image, so we can easily track regressions as well as different behavior between platforms (ideally, there should be none ;)) Details about new builds: - it is a merge with VMMaker.oscog-eem.115 which contains an important fix for #become: primitive With this fix, i could say that Cog VMs are much stable! Problems, not yet solved: Windows: - there is no windows jobs yet, because we're still having problems with windows slave (it is inaccessible right now), but once it will work, i will add jobs for windows as well. Mac Cocoa builds: - i migrated the cocoa builds to jenkins server as well, but it is not yet using an updated verison of sources (we have to wait till Esteban will sync sources) - also those VMs cannot run tests because command-line interface for them is severely broken now :( -- Best regards, Igor Stasenko AKA sig.

1 0

[Pharo-project] GUI failing apart
by Janko MivÅ¡ek Aug. 9, 2011

Aug. 9, 2011

Hi guys, Strange things start happening to my 1.3 image. When edited some method it suddenly became covered with red, yellow crossed. Now other windows also have trouble to recreate when they come in focus. Not to mention many other such problems I cannot even describe. I somehow still manage to work with this image but with such trouble all the time. Is there a way to recover this image from such troubles? Best regards Janko -- Janko MivÅ¡ek Aida/Web Smalltalk Web Application Server http://www.aidaweb.si

6 15

[Pharo-project] On the way to 1.3 Release: images
by Marcus Denker Aug. 9, 2011

Aug. 9, 2011

Hi, So now we have images on Gforge that will be the release: Core: https://gforge.inria.fr/frs/download.php/28859/PharoCore-1.3-13298.zip Full: https://gforge.inria.fr/frs/download.php/28860/Pharo-1.3-13298.zip They are the ones build by Hudson, because magically the unix vm used there reads cog images but saves interpreter images (didn't know that). So these images should even run on ancient VMs, as promised for 1.3. Next steps: -> Build a one-click image. If nobody helps, I will do the same like 1.2: take the one of 1.2 and just copy some random VMs in there. Worked fine last time... -> change the links on pharo-project to point to these images for http://www.pharo-project.org/pharo-download/stable http://www.pharo-project.org/pharo-download/stable-core -> change the link http://www.pharo-project.org/pharo-download/unstable(-core) to point to the one jenkins build of 1.4 -> add a page or 1.3 on pharo-project.org -> clean up a bit, no need to have pages for old .1 release. Marcus -- Marcus Denker -- http://marcusdenker.de

5 6

Re: [Pharo-project] On the way to 1.3 Release: images
by Marcus Denker Aug. 9, 2011

Aug. 9, 2011

Thanks! > >> -> change the link >> http://www.pharo-project.org/pharo-download/unstable(-core) >> to point to the one jenkins build of 1.4 > > I changed /unstable-core to point to https://ci.lille.inria.fr/pharo/view/Pharo%201.4/job/Pharo%201.4/lastSucces… > > I assume there is no /unstable build (yet)? > For 1.4, we want to not have multiple images anymore... this is really difficult to fix bugs in two images, it's hard to explain, it complicated harvesting fixes (two completely different ways), it confuses new people. So there is just one Pharo starting from 1.4 Right now, this is the same as what used to be the core image. But we will add everything there that is needed to make it that environment that we want to use for developing Pharo itself... >> >> -> clean up a bit, no need to have pages for old .1 release. > > On pharo-project.org? > yes... the page for 1.1.1 we should merge into the page for 1.1 (just to make it look cleaner) Marcus -- Marcus Denker -- http://marcusdenker.de

3 2

[Pharo-project] Seaside on Pharo-Kernel
by Pavel Krivanek Aug. 9, 2011

Aug. 9, 2011

Hi, there's possible to load Seaside to the Pharo-Kernel. 1) Load PharoKernel-Gofer image from CI server (https://ci.lille.inria.fr/pharo/view/Pharo-Kernel/job/Pharo%20Kernel%20Gofe…) 2) run the image with seaside.st script as an argument. That will create about 4.1 MB image with basic Seaside packages and basic examples. 3) run the image with run.st script (note that starting of the server in the seaside.st script will hang, currently I have no idea why). 4) see if everything works at http://localhost:8080/examples/examplebrowser Cheers, -- Pavel

2 2

Re: [Pharo-project] On the way to 1.3 Release: images
by Marcus Denker Aug. 9, 2011

Aug. 9, 2011

On Aug 9, 2011, at 1:34 PM, Sean P. DeNigris wrote: > > marcus.denker wrote: >> >> For 1.4, we want to not have multiple images anymore... >> > > Awesome! Fixing bugs will be much more fun with e.g. OB loaded :) The problem with multiple browsers is that we have to maintain right now two Browsers. The problem is that one can only use one, and than the other will degrade. Or the other way around. Marcus -- Marcus Denker -- http://marcusdenker.de

1 0

Aug. 9, 2011

> > > On Aug 9, 2011, at 9:50 AM, btc(a)openInWorld.com wrote: > >> greetings all, >> >> What tools exist to assist with the forward engineering of UML diagrams into Smalltalk code? >> I have been searching for some time but my results are swamped by tools that: >> - reverse engineer Smalltalk code into UML diagrams >> - implement new techniques moving beyond UML and MOF >> >> I am implementing the [electric power system] Common Information Model of IEC 61970 in Smalltalk. This is defined as a UML Class Diagram (part of which I have attached) maintained using Enterprise Architect, which can export into XMI format. I hoped there might be a way to load the XMI directly into Smalltalk classes. Manually implementing the inheritance structure is straight forward, and I've developed a template for the aggregate relationships but an automated function would help to assure correctness, consistency and to track changes in the model. >> >> <Mail Attachment.jpeg > > > Hi btc > > In Moose on VW long time ago we implemented everything to load XMI, we had an emof reader that (I'm not sure anymore) was generating FAMIX classes. > May be you should ask on the Moose mailing-list. I could check on our old store but I should find somewhere how to connect to it. > > Stef > >

1 0