- Pharo-dev - lists.pharo.org

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

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

by Sven Van Caekenberghe

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

April 1, 2014

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

by Esteban Lorenzano

yes, zeroconf scripts fail in a non-empty folder (with an older vm, bah) Esteban On 01 Apr 2014, at 13:36, Gabriel Cotelli <g.cotelli(a)gmail.com> wrote: > Give it a try on an empty folder... I think that fails if you already have the VM or image. > > > On Tue, Apr 1, 2014 at 12:30 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > (run under mingw sheel) > > curl get.pharo.org/vmLatest | bash > % Total % Received % Xferd Average Speed Time Time Time Current > Dload Upload Total Spent Left Speed > 100 5309 100 5309 0 0 129k 0 --:--:-- --:--:-- --:--:-- 259k > Downloading the latest pharoVM: > http://files.pharo.org/vm/pharo/win/latest.zip > pharo-vm/Pharo.exe > Downloading PharoV10.sources: > http://files.pharo.org/sources//PharoV10.sources.zip > Downloading PharoV20.sources: > http://files.pharo.org/sources//PharoV20.sources.zip > Creating starter scripts pharo and pharo-ui > bash: line 115: pharo: File exists > > -- > Best regards, > Igor Stasenko. >

April 1, 2014

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

by phil＠highoctane.be

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? Phil On Tue, Apr 1, 2014 at 6:29 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > meh... > :( > > as in meh.com > > > On 1 April 2014 17:41, phil(a)highoctane.be <phil(a)highoctane.be> wrote: > >> Works here. >> >> >> User@Techlab ~/Experiments/igor >> $ curl get.pharo.org/vmLatest | bash >> % Total % Received % Xferd Average Speed Time Time Time >> Current >> Dload Upload Total Spent Left >> Speed >> 100 5309 100 5309 0 0 13612 0 --:--:-- --:--:-- --:--:-- >> 13612 >> Downloading the latest pharoVM: >> http://files.pharo.org/vm/pharo/win/latest.zip >> pharo-vm/Pharo.exe >> Downloading PharoV10.sources: >> http://files.pharo.org/sources//PharoV10.sources.zip >> Downloading PharoV20.sources: >> http://files.pharo.org/sources//PharoV20.sources.zip >> Creating starter scripts pharo and pharo-ui >> >> On Tue, Apr 1, 2014 at 5:30 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >> >>> (run under mingw sheel) >>> >>> curl get.pharo.org/vmLatest | bash >>> % Total % Received % Xferd Average Speed Time Time Time >>> Current >>> Dload Upload Total Spent Left >>> Speed >>> 100 5309 100 5309 0 0 129k 0 --:--:-- --:--:-- >>> --:--:-- 259k >>> Downloading the latest pharoVM: >>> http://files.pharo.org/vm/pharo/win/latest.zip >>> pharo-vm/Pharo.exe >>> Downloading PharoV10.sources: >>> http://files.pharo.org/sources//PharoV10.sources.zip >>> Downloading PharoV20.sources: >>> http://files.pharo.org/sources//PharoV20.sources.zip >>> Creating starter scripts pharo and pharo-ui >>> bash: line 115: pharo: File exists >>> >>> -- >>> Best regards, >>> Igor Stasenko. >>> >> >> > > > -- > Best regards, > Igor Stasenko. >

April 1, 2014