July 2016 - Pharo-users - lists.pharo.org

Re: [Pharo-users] XMLParser Claims U+00A0 is âInvalid UTF-8â

by Sean P. DeNigris

monty-3 wrote > Just to be sure, I manually recreated your file (with the great Bless hex > editor) and parsed it with no issue. Thanks! monty-3 wrote > Please post your code and attach the actual source as a file separately. The code is merely: messageLog := FileLocator home / 'illegal-UTF-sms.xml'. doc := XMLDOMParser parse: messageLog. File: illegal-UTF-sms.xml <http://forum.world.st/file/n4908531/illegal-UTF-sms.xml> ----- Cheers, Sean -- View this message in context: http://forum.world.st/XMLParser-Claims-U-00A0-is-Invalid-UTF-8-tp4908525p49… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

July 28, 2016

Re: [Pharo-users] OpenGLES2 binding available!

by stepharo

> > Anyway, implementing a Athens backend from scratch is a really hard > problem, because paths can be concave, curve and self intersecting. > Drawing a path, unlike drawing a triangle is a global operation, for > which GPUs were not designed for. The easiest and most robust > technique for drawing a path using the GPU is to flatten the path > using De Casteljau's algorithm and then using the stencil buffer > technique for drawing concave polygons that was described in the > OpenGL red book ( > http://www.glprogramming.com/red/chapter14.html#name13 ). The problem > of this technique is that involves many state changes(glStencil*) and > drawing commands(glDrawElements) per path, which are the most > expensive operations when using OpenGL. The alternative is to perform > a triangulation in the CPU of paths, or to use one of the newer low > level APIs such as Vulkan and Direct 3D 12 which were designed to > reduce or eliminate the cost of state changes and drawing commands. > > Path stroking is an even harder problem, which I have not solved yet. > The standard approach is to convert a stroked path into a path that > can be filled. The problem is that bezier offset curves are not bezier > curves, so they have to be approximated. Fortunately, since this > operation is backend agnostic, it can be used and reused by many > Athens backends. Since stroking is not critical for my needs, I do not > think I will implement it soon properly. Currently I am just drawing a > 1 pixel thick line, which can look horrible, but is better than > nothing. One algorithm that seems to be simple to implement is one > described in a paper from the Cairo people, which uses the Minkowksi > Sum between the outline of the path to be stroked, and shape of the > pen that is stroking > the path: http://keithp.com/~keithp/talks/cairo2003.pdf > <http://keithp.com/%7Ekeithp/talks/cairo2003.pdf> Thanks because indeed this is a lot of work. Thanks for the reality check. > > Soon I will merge the Lowcode instructions into the SqueakVM/Cog VM to > integrate these bytecodes into the mainline VM. > > I will not publish Woden 2 until the dependencies and Woden 2 itself > can be loaded easily. Soon I will publish properly the Dastrel shader > language and the Slovim backend. Slovim name comes from Smalltalk Low > levelish VIrtual Machine, an intermediate representation heavily > modeled after the one used in LLVM, implemented in Pharo, some very > basic optimizations(basic constant folding, inlining and some dead > code generation), and a code generator backend for SpirV, GLSL and > C++. My biggest issue before publishing this compiler are: > - Implementing a command line interface. > - Doing an easy to install and use package for Linux, OS X and Windows. > - Documenting the language and the compiler. > > Best regards, > Ronie > > 2016-07-28 19:31 GMT+02:00 Alexandre Bergel <alexandre.bergel(a)me.com > <mailto:alexandre.bergel@me.com>>: > >> I would love to see an athens back-end for it. >> > Isn't it what Ronie is working on? > > Alexandre > >> >> Le 19/7/16 Ã 13:19, Thibault Raffaillac a Ã©crit : >>> Hi all, >>> >>> My tiny binding for OpenGLES2 is ready :) >>> http://smalltalkhub.com/#!/~ThibaultRaffaillac/OpenGLES2/ >>> <http://smalltalkhub.com/#%21/%7EThibaultRaffaillac/OpenGLES2/> >>> >>> It takes a different direction than that of NBOpenGL. I found the support for all versions of OpenGL overwhelming, both for beginners and to maintain. With a limited number of functions I could carefully name all messages. >>> >>> A demo using either SDL2 or GLFW (faster) is included, supporting VSync and retina displays. >>> Tested only on Mac OSX, patches welcome! >>> >>> Cheers, >>> Thibault >>> >> > >

July 28, 2016

Re: [Pharo-users] OpenGLES2 binding available!

by Alexandre Bergel

+1 > On Jul 28, 2016, at 3:52 PM, stepharo <stepharo(a)free.fr> wrote: > > Thanks ronie for your analysis (especially the thread local point). > Stef > > Le 28/7/16 Ã 20:36, Ronie Salgado a Ã©crit : >> Isn't it what Ronie is working on? >> I am not working with OpenGL or OpenGL ES anymore. I am moving all of my efforts into Woden 2, the AbstractGPU (an abstraction layer for Vulkan, Direct3D 12 and Metal), and Dastrel (Data Stream Language) a custom shader language whose compiler I implemented in Pharo, with a backend for SpirV, GLSL and C++. I still have to implement the backends for Metal and HLSL. >> >> Thibault is interested more on being able to use OpenGL ES 2.0 directly in the playground, for teaching purposes without any abstraction layer underlying. I do not agree with many of his approaches, too low level, and many of themp do not work well with Pharo VM. One of the biggest issue of OpenGL is related with vsync, which is an operation that can block all of the Pharo processes, until we get a VM with the threaded FFI, which will have in the near future. It will use the UnifiedFFI API, so we will not have to further changes to take advantage of the threaded ffi in the user code. >> >> A far worse problem with OpenGL is that the current OpenGL context is a thread local variable, which do not interact at all with Pharo processes. This is the reason of why I added the OSWindowRenderThread class for serializing OSWindow and OpenGL animations. SDL2 renderers are usually implemented using OpenGL. They are two correct solution for this problem: >> - Having a VM that maps each Pharo Process into an operating system thread, >> - Not using OpenGL at all. >> >> The others low level graphics API (Vulkan, Direct 3D and Metal) do not rely on a global thread local storage variable. These APIs are object oriented, so handles are passed in each API call. >> >> Currently, I have an Athens backend above Woden 2, which is only supporting Vulkan for now. Since this backend is for Woden 2, it has some dependencies in the Woden 2 Math and the Lowcode NativeStructure. This means that the Woden 2 Athens backend has a strong dependency in the the modified OpalCompiler that uses the Lowcode extended byte code set, and the the modified PharoVM that implements these extra bytecode in the just in time compiler. >> >> Anyway, implementing a Athens backend from scratch is a really hard problem, because paths can be concave, curve and self intersecting. Drawing a path, unlike drawing a triangle is a global operation, for which GPUs were not designed for. The easiest and most robust technique for drawing a path using the GPU is to flatten the path using De Casteljau's algorithm and then using the stencil buffer technique for drawing concave polygons that was described in the OpenGL red book ( http://www.glprogramming.com/red/chapter14.html#name13 ). The problem of this technique is that involves many state changes(glStencil*) and drawing commands(glDrawElements) per path, which are the most expensive operations when using OpenGL. The alternative is to perform a triangulation in the CPU of paths, or to use one of the newer low level APIs such as Vulkan and Direct 3D 12 which were designed to reduce or eliminate the cost of state changes and drawing commands. >> >> Path stroking is an even harder problem, which I have not solved yet. The standard approach is to convert a stroked path into a path that can be filled. The problem is that bezier offset curves are not bezier curves, so they have to be approximated. Fortunately, since this operation is backend agnostic, it can be used and reused by many Athens backends. Since stroking is not critical for my needs, I do not think I will implement it soon properly. Currently I am just drawing a 1 pixel thick line, which can look horrible, but is better than nothing. One algorithm that seems to be simple to implement is one described in a paper from the Cairo people, which uses the Minkowksi Sum between the outline of the path to be stroked, and shape of the pen that is stroking >> the path: http://keithp.com/~keithp/talks/cairo2003.pdf >> >> Soon I will merge the Lowcode instructions into the SqueakVM/Cog VM to integrate these bytecodes into the mainline VM. >> >> I will not publish Woden 2 until the dependencies and Woden 2 itself can be loaded easily. Soon I will publish properly the Dastrel shader language and the Slovim backend. Slovim name comes from Smalltalk Low levelish VIrtual Machine, an intermediate representation heavily modeled after the one used in LLVM, implemented in Pharo, some very basic optimizations(basic constant folding, inlining and some dead code generation), and a code generator backend for SpirV, GLSL and C++. My biggest issue before publishing this compiler are: >> - Implementing a command line interface. >> - Doing an easy to install and use package for Linux, OS X and Windows. >> - Documenting the language and the compiler. >> >> Best regards, >> Ronie >> >> 2016-07-28 19:31 GMT+02:00 Alexandre Bergel <alexandre.bergel(a)me.com>: >>> I would love to see an athens back-end for it. >>> >> Isn't it what Ronie is working on? >> >> Alexandre >> >>> >>> Le 19/7/16 Ã 13:19, Thibault Raffaillac a Ã©crit : >>>> Hi all, >>>> >>>> My tiny binding for OpenGLES2 is ready :) >>>> >>>> http://smalltalkhub.com/#!/~ThibaultRaffaillac/OpenGLES2/ >>>> >>>> >>>> It takes a different direction than that of NBOpenGL. I found the support for all versions of OpenGL overwhelming, both for beginners and to maintain. With a limited number of functions I could carefully name all messages. >>>> >>>> A demo using either SDL2 or GLFW (faster) is included, supporting VSync and retina displays. >>>> Tested only on Mac OSX, patches welcome! >>>> >>>> Cheers, >>>> Thibault >>>> >>>> >>> >> >> > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

July 28, 2016

Re: [Pharo-users] OpenGLES2 binding available!

by stepharo

Thanks ronie for your analysis (especially the thread local point). Stef Le 28/7/16 Ã 20:36, Ronie Salgado a Ã©crit : > > Isn't it what Ronie is working on? > > I am not working with OpenGL or OpenGL ES anymore. I am moving all of > my efforts into Woden 2, the AbstractGPU (an abstraction layer for > Vulkan, Direct3D 12 and Metal), and Dastrel (Data Stream Language) a > custom shader language whose compiler I implemented in Pharo, with a > backend for SpirV, GLSL and C++. I still have to implement the > backends for Metal and HLSL. > > Thibault is interested more on being able to use OpenGL ES 2.0 > directly in the playground, for teaching purposes without any > abstraction layer underlying. I do not agree with many of his > approaches, too low level, and many of themp do not work well with > Pharo VM. One of the biggest issue of OpenGL is related with vsync, > which is an operation that can block all of the Pharo processes, until > we get a VM with the threaded FFI, which will have in the near future. > It will use the UnifiedFFI API, so we will not have to further changes > to take advantage of the threaded ffi in the user code. > > A far worse problem with OpenGL is that the current OpenGL context is > a thread local variable, which do not interact at all with Pharo > processes. This is the reason of why I added the OSWindowRenderThread > class for serializing OSWindow and OpenGL animations. SDL2 renderers > are usually implemented using OpenGL. They are two correct solution > for this problem: > - Having a VM that maps each Pharo Process into an operating system > thread, > - Not using OpenGL at all. > > The others low level graphics API (Vulkan, Direct 3D and Metal) do not > rely on a global thread local storage variable. These APIs are object > oriented, so handles are passed in each API call. > > Currently, I have an Athens backend above Woden 2, which is only > supporting Vulkan for now. Since this backend is for Woden 2, it has > some dependencies in the Woden 2 Math and the Lowcode NativeStructure. > This means that the Woden 2 Athens backend has a strong dependency in > the the modified OpalCompiler that uses the Lowcode extended byte code > set, and the the modified PharoVM that implements these extra bytecode > in the just in time compiler. > > Anyway, implementing a Athens backend from scratch is a really hard > problem, because paths can be concave, curve and self intersecting. > Drawing a path, unlike drawing a triangle is a global operation, for > which GPUs were not designed for. The easiest and most robust > technique for drawing a path using the GPU is to flatten the path > using De Casteljau's algorithm and then using the stencil buffer > technique for drawing concave polygons that was described in the > OpenGL red book ( > http://www.glprogramming.com/red/chapter14.html#name13 ). The problem > of this technique is that involves many state changes(glStencil*) and > drawing commands(glDrawElements) per path, which are the most > expensive operations when using OpenGL. The alternative is to perform > a triangulation in the CPU of paths, or to use one of the newer low > level APIs such as Vulkan and Direct 3D 12 which were designed to > reduce or eliminate the cost of state changes and drawing commands. > > Path stroking is an even harder problem, which I have not solved yet. > The standard approach is to convert a stroked path into a path that > can be filled. The problem is that bezier offset curves are not bezier > curves, so they have to be approximated. Fortunately, since this > operation is backend agnostic, it can be used and reused by many > Athens backends. Since stroking is not critical for my needs, I do not > think I will implement it soon properly. Currently I am just drawing a > 1 pixel thick line, which can look horrible, but is better than > nothing. One algorithm that seems to be simple to implement is one > described in a paper from the Cairo people, which uses the Minkowksi > Sum between the outline of the path to be stroked, and shape of the > pen that is stroking > the path: http://keithp.com/~keithp/talks/cairo2003.pdf > <http://keithp.com/%7Ekeithp/talks/cairo2003.pdf> > > Soon I will merge the Lowcode instructions into the SqueakVM/Cog VM to > integrate these bytecodes into the mainline VM. > > I will not publish Woden 2 until the dependencies and Woden 2 itself > can be loaded easily. Soon I will publish properly the Dastrel shader > language and the Slovim backend. Slovim name comes from Smalltalk Low > levelish VIrtual Machine, an intermediate representation heavily > modeled after the one used in LLVM, implemented in Pharo, some very > basic optimizations(basic constant folding, inlining and some dead > code generation), and a code generator backend for SpirV, GLSL and > C++. My biggest issue before publishing this compiler are: > - Implementing a command line interface. > - Doing an easy to install and use package for Linux, OS X and Windows. > - Documenting the language and the compiler. > > Best regards, > Ronie > > 2016-07-28 19:31 GMT+02:00 Alexandre Bergel <alexandre.bergel(a)me.com > <mailto:alexandre.bergel@me.com>>: > >> I would love to see an athens back-end for it. >> > Isn't it what Ronie is working on? > > Alexandre > >> >> Le 19/7/16 Ã 13:19, Thibault Raffaillac a Ã©crit : >>> Hi all, >>> >>> My tiny binding for OpenGLES2 is ready :) >>> http://smalltalkhub.com/#!/~ThibaultRaffaillac/OpenGLES2/ >>> <http://smalltalkhub.com/#%21/%7EThibaultRaffaillac/OpenGLES2/> >>> >>> It takes a different direction than that of NBOpenGL. I found the support for all versions of OpenGL overwhelming, both for beginners and to maintain. With a limited number of functions I could carefully name all messages. >>> >>> A demo using either SDL2 or GLFW (faster) is included, supporting VSync and retina displays. >>> Tested only on Mac OSX, patches welcome! >>> >>> Cheers, >>> Thibault >>> >> > >

July 28, 2016

XMLParser Claims U+00A0 is âInvalid UTF-8â

by Sean P. DeNigris

Posted to StackOverflow (https://stackoverflow.com/questions/38645553/xmlparser-in-pharo-claims-u00a…) Given the input: <?xml version='1.0' encoding='UTF-8' standalone='yes' ?> <sms body=". what" /> Where the character after the "." in the body attribute of the sms tag is U+00A0; I get the error: XMLEncodingException: Invalid UTF-8 character encoding (line 2) (column 13) IIUC, the UTF-8 representation of that character is 0xC2 0xA0 per Wikipedia. Sure enough, bytes 72 and 73 of the input are 194 and 160 respectively. This seems like a bug in XMLParser, or am I missing something? ----- Cheers, Sean -- View this message in context: http://forum.world.st/XMLParser-Claims-U-00A0-is-Invalid-UTF-8-tp4908525.ht… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

July 28, 2016

Re: [Pharo-users] Pharo-users Digest, Vol 39, Issue 126

by Sven Van Caekenberghe

I am pretty sure I am talking to a bot, but in the case you are a real human, this is how you would parse the file you gave as example (which is technically TSV, tab separated values): | input | input := 'DÃa Evento Registrado NÃºmero Originante Moneda (*) Monto (*) Fecha de EjecuciÃ³n (pago, cobro o congelamiento) Frecuencia de Pago Comprobante Asociado (**) 1 Factura F1 Propia Pesos 1000 DÃa 10 - - 1 Factura F2 Propia Pesos 500 DÃa 11 - - 2 Factura F3 Terceros Pesos 250 DÃa 11 - - 3 Factura F4 Propia DÃ³lares 5000 DÃa 10 - - 4 Factura F5 Propia DÃ³lares 5000 DÃa 22 - - 5 Factura F6 Terceros DÃ³lares 5000 DÃa 23 - - 6 Factura F7 Propia DÃ³lares 5000 DÃa 35 - - 7 Factura Recurrente FR8 Propia Pesos 100 DÃa 11 3 veces, cada 10 dÃas. - 8 Factura Recurrente FR9 Propia Pesos 150 DÃa 15 3 veces, cada 5 dÃas. - 10 Congelamiento FR FR9 - - - DÃa 22 - - 10 Factura (Real) F81 Propia Pesos 100 DÃa 11 - FR8 14 Factura (Real) F91 Propia Pesos 150 DÃa 15 - FR9 19 Factura (Real) F92 Propia Pesos 150 DÃa 20 - FR9 20 Factura (Real) F82 Propia Pesos 100 DÃa 21 - FR8 30 Factura (Real) F83 Propia Pesos 100 DÃa 31 - FR8 '. (NeoCSVReader on: input readStream) separator: Character tab; skipHeader; upToEnd. Regards, Sven > On 28 Jul 2016, at 19:17, Alejandro Adgi Romano <adgiromanoalejandro(a)gmail.com> wrote: > > Good morning! > > Okey, so, i must create an object from Ghost? > > I am sendig all of you the data from cvs file. > > What I need is generate a code in Pharo for Read this information, (because i need work with the pays, or the credits notes), so I need, in a variable for example, put the value of the cell X, which contains the $Total. > > The information from csv file is like the next. I tried to use NeoCsv but i donÂ´t understood. Is good NeoCsv or is better the way using Ghost how you say? > > DÃa Evento Registrado NÃºmero Originante Moneda (*) Monto (*) Fecha de EjecuciÃ³n (pago, cobro o congelamiento) Frecuencia de Pago Comprobante Asociado (**) > 1 Factura F1 Propia Pesos 1000 DÃa 10 - - > 1 Factura F2 Propia Pesos 500 DÃa 11 - - > 2 Factura F3 Terceros Pesos 250 DÃa 11 - - > 3 Factura F4 Propia DÃ³lares 5000 DÃa 10 - - > 4 Factura F5 Propia DÃ³lares 5000 DÃa 22 - - > 5 Factura F6 Terceros DÃ³lares 5000 DÃa 23 - - > 6 Factura F7 Propia DÃ³lares 5000 DÃa 35 - - > 7 Factura Recurrente FR8 Propia Pesos 100 DÃa 11 3 veces, cada 10 dÃas. - > 8 Factura Recurrente FR9 Propia Pesos 150 DÃa 15 3 veces, cada 5 dÃas. - > 10 Congelamiento FR FR9 - - - DÃa 22 - - > 10 Factura (Real) F81 Propia Pesos 100 DÃa 11 - FR8 > 14 Factura (Real) F91 Propia Pesos 150 DÃa 15 - FR9 > 19 Factura (Real) F92 Propia Pesos 150 DÃa 20 - FR9 > 20 Factura (Real) F82 Propia Pesos 100 DÃa 21 - FR8 > 30 Factura (Real) F83 Propia Pesos 100 DÃa 31 - FR8 > > 2016-07-28 9:06 GMT-03:00 <pharo-users-request(a)lists.pharo.org>: > Send Pharo-users mailing list submissions to > pharo-users(a)lists.pharo.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.pharo.org/mailman/listinfo/pharo-users_lists.pharo.org > or, via email, send a message with subject or body 'help' to > pharo-users-request(a)lists.pharo.org > > You can reach the person managing the list at > pharo-users-owner(a)lists.pharo.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Pharo-users digest..." > > > Today's Topics: > > 1. Update CI books written in Pillar (Yann Dubois) > 2. Re: "self problem" with Ghost (virus) (Steven Costiou) > 3. Re: "self problem" with Ghost (virus) (Denis Kudriashov) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 28 Jul 2016 13:43:52 +0200 > From: Yann Dubois <yann59.dubois(a)gmail.com> > To: Any question about pharo is welcome <pharo-users(a)lists.pharo.org> > Subject: [Pharo-users] Update CI books written in Pillar > Message-ID: > <CALbP1jtHe9GefP7s9KwAnD6QaB_qzyBuUqzE1sZH0oNuSWESAA(a)mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Hi ! > > In the last version of Pillar (4.0.x), Pillar don't manage the compilation > cycle. So the ./compile.sh does not work anymore. > > To update our CI, we use a Makefile (I advise you to use this too). You > have an example on : > https://github.com/pillar-markup/Pillar-Archetype/blob/master/welcome/Makef… > . > > In this Makefile, we create symbolic links pointing on the output > directory. It causes "out of memory" on Jenkins. To solve this problem, you > need to remove the symbolic links after the compilation. Personnaly, I had > > *find book-result -type l -exec unlink {} \;* > > > at the end of the EnterprisePharo's Jenkins script. > > Cheers, Yann >

July 28, 2016

Re: [Pharo-users] OpenGLES2 binding available!

by Ronie Salgado

> > Isn't it what Ronie is working on? I am not working with OpenGL or OpenGL ES anymore. I am moving all of my efforts into Woden 2, the AbstractGPU (an abstraction layer for Vulkan, Direct3D 12 and Metal), and Dastrel (Data Stream Language) a custom shader language whose compiler I implemented in Pharo, with a backend for SpirV, GLSL and C++. I still have to implement the backends for Metal and HLSL. Thibault is interested more on being able to use OpenGL ES 2.0 directly in the playground, for teaching purposes without any abstraction layer underlying. I do not agree with many of his approaches, too low level, and many of themp do not work well with Pharo VM. One of the biggest issue of OpenGL is related with vsync, which is an operation that can block all of the Pharo processes, until we get a VM with the threaded FFI, which will have in the near future. It will use the UnifiedFFI API, so we will not have to further changes to take advantage of the threaded ffi in the user code. A far worse problem with OpenGL is that the current OpenGL context is a thread local variable, which do not interact at all with Pharo processes. This is the reason of why I added the OSWindowRenderThread class for serializing OSWindow and OpenGL animations. SDL2 renderers are usually implemented using OpenGL. They are two correct solution for this problem: - Having a VM that maps each Pharo Process into an operating system thread, - Not using OpenGL at all. The others low level graphics API (Vulkan, Direct 3D and Metal) do not rely on a global thread local storage variable. These APIs are object oriented, so handles are passed in each API call. Currently, I have an Athens backend above Woden 2, which is only supporting Vulkan for now. Since this backend is for Woden 2, it has some dependencies in the Woden 2 Math and the Lowcode NativeStructure. This means that the Woden 2 Athens backend has a strong dependency in the the modified OpalCompiler that uses the Lowcode extended byte code set, and the the modified PharoVM that implements these extra bytecode in the just in time compiler. Anyway, implementing a Athens backend from scratch is a really hard problem, because paths can be concave, curve and self intersecting. Drawing a path, unlike drawing a triangle is a global operation, for which GPUs were not designed for. The easiest and most robust technique for drawing a path using the GPU is to flatten the path using De Casteljau's algorithm and then using the stencil buffer technique for drawing concave polygons that was described in the OpenGL red book ( http://www.glprogramming.com/red/chapter14.html#name13 ). The problem of this technique is that involves many state changes(glStencil*) and drawing commands(glDrawElements) per path, which are the most expensive operations when using OpenGL. The alternative is to perform a triangulation in the CPU of paths, or to use one of the newer low level APIs such as Vulkan and Direct 3D 12 which were designed to reduce or eliminate the cost of state changes and drawing commands. Path stroking is an even harder problem, which I have not solved yet. The standard approach is to convert a stroked path into a path that can be filled. The problem is that bezier offset curves are not bezier curves, so they have to be approximated. Fortunately, since this operation is backend agnostic, it can be used and reused by many Athens backends. Since stroking is not critical for my needs, I do not think I will implement it soon properly. Currently I am just drawing a 1 pixel thick line, which can look horrible, but is better than nothing. One algorithm that seems to be simple to implement is one described in a paper from the Cairo people, which uses the Minkowksi Sum between the outline of the path to be stroked, and shape of the pen that is stroking the path: http://keithp.com/~keithp/talks/cairo2003.pdf Soon I will merge the Lowcode instructions into the SqueakVM/Cog VM to integrate these bytecodes into the mainline VM. I will not publish Woden 2 until the dependencies and Woden 2 itself can be loaded easily. Soon I will publish properly the Dastrel shader language and the Slovim backend. Slovim name comes from Smalltalk Low levelish VIrtual Machine, an intermediate representation heavily modeled after the one used in LLVM, implemented in Pharo, some very basic optimizations(basic constant folding, inlining and some dead code generation), and a code generator backend for SpirV, GLSL and C++. My biggest issue before publishing this compiler are: - Implementing a command line interface. - Doing an easy to install and use package for Linux, OS X and Windows. - Documenting the language and the compiler. Best regards, Ronie 2016-07-28 19:31 GMT+02:00 Alexandre Bergel <alexandre.bergel(a)me.com>: > I would love to see an athens back-end for it. > > Isn't it what Ronie is working on? > > Alexandre > > > Le 19/7/16 Ã 13:19, Thibault Raffaillac a Ã©crit : > > Hi all, > > My tiny binding for OpenGLES2 is ready :)http://smalltalkhub.com/#!/~ThibaultRaffaillac/OpenGLES2/ > > It takes a different direction than that of NBOpenGL. I found the support for all versions of OpenGL overwhelming, both for beginners and to maintain. With a limited number of functions I could carefully name all messages. > > A demo using either SDL2 or GLFW (faster) is included, supporting VSync and retina displays. > Tested only on Mac OSX, patches welcome! > > Cheers, > Thibault > > > > >

July 28, 2016

Listing Named Play Pages

by Sean P. DeNigris

Is there another way besides via Spotter? I would expect to find a menu or button on the playground itself... ----- Cheers, Sean -- View this message in context: http://forum.world.st/Listing-Named-Play-Pages-tp4908505.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

July 28, 2016

Re: [Pharo-users] OpenGLES2 binding available!

by Alexandre Bergel

> I would love to see an athens back-end for it. > Isn't it what Ronie is working on? Alexandre > > Le 19/7/16 Ã 13:19, Thibault Raffaillac a Ã©crit : >> Hi all, >> >> My tiny binding for OpenGLES2 is ready :) >> http://smalltalkhub.com/#!/~ThibaultRaffaillac/OpenGLES2/ <http://smalltalkhub.com/#%21/%7EThibaultRaffaillac/OpenGLES2/> >> >> It takes a different direction than that of NBOpenGL. I found the support for all versions of OpenGL overwhelming, both for beginners and to maintain. With a limited number of functions I could carefully name all messages. >> >> A demo using either SDL2 or GLFW (faster) is included, supporting VSync and retina displays. >> Tested only on Mac OSX, patches welcome! >> >> Cheers, >> Thibault >> >

July 28, 2016

Re: [Pharo-users] OpenGLES2 binding available!

by stepharo

Hi thibault I took some times to look at your project. Nice. Now the GLW example is not working. I understand that this is a binding. I do not want to have to work that low level. I'm curious to see what people will be able to build on top of it. Stef Le 19/7/16 Ã 13:19, Thibault Raffaillac a Ã©crit : > Hi all, > > My tiny binding for OpenGLES2 is ready :) > http://smalltalkhub.com/#!/~ThibaultRaffaillac/OpenGLES2/ > > It takes a different direction than that of NBOpenGL. I found the support for all versions of OpenGL overwhelming, both for beginners and to maintain. With a limited number of functions I could carefully name all messages. > > A demo using either SDL2 or GLFW (faster) is included, supporting VSync and retina displays. > Tested only on Mac OSX, patches welcome! > > Cheers, > Thibault > >

July 28, 2016