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

Re: [Pharo-users] Detecting a class is abstract

by Hilaire

Thanks Peter. So I guess, Nautilus does not offer this functionnality. Hilaire -- Dr. Geo http://drgeo.eu

April 4, 2016

Re: [Pharo-users] Detecting a class is abstract

by Peter UhnÃ¡k

1. To tell whether a class is abstract: isAbstract := [ :aClass | (aClass whichSelectorsReferTo: #subclassResponsibility) isNotEmpty or: [ (aClass respondsTo: #isAbstract) and: [ aClass isAbstract ] ] ] Just be aware that some classes are "abstract", but you can actually instantiate them, because in #new they return something else. isAbstract value: String "true" 2. To change an icon for a single class (and it's children), add a method to class-side named "systemIcon" 3. To conditionally change an icon for all classes 3.a.) override Object>>systemIcon and make a test based on the isAbstract in 1) 3.b.) or do the same, but in AbstractNautilusUI>>#classIconFor: , this is where test icons are added for example Peter On Mon, Apr 4, 2016 at 11:49 AM, Hilaire <hilaire(a)drgeo.eu> wrote: > 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

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