- Pharo-dev - lists.pharo.org

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/50439 Home: https://github.com/pharo-project/pharo-core

Nov. 12, 2015

[pharo-project/pharo-core] 56b5ef: 50439

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 56b5ef44e07c2b445b71e979444fe8b2da4dc3b8 https://github.com/pharo-project/pharo-core/commit/56b5ef44e07c2b445b71e979… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-11-12 (Thu, 12 Nov 2015) Changed paths: M ConfigurationOfVersionner.package/ConfigurationOfVersionner.class/instance/symbolic versions/stable_.st A ConfigurationOfVersionner.package/ConfigurationOfVersionner.class/instance/versions/version2137_.st A Deprecated50.package/extension/TBehavior/instance/methodDictAddSelectorSilently_withMethod_.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50438.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50439.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50438.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50439.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st R Traits.package/TBehavior.class/instance/adding%2Fremoving methods/methodDictAddSelectorSilently_withMethod_.st A Traits.package/TClass.class/instance/subclass creation/subclass_uses_instanceVariableNames_classVariableNames_package_.st M Versionner-Core-DependenciesModel.package/MTDependency.class/instance/comparing/=.st M Versionner-Core-Model.package/MBGroupInfo.class/instance/accessing/name.st Log Message: ----------- 50439 16992 deprecate methodDictAddSelectorSilently:withMethod: https://pharo.fogbugz.com/f/cases/16992 16952 Change class template creation https://pharo.fogbugz.com/f/cases/16952 16975 versionner (Object>>#name) https://pharo.fogbugz.com/f/cases/16975 http://files.pharo.org/image/50/50439.zip

Nov. 12, 2015

Re: [Pharo-dev] [Pharo-project] [Vm-dev] Cog issue? Re: StandardFileStream size limit?

by Nicolai Hess

2015-11-12 14:10 GMT+01:00 Dimitris Chloupis <kilon.alios(a)gmail.com>: > latest vm has issues with OSProcess stdout the last time I checked on > Yosemite. I would not call it stable unless we talk only crashes here. > Ah, I didn't know this was a vm issue. Does this means it is working with the "official" stable vm ? > > On Thu, Nov 12, 2015 at 2:55 PM Nicolai Hess <nicolaihess(a)gmail.com> > wrote: > >> 2015-11-12 6:14 GMT+01:00 Jimmie Houchin <jlhouchin(a)gmail.com>: >> >>> This still fails three and a half years later with a default Pharo 4 vm >>> and image. >>> :( >>> >>> I spent a few hours trying to diagnose why Pharo was telling me that I >>> file I knew existed didn't exist. Very frustrating trying to debug this and >>> then to find it is a vm and not an image issue. I then to search the >>> archives to find this is a known issue for this long and still broken. >>> >>> The latest linux vm works fine. >>> http://files.pharo.org/vm/pharo/linux/Pharo-VM-linux-latest.zip >>> >> >> Yes, the latest vm is pretty stable. But I think the problem is, there >> are to many changes for to many >> different projects: >> - I added a change to the windows keyevent handling and created a small >> regression (can not use ctrl+space anymore) >> - changes for OSWindow /SDL >> - spur (?) or any other changes from the main squeak vm >> - ... >> >> I think we should have create release candidate branch and make sure more >> people testing that version and all >> newer changes go to the master/development branch only. >> >> nicolai >> >> >>> >>> Is there a reason why the "latest" vm isn't the stable vm? Or at least >>> this bugfix applied to the stable vm? >>> >>> Thanks. >>> >>> Jimmie >>> >>> >>> >>> On 06/13/2012 05:00 PM, eliot.miranda at gmail.com (Eliot Miranda) >>> wrote: >>> >>>> On Wed, Jun 13, 2012 at 7:40 AM, David T. Lewis <lewis at mail.msen.com> >>>> wrote: >>>> >>>> On Wed, Jun 13, 2012 at 04:08:14PM +0200, G?ran Krampe wrote: >>>>> >>>>>> Hey! >>>>>> >>>>>> Ok, so the plot thickens: >>>>>> >>>>>> If I run this in a "oneclick 1.4" I will get a file write error on >>>>>> 2Gb: >>>>>> >>>>>> | f b | >>>>>> f := StandardFileStream newFileNamed: 'test'. >>>>>> b := ByteArray new: 1024*1024*100. "100Mb" >>>>>> [30 timesRepeat: [f nextPutAll: b]] ensure: [f close] "3Gb" >>>>>> >>>>>> >>>>>> ...but it worked fine using a self built "standard" VM from >>>>>> squeakvm.org >>>>>> (4.4.7.2357)! Same image btw. >>>>>> >>>>>> Now, does it work with the bleeding edge Cog? Tried r2556 and nope, >>>>>> same >>>>>> problem. >>>>>> >>>>>> So I "guess" it is a Cog thing? I haven't tried building Cog from >>>>>> source. >>>>>> >>>>>> regards, G?ran >>>>>> >>>>> Background on large file support, see especially Bert's summary: >>>>> >>>>> >>>>> >>>>> http://forum.world.st/Re-squeak-dev-filesize-reporting-0-for-very-large-fil… >>>>> http://bugs.squeak.org/view.php?id=7522 >>>>> http://www.suse.de/~aj/linux_lfs.html >>>>> >>>>> I'm not sure if the Cog VMs are being compiled with the the LFS option, >>>>> although >>>>> I expect that if you compile it yourself with the build options that >>>>> Bert >>>>> explains, >>>>> then it should start working. >>>>> >>>>> I just committed the necessary changes for my branch. Will rebuild >>>> soon. >>>> G?ran, if you're in a hurry build your own? You'd need to be in >>>> http://www.squeakvm.org/svn/squeak/branches/Cog/unixbuild/bld and run >>>> ./mvm. >>>> >>> >>> >>>

Nov. 12, 2015

Re: [Pharo-dev] [Pharo-project] [Vm-dev] Cog issue? Re: StandardFileStream size limit?

by Dimitris Chloupis

latest vm has issues with OSProcess stdout the last time I checked on Yosemite. I would not call it stable unless we talk only crashes here. On Thu, Nov 12, 2015 at 2:55 PM Nicolai Hess <nicolaihess(a)gmail.com> wrote: > 2015-11-12 6:14 GMT+01:00 Jimmie Houchin <jlhouchin(a)gmail.com>: > >> This still fails three and a half years later with a default Pharo 4 vm >> and image. >> :( >> >> I spent a few hours trying to diagnose why Pharo was telling me that I >> file I knew existed didn't exist. Very frustrating trying to debug this and >> then to find it is a vm and not an image issue. I then to search the >> archives to find this is a known issue for this long and still broken. >> >> The latest linux vm works fine. >> http://files.pharo.org/vm/pharo/linux/Pharo-VM-linux-latest.zip >> > > Yes, the latest vm is pretty stable. But I think the problem is, there are > to many changes for to many > different projects: > - I added a change to the windows keyevent handling and created a small > regression (can not use ctrl+space anymore) > - changes for OSWindow /SDL > - spur (?) or any other changes from the main squeak vm > - ... > > I think we should have create release candidate branch and make sure more > people testing that version and all > newer changes go to the master/development branch only. > > nicolai > > >> >> Is there a reason why the "latest" vm isn't the stable vm? Or at least >> this bugfix applied to the stable vm? >> >> Thanks. >> >> Jimmie >> >> >> >> On 06/13/2012 05:00 PM, eliot.miranda at gmail.com (Eliot Miranda) wrote: >> >>> On Wed, Jun 13, 2012 at 7:40 AM, David T. Lewis <lewis at mail.msen.com> >>> wrote: >>> >>> On Wed, Jun 13, 2012 at 04:08:14PM +0200, G?ran Krampe wrote: >>>> >>>>> Hey! >>>>> >>>>> Ok, so the plot thickens: >>>>> >>>>> If I run this in a "oneclick 1.4" I will get a file write error on 2Gb: >>>>> >>>>> | f b | >>>>> f := StandardFileStream newFileNamed: 'test'. >>>>> b := ByteArray new: 1024*1024*100. "100Mb" >>>>> [30 timesRepeat: [f nextPutAll: b]] ensure: [f close] "3Gb" >>>>> >>>>> >>>>> ...but it worked fine using a self built "standard" VM from >>>>> squeakvm.org >>>>> (4.4.7.2357)! Same image btw. >>>>> >>>>> Now, does it work with the bleeding edge Cog? Tried r2556 and nope, >>>>> same >>>>> problem. >>>>> >>>>> So I "guess" it is a Cog thing? I haven't tried building Cog from >>>>> source. >>>>> >>>>> regards, G?ran >>>>> >>>> Background on large file support, see especially Bert's summary: >>>> >>>> >>>> >>>> http://forum.world.st/Re-squeak-dev-filesize-reporting-0-for-very-large-fil… >>>> http://bugs.squeak.org/view.php?id=7522 >>>> http://www.suse.de/~aj/linux_lfs.html >>>> >>>> I'm not sure if the Cog VMs are being compiled with the the LFS option, >>>> although >>>> I expect that if you compile it yourself with the build options that >>>> Bert >>>> explains, >>>> then it should start working. >>>> >>>> I just committed the necessary changes for my branch. Will rebuild >>> soon. >>> G?ran, if you're in a hurry build your own? You'd need to be in >>> http://www.squeakvm.org/svn/squeak/branches/Cog/unixbuild/bld and run >>> ./mvm. >>> >> >> >>

Nov. 12, 2015

Re: [Pharo-dev] [Pharo-project] [Vm-dev] Cog issue? Re: StandardFileStream size limit?

by Nicolai Hess

2015-11-12 6:14 GMT+01:00 Jimmie Houchin <jlhouchin(a)gmail.com>: > This still fails three and a half years later with a default Pharo 4 vm > and image. > :( > > I spent a few hours trying to diagnose why Pharo was telling me that I > file I knew existed didn't exist. Very frustrating trying to debug this and > then to find it is a vm and not an image issue. I then to search the > archives to find this is a known issue for this long and still broken. > > The latest linux vm works fine. > http://files.pharo.org/vm/pharo/linux/Pharo-VM-linux-latest.zip > Yes, the latest vm is pretty stable. But I think the problem is, there are to many changes for to many different projects: - I added a change to the windows keyevent handling and created a small regression (can not use ctrl+space anymore) - changes for OSWindow /SDL - spur (?) or any other changes from the main squeak vm - ... I think we should have create release candidate branch and make sure more people testing that version and all newer changes go to the master/development branch only. nicolai > > Is there a reason why the "latest" vm isn't the stable vm? Or at least > this bugfix applied to the stable vm? > > Thanks. > > Jimmie > > > > On 06/13/2012 05:00 PM, eliot.miranda at gmail.com (Eliot Miranda) wrote: > >> On Wed, Jun 13, 2012 at 7:40 AM, David T. Lewis <lewis at mail.msen.com> >> wrote: >> >> On Wed, Jun 13, 2012 at 04:08:14PM +0200, G?ran Krampe wrote: >>> >>>> Hey! >>>> >>>> Ok, so the plot thickens: >>>> >>>> If I run this in a "oneclick 1.4" I will get a file write error on 2Gb: >>>> >>>> | f b | >>>> f := StandardFileStream newFileNamed: 'test'. >>>> b := ByteArray new: 1024*1024*100. "100Mb" >>>> [30 timesRepeat: [f nextPutAll: b]] ensure: [f close] "3Gb" >>>> >>>> >>>> ...but it worked fine using a self built "standard" VM from >>>> squeakvm.org >>>> (4.4.7.2357)! Same image btw. >>>> >>>> Now, does it work with the bleeding edge Cog? Tried r2556 and nope, same >>>> problem. >>>> >>>> So I "guess" it is a Cog thing? I haven't tried building Cog from >>>> source. >>>> >>>> regards, G?ran >>>> >>> Background on large file support, see especially Bert's summary: >>> >>> >>> >>> http://forum.world.st/Re-squeak-dev-filesize-reporting-0-for-very-large-fil… >>> http://bugs.squeak.org/view.php?id=7522 >>> http://www.suse.de/~aj/linux_lfs.html >>> >>> I'm not sure if the Cog VMs are being compiled with the the LFS option, >>> although >>> I expect that if you compile it yourself with the build options that Bert >>> explains, >>> then it should start working. >>> >>> I just committed the necessary changes for my branch. Will rebuild soon. >> G?ran, if you're in a hurry build your own? You'd need to be in >> http://www.squeakvm.org/svn/squeak/branches/Cog/unixbuild/bld and run >> ./mvm. >> > > >

Nov. 12, 2015

Re: [Pharo-dev] Smalltalkhub returning 500 response for a public repository

by Denis Kudriashov

Same for me now. I try commit to CAR/Ghost repository 2015-11-11 20:30 GMT+01:00 Euan Mee <euanmee(a)gmail.com>: > I've been trying unsuccessfully to write to the > SandstoneDb public repository at smalltalkhub.com > > http://smalltalkhub.com/#!/~gnaritas/SandstoneDb > shows the green tickmark and PUBLIC > > Writing to a package within it receives a 500 error. > > The specific package I am writing to is: > SandstoneDbTests > which is marked in Monticello (after I have downloaded it) as belonging in > http://smalltalkhub.com/mc/gnaritas/SandstoneDb/main > > as do all the other listed packages, i.e. > ConfigurationOfSandstoneDb > SandstoneDb > SandstoneDbFileSystemStore > SandstoneDbFuel > SandstoneDbFileDirectoryStore > SandstoneDbSqueak > SandstoneGOODS > SandstondDbGOODSTests > > (Thank you to Max Leske for confirming it was a 500 error at the > smalltalkhub.com end that was causing the debugger to respond to my > attempted commit). > >

Nov. 12, 2015

Re: [Pharo-dev] Does anybody know if Sport is available in Pharo?

by Christophe Demarey

Le 12 nov. 2015 Ã 10:15, Frank Shearar a Ã©crit : > On 12 November 2015 at 09:04, Christophe Demarey > <Christophe.Demarey(a)inria.fr> wrote: >> >> Le 10 nov. 2015 Ã 21:39, Sven Van Caekenberghe a Ã©crit : >> >>> << Sport is a Smalltalk portability layer. Sport presents a consistent interface and implemented in a number of Smalltalk dialects. Smalltalk code written to the Sport interfaces can be run in any Smalltalk dialect without alteration. >> >>> >>> Anyway, that was the idea some years ago. It is somewhat comparable to Grease (used by Seaside). >> >> Any reason to prefer one or the other? > > While they're both compatibility layers, Grease is a portability layer > _for Seaside_, while Sport is a portability layer for time, sockets, > and files. ok, thanks

Nov. 12, 2015

Re: [Pharo-dev] Never ending BlockClosure>>benchFor:

by Sven Van Caekenberghe

> On 12 Nov 2015, at 10:49, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > But how could Epicea have an impact on that part ? > > That is the question. > > Unless someone objects, I would not say that this should hold integration. There will be much more work to do after integration when people start using it ;-) Unless #benchFor: is broken for everyone, everywhere, of course >> On 12 Nov 2015, at 10:40, Martin Dias <tinchodias(a)gmail.com> wrote: >> >> Hi Sven, >> >> El 12/11/2015 9:32, "Sven Van Caekenberghe" <sven(a)stfx.eu> escribiÃ³: >> Hi Martin, >> >> Here is the relevant issue for the last change in that method: >> >> https://pharo.fogbugz.com/f/cases/14989/Improve-and-simplify-BlockClosure-b… >> >> IIRC the timing change was done in Squeak too, not the BenchmarkResult object. >> >> Maybe the old code is more reliable, thing is, the CI machines being VM's sometimes act very weird with respect to timing and clocks. >> >> Thanks for the pointer, I like the improvements of that slice: using the fork instead of comparing on each run, the new API, the new object to model the benchmark. >> >> Any suggestion of what to do with my problem? If I skip #testBenchFor, then no problem. So, it's the only test in the whole image that presents this problem. >> >> Ah, and this happens locally in my Mac OS too, not only in the CI. >> >> Martin >

Nov. 12, 2015

Re: [Pharo-dev] Never ending BlockClosure>>benchFor:

by Sven Van Caekenberghe

But how could Epicea have an impact on that part ? That is the question. Unless someone objects, I would not say that this should hold integration. There will be much more work to do after integration when people start using it ;-) > On 12 Nov 2015, at 10:40, Martin Dias <tinchodias(a)gmail.com> wrote: > > Hi Sven, > > El 12/11/2015 9:32, "Sven Van Caekenberghe" <sven(a)stfx.eu> escribiÃ³: > Hi Martin, > > Here is the relevant issue for the last change in that method: > > https://pharo.fogbugz.com/f/cases/14989/Improve-and-simplify-BlockClosure-b… > > IIRC the timing change was done in Squeak too, not the BenchmarkResult object. > > Maybe the old code is more reliable, thing is, the CI machines being VM's sometimes act very weird with respect to timing and clocks. > > Thanks for the pointer, I like the improvements of that slice: using the fork instead of comparing on each run, the new API, the new object to model the benchmark. > > Any suggestion of what to do with my problem? If I skip #testBenchFor, then no problem. So, it's the only test in the whole image that presents this problem. > > Ah, and this happens locally in my Mac OS too, not only in the CI. > > Martin

Nov. 12, 2015

Re: [Pharo-dev] Never ending BlockClosure>>benchFor:

by Martin Dias

Hi Sven, El 12/11/2015 9:32, "Sven Van Caekenberghe" <sven(a)stfx.eu> escribiÃ³: > Hi Martin, > > Here is the relevant issue for the last change in that method: > > > https://pharo.fogbugz.com/f/cases/14989/Improve-and-simplify-BlockClosure-b… > > IIRC the timing change was done in Squeak too, not the BenchmarkResult > object. > > Maybe the old code is more reliable, thing is, the CI machines being VM's > sometimes act very weird with respect to timing and clocks. > Thanks for the pointer, I like the improvements of that slice: using the fork instead of comparing on each run, the new API, the new object to model the benchmark. Any suggestion of what to do with my problem? If I skip #testBenchFor, then no problem. So, it's the only test in the whole image that presents this problem. Ah, and this happens locally in my Mac OS too, not only in the CI. Martin

Nov. 12, 2015