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

Smalltalk Reflections Podcast

by davidbuck

Craig Latta and I have started up a new weekly podcast called Smalltalk Reflections. The web side is http://smalltalkreflections.blogspot.ca/ and it's available from iTunes. We would like to ask the Pharo community if anyone would be interested in participating to promote Smalltalk or Pharo. We'd love to be able to interview people from the Pharo community. Also if anyone would like to take on the task of recording a weekly Pharo insert we'd love to have that as well. If weekly is too frequent for you, we can also arrange monthly or whenever you have time. If you're interested in participating in any way, drop me a line at david(a)simberon.com. Thanks -- View this message in context: http://forum.world.st/Smalltalk-Reflections-Podcast-tp4797444.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Dec. 30, 2014

Re: [Pharo-dev] Jun4Pharo so exciting :)

by kilon alios

Is this a real concern ? Afterall vector data is a lot less complex than 3d geometry and CPUs nowdays are multicore. Don't know about the Opengl backend of Cairo. Igor also once shown me a Spec for vector graphics on OpenGL by Khronos Group. So there are alternatives but as always it will require someone doing the hard work to bring that functionality to Pharo. Newest OpenGL versions also come with dynamic tesselation geometry shaders that basically increase the detail of a 3d object the closer a camera gets to it which is similar to vector graphics which is something that could also work as basic via NBOpenGL to bring Athens to 3d side completely bypassing Cairo. On Tue, Dec 30, 2014 at 9:18 PM, Ronie Salgado <roniesalg(a)gmail.com> wrote: > Athens uses Cairo , Cairo can be used with OpenGL. You can use Cairo to >> apply a 2d vector graphic as a texture to a 3d polygon. Cairo website shows >> several examples of this. That means its possible to have 2d vector >> graphics in 3d space as if its true 3d. >> > I do not think that is going to work easily with the best performance > possible. Cairo could be using OpenGL, but probably in a different OpenGL > than the one that is being used for 3d graphics. > > In addition, the Cairo OpenGL backend is experimental ( > http://cairographics.org/OpenGL/) . Currently you have to render into a > surface in CPU, then transfer it into GPU and then render the polygon. A > naive version using the OpenGL backend is going to have GPU->CPU->GPU > roundtrip > > If we are using this route, I think that is better to just use the current > version of Athens for this. With Athens we can render into a Form, which > can be used to populate a Woden/Roassal texture or transferred directly to > OpenGL. This has the advantage of not having a explicit dependency in > Cairo. I guess that I will make a demo of this later. It should be easy. > > I think that a longer term approach could be having a custom renderer, > tailored for Athens using OpenGL or maybe OpenCL. > > 2D vector graphics are really hard. In my opinion they are harder than 3d > graphics because of concave self intersecting paths. Stroking a path can be > really hard because of thins such as tapering. > > The 3D hardware is designed to draw efficiently points, lines and > triangles. All of them are simple convex polygon. Most of the 2D vector > engines such as Cairo are software renderer, scanliners to be more > specific. The old cairo opengl backend had to tessellate the paths > > Later I am going to take a better look in Jun. And see how I can integrate > with Woden/Woden-Roassal. For what I have seen in the videos, it seems to > be using software rendering. Currently I have been working in my internship > about volumetric data visualization and the new FFI. > > 2014-12-30 11:01 GMT-03:00 kilon alios <kilon.alios(a)gmail.com>: > > Athens uses Cairo , Cairo can be used with OpenGL. You can use Cairo to >> apply a 2d vector graphic as a texture to a 3d polygon. Cairo website shows >> several examples of this. That means its possible to have 2d vector >> graphics in 3d space as if its true 3d. >> >> On Tue, Dec 30, 2014 at 12:10 AM, stepharo <stepharo(a)free.fr> wrote: >> >>> Sven >>> >>> Jun is a 3D frameworks developed in 1998 in VisualWorks >>> http://aokilab.kyoto-su.ac.jp/jun/index.html >>> It was quite advanced and this is nice to get more people doing 3d in >>> Pharo. >>> They are using the back -end developed by ronie and JB and this is cool >>> >>> Athens is just a canvas and a oo decomposition of the canvas, brush and >>> strokes >>> nothing related to 3D. >>> Stef >>> >>> >>> Le 29/12/14 20:20, Sven Van Caekenberghe a Ã©crit : >>> >>> On 29 Dec 2014, at 15:36, stepharo <stepharo(a)free.fr> wrote: >>>>> >>>>> https://www.youtube.com/watch?v=sH_P5otiWJM&feature=youtu.be >>>>> >>>> It certainly looks nice, but what is Jun exactly ? >>>> >>>> >>>> >>> >>> >> >

Dec. 30, 2014

Re: [Pharo-dev] Jun4Pharo so exciting :)

by Ronie Salgado

> > Athens uses Cairo , Cairo can be used with OpenGL. You can use Cairo to > apply a 2d vector graphic as a texture to a 3d polygon. Cairo website shows > several examples of this. That means its possible to have 2d vector > graphics in 3d space as if its true 3d. > I do not think that is going to work easily with the best performance possible. Cairo could be using OpenGL, but probably in a different OpenGL than the one that is being used for 3d graphics. In addition, the Cairo OpenGL backend is experimental ( http://cairographics.org/OpenGL/) . Currently you have to render into a surface in CPU, then transfer it into GPU and then render the polygon. A naive version using the OpenGL backend is going to have GPU->CPU->GPU roundtrip If we are using this route, I think that is better to just use the current version of Athens for this. With Athens we can render into a Form, which can be used to populate a Woden/Roassal texture or transferred directly to OpenGL. This has the advantage of not having a explicit dependency in Cairo. I guess that I will make a demo of this later. It should be easy. I think that a longer term approach could be having a custom renderer, tailored for Athens using OpenGL or maybe OpenCL. 2D vector graphics are really hard. In my opinion they are harder than 3d graphics because of concave self intersecting paths. Stroking a path can be really hard because of thins such as tapering. The 3D hardware is designed to draw efficiently points, lines and triangles. All of them are simple convex polygon. Most of the 2D vector engines such as Cairo are software renderer, scanliners to be more specific. The old cairo opengl backend had to tessellate the paths Later I am going to take a better look in Jun. And see how I can integrate with Woden/Woden-Roassal. For what I have seen in the videos, it seems to be using software rendering. Currently I have been working in my internship about volumetric data visualization and the new FFI. 2014-12-30 11:01 GMT-03:00 kilon alios <kilon.alios(a)gmail.com>: > Athens uses Cairo , Cairo can be used with OpenGL. You can use Cairo to > apply a 2d vector graphic as a texture to a 3d polygon. Cairo website shows > several examples of this. That means its possible to have 2d vector > graphics in 3d space as if its true 3d. > > On Tue, Dec 30, 2014 at 12:10 AM, stepharo <stepharo(a)free.fr> wrote: > >> Sven >> >> Jun is a 3D frameworks developed in 1998 in VisualWorks >> http://aokilab.kyoto-su.ac.jp/jun/index.html >> It was quite advanced and this is nice to get more people doing 3d in >> Pharo. >> They are using the back -end developed by ronie and JB and this is cool >> >> Athens is just a canvas and a oo decomposition of the canvas, brush and >> strokes >> nothing related to 3D. >> Stef >> >> >> Le 29/12/14 20:20, Sven Van Caekenberghe a Ã©crit : >> >> On 29 Dec 2014, at 15:36, stepharo <stepharo(a)free.fr> wrote: >>>> >>>> https://www.youtube.com/watch?v=sH_P5otiWJM&feature=youtu.be >>>> >>> It certainly looks nice, but what is Jun exactly ? >>> >>> >>> >> >> >

Dec. 30, 2014

Re: [Pharo-dev] Can a hash be negative ?

by Nicolas Cellier

2014-12-30 18:53 GMT+01:00 ClÃ©ment Bera <bera.clement(a)gmail.com>: > > > 2014-12-30 17:14 GMT+01:00 phil(a)highoctane.be <phil(a)highoctane.be>: > >> >> Le 30 dÃ©c. 2014 13:13, "ClÃ©ment Bera" <bera.clement(a)gmail.com> a Ã©crit : >> > >> > Hello Pharoers, >> > >> > I was wondering, is it a good practice to have negative hashes ? >> > >> > Based on the class comment of Object>>#hash >> > >> > "Answer a SmallInteger whose value is related to the receiver's >> identity. [...]" >> > >> > The hash is a smallInteger and therefore can be negative. >> >> Why would this be a poor practice if seen as a set of bits? >> >> As long as it does its job for identifying buckets, it looks okay to me. >> >> More bits with good spreading is more space for the hashes. >> >> Now hash should be redefined along with equals if we run into large sets >> to limit collisions. And I guess we wouldn't keep SmallInteger then. >> >> Why the question? >> > > Well I am fixing compiled method to support negative compiled method > header and the compiled method hash may now be negative if its compiled > method header is. That's why. > > > But -1 hash -> -1 already, so I don't see any problem... Nicolas > Phil >> >> > >> > Thanks for any answer. >> > >> > Clement >> > >

Dec. 30, 2014

[pharo-project/pharo-core]

by GitHub

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

Dec. 30, 2014

[pharo-project/pharo-core] 2b60f1: 40426

by GitHub

Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: 2b60f1eeac13a27a0dca245f6ab1180b27c051c2 https://github.com/pharo-project/pharo-core/commit/2b60f1eeac13a27a0dca245f… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2014-12-30 (Tue, 30 Dec 2014) Changed paths: M Kernel.package/CompiledMethod.class/instance/accessing/clearFlag.st M Kernel.package/CompiledMethod.class/instance/accessing/flag.st M Kernel.package/CompiledMethod.class/instance/accessing/frameSize.st M Kernel.package/CompiledMethod.class/instance/accessing/numArgs.st M Kernel.package/CompiledMethod.class/instance/accessing/numLiterals.st M Kernel.package/CompiledMethod.class/instance/accessing/numTemps.st M Kernel.package/CompiledMethod.class/instance/accessing/primitive.st A Kernel.package/CompiledMethod.class/instance/debugger support/prepareForSimulationWith_.st M Kernel.package/CompiledMethod.class/instance/initialize-release/needsFrameSize_.st A Kernel.package/CompiledMethod.class/instance/initialize-release/setFrameBit_.st A Kernel.package/CompiledMethod.class/instance/literals/absoluteHeader.st M Kernel.package/CompiledMethod.class/instance/literals/headerDescription.st R Kernel.package/Context.class/instance/private/setNumArgs_toMethod_.st M Kernel.package/Context.class/instance/private/withoutPrimitiveTryNamedPrimitiveIn_for_withArgs_.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script426.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40426.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 40426 14664 CompiledMethod and Context API should support negative compiled method header https://pharo.fogbugz.com/f/cases/14664 http://files.pharo.org/image/40/40426.zip

Dec. 30, 2014

Re: [Pharo-dev] Can a hash be negative ?

by ClÃ©ment Bera

2014-12-30 17:14 GMT+01:00 phil(a)highoctane.be <phil(a)highoctane.be>: > > Le 30 dÃ©c. 2014 13:13, "ClÃ©ment Bera" <bera.clement(a)gmail.com> a Ã©crit : > > > > Hello Pharoers, > > > > I was wondering, is it a good practice to have negative hashes ? > > > > Based on the class comment of Object>>#hash > > > > "Answer a SmallInteger whose value is related to the receiver's > identity. [...]" > > > > The hash is a smallInteger and therefore can be negative. > > Why would this be a poor practice if seen as a set of bits? > > As long as it does its job for identifying buckets, it looks okay to me. > > More bits with good spreading is more space for the hashes. > > Now hash should be redefined along with equals if we run into large sets > to limit collisions. And I guess we wouldn't keep SmallInteger then. > > Why the question? > Well I am fixing compiled method to support negative compiled method header and the compiled method hash may now be negative if its compiled method header is. That's why. Phil > > > > > Thanks for any answer. > > > > Clement >

Dec. 30, 2014

Re: [Pharo-dev] The Smalltalk Renaissance Program

by horrido

BTW, you missed another key point: My Google+ page (and my Facebook page) is *part of a branding effort* for Smalltalk, and Smalltalk Renaissance. Thus, the Pharo Project Google+ page is of little value to me. I'm truly astonished that you didn't understand that. Marcus Denker-4 wrote >> On 30 Dec 2014, at 14:45, Marcus Denker < > marcus.denker@ > > wrote:of course it needs a genius like you do set up a google plus > account: > > http://google.com/+Pharo-projectOrg > > Marcus -- View this message in context: http://forum.world.st/The-Smalltalk-Renaissance-Program-tp4797112p4797425.h… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Dec. 30, 2014

Re: [Pharo-dev] Can a hash be negative ?

by phil＠highoctane.be

Le 30 dÃ©c. 2014 13:13, "ClÃ©ment Bera" <bera.clement(a)gmail.com> a Ã©crit : > > Hello Pharoers, > > I was wondering, is it a good practice to have negative hashes ? > > Based on the class comment of Object>>#hash > > "Answer a SmallInteger whose value is related to the receiver's identity. [...]" > > The hash is a smallInteger and therefore can be negative. Why would this be a poor practice if seen as a set of bits? As long as it does its job for identifying buckets, it looks okay to me. More bits with good spreading is more space for the hashes. Now hash should be redefined along with equals if we run into large sets to limit collisions. And I guess we wouldn't keep SmallInteger then. Why the question? Phil > > Thanks for any answer. > > Clement

Dec. 30, 2014

Re: [Pharo-dev] The Smalltalk Renaissance Program

by horrido

Thank you very much. So please explain how the PR message is not aligned with the technical vision. I don't see any inconsistency. Ben Coman wrote > On Wednesday, December 31, 2014, Ben Coman wrote: > >> >> >> On Wednesday, December 31, 2014, horrido < > horrido.hobbies@ > > <javascript:_e(%7B%7D,'cvml',' > horrido.hobbies@ > ');>> wrote: >> >>> And, yes, I did not do my most thorough homework regarding Pharo, as >>> several >>> of you have pointed out. Frankly, I don't have /that/ much time and >>> energy. >>> I'm old and retired. I'm just doing this for pleasure. >>> >>> So I rely on /you/ to set me straight. >> >> >> In process :) >> >> >>> I remind you that I'm just the >>> coordinator of the campaign, because I'm sure none of you have that much >>> time to do what I'm doing. >> >> >> >> >> >>> >>> Marcus suggested that anyone can create a Google+ page, but he misses >>> the >>> point. The Google+ page is just one brick in the foundation of the >>> campaign. >>> It's part of a whole. >>> >>> Norbert suggests that I think I know what to do. No, I have ideas and I >>> have >>> a plan. There's no guarantee that it will work. Either you buy into my >>> plan, >>> or you don't. Either I have your support, or I don't. If the latter, I >>> shan't waste any more time (yours or mind). >>> >>> >> >> It's not just a matter of time, but inclination. If you are inclined to >>> do this, then it should be supported - but it's a matter of getting the >>> PR message aligned with the technical vision. We don't want the market >>> being told one thing then getting a different message here in-list. So >>> you made a misstep here. That's okay, you learn more that way than doing >>> nothing. It may take some more back-n-forth. I hope you continue. >> >> >> -Ben >> >> -- View this message in context: http://forum.world.st/The-Smalltalk-Renaissance-Program-tp4797112p4797416.h… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Dec. 30, 2014