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

[Pharo-project] importing versions in squeaksource does not work anymore
by Veronica Isabel Uquillas Gomez Aug. 2, 2011

Aug. 2, 2011

Hi, This feature is broken. I am getting the following error: There was an error importing the file xxx.25.mcz. The file has to be in mcz format! It does not make sense. How can I publish files in a repository now? Regards, Veronica

1 0

[Pharo-project] updating the state of a state button
by Hilaire Fernandes Aug. 2, 2011

Aug. 2, 2011

In a dialog, I found the state of a button is not updated, even after self changed. See the code bellowm with methodes defnied in the dialog: newMySketchesButton ^ self newButtonFor: self getState: #isMySketches action: #sketches arguments: nil getEnabled: #beMySketches "alway return true" label: 'MySketches' translated help: 'View my sketches' translated sketches self isExamples: false. isExamples: boolean isExamples := boolean. self changed isMySketches ^self isExamples not There is no #update at the dialog level, how should the button state updated? (I know I can do it by-hand) Implementing myself an #update or do I miss something? Thanks Hilaire -- Education 0.2 -- http://blog.ofset.org/hilaire

2 2

[Pharo-project] Hudson build is back to normal : Pharo 1.3 #248
by marcus.denker＠inria.fr Aug. 2, 2011

Aug. 2, 2011

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

1 0

[Pharo-project] Build failed in Hudson: Pharo Core 1.3 #391
by marcus.denker＠inria.fr Aug. 2, 2011

Aug. 2, 2011

See <https://pharo-ic.lille.inria.fr/hudson/job/Pharo%20Core%201.3/391/> ------------------------------------------ Started due to content change in http://pharo.gforge.inria.fr/updates/pharo1.3/updates13.list Construction ? distance sur pharo-build.lille.inria.fr FATAL: Impossible de produire un fichier de script hudson.util.IOException2: Failed to create a temp file on <https://pharo-ic.lille.inria.fr/hudson/job/Pharo%20Core%201.3/ws/> at hudson.FilePath.createTextTempFile(FilePath.java:964) at hudson.tasks.CommandInterpreter.perform(CommandInterpreter.java:66) at hudson.tasks.CommandInterpreter.perform(CommandInterpreter.java:58) at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19) at hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:601) at hudson.model.Build$RunnerImpl.build(Build.java:174) at hudson.model.Build$RunnerImpl.doRun(Build.java:138) at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:416) at hudson.model.Run.run(Run.java:1241) 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: remote file operation failed: <https://pharo-ic.lille.inria.fr/hudson/job/Pharo%20Core%201.3/ws/> at hudson.remoting.Channel@fb6bad6:pharo-build.lille.inria.fr at hudson.FilePath.act(FilePath.java:752) at hudson.FilePath.act(FilePath.java:738) at hudson.FilePath.createTextTempFile(FilePath.java:942) ... 11 more Caused by: hudson.util.IOException2: Failed to create a temporary directory in /tmp at hudson.FilePath$12.invoke(FilePath.java:953) at hudson.FilePath$12.invoke(FilePath.java:942) 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: java.io.IOException: Read-only file system at java.io.UnixFileSystem.createFileExclusively(Native Method) at java.io.File.checkAndCreate(File.java:1704) at java.io.File.createTempFile(File.java:1792) at hudson.FilePath$12.invoke(FilePath.java:951) ... 11 more Archiving artifacts Enregistrement des r?sultats des tests Description set:

1 1

[Pharo-project] [update 1.3] #13292
by Marcus Denker Aug. 2, 2011

Aug. 2, 2011

13292 ----- Issue 3923: #condenseChanges not working in 1.3 http://code.google.com/p/pharo/issues/detail?id=3923 -- Marcus Denker -- http://marcusdenker.de

1 0

[Pharo-project] [update 1.4] #14070
by Marcus Denker Aug. 2, 2011

Aug. 2, 2011

14070 ----- Issue 3923: #condenseChanges not working in 1.3 http://code.google.com/p/pharo/issues/detail?id=3923 -- Marcus Denker -- http://marcusdenker.de

1 0

[Pharo-project] Squeaksource down?
by Cyrille Delaunay Aug. 2, 2011

Aug. 2, 2011

Hello, I am not able to connect to squeaksource

2 1

Aug. 1, 2011

ProtocolBrowser, a subclass of MessageSet, should be deprecated. Now if the functionality is used (I never used it but I may be a non typical programmer), we could use FlatListBrowser to implement ProtocolBrowser. So let us know what you think. http://code.google.com/p/pharo/issues/detail?id=4575 Stef

5 10

Aug. 1, 2011

14069 ----- - fixed CommentReference missing backward compatibility methods. - fixed some methodSymbol references http://code.google.com/p/pharo/issues/detail?id=4550 - fixed eval and execution of code in FlatMessageListBrowser Issue 4580: RGMethodDefinition protocol can be nil - fix results of protocolAt: and timeStampAt: of SourceFileArray. - add test to cover SourceFileArray utils methods http://code.google.com/p/pharo/issues/detail?id=4580 Stef

1 0

Re: [Pharo-project] [Pharo-users] 1.4 update is broken do not use it
by Marcus Denker Aug. 1, 2011

Aug. 1, 2011

On Aug 1, 2011, at 6:27 PM, Torsten Bergmann wrote: > Marcus wrote: >>>> so now updating from https://gforge.inria.fr/frs/download.php/28827/Pharo-1.4-14065.zip >>> >>> Is this a core or a full image? If core (which one can use to update further) shouldnt this be reflected in the ZIP's name? > >> In 1.4, there is only one image. >> This simplifies everything.... > > > OK, but then two questions regarding the above image: > > - what is the intention? Provide only the core image in the future? > Will ConfigurationOfPharo still be maintained to be able to > build a dev image? > The intention is that maintaining two images is one too much. -> We need to test two images -> We track bugs in two categories (see my old mails, very confusing "X bugs here, Z bugs open there") -> We have two completely different ways of how fixes get into the system. And the one fo the ConfigurationOfPharo is really complex to get even a trivial change in. In addtion, it complicates many things: -> the story gets complex. Two downloads. Which do I take? Just look at pharo-project.org. Too complex. -> The Full image can not be updated. That alone is a killer. -> We maintain two browsers -> ..... It's not sustainable. It should be noted that the ConfigurationOfPharo was broken for far too many days, and fixing takes too much effort. The idea is *not* that this one image has the functionality of the old Core image. The idea instead is to have *one* image that is the one that everyone uses and that is the best development environment that we can do. > - why is the provided image a Cog only image (was not able to open it > with the standard VM, so it looks like it was saved with Cog) > Is this intended? I have only one VM on my machine. So this lead to the problem that I updated the image for download with that VM.... and I forgot that there is problem. This happend in 1.2 and in 1.3 and in 1.4, and I am tired of it. I am too dumb, I will never get it right. This is again is a question of complexity: Something that is so complex needs to be simplified. We can not support all old VMs forever. New VMs can load the new image format. One of the ideas of 1.4 is that besides one Image, we will have "one" set of VMs. The ones build by the Jenkins/Hudson. They run the new image format. The rule is: for version X of Pharo, use version X of the VM. This solves another problem: Moving to the Future. E.g. the new VMs support better finalization, yet the image needs to be compatible forever to the old code. The new VMs support Ephemerons. Do we ever want to use them? An images where they are active will not run on the old VMs. Being able to move forward on the VM side is very, very important. It makes no sense to be backward *and* forward compatible forever. Marcus -- Marcus Denker -- http://marcusdenker.de

2 1