- Pharo-users - lists.pharo.org

Detecting a class is abstract

by Hilaire

Hi, Can Nautilius indicate when a class is abstract (i.e. at least one method in the class, then its hierarchy is definted respond subclassResponsability?) I did not find it in the Analyze menu. Thanks Hilaire -- Dr. Geo http://drgeo.eu

April 4, 2016

SMTPClient further - kind of answer

by Robert Kuszinger

Hello, A few days ago I've posted an SMTP related question about timeouts. (SMTPClient sending). I was able the repeat the situation on Linux as well with Postfix SMTP server on the other side (The original question was Windows / Exchange Server) Now smtp works and there are two consequences, at least for Pharo/Seaside beginners like I am :) - Using Halt for debugging in such a Seaside project when sending SMTPClient emails could make this timeout. It waits for signal not coming and it maybe related to timeout handling inside what I don't understand. If you face SMTPClient timeout in the DATA phase of sending an email check if you are debugging (in debugger window, using halts, etc) and try without that (eg. Transcript show: logs or something else to check what is going on). - Pay extra attention to email mime type and content encoding including subject string of the message. Since I'm sending hungarian language emails it was essential. Server answers and sensitivity on exotic email messages depends on the SMTP server implementation in question, but staying minimal on smtp fields is always a good idea. Specify To: and From: fields in the DATA part also. When I created correct email DATA part with correct encoding and removed debugging from the Seaside application code (so debugger was not active when run into SMTP sending) emails started to go out with no problem. good night R

April 3, 2016

Re: [Pharo-users] Tables in Pillar

by stepharo

Le 3/4/16 10:55, Damien Cassou a Ã©crit : > stepharo <stepharo(a)free.fr> writes: > >> Le 31/3/16 17:56, Damien Cassou a Ã©crit : >>> Norbert Hartl <norbert(a)hartl.name> writes: >>> >>>> Wow that sounds a lot of things are possible. Do you have a roadmap? >>> There are plenty of things we would like to do: >>> >>> - clean the issue tracker by doing all the simple things (it's time for >>> users to write their ideas there) >>> >>> - facilitate the creation of new Pillar projects. Currently, it's a hell >>> to start a new book or a new lecture. >>> >>> - simplify Pillar to avoid the current transformation to a build system. >>> We want to remove the dependency to the Mustache template engine. We >>> also want to remove Pillar's ability to compile LaTeX files to PDF. I >>> want Pillar to do just 1 thing: convert a .pillar to a .tex/.html/.*. >>> The rest will move to external projects, reusing as much as possible >>> of what's already there (e.g., GNU/Make) and leveraging other tools >>> (e.g., other template engines, even not implemented in Pharo). >> - Well I would prefer to improve mustache if necessary. Controlling >> the stack of external great tools is important. > The idea is not to make Mustache perfect for every possible use case, Damien can you read what I wrote? Did I say make mustache perfect? No so what is your point? > the idea is that users should be able to pick the template engine that > fits best. and also have a solution that works without relying on a specific tools runnning on a single OS and that we cannot debug. "Je dis juste si mustache a une limitation et quâelle est facile a enlever alors câest mieux dâameliorer mustache car on ameliore mustache on amerliore pillar Et moins on doit maintenir de trucs exterieurs plus on a une solution perenne. Je suis sur que si on demande a norbert dâameliorer mustache il le fera en plus. Am I clear? Now if you do not want that I work and push Pillar tell it to me too and I can do something else. In this moment I'm about to rethink what I want to spend my energy so pillar could be also one less. Stef

April 3, 2016

Re: [Pharo-users] Tables in Pillar

by Damien Cassou

stepharo <stepharo(a)free.fr> writes: > Le 31/3/16 17:56, Damien Cassou a Ã©crit : >> Norbert Hartl <norbert(a)hartl.name> writes: >> >>> Wow that sounds a lot of things are possible. Do you have a roadmap? >> There are plenty of things we would like to do: >> >> - clean the issue tracker by doing all the simple things (it's time for >> users to write their ideas there) >> >> - facilitate the creation of new Pillar projects. Currently, it's a hell >> to start a new book or a new lecture. >> >> - simplify Pillar to avoid the current transformation to a build system. >> We want to remove the dependency to the Mustache template engine. We >> also want to remove Pillar's ability to compile LaTeX files to PDF. I >> want Pillar to do just 1 thing: convert a .pillar to a .tex/.html/.*. >> The rest will move to external projects, reusing as much as possible >> of what's already there (e.g., GNU/Make) and leveraging other tools >> (e.g., other template engines, even not implemented in Pharo). > - Well I would prefer to improve mustache if necessary. Controlling > the stack of external great tools is important. The idea is not to make Mustache perfect for every possible use case, the idea is that users should be able to pick the template engine that fits best. -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." --Winston Churchill

April 3, 2016

Re: [Pharo-users] STON UUID in the key

by Peter UhnÃ¡k

Perfect! Thanks On Sat, Apr 2, 2016 at 11:21 PM, Henrik Nergaard <henrik.nergaard(a)uia.no> wrote: > You need to set âallowComplexMapKeysâ in StonReader to true for it to > handle objects as keys. > > > > | reader | > > > > reader := STONReader new. > > reader allowComplexMapKeys: true. > > reader on: (STON toStringPretty: (Object new-> Morph new -> nil)) > readStream. > > > > reader next. > > > > > > Best regards, > > Henrik > > > > *From:* Pharo-users [mailto:pharo-users-bounces@lists.pharo.org] *On > Behalf Of *Peter UhnÃ¡k > *Sent:* Saturday, April 2, 2016 10:45 PM > *To:* Pharo Users List <pharo-users(a)lists.pharo.org> > *Subject:* [Pharo-users] STON UUID in the key > > > > Why does this fail? > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > STON fromString: ( > > STON toStringPretty: (Dictionary with: UUID new -> nil) > > ) > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > > I would assume that if it can be serialized, then it should be also > parsable. > > > > Having scalars for keys is JSON (and JavaScript) limitation because it's > stupid, > > but if Smalltalk can have any hashable object for key (so any object), > then it should be also possible to STON it in/out. > > > > Would this be hard to change? > > > > Peter >

April 2, 2016

Re: [Pharo-users] STON UUID in the key

by Henrik Nergaard

You need to set âallowComplexMapKeysâ in StonReader to true for it to handle objects as keys. | reader | reader := STONReader new. reader allowComplexMapKeys: true. reader on: (STON toStringPretty: (Object new-> Morph new -> nil)) readStream. reader next. Best regards, Henrik From: Pharo-users [mailto:pharo-users-bounces@lists.pharo.org] On Behalf Of Peter UhnÃ¡k Sent: Saturday, April 2, 2016 10:45 PM To: Pharo Users List <pharo-users(a)lists.pharo.org> Subject: [Pharo-users] STON UUID in the key Why does this fail? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ STON fromString: ( STON toStringPretty: (Dictionary with: UUID new -> nil) ) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ I would assume that if it can be serialized, then it should be also parsable. Having scalars for keys is JSON (and JavaScript) limitation because it's stupid, but if Smalltalk can have any hashable object for key (so any object), then it should be also possible to STON it in/out. Would this be hard to change? Peter

April 2, 2016

STON UUID in the key

by Peter UhnÃ¡k

Why does this fail? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ STON fromString: ( STON toStringPretty: (Dictionary with: UUID new -> nil) ) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ I would assume that if it can be serialized, then it should be also parsable. Having scalars for keys is JSON (and JavaScript) limitation because it's stupid, but if Smalltalk can have any hashable object for key (so any object), then it should be also possible to STON it in/out. Would this be hard to change? Peter

April 2, 2016

Re: [Pharo-users] Tables in Pillar

by stepharo

Le 31/3/16 17:56, Damien Cassou a Ã©crit : > Norbert Hartl <norbert(a)hartl.name> writes: > >> Wow that sounds a lot of things are possible. Do you have a roadmap? > There are plenty of things we would like to do: > > - clean the issue tracker by doing all the simple things (it's time for > users to write their ideas there) > > - facilitate the creation of new Pillar projects. Currently, it's a hell > to start a new book or a new lecture. > > - simplify Pillar to avoid the current transformation to a build system. > We want to remove the dependency to the Mustache template engine. We > also want to remove Pillar's ability to compile LaTeX files to PDF. I > want Pillar to do just 1 thing: convert a .pillar to a .tex/.html/.*. > The rest will move to external projects, reusing as much as possible > of what's already there (e.g., GNU/Make) and leveraging other tools > (e.g., other template engines, even not implemented in Pharo). - Well I would prefer to improve mustache if necessary. Controlling the stack of external great tools is important. > > - refactor and recompose Pillar's source code to break all package > cycles. Also make sure no new cycle is created in the future by adding > a check in the test suite. - make a minimal Pillar renderer so that class comment could be nicely rendered :) > > - add a new XML-based exporter to publish the Mooc on a dedicated > platform > > - take care of all the user's feedback during the internship - better support for ecstatic - epub? :) > >

April 2, 2016

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