June 2015 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Comments in STON

by Christophe Demarey

Le 8 juin 2015 Ã 17:03, Damien Cassou a Ã©crit : > > Sven Van Caekenberghe <sven(a)stfx.eu> writes: > >> I am not so sure we should add that. >> >> The JSON spec explicitly does not allow comments because of fear of abuse (that the comments would be used to add semantic meaning outside the spec). > > > really? That's surprising. Comments in configuration files are very > important. Even more when the configuration files are templates for new > users. +1 but it may outline that json/ston is not well suited to configuration files

June 8, 2015

Re: [Pharo-dev] Comments in STON

by Damien Cassou

Sven Van Caekenberghe <sven(a)stfx.eu> writes: > I am not so sure we should add that. > > The JSON spec explicitly does not allow comments because of fear of abuse (that the comments would be used to add semantic meaning outside the spec). really? That's surprising. Comments in configuration files are very important. Even more when the configuration files are templates for new users. -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." --Winston Churchill

June 8, 2015

Re: [Pharo-dev] catch server-side errors of a rest server

by Sven Van Caekenberghe

> On 08 Jun 2015, at 16:51, Christophe Demarey <Christophe.Demarey(a)inria.fr> wrote: > > > Le 8 juin 2015 Ã 16:33, Sven Van Caekenberghe a Ã©crit : > >> Did you see Zn[JSON]RestServerDelegate>>#errorResponse:code:message: and follow its users ? > > yes. I saw #serverError:exception: that is using it (and also a bunch of other useful methods) > >> Also, ZnRestServerDelegate>>#handleRequest: does transform any error in a proper REST server error. > > Strangely, I did not catch this one. Surprising because it is one of the two users of #serverError:exception: > It is exactly what I search for. Good. >> Does that help ? > > Yes, when you put into production, you just need to remove the call to debugMode: true. I forgot this one and then, was surprised to see the debugger popping. > > By the way, what is the best strategy to keep a trace of failures. I can see you log failures as announcements. Do you have an object in the image recording all announcements? No, but the beauty of logging as objects is that you can do what you want, just subscribe to ZnLogEvent announcer And filter/do what you want. > Thanks Sven.

June 8, 2015

Re: [Pharo-dev] catch server-side errors of a rest server

by Christophe Demarey

Le 8 juin 2015 Ã 16:33, Sven Van Caekenberghe a Ã©crit : > Did you see Zn[JSON]RestServerDelegate>>#errorResponse:code:message: and follow its users ? yes. I saw #serverError:exception: that is using it (and also a bunch of other useful methods) > Also, ZnRestServerDelegate>>#handleRequest: does transform any error in a proper REST server error. Strangely, I did not catch this one. Surprising because it is one of the two users of #serverError:exception: It is exactly what I search for. > Does that help ? Yes, when you put into production, you just need to remove the call to debugMode: true. I forgot this one and then, was surprised to see the debugger popping. By the way, what is the best strategy to keep a trace of failures. I can see you log failures as announcements. Do you have an object in the image recording all announcements? Thanks Sven.

June 8, 2015

Re: [Pharo-dev] Comments in STON

by Sven Van Caekenberghe

I am not so sure we should add that. The JSON spec explicitly does not allow comments because of fear of abuse (that the comments would be used to add semantic meaning outside the spec). I have to think about that. In any case, I think comments with open/close are generally more useful. > On 08 Jun 2015, at 16:12, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > > Hi Sven, list, > > I'm using Pillar, and thus STON for its configuration file. And since I want users to change configuration files as they want, I wanted to add some comments explaining the meaning of the file fields. > > This raises the question: How can I write comments in a ston file? I was checking the STON reader and it looks like that is not supported. > > What should be a good comment format? > > { > /* The site id is.... */ > % comment line > ## comment line > -- comment line > "siteid" : "" > } > > Guille

June 8, 2015

Re: [Pharo-dev] catch server-side errors of a rest server

by Sven Van Caekenberghe

Did you see Zn[JSON]RestServerDelegate>>#errorResponse:code:message: and follow its users ? Also, ZnRestServerDelegate>>#handleRequest: does transform any error in a proper REST server error. Does that help ? > On 08 Jun 2015, at 16:11, Christophe Demarey <Christophe.Demarey(a)inria.fr> wrote: > > Hi, > > When you offer a ReST API, you may have errors on the server side. > I wonder how you manage that. > In Zinc-Rest implementation, I did not see a common mechanism to handle Error(s) occurring server side to convert them to HTTP Internal Server Error (500) error code for example. > It looks like a good practice but I would like to know about your practices. > Do you just deactivate the debugger? Do you catch Errors? other? > > Thanks, > Christophe.

June 8, 2015

Comments in STON

by Guillermo Polito

Hi Sven, list, I'm using Pillar, and thus STON for its configuration file. And since I want users to change configuration files as they want, I wanted to add some comments explaining the meaning of the file fields. This raises the question: How can I write comments in a ston file? I was checking the STON reader and it looks like that is not supported. What should be a good comment format? { /* The site id is.... */ % comment line ## comment line -- comment line "siteid" : "" } Guille

June 8, 2015

catch server-side errors of a rest server

by Christophe Demarey

Hi, When you offer a ReST API, you may have errors on the server side. I wonder how you manage that. In Zinc-Rest implementation, I did not see a common mechanism to handle Error(s) occurring server side to convert them to HTTP Internal Server Error (500) error code for example. It looks like a good practice but I would like to know about your practices. Do you just deactivate the debugger? Do you catch Errors? other? Thanks, Christophe.

June 8, 2015

Re: [Pharo-dev] [Pharo-users] Pharo on bitnami

by Emilio Oca

Hi, Yes, my experience with bitnami's products and assistance is really good too. Besides running in the cloud, I think that having installer scrips to deploy on Windows, Osx or Ubuntu and virtual machines increases chances to successfully deploy on, for example, reluctant IT guys' corporate servers. Best Emilio -----Mensaje original----- De: Pharo-users [mailto:pharo-users-bounces@lists.pharo.org] En nombre de Offray Vladimir Luna CÃ¡rdenas Enviado el: Domingo, 07 de Junio de 2015 14:59 Para: pharo-users(a)lists.pharo.org Asunto: Re: [Pharo-users] [Pharo-dev] Pharo on bitnami Hi, I have been using Bitnami and I think that they're really good at providing "execute and deploy" stacks for a lot of applications which are cumbersome to configure and complicated. They're a real time saver. The only one similar offer I know we have is Pharo Cloud but the advantage of a Bitnami Pharo stack is that they could run on Digital Ocean with a more versatile stack and more attractive prices. In fact that's my approach when I need to deploy a stack I usually choose Bitnami Stack + digital ocean for hosting, if the stack I'm looking for is available in bitnami, which is usually cheaper that Specific stack hosting. I don't know if Pharo Cloud could be the company that Bitnami is looking for as a Software partner for deploying. Cheers, Offray On 07/06/15 09:14, Norbert Hartl wrote: > Could be something good. I wanted to figure out what is to provide but I didn't find anything useful in all this massive amount of marketing bullshit on their site. Do you really contact them before you can see how you can provide a package? > > Norbert > >> Am 07.06.2015 um 13:08 schrieb stepharo <stepharo(a)free.fr>: >> >> Hi pharoers >> >> we got in contact with bitnami and I would love to see two bitnami apps around Pharo: >> - basic pharo >> - pharo + seaside + magritte + voyage (mongo pharo layer) + >> mongodb >> >> So who would like to help pushing this effort? >> >> Stef >> >> Begin forwarded message: >> >> From: Kevin Franklin <kevin(a)bitnami.com> >> Subject: Introducing Bitnami... >> Date: 5 Jun 2015 10:57:36 GMT+2 >> To: <board(a)pharo.org> >> >> Hello Pharo Association >> >> I wondered if you knew about Bitnami. Please check us out at www.bitnami.com. We provide over 120 apps and development stacks â many of them open-source. >> If you would like Pharo to be included in our marketplace, we have a contest https://bitnami.com/contest were you can nominate it, and encourage your community to vote for its inclusion. >> >> Also, I wondered if you could put me in touch with any commercial >> companies within and around the Pharo ecosystem that might like to >> work with us as a software partner >> https://bitnami.com/partners/software >> >> Kind regards >> Kevin >> >> -- >> Kevin Franklin >> Director of Business Development, Bitnami >> +44 78 2525 6020 >> @kevinjfranklin >> >> Run your favorite apps in the cloud with Bitnami >> >> Confidential - All Rights Reserved. >> Bitnami Â© 2015 >> > >

June 8, 2015

Re: [Pharo-dev] [Reflectivity] HowTo

by Marcus Denker

> On 08 Jun 2015, at 15:44, Clara Allende <clari.allende(a)gmail.com> wrote: > > > > 2015-06-08 10:17 GMT-03:00 Marcus Denker <marcus.denker(a)inria.fr <mailto:marcus.denker@inria.fr>>: > Hello, > > sorry for answering lateâ¦ last week was less productive than I hoped. There is not yet any documentation as I am busy actually implementing > things. > > There is my blog <https://clariallende.wordpress.com/>, with a little bit of documentation, but not up-to-date :( . Anyway, if your intention is to get some insight on what reflectivity is, and get a short and *very simplified* explanation of how it works, you can start there. > Itâs clear that we need good documentation.. but I want to first have a final version of the implementationâ¦ with all the details fixedâ¦ like always, progress is slower than anticipated. I try to block as much time as possible for the rest of the month to get it done. Marcus

June 8, 2015