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

Re: [Pharo-project] SmallLint applied on Pharo: Continued

by StÃ©phane Ducasse

We want that everybody runs smallLint on their code :) I downloaded your code and I will have a look. I should published my changes but I want to fix first the PharoTaskForces repo problem. We are going there and it will be a massive attack :) http://www.youtube.com/watch?v=u7K72X4eo_s&list=AL94UKMTqg-9Aoc-c5isxIXHiEW… cool music Stef On Jan 23, 2013, at 11:48 AM, Hernan Wilkinson wrote: > Hi Stef, > it is great to see that you are using SmallLint to check for errors in Pharo. I the development process we had in a project I participated, we had a step where you had to run SmallLint and you could not commit code with smallLint errors and for some packages with possible errors. > Becuase SmallLint generates a quite a lot false positives, we developed at that time (it was around 2004) something we called "ExpectedSmallLintErrors" that we use to document those false positives and therefore be able to commit the changes (the documentation was smalltalk code of course that included a reason and an author). The interesting thing about this kind of doc. was that if the false positive went away you had to remove the related "expected error", so it worked both ways. > We solved the problems you mentioned about subclass responsibility and others similars, all with VisualAge > It was really cool and it help us to catch and prevent a lot of errors. We ported it to Pharo (or Squeak at that time) a long time ago, but I cannot find the project on SqueakSource... I remember that Lukas had implemented something similar using pragmas but it lacked some features that we supported that I don't remember now :-) > > Anyway, I'm really happy to see that the Pharo team is using SmallLint and I think you should put it as a step in the development process, and I also recommend to you to have some "interesting" way of documenting false positive because if not you will end up not using it... at least that was my experience. > > Bye, > Hernan. > > > On Tue, Jan 22, 2013 at 8:59 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > Well. I've written the tag support, so let's make it simple, MIT. > > I may export a changeset with that code for you, if you like. > > Else I will just go over them and it will help me to understand. I think that this is not difficult. > > > For rules written by CG I'm not sure. You should check with him. > > But I think it won't be a problem given that you preserve all > > the signatures and #documentation and #version_XXX methods > > (we use them to track changes in the source). > > > > However, what I planned (and run out of time :-) is to make > > tag a first class object with name (symbol) description etc > > and have class methods to create them. Then one may define and > > describe meaning of the tag in an extension method. > > Also, the selection/rejection logic could dispatch back on > > the tag instance so you may then create fancy dynamic tags > > (like #portability that automatically includes everything tagged > > as #pharo #squeak #stx #va, for instance or whatever. > > > > I might hack it later this week, if you would include it into > > your version (otherwise I've more important things to do :-) > > I imagine well. > Let us keep it simple. Simple tags with a little class comments are good enough :) > > > > > Cheers > > > > On 22/01/13 19:32, StÃ©phane Ducasse wrote: > >> Jan > >> what is the license of your tags and other code? > >> > >> Stef > >> > >> On Jan 22, 2013, at 3:45 PM, Jan Vrany wrote: > >> > >>> On 22/01/13 18:22, StÃ©phane Ducasse wrote: > >>>> Hi > >>>> > >>>> I'm running the rule RBSubclassResponsibilityNotDefinedRule that > >>>> > >>>> Checks that all subclassResponsibility methods are defined in all leaf classes. > >>>> > >>>> Now the results display the sender of ^ subclassResponsibility but I have to manually find the > >>>> problems. I would be better to report the violations. Of course this is not that simple: returning a class and missing method. > >>>> > >>>> But this would be much better. Jan did you do that in your version? > >>> > >>> Good point. Yes, since now we do that :-) > >>> > >>> Jan > >>> > >>>> > >>>> Stef > >>>> > >>> > >>> > >> > >> > >> > > > > > > > > > > -- > HernÃ¡n Wilkinson > Agile Software Development, Teaching & Coaching > Phone: +54 - 011 - 6091 - 3125 > Mobile: +54 - 911 - 4470 - 7207 > email: hernan.wilkinson(a)10Pines.com > site: http://www.10Pines.com > Address: Alem 693, Floor 5 B, Buenos Aires, Argentina

Jan. 23, 2013

Re: [Pharo-project] about Loom profiler

by StÃ©phane Ducasse

On Jan 23, 2013, at 10:54 AM, Alexandre Bergel wrote: > Hi! > > Sorry for the late reply. > >> how Loom compares with the fixes that andreas added to the default profiler. > > I am not sure about Andreas' fixes. this is why it would be nice that you know because you should be the profiler expert :) > Loom tells you for each thread running in the VM the amount of CPU it consumes. > Some screenshots should be self explaining: > http://objectprofile.com/loom-screenshots.html > >> I do not know if the code is in squeak because this code was licensed under GPL. > > Loom is MIT. > >> But I would like to know if your profiler takes into account the problems solved by andreas. > > Any ref about this? look into the list it was mentioned. > >> I did not see an announce of Loom (by the way Loom is the name of large oo memory developed by the original smalltalk team >> a while ago). >> >> http://objectprofile.com/loom-download.html >> >> I'm know that some people got problem with our profiler and I would like to see how we >> can improve it. > > We haven't announced Loom because the Pharo version is not yet ready. Although usable, it has a very poor graphical user interface. > The first goal is to have Loom replace the standard process browser. > > Cheers, > Alexandre > > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > >

Jan. 23, 2013

Re: [Pharo-project] DocTest

by StÃ©phane Ducasse

Doru I will try to have a look later today but busyâ¦. Stef On Jan 23, 2013, at 8:38 AM, Tudor Girba wrote: > We are releasing Moose as soon as we figure out how to load RPackage from PharoTaskForces squeak source repository (see my previous mail), and afterwards we move to 2.0. > > Cheers, > Doru > > > > On Wednesday, January 23, 2013, Sven Van Caekenberghe wrote: > > On 23 Jan 2013, at 11:34, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > > FYI, we are already using Phexample in Moose since several years, and it just works out of the box next to Sunit. > > That is good to know. > Moose is a really important project for Pharo. > It feels good to know that such a big code base is pushing forward like that. > > BTW, is work already being done bring Moose to Pharo 2.0 ? > > > Doru > > > > On Wednesday, January 23, 2013, Sven Van Caekenberghe wrote: > > Yes we #should ;-) > > > > It is beautiful. > > > > On 23 Jan 2013, at 11:04, Camillo Bruni <camillobruni(a)gmail.com> wrote: > > > > > check the project page for all examples and explanations: > > > > > > http://smalltalkthoughts.blogspot.ch/2009/11/phexample-because-examples-exp… > > > http://www.iam.unibe.ch/~akuhn/blog/2009/shoulda-use-this-in-pharo > > > > > > to me this feels more like Smalltalk and less like Java ;) > > > > > > On 2013-01-23, at 08:47, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > > >> Who should assert then? > > >> From a certain POV, it does not seem that awfully unlogical to > > >> delegate this responsability to a TestCase. > > >> A TestCase is here to assert some rule. > > >> > > >> Nicolas > > >> > > >> 2013/1/23 Camillo Bruni <camillobruni(a)gmail.com>: > > >>> for that we already have a fully working Phexample: > > >>> > > >>> http://www.squeaksource.com/phexample.html > > >>> > > >>> which I will push in 3.0, cause I never really liked #assert: and friends being > > >>> sent to self. Furthermore we could finally build up decent messages! > > >>> > > >>> On 2013-01-22, at 18:24, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > >>> > > >>>> it would be nice to introduce the same syntax than Sunit > > >>>> > > >>>> exp assert: exp2 > > >>>> > > >>>> [ exp ] shouldraise: > > >>>> > > >>>> Stef > > >>>> > > >>>> > > >>>> On Jan 21, 2013, at 4:41 AM, Benjamin wrote: > > >>>> > > >>>>> Hi guys, > > >>>>> > > >>>>> I am attending a python lecture and discovered DocTest[1], and I was wondering if such a tool exists for Pharo ? :) > > >>>>> > > >>>>> > > >>>>> Ben > > >>>>> > > >>>>> [1]http://docs.python.org/2/library/doctest.html > > >>>>> > > >>>>> > > >>>> > > >>>> > > >>> > > >>> > > >> > > > > > > > > > > > > > > > > -- > > www.tudorgirba.com > > > > "Every thing has its own flow" > > > > > > > -- > www.tudorgirba.com > > "Every thing has its own flow" >

Jan. 23, 2013

Re: [Pharo-project] [ANN] Headless support for Cog Cocoa VM

by StÃ©phane Ducasse

> You don't know the power of the dark sideâ¦ No Lukriano I'm not your father

Jan. 23, 2013

Re: [Pharo-project] NativeBoost and unions

by StÃ©phane Ducasse

> I would recommend sthub, quick howto for moving: sthub! Let us deprecate SS for now and after we think about git. We cannot break too many eggs at the same time. > http://goran.krampe.se/2013/01/07/moving-to-smalltalkhub > > regards, GÃ¶ran

Jan. 23, 2013

Re: [Pharo-project] about the VM and Pharo

by Igor Stasenko

On 23 January 2013 20:34, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > On Wed, Jan 23, 2013 at 9:01 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: >> >> On 23 January 2013 17:27, Sean P. DeNigris <sean(a)clipperadams.com> wrote: >> > EstebanLM wrote >> >> Pharo 2.0 will be released with a stable, branded vm with a bunch of >> >> useful plugins and libraries (like freetype) and out-of-the-box support >> >> for NativeBoost. >> >> ... >> >> For Pharo 3.0 we are even more ambitious: we want to start replacing >> >> some >> >> important parts of the vm with plugins (like extract a "DisplayPlugin", >> >> so >> >> we can control from image side the initialization of a morphic world or >> >> something extra. And we want to replace BitBlt plugin with Athens, so >> >> that >> >> will keep us busy enough time. >> > >> > Wow, very exciting! Thank everyone for the hard work :) >> > >> > >> > EstebanLM wrote >> >> - ephemerons support. >> > >> > Is this currently available? If so, does that mean that weak >> > announcements >> > taking a block are now working properly? >> > >> no it is not integrated yet. >> After discussing with Eliot, he recommended to use last object format >> to denote ephemerons. >> Existing implementation is a bit hackish way to determine if object is >> ephemeron. >> So, before we do such change, assume they are not working yet. > > > Yes, please. This is the only thing that has kept me from integrating the > ephemeron work. We can use instSpec/format #5. The instSpec/formats are > 0: zero-fixed-sized pointers (e.g. UndefinedObject) > 1: non-zero-fixed-sized pointers (e.g. Point (x,y)) > 2: zero-fixed-size variable pointers (e.g. Array) > 3. non-zero-fixed-sized variable pointers (e.g. AdditionalMethodState > (method,selector)) > 4. arbitrary-fixed-sized variable weak pointers (e.g. WeakFinalizerItem > (list,next,executor) > 5. unused > 6. variable 32-bit non-pointers (e.g. Float) > 7. unused (but should be odd bit for length of format 6 objects in 64-bit > system) > 8. variable 8-bit non-pointers (e.g. ByteArray, String) > 9,10,11 odd bits for length of format 8 objects > 12 hybrid variable pointers, variable bytes (CompiledMethod and subclasses) > 13,14,15 odd bits for length of format 12 objects > > So 5 is the obvious one. format <= 5 are pointers, format <= 5 or >= 12 > contain pointers. 7's a really bad choice. Good. > > And I won't bore you with the extension to 64-bits and a 5 bit field. :) As a tangent.. i looking for a ways to have simpler model where we have only 2 object formats: - objects which fields are pointers - objects which contain no pointers because this is the only thing that matters for VM/GC most of the time. For other contracts, like how to treat pointers (whether they weak or ephemeron or any other kind), we could use a 'marker' object, i.e. a special object stored in first slot of questioned object. So, for example, if a first slot has reference to 'WeakKind' special object, then rest references is held weakly. By analogy, putting 'EphemeronKind' will automatically mark object as ephemeron. So, instead of using bits in header, we using extra slot. The advantage is that we're no longer constrained by the number of bits reserved for object format, and future VM can introduce any other kind, if needed, without need to touch rest. dreams, dreams.. :) -- Best regards, Igor Stasenko.

Jan. 23, 2013

Re: [Pharo-project] TxTextMorph based on new text model

by StÃ©phane Ducasse

On Jan 23, 2013, at 1:34 PM, Sean P. DeNigris wrote: > Thanks for tackling this urgent and complicated topic! + 1000 Stef

Jan. 23, 2013

Re: [Pharo-project] about the VM and Pharo

by StÃ©phane Ducasse

esteban ***THANKS*** for this mail. Could you consolidate a version (including igor feedback) and post it as a blog post on the pharo web site? This is for this kind of work that we need a stronger consortium. Stef On Jan 23, 2013, at 12:40 PM, Esteban Lorenzano wrote: > Hi, > > Maybe this was talked before, and everybody knows what I'm going to say, but I want to talk about one of the issues we are tackling for 2.0 release: The VM and its Plugins. > > Of course you all know that at least for now (and the next couple of years, he), we use Eliot's Cog for running Pharo. > But probably some of you don't know that we actually make some changes to the VM in order to make it suitable for Pharo. This changes are sometimes incorporated to the regular VM, but some others not. So, part of our work is to keep the sources in sync with Eliot's trunk and introduce our "things" in it. > What are those things? Well, a small list: > > - the adaptation of interpreter to run NativeBoost > - external semaphores enhancement to grow easily over 250. > - ephemerons support. > > in the plugins area, this year we improved some of the existing ones: > - FilePlugin, now can retrieve file permissions and knows if file is a symlink > - SerialPlugin, now works in Macs (it was never implemented) > > in addition, we are supporting the Cocoa VM for Mac (the Cocoa framework for Mac is the Objective-C replacement for Carbon, the old and legacy UI framework), and thanks to Mariano and Square[i] now we have headless support for macs (we are just missing complete headless support for windows, now). > > So, for Pharo 2.0 now we are working on this twi issues: > > - Stability! We need a stable VM, and as I already said it, we still have some problems there. > - Improve the build process, to make it easier. > - Branding. We need a VM that says "Pharo" and not "Cog" or "Squeak"... why? just because we make Pharo :) also, if we improve this process, then ppl doing desktop applications can reproduce it with their own branding (I suppose if you do a Mac or Windows app, you want your icon in the dock bar, not a pharo, or a cog, or a mouse... and in mac is trivial to adapt, but in windows is complicated :) > > Pharo 2.0 will be released with a stable, branded vm with a bunch of useful plugins and libraries (like freetype) and out-of-the-box support for NativeBoost. > > For Pharo 3.0 we are even more ambitious: we want to start replacing some important parts of the vm with plugins (like extract a "DisplayPlugin", so we can control from image side the initialization of a morphic world or something extra. And we want to replace BitBlt plugin with Athens, so that will keep us busy enough time. > > Cheers, > Esteban

Jan. 23, 2013

Re: [Pharo-project] TxTextMorph based on new text model

by DeNigris Sean

> I don't. Do you have link? Here is the paper: http://www.vpri.org/pdf/m2010002_lobjects.pdf And you can download the image with the actual active essay from http://tinlizzie.org/lesserphic2/Text%20Field%20for%20LObject.zip

Jan. 23, 2013

Re: [Pharo-project] about the VM and Pharo

by Eliot Miranda

On Wed, Jan 23, 2013 at 9:01 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 23 January 2013 17:27, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > EstebanLM wrote > >> Pharo 2.0 will be released with a stable, branded vm with a bunch of > >> useful plugins and libraries (like freetype) and out-of-the-box support > >> for NativeBoost. > >> ... > >> For Pharo 3.0 we are even more ambitious: we want to start replacing > some > >> important parts of the vm with plugins (like extract a "DisplayPlugin", > so > >> we can control from image side the initialization of a morphic world or > >> something extra. And we want to replace BitBlt plugin with Athens, so > that > >> will keep us busy enough time. > > > > Wow, very exciting! Thank everyone for the hard work :) > > > > > > EstebanLM wrote > >> - ephemerons support. > > > > Is this currently available? If so, does that mean that weak > announcements > > taking a block are now working properly? > > > no it is not integrated yet. > After discussing with Eliot, he recommended to use last object format > to denote ephemerons. > Existing implementation is a bit hackish way to determine if object is > ephemeron. > So, before we do such change, assume they are not working yet. > Yes, please. This is the only thing that has kept me from integrating the ephemeron work. We can use instSpec/format #5. The instSpec/formats are 0: zero-fixed-sized pointers (e.g. UndefinedObject) 1: non-zero-fixed-sized pointers (e.g. Point (x,y)) 2: zero-fixed-size variable pointers (e.g. Array) 3. non-zero-fixed-sized variable pointers (e.g. AdditionalMethodState (method,selector)) 4. arbitrary-fixed-sized variable weak pointers (e.g. WeakFinalizerItem (list,next,executor) 5. unused 6. variable 32-bit non-pointers (e.g. Float) 7. unused (but should be odd bit for length of format 6 objects in 64-bit system) 8. variable 8-bit non-pointers (e.g. ByteArray, String) 9,10,11 odd bits for length of format 8 objects 12 hybrid variable pointers, variable bytes (CompiledMethod and subclasses) 13,14,15 odd bits for length of format 12 objects So 5 is the obvious one. format <= 5 are pointers, format <= 5 or >= 12 contain pointers. 7's a really bad choice. And I won't bore you with the extension to 64-bits and a 5 bit field. > > > Also, is the Pharo branded VM on the static file server based on Jit Cog > (as > > opposed to stack, etc)? > > > which server? > > > Cheers, > > Sean > > -- > > View this message in context: > http://forum.world.st/about-the-VM-and-Pharo-tp4664887p4664902.html > > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > > > > > -- > Best regards, > Igor Stasenko. > > -- best, Eliot

Jan. 23, 2013