April 2014 - Pharo-dev - lists.pharo.org

[pharo-project/pharo-core] 49ea21: 30807

by GitHub

Branch: refs/heads/3.0 Home: https://github.com/pharo-project/pharo-core Commit: 49ea21548b47b26f7dde322c894cad9d32c753e2 https://github.com/pharo-project/pharo-core/commit/49ea21548b47b26f7dde322c… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2014-04-02 (Wed, 02 Apr 2014) Changed paths: M AST-Core.package/RBParser.class/instance/private-parsing/parseStatementList_into_.st M FileSystem-Core.package/FileSystemStore.class/instance/converting/printPath_on_.st M FileSystem-Core.package/Path.class/class/private/absoluteWindowsPathRegex.st A FileSystem-Disk.package/WindowsStore.class/instance/converting/currentDisk.st M FileSystem-Disk.package/WindowsStore.class/instance/converting/pathFromString_.st M FileSystem-Disk.package/WindowsStore.class/instance/converting/printPath_on_.st A FileSystem-Disk.package/WindowsStore.class/instance/converting/stripDrive_.st A FileSystem-Tests-Disk.package/WindowsStoreTest.class/instance/testing/testAbsoluteFullName.st M FileSystem-Tests-Disk.package/WindowsStoreTest.class/instance/testing/testAbsolutePath.st A FileSystem-Tests-Disk.package/WindowsStoreTest.class/instance/testing/testRelativeFullName.st M FileSystem-Tests-Disk.package/WindowsStoreTest.class/instance/testing/testRelativePath.st M Graphics-Display Objects.package/Form.class/instance/scaling%2C rotation/magnifyBy_.st M OpalCompiler-Tests.package/OCCompilerNotifyingTest.class/instance/testing/testExpectedExpressionInBraceArray.st M OpalCompiler-Tests.package/OCCompilerNotifyingTest.class/instance/testing/testExtraneousStatementAfterAReturnInABlock.st M OpalCompiler-Tests.package/OCCompilerNotifyingTest.class/instance/testing/testMissingPeriodSeparatorBetweenStatements.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - scripts/script460.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - updates/update30807.st M ScriptLoader30.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 30807 13065 Windows FileSystem \test\bar not an absolute path https://pharo.fogbugz.com/f/cases/13065 13162 Fix comment of Form>>magnifyBy: https://pharo.fogbugz.com/f/cases/13162 13067 Error message on accept has a typo: End of statement list encounted https://pharo.fogbugz.com/f/cases/13067 13026 IdentitySet>>size reports wrong size https://pharo.fogbugz.com/f/cases/13026 http://files.pharo.org/image/30/30807.zip

April 2, 2014

Re: [Pharo-dev] [Inspiration] Toward a better programming

by Norbert Hartl

Definitely the latterâ¦ Norbert Am 02.04.2014 um 09:11 schrieb Andres Valloud <avalloud(a)smalltalk.comcastbiz.net>: > Hey Doru, I was going to ask "so is that a language or a library?"... > > On 4/1/14 23:12 , Tudor Girba wrote: >> Indeed, I read this article several times over the last couple of days. >> This work is impressive particularly when combined with the cloud part. >> >> The language itself is less interesting for me, but what makes it stand >> out is that it has a coherent and robust philosophy behind and >> phenomenal goals to reach. In Pharo, we have the luxury of building on >> top of coherent and robust philosophy (even if different from the >> Wolfram one) and we should try as much as possible to keep our eyes on >> phenomenal goals that seem unreachable. >> >> Another thing I like in Wolfram's work is attention to details: >> http://blog.wolfram.com/2008/01/10/ten-thousand-hours-of-design-reviews/ >> >> Details are crucial, and all the effort in Pharo around naming and >> redesigning what already exists is incredibly important. But, it is >> precisely at the moment when we are knee-deep in details that is crucial >> to keep our eyes on the phenomenal long term goals. >> >> There is so much to build. Let's be bold. >> >> Doru >> >> >> >> On Tue, Apr 1, 2014 at 7:22 PM, Sven Van Caekenberghe <sven(a)stfx.eu >> <mailto:sven@stfx.eu>> wrote: >> >> >> On 31 Mar 2014, at 06:21, S Krish <krishnamachari.sudhakar(a)gmail.com >> <mailto:krishnamachari.sudhakar@gmail.com>> wrote: >> >> > How about impact of this: >> > >> > >> http://blog.stephenwolfram.com/2014/03/injecting-computation-everywhere-a-s… >> > >> > I would agree it is quite complex for any beginner, but utility >> of a programming language on these lines seems cut out for the future.. >> >> Wow, this is really powerful stuff, a long read, but well worth it. >> By recombining and reusing all their technology they seem to be able >> to move into more and more territory. >> >> It is closed source and (very) expensive, and I don't like the >> syntax, but we sure can get good ideas from them. >> >> Thanks for sharing the link. >> >> Sven >> >> >> >> >> >> -- >> www.tudorgirba.com <http://www.tudorgirba.com> >> >> "Every thing has its own flow" >

April 2, 2014

Re: [Pharo-dev] Strange left-over in 30804

by Marcus Denker

On 02 Apr 2014, at 09:25, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: > Ok, > > doing: > > (RPackageOrganizer default packageNamed: #'FloatArray-dot.st') unregister > Ok, we will do that with the next update. Marcus

April 2, 2014

Re: [Pharo-dev] Strange left-over in 30804

by Goubier Thierry

Ok, doing: (RPackageOrganizer default packageNamed: #'FloatArray-dot.st') unregister removes it. Thierry Le 27/03/2014 16:42, Marcus Denker a Ã©crit : > > On 27 Mar 2014, at 16:31, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: > >> Hi All, >> >> has anybody noticed a strange new RPackage in 30804 named: FloatArray-dot.st ? I can't miss it with AltBrowser, and it's visible in Nautilus, but not in Browser. > > > Strange, I just filed in that .st file when integrating. This should normally not create any packageâ¦. > > Marcus > > -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

April 2, 2014

Re: [Pharo-dev] get.pharo.org scripts don't works on windows?

by Marcus Denker

On 01 Apr 2014, at 18:47, phil(a)highoctane.be wrote: > I guess that this is all linked to files.pharo.org who is not that reliable. > > I am getting errors from http://files.pharo.org/vm/src/lib/ when building the VM for the third party libs. > And also, regular occurences of the problem you describe. > > Can't we get something more solid? > I would like to move the files to Amazon S3. Another idea would be bit torrentâ¦ that would be cool, and would really speed up image download. (and allow people to even gave local feeders and trackersâ¦) Marcus

April 2, 2014

Re: [Pharo-dev] [Inspiration] Toward a better programming

by Andres Valloud

Hey Doru, I was going to ask "so is that a language or a library?"... On 4/1/14 23:12 , Tudor Girba wrote: > Indeed, I read this article several times over the last couple of days. > This work is impressive particularly when combined with the cloud part. > > The language itself is less interesting for me, but what makes it stand > out is that it has a coherent and robust philosophy behind and > phenomenal goals to reach. In Pharo, we have the luxury of building on > top of coherent and robust philosophy (even if different from the > Wolfram one) and we should try as much as possible to keep our eyes on > phenomenal goals that seem unreachable. > > Another thing I like in Wolfram's work is attention to details: > http://blog.wolfram.com/2008/01/10/ten-thousand-hours-of-design-reviews/ > > Details are crucial, and all the effort in Pharo around naming and > redesigning what already exists is incredibly important. But, it is > precisely at the moment when we are knee-deep in details that is crucial > to keep our eyes on the phenomenal long term goals. > > There is so much to build. Let's be bold. > > Doru > > > > On Tue, Apr 1, 2014 at 7:22 PM, Sven Van Caekenberghe <sven(a)stfx.eu > <mailto:sven@stfx.eu>> wrote: > > > On 31 Mar 2014, at 06:21, S Krish <krishnamachari.sudhakar(a)gmail.com > <mailto:krishnamachari.sudhakar@gmail.com>> wrote: > > > How about impact of this: > > > > > http://blog.stephenwolfram.com/2014/03/injecting-computation-everywhere-a-s… > > > > I would agree it is quite complex for any beginner, but utility > of a programming language on these lines seems cut out for the future.. > > Wow, this is really powerful stuff, a long read, but well worth it. > By recombining and reusing all their technology they seem to be able > to move into more and more territory. > > It is closed source and (very) expensive, and I don't like the > syntax, but we sure can get good ideas from them. > > Thanks for sharing the link. > > Sven > > > > > > -- > www.tudorgirba.com <http://www.tudorgirba.com> > > "Every thing has its own flow"

April 2, 2014

Re: [Pharo-dev] FogBugz (Case [Issue]13154) Pharo VM - BitBlt bug in alphaSourceBlendBits8

by Nicolai Hess

2014-04-01 0:31 GMT+02:00 Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com>: > > 2014-03-31 23:58 GMT+02:00 Nicolai Hess <nicolaihess(a)web.de>: > > Thank you Nicolas, >> I verified the fix, it works. >> >> I took nicolas' change and build a windows pharo vm. changing the bit >> depth >> to 8bit littleendian (-8) works now. >> >> > hey, you made the major contribution : find the bug and suggest a > correction! > http://bugs.squeak.org/view.php?id=7247 > > >> But there are two more issues (not related to this fix). >> 1. Changing Display depth to 4/8/16 shows horrible rendering artifacts >> (those do not occur on squeak) >> > > could it be related to issue 13057? > No. At least it is not solved by fixing that. Maybe it is related to the fast bitblitting, but I don't think so, and it is in pharo only. > > >> 2. Since refactoring some parts out of DisplayScreen into >> MorphicUIManager you >> can not change the depth from -XX to XX >> Display newDepth:8 >> has no effect if current display depth is -8. >> (This happens on squeak too, verified in Squeak 4.4/Squeak 4.5). >> >> > Hmm, bad, but certainly not an operation tested everyday :) > > >> >> BTW found this change for alphaSourceBlendBits8 its way into squeaks vm? >> I took the lates 4.5 allinone and the bug is still there. >> >> regards >> >> > It's in both VMMaker and VMMaker.oscog head revisions for sure. > But I don't know which VM was included in the distribution. > Squeak VM production is not as engineered as the Pharo one, I think it's > hand-crafted, and the MacOSX version lacks hands now, so it might be >

April 2, 2014

Re: [Pharo-dev] [Inspiration] Toward a better programming

by Tudor Girba

Indeed, I read this article several times over the last couple of days. This work is impressive particularly when combined with the cloud part. The language itself is less interesting for me, but what makes it stand out is that it has a coherent and robust philosophy behind and phenomenal goals to reach. In Pharo, we have the luxury of building on top of coherent and robust philosophy (even if different from the Wolfram one) and we should try as much as possible to keep our eyes on phenomenal goals that seem unreachable. Another thing I like in Wolfram's work is attention to details: http://blog.wolfram.com/2008/01/10/ten-thousand-hours-of-design-reviews/ Details are crucial, and all the effort in Pharo around naming and redesigning what already exists is incredibly important. But, it is precisely at the moment when we are knee-deep in details that is crucial to keep our eyes on the phenomenal long term goals. There is so much to build. Let's be bold. Doru On Tue, Apr 1, 2014 at 7:22 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > On 31 Mar 2014, at 06:21, S Krish <krishnamachari.sudhakar(a)gmail.com> > wrote: > > > How about impact of this: > > > > > http://blog.stephenwolfram.com/2014/03/injecting-computation-everywhere-a-s… > > > > I would agree it is quite complex for any beginner, but utility of a > programming language on these lines seems cut out for the future.. > > Wow, this is really powerful stuff, a long read, but well worth it. By > recombining and reusing all their technology they seem to be able to move > into more and more territory. > > It is closed source and (very) expensive, and I don't like the syntax, but > we sure can get good ideas from them. > > Thanks for sharing the link. > > Sven > > > -- www.tudorgirba.com "Every thing has its own flow"

April 2, 2014

Re: [Pharo-dev] simulator spotted a small problem with initializing stdout for the CommandLineHandler

by Pharo4Stef

Tx https://pharo.fogbugz.com/default.asp?13165 On 01 Apr 2014, at 19:48, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > Hi Camillo, > > ClÃ©ment and I are simulating Pharo for Sista and I've spotted the following small problem with the BasicCommandLineHandler's use of stdout. It looks like a bug in MultiByteFileStream>wantsLineEndConversion:. BasicCommandLineHandler>>initializeStdout sets stdout's line end conventuion, but in doing so MultiByteFileStream>wantsLineEndConversion: sends MultiByteFileStream>detectLineEndConvention, which is wrong, because stdout is write-only. I needed to change the simulator to fail as the VM does, but perhaps a better fix is not to try and read from write-only streams. Anyway, thought I'd point it out. No biggie. > > 16r101B18 M MultiByteFileStream>detectLineEndConvention 16r1F3A7A0: a(n) MultiByteFileStream > 16r101B38 I MultiByteFileStream>wantsLineEndConversion: 16r1F3A7A0: a(n) MultiByteFileStream > 16r101B60 I BasicCommandLineHandler(CommandLineHandler)>initializeStdout 16r1F3A654: a(n) BasicCommandLineHandler > 16r101B84 I BasicCommandLineHandler(CommandLineHandler)>initialize 16r1F3A654: a(n) BasicCommandLineHandler > 16r101BA4 I BasicCommandLineHandler>initialize 16r1F3A654: a(n) BasicCommandLineHandler > 16r101BBC M BasicCommandLineHandler class(Behavior)>new 16r5B04CC: a(n) BasicCommandLineHandler class > 16r101BD4 M [] in BasicCommandLineHandler class>startUp: 16r5B04CC: a(n) BasicCommandLineHandler class > > -- > best, > Eliot

April 2, 2014

simulator spotted a small problem with initializing stdout for the CommandLineHandler

by Eliot Miranda

Hi Camillo, ClÃ©ment and I are simulating Pharo for Sista and I've spotted the following small problem with the BasicCommandLineHandler's use of stdout. It looks like a bug in MultiByteFileStream>wantsLineEndConversion:. BasicCommandLineHandler>>initializeStdout sets stdout's line end conventuion, but in doing so MultiByteFileStream>wantsLineEndConversion: sends MultiByteFileStream>detectLineEndConvention, which is wrong, because stdout is write-only. I needed to change the simulator to fail as the VM does, but perhaps a better fix is not to try and read from write-only streams. Anyway, thought I'd point it out. No biggie. 16r101B18 M MultiByteFileStream>detectLineEndConvention 16r1F3A7A0: a(n) MultiByteFileStream 16r101B38 I MultiByteFileStream>wantsLineEndConversion: 16r1F3A7A0: a(n) MultiByteFileStream 16r101B60 I BasicCommandLineHandler(CommandLineHandler)>initializeStdout 16r1F3A654: a(n) BasicCommandLineHandler 16r101B84 I BasicCommandLineHandler(CommandLineHandler)>initialize 16r1F3A654: a(n) BasicCommandLineHandler 16r101BA4 I BasicCommandLineHandler>initialize 16r1F3A654: a(n) BasicCommandLineHandler 16r101BBC M BasicCommandLineHandler class(Behavior)>new 16r5B04CC: a(n) BasicCommandLineHandler class 16r101BD4 M [] in BasicCommandLineHandler class>startUp: 16r5B04CC: a(n) BasicCommandLineHandler class -- best, Eliot

April 1, 2014