July 2010 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Underscores in 1.1??

by Lukas Renggli

> Is 1.1 able to handle underscores in method *and* class names? Â Is this really behind us now? Yes, all identifiers support underscore characters everywhere. Also temporary and instance variables. And also in the refactoring engine. The only problem I just noticed in the editor is that double clicking on a variable with a underscore does not change the selection correctly. Lukas -- Lukas Renggli www.lukas-renggli.ch

July 25, 2010

Re: [Pharo-project] Invalid utf8 input detected: now what?

by Philippe Marschall

On 23.07.2010 15:15, Schwab,Wilhelm K wrote: > No dialogs, please :) Actually, it would be fine if there were a different stream class or simply a different method/state (encoding =#userInteraction or something??) that is understood to negotiate such details with "the user." In general, exception is the correct way to handle this: the stream "knows" what is wrong; the application will know what to make of it. If the encoding can be detected automatically, that would be great. There is no way to do this. The only thing that can be determined is that something is not utf-8. The stream did that reliably. But you said you already know the encoding, so just set in on the stream and it should work. > Firefox tells me that the encoding is ISO-8859-1; ISO-8859-1 and ISO-8859-15 are not the same. Cheers Philippe

July 25, 2010

[Pharo-project] Underscores in 1.1??

by Schwab,Wilhelm K

Hello all, Is 1.1 able to handle underscores in method *and* class names? Is this really behind us now? Bill

July 25, 2010

Re: [Pharo-project] Invalid utf8 input detected: now what?

by Henrik Johansen

On Jul 24, 2010, at 1:57 11PM, Schwab,Wilhelm K wrote: > I agree that there is apparently not much of a problem. However, I also stand by "no more dialogs" unless they are in a clearly-identified class/method/state that is known to interact with the user. Squeak has *far* too much forced and unexpected interaction, and we must not go back down that road. Which is why I asked initially whether you encountered this when using a tool (ie file browser etc.), or custom code. For tools when you have no way to set one encoding which will be correct for all cases, it might be a better behaviour to open a dialogue where one can be selected instead of raising a DNU, if a GUI is present. > > Those things said, there might be room to grow, as someone suggested the possibility of automatically detecting the coding. Then they were wrong. Cheers, Henry

July 24, 2010

Re: [Pharo-project] Invalid utf8 input detected: now what?

by Schwab,Wilhelm K

I agree that there is apparently not much of a problem. However, I also stand by "no more dialogs" unless they are in a clearly-identified class/method/state that is known to interact with the user. Squeak has *far* too much forced and unexpected interaction, and we must not go back down that road. Those things said, there might be room to grow, as someone suggested the possibility of automatically detecting the coding. ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Henrik Johansen [henrik.s.johansen(a)veloxit.no] Sent: Friday, July 23, 2010 12:41 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Invalid utf8 input detected: now what? Den 23. juli 2010 kl. 15:15 skrev "Schwab,Wilhelm K" <bschwab(a)anest.ufl.edu>: > No dialogs, please :) Actually, it would be fine if there were a different stream class or simply a different method/state (encoding =#userInteraction or something??) that is understood to negotiate such details with "the user." I have no idea what you are suggesting... > In general, exception is the correct way to handle this: the stream "knows" what is wrong; the application will know what to make of it. If the encoding can be detected automatically, that would be great. > Then I fail to see what the problem is. You got an error stating it was not UTF8, which implies a choice of the correct encoding needs to be done by the application. (by setting the streams encoding to something else) As you noticed with gedit/firefox, any "automatic" detection is at best an educated guess, and can not be relied upon to make the correct choice. Cheers, Henry _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

July 24, 2010

Re: [Pharo-project] Time Machine

by Patrick Barroca

I've ordered "Why programs fail" by Andreas Zeller. It will be my summer holidays book ;) On Thu, Jul 22, 2010 at 11:52 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > http://www.st.cs.uni-saarland.de/dd/ > you can get some papers but also the slides that go with the book > Stef > > On Jul 22, 2010, at 11:36 PM, laurent laffont wrote: > >> >> On Thu, Jul 22, 2010 at 11:34 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> did you read delta debugging from andreas Zeller? >> >> No. Where ? >> >> Laurent >> >> >> >> Stef >> >> On Jul 22, 2010, at 11:11 PM, laurent laffont wrote: >> >> > Hi, >> > >> > From a discussion I had with Kent Beck about Continuous Testing / Autotest (see http://pharocasts.blogspot.com/2010/07/live-testing-with-autotest.html ), I would like to add a kind of Time Machine for Smalltalk code in Autotest. >> > >> > When a test fails, what I really want to know is why. Sometimes a test fails and I don't know why. So I have to go through a debugging session which distracts me from what I've been coding. >> > >> > So an idea is to diff backtrace before and after the test fails: >> > - revert to last green >> > - replay the test and save the trace >> > - forward to current test and run (test fails) >> > - compare execution paths in order to see the consequence of last change >> > >> > How would you do this ? Where should I look for materials which can help me coding this ? >> > >> > Cheers, >> > >> > 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 >> >> >> _______________________________________________ >> 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 > -- Patrick Barroca

July 24, 2010

Re: [Pharo-project] Autotest, proof-of-concept [was: About TDD and Pharo]

by Alexandre Bergel

I have been using Autotest for a while already. I greatly reduce the window switching. This is cool. However, I have to disable Autotest when the tests take time to execute. Alexandre On 15 Jun 2010, at 21:41, laurent laffont wrote: > Hi Alexandre, > > I've reorganized Autotest to write tests. The tests now run in a thread with lower priority. Thanks for feedback. > > Cheers, > > Laurent Laffont > > http://pharocasts.blogspot.com/ > http://magaloma.blogspot.com/ > > > On Mon, Jun 14, 2010 at 4:52 PM, Alexandre Bergel <alexandre(a)bergel.eu> wrote: > Hi Laurent, > > I tried to program while having AutoTest running. > More importantly than the interface, I experienced some problem with long executing tests. Basically, these tests should not be executed while I am programming. Or at least in a thread of a lesser priority. Am I the only one to experience this? > > Cheers, > Alexandre > > > On 11 Jun 2010, at 09:02, laurent laffont wrote: > > > On Fri, Jun 11, 2010 at 2:29 PM, Alexandre Bergel <alexandre(a)bergel.eu> wrote: > > Hi Laurent, > > > > I like Autotest. It is true that I always execute the test after modifying it. > > There are three horizontal panes. Why so? Is it just to open a debugger when necessary? > > > > I want to be able to open a debugger from autotest. I agree the GUI is crap now. > > > > > > We could imagine one standalone button instead with a green color to say the test I just edited is green, and yellow or red when it fails. In that case, clicking on the button open a debugger. > > > > I just feel the window of autotest takes a lot of space in the screen, without having a real benefit. > > > > Yes it's true. I'm still thinking on a good GUI. But I'm learning how to make GUI now :) > > > > If you look at Autotest package, AutotestView is just the GUI, so we can implement several GUI and see the best solution. I need to take the time to do it, repository is read / write so feel free to commit :) > > > > What I want to have is a dashboard docked on one side of the screen which acts like you're driving a car. It's always visible, you have to be able to look quickly at it as when you check the speed of your car, adjust your drive, .... > > > > Also another problem with the current version if that if a test fails, change it and fails again, you don't see it has run (nothing moves in the GUI). > > > > Finally, another problem is that you see that a test has failed, but you don't know why (SUnit TestRunner has the same problem). I want to display the exception message too. > > > > Thanks a lot for feedback. > > > > Laurent Laffont > > > > http://pharocasts.blogspot.com/ > > http://magaloma.blogspot.com/ > > > > > > > > Cheers, > > Alexandre > > > > > > On 3 Jun 2010, at 17:11, laurent laffont wrote: > > > > > Hi, > > > > > > I've written a proof-of-concept for Autotest. Draft/crappy code and no tests (exploration mode :) but it loads on PharoCore-1.1-11383-beta image. > > > > > > Load it: > > > Gofer new > > > squeaksource: 'Autotest'; > > > package: 'Autotest'; > > > load > > > > > > Open it: > > > AutotestView open > > > (there's en entry in WorldMenu > Tools) > > > > > > And change a tested method to see the results. > > > > > > There's a bug I need to find, maybe someone knows: > > > - Change Bag>>occurrencesOf: > > > - Autotest gives: > > > > > > 284 run, 281 passes, 0 expected failures, 1 failures, 2 errors, 0 unexpected passes > > > Failures: > > > CollectionRootTest>>#test0FixtureIterateTest > > > > > > Errors: > > > CollectionRootTest>>#testBasicCollect > > > CollectionRootTest>>#testDoWithout > > > > > > but in SUnit CollectionRootTest gives > > > 0 run, 0 passes, 0 expected failures, 0 failures, 0 errors, 0 unexpected passes ?? > > > > > > > > > Cheers, > > > > > > Laurent Laffont > > > > > > http://pharocasts.blogspot.com/ > > > http://magaloma.blogspot.com/ > > > > > > > > > On Thu, Jun 3, 2010 at 6:09 PM, Alexandre Bergel <alexandre(a)bergel.eu> wrote: > > > The idea is excellent. > > > > > > Cheers, > > > Alexandre > > > > > > > > > On 3 Jun 2010, at 10:22, laurent laffont wrote: > > > > > > > > > > > > > > > On Thu, Jun 3, 2010 at 3:42 PM, Alexandre Bergel <alexandre(a)bergel.eu> wrote: > > > > > You may have a lot of noise. > > > > > > > > > > I guess that Ruby uses files as a unit of development/deployment. The closest Smalltalk/Pharo has is the class and the package. > > > > > > > > > > I would suggest that TestCase which would use this feature use some pragma/method to identify/declare which classes/packages this test depends upon. Then the "autotest" framework would register such tests and listen for changes in the given classes/packages, launching required tests whenever a change happen. > > > > > > > > > > Additionally, one could declare such a pragma on a single test method, when this test should be run for a specific class. > > > > > > > > > > Of course, you also to take care of long running tests, which you probably want to exclude from auto-testing. > > > > > > > > I see autotest in Pharo in a slighly different way: When I press save in the Monticello browser, I have a popup menu which asks me whether (i) I want to run all the tests or (ii) only the tests that cover that I changed from the last version. > > > > > > > > Does this make sense? > > > > > > > > Please no popup :) What I like in ruby autotest is that I can quickly look at test results if I want (or not) without stop writing. Often you want to see your tests failing, as you type / save code. I don't have to stop writing, click a button, wait test results, go again.... testing is done in background and I just see notifications whether it's OK or not. > > > > > > > > So test log in a Transcript is OK for me. > > > > > > > > > > > > For autotest unit of work is file: it runs the test file which has the same name as the code file, but you can customize this behavior. For autotest-rails: > > > > "A simplified version of Autotest heuristics in this mode would be: > > > > When changing a test file, only this file is run (e.g. test/unit/foo_test.rb âtest/unit/foo_test.rb). > > > > When changing a model file, only associated unit test file is run (e.g.app/models/foo.rb â test/unit/foo_test.rb). > > > > When changing a controller file, associated functional test file is run (e.g.app/controllers/foo_controller.rb âtest/functional/foo_controller_test.rb). > > > > When changing a fixture file, associated unit test and functional test are run (e.g.app/fixtures/foos.yml â test/unit/foo_test.rb +test/functional/foo_controller_test.rb). > > > > When changing a helper file, associated functional test file is run (e.g.app/helpers/foo_helper.rb âtest/functional/foo_controller_test.rb). > > > > When changing application_helper.rb file all functional test files are run (e.g.application_helper.rb â test/functional/*_test.rb). > > > > When changing a file under the config directory, all tests are run." > > > > > > > > Laurent > > > > > > > > > > > > > > > > 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 > > > > > > > > _______________________________________________ > > > > Pharo-project mailing list > > > > Pharo-project(a)lists.gforge.inria.fr > > > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > -- > > > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > > > 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 > > > > > > _______________________________________________ > > > Pharo-project mailing list > > > Pharo-project(a)lists.gforge.inria.fr > > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > -- > > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > > 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 > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > 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 > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

July 24, 2010

Re: [Pharo-project] Symbol >> #asClass ?

by Andres Valloud

I don't know if others already voiced this concern, but what happens when the symbol does not resolve unambiguously if there are classes with the same "leaf" name in different namespaces? On 7/22/10 6:13 , Philippe Marschall wrote: > Hi > > VAST has an #asClass method on Symbol that does more or less this: > > Symbol>> #asClass > ^ Smalltalk at: self > > This can be quite handy if you want to refer to a class that is not > there a compile time, eg. Metacello. > > Think: > #ConfigurationOfSeaside30 asClass load > > Cheers > Philippe > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >

July 24, 2010

[Pharo-project] Smalltalks 2010 Research Track: Call for Papers

by Andres Valloud

** PLEASE EXCUSE US IF YOU RECEIVE MULTIPLE COPIES ** CALL FOR PAPERS SMALLTALKS 2010 4th Argentinian Smalltalk Conference Research Track: Call for Papers November 11th â 13th, 2010 Important dates: Submission (Hard Deadline): September 7th, 2010 (Argentinian time: UTC/GMT -3 hours). Notification of acceptance: October 6th, 2010. Camera Ready Submission: October 20th, 2010. --------------------------------------------------------------------------------- Conference Site: Universidad TecnolÃ³gica Nacional (UTN), ConcepciÃ³n del Uruguay (Entre RÃos, Argentina) In the past three years the Smalltalks series of conferences (www.fast.org.ar) have been a lively forum on Smalltalk-based software technologies that attracted over more than 200 people from both academia and industry for three days. During the first three conferences, the industrial partners showed the applicability of Smalltalk in business, while researches (both students and professors) showed their advances and didactic uses of Smalltalk. The presented approaches and methodologies concerned the language, its implementation technology, its programming tools as well as the software development culture it supports. This year the accepted papers not only will be available in the website but also the best ranked ones will be published in a special edition of Elsevier COMLAN Journal. Thus, we invite to submit papers in the research track on original scientific research conducted in and/or for Smalltalk in general. Topics of interest include, but are not restricted to: â¢ Aspects, Aspect Languages and Applications. â¢ Ambient Intelligence, Ubiquitous / Pervasive Computing and Embedded Systems. â¢ Compilation Technology, Optimization, Virtual Machines. â¢ Educational Material. â¢ Language Engineering, Extensions. â¢ Model Driven Engineering / Development. â¢ Meta-Modeling, Reflection and Meta-programming. â¢ Programming in the Large, Design, Architectures and Components. â¢ Programming Environments, Browsers, User Interfaces, UI Frameworks. â¢ Reasoning About Code (Analysis, Refactoring, Type Inference, Metrics). â¢ Team Management. â¢ Testing, Extreme Programming / Practices. â¢ Web Services, Internet Applications, Event-driven Programming. â¢ Experience Reports. Important dates: Submission (Hard Deadline): September 7th, 2010 (Argentinian time: UTC/GMT -3 hours). Notification of acceptance: October 6th, 2010. Camera Ready Submission: October 20th, 2010. Papers: Papers should be written in English, in pdf-format and not exceed 15 pages (including references and figures), using Elsevier journal format. Templates for LaTeX formats can be found at http://www.elsevier.com/wps/find/authorsview.authors/elsart Papers must be submitted through the EasyChair submission web site at http://www.easychair.org/conferences/?conf=smalltalks10 The accepted papers will be digitally available in the conference website. From accepted papers, selected ones will be published in a special edition of Elsevier COMLAN Journal. Papers submitted must not have been previously published and must not be under review for publication elsewhere. Papers must strictly adhere to submission guidelines. If you have questions, please send an e-mail to Marcus Denker and Gabriela ArÃ©valo to smalltalks2010-chair(a)fast.org.ar using [Smalltalks2010-RT] as a tag in the e-mail subject. Program Committee -------------------------- â¢ Alexandre Bergel (DCC, Universidad de Chile, Chile) â¢ Noury Bouraqadi (Ecole des Mines, Douai, France) â¢ Gilad Bracha (Ministry of Truth, USA) â¢ Johan Brichau (Inceptive.be, Belgium) â¢ Johan Fabry (DCC, Universidad de Chile, Chile) â¢ Alejandro Fernandez (LIFIA - Facultad de InformÃ¡tica â UNLP, Argentina) â¢ Tudor Girba (Sw-eng. Software Engineering GmbH, Switzerland) â¢ Andy Kellens (SOFT, Vrije Universiteit Brussels, Belgium) â¢ Michele Lanza (University of Lugano, Switzerland) â¢ Adrian Lienhard (SCG, University of Bern, Switzerland) â¢ Damien Pollet (INRIA / UniversitÃ© de Lille 1, France) â¢ Lukas Renggli (SCG, University of Bern, Switzerland) â¢ David RÃ¶thlisberger (SCG, University of Bern, Switzerland) â¢ Tom Van Cutsem (SOFT, Vrije Universeit Brussels, Belgium) Program Chairs -------------------- â¢ Marcus Denker (INRIA, Lille, France) â¢ Gabriela ArÃ©valo (Universidad Austral, Buenos Aires, Argentina) .

July 24, 2010

[Pharo-project] [update 1.2] #12065

by StÃ©phane Ducasse

12065 ----- - Issue 2654: ChangeList ENH from eliot.

July 23, 2010