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

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. 28, 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

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