December 2013 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Opal hook?

by StÃ©phane Ducasse

thanks for your analysis I will have a look at it. I was thinking to check if I should redefine UndefinedObject>>subclass: to raise an error Stef On Dec 3, 2013, at 3:17 PM, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > do you know if the OCUndeclaredVariable is raised for unknown superclass? > > this code: > > AnUnknownClass subclass: #Adaptor1Example > instanceVariableNames: 'customers accountID address name phoneNumber' > classVariableNames: '' > poolDictionaries: '' > category: 'Examples-Cookbook' > > is run as a Do It. In Do It, unknown variables (as here AnUnknownClass) raise an OCUndeclaredVariableWarning. > For example, running: > > AnUnknownClass subclass: #Adaptor1Example > instanceVariableNames: 'customers accountID address name phoneNumber' > classVariableNames: '' > poolDictionaries: '' > category: 'Examples-Cookbook' > > executes the default action for OCUndeclaredVariableWarning, which is opening a pop-up titled: "Unknown variable ...". Here the error is raised at compilation time, therefore it would have no effect to wrap this with a #on:do: > > [ AnUnknownClass subclass: #Adaptor1Example > instanceVariableNames: 'customers accountID address name phoneNumber' > classVariableNames: '' > poolDictionaries: '' > category: 'Examples-Cookbook' ] on: OCSemanticWarning do: [ ] > > ==> same problem. > > Now if you do: > > [ OpalCompiler new evaluate: 'AnUnknownClass subclass: #Adaptor1Example > instanceVariableNames: ''customers accountID address name phoneNumber'' > classVariableNames: '''' > poolDictionaries: '''' > category: ''Examples-Cookbook''' ] on: OCSemanticWarning do: [ :e | e halt ] > > Here we catch the error, and you can handle it. > Now it is not easily possible to resume the error, because you want a global instead and Opal expects a temp (there are way to resume but with very deep stack manipulation that I do not want to show to young pharoers present on this mailing list). So the best is to retry it. One solution is therefore: > > [ OpalCompiler new evaluate: 'AnUnknownClass subclass: #Adaptor1Example > instanceVariableNames: ''customers accountID address phoneNumber'' > classVariableNames: '''' > poolDictionaries: '''' > category: ''Examples-Cookbook''' ] > on: OCSemanticWarning do: [ :e | > Smalltalk at: e node name put: StubRootClass. > e retry ] > > with e node name answering #AnUnknownClass here. > Now you need to make sure that the exception block is executed for the case of a missing superclass and not something else or you will end up creating loads of globals. > > The exception block should be something similar to: > > [ :e | > e node name first isUppercase and: [ "some condition" ] ifTrue: [ > Smalltalk at: e node name put: StubRootClass. > ^ e retry ]. > e pass ] > > How to undefined and OCUndeclaredVariableWarning relate? > > In your case, while loading from Monticello the code is compiled and evaluated in non interactive mode. Therefore it cannot trigger the default action of OCUndeclaredVariableWarning which is a UI event. So it sets by default the unknown global to: > > Undeclared at: varName asSymbol put: nil. > OCUndeclaredVariable new name: varName asSymbol > > in: OCUndeclaredVariableWarning >>defaultAction > > which then later triggers the code in UndefinedObject. > > > > 2013/12/3 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > > On Dec 3, 2013, at 11:20 AM, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > >> Then for your project replace ProtoObject by StubRootClass in UndefinedObject>>subclass:instanceVariableNames:classVariableNames:poolDictionaries:category: it will work. > > yes but this is ugly because I do not want override. > So I will introduce an exception so that we can do that in a clean way. > > >> An alternative is to catch OCSemanticWarning or its subclass OCUndeclaredVariableWarning while loading the new classes and execute another code instead of the default action in the exception handling block > > > do you know if the OCUndeclaredVariable is raised for unknown superclass? > How to undefined and OCUndeclaredVariableWarning relate? > > Stef >> >> >> 2013/12/3 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> >> > Well if the class does not exists it calls the method on UndefinedObject (UndeclaredBinding). And you have: >> >> I will check and see if I can set up a hook because having classes subclasses of protoobject is not a good idea >> when loading broken code. >> >> > UndefinedObject>>subclass: nameOfClass >> > instanceVariableNames: instVarNames >> > classVariableNames: classVarNames >> > poolDictionaries: poolDictnames >> > category: category >> > "Calling this method is now considered an accident. If you really want to create a class with a nil superclass, then create the class and then set the superclass using #superclass:" >> > self traceCr: ('Attempt to create ', nameOfClass, ' as a subclass of nil. Possibly a class is being loaded before its superclass.'). >> > ^ProtoObject >> > subclass: nameOfClass >> > instanceVariableNames: instVarNames >> > classVariableNames: classVarNames >> > poolDictionaries: poolDictnames >> > category: category >> > >> > The best is to set manually the superclass after with #superclass: >> >> No because I have no idea what are the classes whose superclasses are not in the image. >> With a proper hook I could just say >> if the superclass is unknow please use the "StubRootClass" of my framework. >> else let the system handles it. >> >> Stef >> > >

Dec. 3, 2013

Re: [Pharo-dev] [Pharo-users] Building Pharo using Interpreter Class

by StÃ©phane Ducasse

Hello kirstin why dimitri is not able to post? can you tell us more? Stef On Dec 3, 2013, at 1:17 PM, Kirstin Heidler <kirstin.heidler(a)student.hpi.uni-potsdam.de> wrote: > My freind Dimitri was not able to post his message. I am working with him on this. > > _______________________________________________________________________________ > > Hello, > > as part of a Seminar in the University im trying to build the PharoVM. > According to the README file here ([1]) I was able to generate and to > build the VM successfully. > > Now I would like to build the VM without Cog or Stack-to-Register > optimizations... The problem here is, that I could not find any config > class (which is a subclass of CPlatformConfig), that provides the right > configurations and allows to build the VM without errors. I have tried > to modify PharoUnixConfig(because it was the default config class), but > unfortunately the build failes when the compiler tries to compile > gcc3x-interp.c. > > Could somebody help me with this problem? How should I configure my own > Config class? > > Basically our Group tries to implement an object table in Pharo and we > want to use (and modify) the basic Interpreter class. > > > > [1] https://github.com/pharo-project/pharo-vm > > > Best regards, > Dimitri Korsch >

Dec. 3, 2013

Re: [Pharo-dev] CompiledMethod>>#= is broken

by Eliot Miranda

On Tue, Dec 3, 2013 at 11:27 AM, Eliot Miranda <eliot.miranda(a)gmail.com>wrote: > > > > On Tue, Dec 3, 2013 at 9:49 AM, Oscar Nierstrasz < > oscar.nierstrasz(a)gmail.com> wrote: > >> >> The following code breaks: >> >> (SortedCollectionTest>>#testDo) = (SortedCollectionTest>>#testStoreOn). >> >> because it makes use of AdditionalMethodState>>#analogousCodeTo: which >> tries to send #analogousCodeTo: to a property which is an Association. >> >> It seems to me the solution is to implement >> Association>>#analogousCodeTo: with an equality test: >> >> analogousCodeTo: anObject >> ^self class == anObject class >> and: [ self = anObject ] >> >> Does this make sense? >> > > Yes. I should have written it this way in the first place. Thanks. > > >> >> See: >> >> >> https://pharo.fogbugz.com/f/cases/12077/MNU-in-AdditionalMethodState-analog… >> >> Oscar Nierstrasz >> >> >> > > > -- > best, > Eliot > -- best, Eliot

Dec. 3, 2013

Re: [Pharo-dev] Unifying Testing Ideas

by Attila Magyar

Sean P. DeNigris wrote > In fact, #does: and #answers: could easily be merged, using double > dispatch to pass either a block or a value. It's true, but it would make difficult to return a block. E.g. mock can receive: #msg; answers: [ [..] ] Sean P. DeNigris wrote > Unrelatedly, it would be slightly clearer to rename "anything" to > "anyMessage". "anything" makes it seem like it could be passed as an > argument, which doesn't work. Or alternately, you could probably rename > AnyMessage to Anything and combine its API with that of AnyArgument if > they don't clash... I agree, I'll try to combine them first, but anyMessage/anyArgument seems fine too. Anyways, I'm working on the next version with a slightly different api. My plan is to fully separate the DSL from the main part. This will make possible to play with different syntax without touching the core. Or even the users will be able to define their own syntax. -- View this message in context: http://forum.world.st/Unifying-Testing-Ideas-tp4726787p4727144.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Dec. 3, 2013

Re: [Pharo-dev] CompiledMethod>>#= is broken

by Eliot Miranda

On Tue, Dec 3, 2013 at 9:49 AM, Oscar Nierstrasz <oscar.nierstrasz(a)gmail.com > wrote: > > The following code breaks: > > (SortedCollectionTest>>#testDo) = (SortedCollectionTest>>#testStoreOn). > > because it makes use of AdditionalMethodState>>#analogousCodeTo: which > tries to send #analogousCodeTo: to a property which is an Association. > > It seems to me the solution is to implement Association>>#analogousCodeTo: > with an equality test: > > analogousCodeTo: anObject > ^self class == anObject class > and: [ self = anObject ] > > Does this make sense? > Yes. I should have written it this way in the first place. Thanks. > > See: > > > https://pharo.fogbugz.com/f/cases/12077/MNU-in-AdditionalMethodState-analog… > > Oscar Nierstrasz > > > -- best, Eliot

Dec. 3, 2013

Re: [Pharo-dev] Unifying Testing Ideas

by Denis Kudriashov

Problem with TestCase approach is mixing two separate concerns. First is how we want to define system specifications. Another is how we can persist such specifications. When we stay at test case level we lost freedom for specification definition. We restricted with smalltalk language artifacts. For example, how we can group our tests? With classic test case approach we have four levels: packages, classes, protocols and methods. Now remember how many times you put long names for test like #shouldDoingSomethingWhenSomeSitiationHappensDuringAnotherSituationHappenButWhenSituation3NotHappen. And most times you have tests for each separate situation with same long test names. In smalltalk only way to refactor test names duplication is extraction same "when condition" to separate test case classes. But it means that you build classes with very long names and most times your test names stay big (but with reduced length). And do you know way how to group such classes? Only way is put such classes to own class category. Nobody doing this. Now imagine we don't care how to persist tests (specifications). We can model specifications with explicit objects which present #when, #should and other test artifacts, which can group specifications with arbitrary way. With true objects we don't name our specifications with method name convention. We can name tests with natural language, we can put names for "when" and "should" expressions with natural language. With objects we can build "smalltalk vision" of BDD framework. Really with smalltalk live system testing environment can be very different from other languages. BDD frameworks of other languages just changed names of "TDD dictionary". They all stay restricted with language syntax. So it is my vision. I really want to build such system but I have no time for this yet. Maybe Sean doing something similar? 2013/12/3 Esteban A. Maringolo <emaringolo(a)gmail.com> > 2013/12/3 Dennis Schetinin <chaetal(a)gmail.com> > > > > I see the only correct way to build a good testing environment: tests > should be basically objects, not methods. > > They are objects. Instances of TestCase. > > But for simplicity they're implemented in a single "factory" class, > the TestCase subclass... > > > > Esteban A. Maringolo > >

Dec. 3, 2013

Re: [Pharo-dev] 12259: FileSystem memory reads writesusing a binary stream by default

by Damien Cassou

Thanks Max for the report. Do you have an idea on how we could solve the problem ? The previous behaviour was not acceptable either because the streams that came out of a memory filesystem were the only ones with binary content On Dec 3, 2013 5:35 PM, "Max Leske" <maxleske(a)gmail.com> wrote: > Damien, Marcus > > this change breaks a lot of things in FileSystem-Git. I donât disagree > with the idea that reading characters should be default (one could argue > about itâ¦) but your change makes it IMPOSSIBLE to read bytes because > unprintable characters are discarded! So if my ByteArray is a NULL > terminated string, for instance, I can not check for the NULL termination > anymore. > > Cheers, > Max >

Dec. 3, 2013

CompiledMethod>>#= is broken

by Oscar Nierstrasz

The following code breaks: (SortedCollectionTest>>#testDo) = (SortedCollectionTest>>#testStoreOn). because it makes use of AdditionalMethodState>>#analogousCodeTo: which tries to send #analogousCodeTo: to a property which is an Association. It seems to me the solution is to implement Association>>#analogousCodeTo: with an equality test: analogousCodeTo: anObject ^self class == anObject class and: [ self = anObject ] Does this make sense? See: https://pharo.fogbugz.com/f/cases/12077/MNU-in-AdditionalMethodState-analog… Oscar Nierstrasz

Dec. 3, 2013

Slice 12324

by Stephan Eggermont

Can anyone put it in place? Canât seem to commit it

Dec. 3, 2013

[pharo-project/pharo-core]

by GitHub

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

Dec. 3, 2013