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

Re: [Pharo-dev] Comments in STON

by Sven Van Caekenberghe

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 STONCStyleCommentsSkipStream and tests === Name: STON-Tests-SvenVanCaekenberghe.54 Author: SvenVanCaekenberghe Time: 8 June 2015, 11:34:52.918771 pm UUID: 3dcb2c9c-6efe-4d62-bf36-3bbe91f09d08 Ancestors: STON-Tests-SvenVanCaekenberghe.53 Add experimental STONCStyleCommentsSkipStream and tests === Then you can do as follows: STON fromStream: (STONCStyleCommentsSkipStream on: 'Point[/* this is X*/ 1, /* this is Y*/ 2] // Nice huh ?' readStream). => 1@2 STON fromStream: (STONCStyleCommentsSkipStream on: '// Here is how you create a point: Point[ // this is X 1, // this is Y 2 ] // Nice huh ?' readStream). => 1@2 This helper class would be useable in other contexts too (like NeoJSON). The advantage is that it does not change the STON (or JSON) syntax itself, it just add some functionality for those who want it. What do you think ? Sven PS: this probably needs some more testing > On 08 Jun 2015, at 17:16, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> >> On 08 Jun 2015, at 17:03, Damien Cassou <damien.cassou(a)inria.fr> wrote: >> >> >> 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. > > I know some people are using STON in ways that I did not originally anticipate, that is of course cool, but writing configuration files was not the original goal. STON is a version of JSON that is closer to our object model. > > Like I said, I will think about it. > >> -- >> 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] Refactoring File Package

by Sergio Fedi

> 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 relationships > and more easily detect references to behaviours outside a packages > prerequisites chain. > > I realize that is a huge departure from current Squeak and Pharo practice. > But, I hope it's one that will get consideration. (Given all the other first > class modelling you've been adding to Pharo, I think this would be > consistent with the current philosophy!) +1 Multiple categories for methods and proper modelling of Packages seems like a very strong feature to have. Multiple tags per class is also a big plus.

June 8, 2015

Re: [Pharo-dev] Comments in STON

by Richard Sargent

Damien Cassou-2 wrote > Sven Van Caekenberghe < > sven@ > > 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. I think you may have combined two requirements and come up with a "I can adapt this existing idea to handle both" solution. In my experience, I would suggest the word "adapt" in that phrase /usually ends up/ being better read as "pervert". So, let's step back for a moment and start by clearly and precisely identifying the actual requirements. As I interpret the foregoing discussion, there are two. 1) We want the ability to include information in a configuration which can be used to document, explain, guide those who come after. 2) We want to provide a template configuration that will make it easier for people to figure out how to create a good configuration. I will also remind everyone of one thing that seems to be a fundamentally important aspect of Smalltalk programming: we prefer code over comments. For example, I came across some unit tests which included comments like "The result should be blah". Generally, we would write that as "self assert: result equals: blah". So, let's add this requirement: 3) The best implementation of a "spec" like a configuration will maximize the DSL capability of Smalltalk. In my opinion, none of these requirements are well satisfied by adding comments to the STON syntax. The first requirement, again in my opinion, is best handled by modelling a narrative aspect in configurations. I'm not suggestion how that should be done nor what to call it. The second requirement seems best satisfied by providing a template configuration file with the its various aspects specified by some example content that clearly illustrates the right way to do it. And the third requirement is satisfied when the modelling of the configuration formalizes what it is we want it to convey. > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Success is the ability to go from one failure to another without > losing enthusiasm." --Winston Churchill -- View this message in context: http://forum.world.st/Comments-in-STON-tp4830944p4830990.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

June 8, 2015

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/50095 Home: https://github.com/pharo-project/pharo-core

June 8, 2015

[pharo-project/pharo-core] 4c7f55: 50095

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 4c7f55dbcd218076a6331aaa4aa858bece07905a https://github.com/pharo-project/pharo-core/commit/4c7f55dbcd218076a6331aaa… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-06-08 (Mon, 08 Jun 2015) Changed paths: M Fuel.package/extension/Character/instance/serializeOn_.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50094.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50095.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50094.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50095.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st R Shout.package/extension/FileContentsBrowser/instance/shoutAboutToStyle_.st R Tool-FilePackageBrowser.package/FileContentsBrowser.class/README.md R Tool-FilePackageBrowser.package/FileContentsBrowser.class/class/System-FileRegistry/fileReaderServicesForDirectory_.st R Tool-FilePackageBrowser.package/FileContentsBrowser.class/class/System-FileRegistry/fileReaderServicesForFile_suffix_.st R Tool-FilePackageBrowser.package/FileContentsBrowser.class/class/System-FileRegistry/selectAndBrowseFile_.st R Tool-FilePackageBrowser.package/FileContentsBrowser.class/class/System-FileRegistry/serviceBrowseCode.st R Tool-FilePackageBrowser.package/FileContentsBrowser.class/class/System-FileRegistry/serviceBrowseCodeFiles.st R Tool-FilePackageBrowser.package/FileContentsBrowser.class/class/System-FileRegistry/serviceBrowseCompressedCode.st R Tool-FilePackageBrowser.package/FileContentsBrowser.class/class/System-FileRegistry/services.st R Tool-FilePackageBrowser.package/FileContentsBrowser.class/class/initialization/initialize.st R Tool-FilePackageBrowser.package/FileContentsBrowser.class/class/initialization/unload.st R Tool-FilePackageBrowser.package/FileContentsBrowser.class/class/instance creation/browseCompressedCodeStream_.st R Tool-FilePackageBrowser.package/FileContentsBrowser.class/class/instance creation/browseFile_.st R Tool-FilePackageBrowser.package/FileContentsBrowser.class/class/instance creation/browseFiles_.st R Tool-FilePackageBrowser.package/FileContentsBrowser.class/class/instance creation/browseStream_.st R Tool-FilePackageBrowser.package/FileContentsBrowser.class/class/instance creation/browseStream_named_.st R Tool-FilePackageBrowser.package/FileContentsBrowser.class/definition.st R Tool-FilePackageBrowser.package/FileContentsBrowser.class/instance/accessing/contents.st R Tool-FilePackageBrowser.package/FileContentsBrowser.class/instance/accessing/contents_notifying_.st R Tool-FilePackageBrowser.package/FileContentsBrowser.class/instance/accessing/packages.st R Tool-FilePackageBrowser.package/FileContentsBrowser.class/instance/accessing/packages_.st R Tool-FilePackageBrowser.package/FileContentsBrowser.class/instance/accessing/selectedPackage.st R Tool-FilePackageBrowser.package/FileContentsBrowser.class/instance/class list/browseMethodFull.st R Tool-FilePackageBrowser.package/FileContentsBrowser.class/instance/class list/classList.st R Tool-FilePackageBrowser.package/FileContentsBrowser.class/instance/class list/findClass.st R Tool-FilePackageBrowser.package/FileContentsBrowser.class/instance/class list/renameClass.st R Tool-FilePackageBrowser.package/FileContentsBrowser.class/instance/class list/selectedClass.st R Tool-FilePackageBrowser.package/FileContentsBrowser.class/instance/creation/addLowerPanesTo_at_with_.st R Tool-FilePackageBrowser.package/FileContentsBrowser.class/instance/creation/createViews.st R Tool-FilePackageBrowser.package/FileContentsBrowser.class/instance/creation/messageList.st R Tool-FilePackageBrowser.package/FileContentsBrowser.class/instance/creation/open.st R Tool-FilePackageBrowser.package/FileContentsBrowser.class/instance/diffs/methodDiffFor_class_selector_meta_.st R Tool-FilePackageBrowser.package/FileContentsBrowser.class/instance/diffs/modifiedClassDefinition.st R Tool-FilePackageBrowser.package/FileContentsBrowser.class/instance/edit pane/selectedBytecodes.st R Tool-FilePackageBrowser.package/FileContentsBrowser.class/instance/edit pane/selectedMessage.st R Tool-FilePackageBrowser.package/FileContentsBrowser.class/instance/filein%2Ffileout/fileInClass.st R Tool-FilePackageBrowser.package/FileContentsBrowser.class/instance/filein%2Ffileout/fileInMessage.st R Tool-FilePackageBrowser.package/FileContentsBrowser.class/instance/filein%2Ffileout/fileInMessageCategories.st R Tool-FilePackageBrowser.package/FileContentsBrowser.class/instance/filein%2Ffileout/fileOutClass.st R Tool-FilePackageBrowser.package/FileContentsBrowser.class/instance/filein%2Ffileout/fileOutMessage.st R Tool-FilePackageBrowser.package/FileContentsBrowser.class/instance/filein%2Ffileout/fileOutMessageCategories.st R Tool-FilePackageBrowser.package/FileContentsBrowser.class/instance/filein%2Ffileout/fileOutPackage.st R Tool-FilePackageBrowser.package/FileContentsBrowser.class/instance/infoview/extraInfo.st R Tool-FilePackageBrowser.package/FileContentsBrowser.class/instance/infoview/infoViewContents.st R Tool-FilePackageBrowser.package/FileContentsBrowser.class/instance/infoview/packageInfo_.st R Tool-FilePackageBrowser.package/FileContentsBrowser.class/instance/infoview/updateInfoView.st R Tool-FilePackageBrowser.package/FileContentsBrowser.class/instance/initialization/defaultBrowserTitle.st R Tool-FilePackageBrowser.package/FileContentsBrowser.class/instance/keys/classListKey_from_.st R Tool-FilePackageBrowser.package/FileContentsBrowser.class/instance/keys/messageListKey_from_.st R Tool-FilePackageBrowser.package/FileContentsBrowser.class/instance/keys/packageListKey_from_.st R Tool-FilePackageBrowser.package/FileContentsBrowser.class/instance/menus/classListMenu_.st R Tool-FilePackageBrowser.package/FileContentsBrowser.class/instance/menus/classListMenu_shifted_.st R Tool-FilePackageBrowser.package/FileContentsBrowser.class/instance/menus/contentsSymbolQuints.st R Tool-FilePackageBrowser.package/FileContentsBrowser.class/instance/menus/messageCategoryMenu_.st R Tool-FilePackageBrowser.package/FileContentsBrowser.class/instance/menus/messageListMenu_.st R Tool-FilePackageBrowser.package/FileContentsBrowser.class/instance/metaclass/selectedClassOrMetaClass.st R Tool-FilePackageBrowser.package/FileContentsBrowser.class/instance/metaclass/setClassOrganizer.st R Tool-FilePackageBrowser.package/FileContentsBrowser.class/instance/other/browseSenders.st R Tool-FilePackageBrowser.package/FileContentsBrowser.class/instance/other/browseVersions.st R Tool-FilePackageBrowser.package/FileContentsBrowser.class/instance/other/changeMessageCategories_.st R Tool-FilePackageBrowser.package/FileContentsBrowser.class/instance/other/didCodeChangeElsewhere.st R Tool-FilePackageBrowser.package/FileContentsBrowser.class/instance/other/labelString.st R Tool-FilePackageBrowser.package/FileContentsBrowser.class/instance/other/methodHierarchy.st R Tool-FilePackageBrowser.package/FileContentsBrowser.class/instance/removing/removeClass.st R Tool-FilePackageBrowser.package/FileContentsBrowser.class/instance/removing/removeMessage.st R Tool-FilePackageBrowser.package/FileContentsBrowser.class/instance/removing/removeMessageCategory.st R Tool-FilePackageBrowser.package/FileContentsBrowser.class/instance/removing/removePackage.st R Tool-FilePackageBrowser.package/FileContentsBrowser.class/instance/removing/removeUnmodifiedCategories.st R Tool-FilePackageBrowser.package/FileContentsBrowser.class/instance/removing/removeUnmodifiedMethods.st Log Message: ----------- 50095 15715 Character>>#serializeOn: needs to use accessor to value https://pharo.fogbugz.com/f/cases/15715 15712 Remove FileContentsBrowser https://pharo.fogbugz.com/f/cases/15712 http://files.pharo.org/image/50/50095.zip

June 8, 2015

Re: [Pharo-dev] Refactoring File Package

by Richard Sargent

Ben Coman wrote > On Sat, Jun 6, 2015 at 5:26 PM, Guillermo Polito > < > guillermopolito@ > > 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 necessarily visible to > everyone and I am wondering once the bootstrap goal is achieved you > will handle the entropy of ongoing development by many others > accidentally introducing dependencies that breaks the bootstrap? > > Also what I have seen is classes being moved out of their current > packaging (sorry I forget the details, but I think it was moved out of > System) into a new top-level package, which I think loses something in > structure and might pollute the top-level packages. > > So considering the recent discussion of package tags, I wonder if > somehow we could have a "Bootstrap" tag and realtime critics that > complain if Bootstrap-tagged-class references any > non-Bootstrap-tagged-class. There might even be several levels of > Bootstrap tags. This would improve ongoing visibility of the > bootstrap structure and help the rest of us to not shoot it in the > foot. 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 relationships and more easily detect references to behaviours outside a packages prerequisites chain. I realize that is a huge departure from current Squeak and Pharo practice. But, I hope it's one that will get consideration. (Given all the other first class modelling you've been adding to Pharo, I think this would be consistent with the current philosophy!) > I wonder also if tags might also be extended to method protocols, so > you can have a method with the "accessors" tag and also the > "bootstrap" tag, so that even a Bootstrap-tagged-class can be further > minimised by the methods it needs during bootstrap. Otherwise I guess > to minimise the methods in a Bootstrap-tagged-class, later extension > by another package could not add methods to the "accessors" protocol. > > P.S. I know I do a lot of wondering, and of course divergent thought > is easier than concrete answers. > cheers -ben > > >> >> Then the bootstrap will include essential packages at the beginning and >> non-essential will be just loaded on top. >> >> The rationale is: the smaller the kernel, the fastest the bootstrap, and >> with it the feedback loop we have. >> >> That's why I was working on the File abstractions, and splitting some >> other >> kernel package. >> >> El vie., 5 de jun. de 2015 a la(s) 7:35 p. m., stepharo < > stepharo@ > > >> escribiÃ³: >>> >>> Yes sven but with guille we are working on a really small kernel. So we >>> can duplicate just the classes we need but I would prefer not >>> but we can do it. The size is important for us because it takes time to >>> bootstrap. >>> >>> Stef >>> >>> Le 5/6/15 19:06, Sven Van Caekenberghe a Ã©crit : >>> >> On 05 Jun 2015, at 18:43, Guillermo Polito < > guillermopolito@ > > >>> >> wrote: >>> >> >>> >> The only encoder that makes a bit of noise to me is the ZnByteEncoder >>> >> that contains a lot of mapping tables for mostly unused encodings >>> > 67 encoding specifications, each a 128 array. The method constant is >>> > shared when used. >>> > In the beginning there were only a couple, one day I added many more, >>> > some people need them. >>> > For me, the cost is reasonable. >>> > >>> >> (plus methods with metadata to recreate them)... >>> > That is just two method (which is pretty cool, I love spec based >>> > programming). >>> > >>> >> El vie., 5 de jun. de 2015 a la(s) 6:30 p. m., Sven Van Caekenberghe >>> >> < > sven@ > > escribiÃ³: >>> >> >>> >>> On 05 Jun 2015, at 18:20, stepharo < > stepharo@ > > wrote: >>> >>> >>> >>> Sven >>> >>> >>> >>> we were talking about splitting your package into two parts :) >>> >>> Would you be ok to get the basic encoders in a separate package? >>> >> Zinc-Character-Encoding is already a separate package, it depends on >>> >> nothing. >>> >> Zinc-Resource-Meta is next up (containing URL and Mime-Type). >>> >> Both are completely independent of any HTTP stuff. >>> >> All this is by design. >>> >> >>> >> You probably mean that you want a separate config ? Right now they >>> are >>> >> just a groups. >>> >> >>> >>> We were also thinking that NullEncoder could be called AsciiEncoder? >>> >> Maybe, maybe not, let me think about that a bit. >>> >> >>> >>> Stef >>> >>> >>> >>>>> On 05 Jun 2015, at 18:09, Damien Cassou < > damien.cassou@ > > >>> >>>>> wrote: >>> >>>>> >>> >>>>> >>> >>>>> Guillermo Polito < > guillermopolito@ > > writes: >>> >>>>> >>> >>>>>> Well, I made a cleaner implementation at the side with >>> >>>>>> >>> >>>>>> - a simple File object that is a sequential File as we all know >>> >>>>>> - a binary File stream on top of it that is composable with Zn >>> >>>>>> encoders and >>> >>>>>> other decorators >>> >>>>>> - a new interface to access Stdio streams >>> >>>>> that's really good news Guillermo. >>> >>>> Yes it is (need time to look at this in detail) >>> >>>> >>> >>>>> Is it ok to make File reading depend >>> >>>>> on Zinc? This sounds strange. Wouldn't that make bootstrapping >>> >>>>> harder? >>> >>>> It does not depend on the HTTP part, but on the Encoding part below >>> >>>> it, so that should be OK. >>> >>>> >>> >>>>> -- >>> >>>>> Damien Cassou >>> >>>>> http://damiencassou.seasidehosting.st >>> >>>>> >>> >>>>> "Success is the ability to go from one failure to another without >>> >>>>> losing enthusiasm." --Winston Churchill >>> >>>>> >>> >>>> >>> >>> >>> >> >>> > >>> > >>> >>> >> -- View this message in context: http://forum.world.st/Refactoring-File-Package-tp4830625p4830987.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

June 8, 2015

Re: [Pharo-dev] Comments in STON

by Guillermo Polito

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 < sven(a)stfx.eu> escribiÃ³: > > > On 08 Jun 2015, at 17:03, Damien Cassou <damien.cassou(a)inria.fr> wrote: > > > > > > 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. > > I know some people are using STON in ways that I did not originally > anticipate, that is of course cool, but writing configuration files was not > the original goal. STON is a version of JSON that is closer to our object > model. > > Like I said, I will think about it. > > > -- > > 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] Roassal Camp Smalltalk

by Alexandre Bergel

> 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 certainly things to be discussed about this. Hi Peter, Indeed, we have not been good at producing a descent version numbering schema. My position was always this one: the last version should always fit your need. However, some product favored stability when Roassal is used in a commercial setting. We will be more careful when updating the configuration with a proper version number. Cheers, Alexandre > > On Fri, Jun 5, 2015 at 7:31 PM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > Oh, then itâs my bad. Last time Iâve checked it seemed that it wasnât updated for a long time. Maybe I was wrong. > > Uko > > > >> On 05 Jun 2015, at 18:08, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: >> >> There sure are, look at ConfigurationOfRoassal2>>version*: >> >> and in my baseline I have something like >> >> ~~~~~~~~~~~ >> spec >> project: 'Roassal2' with: [ >> spec >> className: #ConfigurationOfRoassal2; >> versionString: '1.52'; >> repository: 'http://smalltalkhub.com/mc/ObjectProfile/Roassal2/main/' ]; >> ~~~~~~~~~~~ >> >> Peter >> >> On Fri, Jun 5, 2015 at 4:37 PM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: >> But are there numbered version to refer to? >> >> Uko >> >>> On 05 Jun 2015, at 16:34, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: >>> >>> >>> >>> On Fri, Jun 5, 2015 at 3:29 PM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: >>> Iâm interested in participating. Personally Iâd like to talk more about design decisions behind roassal ecosystem, release strategy and so on. Usually when I work with Roassal I have this issue that things are breaking because of rapid changes, or because of the differences between different parts of roassal. Maybe someone is also concerned about this, so we can discuss and maybe improve somethingâ¦ >>> >>> Yes I am also interested in this, right now I am actually using quite old version (month+) because I didn't have time to keep up. :) (Arguably 90% of my problems were from infamous composite shapes. :)) >>> >>> Peter >>> >>> Uko >>> >>> > On 04 Jun 2015, at 19:55, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: >>> > >>> > Dear Colleagues and Friends, >>> > >>> > We are happy to announce we will organize a CampSmalltalk about the Roassal visualization engine, on _Sunday 12 July_. >>> > >>> > As far as we have seen, the interests are multiple. Here is a list of topics we will happy to work on: >>> > - Port of Roassal on VisualWorks >>> > - Using Roassal on Gemstone >>> > - HTML/JavaScript export >>> > - Improving Grapher, our charting library >>> > >>> > If you wish to participate, get in touch with us. Since we will probably have a sponsoring of the event, it would be nice to know how many will attend to ease the logistic and the pizza ordering :-) >>> > >>> > Cheers, >>> > Alexandre >>> > -- >>> > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> > Alexandre Bergel http://www.bergel.eu >>> > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> > >>> > >>> > >>> > >>> >>> >>> >> >> > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

June 8, 2015

Re: [Pharo-dev] Comments in STON

by Sven Van Caekenberghe

> On 08 Jun 2015, at 17:03, Damien Cassou <damien.cassou(a)inria.fr> wrote: > > > 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. I know some people are using STON in ways that I did not originally anticipate, that is of course cool, but writing configuration files was not the original goal. STON is a version of JSON that is closer to our object model. Like I said, I will think about it. > -- > 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 Christophe Demarey

Le 8 juin 2015 Ã 16:59, Sven Van Caekenberghe a Ã©crit : > >> On 08 Jun 2015, at 16:51, Christophe Demarey <Christophe.Demarey(a)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 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. ok, thanks

June 8, 2015