Re: [Pharo-dev] Refactoring File Package
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.
Re: [Pharo-dev] Comments in STON
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 s...@stfx.eu wrote: 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 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
Re: [Pharo-dev] Comments in STON
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
Re: [Pharo-dev] Refactoring File Package
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 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? Well no. I try to not do that. Currently what I have working is: - a metacello configuration describing the packages+versions that will be part of the built kernel - a simple script that will create the initial objects of an image before class creation (e.g., create Smalltalk, initialize the symbol table, etc). I want this guy to be the smallest as possible to avoid what you describe above - a script to initialize the image after class creation. e.g., create the first process, and execute some class side initialize. Then again, the ad-hoc bootstrap scripts try to be minimal to avoid being impacted. Of course they could be impacted by changes of APIs, but I think it is still controllable in the size of the scripts :). And then, that is why I try to push as many modularity concerns to Pharo itself, to keep these scripts small. 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. Yes, mea culpa there. Some times when extracting classes from one package I didn't put the new package under the System-* or whatever top level package. However, I believe also that the agreement on what are the top-level packages is kind of implicit and obscure to me. I remember some discussions in the list with the Alt browser from Thierry using the idea of top level packages, and others talking about the navigation of the system. I check the latest Pharo Image and I found: - AST (should be system?) - Announcements (should be system?) - Collections (should be system?) - Files (should be system?) - Networking (should be system?) ... And then if we check what is inside the System top-level package today I'd say it is a sack full of random things, with no evident criteria. So maybe we should discuss and agree on how to name packages and 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. v 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. That would be amazing if I could add meta-data to packages to only install specific classes. Because we could keep a coarser granularity of packages while keeping the bootstrap small. However, the problem is that you cannot predict what classes/methods the bootstrap will use. So far, I'm using the class builder to build classes in the bootstrap. In such way, I ensure that all classes that I create will honor the same invariants as a normal class and I don't have to duplicate the creation code :). That means that we can change the internals of the class builder as long as we don't change the API + preconditions and the bootstrap will continue working. Guille
Re: [Pharo-dev] Pharo on bitnami
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 with in the future) for Pharo users. It is quite curious what they mean by partnership and what they expect from it. Back to Pharocloud: yes, we already have this kind of appliances and we can create any appliances needed – you name it, we publish it – no need to even have a poll or a contest. We are currently working on several great new mashup appliances like Pharo+Mongo. I hope those new appliances will bring new power to Pharo web development. Also there is a project on integration of Pharocloud with Digital Ocean and Amazon EC2 clouds, I hope to release it soon. So having this, Pharcloud self hosting, Pharocloud Managed Servers, on-permise installations (Pharocloud downloadable ISO [1]) and the support of the community I am totally sure that we can have the best in-house Pharo-centric cloud. -- View this message in context: http://forum.world.st/Pharo-on-bitnami-tp4830833p4830905.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Re: [Pharo-dev] [Reflectivity] HowTo
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 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
[Pharo-dev] catch server-side errors of a rest server
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. smime.p7s Description: S/MIME cryptographic signature
Re: [Pharo-dev] [Pharo-users] Pharo on bitnami
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-boun...@lists.pharo.org] En nombre de Offray Vladimir Luna Cárdenas Enviado el: Domingo, 07 de Junio de 2015 14:59 Para: pharo-us...@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 steph...@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 ke...@bitnami.com Subject: Introducing Bitnami... Date: 5 Jun 2015 10:57:36 GMT+2 To: bo...@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
Re: [Pharo-dev] catch server-side errors of a rest server
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, 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.
[Pharo-dev] Comments in STON
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
Re: [Pharo-dev] [Reflectivity] HowTo
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 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. HTH 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 more difficult as I want to make sure that the mapping between the AST and the text stays correct…) What you can do already is a #before on a whole method *if* that method is not a primitive method (which will work eventually, too). e.g. | sendNode link | sendNode := (ReflectivityExamples#exampleMethod) ast. link := MetaLink new metaObject: Transcript; selector: #show:; arguments: #(object). sendNode link: link. now execute: ReflectivityExamples new exampleMethod. What is missing (working on it) 1) #after. This needs to wrap the AST of the method in an #ensure: (Here we need to take care to keep the mapping AST - text intact…) 2) promitives. Wrap the compiled Method. 3) pass information to the meta. Right now just #object and #node works. #arguments is the most complex and important. I am working on all this… the next I want to get working is the argument passing. Marcus On 03 Jun 2015, at 16:23, roberto.mine...@usi.ch wrote: Dear Marcus, I am following your progresses on Reflectivity and I’d like to start with a big: THANK YOU! Having said that, I am wondering whether this is a good point in which I can try (as an alpha tester :) to use it. What I need to achieve is something similar to a method wrapper, i.e., some code that gets executed before or after a particular method call. Is something doable at this point? Could you _please_ provide me pointers where to look to understand the Reflectivity framework? Cheers and thanks in advance, Roberto
[Pharo-dev] [pharo-project/pharo-core]
Branch: refs/tags/50094 Home: https://github.com/pharo-project/pharo-core
[Pharo-dev] [pharo-project/pharo-core] 670900: 50094
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: 2015-06-08 (Mon, 08 Jun 2015) Changed paths: A Files-Tests.package/BinaryFileStreamTest.class/README.md A Files-Tests.package/BinaryFileStreamTest.class/definition.st A Files-Tests.package/BinaryFileStreamTest.class/instance/running/fileStreamClass.st A Files-Tests.package/BinaryFileStreamTest.class/instance/running/fileStreamForFileNamed_.st A Files-Tests.package/BinaryFileStreamTest.class/instance/running/tearDown.st A Files-Tests.package/BinaryFileStreamTest.class/instance/testing/testEmptyFileIsAtEnd.st A Files-Tests.package/BinaryFileStreamTest.class/instance/testing/testFileWithSomeBytesSizeIsNotZero.st A Files-Tests.package/BinaryFileStreamTest.class/instance/testing/testFullFileIsAtEnd.st A Files-Tests.package/BinaryFileStreamTest.class/instance/testing/testOpenFile.st A Files-Tests.package/BinaryFileStreamTest.class/instance/testing/testPeekDoesNotAdvanceTheStream.st A Files-Tests.package/BinaryFileStreamTest.class/instance/testing/testReadFullFileIsAtEnd.st A Files-Tests.package/BinaryFileStreamTest.class/instance/testing/testReadLessThanAvailableYieldsJustRead.st A Files-Tests.package/BinaryFileStreamTest.class/instance/testing/testReadMoreThanAvailableYieldsOnlyAvailable.st A Files-Tests.package/BinaryFileStreamTest.class/instance/testing/testReadMultipleBytes.st A Files-Tests.package/BinaryFileStreamTest.class/instance/testing/testReadWhenNothingAvailableYieldsNil.st A Files-Tests.package/BinaryFileStreamTest.class/instance/testing/testSkipLecture.st A Files-Tests.package/BinaryFileStreamTest.class/instance/testing/testWriteMultipleBytes.st A Files-Tests.package/BinaryFileStreamTest.class/instance/testing/testWriteReadInt.st A Files-Tests.package/BinaryFileStreamTest.class/instance/testing/testWriteToClosedFileFails.st A Files-Tests.package/FileTest.class/README.md A Files-Tests.package/FileTest.class/definition.st A Files-Tests.package/FileTest.class/instance/running/tearDown.st A Files-Tests.package/FileTest.class/instance/tests/testCannotOpenFileTwice.st A Files-Tests.package/FileTest.class/instance/tests/testCreateFileObjectDoesNotCreateFile.st A Files-Tests.package/FileTest.class/instance/tests/testEmptyFileSizeIsZero.st A Files-Tests.package/FileTest.class/instance/tests/testFileAtEnd.st A Files-Tests.package/FileTest.class/instance/tests/testFileBufferedRead.st A Files-Tests.package/FileTest.class/instance/tests/testFileDelete.st A Files-Tests.package/FileTest.class/instance/tests/testFileExists.st A Files-Tests.package/FileTest.class/instance/tests/testFileWriteBufferedString.st A Files-Tests.package/FileTest.class/instance/tests/testFileWriteFullString.st A Files-Tests.package/FileTest.class/instance/tests/testForceNewFileDeletesExistingFile.st A Files-Tests.package/FileTest.class/instance/tests/testOpenFileForReadDoesNotDeleteExistingFile.st A Files-Tests.package/FileTest.class/instance/tests/testOpeningFileNormallyDoesNotDeleteExistingFile.st A Files-Tests.package/FileTest.class/instance/tests/testOpeningFileObjectCreatesFile.st A Files-Tests.package/FileTest.class/instance/tests/testOpeningFileSetsPositionAtBeggining.st A Files-Tests.package/FileTest.class/instance/tests/testSeekAbsoluteCannotBeNegative.st A Files-Tests.package/FileTest.class/instance/tests/testSeekAbsoluteChangesPositionAbsolutely.st A Files-Tests.package/FileTest.class/instance/tests/testSeekRelativeMovesFromCurrentPosition.st A Files.package/AbstractBinaryFileStream.class/README.md A Files.package/AbstractBinaryFileStream.class/class/instance-creation/on_.st A Files.package/AbstractBinaryFileStream.class/definition.st A Files.package/AbstractBinaryFileStream.class/instance/accessing/file.st A Files.package/AbstractBinaryFileStream.class/instance/accessing/file_.st A Files.package/AbstractBinaryFileStream.class/instance/helpers/cr.st A Files.package/AbstractBinaryFileStream.class/instance/helpers/crlf.st A Files.package/AbstractBinaryFileStream.class/instance/helpers/lf.st A Files.package/AbstractBinaryFileStream.class/instance/peeking/peek.st A Files.package/AbstractBinaryFileStream.class/instance/position/atEnd.st A Files.package/AbstractBinaryFileStream.class/instance/position/position.st A Files.package/AbstractBinaryFileStream.class/instance/printing/printOn_.st A Files.package/AbstractBinaryFileStream.class/instance/private/onPositionDo_.st A Files.package/AbstractBinaryFileStream.class/instance/reading/next.st A
[Pharo-dev] Pharo Bootstrap (Was Re: Refactoring File Package)
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. m., Ben Coman b...@openinworld.com escribió: On Sat, Jun 6, 2015 at 5:26 PM, Guillermo Polito guillermopol...@gmail.com 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? Well no. I try to not do that. Currently what I have working is: - a metacello configuration describing the packages+versions that will be part of the built kernel - a simple script that will create the initial objects of an image before class creation (e.g., create Smalltalk, initialize the symbol table, etc). I want this guy to be the smallest as possible to avoid what you describe above Ahhh. That is real nice to know. Very cool. - a script to initialize the image after class creation. e.g., create the first process, and execute some class side initialize. Then again, the ad-hoc bootstrap scripts try to be minimal to avoid being impacted. Of course they could be impacted by changes of APIs, but I think it is still controllable in the size of the scripts :). And then, that is why I try to push as many modularity concerns to Pharo itself, to keep these scripts small. 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. Yes, mea culpa there. Some times when extracting classes from one package I didn't put the new package under the System-* or whatever top level package. However, I believe also that the agreement on what are the top-level packages is kind of implicit and obscure to me. I remember some discussions in the list with the Alt browser from Thierry using the idea of top level packages, and others talking about the navigation of the system. I check the latest Pharo Image and I found: - AST (should be system?) - Announcements (should be system?) - Collections (should be system?) - Files (should be system?) - Networking (should be system?) ... Also we should consider whether its possible/desirable for packages AsmJit, Athens, ConfigurationXxxx, Filesystem, Glamour, Graphics, etc to have just one top-level entry each. And then if we check what is inside the System top-level package today I'd say it is a sack full of random things, with no evident criteria. So maybe we should discuss and agree on how to name packages and top-level packages! Probably a bit hard to do across a mail list. Maybe an initial stab at this could be done during a sprint? 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. 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. That would be amazing if I could add meta-data to packages to only install specific classes. Because we could keep a coarser granularity of packages while keeping the bootstrap small. However, the problem is that you cannot predict what classes/methods the bootstrap will use. Maybe at certain points of the bootstrap you add the pragma bootstrap to all methods currently in the image. This would become a form of documentation, but also perhaps for the next bootstrap build, you scan for the bootstrap methods to install into the bootstrap image, and the classes get installed merely as a consequence of being a dependency to allow bootstrap methods to be installed. cheers -ben So far, I'm using the class builder to build classes in the bootstrap. In such way, I ensure that all classes that I create will honor the same invariants as a normal class and I don't have to duplicate the creation code :). That means that we can change the internals of the class builder as
Re: [Pharo-dev] [Reflectivity] HowTo
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 more difficult as I want to make sure that the mapping between the AST and the text stays correct…) What you can do already is a #before on a whole method *if* that method is not a primitive method (which will work eventually, too). e.g. | sendNode link | sendNode := (ReflectivityExamples#exampleMethod) ast. link := MetaLink new metaObject: Transcript; selector: #show:; arguments: #(object). sendNode link: link. now execute: ReflectivityExamples new exampleMethod. What is missing (working on it) 1) #after. This needs to wrap the AST of the method in an #ensure: (Here we need to take care to keep the mapping AST - text intact…) 2) promitives. Wrap the compiled Method. 3) pass information to the meta. Right now just #object and #node works. #arguments is the most complex and important. I am working on all this… the next I want to get working is the argument passing. Marcus On 03 Jun 2015, at 16:23, roberto.mine...@usi.ch wrote: Dear Marcus, I am following your progresses on Reflectivity and I’d like to start with a big: THANK YOU! Having said that, I am wondering whether this is a good point in which I can try (as an alpha tester :) to use it. What I need to achieve is something similar to a method wrapper, i.e., some code that gets executed before or after a particular method call. Is something doable at this point? Could you _please_ provide me pointers where to look to understand the Reflectivity framework? Cheers and thanks in advance, Roberto
Re: [Pharo-dev] Comments in STON
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 guillermopol...@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
Re: [Pharo-dev] catch server-side errors of a rest server
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 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 smime.p7s Description: S/MIME cryptographic signature
Re: [Pharo-dev] Comments in STON
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 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
Re: [Pharo-dev] Comments in STON
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 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
Re: [Pharo-dev] Roassal Camp Smalltalk
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.tymc...@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.uh...@gmail.com wrote: There sure are, look at ConfigurationOfRoassal2version*: 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.tymc...@me.com wrote: But are there numbered version to refer to? Uko On 05 Jun 2015, at 16:34, Peter Uhnák i.uh...@gmail.com wrote: On Fri, Jun 5, 2015 at 3:29 PM, Yuriy Tymchuk yuriy.tymc...@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.ber...@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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Re: [Pharo-dev] catch server-side errors of a rest server
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. smime.p7s Description: S/MIME cryptographic signature
Re: [Pharo-dev] catch server-side errors of a rest server
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 (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.
Re: [Pharo-dev] Comments in STON
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). 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 smime.p7s Description: S/MIME cryptographic signature
Re: [Pharo-dev] Comments in STON
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 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 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
Re: [Pharo-dev] Comments in STON
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. 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.
[Pharo-dev] [pharo-project/pharo-core]
Branch: refs/tags/50095 Home: https://github.com/pharo-project/pharo-core
[Pharo-dev] [pharo-project/pharo-core] 4c7f55: 50095
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: 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
Re: [Pharo-dev] Refactoring File Package
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 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 lt; stepharo@ gt; 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 lt; guillermopolito@ gt; 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 lt; sven@ gt; escribió: On 05 Jun 2015, at 18:20, stepharo lt; stepharo@ gt; 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 lt; damien.cassou@ gt; wrote: Guillermo Polito lt; guillermopolito@ gt; 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
