December 2015 - Pharo-users

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