December 2016 - Pharo-dev - lists.pharo.org

[ANN] TechTalks Jan and Feb

by Marcus Denker

Hi, We have fixed the next two tech talks: - 24 Jan 2017. Topic "Bloc/Brickâ https://association.pharo.org/event-2405619 - 28 Feb 2017. Topic: âRefelectivity" https://association.pharo.org/event-2407465 We added these as âEventsâ to the association website. People registered there will get the information how to participate via mail (and a mail pointing to the recording afterwards). This is therefor especially interesting for those not following the mailing lists. The idea is to have one each months, if you have ideas for topics (or want to do some yourself), send a mail. Blog post: http://pharo.org/news/techtalks17

Dec. 19, 2016

Problem with OSSubprocess / signals / heartbeat ?

by Mariano Martinez Peck

Hi guys, There is a bug happening in OSSubprocess since quite some time which we were never able to fix. What happens is that at certain point (after having used OSSubprocess for a while), a simple command like the following would "hang" Pharo: OSSUnixSubprocess new command: 'ls'; arguments: #(); redirectStdout; runAndWaitOnExitDo: [ :process :outString | outString ] Once the image does that, it keeps doing it in a 80% of the cases (so it is easy enough to debug). Guille Polito kept one of these images if someone can give us a hand. He also proposed the great idea of using `strace` to see what was going on. He (together with Pable Tesone) suspected that the heartbeat could be interrupting the `clone()` function which is (I think) called internally by the 'posix_spawn()' which is the one used by OSSubprocess. When these images are "hung" they found at a infinitive loop like this: [pid 17477] --- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL} --- [pid 17477] gettimeofday({1482152630, 593498}, NULL) = 0 [pid 17477] sigreturn() (mask []) = 120 [pid 17477] clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0xf7578768) = ? ERESTARTNOINTR (To be restarted) [pid 17477] --- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL} --- [pid 17477] gettimeofday({1482152630, 600126}, NULL) = 0 [pid 17477] sigreturn() (mask []) = 120 [pid 17477] clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0xf7578768) = ? ERESTARTNOINTR (To be restarted) [pid 17477] --- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL} --- [pid 17477] gettimeofday({1482152630, 606282}, NULL) = 0 [pid 17477] sigreturn() (mask []) = 120 [pid 17477] clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0xf7578768) = ? ERESTARTNOINTR (To be restarted) [pid 17477] --- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL} --- [pid 17477] gettimeofday({1482152630, 612528}, NULL) = 0 [pid 17477] sigreturn() (mask []) = 120 [pid 17477] clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0xf7578768) = ? ERESTARTNOINTR (To be restarted) [pid 17477] --- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL} --- [pid 17477] gettimeofday({1482152630, 618689}, NULL) = 0 [pid 17477] sigreturn() (mask []) = 120 [pid 17477] clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0xf7578768) = ? ERESTARTNOINTR (To be restarted) [pid 17477] --- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL} --- [pid 17477] gettimeofday({1482152630, 624922}, NULL) = 0 [pid 17477] sigreturn() (mask []) = 120 [pid 17477] clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0xf7578768) = ? ERESTARTNOINTR (To be restarted) [pid 17477] --- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL} --- [pid 17477] gettimeofday({1482152630, 631145}, NULL) = 0 [pid 17477] sigreturn() (mask []) = 120 [pid 17477] clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0xf7578768) = ? ERESTARTNOINTR (To be restarted) [pid 17477] --- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL} --- [pid 17477] gettimeofday({1482152630, 637241}, NULL) = 0 [pid 17477] sigreturn() (mask []) = 120 [pid 17477] clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0xf7578768) = ? ERESTARTNOINTR (To be restarted) [pid 17477] --- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL} --- [pid 17477] gettimeofday({1482152630, 643578}, NULL) = 0 [pid 17477] sigreturn() (mask []) = 120 [pid 17477] clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0xf7578768) = ? ERESTARTNOINTR (To be restarted) [pid 17477] --- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL} --- [pid 17477] gettimeofday({1482152630, 649974}, NULL) = 0 [pid 17477] sigreturn() (mask []) = 120 [pid 17477] clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0xf7578768) = ? ERESTARTNOINTR (To be restarted) [pid 17477] --- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL} --- As you can see, there is a SIGALARM involved. It also looks like the `gettimeofday` is used by the heartbeat ? Could it be that someone the heartbeat is interrupting the `clone()` ? Guille also showed me the `strace` output with a regular / working image: [pid 18647] --- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL} --- [pid 18647] gettimeofday({1482152829, 481014}, NULL) = 0 [pid 18647] sigreturn() (mask []) = -1 EINTR (Interrupted system call) [pid 18647] getitimer(ITIMER_REAL, {it_interval={0, 2000}, it_value={0, 1917}}) = 0 [pid 18647] recvmsg(3, 0xff7b0734, 0) = -1 EAGAIN (Resource temporarily unavailable) [pid 18647] select(4, [3], [], [3], {0, 1000}) = 0 (Timeout) [pid 18647] getitimer(ITIMER_REAL, {it_interval={0, 2000}, it_value={0, 797}}) = 0 [pid 18647] recvmsg(3, 0xff7b0734, 0) = -1 EAGAIN (Resource temporarily unavailable) [pid 18647] select(4, [3], [], [3], {0, 1000}) = ? ERESTARTNOHAND (To be restarted if no handler) [pid 18647] --- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL} --- Does anyone have any hint here? Thanks in advance, -- Mariano http://marianopeck.wordpress.com

Dec. 19, 2016

Re: [Pharo-dev] a request to change the meaning of <example> pragma

by Tudor Girba

Hi, Thanks for the message. There are several points under discussion. I am not arguing now for introduction of GTExamples in the Pharo distribution. This is a discussion for the future. But, I would like to distinguish between the current implementation and the goal. I believe "Example-driven development" is an interesting possibility to raise awareness for Pharo especially if we double the technology with a practice or method that will be in line with the idea of live programming. It might sound far fetched, but I really believe we can deliver on that. GTExamples is a full first version (not a prototype). It certainly will not be the last. Regarding composition, in its simplest form, there is no composition, and for that you only need unary methods with <gtExample>. But, you do get the possibility of adding assertions and of specifying cleanups. So, relying on plain <gtExample> does not force you to use dependencies but you get extra advantages. Nevertheless, as I said before, composition is a point on which we want to work more. I believe it should be possible to use static analysis to recover example dependencies without the need of injecting arguments based on pragmas, but it is not yet clear how this would work. Cheers, Doru > On Dec 19, 2016, at 1:32 PM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > > Hi all > > In nautilus in Pharo 60 when you use > <sampleInstance> you can get an inspector on the object returned by the method > > Example > > Die class >> d6 > <sampleInstance> > ^ self faces: 6 > > I started to use this pragma in all my libraries and I chose it to avoid conflict with <example> and others. > > I can change another time to make everybody happy. But I would like to avoid to have to change everything again because this is the second time. :) > So let me know. > > Now as I already said in the past, I will veto the integration of Examples based on pragmas to compose them. > I do not want to need a special tools to get example working. But you know all that. > > > Stef > > > > > > > > > > On Sun, Dec 18, 2016 at 10:49 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi, > > As you might know, a while ago we created GTExamples, a framework that supports both example-based live documentation and testing: > http://gtoolkit.org/doc/Examples/examples.html > > GTExamples was part of the GTInspector for a while, but as it evolved, we pulled it out in a separate project. This separate project is not in Pharo anymore but it is part of the full GToolkit configuration (Pharo only ships the core of GToolkit). The idea of taking GTExamples out was to allow the community to have a more elaborate discussion about the role of examples in our environment. > > I have invited you to join that conversation, but it did not take off. I understand that perhaps the topic does not look appealing at this moment. > > We will certainly continue to evolve GTExamples both on the semantics level of the dependency constructs and on the integration with tools. Our goal is to enable a new practice that I would like to call Example-Guilded Development (or Example-Driven Development), and position Pharo to be the only platform on which someone can do that. But, that is our goal, and does not have to be the same with other peopleâs goal. > > Right now, GTExamples relies on the <gtExample> pragma to denote a method that returns an object that exemplifies something. Executing this method as an example should have no side-effects (either because the method itself does not have a side-effect, or because the example method defines how the cleanup should happen using the mechanism provided by GTExamples). > > This meaning is different from the meaning of the <example> pragma used through Pharo. There are currently 55 places that use this pragma inside Pharo and most of them come from FastTable. As things will progress and more libraries might use GTExamples, the situation can become confusing. > > To make things less confusing in the future, I would like to define the meaning of the <example> to denote a method that returns an object without having side effects. Would you agree with this? > > If yes, I would suggest the name of the new pragma that would replace the existing one to include âscriptâ in the name. For example, <sampleScript>. > > What do you think? > > Cheers, > Doru > > > -- > www.tudorgirba.com > www.feenk.com > > "Reasonable is what we are accustomed with." > > > -- www.tudorgirba.com www.feenk.com "Problem solving efficiency grows with the abstractness level of problem understanding."

Dec. 19, 2016

Re: [Pharo-dev] [Moose-dev] Re: Too frequent crashes :-(

by Peter Uhnak

On Mon, Dec 19, 2016 at 08:12:29AM +0800, Ben Coman wrote: > Can yo point to where you added you workaround? The fix is a single line, because I hate myself. interpreterProxy failed ifTrue:[^nil]. https://github.com/pharo-project/pharo-vm/commit/9bf66cf656b176d988e1b0ba74… To give you more info: The problem is that memory of canvas forms are not properly pinned, so during garbage collection the form is being moved, but if at the same time the canvas form is being updated and moved, you are accessing wrong memory -> crash. My fix will return prematurely if an error occurs and throws PrimitiveFailed in the image before any wrong memory is accessed. On Roassal side the PrimitiveFailed is catched and a paint cycle is skipped --- this is good enough, as it results only in ocassional flicker that immediately fixes itself instead of crashing the image. It seems that on Mac there are also other places in the BitBlt code where the surface is being accessed without a check. Also be careful not to be misled by the crash dump stack. It took me quite a while to figure out that GrafPort is already operating on wrong data, so it's not GrafPort's fault, but BitBlt's; of course both should possibly be investigated with respect to the mac crash. Final note, personally I found it much easier the debug and manipulate the resulting C code (and recompiling just that), then to modify the Slang code and rebuild the source code and recompile it all (but again, I don't know what is the proper way to work with the VM code). I used this script to trigger the crash https://gist.github.com/peteruhnak/024650ed2594301558df4da913549b54 As the crash depends on memory consumption and "proper" garbage collection cycle, it wasn't the easiest to reproduce, however the script above usually managed to crash it. Having a more reliable way would be nice, but simply triggering GC (nor full GC) wasn't enough because the memory wasn't in the "right" state. Peter

Dec. 19, 2016

Re: [Pharo-dev] a request to change the meaning of <example> pragma

by Tudor Girba

Hi, Thanks for reacting. Knowing that you were a strong debate counterpart, I would be very happy to work with you on this topic :). As Nicolai noticed, GTExamples is significantly more than sample instances. For example, right now, it is the basis for building examples that are also tests. Furthermore, we played also with building documentation around it. Sample instances are just the prerequisite for making this happen, but the method is very much an example. I do not want to hijack anything. The result of the debate a year ago was to not introduce the <example> pragma at all to have the chance of comparing solutions rather than just having something that is half backed and get stuck with it. Now we have 55 such <example> methods in the image. GTExamples will not change because we do not learn from samples or exemplars, we learn from examples, and the goal of this project is to offer a solution for live documentation and testing. You might not believe in it, and that is fine. We wrote down the documentation so that people can look at it. People do not, and that is fine as well. Examples is a very rich word, and it would be a pity to not spend it to its full potential. I am not saying that the current form of GTExamples is that full potential, but I do want us to dream for more than what is achievable easily. I already said that one issue we have with GTExamples is that the composition based on pragmas can become somewhat difficult (at least with the current tools) and we are looking for alternatives. Even so, this library is already in use and it will be used further. Furthermore, not using the term âexamples" for this goal is a bit like saying that because some methods used to be called âtestsâ before SUnit appeared that SUnit should have employed a different term than tests to denote the methods. For example, they could have been called assertions. Cheers, Doru > On Dec 19, 2016, at 1:03 PM, Torsten Bergmann <astares(a)gmx.de> wrote: > > Hi Tudor, > > we all already had exchanged on this topic in discussions on this list back a year ago or even before > and as we have seen there were different arguments and different point of views. > > Actions to make Pharo more known are always appreciated and as you made more progress on the idea/tools > side for sure you can demonstrate better what can be done with this approach. > > But does it mean all the other arguments are now invalid because of this? I don't think so. > > Anything described/demonstrated in this approach can perfectly be done without changing the meaning > of the "example" pragma and by using an own pragma to mark methods following that idea. > > Trying to hijack "example" pragma again as it is your preferred pragma name does not help because this is > like enforcing your own point of view on the topic to people like me following the existing > "example" usage. Currently <example> and its usage is very generous and not so restrictive what kind of > example the method contains or what return value it may provide. > > Also counting the current usage in the default image does not tell you anything as it leaves out all external > projects. > > > Similar to Ben I personally have not changed my point of view. I agree with him in using an own and more specific > pragma like > > - <sample> > - <sampleInstance> > - <exemplar> > > better depicting the meaning of returning an sample/sample instance/exemplar of an instance of the class. > I would be fine with using just "sample" as well as "Sample driven development". > > > There is no need to change the meaning of the existing pragma <example> which is more > general and can be any kind of example like: > - example of usage > - a simple example script > - sample instance > - example of an algorithm > - example on how to use several classes together > - ... > > For <example> it is not necessary to return exactly once instance of the class where the pragma > is used in. > > Thx > T. > -- www.tudorgirba.com www.feenk.com "Innovation comes in the least expected form. That is, if it is expected, it already happened."

Dec. 19, 2016

Re: [Pharo-dev] a request to change the meaning of <example> pragma

by Stephane Ducasse

Hi all In nautilus in Pharo 60 when you use <sampleInstance> you can get an inspector on the object returned by the method Example Die class >> d6 <sampleInstance> ^ self faces: 6 I started to use this pragma in all my libraries and I chose it to avoid conflict with <example> and others. I can change another time to make everybody happy. But I would like to avoid to have to change everything again because this is the second time. :) So let me know. Now as I already said in the past, I will veto the integration of Examples based on pragmas to compose them. I do not want to need a special tools to get example working. But you know all that. Stef On Sun, Dec 18, 2016 at 10:49 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi, > > As you might know, a while ago we created GTExamples, a framework that > supports both example-based live documentation and testing: > http://gtoolkit.org/doc/Examples/examples.html > > GTExamples was part of the GTInspector for a while, but as it evolved, we > pulled it out in a separate project. This separate project is not in Pharo > anymore but it is part of the full GToolkit configuration (Pharo only ships > the core of GToolkit). The idea of taking GTExamples out was to allow the > community to have a more elaborate discussion about the role of examples in > our environment. > > I have invited you to join that conversation, but it did not take off. I > understand that perhaps the topic does not look appealing at this moment. > > We will certainly continue to evolve GTExamples both on the semantics > level of the dependency constructs and on the integration with tools. Our > goal is to enable a new practice that I would like to call Example-Guilded > Development (or Example-Driven Development), and position Pharo to be the > only platform on which someone can do that. But, that is our goal, and does > not have to be the same with other peopleâs goal. > > Right now, GTExamples relies on the <gtExample> pragma to denote a method > that returns an object that exemplifies something. Executing this method as > an example should have no side-effects (either because the method itself > does not have a side-effect, or because the example method defines how the > cleanup should happen using the mechanism provided by GTExamples). > > This meaning is different from the meaning of the <example> pragma used > through Pharo. There are currently 55 places that use this pragma inside > Pharo and most of them come from FastTable. As things will progress and > more libraries might use GTExamples, the situation can become confusing. > > To make things less confusing in the future, I would like to define the > meaning of the <example> to denote a method that returns an object without > having side effects. Would you agree with this? > > If yes, I would suggest the name of the new pragma that would replace the > existing one to include âscriptâ in the name. For example, <sampleScript>. > > What do you think? > > Cheers, > Doru > > > -- > www.tudorgirba.com > www.feenk.com > > "Reasonable is what we are accustomed with." > > >

Dec. 19, 2016

Re: [Pharo-dev] a request to change the meaning of <example> pragma

by Torsten Bergmann

Hi Tudor, we all already had exchanged on this topic in discussions on this list back a year ago or even before and as we have seen there were different arguments and different point of views. Actions to make Pharo more known are always appreciated and as you made more progress on the idea/tools side for sure you can demonstrate better what can be done with this approach. But does it mean all the other arguments are now invalid because of this? I don't think so. Anything described/demonstrated in this approach can perfectly be done without changing the meaning of the "example" pragma and by using an own pragma to mark methods following that idea. Trying to hijack "example" pragma again as it is your preferred pragma name does not help because this is like enforcing your own point of view on the topic to people like me following the existing "example" usage. Currently <example> and its usage is very generous and not so restrictive what kind of example the method contains or what return value it may provide. Also counting the current usage in the default image does not tell you anything as it leaves out all external projects. Similar to Ben I personally have not changed my point of view. I agree with him in using an own and more specific pragma like - <sample> - <sampleInstance> - <exemplar> better depicting the meaning of returning an sample/sample instance/exemplar of an instance of the class. I would be fine with using just "sample" as well as "Sample driven development". There is no need to change the meaning of the existing pragma <example> which is more general and can be any kind of example like: - example of usage - a simple example script - sample instance - example of an algorithm - example on how to use several classes together - ... For <example> it is not necessary to return exactly once instance of the class where the pragma is used in. Thx T.

Dec. 19, 2016

Re: [Pharo-dev] a request to change the meaning of <example> pragma

by Torsten Bergmann

Dec. 19, 2016

[MoreVMs'17] Call for Contributions: 1st Workshop on Modern Language Runtimes, Ecosystems, and VMs at <Programming> 2017

by Stefan Marr

============================================================================ Call for Papers: MoreVMsâ17 1st Workshop on Modern Language Runtimes, Ecosystems, and VMs Co-located with <Programming> 2017 April, 2017, Brussels, Belgium http://2017.programming-conference.org/track/MoreVMs-2017-papers ============================================================================ The MoreVMs'17 workshop aims bring together programmers from industry and academy to discuss the design, implementation, and usage of modern languages and runtimes. This includes aspects such as reuse of language runtimes, modular implementation, or design and compilation strategies to target existing runtimes. The main goals of the workshop is to bring together both researchers and practitioners and facilitate effective sharing of their respective experiences and ideas on how languages and runtimes are utilized and where they need to improve further. We welcome presentation proposals in the form of extended abstracts discussing experiences, work-in-progress, as well as future visions from the academic as well as industrial perspective. Relevant topics include, but are definitely not limited to, the following: - extensible VM design (compiler- or interpreter-based VMs) - reusable runtime components (e.g. interpreters, garbage collectors, intermediate representations) - static and dynamic compiler techniques - techniques for compilation to high-level languages such as JavaScript - runtimes and mechanisms for interoperability between languages - tooling support (e.g. debugging, profiling, etc.) - programming language development environments and virtual machines - case studies of existing language implementations, virtual machines, and runtime components (e.g. design choices, tradeoffs, etc.) - language implementation challenges and trade-offs (e.g. performance, completeness, etc.) - surveys and applications usage reports to understand runtime usage in the wild - surveys on frameworks and their impact on runtime usage - new research ideas on how we want to build languages in the future ### Workshop Format and Submissions This workshop welcomes the presentation and discussion of new ideas and emerging problems to facilitate interaction among workshop participants and exchange of ideas. We accept presentation proposals in the form of extended abstracts (1-2 pages). Accepted abstracts will be published on the workshop's website before the workshop date. For preparing your abstract, please use the provided author kit: https://github.com/smarr/morevms17-author-kit. It is based on the ACM SIGPLAN Conference Format with 10 point font, and includes a Creative Commons License, which will allow us to publish the abstract on the workshop web site. Please submit abstracts through http://ssw.jku.at/morevms17/ ### Important Dates Abstract submission: 15 February 2017 Author notification: 01 March 2017 Workshop: 3 April 2017 All deadlines are Anywhere on Earth (AoE), i.e. GMT/UTCâ12:00 hour ### Program Committee Matthias Grimmer, Oracle Labs Christine H. Flood, Red Hat Tony Hosking, Australian National University Hannes Payer, Google Tiark Rompf, Purdue University Jeremy Singer, University of Glasgow Mark Stoodley, IBM Canada Sam Tobin-Hochstadt, Indiana University ### Workshop Organizers Laurence Tratt, King's College London, United Kingdom Adam Welc, Oracle Labs, United States Stefan Marr, Johannes Kepler University Linz, Austria

Dec. 19, 2016

Re: [Pharo-dev] a request to change the meaning of <example> pragma

by phil＠highoctane.be

Ok, thx. Will try. I am tired of examples in comments, selecting stuff etc when it is possible to have a click on an icon. Thx for this thing. Phil On Mon, Dec 19, 2016 at 8:34 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > We did not try, but it should not be a problem, except for the fact that > there will be a GTExample class in Pharo 5 packaged with GTInspector. > > Cheers, > Doru > > > > On Dec 19, 2016, at 12:51 AM, phil(a)highoctane.be wrote: > > > > Is it possible to have examples in a 5.0? > > > > Phil > > > > On Sun, Dec 18, 2016 at 10:49 PM, Tudor Girba <tudor(a)tudorgirba.com> > wrote: > > Hi, > > > > As you might know, a while ago we created GTExamples, a framework that > supports both example-based live documentation and testing: > > http://gtoolkit.org/doc/Examples/examples.html > > > > GTExamples was part of the GTInspector for a while, but as it evolved, > we pulled it out in a separate project. This separate project is not in > Pharo anymore but it is part of the full GToolkit configuration (Pharo only > ships the core of GToolkit). The idea of taking GTExamples out was to allow > the community to have a more elaborate discussion about the role of > examples in our environment. > > > > I have invited you to join that conversation, but it did not take off. I > understand that perhaps the topic does not look appealing at this moment. > > > > We will certainly continue to evolve GTExamples both on the semantics > level of the dependency constructs and on the integration with tools. Our > goal is to enable a new practice that I would like to call Example-Guilded > Development (or Example-Driven Development), and position Pharo to be the > only platform on which someone can do that. But, that is our goal, and does > not have to be the same with other peopleâs goal. > > > > Right now, GTExamples relies on the <gtExample> pragma to denote a > method that returns an object that exemplifies something. Executing this > method as an example should have no side-effects (either because the method > itself does not have a side-effect, or because the example method defines > how the cleanup should happen using the mechanism provided by GTExamples). > > > > This meaning is different from the meaning of the <example> pragma used > through Pharo. There are currently 55 places that use this pragma inside > Pharo and most of them come from FastTable. As things will progress and > more libraries might use GTExamples, the situation can become confusing. > > > > To make things less confusing in the future, I would like to define the > meaning of the <example> to denote a method that returns an object without > having side effects. Would you agree with this? > > > > If yes, I would suggest the name of the new pragma that would replace > the existing one to include âscriptâ in the name. For example, > <sampleScript>. > > > > What do you think? > > > > Cheers, > > Doru > > > > > > -- > > www.tudorgirba.com > > www.feenk.com > > > > "Reasonable is what we are accustomed with." > > > > > > > > -- > www.tudorgirba.com > www.feenk.com > > "There are no old things, there are only old ways of looking at them." > > > > > >

Dec. 19, 2016