One of the things I really like about ENVY (as found in VA Smalltalk) is
that packages are formally modelled and are distinct from method
categories.
(Another is that a method can have multiple categories.) And by formally
modelling packages, one can easily include proper dependency
I would do it like this: use a wrapping stream to skip comments.
===
Name: STON-Core-SvenVanCaekenberghe.59
Author: SvenVanCaekenberghe
Time: 8 June 2015, 11:34:32.886167 pm
UUID: 7ab942b5-9d1a-44c3-9d58-da29feb72380
Ancestors: STON-Core-SvenVanCaekenberghe.58
Add experimental
Sven Van Caekenberghe s...@stfx.eu writes:
What do you think ?
this looks like a very good solution.
Thank you very much Sven
--
Damien Cassou
http://damiencassou.seasidehosting.st
Success is the ability to go from one failure to another without
losing enthusiasm. --Winston Churchill
Hi Ben!
I answer between lines. If the discussion continues maybe we should move to
another thread also ^^.
El sáb., 6 de jun. de 2015 a la(s) 12:39 p. m., Ben Coman
b...@openinworld.com escribió:
On Sat, Jun 6, 2015 at 5:26 PM, Guillermo Polito
guillermopol...@gmail.com wrote:
Actually we
I think it is a good idea to get Pharo at Bitnami as it will increase the
visibility of the project to the world and put us to the rightful place
alongside with other platforms like Python, Ruby and other :) Moreover it
opens new clouds like Azure, Google Cloud (and whatever Bitnami is partnered
On 08 Jun 2015, at 15:44, Clara Allende clari.alle...@gmail.com wrote:
2015-06-08 10:17 GMT-03:00 Marcus Denker marcus.den...@inria.fr
mailto:marcus.den...@inria.fr:
Hello,
sorry for answering late… last week was less productive than I hoped. There
is not yet any documentation as
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
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
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.dema...@inria.fr
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
2015-06-08 10:17 GMT-03:00 Marcus Denker marcus.den...@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
Branch: refs/tags/50094
Home: https://github.com/pharo-project/pharo-core
Branch: refs/heads/5.0
Home: https://github.com/pharo-project/pharo-core
Commit: 67090097bdda0e242f5729ccff34c549f9b81df7
https://github.com/pharo-project/pharo-core/commit/67090097bdda0e242f5729ccff34c549f9b81df7
Author: Jenkins Build Server bo...@pharo-project.org
Date:
On Mon, Jun 8, 2015 at 4:08 PM, Guillermo Polito
guillermopol...@gmail.com wrote:
Hi Ben!
I answer between lines. If the discussion continues maybe we should move to
another thread also ^^.
I don't have much to add, but a new thread none the less.
El sáb., 6 de jun. de 2015 a la(s) 12:39 p.
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.
What I am working on now (that is, last week) was how to pass parameters to the
meta. I now have a design that should work.
(things are
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
Le 8 juin 2015 à 16:59, Sven Van Caekenberghe a écrit :
On 08 Jun 2015, at 16:51, Christophe Demarey christophe.dema...@inria.fr
wrote:
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
Sven Van Caekenberghe s...@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
On 08 Jun 2015, at 17:03, Damien Cassou damien.cas...@inria.fr wrote:
Sven Van Caekenberghe s...@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
Well at least for me it is certainly not clear what release policy is Roassal
following; i.e. if I see a minor version change what to expect, if any BC
breaks were introduced, etc. Of course this is extra effort for the person
doing it, so it should be taken with care. But there are
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
On 08 Jun 2015, at 16:51, Christophe Demarey christophe.dema...@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
Le 8 juin 2015 à 17:03, Damien Cassou a écrit :
Sven Van Caekenberghe s...@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).
If not we could maybe write a yaml parser :)
http://yaml.org/
It has no brackets, it is also hierarchical and it supports comments.
El lun., 8 de jun. de 2015 a la(s) 5:16 p. m., Sven Van Caekenberghe
s...@stfx.eu escribió:
On 08 Jun 2015, at 17:03, Damien Cassou damien.cas...@inria.fr
Damien Cassou-2 wrote
Sven Van Caekenberghe lt;
sven@
gt; 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.
Branch: refs/tags/50095
Home: https://github.com/pharo-project/pharo-core
Branch: refs/heads/5.0
Home: https://github.com/pharo-project/pharo-core
Commit: 4c7f55dbcd218076a6331aaa4aa858bece07905a
https://github.com/pharo-project/pharo-core/commit/4c7f55dbcd218076a6331aaa4aa858bece07905a
Author: Jenkins Build Server bo...@pharo-project.org
Date:
Ben Coman wrote
On Sat, Jun 6, 2015 at 5:26 PM, Guillermo Polito
lt;
guillermopolito@
gt; wrote:
Actually we just want to have a kind of split in:
- essential
- non-essential
I guess you have scripts outside the image to shrink the image and
then bootstrap it. However these are not
28 matches
Mail list logo
