- Pharo-users - lists.pharo.org

Re: [Pharo-users] Pharo Consortium New Gold Member: Thales

by Esteban Lorenzano

can you try to do it using chrome or firefox? (Iâm trying to determine if this is an âold time bugâ I sawâ¦) (this sites -association, consortium- need some serious work, Iâm afraidâ¦ and no time right now :( ) cheers, Esteban > On 01 Dec 2015, at 01:14, John Pfersich <jpfersich(a)gmail.com> wrote: > > I have tried to join the association in the past, but I get an error message every time I try. See the attached picture to see the result. > > <image1.PNG> > > Sent from my iPad > >> On Nov 30, 2015, at 03:27, Tudor Girba <tudor(a)tudorgirba.com> wrote: >> >> Great news! >> >> For everyone not directly involved in the Consortium: >> The money collected from memberships go towards the infrastructure of Pharo in form of engineering time. This is a key effort to make Pharo a sustainable platform for the long run. >> >> That is why these pieces of news are so important. >> >> Doru >> >> >>> On Nov 26, 2015, at 2:42 PM, marcus.denker(a)inria.fr wrote: >>> >>> The Pharo Consortium is very happy to announce that Thales >>> has joined the Consortium as an Gold Member. >>> >>> About >>> - Thales: https://www.thalesgroup.com >>> - Pharo Consortium: http://consortium.pharo.org >>> >>> The goal of the Pharo Consortium is to allow companies and institutions to >>> support the ongoing development and future of Pharo. >>> >>> Individuals can support Pharo via the Pharo Association: >>> >>> http://association.pharo.org >>> >> >> -- >> www.tudorgirba.com >> >> "Value is always contextual." >> >> >> >>

Dec. 1, 2015

Re: [Pharo-users] [Pharo-dev] Machine Learning algorithms

by serge.stinckwich＠gmail.com

Great initiative Klerisson ! This is better to talk on the pharo-users I guess. There is a project called SciSmalltalk where a lot of mathematics libraries are already available that might be useful for ML algorithms. Please join us on https://github.com/SergeStinckwich/SciSmalltalk Mailing list here: https://groups.google.com/forum/m/#!forum/scismalltalk Regards Sent from my iPhone > On 1 dÃ©c. 2015, at 00:08, KlÃ©risson PaixÃ£o <klerissonpaixao(a)gmail.com> wrote: > > Greetings! > > We're thinking to power up Pharo with some machine learning algorithms (Naive Bayes, Random Forest and so on). I'm wondering if there is anything done already? > > Thanks, > KlÃ©risson

Dec. 1, 2015

Re: [Pharo-users] Pharo for Data Visualization

by Volkert

That is cool. Thank you ... BW, Volkert On 01.12.2015 01:25, Ronie Salgado wrote: > Hello, > > I added a fallback method for the selection, so the missing extension > should not be required. The following script should work in a playground. > > =========================================================== > > view := RWView new. > elements := RWCube elementsOn: (1 to: 50). > RWCubeLayout on: elements. > elements do: [:el | > el when: RWMouseButtonDown do: [ :ev | > ev element color: WDColor red. > ev element changed. > ] > ]. > > view addAll: elements. > view addInteraction: RWMouseKeyControl. > view open > > ============================================================ > I tested it on: > > glxinfo > OpenGL vendor string: Intel Open Source Technology Center > OpenGL renderer string: Mesa DRI Intel(R) Ivybridge Mobile > > cat /proc/cpuinfo > model name : Intel(R) Core(TM) i5-3230M CPU @ 2.60GHz > > Best regards, > Ronie > > 2015-11-29 3:33 GMT-03:00 Ben Coman <btc(a)openinworld.com > <mailto:btc@openinworld.com>>: > > Interesting stuff Ronie. Hopefully we'll gain a lot in > portability with Vulkan. What I find interesting is the use of > Standard Portable Intermediate Representation (SPIR) common to > Vulkan graphics API and OpenCL compute API. [1] is an interesting > article outlining this. [2] indicates a few programming languages > will compile direct to SPIR and I wonder if Pharo might be able to > do the same? New technologies (SPIR) => new opportunities to draw > the curious to Pharo. Wild speculation... be able to debug a > shader on a SPIR simulator running inside Pharo. > > (btw, apparently SPIR is pronounced "spear" not to be confused > with our "spur" vm) > > [2] p39,40 says "Debug information via standardized API calls" and > "Khronos encouraging open community of tools e.g. shader > debugging" which may provide an opportunity to produce a shader > debugging tool for use by individual developers in a corporate > environment that constrains their language choice for the main > application, but have more flexibility to choice their tools. So > potentially once exposed to Pharo we hook some of them. Maybe > interesting debugging info could be gathered that could be > presented by Roassal. > > [3] p4 says "SPIR-V is fully set up to support multiple source > languages" and "SPIR-V also enables development of new > experimental languages" and [4] says "Enable third-party code > generation targeting OpenCL platforms without going through OpenCL > C." So maybe(?) this makes it easier to get fast computing within > Pharo using more of our own tools? > > [1] > http://www.pcper.com/reviews/General-Tech/GDC-15-What-Vulkan-glNext-SPIR-V-… > [2] > https://www.khronos.org/assets/uploads/developers/library/2015-sigasia/SIGG… > [3] https://www.khronos.org/registry/spir-v/papers/WhitePaper.pdf > [4] https://www.khronos.org/faq/spir > > cheers -ben > > On Sun, Nov 29, 2015 at 6:13 AM, Ronie Salgado > <roniesalg(a)gmail.com <mailto:roniesalg@gmail.com>> wrote: > > Hi Stef, > > I think that this is important that people can pick > different ("compatible") driver/framework back-end. > You see if Woden is only built to work on something that > does not run on mac or windows then > it will be limited. > > The problem is not Window or Mac. The problem is Linux. > > We are having some discussion on this with Alex on this. I am > going to try to remove the requirement on that extension by > providing a fallback method for the selection, that does not > require that extension. Then I will test it in my laptop by > selecting the Intel driver (My laptop has the integrated Intel > card in the CPU and a dedicated AMD graphics cards). > > However Woden-Roassal relies a lot on hardware instancing > support to be able to draw a lot of dynamic cubes. The > alternative is to use a vertex buffer and index buffer that > holds all of the transformed visible geometry that is updated > on each frame in the worst case scenario. In the best case > scenario (static cubes or objects), they are updated only > once. This relies a lot on the CPU because all of the > transformations has to be done manually on the CPU. > > This is not a hardware problem, this is a drivers problem > because OpenGL is huge, complex, unefficient, does not > represent the graphics hardware. The Mesa Open Source guys are > not able to keep pace with the extension hell known as OpenGL. > In Ubuntu 14.04 Mesa supports up until OpenGL 3.0 > compatibility profile, and OpenGL 3.1 core profile. The > current version of OpenGL is 4.5. Each version of OpenGL has a > different version of GLSL (OpenGL Shader Language), which > makes harder to stick with one reasonable subset and then > support features depending on which hardware you are running. > In contrast, if you are developing for Direct3D in Windows, > you only need to choose between Direct3D 9(Windows XP), > 11(Vista I think/7/8), 12(Windows 10) and thats it. In > Direct3D you do not have to deal with hardware vendor > extensions because there are not extensions. > > By using instancing, I have a buffer with the geometry of a > single cube or shape. Then I have another buffer with the > transformation and color of each cube or simple shape. When > updating the position, size or color of an element I only have > to change a single entry in this buffer. > > The original Roassal 3D used a draw call per element. This > more flexible, but a lot slower. 20.000 cubes in Roassal3D vs > 300.000-600.000 in Woden-Roassal visibles at the same time. > The overhead of a draw call is produced because some > validations are made by the OpenGL driver for each draw call. > > A draw call per-element is only reasonable when using Direct3D > 12(Window), Metal(iOS, OS X) or Vulkan (Linux, Windows and > mobiles) because there are designed to remove the overhead of > draw calls. This is the approach that I am going to use in > Woden 2 via an abstraction layer that I am making in C/C++ > above the graphics API. Currently I have a backend for > Direct3D 12 and OpenGL 4.x (it should be possible to use > OpenGL 3.3, but I need to test it). I made the OpenGL backend > because Vulkan has not been released yet. It is impossible to > get the best performance by using the OpenGL backend because > of its design. In theory it should be possible to make a > backend for OpenGL 2.0 and OpenGL 2.0 ES, but it will be > really hard to do. And it will not have a good performance. > > Greetings, > Ronie > > > 2015-11-28 14:41 GMT-03:00 stepharo <stepharo(a)free.fr > <mailto:stepharo@free.fr>>: > > Ronie > > I think that this is important that people can pick > different ("compatible") driver/framework back-end. > You see if Woden is only built to work on something that > does not run on mac or windows then > it will be limited. > > Stef > > Le 25/11/15 00:14, Ronie Salgado a Ã©crit : >> >> What do you mean with "modern"? >> >> By modern I mean a graphics card a with graphics driver >> that supports at least OpenGL 4.x. That Intel HD graphics >> card is capable of supporting at least OpenGL 4.2, but >> the Open Source Mesa driver gives you support up until >> OpenGL 3.1. Unfortunately, unlike with AMD or NVIDIA >> graphics cards, the open source driver is the official >> driver. >> >> Woden-Roassal requires integer arithmetic in shaders >> which is used to support the selection of objects. >> Integer arithmetics in shaders requires at least OpenGL >> 3.3, or the missing extension for which you are receiving >> the error. >> >> It is not required by the Woden-Core api, so you should >> be able to try the following in a workspace: >> >> WDFPSSimpleExample6 new open >> >> My notebook with an HD Graphics 4400 has no problems >> with all "three.js" demos found here http://threejs.org/. >> >> Three.js or any WebGL based example is a bad test for >> that graphics card. WebGL is based in OpenGL ES 2.0 which >> is a subset of OpenGL 2.0. This is a very old technology >> for that graphics card. >> >> Woden will be using Vulkan in the future. According to >> this Phoronix article >> (http://www.phoronix.com/scan.php?page=news_item&px=LunarG-Vulkan-AMA) >> Valve has already made a proper Vulkan driver for the >> Intel graphics cards. We only need an official release of >> the Vulkan spec. >> >> Best regards >> Ronie >> >> 2015-11-24 18:50 GMT-03:00 Volkert >> <volkert(a)komponentenwerkstatt.de >> <mailto:volkert@komponentenwerkstatt.de>>: >> >> My notebook with an HD Graphics 4400 has no problems >> with all "three.js" demos found here >> http://threejs.org/. >> >> What do you mean with "modern"? >> >> >> >> On 24.11.2015 22:25, Ronie Salgado wrote: >>> You need a modern graphics card. Open source >>> graphics drivers are not supported because there are >>> very behind in their implementations of OpenGL. >>> >>> >>> 2015-11-24 17:28 GMT-03:00 Volkert >>> <volkert(a)komponentenwerkstatt.de >>> <mailto:volkert@komponentenwerkstatt.de>>: >>> >>> But not on my linux box .... ubuntu 14.04 :-( >>> >>> >>> >>> >>> On 24.11.2015 21:03, Alexandre Bergel wrote: >>>> Woden works in Pharo 5.0 >>>> I have just tried. >>>> >>>> Alexandre >>>> -- >>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>> Alexandre Bergel http://www.bergel.eu >>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>> >>>> >>>> >>>>> On Nov 24, 2015, at 3:15 PM, Volkert >>>>> <volkert(a)komponentenwerkstatt.de >>>>> <mailto:volkert@komponentenwerkstatt.de>> wrote: >>>>> >>>>> Cool ... >>>>> >>>>> Which Pharo Version? I tried Pharo 4.0 and got >>>>> this error: >>>>> >>>>> <edcefcdd.png> >>>>> >>>>> >>>>> On 24.11.2015 12:50, Alexandre Bergel wrote: >>>>>>> Do we have a tutorial? i found only >>>>>>> http://woden.ronie.cl. >>>>>>> >>>>>>> What about mouse control and object >>>>>>> selection. It that possible? >>>>>> >>>>>> Yes. >>>>>> >>>>>> To load Woden: >>>>>> >>>>>> Gofer new smalltalkhubUser: 'ronsaldo' >>>>>> project: 'Woden'; package: >>>>>> 'ConfigurationOfWoden'; load. (Smalltalk at: >>>>>> #ConfigurationOfWoden) loadBleedingEdge. >>>>>> >>>>>> Try: >>>>>> =-=-=-==-=-=-==-=-=-==-=-=-= >>>>>> v := RWView new. >>>>>> >>>>>> 1 to: 100 do: [ :i | >>>>>> e := RWCube element. >>>>>> e when: RWMouseButtonDown do: [ :ev | >>>>>> ev element shape color: WDColor green. >>>>>> ev element changed. >>>>>> ]. >>>>>> v add: e. >>>>>> ]. >>>>>> RWXZGridLayout on: v elements. >>>>>> v addInteraction: RWMouseKeyControl. >>>>>> v camera position: (WDVector3 x: 0.0 y: 0.0 >>>>>> z: 3.0). >>>>>> v open >>>>>> =-=-=-==-=-=-==-=-=-==-=-=-= >>>>>> Use the keys A S D W and the moose to >>>>>> navigate. Click on cube to make them green >>>>>> >>>>>> <Mail Attachment.png> >>>>>> >>>>>> Cheers, >>>>>> Alexandre >>>>>> >>>>>> >>>>>> >>>>>>> >>>>>>> BW, >>>>>>> Volkert >>>>>>> >>>>>>> On 22.11.2015 21:10, Alexandre Bergel wrote: >>>>>>>> We have also put quite some effort on >>>>>>>> Woden, a 3d engine for Pharoâ¦ >>>>>>>> >>>>>>>> Cheers, >>>>>>>> Alexandre >>>>>>>> >>>>>>>> >>>>>>>>> On Nov 22, 2015, at 2:56 PM, Dimitris >>>>>>>>> Chloupis <kilon.alios(a)gmail.com >>>>>>>>> <mailto:kilon.alios@gmail.com>> wrote: >>>>>>>>> >>>>>>>>> its possible via my Ephestos project, to >>>>>>>>> render to video or real time but the >>>>>>>>> project is still very much a WIP. Its >>>>>>>>> doable but require some python knowledge >>>>>>>>> and knowledge of Blender UI and API. I >>>>>>>>> will be making a true Pharo API for it >>>>>>>>> fairly soon but as you can imagine these >>>>>>>>> things take time. >>>>>>>>> >>>>>>>>> On Sun, Nov 22, 2015 at 6:35 PM Volkert >>>>>>>>> <volkert(a)komponentenwerkstatt.de >>>>>>>>> <mailto:volkert@komponentenwerkstatt.de>> >>>>>>>>> wrote: >>>>>>>>> Is this possible with Pharo? >>>>>>>>> >>>>>>>>> http://www.asterank.com/3d/ >>>>>>>>> >>>>>>>>> BW, >>>>>>>>> Volkert >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >>> >> >> > > > >

Dec. 1, 2015

Re: [Pharo-users] [ANN] breakpoints and watchpoints working

by Ben Coman

On Tue, Dec 1, 2015 at 4:32 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > >> >>>> but a problem you could be aware is setting a break once in InputEventFetcher>>signalEvent: , and then moving the mouse, the image hangs. >>>> >>> Thanks, we will investigate. The âonceâ breakpoint triggers a recompile before opening the debugger. >>> but of course the devil is in the detailsâ¦ we will check to see what exactly is happening here. >>> >> >> I think I understand what happens: the method is called because there is an interrupt. Check for interrupt happens on all message sends >> ==> even though we *want* to recompile before calling the method again, the check for interrupt happens and it is called again before the new >> method is installed. > > Hmm.. I think it could be fixed by changing priorities of running threads: if we lover (temporarily) the input-event fetcher priority and raise > the thread that does the compiling/installing, maybe we can make sure that the signalEvent: is not called before the break is removedâ¦ I speculate that changing the priority of input-event fetcher would have more impact than just raising the installing thread above it, but then I guess the DelayScheduler timing-priority event loop will be susceptible to the same problem. Maybe the final part of the install needs to be done with a primitive like #become: ? cheers -ben

Dec. 1, 2015

Re: [Pharo-users] Pharo for Data Visualization

by Ronie Salgado

Hello, I added a fallback method for the selection, so the missing extension should not be required. The following script should work in a playground. =========================================================== view := RWView new. elements := RWCube elementsOn: (1 to: 50). RWCubeLayout on: elements. elements do: [:el | el when: RWMouseButtonDown do: [ :ev | ev element color: WDColor red. ev element changed. ] ]. view addAll: elements. view addInteraction: RWMouseKeyControl. view open ============================================================ I tested it on: glxinfo OpenGL vendor string: Intel Open Source Technology Center OpenGL renderer string: Mesa DRI Intel(R) Ivybridge Mobile cat /proc/cpuinfo model name : Intel(R) Core(TM) i5-3230M CPU @ 2.60GHz Best regards, Ronie 2015-11-29 3:33 GMT-03:00 Ben Coman <btc(a)openinworld.com>: > Interesting stuff Ronie. Hopefully we'll gain a lot in portability with > Vulkan. What I find interesting is the use of Standard Portable > Intermediate Representation (SPIR) common to Vulkan graphics API and OpenCL > compute API. [1] is an interesting article outlining this. [2] indicates > a few programming languages will compile direct to SPIR and I wonder if > Pharo might be able to do the same? New technologies (SPIR) => new > opportunities to draw the curious to Pharo. Wild speculation... be able to > debug a shader on a SPIR simulator running inside Pharo. > > (btw, apparently SPIR is pronounced "spear" not to be confused with our > "spur" vm) > > [2] p39,40 says "Debug information via standardized API calls" and > "Khronos encouraging open community of tools e.g. shader debugging" which > may provide an opportunity to produce a shader debugging tool for use by > individual developers in a corporate environment that constrains their > language choice for the main application, but have more flexibility to > choice their tools. So potentially once exposed to Pharo we hook some of > them. Maybe interesting debugging info could be gathered that could be > presented by Roassal. > > [3] p4 says "SPIR-V is fully set up to support multiple source languages" > and "SPIR-V also enables development of new experimental languages" and [4] > says "Enable third-party code generation targeting OpenCL platforms without > going through OpenCL C." So maybe(?) this makes it easier to get fast > computing within Pharo using more of our own tools? > > [1] > http://www.pcper.com/reviews/General-Tech/GDC-15-What-Vulkan-glNext-SPIR-V-… > [2] > https://www.khronos.org/assets/uploads/developers/library/2015-sigasia/SIGG… > [3] https://www.khronos.org/registry/spir-v/papers/WhitePaper.pdf > [4] https://www.khronos.org/faq/spir > > cheers -ben > > On Sun, Nov 29, 2015 at 6:13 AM, Ronie Salgado <roniesalg(a)gmail.com> > wrote: > >> Hi Stef, >> >> I think that this is important that people can pick different >>> ("compatible") driver/framework back-end. >>> You see if Woden is only built to work on something that does not run on >>> mac or windows then >>> it will be limited. >> >> The problem is not Window or Mac. The problem is Linux. >> >> We are having some discussion on this with Alex on this. I am going to >> try to remove the requirement on that extension by providing a fallback >> method for the selection, that does not require that extension. Then I will >> test it in my laptop by selecting the Intel driver (My laptop has the >> integrated Intel card in the CPU and a dedicated AMD graphics cards). >> >> However Woden-Roassal relies a lot on hardware instancing support to be >> able to draw a lot of dynamic cubes. The alternative is to use a vertex >> buffer and index buffer that holds all of the transformed visible geometry >> that is updated on each frame in the worst case scenario. In the best case >> scenario (static cubes or objects), they are updated only once. This relies >> a lot on the CPU because all of the transformations has to be done manually >> on the CPU. >> >> This is not a hardware problem, this is a drivers problem because OpenGL >> is huge, complex, unefficient, does not represent the graphics hardware. >> The Mesa Open Source guys are not able to keep pace with the extension hell >> known as OpenGL. In Ubuntu 14.04 Mesa supports up until OpenGL 3.0 >> compatibility profile, and OpenGL 3.1 core profile. The current version of >> OpenGL is 4.5. Each version of OpenGL has a different version of GLSL >> (OpenGL Shader Language), which makes harder to stick with one reasonable >> subset and then support features depending on which hardware you are >> running. In contrast, if you are developing for Direct3D in Windows, you >> only need to choose between Direct3D 9(Windows XP), 11(Vista I think/7/8), >> 12(Windows 10) and thats it. In Direct3D you do not have to deal with >> hardware vendor extensions because there are not extensions. >> >> By using instancing, I have a buffer with the geometry of a single cube >> or shape. Then I have another buffer with the transformation and color of >> each cube or simple shape. When updating the position, size or color of an >> element I only have to change a single entry in this buffer. >> >> The original Roassal 3D used a draw call per element. This more flexible, >> but a lot slower. 20.000 cubes in Roassal3D vs 300.000-600.000 in >> Woden-Roassal visibles at the same time. The overhead of a draw call is >> produced because some validations are made by the OpenGL driver for each >> draw call. >> >> A draw call per-element is only reasonable when using Direct3D >> 12(Window), Metal(iOS, OS X) or Vulkan (Linux, Windows and mobiles) because >> there are designed to remove the overhead of draw calls. This is the >> approach that I am going to use in Woden 2 via an abstraction layer that I >> am making in C/C++ above the graphics API. Currently I have a backend for >> Direct3D 12 and OpenGL 4.x (it should be possible to use OpenGL 3.3, but I >> need to test it). I made the OpenGL backend because Vulkan has not been >> released yet. It is impossible to get the best performance by using the >> OpenGL backend because of its design. In theory it should be possible to >> make a backend for OpenGL 2.0 and OpenGL 2.0 ES, but it will be really hard >> to do. And it will not have a good performance. >> >> Greetings, >> Ronie >> >> >> 2015-11-28 14:41 GMT-03:00 stepharo <stepharo(a)free.fr>: >> >>> Ronie >>> >>> I think that this is important that people can pick different >>> ("compatible") driver/framework back-end. >>> You see if Woden is only built to work on something that does not run on >>> mac or windows then >>> it will be limited. >>> >>> Stef >>> >>> Le 25/11/15 00:14, Ronie Salgado a Ã©crit : >>> >>> >>> What do you mean with "modern"? >>>> >>> By modern I mean a graphics card a with graphics driver that supports at >>> least OpenGL 4.x. That Intel HD graphics card is capable of supporting at >>> least OpenGL 4.2, but the Open Source Mesa driver gives you support up >>> until OpenGL 3.1. Unfortunately, unlike with AMD or NVIDIA graphics cards, >>> the open source driver is the official driver. >>> >>> Woden-Roassal requires integer arithmetic in shaders which is used to >>> support the selection of objects. Integer arithmetics in shaders requires >>> at least OpenGL 3.3, or the missing extension for which you are receiving >>> the error. >>> >>> It is not required by the Woden-Core api, so you should be able to try >>> the following in a workspace: >>> >>> WDFPSSimpleExample6 new open >>> >>> My notebook with an HD Graphics 4400 has no problems with all "three.js" >>>> demos found here http://threejs.org/. >>>> >>> Three.js or any WebGL based example is a bad test for that graphics >>> card. WebGL is based in OpenGL ES 2.0 which is a subset of OpenGL 2.0. This >>> is a very old technology for that graphics card. >>> >>> Woden will be using Vulkan in the future. According to this Phoronix >>> article ( >>> http://www.phoronix.com/scan.php?page=news_item&px=LunarG-Vulkan-AMA) >>> Valve has already made a proper Vulkan driver for the Intel graphics cards. >>> We only need an official release of the Vulkan spec. >>> >>> Best regards >>> Ronie >>> >>> 2015-11-24 18:50 GMT-03:00 Volkert <volkert(a)komponentenwerkstatt.de>: >>> >>>> My notebook with an HD Graphics 4400 has no problems with all >>>> "three.js" demos found here http://threejs.org/. >>>> >>>> What do you mean with "modern"? >>>> >>>> >>>> >>>> On 24.11.2015 22:25, Ronie Salgado wrote: >>>> >>>> You need a modern graphics card. Open source graphics drivers are not >>>> supported because there are very behind in their implementations of OpenGL. >>>> >>>> >>>> 2015-11-24 17:28 GMT-03:00 Volkert < <volkert(a)komponentenwerkstatt.de> >>>> volkert(a)komponentenwerkstatt.de>: >>>> >>>>> But not on my linux box .... ubuntu 14.04 :-( >>>>> >>>>> >>>>> >>>>> >>>>> On 24.11.2015 21:03, Alexandre Bergel wrote: >>>>> >>>>> Woden works in Pharo 5.0 >>>>> I have just tried. >>>>> >>>>> Alexandre >>>>> -- >>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>>> Alexandre Bergel <http://www.bergel.eu>http://www.bergel.eu >>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>>> >>>>> >>>>> >>>>> On Nov 24, 2015, at 3:15 PM, Volkert < >>>>> <volkert(a)komponentenwerkstatt.de>volkert(a)komponentenwerkstatt.de> >>>>> wrote: >>>>> >>>>> Cool ... >>>>> >>>>> Which Pharo Version? I tried Pharo 4.0 and got this error: >>>>> >>>>> <edcefcdd.png> >>>>> >>>>> >>>>> On 24.11.2015 12:50, Alexandre Bergel wrote: >>>>> >>>>> Do we have a tutorial? i found only <http://woden.ronie.cl> >>>>> http://woden.ronie.cl. >>>>> >>>>> What about mouse control and object selection. It that possible? >>>>> >>>>> >>>>> Yes. >>>>> >>>>> To load Woden: >>>>> >>>>> Gofer new smalltalkhubUser: 'ronsaldo' project: 'Woden'; package: >>>>> 'ConfigurationOfWoden'; load. (Smalltalk at: #ConfigurationOfWoden) >>>>> loadBleedingEdge. >>>>> >>>>> Try: >>>>> =-=-=-==-=-=-==-=-=-==-=-=-= >>>>> v := RWView new. >>>>> >>>>> 1 to: 100 do: [ :i | >>>>> e := RWCube element. >>>>> e when: RWMouseButtonDown do: [ :ev | >>>>> ev element shape color: WDColor green. >>>>> ev element changed. >>>>> ]. >>>>> v add: e. >>>>> ]. >>>>> RWXZGridLayout on: v elements. >>>>> v addInteraction: RWMouseKeyControl. >>>>> v camera position: (WDVector3 x: 0.0 y: 0.0 z: 3.0). >>>>> v open >>>>> =-=-=-==-=-=-==-=-=-==-=-=-= >>>>> Use the keys A S D W and the moose to navigate. Click on cube to make >>>>> them green >>>>> >>>>> <Mail Attachment.png> >>>>> >>>>> Cheers, >>>>> Alexandre >>>>> >>>>> >>>>> >>>>> >>>>> BW, >>>>> Volkert >>>>> >>>>> On 22.11.2015 21:10, Alexandre Bergel wrote: >>>>> >>>>> We have also put quite some effort on Woden, a 3d engine for Pharoâ¦ >>>>> >>>>> Cheers, >>>>> Alexandre >>>>> >>>>> >>>>> On Nov 22, 2015, at 2:56 PM, Dimitris Chloupis < >>>>> <kilon.alios(a)gmail.com>kilon.alios(a)gmail.com> wrote: >>>>> >>>>> its possible via my Ephestos project, to render to video or real time >>>>> but the project is still very much a WIP. Its doable but require some >>>>> python knowledge and knowledge of Blender UI and API. I will be making a >>>>> true Pharo API for it fairly soon but as you can imagine these things take >>>>> time. >>>>> >>>>> On Sun, Nov 22, 2015 at 6:35 PM Volkert < >>>>> <volkert(a)komponentenwerkstatt.de>volkert(a)komponentenwerkstatt.de> >>>>> wrote: >>>>> Is this possible with Pharo? >>>>> >>>>> <http://www.asterank.com/3d/>http://www.asterank.com/3d/ >>>>> >>>>> BW, >>>>> Volkert >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> >

Dec. 1, 2015

Re: [Pharo-users] Pharo productivity

by Esteban Lorenzano

cool :) but those scripts can be easily improved: Gofer it url: âfiletree:///home/deployâ; package: âWebCounterâ; package: âHelloWorldAppâ; load. stdout << 'WebCounter installed'; lf. ZnZincServerAdaptor startOn: 8080. WAAdmin register: WebCounter asApplicationAt: 'webcounterâ. (looks a lot easier to understand :P) cheers, Esteban > On 30 Nov 2015, at 22:51, phil(a)highoctane.be wrote: > > https://github.com/Geal/pharo-seaside-docker-example > https://www.clever-cloud.com/blog/guests/2015/01/05/smalltalk-in-the-cloud/ > > Phil > > > On Mon, Nov 30, 2015 at 9:43 PM, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > Do you have a recipe to put Pharo in a Docker container? > Esteban A. Maringolo > > > 2015-11-30 17:34 GMT-03:00 phil(a)highoctane.be <phil(a)highoctane.be>: > > I have been using Pharo somewhat less in my current projects. > > > > Nevertheless, I needed a tool done fast and behaving correctly. > > > > Did it the TDD way with Pharo. > > > > Great experience. Great productivity. No messing around with external > > libraries, modules... > > > > 64-bit Linux compatibility would really help these days. But stuffing Pharo > > and 32 bit on a docker container works nicely too. > > > > Phil > > >

Dec. 1, 2015

Re: [Pharo-users] Pharo Consortium New Gold Member: Thales

by John Pfersich

I have tried to join the association in the past, but I get an error message every time I try. See the attached picture to see the result. Sent from my iPad > On Nov 30, 2015, at 03:27, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Great news! > > For everyone not directly involved in the Consortium: > The money collected from memberships go towards the infrastructure of Pharo in form of engineering time. This is a key effort to make Pharo a sustainable platform for the long run. > > That is why these pieces of news are so important. > > Doru > > >> On Nov 26, 2015, at 2:42 PM, marcus.denker(a)inria.fr wrote: >> >> The Pharo Consortium is very happy to announce that Thales >> has joined the Consortium as an Gold Member. >> >> About >> - Thales: https://www.thalesgroup.com >> - Pharo Consortium: http://consortium.pharo.org >> >> The goal of the Pharo Consortium is to allow companies and institutions to >> support the ongoing development and future of Pharo. >> >> Individuals can support Pharo via the Pharo Association: >> >> http://association.pharo.org >> > > -- > www.tudorgirba.com > > "Value is always contextual." > > > >

Dec. 1, 2015

Re: [Pharo-users] PharoJS Status

by Sebastian Heidbrink

Hi Craig, First you should check the tests and run them 1 by 1. Your default browser should open and you should see a PharoJS logo following a websocket log. If that is working correctly then you have loaded all needed sources and your image should be fine. There is general problem with the JSWorkspace and JSPlayground. If timeouts occur then it seems as if the image is busted and no PharoJS code works anymore. In my case it usually helps to just start one of the interactive unit tests or to close and open the image. Please read the class comments of JBBridge and other documented classes. This will give you a better understanding of how PharoJS actually works. If you "doit" a "JbDemoApplication start" then your default web browser should open and you should see a green rectangle asking you to click on it. You can put a "self halt" into the "setupDOM" method and especially into the callback handler blocks,.... see what it does,... you can debug the JS app within Pharo and the app changes live in the browser.... There is also the class "JbBrowserExamples" which has two scripts on the class side. Copy them into a JSPlayground and inspect them. The action should take place in the browser opened while you opened the JSPlayground. But be aware! Those scripts do not stop the websocket nor the proxy and it usually does not take long until you have to restart/reset the image.... I hope that helps a little?! Sebastian On 2015-11-30 12:56 PM, craig wrote: > > Can the people that have it working provide some tips please. > > I have the pink PharoJS workspace open, am I correct in understanding > that the results of any evaluation is this workspace should show-up in > the browser? At this point nothing shows-up in the browser. > > Craig > > On 2015-11-30 21:16, craig wrote: > >> I just loaded PharoJS into a fresh v5 image, and I also had the DNU >> message until I loaded the NewExternalWebBrowser package. >> Craig >> Sent from Samsung Mobile >> >> >> -------- Original message -------- >> From: Noury Bouraqadi >> Date:2015/11/30 5:48 PM (GMT+02:00) >> To: Any question about pharo is welcome >> Subject: Re: [Pharo-users] PharoJS Status >> >> Just tested with a fresh image and it worked. >> Noury >>> On 30 Nov 2015, at 16:37, Andy Burnett >>> <andy.burnett(a)knowinnovation.com >>> <mailto:andy.burnett@knowinnovation.com>> wrote: >>> >>> >>> Craig said >>> Hi All, >>> >>> I'd like to start messing around with PharoJS. Can anybody tell what >>> the status is? (Stable, broken, etc.) >>> >>> And, which Pharo version should I use for this? >>> <<< >>> I have just started playing with it. I have had some difficulty >>> getting a running image. Following the instructions - should - work, >>> but I found that I needed to install the NewExternalWebBrowser >>> package separately before it would run. >>> Cheers >>> Andy

Nov. 30, 2015

Re: [Pharo-users] Pharo productivity

by Norbert Hartl

Sure but the deployment issue is orchestration. The distribution of functionality works along the available resources. The example machine Sven mentioned (32 cores, 96 MB) is worth nothing if you have a lot of instances and spindle hard discs. It is an act of finding the balance that uses the maximum of all resources. You just need to decrease the role of the weakest link. Modern containers are just about making it comfortable but not solving the "real" problems. My 2 cents, Norbert > Am 30.11.2015 um 22:52 schrieb "phil(a)highoctane.be" <phil(a)highoctane.be>: > > Yes but are they working as nicely on Macs and Win boxes running Dockermachine? > > Phil > >> On Mon, Nov 30, 2015 at 9:48 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> LXC/LXD containers are much nicer, IMHO, as they look and feel like a regular VM, yet are way more efficient. >> >> > On 30 Nov 2015, at 21:43, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: >> > >> > Do you have a recipe to put Pharo in a Docker container? >> > Esteban A. Maringolo >> > >> > >> > 2015-11-30 17:34 GMT-03:00 phil(a)highoctane.be <phil(a)highoctane.be>: >> >> I have been using Pharo somewhat less in my current projects. >> >> >> >> Nevertheless, I needed a tool done fast and behaving correctly. >> >> >> >> Did it the TDD way with Pharo. >> >> >> >> Great experience. Great productivity. No messing around with external >> >> libraries, modules... >> >> >> >> 64-bit Linux compatibility would really help these days. But stuffing Pharo >> >> and 32 bit on a docker container works nicely too. >> >> >> >> Phil >> > >

Nov. 30, 2015

Re: [Pharo-users] Pharo productivity

by Norbert Hartl

:) Well, looking at all the isolation containers I still have doubts that isolation is working as expected. There are many influences that make containers less independent. Prominent candidate is (as always) I/O that has the ability to slow down everything. But let's talk! I always appreciate exchanging thoughts ans experiences with you :) Norbert > Am 30.11.2015 um 22:28 schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: > > >> On 30 Nov 2015, at 22:08, Norbert Hartl <norbert(a)hartl.name> wrote: >> >> true. We use them a lot > > Good to know, we're currently deploying an upgrade to our server park, all new machines (32 cores, 96 Gb RAM each) will be running many LXC/LXD instances, probably using ZFS for their storage. The networking was the biggest challenge, but I think we got that covered. In any case, Pharo ran perfectly on them (either 32 or 64 bit) ! > > If we get stuck on something, I will know who I can beg for help ;-) > >> +1 >> >> Norbert >> >>> Am 30.11.2015 um 21:48 schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: >>> >>> LXC/LXD containers are much nicer, IMHO, as they look and feel like a regular VM, yet are way more efficient. >>> >>>> On 30 Nov 2015, at 21:43, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: >>>> >>>> Do you have a recipe to put Pharo in a Docker container? >>>> Esteban A. Maringolo >>>> >>>> >>>> 2015-11-30 17:34 GMT-03:00 phil(a)highoctane.be <phil(a)highoctane.be>: >>>>> I have been using Pharo somewhat less in my current projects. >>>>> >>>>> Nevertheless, I needed a tool done fast and behaving correctly. >>>>> >>>>> Did it the TDD way with Pharo. >>>>> >>>>> Great experience. Great productivity. No messing around with external >>>>> libraries, modules... >>>>> >>>>> 64-bit Linux compatibility would really help these days. But stuffing Pharo >>>>> and 32 bit on a docker container works nicely too. >>>>> >>>>> Phil > >

Nov. 30, 2015