October 2009 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Linux FFI question: library given function name?

by HernÃ¡n Morales Durand

http://www.linuxselfhelp.com/HOWTO/Program-Library-HOWTO/miscellaneous.html 2009/10/27 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> > Hello all, > > In the short term, I'm looking for where I might find syslog() and friends, > but a fishing lesson would be even better. How does one figure out in which > library a named function lives? > > Bill > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 28, 2009

Re: [Pharo-project] Abstract classes

by Alexandre Bergel

>> If the class >> contains any method that sends #subclassResponsibility, the we >> consider the class as abstract. Presence of abstract method in the metaclass is also necessary. -=-=-=-=-=-=-=-=-=-=-=-= ISSUE #1383: This issue proposes the addition of -two new methods in Behavior: allMethods and isAbstractClass. -one new method in Metaclass -two testing methods in BehaviorTest that test the allMethods and isAbstractClass allMethods returns the list of non-overrided compiled methods. Behavior already answer to allSelectors, allMethods was missing. isAbstractClass answers true if the receiving class or its metaclass contains or inherits an abstract method All tests in BehaviorTest are green. Tested in a pharo1.0-10491- rc1dev09.10.5 -=-=-=-=-=-=-=-=-=-=-=-= A .cs file is attached to the issue. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Oct. 28, 2009

Re: [Pharo-project] Abstract classes

by Alexandre Bergel

> As Mariano writes, most applications implement a message #isAbstract > themselves with the exact semantics they require. I don't think a > generic message in Behavior is really useful, especially if it is not > used by the core system. In that case, we could have isAbstractClass or something else. I feel this information is important. > If the class > contains any method that sends #subclassResponsibility, the we > consider the class as abstract. I am not sure what "contains" means in that context. But apparently, the definition you gave is not sufficient. The presence of subclassResponsibility need to be checked in the methods obtained from superclasses. (the code I gave in my previous email does not satisfy this although). I will create an issue. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Oct. 28, 2009

Re: [Pharo-project] Making packages shipped with Pharo ready for 1.0

by Mariano Martinez Peck

On Tue, Oct 27, 2009 at 1:04 PM, Adrian Lienhard <adi(a)netstyle.ch> wrote: > Hi, > > I've more closely looked at the failing tests and undeclared > references in the Pharo image. The test result is 14 expected > failures, 34 failures, 54 errors, 2 unexpected passes. Considering > that the Pharo-core ships with all tests green, this situation needs > to be fixed. > > First of all, I really want to thank you Adrian. I am always complaining about this, but I never took the time to do something. So I _really_ appreciate your work and I think this is very important for Pharo. I urge the package maintainers to closely look at the list below and > provide fixes and cleanups of their code. > > If there are packages without maintainers, may be this could be a task for Smalltalks 2009 Pharo Sprint in November. > There are also 9 tests failing from Pharo-core. I will take care of > those. > > Nil > ----- > - Sends deprecated message: #findLastOccuranceOfString:startingAt: > - A test opens a workspace that says: "Squeak is a beautiful language. > Look at http:\\www.squeak.org ..." > - Another test opens another workspace > - NSBuffer has method that references an undeclared variable > 'collection' > - undeclared reference to GradientFillMorph, StringSocketStream > - Total failing tests: 10 > - Total tests with errors: 11 > > ECompleteion > ------------ > - 7 tests failing > - 2 errors > > O2 > -- > - #dropOnClass: references InputSensor (this class does not exist > anymore!) > - 15 undeclared references to OB* classes, to non-existent variable > hasChanges, modifiedTimeStamp, smartGroup, and sensor > - 11 failing tests > - >30 tests with errors > > OB > ------ > - undeclared references: HttpResponse, Json, JsonObject > - #dropOnClass: references InputSensor (this class does not exist > anymore!) > > NewInspector > ------------ > - undeclared reference automaticallyHideIfNoChild > - NewInspector DNU #inspect (sent in #testSymbolTableM6812) > > Shout > ----- > - undeclared variable sourceMap > > RB > -- > - undeclared reference to RBBasicLintRuleTest and > RBTransformationRuleTest > > Pharo-core tests failing > ------------------------ > - FontTest>>testFallback (assumes different font, to be removed) > - FontTest>>testParagraphFallback (assumes different font, to be > removed) > - FontTest>>testResetAfterEmphasized (assumes different font, to be > removed) > - StandardSystemFontsTest>>testRestoreDefaultFonts (assumes different > font, to be removed) > - TestIndenting>>testNewLineStartsIndentedWhenWrapped (assumes > different font, to be removed) > - TestIndenting>>testSetUp (assumes different font, to be removed) > - LocaleTest>>testIsFontAvailable (some Japanese font checking that > fails with DejaVu, to be removed) > - testFinalizationOfEquals (was on my to do list, but works again: > remove expected failure tag) > - testObsoleteClasses: again includes classes from MC and others (have > to be checked) > > MorphExamplesAndDemos > --------------------- > - undeclared references to DescriptionForPartsBin and ScreeningMorph > > Cheers, > Adrian > > BTW, Damien, do we know for each package who the maintainer is? Does > each package have one? > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 28, 2009

Re: [Pharo-project] Abstract classes

by Lukas Renggli

> The only problem I see (maybe I am wrong) here is that there are already a > lot of implementors of isAbstract. For example, those used in Sunit. So, if > you add this method to Behavior, there will be a lot of non-intentional > overrides. As Mariano writes, most applications implement a message #isAbstract themselves with the exact semantics they require. I don't think a generic message in Behavior is really useful, especially if it is not used by the core system. Interesting in this context is how the Refactoring Engine determines if a class is abstract: "Smalltalk doesn't have any language feature that denotes an abstract class like C++ or Java. As a result, we check for a couple things when looking for an abstract class. If the class contains any method that sends #subclassResponsibility, the we consider the class as abstract. A method that sends subclassResponsibility signifies that users should override this method in every subclass to have all the class' functionality to work. Another check we use to determine if a class is abstract is to look for references to the class. If the class is not referenced then the class is considered to be abstract, since there is no way to create an instance of the class." [http://st-www.cs.illinois.edu/users/brant/Refactory/] Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Oct. 28, 2009

Re: [Pharo-project] Abstract classes

by Alexandre Bergel

> The only problem I see (maybe I am wrong) here is that there are > already a lot of implementors of isAbstract. For example, those used > in Sunit. So, if you add this method to Behavior, there will be a > lot of non-intentional overrides. I thought about it, but I haven't felt this could be a real problem. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Oct. 28, 2009

Re: [Pharo-project] Abstract classes

by Mariano Martinez Peck

On Wed, Oct 28, 2009 at 10:22 AM, Alexandre Bergel <alexandre(a)bergel.eu>wrote: > Dear List, > > I was looking for a way to test whether a class is abstract or not. > One easy way, is to check whether the class sends the message > subclassResponsibility. This is not perfect, since we should also > check whether the receiver is 'self' and this is the only statement in > the method body. Looking at sender of #subclassResponsibiliy did not > reveal anything. I propose to define the following method: > > Behavior>>isAbstract > ^ self methods anySatisfy: [:cm | cm sendsSelector: > #subclassResponsibility ] > > The only problem I see (maybe I am wrong) here is that there are already a lot of implementors of isAbstract. For example, those used in Sunit. So, if you add this method to Behavior, there will be a lot of non-intentional overrides. > Shall I can create an issue and add a changeset? > > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 28, 2009

[Pharo-project] Abstract classes

by Alexandre Bergel

Dear List, I was looking for a way to test whether a class is abstract or not. One easy way, is to check whether the class sends the message subclassResponsibility. This is not perfect, since we should also check whether the receiver is 'self' and this is the only statement in the method body. Looking at sender of #subclassResponsibiliy did not reveal anything. I propose to define the following method: Behavior>>isAbstract ^ self methods anySatisfy: [:cm | cm sendsSelector: #subclassResponsibility ] Shall I can create an issue and add a changeset? Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Oct. 28, 2009

Re: [Pharo-project] How to make Pharo produce random garbage bytes

by Lukas Renggli

If you are up to that kind of random data you can also try Object new executeMethod: (Point >> #x) Lukas 2009/10/28 Niko Schwarz <niko.schwarz(a)googlemail.com>: > Hi list, I learned something fun today from a friend, how to make > Pharo produce random garbage! > > Â Make a class AC which is defined as: > Â Object subclass: #AC > Â Â Â instanceVariableNames: 'a' > Â Â Â classVariableNames: '' > Â Â Â poolDictionaries: '' > Â Â Â category: 'OB-Standard-Browsers' > > Then you make a second class AB defined as: > > Object variableByteSubclass: #AB > Â Â Â instanceVariableNames: '' > Â Â Â classVariableNames: '' > Â Â Â poolDictionaries: '' > Â Â Â category: 'OB-Standard-Browsers' > > Then you make accessors for 'a' in AC > Now execute: AB superclass: AC > And then you do "AB new a" which gives you back random data. > > > Cheers, > > Niko > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Lukas Renggli http://www.lukas-renggli.ch

Oct. 28, 2009

[Pharo-project] How to make Pharo produce random garbage bytes

by Niko Schwarz

Hi list, I learned something fun today from a friend, how to make Pharo produce random garbage! Make a class AC which is defined as: Object subclass: #AC instanceVariableNames: 'a' classVariableNames: '' poolDictionaries: '' category: 'OB-Standard-Browsers' Then you make a second class AB defined as: Object variableByteSubclass: #AB instanceVariableNames: '' classVariableNames: '' poolDictionaries: '' category: 'OB-Standard-Browsers' Then you make accessors for 'a' in AC Now execute: AB superclass: AC And then you do "AB new a" which gives you back random data. Cheers, Niko

Oct. 28, 2009