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

Re: [Pharo-dev] Color yzw

by Nicolai Hess

2016-01-29 13:10 GMT+01:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > Hi Nicolai. > Now your proposals in slice 17496 > <https://pharo.fogbugz.com/f/cases/17496/add-table-for-all-defined-method-se…> > . > We change it a little bit: we make SelectorsTable lazy. And code > completion uses it too. > +1, Let's see if it works :) Thanks > > 2016-01-16 22:17 GMT+01:00 Nicolai Hess <nicolaihess(a)gmail.com>: > >> >> >> 2016-01-16 13:46 GMT+01:00 Marcus Denker <marcus.denker(a)inria.fr>: >> >>> >>> On 16 Jan 2016, at 13:26, Nicolai Hess <nicolaihess(a)gmail.com> wrote: >>> >>> >>> >>> 2016-01-16 10:11 GMT+01:00 Marcus Denker <marcus.denker(a)inria.fr>: >>> >>>> >>>> anyone an idea? >>>> >>>> I'm trying to think. >>>> Looks like it would be good to be able to make a distinction between >>>> symbols and selectors (selectors installed >>>> in method dictionaries) >>>> >>>> >>>> yes, this would improve code completion a bit, too, as there are more >>>> symbols than symbols that are actually names >>>> of methods. >>>> >>>> The data could be created per environment (Smalltalk globals) the first >>>> time and then cached till shutdown. >>>> (it would be an array of size 46451, pointing to existing symbols). >>>> >>>> The environment could cache sent selectors, tooâ¦ pablo did an >>>> experiment with that. >>>> >>>> Marcus >>>> >>>> >>> How about a new SymbolTable "SelectorTable" that gets new entries on >>> every method compilation ? >>> >>> >>> maybe better when a method is added to a Method Dictionary? This way >>> even adding things the strange >>> way would work... >>> >> >> I tried some methods from TBehavior basicAddSelector:withMethod: >> but for example Nautilus, directly modifies method dict >> >> >>> >>> >>> I hacked a simple experimental version. >>> But I don't yet understand the workflow for initialisation of the Symbol >>> class (with rehash, interned, and compacting). >>> >>> >>> If we hook into adding methods, then compactSymbolTable and rehash could >>> just reset the SelectorTable and fill it after by going over all methodsâ¦ >>> >> >> >> see attached changesets. >> >> load with: >> >> DangerousClassNotifier disableDuring:[ >> String subclass: #Symbol >> instanceVariableNames: '' >> classVariableNames: 'NewSymbols OneCharacterSymbols SymbolTable >> SelectorTable' >> package: 'Collections-Strings' >> ]. >> >> DangerousClassNotifier disableDuring:[ >> 'selectortable.1.cs' >> asFileReference fileIn. >> ]. >> Symbol initSelectorTable. >> 'use_selector_table.cs' asFileReference fileIn. >> >> what do you think ? >> >> (selectortable.cs defines SelectorTable and some methods in Symbol and >> String) >> (use_selector_table adds selectors as internedSelectorSymbol if this >> selector is set as a selector on CompiledMethod >> and uses findInternedSelector .... in RubStyler visitMessageNode) >> >> >>> >>> >>> Marcus >>> >>> >> >

Jan. 29, 2016

Re: [Pharo-dev] [pharo-project/pharo-core] 6456a3: 50555

by Esteban Lorenzano

this is, again, not trueâ¦ integrator is seriously brokenâ¦ looking at it now. > On 29 Jan 2016, at 12:28, GitHub <noreply(a)github.com> wrote: > > Branch: refs/heads/5.0 > Home: https://github.com/pharo-project/pharo-core > Commit: 6456a3f5d3400e8efce6941a99ea425f7c3da45a > https://github.com/pharo-project/pharo-core/commit/6456a3f5d3400e8efce6941a… > Author: Jenkins Build Server <board(a)pharo-project.org> > Date: 2016-01-29 (Fri, 29 Jan 2016) > > Changed paths: > R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50554.st > A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50555.st > R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50554.st > A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50555.st > M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st > > Log Message: > ----------- > 50555 > 16735 Replace Startup/Shutdown list with SessionManager > https://pharo.fogbugz.com/f/cases/16735 > > http://files.pharo.org/image/50/50555.zip > >

Jan. 29, 2016

Re: [Pharo-dev] Color yzw

by Denis Kudriashov

Hi Nicolai. Now your proposals in slice 17496 <https://pharo.fogbugz.com/f/cases/17496/add-table-for-all-defined-method-se…> . We change it a little bit: we make SelectorsTable lazy. And code completion uses it too. 2016-01-16 22:17 GMT+01:00 Nicolai Hess <nicolaihess(a)gmail.com>: > > > 2016-01-16 13:46 GMT+01:00 Marcus Denker <marcus.denker(a)inria.fr>: > >> >> On 16 Jan 2016, at 13:26, Nicolai Hess <nicolaihess(a)gmail.com> wrote: >> >> >> >> 2016-01-16 10:11 GMT+01:00 Marcus Denker <marcus.denker(a)inria.fr>: >> >>> >>> anyone an idea? >>> >>> I'm trying to think. >>> Looks like it would be good to be able to make a distinction between >>> symbols and selectors (selectors installed >>> in method dictionaries) >>> >>> >>> yes, this would improve code completion a bit, too, as there are more >>> symbols than symbols that are actually names >>> of methods. >>> >>> The data could be created per environment (Smalltalk globals) the first >>> time and then cached till shutdown. >>> (it would be an array of size 46451, pointing to existing symbols). >>> >>> The environment could cache sent selectors, tooâ¦ pablo did an experiment >>> with that. >>> >>> Marcus >>> >>> >> How about a new SymbolTable "SelectorTable" that gets new entries on >> every method compilation ? >> >> >> maybe better when a method is added to a Method Dictionary? This way even >> adding things the strange >> way would work... >> > > I tried some methods from TBehavior basicAddSelector:withMethod: > but for example Nautilus, directly modifies method dict > > >> >> >> I hacked a simple experimental version. >> But I don't yet understand the workflow for initialisation of the Symbol >> class (with rehash, interned, and compacting). >> >> >> If we hook into adding methods, then compactSymbolTable and rehash could >> just reset the SelectorTable and fill it after by going over all methodsâ¦ >> > > > see attached changesets. > > load with: > > DangerousClassNotifier disableDuring:[ > String subclass: #Symbol > instanceVariableNames: '' > classVariableNames: 'NewSymbols OneCharacterSymbols SymbolTable > SelectorTable' > package: 'Collections-Strings' > ]. > > DangerousClassNotifier disableDuring:[ > 'selectortable.1.cs' > asFileReference fileIn. > ]. > Symbol initSelectorTable. > 'use_selector_table.cs' asFileReference fileIn. > > what do you think ? > > (selectortable.cs defines SelectorTable and some methods in Symbol and > String) > (use_selector_table adds selectors as internedSelectorSymbol if this > selector is set as a selector on CompiledMethod > and uses findInternedSelector .... in RubStyler visitMessageNode) > > >> >> >> Marcus >> >> >

Jan. 29, 2016

[pharo-project/pharo-core]

by GitHub

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

Jan. 29, 2016

[pharo-project/pharo-core] 6456a3: 50555

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 6456a3f5d3400e8efce6941a99ea425f7c3da45a https://github.com/pharo-project/pharo-core/commit/6456a3f5d3400e8efce6941a… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-01-29 (Fri, 29 Jan 2016) Changed paths: R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50554.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50555.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50554.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50555.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 50555 16735 Replace Startup/Shutdown list with SessionManager https://pharo.fogbugz.com/f/cases/16735 http://files.pharo.org/image/50/50555.zip

Jan. 29, 2016

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