May 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Pharocast ContactManager using SandstoneDb

by Jeff Gray

Kind of on topic as you're talking about sandstone....Since all records are loaded at start up, is there an advantage of using sandstonedb for persistence over just saving the image? -- View this message in context: http://forum.world.st/Re-Pharocast-ContactManager-using-SandstoneDb-tp34934… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

May 4, 2011

Re: [Pharo-project] RFC: PluggableTextMorphWithLimits

by Benjamin

In fact, I ant to know if the limit is negative or not because if it's, so it just act like a classic PluggableTextMorph ( if the same text morph is used to display source code and comments, you do not want to restrict comment size ). But I could use a boolean instead, it was just a first release to know if the concept is cool enough to be used :) Thanks for your feedback :) Ben On May 4, 2011, at 1:05 PM, Fernando Olivero wrote: > Hi Ben, its a cool idea. To use this physiological "stress factor" to > force developers to stop coding really long method. > > I looked at the class, i only disliked the statement > > self warningLimit negative ifTrue:[ ^ self basicColor]. > > you could do : > warningLimit: aNumber > warningLimit := aNumber max: 0. > > Fernando > > On Wed, May 4, 2011 at 11:18 AM, Benjamin > <benjamin.vanryseghem.pharo(a)gmail.com> wrote: >> Hello Smalltalkers, >> >> I'm currently working on new code editing tools, and I've implemented a new subclass of PluggableTextMorph named PluggableTextMorphWithLimits , with a code oriented feature: >> >> You have a warningLimit ( 350 by default ) and an alertLimit ( 2* warningLimit by default ), and the number of characters of the text displayed is counted ( without space, tabs, cr etc). >> >> If you are below the warning limit, the background is white ( or the default color ), if you are between warningLimit and alertLimit, the background turn more and more yellow, and if you are above the alertLimit, the background turn orange :) >> >> After using it for ten minutes, you start shivering when the background turn yellow ;) >> >> Gofer new >> squeaksource: 'Nautilus'; >> package: 'PluggableTextMorphWithLimits'; >> load. >> >> You can test it by evaluating: >> >> PluggableTextMorphWithLimits example. >> >> I think it will be used by Nautilus, but maybe more code editing tools should used it. >> >> >> Thanks in advance for your feedback :) >> >> >> >> Ben >> >

May 4, 2011

Re: [Pharo-project] RFC: PluggableTextMorphWithLimits

by Fernando Olivero

Hi Ben, its a cool idea. To use this physiological "stress factor" to force developers to stop coding really long method. I looked at the class, i only disliked the statement self warningLimit negative ifTrue:[ ^ self basicColor]. you could do : warningLimit: aNumber warningLimit := aNumber max: 0. Fernando On Wed, May 4, 2011 at 11:18 AM, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> wrote: > Hello Smalltalkers, > > I'm currently working on new code editing tools, and I've implemented a new subclass of PluggableTextMorph named PluggableTextMorphWithLimits , with a code oriented feature: > > You have a warningLimit ( 350 by default ) and an alertLimit ( 2* warningLimit by default ), and the number of characters of the text displayed is counted ( without space, tabs, cr etc). > > If you are below the warning limit, the background is white ( or the default color ), if you are between warningLimit and alertLimit, the background turn more and more yellow, and if you are above the alertLimit, the background turn orange :) > > After using it for ten minutes, you start shivering when the background turn yellow ;) > > Â Â Â Â Gofer new > Â Â Â Â Â Â Â Â squeaksource: 'Nautilus'; > Â Â Â Â Â Â Â Â package: 'PluggableTextMorphWithLimits'; > Â Â Â Â Â Â Â Â load. > > You can test it by evaluating: > > PluggableTextMorphWithLimits example. > > I think it will be used by Nautilus, but maybe more code editing tools should used it. > > > Thanks in advance for your feedback :) > > > > Ben >

May 4, 2011

[Pharo-project] RFC: PluggableTextMorphWithLimits

by Benjamin

Hello Smalltalkers, I'm currently working on new code editing tools, and I've implemented a new subclass of PluggableTextMorph named PluggableTextMorphWithLimits , with a code oriented feature: You have a warningLimit ( 350 by default ) and an alertLimit ( 2* warningLimit by default ), and the number of characters of the text displayed is counted ( without space, tabs, cr etc). If you are below the warning limit, the background is white ( or the default color ), if you are between warningLimit and alertLimit, the background turn more and more yellow, and if you are above the alertLimit, the background turn orange :) After using it for ten minutes, you start shivering when the background turn yellow ;) Gofer new squeaksource: 'Nautilus'; package: 'PluggableTextMorphWithLimits'; load. You can test it by evaluating: PluggableTextMorphWithLimits example. I think it will be used by Nautilus, but maybe more code editing tools should used it. Thanks in advance for your feedback :) Ben

May 4, 2011

Re: [Pharo-project] Just starting out

by Toon Verwaest

On 05/04/2011 09:53 AM, Sven Van Caekenberghe wrote: > On 04 May 2011, at 09:41, Toon Verwaest wrote: > >> On 05/04/2011 07:20 AM, StÃ©phane Ducasse wrote: >>> this is because they are forced to do so because of a new law in the us about crypto. >>> Believe they do not like that. >> What law is that, and why? Sounds interesting :) > http://en.wikipedia.org/wiki/Export_of_cryptography_in_the_United_States > > Basically, encryption is a weapon. > > Sven Uncrackable encryption will allow drug lords, spies, terrorists and even violent gangs to communicate about their crimes and their conspiracies with impunity. We will lose one of the few remaining vulnerabilities of the worst criminals and terrorists upon which law enforcement depends to successfully investigate and often prevent the worst crimes. For this reason, the law enforcement community is unanimous in calling for a balanced solution to this problem. Seriously? ROFL So soon you can't ssh to the states anymore? :)

May 4, 2011

Re: [Pharo-project] Just starting out

by Peter Hugosson-Miller

Yes, I'm interested too. Sounds reminiscent of the ITAR days of the late 1990s. Wonder if I still have that T-shirt... -- Cheers, Peter. On 4 maj 2011, at 09:41, Toon Verwaest <toon.verwaest(a)gmail.com> wrote: > On 05/04/2011 07:20 AM, StÃ©phane Ducasse wrote: >> this is because they are forced to do so because of a new law in the us about crypto. >> Believe they do not like that. > What law is that, and why? Sounds interesting :) >

May 4, 2011

Re: [Pharo-project] Just starting out

by Sven Van Caekenberghe

On 04 May 2011, at 09:41, Toon Verwaest wrote: > On 05/04/2011 07:20 AM, StÃ©phane Ducasse wrote: >> this is because they are forced to do so because of a new law in the us about crypto. >> Believe they do not like that. > What law is that, and why? Sounds interesting :) http://en.wikipedia.org/wiki/Export_of_cryptography_in_the_United_States Basically, encryption is a weapon. Sven

May 4, 2011

Re: [Pharo-project] Just starting out

by Toon Verwaest

On 05/04/2011 07:20 AM, StÃ©phane Ducasse wrote: > this is because they are forced to do so because of a new law in the us about crypto. > Believe they do not like that. What law is that, and why? Sounds interesting :)

May 4, 2011

Re: [Pharo-project] Timespan #intersection: yields wrong result

by Johan Brichau

Stef, No, and it seems I have mixed up Chronology and Chronos. I just got an answer from Alan Lovejoy confirming that my snippet works correct in the Chronos implementation (which is not the standard date/time library). So, I'm still wondering why this is not the case in Chronology. I will definitely check out Chronos and Aconcagua now. Stupid me that I did not see that :-( Johan On 03 May 2011, at 22:51, StÃ©phane Ducasse wrote: > BTW johan did you also check aconcagua? > > > Stef > > On May 3, 2011, at 7:25 PM, Johan Brichau wrote: > >> Hi, >> >> I traced a bug when working with timespans to the following issue illustrated in the code snippet below. >> The last expression in the snippet yields false, although it should yield true (imho). >> >> |start end span| >> start :=DateAndTime now. >> end := start + 1 hour. >> span := Timespan starting: start ending: end. >> (span intersection: span) = span --> false >> >> I think that the intersection of a span with itself, should be itself. The origin of the problem is that Timespan>>intersection: creates a new timespan roughly as follows: >> >> Timespan starting: aBegin ending: self end. >> >> But Timespan>>end returns the end time of the timespan minus the clockprecision. As such, the intersecting span is a nanosecond shorter than the one we would expect. This eventually yields wrong results when working with timespans. >> >> The real question now is: should the implementation of Timespan>>intersection be changed -or- should Timespan>>end really return the (non-included) end time (that was passed when constructing it)? >> >> I sent this email to bugs(a)chronos-st.org, but a discussion here probably will not hurt either. >> >> Best regards >> Johan Brichau > >

May 4, 2011

Re: [Pharo-project] ZnClient ConnectionTimedOut

by Sven Van Caekenberghe

Hi Jimmie, On 04 May 2011, at 00:53, Jimmie Houchin wrote: > Hello, > > I am happily use ZincHttpComponents, specifically ZnClient for my application. That's good to hear. > I make a request to the Python server part of my application which retrieves data from another server. This at times takes longer than the provided "timeout" for a connection. > > I am currently doing, ZnClient get: url. > > How can I increase the "timeout" for retrieving my data. I know it is a bit confusing, but there are different HTTP clients inside Zn. ZnClient is the simplest one, it can only to one-shot requests, optionally with basic authentication. It supports proxies. ZnFixedClient is a special client to repeatedly talk to the same host:port and reuse open connections, if possible. This makes it potentially faster. ZnUserAgent and its subclass ZnHttpClient constitute a more sophisticated client with a richer API. Of these, ZnHttpClient has a more builder like API. They can follow redirects, allow the setting of timeout and other parameter and can do digest authentication. To make a long story short, to do a GET with a custom timeout you can do: | settings | settings := (ZnUserAgentSettings defaultSettingsClass new) timeout: 60. ZnHttpClient new settings: settings; url: 'http://zn.stfx.eu/random/256'; get. #get returns the response contents. If you want to access the actual ZnResponse (to see if the request was actually successful) use #response after doing a #get. Let me know if this solves your problem or not. Zn is quite flexible, it all depends on your needs. > Any help greatly appreciated. > > Thanks. > > Jimmie HTH, Sven

May 4, 2011