- Pharo-dev - lists.pharo.org

[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

[Pharo-project] Deprecating Protocol browser
by StÃ©phane Ducasse Aug. 1, 2011

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

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

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

Aug. 1, 2011

Thanks! Stef On Aug 1, 2011, at 7:03 PM, Pavel Krivanek wrote: > The problem was with double exclamation mark in method > MultiByteFileStreamTest >> #chunkString. Fix attached to the issue. It > only rewrites original source code with the same one. > > -- Pavel > > > On Mon, Aug 1, 2011 at 2:04 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> >> On Aug 1, 2011, at 2:02 PM, Pavel Krivanek wrote: >> >>> Hi, >>> >>> I created a special on the CI server and it seems that we are not able >>> to condense changes. See >>> https://ci.lille.inria.fr/pharo/job/Pharo%201.4%20condenseChanges/5/console >> >> Yes, this is already broken since sime time... >> >> http://code.google.com/p/pharo/issues/detail?id=3923 >> >> (I think even in 1.2). >> >> Everything not tested will break... >> >> >> -- >> Marcus Denker -- http://marcusdenker.de >> >> >> >

1 0

Re: [Pharo-project] How to deprecate a Class?
by Marcus Denker Aug. 1, 2011

Aug. 1, 2011

On Aug 1, 2011, at 8:18 PM, Bernardo Ezequiel Contreras wrote: > Hi all, > In the issue tracker, there are many issues to deprecate several classes. so, What do you do in order to deprecate a class? > Could you explain the procedure to deprecate a class? > often it's just moving it to the Deprecated package. (Deprecated14, does not exist yet I think). Sometimes it makes sense to deprecate the class instatiaton methods in addition. Marcus -- Marcus Denker -- http://marcusdenker.de

1 0

[Pharo-project] [Pharo-users] 1.4 update is broken do not use it
by Torsten Bergmann Aug. 1, 2011

Aug. 1, 2011

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? - 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? Bye T. -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de

1 0