- Pharo-dev - lists.pharo.org

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

by Nicolai Hess

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> >> 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. nicolai

Jan. 28, 2016

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

by Nicolas Cellier

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> > 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 > > > >

Jan. 28, 2016

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

by stepharo

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 >> <mailto:alex.syrel@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 >

Jan. 28, 2016

Re: [Pharo-dev] Contributing to Pharo

by Dale Henrichs

On 01/28/2016 12:16 PM, Thierry Goubier wrote: > Le 28/01/2016 20:55, Dale Henrichs a Ã©crit : >> >> >> On 01/28/2016 12:50 AM, Thierry Goubier wrote: >>> Configurations are a bit different, since a configuration can snapshot >>> multiple versions. But I'd really like to make it simple and obvious >>> how to setup a project. >> I'm not sure what you are talking about here. >> >> In Metacello a BaselineOf has a single version and the >> MetacelloMCVersion class manages the version ... Yes, a Configuration >> has multiple versions and each of those versions is an instance of >> MetacelloMCVersion.... >> >> Perhaps when you have time, you can provide a bit more information about >> what you are trying to do ... > > I was just looking at it from the angle of having to explain it to one > of my students (non-smalltalkers)... The simplest path to creating a > project. > > I guess one must have a tool like Versionner. From this perspective you should look at the MetacelloToolBox and specifically MetacelloToolBox class>>createBaselineOf:requiredProjects:packages:repositories:dependencies:groups:. Versionner uses the MetacelloToolBox api and about 3 months ago I added the basic support for creating a BaselineOf as I added a `project new` command to tODE ... I would be glad to expand the MetacelloToolBox api for BaselineOf if folks ask for specific functionality ... The MetacelloToolBox is meant to be the common point for programmatically creating and updating ConfigurationOf and BaselineOf ... Dale

Jan. 28, 2016

Re: [Pharo-dev] Contributing to Pharo

by Dale Henrichs

On 01/28/2016 12:55 AM, Christophe Demarey wrote: > Le 28 janv. 2016 Ã 09:34, Sven Van Caekenberghe a Ã©crit : > >>> On 28 Jan 2016, at 09:23, Christophe Demarey <Christophe.Demarey(a)inria.fr> wrote: >>> >>> I read too fast. >>> But my comment is still true. >>> We also want a new version browser. Monticello browser is too tied to ... Monticello. We would like a better approach for both git and monticello. >> It is totally wrong to put Git and Monticello at the same level, they are related but different things. >> >> Monticello models our code and your changes to it. It also has a way of putting a package into a persistent representation that can be copied around. An MC server is nothing more than storage. >> >> Filetree is another way of doing that, using a different representation, but it still needs MC for the high level stuff. Git is versioned storage. And there is a conflict there, yes. >> >> But throwing away the MC code and changes model would leave you with file outs. You do not want to go there, really. Never, ever. > I fully agree. > The problem is that Monticello does too much things: code representation, versioning, loading of the code and call of #initialize methods, etc. > We want to keep a code representation but the question that comes: is it the better code representation? We also have ring, ficus (hierarchical model on top of ring). For code representation, we would like to represent code (from packages to method source code) for multiple versions, in a hierarchical way (to be able to query easily), potentially coming from a remote environment. > We also need to split the loading part (loading from the code representation) and the serialization / deserialization part. > > At the end, we want an uniform way to represent code (not SCM related), a common API for versioning and different backends (git, Monticello). Agreed .... > By the way, we can add the storage format: there are already different versions of the filetree format (with metadata, without, one file per method, one file per class). At some point, we need to handle this point of variability. On this point I think that we will always want to support multiple disk formats .... in a perfect world, there is no reason not to have one file per method and no Monticello meta data ... but perfection does not exist. Monticello meta data was included in FileTree because it was needed over the last 4 years so that developers could dip there toes into using git without completely abandoning Monticello .... Now that we are gaining a critical mass of users and the tool support is starting to show up, dropping the meta data is a practical thing to do ... but there is code committed on github that hasn't been updated in years that is still being used and Monticello meta data is still present, so it is necessary to "support the older formats". The one file per method was chosen for two reasons. The first reason has to do with the fact that disk based SCMs are designed manage files as atomic units and in Smalltalk the method is the atomic unit for source code ... it is very convenient to be able to leverage native SCN files for a) versioning files and b) maintaining version history for a method as it moves from class to class ... The second reason has to do with the fact that there is no cross platform fileout format for Smalltalk. Chunk format comes is "common" but chunk format also relies on executing Smalltalk code to define classes and there hasn't been a standard class creation method since the second Smalltalk implementation showed up on the planet ... Technically, class and method definitions can be derived from a file per class approach, but without a standardized file format you end up with each dialect isolating itself from the others and this is not desirable nor necessary ... It just takes more work to come up with a file format that can accommodate the different needs of the different dialects .... the one method per file and a generic properties file for class definitions[1] and the provision for allowing additional platform specific property files and directories (like monticello meta data) simplified the whole process ... So I would like changing the disk format for sharing source code to be a multi-platform effort - which means that format that is chosen is flexible enough to allow dialects to include the meta data that they need ... It is important to note that there has never been a guarantees that all platforms would PRESERVE and WRITE foreign meta data ... the only provision that exists is that ALL platforms can READ the format while ignoring anything it doesn't recognize .... Dale [1] https://raw.githubusercontent.com/CampSmalltalk/Cypress/master/img/CypressS…

Jan. 28, 2016

Re: [Pharo-dev] Contributing to Pharo

by Thierry Goubier

Le 28/01/2016 20:55, Dale Henrichs a Ã©crit : > > > On 01/28/2016 12:50 AM, Thierry Goubier wrote: >> Hi Dale, >> >> 2016-01-27 15:41 GMT+01:00 Dale Henrichs >> <dale.henrichs(a)gemtalksystems.com >> <mailto:dale.henrichs@gemtalksystems.com>>: >> >> >> >> On 1/27/16 12:03 AM, Thierry Goubier wrote: >> >> Hi Dale, >> >> then a question: how does one query a baselineOf or a configOf >> to retrieve the current project state (i.e. packages) loaded >> in the image? >> >> Thierry >> >> Thierry, >> >> Good question:) >> >> To start with in tODE I have a class >> TDMetacelloProjectRegistrationDefinition which is part of the >> following hierarchy: >> >> Object >> TDDefinition >> TDPackageBasedDefinition >> TDAbstractProjectRegistrationDefinition >> TDGitProjectRegistrationDefinition >> TDMetacelloProjectRegistrationDefinition >> TDMetacelloRegistrationDefinition >> TDMetacelloBaselineRegistrationDefinition >> TDMetacelloConfigurationRegistrationDefinition >> TDMetacelloHybridRegistrationDefinition >> TDMetacelloUnloadedProjectRegistrationDefinition >> >> The method >> TDMetacelloProjectRegistrationDefinition>>workingCopies[1] >> calculates the list of MCWorkingCopy instances for the loaded >> packages associated with a project (including the configurationof >> or baselineof... or both). >> >> The key Metacello methods called include: >> >> MetacelloProjectRegistration>>projectVersion[2] >> MetacelloMCVersion>>packages[3] >> MetacelloPackageSpec>>workingCopy[4] >> MetacelloMCProjectSpec>>projectPackage[5] >> >> This is really the key information for doing all of the other >> operations for a "Project Browser" like "save all dirty packages >> and commit" and "give me diffs for all dirty packages in project"... >> >> >> I was just asking that because I'd like to see that information merged >> as much as possible; separating concepts just strikes me as unneeded >> complexity, at least for baselines. > Not sure what you mean by "separating concepts and unneeded complexity". > I provided a picture of some of the abstractions that I am using in tODE > ... these abstractions are used in a number of commands, but I also > tried to provide you with the basic implementation used in tODE in case > you were interested in the fact that tODE includes the BaselineOf > package in the list of packages for a project... This is me trying to express something and being unable to make it clear :) I'll have something at one point later. Or maybe not. Doesn't really matter; I'll wait until it becomes clearer to me. > The simple answer is MetacelloMCVersion>>packages[3] Thanks. I'll try something. >> Configurations are a bit different, since a configuration can snapshot >> multiple versions. But I'd really like to make it simple and obvious >> how to setup a project. > I'm not sure what you are talking about here. > > In Metacello a BaselineOf has a single version and the > MetacelloMCVersion class manages the version ... Yes, a Configuration > has multiple versions and each of those versions is an instance of > MetacelloMCVersion.... > > Perhaps when you have time, you can provide a bit more information about > what you are trying to do ... I was just looking at it from the angle of having to explain it to one of my students (non-smalltalkers)... The simplest path to creating a project. I guess one must have a tool like Versionner. > I apologize if I provided too much information but when working with > folks in different time zones, I am in the habit of packing as much > information in a message as possible, because it's often a 24 hour > turnaround for responses... (as it is in this case:) Don't worry about that, you already provided a lot, certainly enough for what I was looking for: a way to organize groups of packages in the image out of the Metacello baselines and configurations present, instead of hacking stuff based on catalog keywords and package name prefix. Now, it's time to implement... If I find that time :( Thierry

Jan. 28, 2016

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

by Sven Van Caekenberghe

> On 28 Jan 2016, at 20:59, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > > I totally dislike these hacks: it means that the source code does not anymore determine the behavior. > It's OK as long as it's just a hack,.. But it can't be serious. > Copying all the bad features from C is not required to become a mainstream thing ;) > Marcus, I definitely classify these fantastic super powers in evil category ! You are totally right, Nicolas. But, the compiler can be customised per class, if i am right, so then it is no longer global (which would be terrible indeed). > 2016-01-28 17:49 GMT+01:00 Marcus Denker <marcus.denker(a)inria.fr>: > > > On 28 Jan 2016, at 17:32, Torsten Bergmann <astares(a)gmx.de> wrote: > > > > > > > > Havent tried but would that still compile #assert: as used in SUnit? > > > > This very simplistic version would of course delete those, too. > > A real version needs to take this into account. > > Marcus > > >

Jan. 28, 2016

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

by Nicolas Cellier

I totally dislike these hacks: it means that the source code does not anymore determine the behavior. It's OK as long as it's just a hack,.. But it can't be serious. Copying all the bad features from C is not required to become a mainstream thing ;) Marcus, I definitely classify these fantastic super powers in evil category ! 2016-01-28 17:49 GMT+01:00 Marcus Denker <marcus.denker(a)inria.fr>: > > > On 28 Jan 2016, at 17:32, Torsten Bergmann <astares(a)gmx.de> wrote: > > > > > > > > Havent tried but would that still compile #assert: as used in SUnit? > > > > This very simplistic version would of course delete those, too. > > A real version needs to take this into account. > > Marcus > > >

Jan. 28, 2016

Re: [Pharo-dev] Contributing to Pharo

by Dale Henrichs

On 01/28/2016 12:50 AM, Thierry Goubier wrote: > Hi Dale, > > 2016-01-27 15:41 GMT+01:00 Dale Henrichs > <dale.henrichs(a)gemtalksystems.com > <mailto:dale.henrichs@gemtalksystems.com>>: > > > > On 1/27/16 12:03 AM, Thierry Goubier wrote: > > Hi Dale, > > then a question: how does one query a baselineOf or a configOf > to retrieve the current project state (i.e. packages) loaded > in the image? > > Thierry > > Thierry, > > Good question:) > > To start with in tODE I have a class > TDMetacelloProjectRegistrationDefinition which is part of the > following hierarchy: > > Object > TDDefinition > TDPackageBasedDefinition > TDAbstractProjectRegistrationDefinition > TDGitProjectRegistrationDefinition > TDMetacelloProjectRegistrationDefinition > TDMetacelloRegistrationDefinition > TDMetacelloBaselineRegistrationDefinition > TDMetacelloConfigurationRegistrationDefinition > TDMetacelloHybridRegistrationDefinition > TDMetacelloUnloadedProjectRegistrationDefinition > > The method > TDMetacelloProjectRegistrationDefinition>>workingCopies[1] > calculates the list of MCWorkingCopy instances for the loaded > packages associated with a project (including the configurationof > or baselineof... or both). > > The key Metacello methods called include: > > MetacelloProjectRegistration>>projectVersion[2] > MetacelloMCVersion>>packages[3] > MetacelloPackageSpec>>workingCopy[4] > MetacelloMCProjectSpec>>projectPackage[5] > > This is really the key information for doing all of the other > operations for a "Project Browser" like "save all dirty packages > and commit" and "give me diffs for all dirty packages in project"... > > > I was just asking that because I'd like to see that information merged > as much as possible; separating concepts just strikes me as unneeded > complexity, at least for baselines. Not sure what you mean by "separating concepts and unneeded complexity". I provided a picture of some of the abstractions that I am using in tODE ... these abstractions are used in a number of commands, but I also tried to provide you with the basic implementation used in tODE in case you were interested in the fact that tODE includes the BaselineOf package in the list of packages for a project... The simple answer is MetacelloMCVersion>>packages[3] > Configurations are a bit different, since a configuration can snapshot > multiple versions. But I'd really like to make it simple and obvious > how to setup a project. I'm not sure what you are talking about here. In Metacello a BaselineOf has a single version and the MetacelloMCVersion class manages the version ... Yes, a Configuration has multiple versions and each of those versions is an instance of MetacelloMCVersion.... Perhaps when you have time, you can provide a bit more information about what you are trying to do ... I apologize if I provided too much information but when working with folks in different time zones, I am in the habit of packing as much information in a message as possible, because it's often a 24 hour turnaround for responses... (as it is in this case:) Dale

Jan. 28, 2016

Re: [Pharo-dev] Nitpick: Launcher Colors

by Cyril Ferlicot D.

Le 28/01/2016 20:20, Sean P. DeNigris a Ã©crit : > I don't get the addition of alternating row colors to Launcher. As I > understand this, it's value is in a table-like situation where one wants to > track across the row in the same record. Since both panes have only one cell > per row, I don't get the purpose, and it looks really funky to me in the > dark theme. > > My 2c. > Sean > When the launcher is in full screen and the label of the image/template is short, it allow to click on the right row where there is nothing. In Windows it happen a lot that the window is in full screen. > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/Nitpick-Launcher-Colors-tp4874592.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. > -- Cyril Ferlicot http://www.synectique.eu 165 Avenue Bretagne Lille 59000 France

Jan. 28, 2016