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

[Pharo-project] Primitives ?

by James Ladd

Hi All, I'm looking at some low level details of Pharo Smalltalk and I am wondering, when I see a primitive in the bytecode, is it safe to assume that before the primitive is executed, the receiver and any args to the method are pushed onto the stack? Rgs, James. _________________________________________________________________ If It Exists, You'll Find it on SEEK. Australia's #1 job site http://clk.atdmt.com/NMN/go/157639755/direct/01/

July 25, 2010

Re: [Pharo-project] cog-based image crashes on mac

by Levente Uzonyi

On Sun, 25 Jul 2010, Tudor Girba wrote: > Hi, > > I have been using the Cog VM exclusively for several months now, and from Did you get a VM from Teleplace before it was open sourced? > time to time it crashes on me without leaving any trace in debug log. > > One frequent cause for the crash that I noticed is dealing with Monticello > (both reading and writing). Does anyone experience similar things? Am I doing > something wrong? IIRC this issue was fixed in VMMaker-oscog.17. > > The image I got is based on the sources from 27.06.2010. You may be missing some image-side changes. The CogVM was open sourced on 20.06.2010. Levente > > Perhaps a more general idea: given that this VM brings an important > improvement, do we want to have a more concerted effort to beta-test it? > > Cheers, > Doru > > > -- > www.tudorgirba.com > > "It's not how it is, it is how we see it." > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

July 25, 2010

Re: [Pharo-project] [ANN 1.1] One-Click 1.1 release

by Mariano Martinez Peck

On Sun, Jul 25, 2010 at 4:02 PM, Adrian Lienhard <adi(a)netstyle.ch> wrote: > Hm, the link doesn't work for me. I just get an empty response... > > https://gforge.inria.fr/frs/download.php/27303/Pharo-1.1-OneClick.zip works ok here > Adrian > > > On Jul 25, 2010, at 12:05 , Marcus Denker wrote: > > > > > > > > https://gforge.inria.fr/frs/download.php/27302/Pharo-1.1-OneClick.zip > > > > -- > > Marcus Denker -- http://www.marcusdenker.de > > INRIA Lille -- Nord Europe. Team RMoD. > > > > > > _______________________________________________ > > 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 >

July 25, 2010

Re: [Pharo-project] [ANN 1.1] One-Click 1.1 release

by Adrian Lienhard

Hm, the link doesn't work for me. I just get an empty response... Adrian On Jul 25, 2010, at 12:05 , Marcus Denker wrote: > > > https://gforge.inria.fr/frs/download.php/27302/Pharo-1.1-OneClick.zip > > -- > Marcus Denker -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

July 25, 2010

Re: [Pharo-project] [ANN 1.1] One-Click 1.1 release

by Marcus Denker

On Jul 25, 2010, at 12:05 PM, Marcus Denker wrote: > > > https://gforge.inria.fr/frs/download.php/27302/Pharo-1.1-OneClick.zip due to a small glicht (used the wrong zip, added macos meta data...) Sadly the gforge can not replace files and keep the same path... https://gforge.inria.fr/frs/download.php/27303/Pharo-1.1-OneClick.zip -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

July 25, 2010

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

by Schwab,Wilhelm K

I'm ok with calling this "works as intended" if the encoding experts are. Since I am *not* an expert on encoding, I ran it up the flag pole. ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Philippe Marschall [kustos(a)gmx.net] Sent: Sunday, July 25, 2010 3:57 AM To: pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Invalid utf8 input detected: now what? 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 _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

July 25, 2010

Re: [Pharo-project] cog-based image crashes on mac

by Schwab,Wilhelm K

Do you ordinarily get output in the log? I have found the Linux vm to be very stingy with such information, but something like ( /fullPathTo/squeakvm \ /anotherFullPath/Pharo-1.0.image # ) 1>pharo_out.txt 2>pharo_error.txt seemed to work. ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Tudor Girba [tudor.girba(a)gmail.com] Sent: Sunday, July 25, 2010 6:47 AM To: Pharo Development Subject: [Pharo-project] cog-based image crashes on mac Hi, I have been using the Cog VM exclusively for several months now, and from time to time it crashes on me without leaving any trace in debug log. One frequent cause for the crash that I noticed is dealing with Monticello (both reading and writing). Does anyone experience similar things? Am I doing something wrong? The image I got is based on the sources from 27.06.2010. Perhaps a more general idea: given that this VM brings an important improvement, do we want to have a more concerted effort to beta-test it? Cheers, Doru -- www.tudorgirba.com "It's not how it is, it is how we see it." _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

July 25, 2010

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

by Schwab,Wilhelm K

THANKS!!!!! to all involved in getting this done. ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Lukas Renggli [renggli(a)gmail.com] Sent: Sunday, July 25, 2010 4:32 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Underscores in 1.1?? > 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 _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

July 25, 2010

[Pharo-project] cog-based image crashes on mac

by Tudor Girba

Hi, I have been using the Cog VM exclusively for several months now, and from time to time it crashes on me without leaving any trace in debug log. One frequent cause for the crash that I noticed is dealing with Monticello (both reading and writing). Does anyone experience similar things? Am I doing something wrong? The image I got is based on the sources from 27.06.2010. Perhaps a more general idea: given that this VM brings an important improvement, do we want to have a more concerted effort to beta-test it? Cheers, Doru -- www.tudorgirba.com "It's not how it is, it is how we see it."

July 25, 2010

[Pharo-project] [ANN 1.1] One-Click 1.1 release

by Marcus Denker

https://gforge.inria.fr/frs/download.php/27302/Pharo-1.1-OneClick.zip -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

July 25, 2010

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

[Pharo-project] Object-oriented reengineering patterns :)

by StÃ©phane Ducasse

In changeList browseCurrentVersionsOfSelections "Opens a message-list browser on the current in-memory versions of all methods that are currently seleted" | aList | aList := OrderedCollection new. Cursor read showWhile: [ 1 to: changeList size do: [:i | (listSelections at: i) ifTrue: [ | aClass aChange | aChange := changeList at: i. (aChange type = #method and: [(aClass := aChange methodClass) notNil and: [aClass includesSelector: aChange methodSelector]]) contentsDiffedFromCurrent "Answer the contents diffed forward from current (in-memory) method version" | aChange aClass | listIndex = 0 ifTrue: [^ '']. aChange := changeList at: listIndex. (aChange type == #method and: [(aClass := aChange methodClass) notNil and: [aClass includesSelector: aChange methodSelector]]) ifTrue: destroyCurrentCodeOfSelections "Actually remove from the system any in-memory methods with class and selector identical to items current selected. This may seem rather arcane but believe me it has its great uses, when trying to split out code. To use effectively, first file out a change set that you wish to split off. Then open a ChangeList browser on that fileout. Now look through the methods, and select any of them which you want to remove completely from the system, then issue this command. For those methods where you have made changes to pre-existing versions, of course, you won't want to remove them from the system, so use this mechanism with care!" | aClass aChange aList | aList := OrderedCollection new. 1 to: changeList size do: [:index | (listSelections at: index) ifTrue: [aChange := changeList at: index. (aChange type = #method and: [(aClass := aChange methodClass) notNil and: [aClass includesSelector: aChange methodSelector]]) ifTrue: and a couple more.... I like old design. It is sweet and you feel cool when you fix it. Stef

July 23, 2010

Re: [Pharo-project] About validating the result of RBParser >> parseMethod:

by StÃ©phane Ducasse

Ok ;) > My point was that while good work on non-interactive errors in the standard compiler has been done there's no guarantee its finished and we should check and make whatever modifications are required so that it all errors can be caught. > > best > Eliot > > Fernando if you can check and let us know.

July 23, 2010

Re: [Pharo-project] About validating the result of RBParser >> parseMethod:

by Lukas Renggli

Yeah, these notifications are integrated in Pharo 1.0. OmniBrowser uses them. Lukas On 23 July 2010 19:12, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > I thought I integrated those. > Fernando if you can check and let us know. > > Stef > > On Jul 23, 2010, at 6:48 PM, Eliot Miranda wrote: > >> Hi Fernando, >> >> On Fri, Jul 23, 2010 at 2:46 AM, Fernando olivero <oliverof(a)lu.unisi.ch> wrote: >> Lukas, thanks for the answer. I will see if AST-Semantics solves my problem. >> >> I also tried using the Compiler and the parser, and faking a notifier. But the Compiler>>interactive behavior is hard to override, >> it always gives me visual feedback ( pop menus and related dialogs). >> >> Colin Putney has done good work replacing a number of interactive errors with exceptions whose defaultAction is to produce the notifier. Â These are in Squeak 4.1. Â Have you taken a look at the trunk 4.1 compiler? Â Clearly the standard compiler should be able to do what you want. Â We should fix it :) >> >> best >> Eliot >> >> Maybe the newCompiler is more customizable? >> >> Fernando >> >> >> On Jul 23, 2010, at 7:34 AM, Lukas Renggli wrote: >> >> > You can use #parseMethod:onError: to check for syntactical errors. >> > >> > Semantical errors are harder to detect, some of them (e.g. undeclared >> > variables) you can find using AST-Semantics. >> > >> > Lukas >> > >> > On 23 July 2010 00:35, Fernando olivero <oliverof(a)lu.unisi.ch> wrote: >> >> I have a question about validating a methodNode, suppose we have the following: >> >> >> >> parsedNode := Â RBParser parseMethod: 'test ^ self add: anUnbindedVariable'. >> >> >> >> Is there a way of checking the health/validity of the parsedNode? >> >> >> >> I couldn't find any behavior in RBMethodNode or related classes. >> >> >> >> Lukas, do you have an idea is i could run any Lint rule? >> >> >> >> My idea is to provide a method editor morph, that prevents from accepting invalid sources, and informs the user any problems detected with the edited code. >> >> >> >> Thanks, >> >> Fernando >> >> >> >> >> >> _______________________________________________ >> >> Pharo-project mailing list >> >> Pharo-project(a)lists.gforge.inria.fr >> >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> > >> > >> > >> > -- >> > Lukas Renggli >> > 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 >> >> >> _______________________________________________ >> 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 > -- Lukas Renggli www.lukas-renggli.ch

July 23, 2010

Re: [Pharo-project] About validating the result of RBParser >> parseMethod:

by Eliot Miranda

Hi StÃ©phane, On Fri, Jul 23, 2010 at 10:12 AM, StÃ©phane Ducasse < stephane.ducasse(a)inria.fr> wrote: > I thought I integrated those. > My point was that while good work on non-interactive errors in the standard compiler has been done there's no guarantee its finished and we should check and make whatever modifications are required so that it all errors can be caught. best Eliot > Fernando if you can check and let us know. > > Stef > > On Jul 23, 2010, at 6:48 PM, Eliot Miranda wrote: > > > Hi Fernando, > > > > On Fri, Jul 23, 2010 at 2:46 AM, Fernando olivero <oliverof(a)lu.unisi.ch> > wrote: > > Lukas, thanks for the answer. I will see if AST-Semantics solves my > problem. > > > > I also tried using the Compiler and the parser, and faking a notifier. > But the Compiler>>interactive behavior is hard to override, > > it always gives me visual feedback ( pop menus and related dialogs). > > > > Colin Putney has done good work replacing a number of interactive errors > with exceptions whose defaultAction is to produce the notifier. These are > in Squeak 4.1. Have you taken a look at the trunk 4.1 compiler? Clearly > the standard compiler should be able to do what you want. We should fix it > :) > > > > best > > Eliot > > > > Maybe the newCompiler is more customizable? > > > > Fernando > > > > > > On Jul 23, 2010, at 7:34 AM, Lukas Renggli wrote: > > > > > You can use #parseMethod:onError: to check for syntactical errors. > > > > > > Semantical errors are harder to detect, some of them (e.g. undeclared > > > variables) you can find using AST-Semantics. > > > > > > Lukas > > > > > > On 23 July 2010 00:35, Fernando olivero <oliverof(a)lu.unisi.ch> wrote: > > >> I have a question about validating a methodNode, suppose we have the > following: > > >> > > >> parsedNode := RBParser parseMethod: 'test ^ self add: > anUnbindedVariable'. > > >> > > >> Is there a way of checking the health/validity of the parsedNode? > > >> > > >> I couldn't find any behavior in RBMethodNode or related classes. > > >> > > >> Lukas, do you have an idea is i could run any Lint rule? > > >> > > >> My idea is to provide a method editor morph, that prevents from > accepting invalid sources, and informs the user any problems detected with > the edited code. > > >> > > >> Thanks, > > >> Fernando > > >> > > >> > > >> _______________________________________________ > > >> Pharo-project mailing list > > >> Pharo-project(a)lists.gforge.inria.fr > > >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > >> > > > > > > > > > > > > -- > > > Lukas Renggli > > > 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 > > > > > > _______________________________________________ > > 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 >

July 23, 2010

Re: [Pharo-project] About validating the result of RBParser >> parseMethod:

by StÃ©phane Ducasse

I thought I integrated those. Fernando if you can check and let us know. Stef On Jul 23, 2010, at 6:48 PM, Eliot Miranda wrote: > Hi Fernando, > > On Fri, Jul 23, 2010 at 2:46 AM, Fernando olivero <oliverof(a)lu.unisi.ch> wrote: > Lukas, thanks for the answer. I will see if AST-Semantics solves my problem. > > I also tried using the Compiler and the parser, and faking a notifier. But the Compiler>>interactive behavior is hard to override, > it always gives me visual feedback ( pop menus and related dialogs). > > Colin Putney has done good work replacing a number of interactive errors with exceptions whose defaultAction is to produce the notifier. These are in Squeak 4.1. Have you taken a look at the trunk 4.1 compiler? Clearly the standard compiler should be able to do what you want. We should fix it :) > > best > Eliot > > Maybe the newCompiler is more customizable? > > Fernando > > > On Jul 23, 2010, at 7:34 AM, Lukas Renggli wrote: > > > You can use #parseMethod:onError: to check for syntactical errors. > > > > Semantical errors are harder to detect, some of them (e.g. undeclared > > variables) you can find using AST-Semantics. > > > > Lukas > > > > On 23 July 2010 00:35, Fernando olivero <oliverof(a)lu.unisi.ch> wrote: > >> I have a question about validating a methodNode, suppose we have the following: > >> > >> parsedNode := RBParser parseMethod: 'test ^ self add: anUnbindedVariable'. > >> > >> Is there a way of checking the health/validity of the parsedNode? > >> > >> I couldn't find any behavior in RBMethodNode or related classes. > >> > >> Lukas, do you have an idea is i could run any Lint rule? > >> > >> My idea is to provide a method editor morph, that prevents from accepting invalid sources, and informs the user any problems detected with the edited code. > >> > >> Thanks, > >> Fernando > >> > >> > >> _______________________________________________ > >> Pharo-project mailing list > >> Pharo-project(a)lists.gforge.inria.fr > >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >> > > > > > > > > -- > > Lukas Renggli > > 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 > > > _______________________________________________ > 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

July 23, 2010

Re: [Pharo-project] About validating the result of RBParser >> parseMethod:

by Eliot Miranda

Hi Fernando, On Fri, Jul 23, 2010 at 2:46 AM, Fernando olivero <oliverof(a)lu.unisi.ch>wrote: > Lukas, thanks for the answer. I will see if AST-Semantics solves my > problem. > > I also tried using the Compiler and the parser, and faking a notifier. But > the Compiler>>interactive behavior is hard to override, > it always gives me visual feedback ( pop menus and related dialogs). Colin Putney has done good work replacing a number of interactive errors with exceptions whose defaultAction is to produce the notifier. These are in Squeak 4.1. Have you taken a look at the trunk 4.1 compiler? Clearly the standard compiler should be able to do what you want. We should fix it :) best Eliot > Maybe the newCompiler is more customizable? > > Fernando > > > On Jul 23, 2010, at 7:34 AM, Lukas Renggli wrote: > > > You can use #parseMethod:onError: to check for syntactical errors. > > > > Semantical errors are harder to detect, some of them (e.g. undeclared > > variables) you can find using AST-Semantics. > > > > Lukas > > > > On 23 July 2010 00:35, Fernando olivero <oliverof(a)lu.unisi.ch> wrote: > >> I have a question about validating a methodNode, suppose we have the > following: > >> > >> parsedNode := RBParser parseMethod: 'test ^ self add: > anUnbindedVariable'. > >> > >> Is there a way of checking the health/validity of the parsedNode? > >> > >> I couldn't find any behavior in RBMethodNode or related classes. > >> > >> Lukas, do you have an idea is i could run any Lint rule? > >> > >> My idea is to provide a method editor morph, that prevents from > accepting invalid sources, and informs the user any problems detected with > the edited code. > >> > >> Thanks, > >> Fernando > >> > >> > >> _______________________________________________ > >> Pharo-project mailing list > >> Pharo-project(a)lists.gforge.inria.fr > >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >> > > > > > > > > -- > > Lukas Renggli > > 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 > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

July 23, 2010

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

by Henrik Johansen

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

July 23, 2010

Re: [Pharo-project] What is correct way to save image automatically in background?

by Yanni Chiu

Here's my understanding of how it works. Garbage collection is completed before the Unix fork system call is made. At the moment of the fork, the original server VM process and the new image saving VM process share the exact same pages in the Unix OS - due to "Unix copy-on-write memory management". Immediately after the fork, the server VM process continues processing requests. Meanwhile, the image saving VM process proceeds to save the image. As each process continues execution, they will "dirty" their memory pages. Each dirty page means that that page is no longer shared between the two processes - leading to increased OS memory resources being allocated to the two processes. If the server VM process is very active, then a lot of dirty pages will be created, before the image saving VM process can complete. So, running the image saving process at a lower priority may actually be detrimental. One thing that occurs to me now, is whether or not the garbage collection is completed before the fork. If not, and it's done first thing by the image saving process, then it will be as you describe - the whole memory gets copied anyway. -- Yanni Lukas Renggli wrote: > David, is what is said about memory management really true? I thought > that saving the image triggered a garbage collect what forces to copy > the whole memory anyway. > > Lukas > > On 23 July 2010 14:00, David T. Lewis <lewis(a)mail.msen.com> wrote: >> On Fri, Jul 23, 2010 at 09:49:46AM +0200, Lukas Renggli wrote: >>>> But How I can do that without fork? I track changes in another process and >>>> when I do update I save image in this process. >>>> How I can initiate image saving from ui process? >>> I don't understand what you are saying. >>> >>> The thing is that using #fork to save the image has no effect (other >>> than wrecking the image), because #snapshot:andQuit: is eventually >>> calling a primitive that locks the complete VM anyway. >>> >>> If you want to fork while saving the image you need to use an OS-level >>> fork, not a Smalltalk-level fork. You can do this with OSProcess for >>> example (check the Seaside mailing-list archive). >> "UnixProcess saveImageInBackgroundNicely" >> >> Explained in the method comment: >> >> UnixProcess class>>saveImageInBackground: savedImageName nice: niceFlag >> "When Squeak is used as a server it is sometimes desirable to periodically >> save image snapshots. This method forks a headless Squeak to perform a >> snapshot without impacting the server Squeak. Very little additional memory >> is required to do this because Unix copy-on-write memory management allows >> the two Squeak images to share object memory while the save is performed. >> The saved image is given a time stamped name, and the image name of >> the main server Squeak remains unchanged. If niceFlag is true, the >> background OS process runs at lowered scheduling priority." >> >> Dave

July 23, 2010

Re: [Pharo-project] Another RB engine change

by StÃ©phane Ducasse

Smalltalk>>globals ^ self in 1.0 then :) On Jul 23, 2010, at 5:32 PM, Yanni Chiu wrote: > I don't use omnibrowser on Pharo-1.0, but I was still building it. See: > http://hudson.jooshr.org/job/Pharo1.0-Seaside3.0/200/testReport/ > > I checked only a few of the stacktraces on the 404 newly failing tests, and they were all: > SystemDictionary(Object)>>doesNotUnderstand: #globals > > Maybe the simplest thing to do is a maintenance patch to Pharo-1.0 with an implementation for Smalltalk>>globals. > > > > Lukas Renggli wrote: >> I fixed that and about 30 other occurrences of the same problem. >> Name: Refactoring-Core-lr.147 >> Author: lr >> Time: 23 July 2010, 8:14:01 am >> UUID: 8e608df4-579d-4a3d-a589-0eb90109275e >> Ancestors: Refactoring-Core-lr.146 >> - fixed numerous occurrences where the old 'Smalltalk' was used >> Thank you for pointing out. >> Lukas >> On 23 July 2010 00:01, Fernando olivero <oliverof(a)lu.unisi.ch> wrote: >>> Hi Lukas, here is another change in the RB engine package. >>> >>> RBClass>>realName: aSymbol >>> self realClass: (Smalltalk at: aSymbol) >>> >>> => >>> self realClass: (Smalltalk globals at: aSymbol) >>> >>> Fernando >>> >>> _______________________________________________ >>> 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

July 23, 2010

Re: [Pharo-project] What is correct way to save image automatically in background?

by Lukas Renggli

Cool, thanks for the update. On Friday, July 23, 2010, David T. Lewis <lewis(a)mail.msen.com> wrote: > Yes, it really is true. That said, I would expect the practical impact > to vary depending on how busy the main image is. > > If you are running a Squeak/Pharo image that is not busy, such as your > own personal desktop image or a Seaside image that is not currently > receiving requests, then the additional system memory used by the > forked background image is extremely small (it's pretty amazing > actually, try watching it on a system monitor such as xosview). > However, I would expect that if you were to do this with a busy > Seaside image, then that image would be doing a lot of updates to > memory and possibly garbage collection, so that will force the OS > to use more memory. > > Unfortunately this means that the busier your image is, the less > benefit you get from a memory usage point of view. But even at that, > you still get the advantage of doing the image save in a background > OS process running at lower OS scheduling priority. > > I do not actually run any Seaside server images, so someone would > need to try this on a real system to find out how much benefit it > delivers in practice. I would be interested to know the results. > > Dave > > > On Fri, Jul 23, 2010 at 02:12:14PM +0200, Lukas Renggli wrote: >> David, is what is said about memory management really true? I thought >> that saving the image triggered a garbage collect what forces to copy >> the whole memory anyway. >> >> Lukas >> >> On 23 July 2010 14:00, David T. Lewis <lewis(a)mail.msen.com> wrote: >> > On Fri, Jul 23, 2010 at 09:49:46AM +0200, Lukas Renggli wrote: >> >> > But How I can do that without fork? I track changes in another process and >> >> > when I do update I save image in this process. >> >> > How I can initiate image saving from ui process? >> >> >> >> I don't understand what you are saying. >> >> >> >> The thing is that using #fork to save the image has no effect (other >> >> than wrecking the image), because #snapshot:andQuit: is eventually >> >> calling a primitive that locks the complete VM anyway. >> >> >> >> If you want to fork while saving the image you need to use an OS-level >> >> fork, not a Smalltalk-level fork. You can do this with OSProcess for >> >> example (check the Seaside mailing-list archive). >> > >> > "UnixProcess saveImageInBackgroundNicely" >> > >> > Explained in the method comment: >> > >> > UnixProcess class>>saveImageInBackground: savedImageName nice: niceFlag >> > ? ? ? ?"When Squeak is used as a server it is sometimes desirable to periodically >> > ? ? ? ?save image snapshots. This method forks a headless Squeak to perform a >> > ? ? ? ?snapshot without impacting the server Squeak. Very little additional memory >> > ? ? ? ?is required to do this because Unix copy-on-write memory management allows >> > ? ? ? ?the two Squeak images to share object memory while the save is performed. >> > ? ? ? ?The saved image is given a time stamped name, and the image name of >> > ? ? ? ?the main server Squeak remains unchanged. If niceFlag is true, the >> > ? ? ? ?background OS process runs at lowered scheduling priority." >> > >> > Dave >> > >> > >> > _______________________________________________ >> > Pharo-project mailing list >> > Pharo-project(a)lists.gforge.inria.fr >> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > >> >> >> >> -- >> Lukas Renggli >> 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 > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Lukas Renggli www.lukas-renggli.ch

July 23, 2010

Re: [Pharo-project] Another RB engine change

by Yanni Chiu

I don't use omnibrowser on Pharo-1.0, but I was still building it. See: http://hudson.jooshr.org/job/Pharo1.0-Seaside3.0/200/testReport/ I checked only a few of the stacktraces on the 404 newly failing tests, and they were all: SystemDictionary(Object)>>doesNotUnderstand: #globals Maybe the simplest thing to do is a maintenance patch to Pharo-1.0 with an implementation for Smalltalk>>globals. Lukas Renggli wrote: > I fixed that and about 30 other occurrences of the same problem. > > Name: Refactoring-Core-lr.147 > Author: lr > Time: 23 July 2010, 8:14:01 am > UUID: 8e608df4-579d-4a3d-a589-0eb90109275e > Ancestors: Refactoring-Core-lr.146 > > - fixed numerous occurrences where the old 'Smalltalk' was used > > Thank you for pointing out. > > Lukas > > On 23 July 2010 00:01, Fernando olivero <oliverof(a)lu.unisi.ch> wrote: >> Hi Lukas, here is another change in the RB engine package. >> >> RBClass>>realName: aSymbol >> self realClass: (Smalltalk at: aSymbol) >> >> => >> self realClass: (Smalltalk globals at: aSymbol) >> >> Fernando >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > >

July 23, 2010

Re: [Pharo-project] What is correct way to save image automatically in background?

by David T. Lewis

Yes, it really is true. That said, I would expect the practical impact to vary depending on how busy the main image is. If you are running a Squeak/Pharo image that is not busy, such as your own personal desktop image or a Seaside image that is not currently receiving requests, then the additional system memory used by the forked background image is extremely small (it's pretty amazing actually, try watching it on a system monitor such as xosview). However, I would expect that if you were to do this with a busy Seaside image, then that image would be doing a lot of updates to memory and possibly garbage collection, so that will force the OS to use more memory. Unfortunately this means that the busier your image is, the less benefit you get from a memory usage point of view. But even at that, you still get the advantage of doing the image save in a background OS process running at lower OS scheduling priority. I do not actually run any Seaside server images, so someone would need to try this on a real system to find out how much benefit it delivers in practice. I would be interested to know the results. Dave On Fri, Jul 23, 2010 at 02:12:14PM +0200, Lukas Renggli wrote: > David, is what is said about memory management really true? I thought > that saving the image triggered a garbage collect what forces to copy > the whole memory anyway. > > Lukas > > On 23 July 2010 14:00, David T. Lewis <lewis(a)mail.msen.com> wrote: > > On Fri, Jul 23, 2010 at 09:49:46AM +0200, Lukas Renggli wrote: > >> > But How I can do that without fork? I track changes in another process and > >> > when I do update I save image in this process. > >> > How I can initiate image saving from ui process? > >> > >> I don't understand what you are saying. > >> > >> The thing is that using #fork to save the image has no effect (other > >> than wrecking the image), because #snapshot:andQuit: is eventually > >> calling a primitive that locks the complete VM anyway. > >> > >> If you want to fork while saving the image you need to use an OS-level > >> fork, not a Smalltalk-level fork. You can do this with OSProcess for > >> example (check the Seaside mailing-list archive). > > > > "UnixProcess saveImageInBackgroundNicely" > > > > Explained in the method comment: > > > > UnixProcess class>>saveImageInBackground: savedImageName nice: niceFlag > > ? ? ? ?"When Squeak is used as a server it is sometimes desirable to periodically > > ? ? ? ?save image snapshots. This method forks a headless Squeak to perform a > > ? ? ? ?snapshot without impacting the server Squeak. Very little additional memory > > ? ? ? ?is required to do this because Unix copy-on-write memory management allows > > ? ? ? ?the two Squeak images to share object memory while the save is performed. > > ? ? ? ?The saved image is given a time stamped name, and the image name of > > ? ? ? ?the main server Squeak remains unchanged. If niceFlag is true, the > > ? ? ? ?background OS process runs at lowered scheduling priority." > > > > Dave > > > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > -- > Lukas Renggli > 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

July 23, 2010

Re: [Pharo-project] Literal array with evaluated value of stmts, vars etc..

by StÃ©phane Ducasse

On Jul 23, 2010, at 4:36 PM, Henrik Johansen wrote: > > On Jul 23, 2010, at 3:14 31PM, StÃ©phane Ducasse wrote: > >> ok not this is not what we have with MenuIcons? >> >> Stef > > A close cousin, I would say. Yes this is a distributed version. > Assets > - saves the need for the separate Contents/Icon methods and an Icons dictionary, due to once usage. > - utilizes pragma instead of method names/comments for imported file names, so you can rename your methods and still sync with the correct file. so the pragma are more for doing a rebuild. > - keeps an md5 hash, so you can update only those methods for which the on-disk resource has actually changed. what is the license? Stef > > 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 23, 2010

Re: [Pharo-project] Literal array with evaluated value of stmts, vars etc..

by Henrik Johansen

On Jul 23, 2010, at 3:14 31PM, StÃ©phane Ducasse wrote: > ok not this is not what we have with MenuIcons? > > Stef A close cousin, I would say. Assets - saves the need for the separate Contents/Icon methods and an Icons dictionary, due to once usage. - utilizes pragma instead of method names/comments for imported file names, so you can rename your methods and still sync with the correct file. - keeps an md5 hash, so you can update only those methods for which the on-disk resource has actually changed. Cheers, Henry

July 23, 2010

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

by Schwab,Wilhelm K

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. Firefox tells me that the encoding is ISO-8859-1; I am not leaving off the 5, Firefox and gedit report it differently. In fairness to gedit, I am reporting the encodings listed in its save-as dialog. Unfortunately the offending file contains specifications that are not mine. I have seen pieces of it published elsewhere (quite recently in fact) but will need to do some checking on the licensing. I might be able to excerpt the file and end up with the same behavior. Bill ________________________________________ 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 7:39 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Invalid utf8 input detected: now what? On Jul 23, 2010, at 4:09 30AM, Schwab,Wilhelm K wrote: > Hello all, > > I got an error (on Ubuntu 9.10) trying open an old text file that I created on Windows some time ago. The encoding (if gedit's save-as dialog can be trusted??) is Western ISO-8859-15; resaving as utf8 lets me read it. > > So, is Pharo working by design? Did I do the correct/only thing needed to read the file? What should I be asking? Is there anything I can do to turn this into a useful test/debugging example? > > Bill > This is not an error per se, seeing as the encoding is not utf8 :) If the import was done from some tool instead of in your code (in which case you'd set the encoding of the file stream), a nicer *behavior* might be for the UI Manager to catch encoding errors when trying to read a file, and offer up a dialogue with a list of encodings which the file *can* be read as, along with a preview window of what the text would look like with the selected encoding, like some word processors do. 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 23, 2010

Re: [Pharo-project] Literal array with evaluated value of stmts, vars etc..

by StÃ©phane Ducasse

ok not this is not what we have with MenuIcons? Stef On Jul 23, 2010, at 2:30 PM, Henrik Johansen wrote: > > On Jul 23, 2010, at 9:24 38AM, StÃ©phane Ducasse wrote: > >>> I really like Assets. The whole framework is small, flexible, useful and easy to understand. >> what is assets? >> >> Stef > > A really small and neat external resource-management framework in VisualWorks. > > Its relation to once is being the original use case. > > I've attached the class comment from VW, which explains how it works pretty well :) > <Assets.rtf> > > There's also this screencast, which shows off the RB integration, and caching speedup due to once use: > http://www.cincomsmalltalk.com/userblogs/travis/files/assetsOne.mov > and this blogpost, explaining once: > http://www.cincomsmalltalk.com/userblogs/travis/blogView?entry=3346567529 > > 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 23, 2010

Re: [Pharo-project] Literal array with evaluated value of stmts, vars etc..

by Henrik Johansen

On Jul 23, 2010, at 9:24 38AM, StÃ©phane Ducasse wrote: >> I really like Assets. The whole framework is small, flexible, useful and easy to understand. > what is assets? > > Stef A really small and neat external resource-management framework in VisualWorks. Its relation to once is being the original use case. I've attached the class comment from VW, which explains how it works pretty well :) There's also this screencast, which shows off the RB integration, and caching speedup due to once use: http://www.cincomsmalltalk.com/userblogs/travis/files/assetsOne.mov and this blogpost, explaining once: http://www.cincomsmalltalk.com/userblogs/travis/blogView?entry=3346567529 Cheers, Henry

July 23, 2010

Re: [Pharo-project] What is correct way to save image automatically in background?

by Lukas Renggli

David, is what is said about memory management really true? I thought that saving the image triggered a garbage collect what forces to copy the whole memory anyway. Lukas On 23 July 2010 14:00, David T. Lewis <lewis(a)mail.msen.com> wrote: > On Fri, Jul 23, 2010 at 09:49:46AM +0200, Lukas Renggli wrote: >> > But How I can do that without fork? I track changes in another process and >> > when I do update I save image in this process. >> > How I can initiate image saving from ui process? >> >> I don't understand what you are saying. >> >> The thing is that using #fork to save the image has no effect (other >> than wrecking the image), because #snapshot:andQuit: is eventually >> calling a primitive that locks the complete VM anyway. >> >> If you want to fork while saving the image you need to use an OS-level >> fork, not a Smalltalk-level fork. You can do this with OSProcess for >> example (check the Seaside mailing-list archive). > > "UnixProcess saveImageInBackgroundNicely" > > Explained in the method comment: > > UnixProcess class>>saveImageInBackground: savedImageName nice: niceFlag > Â Â Â Â "When Squeak is used as a server it is sometimes desirable to periodically > Â Â Â Â save image snapshots. This method forks a headless Squeak to perform a > Â Â Â Â snapshot without impacting the server Squeak. Very little additional memory > Â Â Â Â is required to do this because Unix copy-on-write memory management allows > Â Â Â Â the two Squeak images to share object memory while the save is performed. > Â Â Â Â The saved image is given a time stamped name, and the image name of > Â Â Â Â the main server Squeak remains unchanged. If niceFlag is true, the > Â Â Â Â background OS process runs at lowered scheduling priority." > > Dave > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Lukas Renggli www.lukas-renggli.ch

July 23, 2010

Re: [Pharo-project] What is correct way to save image automatically in background?

by David T. Lewis

On Fri, Jul 23, 2010 at 09:49:46AM +0200, Lukas Renggli wrote: > > But How I can do that without fork? I track changes in another process and > > when I do update I save image in this process. > > How I can initiate image saving from ui process? > > I don't understand what you are saying. > > The thing is that using #fork to save the image has no effect (other > than wrecking the image), because #snapshot:andQuit: is eventually > calling a primitive that locks the complete VM anyway. > > If you want to fork while saving the image you need to use an OS-level > fork, not a Smalltalk-level fork. You can do this with OSProcess for > example (check the Seaside mailing-list archive). "UnixProcess saveImageInBackgroundNicely" Explained in the method comment: UnixProcess class>>saveImageInBackground: savedImageName nice: niceFlag "When Squeak is used as a server it is sometimes desirable to periodically save image snapshots. This method forks a headless Squeak to perform a snapshot without impacting the server Squeak. Very little additional memory is required to do this because Unix copy-on-write memory management allows the two Squeak images to share object memory while the save is performed. The saved image is given a time stamped name, and the image name of the main server Squeak remains unchanged. If niceFlag is true, the background OS process runs at lowered scheduling priority." Dave

July 23, 2010

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

by Henrik Johansen

On Jul 23, 2010, at 4:09 30AM, Schwab,Wilhelm K wrote: > Hello all, > > I got an error (on Ubuntu 9.10) trying open an old text file that I created on Windows some time ago. The encoding (if gedit's save-as dialog can be trusted??) is Western ISO-8859-15; resaving as utf8 lets me read it. > > So, is Pharo working by design? Did I do the correct/only thing needed to read the file? What should I be asking? Is there anything I can do to turn this into a useful test/debugging example? > > Bill > This is not an error per se, seeing as the encoding is not utf8 :) If the import was done from some tool instead of in your code (in which case you'd set the encoding of the file stream), a nicer *behavior* might be for the UI Manager to catch encoding errors when trying to read a file, and offer up a dialogue with a list of encodings which the file *can* be read as, along with a preview window of what the text would look like with the selected encoding, like some word processors do. Cheers, Henry

July 23, 2010

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

by Philippe Marschall

On 07/23/2010 04:09 AM, Schwab,Wilhelm K wrote: > Hello all, > > I got an error (on Ubuntu 9.10) trying open an old text file that I created on Windows some time ago. The encoding (if gedit's save-as dialog can be trusted??) is Western ISO-8859-15; resaving as utf8 lets me read it. > > So, is Pharo working by design? Did I do the correct/only thing needed to read the file? You need to pass the encoding to the file stream. Cheers Philippe

July 23, 2010

[Pharo-project] [update 1.2] #12064

by StÃ©phane Ducasse

12064 ----- - Issue 2711: SmartRefStream (and hence also ImageSegment) are broken due to missing #convertToCurrentVersion:refStream:

July 23, 2010

Re: [Pharo-project] About validating the result of RBParser >> parseMethod:

by Lukas Renggli

On 23 July 2010 11:58, Fernando olivero <oliverof(a)lu.unisi.ch> wrote: > Thanks for the pointers Lukas, > > Works now! > >>>canSuccesfullyParse: aSource in: aClass > Â Â Â Â [ parsedNode := RBParser parseMethod: aSource onError: [:descrip :position| evaluation := false. errorDescription := descrip. errorPosition := position ] ] on: Error do:[:err| Â ]. > Â Â Â Â parsedNode annotateInClass: aClass. > Â Â Â Â hasUndeclared := parsedNode allChildren select:[:each| each isVariable and:[ each variableBinding isUndeclaredBinding Â ]] . > Â Â Â Â hasUndeclared ifTrue:[ self .... ]. Yep, something like that. You shouldn't need the Error handler, otherwise that would be a bug in the RBParser. Also you might want to check for shadowed variables (#isShadowed), because they cause the compiler to complain. Lukas -- Lukas Renggli www.lukas-renggli.ch

July 23, 2010

Re: [Pharo-project] About validating the result of RBParser >> parseMethod:

by Lukas Renggli

Unfortunately the NewCompiler doesn't work yet. On 23 July 2010 11:46, Fernando olivero <oliverof(a)lu.unisi.ch> wrote: > Lukas, thanks for the answer. I will see if AST-Semantics solves my problem. > > I also tried using the Compiler and the parser, and faking a notifier. But the Compiler>>interactive behavior is hard to override, > it always gives me visual feedback ( pop menus and related dialogs). Maybe the newCompiler is more customizable? > > Fernando > > > On Jul 23, 2010, at 7:34 AM, Lukas Renggli wrote: > >> You can use #parseMethod:onError: to check for syntactical errors. >> >> Semantical errors are harder to detect, some of them (e.g. undeclared >> variables) you can find using AST-Semantics. >> >> Lukas >> >> On 23 July 2010 00:35, Fernando olivero <oliverof(a)lu.unisi.ch> wrote: >>> I have a question about validating a methodNode, suppose we have the following: >>> >>> parsedNode := Â RBParser parseMethod: 'test ^ self add: anUnbindedVariable'. >>> >>> Is there a way of checking the health/validity of the parsedNode? >>> >>> I couldn't find any behavior in RBMethodNode or related classes. >>> >>> Lukas, do you have an idea is i could run any Lint rule? >>> >>> My idea is to provide a method editor morph, that prevents from accepting invalid sources, and informs the user any problems detected with the edited code. >>> >>> Thanks, >>> Fernando >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> >> -- >> Lukas Renggli >> 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 > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Lukas Renggli www.lukas-renggli.ch

July 23, 2010

Re: [Pharo-project] About validating the result of RBParser >> parseMethod:

by Fernando olivero

Thanks for the pointers Lukas, Works now! >>canSuccesfullyParse: aSource in: aClass [ parsedNode := RBParser parseMethod: aSource onError: [:descrip :position| evaluation := false. errorDescription := descrip. errorPosition := position ] ] on: Error do:[:err| ]. parsedNode annotateInClass: aClass. hasUndeclared := parsedNode allChildren select:[:each| each isVariable and:[ each variableBinding isUndeclaredBinding ]] . hasUndeclared ifTrue:[ self .... ]. On Jul 23, 2010, at 11:46 AM, Fernando olivero wrote: > Lukas, thanks for the answer. I will see if AST-Semantics solves my problem. > > I also tried using the Compiler and the parser, and faking a notifier. But the Compiler>>interactive behavior is hard to override, > it always gives me visual feedback ( pop menus and related dialogs). Maybe the newCompiler is more customizable? > > Fernando > > > On Jul 23, 2010, at 7:34 AM, Lukas Renggli wrote: > >> You can use #parseMethod:onError: to check for syntactical errors. >> >> Semantical errors are harder to detect, some of them (e.g. undeclared >> variables) you can find using AST-Semantics. >> >> Lukas >> >> On 23 July 2010 00:35, Fernando olivero <oliverof(a)lu.unisi.ch> wrote: >>> I have a question about validating a methodNode, suppose we have the following: >>> >>> parsedNode := RBParser parseMethod: 'test ^ self add: anUnbindedVariable'. >>> >>> Is there a way of checking the health/validity of the parsedNode? >>> >>> I couldn't find any behavior in RBMethodNode or related classes. >>> >>> Lukas, do you have an idea is i could run any Lint rule? >>> >>> My idea is to provide a method editor morph, that prevents from accepting invalid sources, and informs the user any problems detected with the edited code. >>> >>> Thanks, >>> Fernando >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> >> -- >> Lukas Renggli >> 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 > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

July 23, 2010

Re: [Pharo-project] About validating the result of RBParser >> parseMethod:

by Fernando olivero

Lukas, thanks for the answer. I will see if AST-Semantics solves my problem. I also tried using the Compiler and the parser, and faking a notifier. But the Compiler>>interactive behavior is hard to override, it always gives me visual feedback ( pop menus and related dialogs). Maybe the newCompiler is more customizable? Fernando On Jul 23, 2010, at 7:34 AM, Lukas Renggli wrote: > You can use #parseMethod:onError: to check for syntactical errors. > > Semantical errors are harder to detect, some of them (e.g. undeclared > variables) you can find using AST-Semantics. > > Lukas > > On 23 July 2010 00:35, Fernando olivero <oliverof(a)lu.unisi.ch> wrote: >> I have a question about validating a methodNode, suppose we have the following: >> >> parsedNode := RBParser parseMethod: 'test ^ self add: anUnbindedVariable'. >> >> Is there a way of checking the health/validity of the parsedNode? >> >> I couldn't find any behavior in RBMethodNode or related classes. >> >> Lukas, do you have an idea is i could run any Lint rule? >> >> My idea is to provide a method editor morph, that prevents from accepting invalid sources, and informs the user any problems detected with the edited code. >> >> Thanks, >> Fernando >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Lukas Renggli > 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

July 23, 2010

Re: [Pharo-project] State of Sound in Morph

by StÃ©phane Ducasse

yes it is but I show you where it came from. so may be we messed up a bit:) Stef On Jul 23, 2010, at 10:34 AM, Hilaire Fernandes wrote: > Le 23/07/2010 10:23, StÃ©phane Ducasse a Ã©crit : >> >> On Jul 23, 2010, at 9:14 AM, Hilaire Fernandes wrote: >> >>> Thanks guys for your feedback, I will make the necessary changes in the >>> package. I have also applied the changes to sound from the Squeak friends. >>> >>> By the way, I wonder if the sound package should not be cut in two >>> package, one related to sound synthesis and the other to morph stuff. >> >> >> but I thought I already did that so may be you are editing the old versions. >> Can you check? >> the packages came from >> http://www.squeaksource.com/PharoSound/ >> and you see that we split it already >> >> We should really improve our traceability. >> We should really get more metacello desription and have a way to mark things as obsolete > > > Euh... is not in PharoNonCorePackages repository ? > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

July 23, 2010

Re: [Pharo-project] State of Sound in Morph

by Hilaire Fernandes

Le 23/07/2010 10:23, StÃ©phane Ducasse a Ã©crit : > > On Jul 23, 2010, at 9:14 AM, Hilaire Fernandes wrote: > >> Thanks guys for your feedback, I will make the necessary changes in the >> package. I have also applied the changes to sound from the Squeak friends. >> >> By the way, I wonder if the sound package should not be cut in two >> package, one related to sound synthesis and the other to morph stuff. > > > but I thought I already did that so may be you are editing the old versions. > Can you check? > the packages came from > http://www.squeaksource.com/PharoSound/ > and you see that we split it already > > We should really improve our traceability. > We should really get more metacello desription and have a way to mark things as obsolete Euh... is not in PharoNonCorePackages repository ?

July 23, 2010

Re: [Pharo-project] State of Sound in Morph

by StÃ©phane Ducasse

On Jul 23, 2010, at 9:51 AM, Hilaire Fernandes wrote: > Now I don't know what is the state of affaire regarding > enabling/unenabling sounds from the Setting browser. It looks like the > sound option in the Setting browser has not action. > It looks like a specific Process is used to play sound, right? > SoundPLayer initialize. Should we add a setting in the preference for > that purpose? probably we should also check that there is no preferences left and only setting > > Hilaire > > > Le 23/07/2010 09:14, Hilaire Fernandes a Ã©crit : >> Thanks guys for your feedback, I will make the necessary changes in the >> package. I have also applied the changes to sound from the Squeak friends. > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

July 23, 2010

Re: [Pharo-project] State of Sound in Morph

by StÃ©phane Ducasse

On Jul 23, 2010, at 9:14 AM, Hilaire Fernandes wrote: > Thanks guys for your feedback, I will make the necessary changes in the > package. I have also applied the changes to sound from the Squeak friends. > > By the way, I wonder if the sound package should not be cut in two > package, one related to sound synthesis and the other to morph stuff. but I thought I already did that so may be you are editing the old versions. Can you check? the packages came from http://www.squeaksource.com/PharoSound/ and you see that we split it already We should really improve our traceability. We should really get more metacello desription and have a way to mark things as obsolete

July 23, 2010