- Pharo-dev - lists.pharo.org

[Pharo-project] [BUG] VM crash during debbuging some code by Through button with Transcript>>show: in deepest inner methods

by Denis Kudriashov

Hello Just insert Transcript>>show:'something' at any method begin. Now debug sender of your method by debugger Through button. If no Transcript opened VM will crash!

May 23, 2010

Re: [Pharo-project] ClassTestCase

by StÃ©phane Ducasse

Sounds exciting can you tell us a bit more? On May 23, 2010, at 2:54 AM, Mariano Abel Coca wrote: > If anyone want, can take a look at: > > http://www.squeaksource.com/CodeQualityTests > http://www.squeaksource.com/CodeStandardsTests > > And run the tests before committing the next version of their packages. > > We will try to help to pass the tests as soon as possible. > > Cheers, > > Mariano. > > > On Sat, May 22, 2010 at 8:06 PM, Francisco Ortiz PeÃ±aloza <patchinko(a)gmail.com> wrote: > We're working on it, making small changes and creating code standards > tests and code quality tests. > > It would be great to have a way of tracking the results of these tests > in a distant future and make them mandatory before integrate new > things into the image. > > Francisco > > On Sat, May 22, 2010 at 7:17 PM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: > > What I was thinking mariano is that we could move one class at a time in classTests and make the tests green. > > This way we do not have red tests and still make progress > > Stef > > > > > > On May 22, 2010, at 8:06 PM, Mariano Abel Coca wrote: > > > >> It is a must. We have to got all the tests in green. But actually that isn't tested. > >> > >> I'll make the tests, I'll fix them, and then I'll send the whole changes to merge in the baseline. > >> > >> Cheers, > >> > >> Mariano. > >> > >> > >> On Sat, May 22, 2010 at 2:58 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > >> the key point is that we would like to avoid to have red tests all the time > >> so fixing the as yet unclassified should be done before. > >> > >> > >> BTW Does anybody use > >> BadEqualer > >> HashTester > >> PrototypeTester > >> > >> because so far I do not see anybody user of them. > >> They look like experiment code to me. > >> > >> Stef > >> > >> On May 22, 2010, at 7:31 PM, Mariano Abel Coca wrote: > >> > >> > Hi, I want to make global the checks included in ClassTestCase, and remove it. That is because actually it's only being tested for it's subclasses. And also, it's declaring that a subclass will be a class test instead of just a test, but no one of it's subclasses actually test the class, but the instances, therefore is a TestCase, not a ClassTestCase. See TimespanTest as an example. > >> > > >> > What Im saying is that I'm trying to force a run of a suit of Code Standards and Code Quality tests before sending something to merge to a baseline of a project. > >> > > >> > What do you think? Are you agree with that? > >> > > >> > Cheers, > >> > > >> > 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 > >> > >> _______________________________________________ > >> 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

May 23, 2010

Re: [Pharo-project] ClassTestCase

by StÃ©phane Ducasse

> We're working on it, making small changes and creating code standards > tests and code quality tests. > > It would be great to have a way of tracking the results of these tests > in a distant future and make them mandatory before integrate new > things into the image. Francisco Three points: - I agree on the principle. Normally I read all the code that is integrated - now we should pay attention. I prefer to put code that make progress but is not perfect versus doing nothing and waiting for a better one - then people can comment on the submission made on the tracker but really few do it. So what is the solution let the code rot there? And kill our good energy. So you see nothing is simple. This is clear that having a nice bunch of SmallLint rules should not hurt :) Stef > > Francisco > > On Sat, May 22, 2010 at 7:17 PM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >> What I was thinking mariano is that we could move one class at a time in classTests and make the tests green. >> This way we do not have red tests and still make progress >> Stef >> >> >> On May 22, 2010, at 8:06 PM, Mariano Abel Coca wrote: >> >>> It is a must. We have to got all the tests in green. But actually that isn't tested. >>> >>> I'll make the tests, I'll fix them, and then I'll send the whole changes to merge in the baseline. >>> >>> Cheers, >>> >>> Mariano. >>> >>> >>> On Sat, May 22, 2010 at 2:58 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>> the key point is that we would like to avoid to have red tests all the time >>> so fixing the as yet unclassified should be done before. >>> >>> >>> BTW Does anybody use >>> BadEqualer >>> HashTester >>> PrototypeTester >>> >>> because so far I do not see anybody user of them. >>> They look like experiment code to me. >>> >>> Stef >>> >>> On May 22, 2010, at 7:31 PM, Mariano Abel Coca wrote: >>> >>>> Hi, I want to make global the checks included in ClassTestCase, and remove it. That is because actually it's only being tested for it's subclasses. And also, it's declaring that a subclass will be a class test instead of just a test, but no one of it's subclasses actually test the class, but the instances, therefore is a TestCase, not a ClassTestCase. See TimespanTest as an example. >>>> >>>> What Im saying is that I'm trying to force a run of a suit of Code Standards and Code Quality tests before sending something to merge to a baseline of a project. >>>> >>>> What do you think? Are you agree with that? >>>> >>>> Cheers, >>>> >>>> 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 >>> >>> _______________________________________________ >>> 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

May 23, 2010

Re: [Pharo-project] Cross-fork Metacello configurations

by Nicolas Cellier

Miguel, It sounds like a defensive attitude. What good can emerge from sharing such mood? You don't deliver any technical argumentation, but "I think it's wrong" and "it upsets me". I'm sure you have more rational reasons to dislike squeak usage, that would be interesting to expose. Squeak people are not going to rape your wife nor kill your children. Qu'un sang impur abreuve nos sillons Nicolas 2010/5/22 Miguel Enrique CobÃ¡ Martinez <miguel.coba(a)gmail.com>: > But, but... > > One thing that I really don't understand is this: > > Squeak people hasn't used the current Metacello "use-case". > Squeak people without use it and see if really has problems (nothing > that can't be solved when it appears) > Squeak people proposed a new way to use Metacello, completly different > than the one is being used > Squeak arguments were about some potential problems with having > configurations outside the image > Squeak arguments were abouth the potential advantages of having a > browser that browses locally (but as Mariano said, it must be updated > from net before having the very last package tested to work available in > the browser) instead of going to the network for the list. > > So, this, hey look what I found, they use it this way, but I think that > we should use it that other way, no matter if it is really a problem Â to > use it the way the other people use it really upsets me. > > Heck, Pharo even build the released dev images with Metacello. That is a > "real" world usage and not words. > > > El vie, 21-05-2010 a las 16:17 -0700, Dale Henrichs escribiÃ³: >> I had suggested that they not use the ConfigurationOf prefix for the Squeak configuration package so that cross platform configurations could continue to be used ... I would hope that folks continue to to create cross platform packages ... the onus on copying shouldn't be on the developer, but the folks that want a managed list of configs:) >> >> I would think that the managed list could be harvested from the ConfigurationOf configs without any direct developer involvement...afterall computers should be used for the things they are good at:) >> >> It will be interesting to see how the managed list idea evolves... >> >> Dale >> ________________________________________ >> From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Miguel Enrique CobÃ¡ Martinez [miguel.coba(a)gmail.com] >> Sent: Friday, May 21, 2010 10:42 AM >> To: Pharo-project(a)lists.gforge.inria.fr >> Subject: Re: [Pharo-project] Cross-fork Metacello configurations >> >> El vie, 21-05-2010 a las 09:13 -0700, Sean P. DeNigris escribiÃ³: >> > I created a Squeak/Pharo SSpec, which puts the fork-specific world menu code >> > into a Platform package. >> > >> > As I work on the config, I came up against Pharo using Object as a subclass, >> > but the Squeak Inbox requiring (because of the browser tool) >> > MetacelloConfiguration. >> > >> > What would be the best/easiest way to deal with this? >> > >> > If the configs have to be forked, then Metacello really loses value (i.e. >> > #squeak and #pharo). Â And, I do a lot of work in both forks, so it would be >> > a shame to pick one to upload to and not share work that has already been >> > done with half the users. >> >> That was one of the problems of the Configuration Package proposed by >> Andreas. Promotes copy&paste of configurations (bad bad) and in the long >> term forks and completely rework to create configurations for Squeak and >> a different (although similar) for Pharo. >> As you say, it doesn't matter that Metacello is capable of installing >> cross-platform packages. With independently created configurations for >> the same packages, is has been stole of its usefulness and is >> discouraging Pharo users that have developed ConfigurationOfXXX that >> worked both in Squeak and Pharo in the past. >> >> >> >> > >> > Thanks. >> > Sean >> > >> >> -- >> Miguel CobÃ¡ >> http://miguel.leugim.com.mx >> >> >> _______________________________________________ >> 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 > > -- > Miguel CobÃ¡ > http://miguel.leugim.com.mx > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

May 23, 2010

Re: [Pharo-project] [BUG] block decompilation during code simulation by Through debugger button

by Eliot Miranda

Hi Denis, (Hi Michaels, this may be related yo your issue)... Denis, this is nothing to do with blocks having homes. It's somewhere in the simulation of RemoteString>>text (used in CompiledMethod>>getSourceFromFile), specifically when UTF8TestDecoders egt involved. Try the following and you'll see the -261 doesNotUnderstand: which is the symptom of the broken simulation. Don't know exactly where simulation breaks down (but I suspect primitive invocation). Anyway this may get you started digging deeper. | m | m := ClassWithBlockDecompilation >> #methodWithDecompilation. ContextPart trace: [ m getSourceFromFile ] "fails" | m | m := ClassWithBlockDecompilation >> #methodWithDecompilation. m getSourceFromFile "succeeds" To dig deeper you may want to open up ContextPart class>>trace:on: in a workspace and put in some break-points, e.g. the following halts at the first doesNotUnderstand:. Work your way back from there to find out where the -261 is coming form (I'm using Squeak 4.1, YMMV). | aStream m aBlock prev | (aStream := Transcript) clear. m := ClassWithBlockDecompilation >> #methodWithDecompilation. aBlock := [m getSourceFromFile]. prev := aBlock. ^thisContext sender runSimulated: aBlock contextAtEachStep: [:current | current selector = #doesNotUnderstand: ifTrue: [self halt]. Sensor anyButtonPressed ifTrue: [^ nil]. current == prev ifFalse: [prev sender ifNil: [aStream space; nextPut: $^. ContextPart carefullyPrint: current top on: aStream]. aStream cr. (current depthBelow: aBlock) timesRepeat: [aStream space]. ContextPart carefullyPrint: current receiver on: aStream. aStream space; nextPutAll: current selector; flush. prev := current] HTH Eliot 2010/5/22 Denis Kudriashov <dionisiydk(a)gmail.com> > Block decompilation not work at situation during code simulation. Maybe its > just problem in debugger "Through button" action implementation. > This happen because block home in that situation not exists. > > I attach class ClassWithBlockDecompilation which help reproduce that > manually. See class side method #debug > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

May 23, 2010

Re: [Pharo-project] ClassTestCase

by Mariano Abel Coca

If anyone want, can take a look at: http://www.squeaksource.com/CodeQualityTests http://www.squeaksource.com/CodeStandardsTests And run the tests before committing the next version of their packages. We will try to help to pass the tests as soon as possible. Cheers, Mariano. On Sat, May 22, 2010 at 8:06 PM, Francisco Ortiz PeÃ±aloza < patchinko(a)gmail.com> wrote: > We're working on it, making small changes and creating code standards > tests and code quality tests. > > It would be great to have a way of tracking the results of these tests > in a distant future and make them mandatory before integrate new > things into the image. > > Francisco > > On Sat, May 22, 2010 at 7:17 PM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: > > What I was thinking mariano is that we could move one class at a time in > classTests and make the tests green. > > This way we do not have red tests and still make progress > > Stef > > > > > > On May 22, 2010, at 8:06 PM, Mariano Abel Coca wrote: > > > >> It is a must. We have to got all the tests in green. But actually that > isn't tested. > >> > >> I'll make the tests, I'll fix them, and then I'll send the whole changes > to merge in the baseline. > >> > >> Cheers, > >> > >> Mariano. > >> > >> > >> On Sat, May 22, 2010 at 2:58 PM, StÃ©phane Ducasse < > stephane.ducasse(a)inria.fr> wrote: > >> the key point is that we would like to avoid to have red tests all the > time > >> so fixing the as yet unclassified should be done before. > >> > >> > >> BTW Does anybody use > >> BadEqualer > >> HashTester > >> PrototypeTester > >> > >> because so far I do not see anybody user of them. > >> They look like experiment code to me. > >> > >> Stef > >> > >> On May 22, 2010, at 7:31 PM, Mariano Abel Coca wrote: > >> > >> > Hi, I want to make global the checks included in ClassTestCase, and > remove it. That is because actually it's only being tested for it's > subclasses. And also, it's declaring that a subclass will be a class test > instead of just a test, but no one of it's subclasses actually test the > class, but the instances, therefore is a TestCase, not a ClassTestCase. See > TimespanTest as an example. > >> > > >> > What Im saying is that I'm trying to force a run of a suit of Code > Standards and Code Quality tests before sending something to merge to a > baseline of a project. > >> > > >> > What do you think? Are you agree with that? > >> > > >> > Cheers, > >> > > >> > 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 > >> > >> _______________________________________________ > >> 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 >

May 23, 2010

[Pharo-project] [ESUG 2010] Call for sponsors

by Bouraqadi Noury

Dear Smalltalkers, As you know ESUG is a non-for-the-profit organization, run by a bunch of volunteers which aims at promoting Smalltalk (http://www.esug.org/Promotion ). ESUG does have multiple actions such as sponsoring Smalltalk- related publications (articles and books), and encouraging developers and more specifically young students to learn Smalltalk (Student Volunteers program) and build innovative software using Smalltalk (SummerTalk, ESUG Awards, "Support your project" program). ESUG revenue comes only from sponsoring, donations, and registrations to the ESUG yearly event (since 18 years!). Therefore, I invite you to support the ESUG actions by encouraging your companies and organizations to sponsor ESUG. As previous years, we have three sponsoring packages (http://www.esug.org/supportesug/becomeasponsor/ ): * Silver ESUG Sponsor: By paying 500 Euros, the logo of your organization is displayed for a whole year on the main page of the ESUG web site and also on conference pages. You are entitled to mention that you are an ESUG sponsor, and to use the ESUG logo in that context. * Gold ESUG Sponsor: By paying 1000 Euros, you get all of the above, and the ESUG correspondence and distributions (CD, Documentation) will also feature your logo. You also get a 10% fee reduction on the ESUG events for up to 5 people of your organisation. * Platinum ESUG Sponsor: By Paying 2000 Euros, you get all of the above, and the fee reduction on the ESUG events is increased to 20% for up to 10 people of your organisation. See you in Barcelona, Dr. Noury Bouraqadi ESUG Treasurer http://car.ensm-douai.fr/noury/ -------------- -ESUG 18th International Smalltalk Conference. Barcelona, Spain, 11-17 september 2010 http://www.esug.org/Conferences/2010

May 22, 2010

Re: [Pharo-project] ClassTestCase

by Francisco Ortiz PeÃ±aloza

We're working on it, making small changes and creating code standards tests and code quality tests. It would be great to have a way of tracking the results of these tests in a distant future and make them mandatory before integrate new things into the image. Francisco On Sat, May 22, 2010 at 7:17 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > What I was thinking mariano is that we could move one class at a time in classTests and make the tests green. > This way we do not have red tests and still make progress > Stef > > > On May 22, 2010, at 8:06 PM, Mariano Abel Coca wrote: > >> It is a must. We have to got all the tests in green. But actually that isn't tested. >> >> I'll make the tests, I'll fix them, and then I'll send the whole changes to merge in the baseline. >> >> Cheers, >> >> Mariano. >> >> >> On Sat, May 22, 2010 at 2:58 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> the key point is that we would like to avoid to have red tests all the time >> so fixing the as yet unclassified should be done before. >> >> >> BTW Does anybody use >> Â Â Â Â BadEqualer >> Â Â Â Â HashTester >> Â Â Â Â PrototypeTester >> >> because so far I do not see anybody user of them. >> They look like experiment code to me. >> >> Stef >> >> On May 22, 2010, at 7:31 PM, Mariano Abel Coca wrote: >> >> > Hi, I want to make global the checks included in ClassTestCase, and remove it. That is because actually it's only being tested for it's subclasses. And also, it's declaring that a subclass will be a class test instead of just a test, but no one of it's subclasses actually test the class, but the instances, therefore is a TestCase, not a ClassTestCase. See TimespanTest as an example. >> > >> > What Im saying is that I'm trying to force a run of a suit of Code Standards and Code Quality tests before sending something to merge to a baseline of a project. >> > >> > What do you think? Are you agree with that? >> > >> > Cheers, >> > >> > 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 >> >> _______________________________________________ >> 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 >

May 22, 2010

Re: [Pharo-project] [BUG] block decompilation during code simulation by Through debugger button

by StÃ©phane Ducasse

thanks we should open a bug item Stef On May 23, 2010, at 12:06 AM, Denis Kudriashov wrote: > Block decompilation not work at situation during code simulation. Maybe its just problem in debugger "Through button" action implementation. > This happen because block home in that situation not exists. > > I attach class ClassWithBlockDecompilation which help reproduce that manually. See class side method #debug > <ClassWithBlockDecompilation.st>_______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

May 22, 2010

Re: [Pharo-project] license of the collaborative book

by StÃ©phane Ducasse

Yes this would be a good idea. On May 22, 2010, at 9:48 PM, laurent laffont wrote: > On Saturday, May 22, 2010, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: >> Hi folks. I am not sure how does it work the license in the collaborative book. So far in the footer of the book I saw: "Licensed under Creative Commons BY-NC-SA" >> >> Now...what does it mean? That everybody is agree that whan he writes will be with that license? I wonder..suppose in one year we want to take such book an generate a real pdf/printed book, will be there some problem with that? I want to avoid such problems in the future. >> >> Thanks >> >> Mariano >> > > Authors can sign a license agreement as done with Pharo contributors. > > Laurent > > -- > Laurent Laffont > > http://pharocasts.blogspot.com/ > http://magaloma.blogspot.com/ > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

May 22, 2010