- Pharo-dev - lists.pharo.org

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

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

by marcus.denker＠inria.fr

See <https://pharo-ic.lille.inria.fr/hudson/job/Pharo%20Core%201.3/400/>

Aug. 23, 2011

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

by Camillo Bruni

It is consistent so I don't care too much :D just curious ;) On 2011-08-23, at 15:42, Lukas Renggli wrote: > Legacy, and because it really doesn't matter of how you name your > double-dispatch methods as long as you do it consistently within your > realm. > > Lukas > > On 23 August 2011 15:40, Tudor Girba <tudor(a)tudorgirba.com> wrote: >> Indeed, this is really confusing :). I am not aware of any particular reason. >> >> Doru >> >> >> On 23 Aug 2011, at 15:33, 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 >> >> -- >> www.tudorgirba.com >> >> "There are no old things, there are only old ways of looking at them." >> >> >> >> >> > > > > -- > Lukas Renggli > www.lukas-renggli.ch >

Aug. 23, 2011

[Pharo-project] [update 1.4] #14110

by Marcus Denker

14110 ----- Issue 4642: FinderUI>>compileSource: aString notifying: aController http://code.google.com/p/pharo/issues/detail?id=4642 -- Marcus Denker -- http://marcusdenker.de

Aug. 23, 2011