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

Re: [Pharo-users] OpenGL project

by Igor Stasenko

On 1 April 2016 at 13:23, Thibault Raffaillac <thibault.raffaillac(a)inria.fr> wrote: > There's (hopefully!) no question of throwing it away already. That > represents too much work, and pretty good design choices IMO. Yet I'm still > pretty new to Pharo/Smalltalk so simply need time. At the moment I am only > practicing on a GLFW binding. > Now, I do believe in OpenGL and hardware rendering in general (vs software > & framebuffer stuff), but these APIs are constantly evolving (with > hardware, market needs, ...), with driver manufacturers having little care > about backward compatibility. This means in that sea of innovations we have > to spot the few key technologies which are going to last long enough to be > still in use by the time they reach Pharo users (think of tesselation, or > geometry shaders, hardly heard of nowadays). OpenGL ES 2 is such a key > tech, I think, for its wide adoption in Android, iOS, RasPi. Still, there > is no doubt it is going to be ditched too in a decade or so (command > buffers are already being reintroduced in Vulkan...), and then in Pharo. > With that in mind, my point is to make it as few and small classes as > possible, to make it easier (and faster!) to ditch them later when a new > key tech arises. > That said, I'm looking for least effort solution, so will still strive to > replace NB with UFFI in generator. > > Hi, Thibault.. don't get me wrong: i am fully supporting any effort to bring cool and fast and fancy graphics tech to Pharo. So, nice to hear from you! There's not much effort in generating calls to numerous GL function - it just a matter of parsing opengl spec and producing appropriate smalltalk code out of it.. The main hurdle, i guess, you may find is service code and GL context wrappers i made to handle extension(s) and dealing with the fact that different extensions may or may not be available depending what kind of context you created. I did it by instantiating a table of function pointers and making a specialized custom ffi callout mechanism, that instead of standard way - looking up for a function pointer once and for the rest of session, doing it individually on a per-context basis. That ensures that you can use different contexts safely without risk of calling a function that is not supported in current context while it was supported in another context, one that you used just before. I don't know how you could preserve such kind of functionality in UFFI.. the only thing i know is that you are much more limited in choice. Sure it could be done.. but would it be as efficient as before (just one extra pointer lookup in table of pointers before making a call)? So, that's what i worry about. Cheers, > Thibault > > > Why cutting things down to a subset? > > You have all specs on Opengl.org .. all you have to do today is to import > > xml file and generate proper ffi calls. You can, of course, add support > of > > OpenGL ES.. but why throwing away rest of spec? It just a spec.. you > don't > > have to use it if you don't need it. Instead, if that feels too big - > you > > can do it smarter way: > > - make package/subpackage/classes for ES edition and for full edition. > > It shouldn't cause much trouble if you do it right. > > Because throwing away is easiest part - but making something that will > > serve for years .. harder, because tomorrow someone else can come and > throw > > your stuff away :) > > OpenGL is around for years now.. and i don't think ES edition will > replace > > standard.. I would prefer to be able to access to full OpenGL > > functionality, at a day i will need it.. why cutting things down? > > > > There's many ways to do things in smart way so, nothing will be lost. > > If you don't want/can't maintain or support full OpenGL support - that's > > another story. Then just don't call your project OpenGL - it will cause > > confusion to those who expecting things to work out of the box, and > finding > > out it just OpenGL ES.. > > > > > > > My advise is don't worry about backward compatibility , make it easy, > make > > > it simple. Don't be afraid to code some of it in C if you have to. > > > Sometimes it's far easier to use C than Pharo. Pharo is no magic wand. > > > > > > > > Yep, make it work. That's all what matters. > > -- Best regards, Igor Stasenko.

April 1, 2016

Re: [Pharo-users] [ANN] OS-Linux-CentOS

by Julien Delplanque

Hello, This is nice :) I have a question: Why do CentOS and Ubuntu classes do inherit from UnixSystem? #contentsOf: and #system: message have the same implementation. Cheers, Julien On 31/03/16 18:31, Torsten Bergmann wrote: > Hi, > > the OS-xxx series with (so far) > > - OS-Windows > - OS-Linux-Ubuntu > - OS-Unix > - OS-Raspbian > > now has a new member called "OS-Linux-CentOS" which is more or less an adopted/customized > pendant to "OS-Linux-Ubuntu". > > Project page is at http://www.smalltalkhub.com/#!/~OS/OS-Linux-CentOS > > Ready for Pharo 5. As ever you can load from Catalog tool or directly by entering "CentOS" > into the Spotter search tool. > > Enjoy the video: > > https://www.youtube.com/watch?v=nAwtVeoll_k > > Bye > T. > >

April 1, 2016

Re: [Pharo-users] [ANN] Search and open Unix man pages in Pharo (using OSUnix project)

by Hilaire

Great! I think I could make good use of Spotter in Dr. Geo, not sure where yet. Hilaire Le 31/03/2016 14:07, Torsten Bergmann a Ã©crit : > I added the possibility to search and open Unix man pages (commands, functions and header files) > directly from Pharo Spotter. You will find it in the updated version of my OSUnix support package > in catalog (Pharo 5) -- Dr. Geo http://drgeo.eu

April 1, 2016

IIS and Pharo web service solutions

by Robert Kuszinger

Hello! 1)--------------------- I've successfully worked out how to operate Pharo / Seaside web services behind IIS on Windows Server 2008 (R2) but maybe works on later editions as well. I could summarize it in a "HOWTO" if there is interest or even post it to include in a documentation. (Pharo as a service on Windows, IIS modules to install, how to make it and how to configure proxy / url rewrite) 2)--------------------- Since failed finding an usable binary for nginx uploader module on windows I worked out a method (not really a piece of software) how to use NeatUpload (.NET solution) together with Pharo/Seaside to receive hundreds of megabytes of uploads on Windows servers. If there is interest I'm also ready to document and post it here or somewhere. Please sign any interest here or in private email and then I'll create the docs. Thanks for the many help from many of you during the last two months :) Robert

April 1, 2016

Re: [Pharo-users] OpenGL project

by Thibault Raffaillac

There's (hopefully!) no question of throwing it away already. That represents too much work, and pretty good design choices IMO. Yet I'm still pretty new to Pharo/Smalltalk so simply need time. At the moment I am only practicing on a GLFW binding. Now, I do believe in OpenGL and hardware rendering in general (vs software & framebuffer stuff), but these APIs are constantly evolving (with hardware, market needs, ...), with driver manufacturers having little care about backward compatibility. This means in that sea of innovations we have to spot the few key technologies which are going to last long enough to be still in use by the time they reach Pharo users (think of tesselation, or geometry shaders, hardly heard of nowadays). OpenGL ES 2 is such a key tech, I think, for its wide adoption in Android, iOS, RasPi. Still, there is no doubt it is going to be ditched too in a decade or so (command buffers are already being reintroduced in Vulkan...), and then in Pharo. With that in mind, my point is to make it as few and small classes as possible, to make it easier (and faster!) to ditch them later when a new key tech arises. That said, I'm looking for least effort solution, so will still strive to replace NB with UFFI in generator. Cheers, Thibault > Why cutting things down to a subset? > You have all specs on Opengl.org .. all you have to do today is to import > xml file and generate proper ffi calls. You can, of course, add support of > OpenGL ES.. but why throwing away rest of spec? It just a spec.. you don't > have to use it if you don't need it. Instead, if that feels too big - you > can do it smarter way: > - make package/subpackage/classes for ES edition and for full edition. > It shouldn't cause much trouble if you do it right. > Because throwing away is easiest part - but making something that will > serve for years .. harder, because tomorrow someone else can come and throw > your stuff away :) > OpenGL is around for years now.. and i don't think ES edition will replace > standard.. I would prefer to be able to access to full OpenGL > functionality, at a day i will need it.. why cutting things down? > > There's many ways to do things in smart way so, nothing will be lost. > If you don't want/can't maintain or support full OpenGL support - that's > another story. Then just don't call your project OpenGL - it will cause > confusion to those who expecting things to work out of the box, and finding > out it just OpenGL ES.. > > > > My advise is don't worry about backward compatibility , make it easy, make > > it simple. Don't be afraid to code some of it in C if you have to. > > Sometimes it's far easier to use C than Pharo. Pharo is no magic wand. > > > > > Yep, make it work. That's all what matters.

April 1, 2016

SMTPCLient vs Exchange smtp - always timeout

by Robert Kuszinger

Hello! I'm trying to send an email with SMTPClient. It always stop with timeout here (Data receive timed out): *waitForDataFor: timeout "Wait for the given nr of seconds for data to arrive. Signal a time out or connection close exception if either happens before data becomes available." ^self waitForDataFor: timeout ifClosed: [ConnectionClosed signal: 'Connection closed while waiting for data.'] ifTimedOut: [ConnectionTimedOut signal: 'Data receive timed out.']* Test code from the Playground is at the end. The server is Exchange. I've tested with bare hand telnet connection, it works well. I was able to create email through telnet and send it. But the SMTPClient in pharo always runs to timeout. Others: last message in SMTPClient ( firstLine := self stream nextLine. I saw in debugger) fetchNextResponse "The FTP and similar protocols allow multi-line responses. If the response is multi-line, the fourth character of the first line is a $- and the last line repeats the numeric code but the code is followed by a space." | response result firstLine | result := '' writeStream. * firstLine := self stream nextLine.* [.... *]* Last response from server: (lastResponse instance variable): *354 Start mail input; end with <CRLF>.<CRLF>* (copied from debugger) This is why I forced CRLF... at the end of the message.... It seems to wait a response after sending the data.... Is there any idea what else to check? Thanks: Robert ------------------------------------ Playground code (yes, port 26) *SMTPClient* deliverMailFrom: 'info(a)sender.hu' to: #(' laszlo.gombas(a)recipient.hu') text: ' To: <info(a)sender.hu> From: <laszlo.gombas(a)recipient.hu> Subject: this is a test Hello! ÃRVÃZTÅ°RÅ TÃKÃRFÃRÃGÃP ',Character cr asString,Character lf asString,'.' ,Character cr asString,Character lf asString usingServer: '10.0.0.31:26'.

April 1, 2016

Re: [Pharo-users] OpenGL project

by Igor Stasenko

On 25 March 2016 at 12:51, Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: > Better name it "Pharo OpenGL ES" so people don't get confused why some of > their OpenGL code does not work. You won't finds docs about it , the guy > that made it rarely frequents this forums anymore and his code is based on > a api that is no longer included and supported by Pharo because it was > doing a lot of machine code stuff that was very hard to maintain. > > Why cutting things down to a subset? You have all specs on Opengl.org .. all you have to do today is to import xml file and generate proper ffi calls. You can, of course, add support of OpenGL ES.. but why throwing away rest of spec? It just a spec.. you don't have to use it if you don't need it. Instead, if that feels too big - you can do it smarter way: - make package/subpackage/classes for ES edition and for full edition. It shouldn't cause much trouble if you do it right. Because throwing away is easiest part - but making something that will serve for years .. harder, because tomorrow someone else can come and throw your stuff away :) OpenGL is around for years now.. and i don't think ES edition will replace standard.. I would prefer to be able to access to full OpenGL functionality, at a day i will need it.. why cutting things down? There's many ways to do things in smart way so, nothing will be lost. If you don't want/can't maintain or support full OpenGL support - that's another story. Then just don't call your project OpenGL - it will cause confusion to those who expecting things to work out of the box, and finding out it just OpenGL ES.. > My advise is don't worry about backward compatibility , make it easy, make > it simple. Don't be afraid to code some of it in C if you have to. > Sometimes it's far easier to use C than Pharo. Pharo is no magic wand. > > Yep, make it work. That's all what matters. > And foremost ask a ton of questions. We love questions. > On Fri, 25 Mar 2016 at 11:38, Thibault Raffaillac < > thibault.raffaillac(a)inria.fr> wrote: > >> > Can you include a proper build script? >> >> Yep sorry, here are the steps I used to make it run on OSX: >> $ brew install glfw3 >> $ cc demo.c -lglfw3 -framework OpenGL >> >> For other systems the doc is hopefully detailed enough ( >> http://www.glfw.org/docs/latest/build.html) >> >> > Why do you say ?porting NBOpenGL?? Is it just a matter of rewriting the >> > native calls with the new FFI system? >> NBOpenGL functions were generated automatically from NBGLGenerator, so I >> need to get used to the tool beforehand. It looks like a lot of work was >> put into this, can I find a paper about it? >> Also, IMO this all looks too complex. My point in limiting to ES 2 is not >> just removing functions, I want to make it look simple like the C demo! >> >> Thibault >> >> -- Best regards, Igor Stasenko.

April 1, 2016