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

Re: [Pharo-project] Very tiny fonts

by StÃ©phane Ducasse

juan do you have some code that we could study to turn this micro police into font in our smalltalk :) Stef On Dec 2, 2009, at 6:06 PM, Marcus Denker wrote: > Hi, > > While discussing Visualisations, we realized we want *really* tiny fonts... > > Here is a hand-drawn sub-pixel font that is just 5 pixels high... > > http://typophile.com/node/61920 > > > Now we need to make a font for Pharo... > > Marcus > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Dec. 3, 2009

Re: [Pharo-project] How to report a bug ? [WAS] lukas-renggli.ch down, mirrors exists ?

by StÃ©phane Ducasse

yes we could put this picture on the web page On Dec 2, 2009, at 11:39 PM, Mariano Martinez Peck wrote: > And I forgot to said that maybe it is a good idea also to put a link to the "Process". > > Slide number 54 of http://www.slideshare.net/MarcusDenker/talk-pharo-at-jm2l-2009 > > On Wed, Dec 2, 2009 at 7:18 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > you are probably right. > Mike R., adrian what do you think? > Mike could you do an editing pass? > > Stef > > > On Dec 2, 2009, at 6:43 PM, Mariano Martinez Peck wrote: > > > I think it is really a good idea to create a page in the Pharo website about how to report a bug. I think that only the link to the google page is not enough. Maybe it is a good idea to explain it a bit more, and in addition, give some tips. I would write something like the text above in that page. I would replace everywhere where it is a link to http://code.google.com/p/pharo/issues/list to this new page. I saw there are these > > > > http://www.pharo-project.org/home (on the right) > > http://www.pharo-project.org/documentation/faq (in the question "Where do I report Pharo bugs?") > > > > My English is not the best at all, so any feedback is more than welcome. In addition, maybe you don't agree with me. > > > > My main purpose is to help newcomers to submit issues. > > > > So....here it is > > > > > > " > > An issue, also known as ticket, represents many things. It can be a bug, a enchantment, packages, projects or commits to check, etc. > > For the Pharo project, we use the Google Code issue tracker which is in http://code.google.com/p/pharo/issues/list. > > > > - Before submitting you may take into account the following tips: > > > > 1) Search in the existent issue list if there is something similar. In the issue tracker you will find a "search" button to do that. Be aware that there is a list of options and the default one is "Open ticket". It is very common you need to search in "All issues". > > > > 2) If the ticket is a bug, and there is a problem with certain method, search for that method or even for that class. It is very common to have "MessageNotUnderstood". So, in this case you can search for that method. For example, if you evaluate: > > > > TestCase nonExistentMethod: something other: another > > > > You will get "MessageNotUnderstood: TestCase class>>nonExistentMethod:other:" > > > > So, here you can search for "nonExistentMethod:other:" for exampe. > > > > 3) Do the same of 1) and 2) but on the mailing list. If you are new or even if you are not subscribed, you can see and search in the mailing list here: > > http://n2.nabble.com/Pharo-Smalltalk-f2305563.html > > > > Sometimes some tickets are reported only in mailing list (that's too bad!!!). And maybe, that happened before you get subscribed in the mailing list. This way you are sure you are searching also in the mailing list. > > > > > > - When you are submitting an issue there are also some tips you should take into account: > > > > 1) If the issue is related to ClassBrowser, refactor or similar, please tell us which browser are you using. If you don't know it, just evaluate and see the results of "SystemBrowser default". > > > > 2) ALWAYS say which version of VM, image (not only if it is a core or pharo image but also exactly the version) and OS are you using. > > > > 3) If the bug is reproducible, please explain how to do it step by step. If we have to use a particular VM, OS, or image, say it. > > > > 4) If the bug brings a debugger popup, it would be very useful if you could put in the issue entry the full stacktrace. To get this stacktrace, there are 2 ways: > > > > 4.a) Search for the generated PharoDebug.log which is in the same directory where if image is and attached in the issue. In that file there is not only the full stacktrace but also some information about the version of the VM, OS and image you were using at that moment, etc. > > > > 4.b) In the debugger, open the contextual menu and there is an item 'mail out bug report' to directly send the stack trace with VM version etc to the pharo list (or whoever you want to, but by default it's the Pharo ml). Of course you can edit the message to describe your problem for example. > > > > 5) If you are not a newcomer and you know a bit you can put labels to the issue. For example if it should be Milestone 1.0 or Type-Closure, or TypeOB, etc. > > > > 6) If you are not a newcomer and you know a bit you can copy people with the "Cc:" option. This is very useful when you know that the issue is in a certain package for example and you know who is responsible or maintainer of it. > > > > 7) After submitting the issue, you must send and email to the mailing list with the link. What you can do also is to copy and paste the details of the issue in the body of the email. With this, all the people know about it. > > > > 8) If the ticket is a MNU it would be very useful to put that message (in our example "MessageNotUnderstood: TestCase class>>nonExistentMethod:other:") in the description of the ticket or even in the title of the issue and the subject of the email. With this we can take advantage of the Google search engine. > > > > 9) If you have a fix remember you must sign the MIT license first. For more information read http://www.pharo-project.org/license > > > > " > > > > On 2 dÃ©c. 2009, at 08:05, Mariano Martinez Peck wrote: > > > >> > >> > >> 2009/12/2 laurent laffont <laurent.laffont(a)gmail.com> > >> Hello, > >> > >> I want to check if there's updates to Slime package as I faces several bugs but sources.lukas-renggli.ch seems to be down. Is there a mirror ? > >> > >> > >> About the bugs (Slime-lr.24,current pharo rc1 web image), when I select refactor > code critics: > >> > >> - it seems that ParserTreeSearcher has been renamed to RBParserTreeSearcher. Thus there's several errors like WAChangesStateWhileRenderingRule>>initialize (ParseTreeSearcher is Undeclared) > >> > >> - this done, I have the error: AnObsoleteParseTreeSearcher(Object)>>doesNotUnderstand: #executeTree:initialAnswer: (from RBAssignmentIfTrueRule>>checkMethod:) > >> > >> > >> How do I save a stack trace to a text file (or clipboard) from the debugger ? > >> > >> Look for the file called PharoDebug.log which is in the directory where the image is. It will have not only the stacktrace but also much more information, as VM version, OS, etc. > > > > > > or.... > > > > In the debugger, open the contextual menu and there is an item 'mail out bug report' to directly send the stack trace with VM version etc to the pharo list (or whoever you want to, but by default it's the Pharo ml). Of course you can edit the message to make it shorter (we dont need the full stack in general) and describe your problem etc. > > > > > >> > >> Best, > >> > >> Mariano > >> > >> > >> > >> Regards, > >> > >> Laurent Laffont > >> > >> _______________________________________________ > >> Pharo-project mailing list > >> Pharo-project(a)lists.gforge.inria.fr > >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >> > >> _______________________________________________ > >> Pharo-project mailing list > >> Pharo-project(a)lists.gforge.inria.fr > >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > -- > > Simon > > > > > > > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Dec. 3, 2009

Re: [Pharo-project] Very tiny fonts

by Tudor Girba

Indeed, that would be great to have. Doru On 2 Dec 2009, at 22:39, StÃ©phane Ducasse wrote: > visualizations. > We would love to have such a tiny font. If I would know how to do > that I would already have done it. > > Stef > > On Dec 2, 2009, at 10:19 PM, Adrian Lienhard wrote: > >> What is the point of a font so small that I can hardly read it? >> >> Or is it just me and I need new glasses? >> >> Adrian >> >> On Dec 2, 2009, at 18:09 , Marcus Denker wrote: >> >>> >>> On Dec 2, 2009, at 6:06 PM, Marcus Denker wrote: >>> >>>> Hi, >>>> >>>> While discussing Visualisations, we realized we want *really* tiny >>>> fonts... >>>> >>>> Here is a hand-drawn sub-pixel font that is just 5 pixels high... >>>> >>>> http://typophile.com/node/61920 >>>> >>>> >>>> Now we need to make a font for Pharo... >>> >>> we should check in addition how good/bad freetype or the mac >>> renderes tinty fonts from >>> the standard truetype fonts. >>> >>> Marcus >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- www.tudorgirba.com "Yesterday is a fact. Tomorrow is a possibility. Today is a challenge."

Dec. 3, 2009

[Pharo-project] 64bit VMs some thoughts.

by John M McIntosh

So you sit there smug about the fact you built a 64bit VM, likely for hosting on your 64bit Linux OS. {Or the unix one for Darwin, or that new fangled cocoa one} However it's possible that it's running 1/3 the performance of the 32bit VM. Did you check? Thought not... So let's talk. Are you using the gnuifed version of interp.c? If you don't know, well go check. Are you using GCC 4.1 or higher? The interpreter loop is highly tuned monster that suffers from compiler optimization issues. With careful tuning parms as found in the macintosh xcode build project for the carbon VM using gcc 4.0 you'll get the most optimum performance. GCC 4.2+ ? Michael Rueger and I spent a few days attempting to get good performance out of GCC 4.2 WITHOUT success. I think that can account for at least a 33% slowdown. So where does the other 33% slowdown come from? Well when we compile the VM in 64bit to use a 32bit image each reference to an oops requires us to add a 64bit memory start address to the 32bit oops number to resolve to a 64bit memory address. Unfortunately GCC 4.2 growls, and produces the lousiest code possible to do this. Maybe higher versions of GCC are better? Anyone care to test? So some solutions. (a) Ensure the squeak oops memory block loads within the 0-4GB address space. See pagezero size for Darwin. Then alter the logic a bit so that sqMemoryBase is zero and that the squeak memory accessors don't do the add of sqMemoryBase=0 to the oops address. Although you might have to use GCC 4.2 you'll run 100% faster. (b) Use the (non-free) Intel compiler -- =========================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================

Dec. 3, 2009

[Pharo-project] On issue Issue 1155: "Renaming of a class do not changes title of a System Browser"

by csrabak＠bol.com.br

Pertaining the bug #1155 http://code.google.com/p/pharo/issues/detail?id=1155, it seems to me that we need to register the change for the class name so the SystemWindow gets updated: O2PackageBrowser class>>registerForNotifications Smalltalk at: #SystemChangeNotifier ifPresent: [:cls | (cls uniqueInstance) noMoreNotificationsFor: self; notify: self ofSystemChangesOfItem: #class change: #Added using: #classModified:; notify: self ofSystemChangesOfItem: #class change: #Modified using: #classModified:; notify: self ofSystemChangesOfItem: #class change: #Renamed using: #classModified:; notify: self ofSystemChangesOfItem: #class change: #Commented using: #classModified:; notify: self ofSystemChangesOfItem: #class change: #Recategorized using: #classMoved:; notify: self ofSystemChangesOfItem: #class change: #Removed using: #classModified:; notify: self ofSystemChangesOfItem: #method change: #Added using: #methodModified:; notify: self ofSystemChangesOfItem: #method change: #Modified using: #methodModified:; notify: self ofSystemChangesOfItem: #method change: #Recategorized using: #methodModified:; notify: self ofSystemChangesOfItem: #method change: #Removed using: #methodModified: ]. However I could not find how to assemble a #notify:chnage:using: message in order to have the model (O2PackageBrowser) notified. . . If some more knowledgeable on this hierarchy can enlighten me I think we can solve this easily, no? -- Cesar Rabak

Dec. 3, 2009

[Pharo-project] macintosh cocoa 32/64bit & 64/64bit VM goes BETA

by John M McIntosh

Ok, it's time for the community to do some testing. ESUG provided me with some funding to take the existing iPhone VM source and extend that to build a new hosting platform using Cocoa on the macintosh and to enable the VM to run in 32 or 64 bit mode and work with a 32 or 64bit image. I have placed two Alpha test VM s in the experimental folder sub-folder COCOA found in the usual places via http://smalltalkconsulting.com/squeak.html There are two VM's (a) a 32/64 bit VM that runs 32bit squeak images in 32bit (powerpc, intel) or 64bit (intel) mode. (b) a 64/64 bit VM that runs 64bit squeak images in 64bit (intel). The VM currently runs on 10.5.x and 10.6.x Support for 10.4.x might happen, we will see. Until I sort out the re-integration of the source code into the squeakvm.org SVN tree you will find the source at isqueak.org Issues, Oh lots. It's a fairly high mountain of material that needs to be tested. Things that should work. (a) access to files and directories UTF8 support only. (b) Full screen support (c) Sockets (d) Basic Sound (better than in the 3.x/4.x VMs) (e) jpegplugin2 (f) cut/copy/paste of text data (from/to) squeak and respect UTF8 chars (g) drag and drop of files into squeak Right now it does not: (a) Support a internet browser as a browser plugin. (b) The 64bit VM has no plugins at the moment. (b2) I've not included any plugins with the 32/64bit VM. Existing plugins might work if the VM is running as "Open in 32bit mode" someone can confirm that. (c) No macintosh host menus, or serial port support (d) No Areithfa Ffenestri multiple-window support (e) No 1, 2, 4, 8, 16 bit appearance support. Things I know about. (a) double clicking *.images when the 5.x VM is running sometimes does not open a new VM. (b) tossing a 32 image at the 64/64 bit VM or a 64 image at the 32/64 VM doesn't give visual feedback that it won't open the image. (c) Full screen grabs all the screens, yes that will change Thoughts on internal plugins. Hint we should have TEST cases so we can confirm if all this stuff works. It would be extremely helpful if someone wanted to work on that. No doubt someone *could* run all the current tests for a 32bit image and see what breaks. However you'll need to explain where and what, versus Oh it just crashed... ADPCMCodecPlugin, untested. Squeak3D, Likely busted due to use of (int) data types in 64bit mode. B2DPlugin, untested. BitBltPlugin, untested. BMPReadWriterPlugin, untested. ZipPlugin, untested. DSAPrims, untested. SqueakFFIPrims, untested. FFTPlugin, untested. FloatArrayPlugin, untested. GeniePlugin, untested. HostWindowPlugin, No support yet JPEGReaderPlugin, untested. Klatt, untested. LargeIntegers, untested. Matrix2x3Plugin, untested. MiscPrimitivePlugin, untested. ObjectiveCPlugin, untested. RePlugin, Likely busted due to use of (int) data types in 64bit mode. SecurityPlugin, untested. SoundCodecPrims, Likely busted due to use of (int) data types in 64bit mode. SoundGenerationPlugin, Likely busted due to use of (int) data types in 64bit mode. StarSqueakPlugin, untested. SurfacePlugin, untested. UUIDPlugin untested. Possibly Large Integers may have a problem in 64bit image mode, but we have to have some discussion if the (unsigned int *) used by one routine is on purpose or an oversight. 64 bit images. We need to built a 64bit Closure image. **** I've no time to do that. *** David T Lewis provided a somewhat current Squeak.image which you'll find on the ftp site. If you build a 64bit image you need to do that on a PowerPC, or make a copy of your VM on macIntel and flip the "Open in 32-bit mode" and the "Open in Rosetta" to on. You will only see the "Open in 32bit mode" if it's a 64bit VM, and the "Open in Rosetta on os-x for 10.5 or 10.6 (if you installed it) Follow the obvious instructions. No doubt some is required to take the code and build a MC change set for Pharo or Squeak Thrunk use so that anyone can convert an existing image. Also see http://bugs.squeak.org/view.php?id=5239 http://bugs.squeak.org/view.php?id=5240 Building your own VM? Hopefully someone will attempt this so I can see if I checked in all the changes. 32bit image VM pick SqueakPureObjc and set #define SQ_VI_BYTES_PER_WORD 4 for a 64bit image reading VM pick SqueakPureObjc64*64 and set #define SQ_VI_BYTES_PER_WORD 8 in the required places. PS You'll find that building a 32/64 VM using GNU's tool chain will give you lousy performance when running as a 64bit VM, more on this later. ---------------------------------------------- Oh and lastly I'm looking for some paid work (smalltalk or objective-c (mac/iPhone) If anyone requires a Smalltalk consultant, or an iPhone app built, please email me. -- =========================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================

Dec. 2, 2009

Re: [Pharo-project] How to report a bug ? [WAS] lukas-renggli.ch down, mirrors exists ?

by Mariano Martinez Peck

And I forgot to said that maybe it is a good idea also to put a link to the "Process". Slide number 54 of http://www.slideshare.net/MarcusDenker/talk-pharo-at-jm2l-2009 On Wed, Dec 2, 2009 at 7:18 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>wrote: > you are probably right. > Mike R., adrian what do you think? > Mike could you do an editing pass? > > Stef > > > On Dec 2, 2009, at 6:43 PM, Mariano Martinez Peck wrote: > > > I think it is really a good idea to create a page in the Pharo website > about how to report a bug. I think that only the link to the google page is > not enough. Maybe it is a good idea to explain it a bit more, and in > addition, give some tips. I would write something like the text above in > that page. I would replace everywhere where it is a link to > http://code.google.com/p/pharo/issues/list to this new page. I saw there > are these > > > > http://www.pharo-project.org/home (on the right) > > http://www.pharo-project.org/documentation/faq (in the question "Where > do I report Pharo bugs?") > > > > My English is not the best at all, so any feedback is more than welcome. > In addition, maybe you don't agree with me. > > > > My main purpose is to help newcomers to submit issues. > > > > So....here it is > > > > > > " > > An issue, also known as ticket, represents many things. It can be a bug, > a enchantment, packages, projects or commits to check, etc. > > For the Pharo project, we use the Google Code issue tracker which is in > http://code.google.com/p/pharo/issues/list. > > > > - Before submitting you may take into account the following tips: > > > > 1) Search in the existent issue list if there is something similar. In > the issue tracker you will find a "search" button to do that. Be aware that > there is a list of options and the default one is "Open ticket". It is very > common you need to search in "All issues". > > > > 2) If the ticket is a bug, and there is a problem with certain method, > search for that method or even for that class. It is very common to have > "MessageNotUnderstood". So, in this case you can search for that method. For > example, if you evaluate: > > > > TestCase nonExistentMethod: something other: another > > > > You will get "MessageNotUnderstood: TestCase > class>>nonExistentMethod:other:" > > > > So, here you can search for "nonExistentMethod:other:" for exampe. > > > > 3) Do the same of 1) and 2) but on the mailing list. If you are new or > even if you are not subscribed, you can see and search in the mailing list > here: > > http://n2.nabble.com/Pharo-Smalltalk-f2305563.html > > > > Sometimes some tickets are reported only in mailing list (that's too > bad!!!). And maybe, that happened before you get subscribed in the mailing > list. This way you are sure you are searching also in the mailing list. > > > > > > - When you are submitting an issue there are also some tips you should > take into account: > > > > 1) If the issue is related to ClassBrowser, refactor or similar, please > tell us which browser are you using. If you don't know it, just evaluate and > see the results of "SystemBrowser default". > > > > 2) ALWAYS say which version of VM, image (not only if it is a core or > pharo image but also exactly the version) and OS are you using. > > > > 3) If the bug is reproducible, please explain how to do it step by step. > If we have to use a particular VM, OS, or image, say it. > > > > 4) If the bug brings a debugger popup, it would be very useful if you > could put in the issue entry the full stacktrace. To get this stacktrace, > there are 2 ways: > > > > 4.a) Search for the generated PharoDebug.log which is in the same > directory where if image is and attached in the issue. In that file there is > not only the full stacktrace but also some information about the version of > the VM, OS and image you were using at that moment, etc. > > > > 4.b) In the debugger, open the contextual menu and there is an item 'mail > out bug report' to directly send the stack trace with VM version etc to the > pharo list (or whoever you want to, but by default it's the Pharo ml). Of > course you can edit the message to describe your problem for example. > > > > 5) If you are not a newcomer and you know a bit you can put labels to the > issue. For example if it should be Milestone 1.0 or Type-Closure, or TypeOB, > etc. > > > > 6) If you are not a newcomer and you know a bit you can copy people with > the "Cc:" option. This is very useful when you know that the issue is in a > certain package for example and you know who is responsible or maintainer of > it. > > > > 7) After submitting the issue, you must send and email to the mailing > list with the link. What you can do also is to copy and paste the details of > the issue in the body of the email. With this, all the people know about it. > > > > 8) If the ticket is a MNU it would be very useful to put that message (in > our example "MessageNotUnderstood: TestCase > class>>nonExistentMethod:other:") in the description of the ticket or even > in the title of the issue and the subject of the email. With this we can > take advantage of the Google search engine. > > > > 9) If you have a fix remember you must sign the MIT license first. For > more information read http://www.pharo-project.org/license > > > > " > > > > On 2 dÃ©c. 2009, at 08:05, Mariano Martinez Peck wrote: > > > >> > >> > >> 2009/12/2 laurent laffont <laurent.laffont(a)gmail.com> > >> Hello, > >> > >> I want to check if there's updates to Slime package as I faces several > bugs but sources.lukas-renggli.ch seems to be down. Is there a mirror ? > >> > >> > >> About the bugs (Slime-lr.24,current pharo rc1 web image), when I select > refactor > code critics: > >> > >> - it seems that ParserTreeSearcher has been renamed to > RBParserTreeSearcher. Thus there's several errors like > WAChangesStateWhileRenderingRule>>initialize (ParseTreeSearcher is > Undeclared) > >> > >> - this done, I have the error: > AnObsoleteParseTreeSearcher(Object)>>doesNotUnderstand: > #executeTree:initialAnswer: (from RBAssignmentIfTrueRule>>checkMethod:) > >> > >> > >> How do I save a stack trace to a text file (or clipboard) from the > debugger ? > >> > >> Look for the file called PharoDebug.log which is in the directory where > the image is. It will have not only the stacktrace but also much more > information, as VM version, OS, etc. > > > > > > or.... > > > > In the debugger, open the contextual menu and there is an item 'mail out > bug report' to directly send the stack trace with VM version etc to the > pharo list (or whoever you want to, but by default it's the Pharo ml). Of > course you can edit the message to make it shorter (we dont need the full > stack in general) and describe your problem etc. > > > > > >> > >> Best, > >> > >> Mariano > >> > >> > >> > >> Regards, > >> > >> Laurent Laffont > >> > >> _______________________________________________ > >> Pharo-project mailing list > >> Pharo-project(a)lists.gforge.inria.fr > >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >> > >> _______________________________________________ > >> Pharo-project mailing list > >> Pharo-project(a)lists.gforge.inria.fr > >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > -- > > Simon > > > > > > > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Dec. 2, 2009

Re: [Pharo-project] is this correct ?

by Mariano Martinez Peck

Ok, got it. Thanks for all the explanations! On Wed, Dec 2, 2009 at 12:27 PM, Lukas Renggli <renggli(a)gmail.com> wrote: > #become: swaps the two pointers, so both objects continue to exist. > > Use the asymmetric variant #becomeForward: to get rid of an object. > > And you probably also need a "Smalltalk garbageCollect" to make the > object really disappear. > > Lukas > > > > 2009/12/2 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > > become: changes the pointer pointing to the objects not the object > itself. > > So I'm not sure that instance should be changed. > > > > If I remember correctly what allinstances does is that it use nextObject > to > > iterate over the object spaces. > > > > Stef > > > > On Dec 2, 2009, at 10:21 AM, Mariano Martinez Peck wrote: > > > >> Hi! Look this peace of code: > >> > >> | instance | > >> instance := TestCase new. > >> Transcript show: TestCase allInstances size; cr. > >> instance become: 'aString'. > >> Transcript show: TestCase allInstances size; cr. > >> > >> > >> The size of TestCase instances is always the same. Although I used > become: (and changed to an instance of another class) to one of its > instances. > >> > >> So, my main question is, is this correct ? Or the message allInstances > to TestCase should not take into account the instance I sent the message > become: ? > >> > >> Thanks in advance. > >> > >> Mariano > >> > >> _______________________________________________ > >> Pharo-project mailing list > >> Pharo-project(a)lists.gforge.inria.fr > >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > _______________________________________________ > > 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 > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Dec. 2, 2009

Re: [Pharo-project] Why some packages are rejected from Test Coverage?

by Mariano Martinez Peck

On Wed, Dec 2, 2009 at 10:43 PM, Lukas Renggli <renggli(a)gmail.com> wrote: > The rejection of the Kernel, Collections, System is not about the > size, it is because of the classes they contain. There are many > classes in the system that you can't wrap without possibly harming the > system. Especially tricky are classes that are used by the system at > all times (so the result would be wrong anyway) and the coverage tools > itself (what could result in infinite recursion), such as Process, > Context, OrderedCollection, Array, Object, etc. All in all the > restrictions imposed on those packages are far too broad, but it was > the easiest without testing all classes (which in case of a failure > mostly leads to a crash) and without introducing unnecessary > dependencies. > :( What a pity. I have already coded it :( And there is no way to test coverage only sub categories of a package? Suppose I want to test the category "System-Object Storage" of the package System. Can I do it ? if true, how? Thanks for the explanation. > Lukas > > 2009/12/2 Mariano Martinez Peck <marianopeck(a)gmail.com>: > > Ok, I see that there are some packages that are not able to be selected > to > > run test coverage. I noticed that they were big packages and then I saw > the > > method: > > > > TestRunner >> promptForPackages > > > > where you can see it rejects packages like Kernel, Collections, System, > etc. > > I guess because Test Coverage may take long time in those big > > packages....but I don't know if that's a good reason to disable them. > Maybe > > a popup saying "Are you sure you want to run Test Coverage over this > > package? It will take a lot of time" is better. At least VisualWorks does > > something similar. > > > > What do you think ? > > > > Cheers, > > > > Mariano > > > > _______________________________________________ > > 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 > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Dec. 2, 2009

Re: [Pharo-project] Why some packages are rejected from Test Coverage?

by Lukas Renggli

The rejection of the Kernel, Collections, System is not about the size, it is because of the classes they contain. There are many classes in the system that you can't wrap without possibly harming the system. Especially tricky are classes that are used by the system at all times (so the result would be wrong anyway) and the coverage tools itself (what could result in infinite recursion), such as Process, Context, OrderedCollection, Array, Object, etc. All in all the restrictions imposed on those packages are far too broad, but it was the easiest without testing all classes (which in case of a failure mostly leads to a crash) and without introducing unnecessary dependencies. Lukas 2009/12/2 Mariano Martinez Peck <marianopeck(a)gmail.com>: > Ok, I see that there are some packages that are not able to be selected to > run test coverage. I noticed that they were big packages and then I saw the > method: > > TestRunner >> promptForPackages > > where you can see it rejects packages like Kernel, Collections, System, etc. > I guess because Test Coverage may take long time in those big > packages....but I don't know if that's a good reason to disable them. Maybe > a popup saying "Are you sure you want to run Test Coverage over this > package? It will take a lot of time" is better. At least VisualWorks does > something similar. > > What do you think ? > > Cheers, > > Mariano > > _______________________________________________ > 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

Dec. 2, 2009