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

[Pharo-project] Little fix for #4697

by Michael Roberts

In inbox: Name: Tools-MikeRoberts.658 Issue: 4697 -Fix to OrderedCollectionInspector that fails #fieldList on OrderedCollections that are not fully formed. ---- I did a little fix for this bug, that prevents the debugger stepping into OrderedCollection new. I mention this to folks working on tools because it is an interesting edge case. If you specialise an inspector for a particular class, for example, you have to handle the case where the object is not fully formed. e.g right after basicNew, or in the middle of some initialisation. It failed for the debugger, because it relies on embedding an inspector for the receiver (bottom left) panel. So i guess this edge case is subtle... cheers, Mike

Aug. 23, 2011

Re: [Pharo-project] Some bugs

by StÃ©phane Ducasse

Don't feel guilty :) But send fixes so that we can collect them for a given version. And we will not get perfect systems. Imagine IBM payed during several year 100 engineers to build eclipse and so far we got one engineer 8 months. Stef On Aug 23, 2011, at 9:57 AM, Lukas Renggli wrote: >>> Now I think the subliminal message of this thread is that the Pharo >>> community should focus on making the existing images really stable >>> before hacking away on Pharo 1.4 and beyond ... :-) >> >> And we need more people actually looking at the bug tracker... I sometimes >> feel a bit lonely... > > Yes, I feel guilty of not being able to contribute more fixes. You are > doing the excellent job of integrating submitted patches > instantaneous. > > The problem is that the unstable versions are pushed extremely hard, > while the supposedly stable versions are still unstable. I don't see > how this can possibly work? > > Subsequently, I hesitate to submit a patch for an old version because > I know it won't be possible to merge it into newer versions. This is a > vicious circle. > > Lukas > > -- > Lukas Renggli > www.lukas-renggli.ch >

Aug. 23, 2011

Re: [Pharo-project] Some bugs

by StÃ©phane Ducasse

+1 On Aug 23, 2011, at 10:42 AM, Marcus Denker wrote: > > On Aug 23, 2011, at 9:54 AM, Alexandre Bergel wrote: > >> These issues are for 1.2.2. Who is maintaining it by the way? > > We maintain the current released image. But when people provide easy to integrate, clear and useful > bug fixes for older versions, we integrate them. > > (this was done for 1.1.2, it has all fixes that where added for 1.2.2) > > Of course it would be possible (and I would prefer it), if a group of 1.2 users could take that > over (e.g. commercial users that are actually using 1.2) > > The idea would not to actively develope it, but just make sure that all the fixes are added that > make sense (bug fixes, mostly). *And* make that driven and coordingated by actual users of > that version. This way we make sure that a release gets important fixes as long as it is used. > > We could have such a group for just every version released: It gets "handed off" to the people > using the release. This group than of course, with time, gets smaller, and in the end fades > away. > > The most important effect of this would be to not burn people maintaining old versions they > don't use themselves... > > Marcus > > > -- > Marcus Denker -- http://marcusdenker.de > >

Aug. 23, 2011

Re: [Pharo-project] little uMorphic progress

by StÃ©phane Ducasse

Thanks. I would love to have a cleaner morphic kernel :) But it will take time. Stef On Aug 23, 2011, at 3:31 PM, Pavel Krivanek wrote: > Hi, > > uMorphic is an experimental image based on Pharo Kernel (+Gofer) that > contains only core of Morphic functionality. It has no windows or > fonts, menus nor halos support, it can only open a basic Morph in the > world and drag it with mouse. The purpose of this image is to provide > information for Morphic packages reorganization. > > Now the basic cleaning was processed on this package so when it is > loaded to basic gofer image, no new Undeclared nor unimplemented > messages are added! :-) So it should be quite stable too. > > It has 2,9 MB and it modifies behavior of 32 methods. > > You may download and try it here: > http://windmap.cz/playground/trash/uMorphic.zip > > Cheers, > -- Pavel >

Aug. 23, 2011

Re: [Pharo-project] RBNodes accept vs. visit

by StÃ©phane Ducasse

I would love to change that because this is terribly confusing for me that the accept: and visit: methods are not well named. stef On Aug 23, 2011, at 2:33 PM, Camillo Bruni wrote: > Hi everyone, > > I just had a quick look at the RBNodes. Is there a particular reason why the visitor pattern methods are prefixed on both sides with 'accept'? > > eg. > > RBArrayNode >> acceptVisitor: aProgramNodeVisitor > ^ aProgramNodeVisitor acceptArrayNode: self > > camillo

Aug. 23, 2011

[Pharo-project] Research Engineer Position at INRIA

by StÃ©phane Ducasse

Hi guys We have a position for an engineer position around dynamic language (javascript, smalltalk) and security. Engineer position â¢ Duration: 1-2 years â¢ Starting date: end 2011/beginning 2012 â¢ Where: RMOD team at INRIA Lille Nord Europe http://rmod.lille.inria.fr/ â¢ Salary: 55 Keuros net (before taxes) Keywords: dynamic languages, security, information flow, Smalltalk, Javascript The position will take place in the context of the Systematic Resilience project. Three main tasks will be our focus: â¢ Develop a component model named JIO to manage I/O user interface in Javascript for cloud applications â¢ Identification of security problems in Javascript â¢ Study and analyze approaches towards securing Javascript and dynamic languages (Caja, isolate...) â¢ Prototype of a safe architecture for Resilience Please contact Stephane Ducasse (Stephane.Ducasse(a)inria.fr) for more information. ------------------------ Dr. StÃ©phane Ducasse -- Directeur de Recherche (Senior Researcher) INRIA - USTL - CNRS UMR 8022 stephane.ducasse(a)inria.fr http://stephane.ducasse.free.fr http://rmod.lille.inria.fr/ **NEW ***Tel 00 33 (0)3 20 43 42 56 - Fax 33 3 59 57 78 50 40, avenue Halley, Parc Scientifique de la Haute Borne, BÃ¢t.A, Park Plaza, Villeneuve d'Ascq, FR-59650, France.

Aug. 23, 2011

[Pharo-project] Build failed in Hudson: Pharo 1.3 #255

by marcus.denker＠inria.fr

See <https://pharo-ic.lille.inria.fr/hudson/job/Pharo%201.3/255/> ------------------------------------------ D?marr? par le projet amont "Pharo Core 1.3" de num?ro de build 400 Construction ? distance sur pharo-build.lille.inria.fr [Pharo 1.3] $ /bin/sh -xe /tmp/hudson6883078532781447625.sh + /builds/builder/build13.sh -i Core1.3 -s dev3 -s pharo/version -o Pharo-1.3 [version] 1.3 #13300 + /builds/builder/build13.sh -i Pharo-1.3 -s testrunner -s delHDLintReport -s runalltests -o Pharo-1.3-AfterRunningTests + zip -r Pharo-1.3.zip Pharo-1.3/Pharo-1.3.changes Pharo-1.3/PharoV10.sources Pharo-1.3/Pharo-1.3.image updating: Pharo-1.3/Pharo-1.3.changes (deflated 79%) updating: Pharo-1.3/PharoV10.sources (deflated 76%) updating: Pharo-1.3/Pharo-1.3.image (deflated 57%) + zip -r Pharo-1.3-AfterRunningTests.zip Pharo-1.3-AfterRunningTests/Pharo-1.3-AfterRunningTests.changes Pharo-1.3-AfterRunningTests/Pharo-1.3-AfterRunningTests.image updating: Pharo-1.3-AfterRunningTests/Pharo-1.3-AfterRunningTests.changes (deflated 80%) updating: Pharo-1.3-AfterRunningTests/Pharo-1.3-AfterRunningTests.image (deflated 57%) + /builds/builder/build-oneclick.sh -i Pharo-1.3 -o PharoOneClick1.3 -n PharoOneClick1.3 -v 1.3 -c Pharo -t Pharo + sh /builds/builder/pharo-shell-scripts/SavePharo13.sh Archiving artifacts Enregistrement des r?sultats des tests ERROR: Failed to archive test reports hudson.util.IOException2: remote file operation failed: <https://pharo-ic.lille.inria.fr/hudson/job/Pharo%201.3/ws/> at hudson.remoting.Channel@18af45f9:pharo-build.lille.inria.fr at hudson.FilePath.act(FilePath.java:752) at hudson.FilePath.act(FilePath.java:738) at hudson.tasks.junit.JUnitParser.parse(JUnitParser.java:66) at hudson.tasks.junit.JUnitResultArchiver.parse(JUnitResultArchiver.java:108) at hudson.tasks.junit.JUnitResultArchiver.perform(JUnitResultArchiver.java:120) at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19) at hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:601) at hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:580) at hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:558) at hudson.model.Build$RunnerImpl.post2(Build.java:158) at hudson.model.AbstractBuild$AbstractRunner.post(AbstractBuild.java:528) at hudson.model.Run.run(Run.java:1264) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:122) Caused by: hudson.util.IOException2: Failed to read <https://pharo-ic.lille.inria.fr/hudson/job/Pharo%201.3/ws/Pharo-1.3-AfterRu…> at hudson.tasks.junit.TestResult.parse(TestResult.java:198) at hudson.tasks.junit.TestResult.parse(TestResult.java:139) at hudson.tasks.junit.TestResult.<init>(TestResult.java:102) at hudson.tasks.junit.JUnitParser$ParseResultCallable.invoke(JUnitParser.java:95) at hudson.tasks.junit.JUnitParser$ParseResultCallable.invoke(JUnitParser.java:70) at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2028) at hudson.remoting.UserRequest.perform(UserRequest.java:114) at hudson.remoting.UserRequest.perform(UserRequest.java:48) at hudson.remoting.Request$2.run(Request.java:270) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:662) Caused by: org.dom4j.DocumentException: Error on line 288 of document file:///builds/workspace/Pharo%201.3/Pharo-1.3-AfterRunningTests/Zinc-Tests-Test.xml : XML document structures must start and end within the same entity. Nested exception: XML document structures must start and end within the same entity. at org.dom4j.io.SAXReader.read(SAXReader.java:482) at org.dom4j.io.SAXReader.read(SAXReader.java:264) at hudson.tasks.junit.SuiteResult.parse(SuiteResult.java:94) at hudson.tasks.junit.TestResult.parse(TestResult.java:183) ... 14 more Caused by: org.xml.sax.SAXParseException: XML document structures must start and end within the same entity. at com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.createSAXParseException(ErrorHandlerWrapper.java:195) at com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.fatalError(ErrorHandlerWrapper.java:174) at com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:388) at com.sun.org.apache.xerces.internal.impl.XMLScanner.reportFatalError(XMLScanner.java:1414) at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.endEntity(XMLDocumentFragmentScannerImpl.java:905) at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.endEntity(XMLDocumentScannerImpl.java:605) at com.sun.org.apache.xerces.internal.impl.XMLEntityManager.endEntity(XMLEntityManager.java:1393) at com.sun.org.apache.xerces.internal.impl.XMLEntityScanner.load(XMLEntityScanner.java:1763) at com.sun.org.apache.xerces.internal.impl.XMLEntityScanner.skipChar(XMLEntityScanner.java:1416) at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(XMLDocumentFragmentScannerImpl.java:2792) at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:648) at com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next(XMLNSDocumentScannerImpl.java:140) at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:511) at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:808) at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:737) at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:119) at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1205) at com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:522) at org.dom4j.io.SAXReader.read(SAXReader.java:465) ... 17 more Description set:

Aug. 23, 2011

Re: [Pharo-project] Some bugs

by Adrian Lienhard

Mike, Thanks for the initiative and the update on this issue! I hope other people have insights or can lend a helping hand... Adrian On Aug 23, 2011, at 14:25 , Michael Roberts wrote: > I think for the debugger, we all live with the bugs. I mean, we (I) > unfortunately made the situation worse with the introduction of the > closures around 1.0/1.1 and it has never been fixed. It is hard to fix > too, this stuff is not simple. I contacted a few people quietly maybe > a year ago to see if we all lived with it, because a few times i > posted about the debugger and there was not a lot of response. I > wondered if no one *actually* programmed in pharo. but no, we become > masters of interpreting the debugger highlight... > > What can we do- > 1) I have contacted Eliot (again). Historically he said it was fixed > (or better) in teleplace images but I need him to send us any patches. > He has also been helpful and highlighted the areas that need work like > the decompiler and how we could write some tests to protect against > unintended change > > 2) I have checked a recent Squeak, and it is bust there too. > > 3) I am writing some test cases. So that we can regression test the > debugger highlighting, and building an analyser class (@esug) to make > it easier to dig into the debugger. > > 4) carefully check Squeak class versions for merging changes into > Pharo. this is not easy. > > 5) We have to rebuild the debugger model based on the new compiler / > decompiler machinery. (This is a long term Pharo goal) > > I am just chipping away at the analysis, and i will share my code when > i have something on the tracker. > > Also would be great in a separate thread if someone could explain to > me the simulation guard primitive. i.e you can not step over process > creation, but you can halt after it e.g. > > cheers, > Mike >

Aug. 23, 2011

[Pharo-project] little uMorphic progress

by Pavel Krivanek

Hi, uMorphic is an experimental image based on Pharo Kernel (+Gofer) that contains only core of Morphic functionality. It has no windows or fonts, menus nor halos support, it can only open a basic Morph in the world and drag it with mouse. The purpose of this image is to provide information for Morphic packages reorganization. Now the basic cleaning was processed on this package so when it is loaded to basic gofer image, no new Undeclared nor unimplemented messages are added! :-) So it should be quite stable too. It has 2,9 MB and it modifies behavior of 32 methods. You may download and try it here: http://windmap.cz/playground/trash/uMorphic.zip Cheers, -- Pavel

Aug. 23, 2011

Re: [Pharo-project] Hudson build became unstable: Pharo Core 1.3 #400

by Camillo Bruni

the server caretaker.wolf359.be seems to be down or unreachable... On 2011-08-23, at 15:54, marcus.denker(a)inria.fr wrote: > See <https://pharo-ic.lille.inria.fr/hudson/job/Pharo%20Core%201.3/400/>

Aug. 23, 2011