- Pharo-dev - lists.pharo.org

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

Re: [Pharo-project] Just starting out

by StÃ©phane Ducasse

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. Stef On May 4, 2011, at 12:31 AM, Steve Taylor wrote: > On 03/05/11 16:18, Torsten Bergmann wrote: >> http://omasko.wordpress.com/2011/05/02/just-starting-out > > I just read the article and it mentioned that Cincom aren't allowing downloads of VisualWorks Non Commercial, but are insisting that you ask for a CD to be mailed. Very strange behaviour for the internet age of instant gratification. > > > > Steve >

May 4, 2011

Re: [Pharo-project] [Vm-dev] Fwd: System time

by David T. Lewis

On Tue, May 03, 2011 at 04:02:04AM +0200, Levente Uzonyi wrote: > > On Mon, 2 May 2011, David T. Lewis wrote: > > > >I have not looked at this carefully, but I suspect an issue in Chronology > >(as opposed to a VM or primitive issue). DateAndTime initializes some > >cached > >values at image startup time, and thereafter calculates things based on the > >millisecond clock. If the millisecond clock drifts with respect to system > >time > >on the underlying platform (as presumably would be the case if the system > >clock > >is synchronized using ntp), then DateAndTime's opinion about current time > >will > >drift with respect to the underlying platform. > > The amount of the drift seems to be 1 millisecond every 14-16 seconds on > my pc. I wrote some code to get the system time via FFI[1], then ran the > following: > > | data | > data := (1 to: 100) collect: [ :run | > 1 seconds asDelay wait. > { DateAndTime now. Win32SystemTime localDateAndTime } ]. > (data collect: [ :each | each first - each second ] as: Set) sorted explore > > > Levente > > [1] http://leves.web.elte.hu/squeak/Win32SystemTime.st I am now running a similar test (attached) on Linux. I was expecting to see clock drift exactly the same as that reported on Windows, but so far after about 15 minutes I see no obvious signs of drift. I cannot explain this but I'll leave it running for a while and see if anything interesting happens. Dave sample output: === Started at 2011-05-03T20:24:35.03-04:00 === Test duration 0:00:15:46.01 OS time now: 2011-05-03T20:40:21.039466-04:00 Squeak time now: 2011-05-03T20:40:21.04-04:00 Difference: 0:00:00:00.000534 Drift: 0:00:00:00.000075 === Started at 2011-05-03T20:24:35.03-04:00 === Test duration 0:00:15:49.072 OS time now: 2011-05-03T20:40:24.101675-04:00 Squeak time now: 2011-05-03T20:40:24.102-04:00 Difference: 0:00:00:00.000325 Drift: -0:00:00:00.000134 === Started at 2011-05-03T20:24:35.03-04:00 === Test duration 0:00:15:52.102 OS time now: 2011-05-03T20:40:27.131382-04:00 Squeak time now: 2011-05-03T20:40:27.132-04:00 Difference: 0:00:00:00.000618 Drift: 0:00:00:00.000159 === Started at 2011-05-03T20:24:35.03-04:00 === Test duration 0:00:15:55.136 OS time now: 2011-05-03T20:40:30.165711-04:00 Squeak time now: 2011-05-03T20:40:30.166-04:00 Difference: 0:00:00:00.000289 Drift: -0:00:00:00.00017

May 4, 2011

Re: [Pharo-project] Just starting out

by Igor Stasenko

On 4 May 2011 00:31, Steve Taylor <stephen.taylor(a)bom.gov.au> wrote: > On 03/05/11 16:18, Torsten Bergmann wrote: >> >> http://omasko.wordpress.com/2011/05/02/just-starting-out > > I just read the article and it mentioned that Cincom aren't allowing > downloads of VisualWorks Non Commercial, but are insisting that you ask for > a CD to be mailed. Very strange behaviour for the internet age of instant > gratification. > > Indeed. This is strange. But you know, there is even more strange stories, like companies who using smalltalk for their competitive advantage, but they hiding this fact from others for obvious reasons. But the bad side of it that it doesn't helps smalltalk to be more popular and attract more developers & industry. So if you hear from some big company official 'we are using .. errr ... Oracle' , don't bet on it :) > Â Â Â Â Â Â Â Â Â Steve -- Best regards, Igor Stasenko AKA sig.

May 4, 2011

[Pharo-project] ZnClient ConnectionTimedOut

by Jimmie Houchin

Hello, I am happily use ZincHttpComponents, specifically ZnClient for my application. 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. Any help greatly appreciated. Thanks. Jimmie

May 3, 2011

Re: [Pharo-project] new Cog VMs uploaded

by Jimmie Houchin

On 5/3/2011 4:40 PM, Eliot Miranda wrote: > > What approach do you suggest should I take? > > > I have no idea. You could try and break down the various activities > and benchmark them separately I suppose. You could look at the > profiles you're already generating in higher resolution to see where > the time is going. You could also try and extract the SystemProfiler > from OpenQwaq, which will run on Cog, and is better than MessageTally. > Andreas wrote it to get around some of MessageTally's limitations. > It should hopefully show primitives quite accurately. Here is where the OpenQwaq GPL licensing gets tricky. I am not bashing the GPL decision, I have already written in defense of it. But it does make extracting code like this a little more challenging. Does the author and/or Teleplace wish to provide an MIT license on the extracted code? Otherwise it is hard or impossible (???) to use in Pharo or Squeak. I am hopeful that Teleplace will on an issue by issue basis allow such extraction and re-licensing with appropriate credits. It would definitely should good faith and citizenship in the broader Smalltalk community. Jimmie

May 3, 2011