- Pharo-dev - lists.pharo.org

Smalltalkhub scheduled maintenance next monday (February, 1st)

by Christophe Demarey

Hello, Smalltalk will be down next monday (february, 1st) from 12:30 to 13:30 (french local time). IT will add storage to the root partition. Regards, Christophe

Jan. 29, 2016

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

by ClÃ©ment Bera

I tried to experiment with such behavior a while ago. I added an opal compiler extension here: http://smalltalkhub.com/mc/ClementBera/NeoCompiler/main . One needs to recompile the package after it is loaded as it uses a compiler extension. The idea was to introduce [ "some code" ] Cvalue, with Cvalue a message evaluated at compilation time depending on a class-side setting. I put examples in the package. This method: example ^ [ Smalltalk vm class ] Cvalue is compiled, depending on a class side setting, to: example ^ VirtualMachine or example ^ Smalltalk vm class I could have added similar things for assert: and maybe add the C++ IFDEF macro, but in the end I don't think this is a good idea in a Smalltalk system. The code becomes hard to read or you have to extend a lot Smalltalk (extend the syntax, etc.). If one really wants to do that, he can write it in his own DSL that compiles to Smalltalk. It is way easier and does not pollute the base Smalltalk. The user-designed compilation could happen with RB AST transformations, and honestly this is not very difficult and a good developer could do it without too many troubles. 2016-01-29 2:12 GMT+01:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > Hi Richard, > > > On Jan 28, 2016, at 2:15 PM, Richard Sargent < > richard.sargent(a)gemtalksystems.com> 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. > > 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. > > > >

Jan. 29, 2016

Re: [Pharo-dev] Travis CI integration added to OSSubprocess and FFICHeaderExtractor

by Sven Van Caekenberghe

Nice ! > On 29 Jan 2016, at 01:03, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > > Hi guys, > > This is just to let you know that with the help of Esteban and between some work together [1] [2] I was able to have Travis CI integrated with OSSubprocess and FFICHeaderExtractor [3] [4] . Both projects are built and tested under Linux and OSX. Note also that one of the projects does a lot of FFI calls to system libs like libc and the other even generates C programs, compiles them and run it. Even the OS dependencies (like installing the compiler) are resolved correctly :) > > If someone wants to know how it's done, simply check the .travis.yml and the scripts/run-test.sh of each project [5] [6]. > > [1] https://pharo.fogbugz.com/f/cases/17488 > [2] https://pharo.fogbugz.com/f/cases/17490 > [3] https://travis-ci.org/marianopeck/OSSubprocess > [4] https://travis-ci.org/marianopeck/FFICHeaderExtractor > [5] https://github.com/marianopeck/OSSubprocess > [6] https://github.com/marianopeck/FFICHeaderExtractor > > > Cheers, > > > -- > Mariano > http://marianopeck.wordpress.com

Jan. 29, 2016

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

by Eliot Miranda

Hi Richard, > On Jan 28, 2016, at 2:15 PM, Richard Sargent <richard.sargent(a)gemtalksystems.com> 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. 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. >

Jan. 29, 2016

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

by Eliot Miranda

Hi Nicolai, > On Jan 28, 2016, at 1:27 PM, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > 2016-01-28 22:12 GMT+01:00 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: >> I wonder if an override of assert/assert: with ^self in production will make a noticeable performance drop once inlining JIT is ready. >> Of course eliminating the send with compiler hack eliminates some work for inliner, but it sounds like manual optimization duplicating automatic optimizer work. >> >> 2016-01-28 21:50 GMT+01:00 stepharo <stepharo(a)free.fr>: >>> Marcus >>> >>> I do not really like that we get per class behavior. >>> I would prefer to have a >>> >>> Compiler recompileAllForProductionAndNoAssert >>> or at the level of the package. >>> >>> Stef >>> >>>> Hello, >>>> >>>> Yes, we should experiment with that. >>>> >>>> A compiler option is very easy to addâ¦ and easy to understand. And trivial to do. >>>> >>>> 1) step one: >>>> >>>> add the following line at the start of OCASTTranslator>>emitMessageNode: >>>> >>>> self compilationContext optionDisableAssert ifTrue: [ >>>> aMessageNode selector == #assert: ifTrue: [ ^methodBuilder pushReceiver ] >>>> ]. >>>> >>>> 2) step 2. There is no step. 2 ;-). Maybe a better version would use pluginâ¦ changing the code generator like that >>>> is a bit a hack. But it works. >>>> >>>> You can now turn off all sends to #assert: by enabling the #optionDisableAssert compiler option. >>>> e.g. class wide by setting on the class side in >>>> >>>> compiler >>>> ^super compiler options: #(+ optionDisableAssert). >>>> >>>> >>>> More magic is, of course, always possible laterâ¦ I have some ideas. >>>> >>>> Marcus >>>> >>>> >>>>> On 28 Jan 2016, at 13:54, Aliaksei Syrel <alex.syrel(a)gmail.com> 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 > > Is it common to use #assert: outside of unit tests? I always saw this as part of sunit and wondering why one would want to disable it. > Sure, there are other language which uses some assert-like construct for runtime checks. But I would have thought smalltalk just does not > use it like that or we would have another one, that is not used for sunit tests. My VMMaker.oscog VM source is full of asserts and it is a key debugging tool. When C source is generated assert becomes a macro which allows asserts to be eliminated from the production VM. I also use "eassert" (expensive assert, which is only evaluated when a flag is set) and deny: because it is very nicely readable. I picked up this style from Peter Deutch's HPS VM, the VW VM, written in C. I was introduced to preconditions and post conditions at college and asserts are very similar, and can subsume that style. But I am open to a compiler switch to turn them off. I'll answer why in a reply to the next message in thread. > nicolai _,,,^..^,,,_ (phone)

Jan. 29, 2016

Travis CI integration added to OSSubprocess and FFICHeaderExtractor

by Mariano Martinez Peck

Hi guys, This is just to let you know that with the help of Esteban and between some work together [1] [2] I was able to have Travis CI integrated with OSSubprocess and FFICHeaderExtractor [3] [4] . Both projects are built and tested under Linux and OSX. Note also that one of the projects does a lot of FFI calls to system libs like libc and the other even generates C programs, compiles them and run it. Even the OS dependencies (like installing the compiler) are resolved correctly :) If someone wants to know how it's done, simply check the .travis.yml and the scripts/run-test.sh of each project [5] [6]. [1] https://pharo.fogbugz.com/f/cases/17488 [2] https://pharo.fogbugz.com/f/cases/17490 [3] https://travis-ci.org/marianopeck/OSSubprocess [4] https://travis-ci.org/marianopeck/FFICHeaderExtractor [5] https://github.com/marianopeck/OSSubprocess [6] https://github.com/marianopeck/FFICHeaderExtractor Cheers, -- Mariano http://marianopeck.wordpress.com

Jan. 29, 2016

Re: [Pharo-dev] Experiences with git, tODE and GsDevKit_home: Part 1 - basic structure considerations

by Dale Henrichs

On 01/28/2016 02:28 PM, Stephan Eggermont wrote: > On 28-01-16 19:26, Dale Henrichs wrote: >> Well, this is a direction that could be taken, but there some advantages >> to sharing the actual checkouts ... in my workflow, I have a collection >> of git repos that represent my current base system and I have a number >> of stones (images) that share this same base system and when I make a >> bugfix in one, I am interested in being able to easily load the bugfix >> into the other stones before starting work in that particular stone so >> having a shared "current directory" amongst a set of stones is actually >> convenient .... this "convenience" also extends to building a new stone >> (image) since the build scripts only need to load from the currently >> checkout versions without having to know the specific SHA of interest >> ... > > So we'd basically have a directory of vms, one of image templates and > one of git repos, and a project directory where I'd make a particular > combination of the three? Or when multi-platform a platform directory > above the vms and images one? Stephan, It does make sense to begin thinking about a structure that makes sense for Pharo. In GsDevKit_home, I have a $GS_HOME env var that points to the root of the directory structure for a collection of stones and the top-level directory structure looks like the following: â¸ $GS_HOME â¸ bin/ â¸ dev/ â¸ docs/ â¸ etc/ â¸ server/ â¸ shared/ â¸ sys/ â¸ tests/ â¸ travis/ and for just the stones and git structure, I have the following: â¸ $GS_HOME â¾ server/ â¸ stones/ â¸ <stone-name-1>/ â¸ git/ â¸ product/ â¸ <stone-name-2>/ â¸ git/ â¸ product/ â¸ <stone-name-3>/ â¸ git/ â¸ product/ â¾ shared/ â¸ downloads/ â¸ products/ â¸ repos/ where: - $GS_HOME/shared/repos is the location for the shared git repositories - $GS_HOME/shared/downloads/products is the location of the GEMSTONE distibution basically vms and templates - $GS_HOME/server/stones/<stone-name-1> is the location of the stone-specific files and directories. - $GS_HOME/server/stones/<stone-name-1>/product is a symbolic link from the stone to the $GS_HOME/shared/downloads/products/<gemstone-product> directory - $GS_HOME/server/stones/<stone-name-1>/git is the standard location for stone-specific git clones You can see that I make provision for "shared repos" and "stone-specific" repos --- the stone-specific repo comes into play only occasionally but making a provision for this possibility is useful on the odd occasion when you are going to do protracted work on one of the shared repositories and that work is likely to break something important ... I think of the stone-specific directories as transient and once the work is done and integrated into the shared/repos git repo, the local clone is destroyed... So in your case you might have something like this: â¾ projects/ â¾ <project-1>/ â¸ git/ â¸ project.image â¸ project.changes/ â¾ <project-2>/ â¸ git/ â¸ project.image â¸ project.changes/ â¸ repos/ â¸ templates/ â¸ vms/ The idea with the projects directory is that you might have a multiple images in play at once and the <project-n> directory would give you isolation for independent git repos as well as other artifacts that should be kept separate ... If it makes more sense to keep all of the image and changes files in a common directory, then an perhaps the following would be more appropriate: â¾ projects/ â¸ <project-1>.image â¸ <project-1>.changes â¸ <project-2>.image â¸ <project-2>.changes â¾ git/ â¸ <project-1>/ â¸<project-2>/ â¸ repos/ â¸ templates/ â¸ vms/ or something different:) For GemStone it is necessary to to dedicate a directory per stone, because of the volume of files/directory involved: â¸ backups/ â¸ bin/ â¸ extents/ â¸ git/ â¸ logs/ â¸ product/ â¸ snapshots/ â¸ stats/ â¸ tranlogs/ For Pharo, there might not need to be such separation on a per image/changes combo, although I can image that applications may indeed need additional files or directories associated in which case a directory per image would be useful ... Well I think this just about covers most of the things I was going to talk about on the topic of "sharing git repos between separate active images. Dale

Jan. 29, 2016

Re: [Pharo-dev] Experiences with git, tODE and GsDevKit_home: Part 1 - basic structure considerations

by Stephan Eggermont

On 28-01-16 19:26, Dale Henrichs wrote: > Well, this is a direction that could be taken, but there some advantages > to sharing the actual checkouts ... in my workflow, I have a collection > of git repos that represent my current base system and I have a number > of stones (images) that share this same base system and when I make a > bugfix in one, I am interested in being able to easily load the bugfix > into the other stones before starting work in that particular stone so > having a shared "current directory" amongst a set of stones is actually > convenient .... this "convenience" also extends to building a new stone > (image) since the build scripts only need to load from the currently > checkout versions without having to know the specific SHA of interest ... So we'd basically have a directory of vms, one of image templates and one of git repos, and a project directory where I'd make a particular combination of the three? Or when multi-platform a platform directory above the vms and images one? Stephan

Jan. 28, 2016

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

by Richard Sargent

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. This also offers the benefit that assertions are practical everywhere, not just under a TestCase hierarchy. 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.

Jan. 28, 2016

Re: [Pharo-dev] why do I get error...when I try to find senders?

by Nicolai Hess

2016-01-27 23:00 GMT+01:00 Nicolai Hess <nicolaihess(a)gmail.com>: > Sorry, I think this is from my fix for 15325 GT workspace/inspector > evaluates source wrong when it ends with $", treating it as nil instead > > I'll try to fix this. > 17491 <https://pharo.fogbugz.com/f/cases/17491/find-selector-shows-syntax-error-de…> find selector shows syntax error debugger > Am 27.01.2016 9:50 nachm. schrieb "stepharo" <stepharo(a)free.fr>: > >> Yes that one! >> Tx alex >> This should be related to Shout or RB. >> >> >> Le 27/1/16 21:15, Aliaksei Syrel a Ã©crit : >> >> >> I have the same. To reproduce: >> >> 1. open playground. >> 2. put both hands on keyboard. >> 3. type "at:" >> 4. press cmd+n or cmd+m >> 5. ... >> 6. Syntax Error >> [image: Inline image 1] >> >> >> Cheers, >> Alex >> >> On Wed, Jan 27, 2016 at 8:59 PM, Tudor Girba <tudor(a)tudorgirba.com> >> wrote: >> >>> Hmm, I never saw this one. Anyone else can reproduce this? >>> >>> Doru >>> >>> > On Jan 27, 2016, at 6:56 PM, stepharo < <stepharo(a)free.fr> >>> stepharo(a)free.fr> wrote: >>> > >>> > Hi >>> > >>> > I open playground or nautilus. >>> > I type >>> > compile:classified: >>> > and select the text >>> > and I press senders and I get a syntax error expected.... >>> > >>> > Just typing this mail now I cannot reproduce it. >>> > There is something wrong with the system. >>> > >>> > Stef >>> > >>> >>> -- >>> www.tudorgirba.com >>> www.feenk.com >>> >>> "Speaking louder won't make the point worthier." >>> >>> >>> >> >>

Jan. 28, 2016