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

Re: [Pharo-dev] Disable assertions (design by contract)

by stepharo

Nicolai some people use assert: (defined in Object) as precondition checker. Stef

Jan. 30, 2016

[pharo-project/pharo-core]

by GitHub

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

Jan. 30, 2016

[pharo-project/pharo-core] 2fb151: 50560

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 2fb151c3eea6bf2b829178b41fd7b7acb3b664f3 https://github.com/pharo-project/pharo-core/commit/2fb151c3eea6bf2b829178b4… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-01-30 (Sat, 30 Jan 2016) Changed paths: A Deprecated50.package/extension/SmalltalkImage/instance/addDeferredStartupAction_.st A Deprecated50.package/extension/SmalltalkImage/instance/addToShutDownList_.st A Deprecated50.package/extension/SmalltalkImage/instance/addToShutDownList_after_.st A Deprecated50.package/extension/SmalltalkImage/instance/addToShutDownList_before_.st A Deprecated50.package/extension/SmalltalkImage/instance/addToStartUpList_.st A Deprecated50.package/extension/SmalltalkImage/instance/addToStartUpList_after_.st A Deprecated50.package/extension/SmalltalkImage/instance/addToStartUpList_before_.st A Deprecated50.package/extension/SmalltalkImage/instance/add_toList_after_.st A Deprecated50.package/extension/SmalltalkImage/instance/add_toList_before_.st A Deprecated50.package/extension/SmalltalkImage/instance/removeFromShutDownList_.st A Deprecated50.package/extension/SmalltalkImage/instance/removeFromStartUpList_.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50559.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50560.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50559.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50560.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M System-BasicCommandLineHandler.package/BasicCommandLineHandler.class/class/system startup/startUp_.st M System-Support.package/SmalltalkImage.class/instance/accessing/session.st A System-Support.package/SmalltalkImage.class/instance/image%2C changes name/changeImagePathTo_.st A System-Support.package/SmalltalkImage.class/instance/image%2C changes name/changesFile.st A System-Support.package/SmalltalkImage.class/instance/image%2C changes name/changesName.st A System-Support.package/SmalltalkImage.class/instance/image%2C changes name/changesSuffix.st A System-Support.package/SmalltalkImage.class/instance/image%2C changes name/fileForChangesNamed_.st A System-Support.package/SmalltalkImage.class/instance/image%2C changes name/fileForImageNamed_.st A System-Support.package/SmalltalkImage.class/instance/image%2C changes name/fullNameForChangesNamed_.st A System-Support.package/SmalltalkImage.class/instance/image%2C changes name/fullNameForImageNamed_.st A System-Support.package/SmalltalkImage.class/instance/image%2C changes name/imageDirectory.st A System-Support.package/SmalltalkImage.class/instance/image%2C changes name/imageFile.st A System-Support.package/SmalltalkImage.class/instance/image%2C changes name/imagePath.st A System-Support.package/SmalltalkImage.class/instance/image%2C changes name/imagePath_.st A System-Support.package/SmalltalkImage.class/instance/image%2C changes name/imageSuffix.st A System-Support.package/SmalltalkImage.class/instance/image%2C changes name/shortImageName.st A System-Support.package/SmalltalkImage.class/instance/image%2C changes name/sourceFileVersionString.st A System-Support.package/SmalltalkImage.class/instance/image%2C changes name/sourcesFile.st A System-Support.package/SmalltalkImage.class/instance/image%2C changes name/sourcesName.st A System-Support.package/SmalltalkImage.class/instance/image%2C changes name/sourcesSuffix.st A System-Support.package/SmalltalkImage.class/instance/image%2C changes name/vmBinary.st A System-Support.package/SmalltalkImage.class/instance/image%2C changes name/vmDirectory.st R System-Support.package/SmalltalkImage.class/instance/image%2C changes names/changeImagePathTo_.st R System-Support.package/SmalltalkImage.class/instance/image%2C changes names/changesFile.st R System-Support.package/SmalltalkImage.class/instance/image%2C changes names/changesName.st R System-Support.package/SmalltalkImage.class/instance/image%2C changes names/changesSuffix.st R System-Support.package/SmalltalkImage.class/instance/image%2C changes names/fileForChangesNamed_.st R System-Support.package/SmalltalkImage.class/instance/image%2C changes names/fileForImageNamed_.st R System-Support.package/SmalltalkImage.class/instance/image%2C changes names/fullNameForChangesNamed_.st R System-Support.package/SmalltalkImage.class/instance/image%2C changes names/fullNameForImageNamed_.st R System-Support.package/SmalltalkImage.class/instance/image%2C changes names/imageDirectory.st R System-Support.package/SmalltalkImage.class/instance/image%2C changes names/imageFile.st R System-Support.package/SmalltalkImage.class/instance/image%2C changes names/imagePath.st R System-Support.package/SmalltalkImage.class/instance/image%2C changes names/imagePath_.st R System-Support.package/SmalltalkImage.class/instance/image%2C changes names/imageSuffix.st R System-Support.package/SmalltalkImage.class/instance/image%2C changes names/shortImageName.st R System-Support.package/SmalltalkImage.class/instance/image%2C changes names/sourceFileVersionString.st R System-Support.package/SmalltalkImage.class/instance/image%2C changes names/sourcesFile.st R System-Support.package/SmalltalkImage.class/instance/image%2C changes names/sourcesName.st R System-Support.package/SmalltalkImage.class/instance/image%2C changes names/sourcesSuffix.st R System-Support.package/SmalltalkImage.class/instance/image%2C changes names/vmBinary.st R System-Support.package/SmalltalkImage.class/instance/image%2C changes names/vmDirectory.st R System-Support.package/SmalltalkImage.class/instance/snapshot and quit/addDeferredStartupAction_.st M System-Support.package/SmalltalkImage.class/instance/snapshot and quit/snapshot_andQuit_.st R System-Support.package/SmalltalkImage.class/instance/startup list/addToShutDownList_.st R System-Support.package/SmalltalkImage.class/instance/startup list/addToShutDownList_after_.st R System-Support.package/SmalltalkImage.class/instance/startup list/addToShutDownList_before_.st R System-Support.package/SmalltalkImage.class/instance/startup list/addToStartUpList_.st R System-Support.package/SmalltalkImage.class/instance/startup list/addToStartUpList_after_.st R System-Support.package/SmalltalkImage.class/instance/startup list/addToStartUpList_before_.st R System-Support.package/SmalltalkImage.class/instance/startup list/add_toList_after_.st R System-Support.package/SmalltalkImage.class/instance/startup list/add_toList_before_.st R System-Support.package/SmalltalkImage.class/instance/startup list/removeFromShutDownList_.st R System-Support.package/SmalltalkImage.class/instance/startup list/removeFromStartUpList_.st M Zinc-HTTP.package/ZnServer.class/class/system startup/startUp_.st Log Message: ----------- 50560 16735 Replace Startup/Shutdown list with SessionManager https://pharo.fogbugz.com/f/cases/16735 http://files.pharo.org/image/50/50560.zip

Jan. 30, 2016

Re: [Pharo-dev] ProcessTest>>testHighPriorityOverridesWaitTime intermittent failures

by Denis Kudriashov

Hi. I like your proposals. It fixed problem. And more important it provides better documentation for tested behaviour 2016-01-30 10:43 GMT+01:00 Ben Coman <btc(a)openinworld.com>: > Case 17373 had an erroneous failure from > ProcessTest>>testHighPriorityOverridesWaitTime > and several others seem also to have suffered... > * https://pharo.fogbugz.com/default.asp?17373 > * https://pharo.fogbugz.com/default.asp?17496 > * https://pharo.fogbugz.com/default.asp?17445 > * https://pharo.fogbugz.com/default.asp?7444 > > These have comments that the problem can't be reproduced, which is > common of occasional race conditions. So rather than just try to > solve this on the issue tracker, I thought I'd share a tip how to > isolate and squash such intermittent failures, essentially by > stressing that single test a large number of times like this... > > 1 to: 100 do: [ :n | Transcript crShow: 'Try ' , n printString. > ProcessTest debug: #testHighPriorityOverridesWaitTime. ] > > Since the debugger only focusses on a point in time snapshot of the > running system, some Transcript instrumentation was useful to overview > the dynamic behaviour, like this... > > ProcessTest>>testHighPriorityOverridesWaitTime > | lowerPriorityWaitingLonger higherPriorityWaitingLess > nextReadyProcess | > lowerPriorityWaitingLonger := [ ] forkAt: 11 > higherPriorityWaitingLess := [ ] forkAt: 12. > nextReadyProcess := Processor nextReadyProcess. > Transcript cr; > tab;show: (lowerPriorityWaitingLonger priority -> > lowerPriorityWaitingLonger identityHash); cr; > tab;show: (higherPriorityWaitingLess priority -> > higherPriorityWaitingLess identityHash); cr; > tab;show: (nextReadyProcess priority -> nextReadyProcess > identityHash). > self assert: nextReadyProcess equals: higherPriorityWaitingLess. > > which produces... > Try 1 > 11->343137024 > 12->40659200 > 12->40659200 > Try 2 > 11->461794304 > 12->374996992 > 12->40659200 > > Observe on the second try nextReadyProcess refers to same process as > from the first try. This can be cleaned up just prior to the asset > check by adding ... > lowerPriorityWaitingLonger terminate. > higherPriorityWaitingLess terminate. > which produces... > Try 1 > 11->1005688064 > 12->833273600 > 12->833273600 > ... > Try 100 > 11->764450816 > 12->807973888 > 12->807973888 > > However this is still a little fragile, since some process with > priority greater than the running test could slip in before the call > to nextReadyProcess, as can be seen by pushing the #to:do: loop out to > 100000, which produces... > Try 32044 > 11->784361216 > 12->431928576 > 40->397533952 > > or wrapping it by [ ]forkAt:39, which produces... > Try 1 > 11->431897088 > 12->400972288 > 30->338363648 > > After several awkward failed attempts to fix this, it seemed best to > observe actual behaviour rather than peeking into the dynamic data > structures. Thus I propose... > > ProcessTest>>testHighPriorityOverridesWaitTime > "The first process to resume will pass straight through the gate > while the other waits for the assert to whichRan." > > | gate checkAssert priorityRan | > gate := Semaphore new signal. > checkAssert := Semaphore new. > > [ gate wait. priorityRan := 11. checkAssert signal ] forkAt: 11. > [ gate wait. priorityRan := 12. checkAssert signal ] forkAt: 12. > > checkAssert wait. > self assert: priorityRan=12 description: 'Second scheduled but > higher priority should run first'. > gate signal. > > checkAssert wait. > self assert: whichRan=11 description: 'First scheduled but lower > priority should run after'. > > https://pharo.fogbugz.com/default.asp?17501 > >

Jan. 30, 2016

Re: [Pharo-dev] Contributing to Pharo

by Bernhard Pieber

Hi David, Just for your information, Cuis uses a file-per-package format. It looks really nice on GitHub and on SourceTree. As far as I can tell, there has not been much merging going, though. So it is entirely possible that it turns out not to work as well as the filetree format when merging. Cheers, Bernhard > Am 29.01.2016 um 23:45 schrieb David Allouche <david(a)allouche.net>: > > Thanks Dale for all the explanations. > > How Monticello and version control relate in the big picture is starting to make sense for me. > > Now, I better understand why filetree ended up uses a file-per-method format, even though that is relatively hostile to git user interfaces optimised for other languages. There is really a need for a file-per-class exchange format, because that would works a lot better with the existing VCS ecosystem. > > I think more package-based user interfaces would indeed be a very good idea, for browsing and for source code management. > > Stef, I have the impression you think that git is popular because it is a new shiny toy. I disagree with this idea. Git is a typical worse-is-better tool. It's good enough for most people, but it still has many shortcomings. It is popular in spite of its shortcomings. It became popular as destination for projects shifting from CVS and Subversion. So it is unlikely to be displaced by a newer, incrementally shinier tools. Anything that will displace it will have to provide an improvement of a similar magnitude as the jump between centralised and distributed version control. > > Still, I think it's a good idea not to restrict high level models to what git provides if that's a less than ideal fit to the image model. > > I have a lot of ideas to improve browsing and source code management in Pharo. I can make no promises, but I would like to produce something there.

Jan. 30, 2016

Re: [Pharo-dev] Contributing to Pharo

by Bernhard Pieber

Dale, Thanks for your thorough answer. I really appreciate how you include links to helpful articles. I find the description of the workflow you actually use very enlightening. However, one thing still remains unclear. In the last step, when merging the pull request. How is the unchanged metadata reconciled with the code changes? I just realized that I just donât know what information is in the Monticello metadata, which is not in the code? Cheers, Bernhard > Am 29.01.2016 um 19:12 schrieb Dale Henrichs <dale.henrichs(a)gemtalksystems.com>: > On 01/29/2016 09:02 AM, Bernhard Pieber wrote: >> Hi Dale, >> >> I am trying to understand this a little better. If a package containing metadata would be changed using a dialect which cannot interpret the metadata, wouldnât or at least couldnât it be broken or lost afterwards for a dialect which tries to interpret the metadata? At least if my assumption is correct that the metadata is related to the code in some way? >> > Bernhard, > > Very good question. > > You are absolutely correct, the act of writing a new version of a package using a different dialect would indeed destroy the platform-specific meta data. > > However, it is NOT expected that two different dialects (with different disk formats) share the same commit. > > If dialect A has committed a package, then dialect B is expected to be able to read the package written by dialect A. Being able to read the package means that all of the information that is common between the two dialects will be preserved ... in FileTree, this means that: > > - all of the class and instance method source is readable and shared > - the method category is readable and shared > - the name, superclass, instance variables, class instance variables, > pools, class category, and class vars for classes is readable and shared > > This is an awful lot common data .... things like traits or namespaces are dialect specific and are ignored by dialects that don't have them when reading the package ... > > When dialect B has read, loaded/compiled and tested the code in the package, the developer has a couple of choices to be made when writing out a new package with her changes: > > - use the current branch > - use a new branch > > I think that using a new branch is the cleanest option. When I port a project like Zinc[1] to GemStone[2], the master branch is preserved for the Pharo-specific code. I create a gs_master branch where the GemStone code goes. When Sven commits new code in his repo, I merge the changes from the his new master branch into my gs_master and resolve conflicts if any, run tests and I'm done. > > The vast mjority of the code base is shared between GemStone and Pharo and only the places where I made changes in porting Zinc to GemStone have the potential for conflicts. Running the tests should highlight any impacts not covered by direct conflicts and if there were some Pharo-specific meta data that I deleted on my branch that causes a test to fail then that is up to me to research and fix. > > When I have changes to feed back to Sven, I make those changes on a separate "topic branch"[3] that is merged into gs_master for my use. I then cherry-pick[4] the topic branch commit into a separate topic branch off of the master branch (this picks up only the changes I made on the topic branch) and open a pull request[5] against Svens repository ... if Sven were using travis-ci, tests would be run automatically against a merge of my changes into his master branch ... if the tests are green and the code passes Sven's scrutiny in a code review he merges my proposed changes into his master branch... > > GemStone and Pharo share a common disk format (not 100% common), but since git only merges the deltas for a commit, it is relatively easy to keep the meta data differences isolated while still sharing the vast bulk of the code and classes .... > > Dale > > [1] https://github.com/svenvc/zinc > [2] https://github.com/GsDevKit/zinc > [3] https://git-scm.com/book/en/v2/Git-Branching-Branching-Workflows > [4] http://think-like-a-git.net/sections/rebase-from-the-ground-up/cherry-picki… > [5] https://help.github.com/articles/using-pull-requests/

Jan. 30, 2016

ProcessTest>>testHighPriorityOverridesWaitTime intermittent failures

by Ben Coman

Case 17373 had an erroneous failure from ProcessTest>>testHighPriorityOverridesWaitTime and several others seem also to have suffered... * https://pharo.fogbugz.com/default.asp?17373 * https://pharo.fogbugz.com/default.asp?17496 * https://pharo.fogbugz.com/default.asp?17445 * https://pharo.fogbugz.com/default.asp?7444 These have comments that the problem can't be reproduced, which is common of occasional race conditions. So rather than just try to solve this on the issue tracker, I thought I'd share a tip how to isolate and squash such intermittent failures, essentially by stressing that single test a large number of times like this... 1 to: 100 do: [ :n | Transcript crShow: 'Try ' , n printString. ProcessTest debug: #testHighPriorityOverridesWaitTime. ] Since the debugger only focusses on a point in time snapshot of the running system, some Transcript instrumentation was useful to overview the dynamic behaviour, like this... ProcessTest>>testHighPriorityOverridesWaitTime | lowerPriorityWaitingLonger higherPriorityWaitingLess nextReadyProcess | lowerPriorityWaitingLonger := [ ] forkAt: 11 higherPriorityWaitingLess := [ ] forkAt: 12. nextReadyProcess := Processor nextReadyProcess. Transcript cr; tab;show: (lowerPriorityWaitingLonger priority -> lowerPriorityWaitingLonger identityHash); cr; tab;show: (higherPriorityWaitingLess priority -> higherPriorityWaitingLess identityHash); cr; tab;show: (nextReadyProcess priority -> nextReadyProcess identityHash). self assert: nextReadyProcess equals: higherPriorityWaitingLess. which produces... Try 1 11->343137024 12->40659200 12->40659200 Try 2 11->461794304 12->374996992 12->40659200 Observe on the second try nextReadyProcess refers to same process as from the first try. This can be cleaned up just prior to the asset check by adding ... lowerPriorityWaitingLonger terminate. higherPriorityWaitingLess terminate. which produces... Try 1 11->1005688064 12->833273600 12->833273600 ... Try 100 11->764450816 12->807973888 12->807973888 However this is still a little fragile, since some process with priority greater than the running test could slip in before the call to nextReadyProcess, as can be seen by pushing the #to:do: loop out to 100000, which produces... Try 32044 11->784361216 12->431928576 40->397533952 or wrapping it by [ ]forkAt:39, which produces... Try 1 11->431897088 12->400972288 30->338363648 After several awkward failed attempts to fix this, it seemed best to observe actual behaviour rather than peeking into the dynamic data structures. Thus I propose... ProcessTest>>testHighPriorityOverridesWaitTime "The first process to resume will pass straight through the gate while the other waits for the assert to whichRan." | gate checkAssert priorityRan | gate := Semaphore new signal. checkAssert := Semaphore new. [ gate wait. priorityRan := 11. checkAssert signal ] forkAt: 11. [ gate wait. priorityRan := 12. checkAssert signal ] forkAt: 12. checkAssert wait. self assert: priorityRan=12 description: 'Second scheduled but higher priority should run first'. gate signal. checkAssert wait. self assert: whichRan=11 description: 'First scheduled but lower priority should run after'. https://pharo.fogbugz.com/default.asp?17501

Jan. 30, 2016

Re: [Pharo-dev] Disable assertions (design by contract)

by Ben Coman

On Sat, Jan 30, 2016 at 9:34 AM, Richard Sargent <richard.sargent(a)gemtalksystems.com> wrote: > To that end, I was wondering about hacking the compiler to test the > association with the reference I've named Assert (but probably in a general > approach for any name). The code generator would send a specific message to > the currently bound value (one would require it to be implemented by all > objects bound to the name, just for honesty and clarity), to ask whether the > code generator should emit code to test the named receiver and skip the > whole statement if it answers true. The code would be generated in all > cases, but it would not be evaluated when the stub mechanism is associated > with Assert, since it would answer true to the skip question. Likewise, the > real assertion mechanism would answer false and the whole statement would be > evaluated. I wonder (in ignorance) if MetaLinks could be applied here? cheers -ben

Jan. 30, 2016

QualityAssistant feedback

by Ben Coman

I've just noticed for "Temporary variables not read AND written" that the offending variable in the temporary variable definition is highlighted. Is this new? Its very nice to have this visual indication. cheers -ben

Jan. 30, 2016

Re: [Pharo-dev] Disable assertions (design by contract)

by Richard Sargent

Eliot Miranda-2 wrote > Hi Richard, > >> On Jan 28, 2016, at 2:15 PM, Richard Sargent < > richard.sargent@ > > wrote: >> >> Aliaksei Syrel wrote >>> Hi >>> >>> Assertions play an important role in design by contract. It is great to >>> have assertions in Pharo out of box (Object>>#assert:). However in >>> projects >>> with many post- and precondition as also class invariants heavy usage of >>> assertions decreases performance... >>> >>> Would it be possible to have a compiler setting (in setting browser) to >>> enable/disable assertions and not compile them to bytecode? Compiler >>> should >>> ignore the whole assertion statement with removed condition. For >>> example: >>> >>>> self assert: self hugeInvariant. >>> >>> with disabled assertion hugeInvariant must not be sent. >>> >>> Thanks, >>> Alex >> >> My concern with this is that this proposal requires certain selectors to >> become /reserved/. Most SUnit variations that I have seen entail several >> dozen methods for asserting and denying behaviours, block evaluation >> versus >> inline expressions, descriptive explanations, and so on. >> >> It seems to me that you would be better off sending messages to a global. >> Instead of: >>> self assert: self hugeInvariant. >> have something like: >>> Assert that: self hugeInvariant. >> >> If the global Assert is bound to a stub the message is sent and ignored. >> If >> bound to a real assertion mechanism, it gets evaluated. Use blocks when >> the >> argument evaluation is expensive or expensive enough. >>> Assert evaluationOf: [self hugeInvariant]. >> >> None of the names should be taken as suggestions. Just the concept. > > It's a good concept, and is the object-oriented approach. It's just that > in practice the costs of creating blocks as assert: arguments, while > typically much cheaper than evaluating the assert and discarding its > result, are still significant > > Hence I'm open to a compiler hack that elides the assert: or deny: and > it's send altogether from the code. Open but not happy; it's something I > hold my nose to do. But this is a style I've been using for twenty odd > years and it is really nice to be able to write assert-laden code but not > have to pay in production. Thanks for the feedback, Eliot. It's appreciated. If we have to hack, I would rather see the hack done differently. One of my goals would be the ability to restore a production database into a test environment without having to recompile all the methods. (Some of our customers have systems with 30-40,000 classes!) To that end, I was wondering about hacking the compiler to test the association with the reference I've named Assert (but probably in a general approach for any name). The code generator would send a specific message to the currently bound value (one would require it to be implemented by all objects bound to the name, just for honesty and clarity), to ask whether the code generator should emit code to test the named receiver and skip the whole statement if it answers true. The code would be generated in all cases, but it would not be evaluated when the stub mechanism is associated with Assert, since it would answer true to the skip question. Likewise, the real assertion mechanism would answer false and the whole statement would be evaluated. That preceding paragraph glosses over a lot, but I hope the gist is sufficiently clear. > There is a ray of hope. The Sista adaptive optimiser /will/ be able to > elide all the cost of the block form: > > ... > self assert: [self expr]. > ... > > Foo methods for assertions > assert: aBlockOrBoolean > ^self > > because there are obviously no side effects. Whereas it will only be able > to elide the entire thing depending on expr in the non-block form: > > ... > self assert: self expr. > ... > > But I wonder how any people would have the discipline or insight to use > the block form. It looks unnecessarily verbose yes? > >> This also offers the benefit that assertions are practical everywhere, >> not >> just under a TestCase hierarchy. > > Whether asserts are practicable everywhere IME depend on how useful they > are in ongoing development. The fact that they cost a /lot/ and slow down > the VM simulator for Cog doesn't change the fact that it would be much > much slower to modify the code base. > > In another thread I was proposing to Gulle to use the VM simulator instead > of a custom VM for his Pharo bootstrap. But in that case one would /have/ > to find a way of eliding asserts. One approach would be a package-level > rewrite tool that could produce a copy of a package in which asserts have > been eliminated. One would always do development in the assert-laden > version, but could make the assert-less version available to clients who > treat the package as a black box, can therefore assume that no asserts > ever fail (because the asserts prove they don't) and use as > high-performance a version of the package as possible. > > With this approach there are no hacks in the compiler, although a > derivative of the compiler might be a workhorse in the rewrite from > assertful to assertless code. And the Monticello tools (& Metacello) > could help automate things. > > >> A second order effect is you aren't playing with the compiler to turn it >> on >> and off, nor to extend the controlled API. > > >> -- >> View this message in context: >> http://forum.world.st/Disable-assertions-design-by-contract-tp4874499p48746… >> Sent from the Pharo Smalltalk Developers mailing list archive at >> Nabble.com. >> -- View this message in context: http://forum.world.st/Disable-assertions-design-by-contract-tp4874499p48748… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Jan. 30, 2016