- Pharo-dev - lists.pharo.org

[Pharo-project] Help and Prof. Stef browsers

by Schwab,Wilhelm K

Hello all, In prodding the 1.1 beta, I noted the help and Prof Stef browsers. Is there any tutorial information on how they were built? They do some very useful things (splitters, layout, trees) and deserve careful study. Bill

June 1, 2010

[Pharo-project] Masked text field input?

by Denis Kudriashov

Is anybody implement masked text field input?

June 1, 2010

Re: [Pharo-project] Using WebClient

by Schwab,Wilhelm K

You can do a simple "man in the middle attack" on yourself. One approach would be to set up your own web server, serve the page with the form to a "real" browser and see what it sends when you submit the form. There is probably also a way to do it with a proxy of some sort, either off the shelf or one you write to log traffic both ways, and then you quickly get a picture of how the conversation works. A network sniffer might be another option. I have had to do things like this with either network or serial port traffic at various times. A few years back, an engineer with a medical device manufacturer was late delivering something that we happened to need at a time that was inconvenient for him. The solution: blame the confusion on the customer (me), of course, and hope that he could later give us something that might make things "easier" on us (which would be a working version of their new software). It got pretty ridiculous shortly before he had to admit that it didn't work. The funny thing was that their demo program for the "new protocol" was using something that looked exactly like the old one :) I was able to show that because I wrote a replacement for their device and connected their program to it: it was obviously not doing what he was claiming. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of GermÃ¡n Arduino [garduino(a)gmail.com] Sent: Monday, May 31, 2010 1:39 PM To: Pharo-project(a)lists.gforge.inria.fr Cc: The general-purpose Squeak developers list Subject: Re: [Pharo-project] Using WebClient Talking of post method, I tried to capture it with Firebug to understand what data post with WebClient, but no way until now. Exist some trick to obtain the exact content of the data to post only debuggin the web page? Cheers. 2010/5/29 GermÃ¡n Arduino <garduino(a)gmail.com>: > I think that is a post method in this case, but can't make it work (yet). > > 2010/5/29 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>: >> It's been a long time, but won't the button cause the browser to send a post or get (whichever action is specified in the form) to the server? It might be enough to decide the content of that and send it over the socket. I am probably thinking in CGI terms, which might not be what you need. >> >> >> ________________________________________ >> From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of StÃ©phane Ducasse [stephane.ducasse(a)inria.fr] >> Sent: Saturday, May 29, 2010 4:14 PM >> To: Pharo-project(a)lists.gforge.inria.fr >> Subject: Re: [Pharo-project] Using WebClient >> >> if you get answers from squeak-dev let us know. >> >> >> Stef >> >> >> On May 29, 2010, at 10:02 PM, GermÃ¡n Arduino wrote: >> >>> Hi: >>> >>> I'm trying to automate some operations on a web page that requires >>> authentication. >>> >>> I managed to arrive to the form that I need to process, authenticated >>> without problems. >>> >>> But I can't figure out how to process the button (is a button of this type: >>> >>> <input class="lButton" style="" name="submit_search" >>> value="Create File" type="submit"> ) to execute the Create File action. >>> >>> The form have two dates (that I can calculate and fill in) but I can't >>> to imagine how to process the submit button programmatically. >>> >>> Any hint will be appreciated. >>> >>> Cheers. >>> >>> -- >>> ================================================= >>> GermÃ¡n S. Arduino <gsa @ arsol.net> Twitter: garduino >>> Arduino Software & Web Hosting http://www.arduinosoftware.com >>> PasswordsPro http://www.passwordspro.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 >> > > > > -- > ================================================= > GermÃ¡n S. Arduino <gsa @ arsol.net> Twitter: garduino > Arduino Software & Web Hosting http://www.arduinosoftware.com > PasswordsPro http://www.passwordspro.com > ================================================= > _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

June 1, 2010

Re: [Pharo-project] SUnit Time out

by Chris Muller

> In other words, the timeout has the advantage to turn a rather > implicit requirement into an explicit requirement. I can almost understand it for this, especially in the context of development within an open source community. Unfortunately, it neuters the deterministic property. Did it timeout because it was stuck in a loop or was the Integrator watching a video while the tests were running, causing a couple of them to timeout? That's an obfuscation that is not quick and easy to see through. And why will someone, someday, have to work their way through this sort of opaque obfuscation? Merely because we imposed a design-time constraint on ourselves, like working in static language. The result of working through it most likely will be a new package version that merely bumps the timeout, hurling us backward toward the present; because the test suite is allowed to run longer, and longer.. > And it's then up to test producers to fine tune their tests wrt this > requirement or use the available hooks in case of long tests, rather > than letting the integrator guess. It's very possible this is another case of me just not seeing or understanding the key point. Exploratory package testing? Integrator doesn't have time to "fine tune"? I must admit, my feelings about it are more visceral than logical nature. However this timeout breaks all long-running legacy tests. I intend to make the default timeout be a global preference in Squeak. From there I will wait and see quietly.. Regards, Chris On Mon, May 31, 2010 at 5:16 AM, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > 2010/5/31 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: >> 2010/5/30 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>> >>> On May 30, 2010, at 8:52 PM, Chris Muller 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.. >>> >>> Thanks this is a really good point. >>> >>>> 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.. >>> >>> Yes this is what I was also implying in my previous mail. >>> If we have a test server this does not really help to have a time out >>> and I wonder the case of infinite loop because this may be really rare. >>> >> >> My opinion differs here. Every test should run in a short time frame >> but a few exceptions. So it seems reasonnable to just have to specify >> a default timeout on your architecture and some specific timeouts for >> a few specific tests (or test classes). >> >> Your main argument is that manual tuning will always be better than >> automated default behaviour, and we can only agree on that one. >> >> But there are two pragmatic cases you don't take into account: >> - the case when community supplied test cases do not comply with these >> rather implicit requirements, and image integrator does not have time >> to dig into each case and do the fine tuning for the rest of >> community. >> - the case when automated tests are used for exploratory package testing. >> >> In the first case, integrator just put a threshold that will reject >> some tests, up to rest of community to inject more time in solving the >> problem. >> > > In other words, the timeout has the advantage to turn a rather > implicit requirement into an explicit requirement. > And it's then up to test producers to fine tune their tests wrt this > requirement or use the available hooks in case of long tests, rather > than letting the integrator guess. > > Nicolas > >> Maybe Andreas was also addressing case of network-in-the-loop tests. >> Thus it can be seen as a quick hack for by-passing the low level >> timeout and number of retries (which are not always accessible that >> easily in some APIs...). >> >> Concerning infinite loops occurence, some are produced by uncompatible >> packages. So when you automate compatible package exploration, it >> might help because I doubt you will have explored each case >> interactively. Of course, you can always put a timeout at upper level >> in your bash or something, but it would not be particularly fine >> grained, would it ? >> >> One typical case I often bump into is those classes defining printOn: >> by sending storeOn: et vice et versa, same for printString and >> printOn:. If core happens to change between two releases, and you have >> a subclass defined in your package, probability to run into one of >> these infinite loops increases. >> >> Nicolas >> >>>> 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.. >>> >>> I agree. >>> Thanks for sharing your thoughts. >>> So the issue is done. :) >>> >>> >>>> >>>> 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 >>>>> >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

May 31, 2010

[Pharo-project] [update 1.1] #11382

by StÃ©phane Ducasse

11382 ----- - Issue 2462: Preference Browser should be removed from the world menu. Thanks Guille. - Issue 2094: Compiler CUIS 22 fixes. Thanks henrik/juan - Issue 2466: MethodReference>> asStringOrText. Thanks Adrian Stef

May 31, 2010

Re: [Pharo-project] Manuia Memory Monitor

by Alexandre Bergel

SmalltalkImage>>vmParameterAt: A number of parameters are related to the memory usage. Alexandre On 31 May 2010, at 16:04, StÃ©phane Ducasse wrote: > good! > how do you compute the memory usage? > Stef > > On May 31, 2010, at 9:49 PM, Alexandre Bergel wrote: > >> Interesting. After some minor adaptation (turning _ into := ) it loads fine. >> I took some of the ideas and put it in the new version of Memory Profiler. >> >> Gofer new >> squeaksource: 'MemoryMonitor'; >> package: 'ConfigurationOfMemoryMonitor'; >> load. >> ((Smalltalk at: #ConfigurationOfMemoryMonitor) project perform: #lastVersion) load. >> >> Cheers, >> Alexandre >> >> <Screen shot 2010-05-31 at 15.48.11.png> >> >> On 31 May 2010, at 11:10, Torsten Bergmann wrote: >> >>> BTW: There is also the old "MemoryUsage" from Squeak (see [1]/[2]). >>> Dont know if it still works >>> >>> [1] http://map.squeak.org/package/5307d593-6aa4-496a-94fa-68a5ed82a3ba >>> [2] http://web.nilpotent.org/software/smalltalk/MemoryUsage3.st.gz >>> -- >>> GRATIS fÃ¼r alle GMX-Mitglieder: Die maxdome Movie-FLAT! >>> Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 >>> >>> _______________________________________________ >>> 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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

May 31, 2010

Re: [Pharo-project] Manuia Memory Monitor

by StÃ©phane Ducasse

good! how do you compute the memory usage? Stef On May 31, 2010, at 9:49 PM, Alexandre Bergel wrote: > Interesting. After some minor adaptation (turning _ into := ) it loads fine. > I took some of the ideas and put it in the new version of Memory Profiler. > > Gofer new > squeaksource: 'MemoryMonitor'; > package: 'ConfigurationOfMemoryMonitor'; > load. > ((Smalltalk at: #ConfigurationOfMemoryMonitor) project perform: #lastVersion) load. > > Cheers, > Alexandre > > <Screen shot 2010-05-31 at 15.48.11.png> > > On 31 May 2010, at 11:10, Torsten Bergmann wrote: > >> BTW: There is also the old "MemoryUsage" from Squeak (see [1]/[2]). >> Dont know if it still works >> >> [1] http://map.squeak.org/package/5307d593-6aa4-496a-94fa-68a5ed82a3ba >> [2] http://web.nilpotent.org/software/smalltalk/MemoryUsage3.st.gz >> -- >> GRATIS fÃ¼r alle GMX-Mitglieder: Die maxdome Movie-FLAT! >> Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 >> >> _______________________________________________ >> 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

May 31, 2010

Re: [Pharo-project] Manuia Memory Monitor

by Alexandre Bergel

Interesting. After some minor adaptation (turning _ into := ) it loads fine. I took some of the ideas and put it in the new version of Memory Profiler. Gofer new squeaksource: 'MemoryMonitor'; package: 'ConfigurationOfMemoryMonitor'; load. ((Smalltalk at: #ConfigurationOfMemoryMonitor) project perform: #lastVersion) load. Cheers, Alexandre On 31 May 2010, at 11:10, Torsten Bergmann wrote: > BTW: There is also the old "MemoryUsage" from Squeak (see [1]/[2]). > Dont know if it still works > > [1] http://map.squeak.org/package/5307d593-6aa4-496a-94fa-68a5ed82a3ba > [2] http://web.nilpotent.org/software/smalltalk/MemoryUsage3.st.gz > -- > GRATIS fÃ¼r alle GMX-Mitglieder: Die maxdome Movie-FLAT! > Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 > > _______________________________________________ > 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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

May 31, 2010

Re: [Pharo-project] Manuia Memory Monitor

by StÃ©phane Ducasse

On May 31, 2010, at 5:10 PM, Torsten Bergmann wrote: > BTW: There is also the old "MemoryUsage" from Squeak (see [1]/[2]). > Dont know if it still works > > [1] http://map.squeak.org/package/5307d593-6aa4-496a-94fa-68a5ed82a3ba I like the comment :) A subclass of ProgressMorph that displays the current VM memory usage. > [2] http://web.nilpotent.org/software/smalltalk/MemoryUsage3.st.gz > -- > GRATIS fÃ¼r alle GMX-Mitglieder: Die maxdome Movie-FLAT! > Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

May 31, 2010

Re: [Pharo-project] Manuia Memory Monitor

by Alexandre Bergel

> And of course, when looking a bit closer, it's even simpler :) (If you don't need custom display etc. that is) Making and keeping it simple is a strong requirement :-) > not sure if probleBlock is a spelingError :) It is, indeed. > PS. Would it be possible to do: > ManuiaMonitor>> initialize > graph := MMGraph new. > graph addProbe: MUsedMemoryProbe new; addProbe: MMGCProbe new. Nicer yes. > That way, a graph not used by the monitor is empty by default, and a new instance can be used for whatever graphing purpose one desires, like Mariano :) New version in the SqueakSource MemoryMonitor repository Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

May 31, 2010