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

Re: [Pharo-project] Issue 670: Should clean Morph menu

by Guillermo Polito

I left in the inbox a little change. I'm not sure what are the obvious entries to remove (because I only use delete :$ :P), so I removed the ones Stephane remarked. Cheers, Guille --------------------------------------------------------------------- Name: Morphic-GuillermoPolito.592 Author: GuillermoPolito Time: 4 June 2010, 12:39:30 pm UUID: 73282bb3-db42-ac4f-9139-b7725319a741 Ancestors: Morphic-GuillermoPolito.591 removed from morph menu the entries: submorphs browse hierarchy attach to resource call #tempCommand define #tempCommand --------------------------------------------------------------------- On Sun, May 30, 2010 at 5:11 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > I would start removing some of the them: the obvious one :) > or the ones I marked > > > > I take this thread back to life. Is everyone happy with this menu? Is It > useful? :P > > > > On Wed, May 26, 2010 at 6:59 AM, StÃ©phane Ducasse < > stephane.ducasse(a)inria.fr> wrote: > > magic of morphic :) > > > > Stef > > > > On May 26, 2010, at 11:29 AM, Gary Chambers wrote: > > > > > Well, even if a morph does not, at any one time, use a table layout the > settings are preserved and use if switched to a table layout... > > > > > > Curiously these options are pretty much the only ones I use from the > menu ;-) > > > > > > > > > Regards, Gary > > > ----- Original Message ----- > > > From: Carla F. Griggio > > > To: Pharo-project(a)lists.gforge.inria.fr > > > Sent: Tuesday, May 25, 2010 10:25 PM > > > Subject: Re: [Pharo-project] Issue 670: Should clean Morph menu > > > > > > Well, I haven't tried all those actions, but if it helps in any way, > the ones I usually use are: > > > > > > grab > > > delete > > > copy text > > > submorphs > > > inspect > > > show actions > > > debug-> > > > inspect morph > > > inspect model > > > browse morph class > > > browse model class > > > > > > > > > > > > I don't see what the layout options do. I don't know much about > layouts, so maybe this doesn't make sense, but... shouldn't the options for > table layout be available only if the morph I'm dealing with has a table > layout? > > > > > > > > > > > > On Tue, May 25, 2010 at 5:58 PM, StÃ©phane Ducasse < > stephane.ducasse(a)inria.fr> wrote: > > > **EXCELLENT** > > > truly excellent > > > Yes we try to sort that and get some cleaning. > > > > > > > grab > > > > copy to paste buffer > > > > collapse > > > > delete > > > > copy text > > > > go behind > > > > add halo > > > > duplicate > > > > embed into-> > > > > PasteUpMorph > > > > SystemWindow > > > > resize > > > > change color... > > > > drop shadow-> > > > > show shadow > > > > shadow color... > > > > shadow offset... > > > > layout-> > > > > no layout > > > > proportional layout > > > > table layout > > > > change layout inset... > > > > child layout-> > > > > disable layout in tables > > > > horizontal resizing-> > > > > rigid > > > > shrink wrap > > > > space fill > > > > vertical resizing-> > > > > rigid > > > > shrink wrap > > > > space fill > > > > table layout-> > > > > reverse table cells > > > > clip to cell size > > > > rubber band cells > > > > change cell inset... > > > > change min cell size... > > > > change max cell size... > > > > list direction-> > > > > ... > > > > wrap direction-> > > > > ... > > > > cell positioning-> > > > > ... > > > > list centering-> > > > > ... > > > > wrap centering-> > > > > ... > > > > list spacing-> > > > > ... > > > > cell spacing-> > > > > ... > > > > provide clipping > > > > submorphs > > > ?? > > > > > > > inspect > > > > explore > > > > > > > browse hierarchy > > > ?? > > > > > > > save morph in file > > > > attach to resource > > > ?? > > > > > > > show actions > > > > debug-> > > > > inspect morph > > > > inspect owner chain > > > > inspect model > > > > explore morph > > > > browse morph class > > > > browse model class > > > > explore view hierarchy > > > > call #tempCommand > > > ?? > > > > define #tempCommand > > > ?? > > > > > > > open editing > > > > edit label... > > > > > > > > Cheers, > > > > Guille > > > > _______________________________________________ > > > > Pharo-project mailing list > > > > Pharo-project(a)lists.gforge.inria.fr > > > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > > > > _______________________________________________ > > > Pharo-project mailing list > > > Pharo-project(a)lists.gforge.inria.fr > > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > > > > > > > _______________________________________________ > > > Pharo-project mailing list > > > Pharo-project(a)lists.gforge.inria.fr > > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > > > Pharo-project mailing list > > > Pharo-project(a)lists.gforge.inria.fr > > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

June 4, 2010

[Pharo-project] Changes aren't saved in the default (unnamed) changeset on a new image

by Guillermo Polito

Hi! I'm using the develop Pharo-1.1-11367-Beta on windows. When I make a change with a fresh image, that change isn't saved in the default changeset :(. In the Core image it's just ok. Is it a bug or a 'feature'? Cheers, Guille

June 4, 2010

Re: [Pharo-project] The Morphic 3 project

by Juan Vuletich

Igor Stasenko wrote: > On 2 June 2010 15:16, Juan Vuletich <juan(a)jvuletich.org> wrote: > >> Lukas Renggli wrote: >> >>> Hi Juan, >>> >>> This looks really exiting! >>> >>> How do you get the actual pixels drawn? Is this implemented in >>> Smalltalk? Did you write primitives to do that? Are you using external >>> libraries? How does it compare performance wise with the current >>> rendering? >>> >>> Lukas >>> >>> >>> >> Hi Lukas, >> >> I'm glad you like it. It is all done in Smalltalk. There are no external >> libraries. In fact, I developed new drawing algorithms that are better than >> those in Cairo, AGG, etc. So there are no libraries in existence I could >> call! >> >> The sampling theorem is about 80 years old. It is the base (together with >> Fourier analysis) of most of the DSP (Digital Signal Processing) field. It >> is therefore the basis of digital audio and photography. But it seems I am >> the first one to apply it to 2d rendering! I have been working on this for >> the last 3 years, after finishing my Ms.Sc. in CS on Image and Signal >> Processing. I had to establish the theoretical foundations, and come up with >> new algorithms to draw basic elements using this theory. What you see are >> the first practical result of all this work. >> >> It is still pure Smalltalk, and therefore, a bit slow. The lion takes 1.8 >> secs to draw on my 1.6GHz Mac mini. I am still changing the code a lot, but >> when it stabilizes I'll do a VM plugin. I guess it would be about 100 times >> faster. The other option is to use Igor's NativeBoost. That could perhaps be >> 10 times faster than the plugin, at the cost of portability and hand written >> asm (I'd done lots of asm in a previous life). >> >> > > Last year i built an SVG API bindings. And i were able to render the Tiger > at screen refresh rate (65Hz). The rendering throughput is even higher > than that, > but it looks like SVG implementation limits the frame rate to screen > refresh rate as maximum :) > > Sure thing, the quality is not that high as yours, > but still, it shows how much speed-up we could achieve, if we put all > processing on > GPU side. > > It would be cool if we could cooperate and implement this stuff using > OpenGL as backend Indeed. Although I wonder if OpenGL is general enough to implement it... I mean, the only standard operation I do is to blend pixels... Everything else is done with new algorithms. Without being an OpenGL expert, I believe that CUDA / OpenCL would be better suited. Cheers, Juan Vuletich

June 4, 2010

[Pharo-project] Little "bug" when browsing classes from TestRunner

by Mariano Martinez Peck

Hi folks. If this is a bug, is very very little, but just in case. When you open a TestRunner, you can select a particular class -> right button -> browse and it opens a browser with it. However, it does not happen the same if you do the following: - You open a Test Runner - Select a particular package, for example, Gofer-Tests which has 4 classes. - Press left click and holding it select the four tests. - Now, press left click again and holding it, deselect all test but the first one. - Now, only the first test should be gray. But if you do right button -> browse, nothing happens. It seems the test is not like selected, although it is gray. In addition, if you click again to that class, it will be unselected. Click again, it will be selected. There, you can browse it. Tested in PharoDev and Core. Cheers Mariano

June 4, 2010

Re: [Pharo-project] About TDD and Pharo

by StÃ©phane Ducasse

he implemented Mockery for dolphin I guess and he is in pharo mailing-list probably flooded by mails :) On Jun 3, 2010, at 9:06 AM, Denis Kudriashov wrote: > Hello, No I dont. Who is it? > > 2010/6/3 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > do you happen to know tim mckinnon? > > Stef > On Jun 3, 2010, at 12:13 AM, Denis Kudriashov wrote: > > > I use Mockery - my implementation SSpec idies. It is realy more powerfull, transparency and flexibility. > > > > With Mockery you dont need any special base classes for TestCases or mocks factory variables in code. You just use mocks where you want by Block creation scenarios: > > > > [:mock | > > [sut doWith: mock] should lenient satisfy: [mock someMessage willReturn: #result] > > ] runScenario. > > > > State specs like "5 should be an instance of: Integer" can be easely added by pragmas. > > > > And Its work in Pharo 1.0. > > > > Of course, It's needs more good stuff. But now I dont have enough time. > > http://www.squeaksource.com/Mocketry.html > > > > 2010/6/3 Sean P. DeNigris <sean(a)clipperadams.com> > > > > > > StÃ©phane Ducasse wrote: > > > > > > Imagine that we would like to sell pharo (+ seaside) as THE agile platform > > > for doing TDD. > > > What would be the changes that we could do support it. > > > > > > > Coming from Ruby, it seemed like BDD was taking over the world, and was the > > next step in TDD evolution, but I found few mentions of it in the Squeak > > world. For my own projects, I use SSpec (which I have been fixing as I go > > along). I only use "tests" with SUnit assertions for community projects, as > > not to confuse or add additional dependencies. > > > > I think that core BDD support would be necessary to woo developers here, > > especially from Ruby, where all the passion and conversation is around BDD. > > > > Sean > > -- > > View this message in context: http://forum.world.st/About-TDD-and-Pharo-tp2240686p2240877.html > > Sent from the Pharo Smalltalk mailing list archive at Nabble.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

June 4, 2010

Re: [Pharo-project] Multiple Worlds (was Re: Can I use Projects in Pharo?)

by StÃ©phane Ducasse

I really like the idea that your tried. I tried in 1.1 and I got a beWorldForProject: is not understood. But continue this sounds interesting. and may be this is what people needs. On Jun 3, 2010, at 9:11 PM, Jochen Riekhof wrote: > JRWorldManager instance createOrSwitchToWorldNamed: 'JustAnotherWorld'.

June 4, 2010

Re: [Pharo-project] [squeak-dev] Re: SUnit Time out

by Hernan Wilkinson

I completely agree On Sun, May 30, 2010 at 2:52 PM, Chris Muller <asqueaker(a)gmail.com> wrote: > (Copying squeak-dev too). > > I'm not sold on the whole test timeout thing. When I run tests, I > want to know the answer to the question, "is the software working?" > > Putting a timeout on tests trades a slower, but definitive, "yes" or > "no" for a supposedly-faster "maybe". But is getting a "maybe" back > really faster? I've just incurred the cost of running a test suite, > but left without my answer. I get a "maybe", what am I supposed to do > next? Find a faster machine? Hack into the code to fiddle with a > timeout pragma? That's not faster.. > > But, the reason given for the change was not for running tests > interactively (the 99% case), rather, all tests form the beginning of > time are now saddled with a timeout for the 1% case: > > "The purpose of the timeout is to catch issues like infinite loops, > unexpected user input etc. in automated test environments." > > If tests are supposed to be quick (and deterministic) anyway, wouldn't > an infinite loop or user-input be caught the first time the test was > run (interactively)? Seriously, when you make software changes, we > run the tests interactively first, and then the purpose of night-time > automated test environment is to catch regressions on the merged > code.. > > In that case, the high-level test-controller which spits out the > results could and should be responsible for handling "unexpected user > input" and/or putting in a timeout, not each and every last test > method.. > > IMO, we want short tests, so let's just write them to be short. If > they're too long, then the encouragement to shorten them comes from > our own impatience of running them interactively. Running them in > batch at night requires no patience, because we're sleeping, and > besides, the batch processor should take responsibility for handling > those rare scenarios at a higher-level.. > > Regards, > Chris > > > On Sat, May 29, 2010 at 2:53 AM, stephane ducasse > <stephane.ducasse(a)free.fr> wrote: > > Hi guys > > > > in Squeak andreas introduced the idea of test time out > > Do you think that this is interesting? > > > > Stef > > > > SUnit > > ----- > > All test cases now have an associated timeout after which the test is > considered failed. The purpose of the timeout is to catch issues like > infinite loops, unexpected user input etc. in automated test environments. > Timeouts can be set on an individual test basis using the <timeout: seconds> > tag or for an entire test case by implementing the #defaultTimeout method. > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > >

June 4, 2010

Re: [Pharo-project] SUnit Time out

by Hernan Wilkinson

I dont think it is a necessary... I mean, if you are doing TDD, you write the test and you run it inmediatly, if it takes too much time to run (that is, more than 2 seconds :-)) then you press ctrl+ . and problem solved... I'm saying this because the should:notTakeMoreThan: has some interesting implementation details, like running the test in another process and synchronizing them, etc... so running all the test would create a process for each test, etc. tacking more time unnecessarily in most of the cases... unless the implementation takes care of only doing this special "feature" when needed (for example, when you have that pragma) but the, if you have to write the pragma why not just send the message #should:notTakeMoreThan: and problem solved? On Sat, May 29, 2010 at 3:42 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > For me the point is that I have the impression that this is an interesting > feature to have > when we have a test server. Like that you make sure that you do not have > tests with infinite recursion > now this is also true that on a test server you do not really care if your > tests take 30s or 2 min. > > Stef > > > We already have #should:notTakeMoreThan: and friends in TestCase. The > > complete TestCase can be protected by overriding #runCase, the > > individual test by wrapping the code of the test method. > > > > Lukas > > > > On 29 May 2010 16:43, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: > >> Stef, > >> > >> Time to expose some of my ignorance (don't worry, I have plenty more > waiting where I found this): what is the tag concept? That sounds very > Tweak-ish, and I am a real believer in doing things "with the language, not > TO the language" whenever possible. That is not to say that frameworks are > bad; in fact, it means that frameworks are good, language extensions are > anywhere from suspect to evil. > >> > >> I have some code that I am still porting, but the basic idea is to be > able to write > >> > >> [ > >> "code that might not complete" > >> > >> ] tryForSeconds:10 onTimeOut:[ > >> > >> ]. > >> > >> With a robust capability to do such things, it is probably not necessary > (or even appropriate) for TestCase to enforce timeouts. The timeout block > can simply raise an exception or assert false, and there is no need to > disable timeouts where they do not belong. > >> > >> Bill > >> > >> ________________________________________ > >> From: pharo-project-bounces(a)lists.gforge.inria.fr [ > pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Michael Roberts > [mike(a)mjr104.co.uk] > >> Sent: Saturday, May 29, 2010 6:17 AM > >> To: Pharo-project(a)lists.gforge.inria.fr > >> Subject: Re: [Pharo-project] SUnit Time out > >> > >> yes think it's a good idea. I'm not sure the granularity that's > >> required though. > >> > >> mike > >> > >> On Saturday, May 29, 2010, stephane ducasse <stephane.ducasse(a)free.fr> > wrote: > >>> Hi guys > >>> > >>> in Squeak andreas introduced the idea of test time out > >>> Do you think that this is interesting? > >>> > >>> Stef > >>> > >>> SUnit > >>> ----- > >>> All test cases now have an associated timeout after which the test is > considered failed. The purpose of the timeout is to catch issues like > infinite loops, unexpected user input etc. in automated test environments. > Timeouts can be set on an individual test basis using the <timeout: seconds> > tag or for an entire test case by implementing the #defaultTimeout method. > >>> _______________________________________________ > >>> 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 > > > > _______________________________________________ > > 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 >

June 4, 2010

Re: [Pharo-project] About TDD and Pharo

by Lukas Renggli

> I have some questions... if you are writting a test in the browser and want > to run it (just test), if you press ctr+t, does it run that test or all the > tests? and also, if it does not save the method, how does it run the test > you just wrote ? It runs just the selected test method. If you have not accepted the change it runs the old compiled code (as it would for a do-it). > I did the ctrl+t do the save before running because I found myself saving > then running, saving then running, etc, all the time... and if you want to > run the test you have to save it before... why do you think you would not > like the two things combined? do you see something that could bother or be > wrong about it? Consistency with the rest of the browser and separation of concerns. But, I haven't tried your approach so I cannot really tell what is better. Jorge demoed your debugger changes (create class, create method). I would like to see them in PharoCore. Also I would like to get rid of the pre-debugger all-together. Do you think that you could provide these changes in the PharoInbox? Lukas -- Lukas Renggli www.lukas-renggli.ch

June 4, 2010

Re: [Pharo-project] About TDD and Pharo

by Lukas Renggli

Name: OB-SUnitIntegration-lr.30 Author: lr Time: 4 June 2010, 1:24:05 pm UUID: cc0a4ad4-3efc-4dbc-8e44-0dc27e9d5f57 Ancestors: OB-SUnitIntegration-lr.29 - say 'run test' (singular) if there is a single test selected 2010/6/4 Mariano Martinez Peck <marianopeck(a)gmail.com>: > > > On Fri, Jun 4, 2010 at 10:40 AM, Lukas Renggli <renggli(a)gmail.com> wrote: >> >> >> > 1) When you are in the browser writing a test method, you can press >> >> > ctrl >> >> > + t >> >> > to save the method and run the test. If the test runs, it will show >> >> > the >> >> > green dot in the browser, if it does not, it popups the debugger >> >> > directly on >> >> > the error. So, this is a way to avoid pressing ctrl + s (save) then >> >> > going to >> >> > the method list, rigth click an select run test and if it fails >> >> > select >> >> > that >> >> > you want to debug it. >> >> >> >> Ctrl+T does not save, but it runs the tests and shows the debugger. I >> >> don't think that I like the two things to be combined :-) >> > >> > That's what I don't like, ctrl + t runs all the tests of the class, not >> > only >> > the method were you are. >> >> No, this is not the case. > > Ups...spoke faster than speaking. It's true, Pharo 1.1 with the latests OB > it works as expected. > Can we just change the label "run tests" to "run test"Â ? > > Thanks lukas > > mariano > > >> >> > This was discussed with Adrian Kuhn and he integrated this change in his >> > package. I don't know where is it neither if it was integrated or not. >> >> Yes, I integrated that a year ago or so :-) >> >> 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 > > > _______________________________________________ > 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

June 4, 2010