- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Sexy font look

by HwaJong Oh

Can you give me some more detailed directions? I really want this! :-) -- View this message in context: http://forum.world.st/Sexy-font-look-tp3874250p4038534.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Nov. 14, 2011

Re: [Pharo-project] Broken #isPrime

by David T. Lewis

I think this may be just an incomplete update from Squeak trunk. I added a comment to the issue to explain. Dave On Sun, Nov 13, 2011 at 06:21:50PM +0100, St?phane Ducasse wrote: > Thanks dave > > http://code.google.com/p/pharo/issues/detail?id=4997 > > Stef > > On Nov 13, 2011, at 4:58 PM, David T. Lewis wrote: > > > Hi, > > > > There seems to be a problem with #isPrime in Pharo 1.4. The following example > > runs apparently forever: > > > > 100000000000000000000000000039 isPrime. > > > > Unfortunately I used #isPrime to demonstrate multiprocessing with worker > > images with RemoteTask. RemoteTask seems to work fine on Pharo, but the > > examples run "forever" and thus appear to fail due to the #isPrime problem. > > > > RemoteTask is described here > > <http://lists.squeakfoundation.org/pipermail/squeak-dev/2011-November/162167…> > > > > > > Dave >

Nov. 14, 2011

Re: [Pharo-project] [Progress Report] Zinc HTTP Components

by mail list

I have been very happily using ZNNeoClient. Does this mean that ZNClient is now the replacement for ZNNeoClient? Thanks S. On Nov 14, 2011, at 5:56 AM, Sven Van Caekenberghe wrote: > Hi, > > This is a list of the most important changes to Zn since May 1st 2011: > > - added brand new ZnClient to replace all other HTTP clients (who became deprecated) > this is an object to build, execute and process HTTP client requests, > it has a rich protocol to construct requests and to access responses, > it has various error handling options, > it can reuse an existing connection to a specific host:port, > it can handle sessions, cookies, redirects and authentication, > it has many options (settings) with sensible defaults. > here is the simplest example: > ZnClient new > get: 'http://zn.stfx.eu/zn/numbers.txt' > and here is an example using some features to make a better HTTP request: > ZnClient new > systemPolicy; > accept: ZnMimeType textPlain; > http; > host: 'zn.stfx.eu'; > path: 'zn/numbers.txt'; > contentReader: [ :entity | entity contents lines collect: [ :each | each asNumber ] ]; > ifFail: [ :exception | self inform: 'I am sorry: ', exception printString ]; > get > - added support so that HTTPS works out of the box if Zodiac is present. > this should work when Zodiac is loaded and the necessary plugin is present: > ZnClient new > url: 'https://www.google.com/search'; > queryAt: 'q' put: 'Pharo Smalltalk'; > get > - added a new subclass, ZnManagingMultiThreadedServer, that keeps track of open > worker connections so that they can be properly closed when needed. > to use this server with the Zn Seaside adaptor, you can do this: > ZnZincServerAdaptor new > port: 8080; > serverClass: ZnManagingMultiThreadedServer; > start > - refactored ZnNetworkingUtils, it is now (also) a factory for creating socket streams > - added ZnDispatcherDelegate for straight-forward dispatching to mapped urls (thx Nick Ager) > - cleanup of the cookie handling API > - fixed support for HTTP proxies (thx Alexandre Bergel for reporting) > - localhost URLs are now excluded from being proxied > - working around SocketStream>>#atEnd issues by using #peek > - implemented support for proxies that require authorization > - introduced ZnConnectionTimeout process variable > - added ManagedServers class variable to ZnServer to dispatch the system's > #startUp/#shutDown messages to all server instances that are #register-ed > - implemented client side support for If-Modified-Since and Not Modified > - changed ZnMimePart>>#fieldValueString to return an empty string instead of 'nil' > when the field is empty or absent (Thx Lukas Renggli) > - added support for dealing with certain defaults in ZnUrl > - added code to throw a ZnMissingHost exception when a bogus ZnUrl is used to connect to a HTTP host > - added ZnMimeType wildcard constants #any and #text > - added ZnHttpUnsuccessful and ZnUnexpectedContentType exceptions > - added a nice example to ZnEasy class>>#getPng: (Thx Lukas Renggli) > - added ZnUtils class>>#parseHttpDate: for use in ZnCookie>>#expiresTimeStamp > - added optional delegate #close-ing to ZnServer hierarchy > - added some Pharo 1.2 compatibility (ZnMultiThreadedServer>>#exceptionSet:) > - lots of small fixes, cleanup and improved documentation > > Sven > >

Nov. 14, 2011

Re: [Pharo-project] [Progress Report] Zinc HTTP Components

by StÃ©phane Ducasse

thanks sven do you know if we should merge with the latest version in 1.4? Stef On Nov 13, 2011, at 10:56 PM, Sven Van Caekenberghe wrote: > Hi, > > This is a list of the most important changes to Zn since May 1st 2011: > > - added brand new ZnClient to replace all other HTTP clients (who became deprecated) > this is an object to build, execute and process HTTP client requests, > it has a rich protocol to construct requests and to access responses, > it has various error handling options, > it can reuse an existing connection to a specific host:port, > it can handle sessions, cookies, redirects and authentication, > it has many options (settings) with sensible defaults. > here is the simplest example: > ZnClient new > get: 'http://zn.stfx.eu/zn/numbers.txt' > and here is an example using some features to make a better HTTP request: > ZnClient new > systemPolicy; > accept: ZnMimeType textPlain; > http; > host: 'zn.stfx.eu'; > path: 'zn/numbers.txt'; > contentReader: [ :entity | entity contents lines collect: [ :each | each asNumber ] ]; > ifFail: [ :exception | self inform: 'I am sorry: ', exception printString ]; > get > - added support so that HTTPS works out of the box if Zodiac is present. > this should work when Zodiac is loaded and the necessary plugin is present: > ZnClient new > url: 'https://www.google.com/search'; > queryAt: 'q' put: 'Pharo Smalltalk'; > get > - added a new subclass, ZnManagingMultiThreadedServer, that keeps track of open > worker connections so that they can be properly closed when needed. > to use this server with the Zn Seaside adaptor, you can do this: > ZnZincServerAdaptor new > port: 8080; > serverClass: ZnManagingMultiThreadedServer; > start > - refactored ZnNetworkingUtils, it is now (also) a factory for creating socket streams > - added ZnDispatcherDelegate for straight-forward dispatching to mapped urls (thx Nick Ager) > - cleanup of the cookie handling API > - fixed support for HTTP proxies (thx Alexandre Bergel for reporting) > - localhost URLs are now excluded from being proxied > - working around SocketStream>>#atEnd issues by using #peek > - implemented support for proxies that require authorization > - introduced ZnConnectionTimeout process variable > - added ManagedServers class variable to ZnServer to dispatch the system's > #startUp/#shutDown messages to all server instances that are #register-ed > - implemented client side support for If-Modified-Since and Not Modified > - changed ZnMimePart>>#fieldValueString to return an empty string instead of 'nil' > when the field is empty or absent (Thx Lukas Renggli) > - added support for dealing with certain defaults in ZnUrl > - added code to throw a ZnMissingHost exception when a bogus ZnUrl is used to connect to a HTTP host > - added ZnMimeType wildcard constants #any and #text > - added ZnHttpUnsuccessful and ZnUnexpectedContentType exceptions > - added a nice example to ZnEasy class>>#getPng: (Thx Lukas Renggli) > - added ZnUtils class>>#parseHttpDate: for use in ZnCookie>>#expiresTimeStamp > - added optional delegate #close-ing to ZnServer hierarchy > - added some Pharo 1.2 compatibility (ZnMultiThreadedServer>>#exceptionSet:) > - lots of small fixes, cleanup and improved documentation > > Sven > >

Nov. 13, 2011

[Pharo-project] [Progress Report] Zinc HTTP Components

by Sven Van Caekenberghe

Hi, This is a list of the most important changes to Zn since May 1st 2011: - added brand new ZnClient to replace all other HTTP clients (who became deprecated) this is an object to build, execute and process HTTP client requests, it has a rich protocol to construct requests and to access responses, it has various error handling options, it can reuse an existing connection to a specific host:port, it can handle sessions, cookies, redirects and authentication, it has many options (settings) with sensible defaults. here is the simplest example: ZnClient new get: 'http://zn.stfx.eu/zn/numbers.txt' and here is an example using some features to make a better HTTP request: ZnClient new systemPolicy; accept: ZnMimeType textPlain; http; host: 'zn.stfx.eu'; path: 'zn/numbers.txt'; contentReader: [ :entity | entity contents lines collect: [ :each | each asNumber ] ]; ifFail: [ :exception | self inform: 'I am sorry: ', exception printString ]; get - added support so that HTTPS works out of the box if Zodiac is present. this should work when Zodiac is loaded and the necessary plugin is present: ZnClient new url: 'https://www.google.com/search'; queryAt: 'q' put: 'Pharo Smalltalk'; get - added a new subclass, ZnManagingMultiThreadedServer, that keeps track of open worker connections so that they can be properly closed when needed. to use this server with the Zn Seaside adaptor, you can do this: ZnZincServerAdaptor new port: 8080; serverClass: ZnManagingMultiThreadedServer; start - refactored ZnNetworkingUtils, it is now (also) a factory for creating socket streams - added ZnDispatcherDelegate for straight-forward dispatching to mapped urls (thx Nick Ager) - cleanup of the cookie handling API - fixed support for HTTP proxies (thx Alexandre Bergel for reporting) - localhost URLs are now excluded from being proxied - working around SocketStream>>#atEnd issues by using #peek - implemented support for proxies that require authorization - introduced ZnConnectionTimeout process variable - added ManagedServers class variable to ZnServer to dispatch the system's #startUp/#shutDown messages to all server instances that are #register-ed - implemented client side support for If-Modified-Since and Not Modified - changed ZnMimePart>>#fieldValueString to return an empty string instead of 'nil' when the field is empty or absent (Thx Lukas Renggli) - added support for dealing with certain defaults in ZnUrl - added code to throw a ZnMissingHost exception when a bogus ZnUrl is used to connect to a HTTP host - added ZnMimeType wildcard constants #any and #text - added ZnHttpUnsuccessful and ZnUnexpectedContentType exceptions - added a nice example to ZnEasy class>>#getPng: (Thx Lukas Renggli) - added ZnUtils class>>#parseHttpDate: for use in ZnCookie>>#expiresTimeStamp - added optional delegate #close-ing to ZnServer hierarchy - added some Pharo 1.2 compatibility (ZnMultiThreadedServer>>#exceptionSet:) - lots of small fixes, cleanup and improved documentation Sven

Nov. 13, 2011

Re: [Pharo-project] [Moose-dev] mooseentitystate

by jannik.laval

self timeStamp ifNotEmpty: [:s | |subS| subS := s subStrings first subS first isLetter ifTrue:[^subS]]. ^'' On Nov 12, 2011, at 22:44 , StÃ©phane Ducasse wrote: > good idea. > if you have a piece of code send it. > > Stef > > On Nov 9, 2011, at 9:32 AM, jannik.laval wrote: > >> Hi Stef, >> >> It is not so simple :) >> Take this example from Moose: >> >> === >> LANNode methodDictionary collect:[:e | e timeStamp ifNotEmpty: [:s | s subStrings first ]] >> === >> >> LANNode has no author, so if you take the first substring you will have the date of creation. >> I have not a good solution, but for my scripts, I test the first character of the substring: if it is a letter, this is an author, else, there is no author. >> === >> ((myString subStrings) first at:1) isLetter >> === >> >> Cheers, >> >> On Nov 6, 2011, at 21:48 , StÃ©phane Ducasse wrote: >> >>> http://code.google.com/p/pharo/issues/detail?id=4971 >>> >>>> >>>>> In moose ? because in pharo this is like that and the changes I added where just to make sure that all the clients do not have to deal with timestamp stupid parsing. >>>>> >>>> >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev(a)iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> --- >> Jannik Laval >> >> > > --- Jannik Laval

Nov. 13, 2011

Re: [Pharo-project] FFI wish list: double arrays and friends

by StÃ©phane Ducasse

we will have some cases don't worry. JNIPort Mars? DBXTalk cairo Stef On Nov 13, 2011, at 7:07 PM, Schwab,Wilhelm K wrote: > Sig, > > The problem is that I can't release the current form for various reasons. My plan is to make (roughly) 2000 methods and 135 structure definitions available, plus any other wrappers that can be separated from the grip of GPL. The tangled BLAS and GSL libraries will necessitate a wrapper library of some type, but the current form needs to go on a proprietary code diet. > > It's a lot of work for one-at-a-time fixes. Callbacks will be a big step in the right direction. It would be nice to get the array types at the same time. > > Bill > > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Igor Stasenko [siguctua(a)gmail.com] > Sent: Sunday, November 13, 2011 12:07 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] FFI wish list: double arrays and friends > > On 12 November 2011 18:43, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: >> Sig, >> >> Stef is hinting that you are going to have some good news about OpenGL and >> FFI in general. One area in which I have been fumbling along is arrays of >> doubles, float, signed and unsigned single and double words. Some of it is >> redundant and arguably more about making code written for Dolphin happy in >> Pharo, but the doubles really are missing. Alignment is a concern; I have >> been lucky. It would be nice to get it right. >> >> I (ab)use byte arrays to hold the data, have some accessors that I seldom >> use (most of the access is, thankfully for speed, through functions in >> external libraries). Ideally, Pharo would provide a full range of double, >> float, signed and unsigned single and double and probably quad words with >> FFI awareness of all of them. >> > > It is easy to add more types and other stuff, except that i need some > real stuff to work with, like one you working on. > > >> Where is all of this going? >> >> My GSL interface is scarred by the past lack of support for underscores, and >> really needs to be rebuilt now that this is no longer a problem. It's even >> worse with PLplot because their function names are mystifyingly cryptic; >> Camel Case them and they are *completely* unrecognizable :( >> >> Another wrinkle with GSL is that I was unable to load it (as-is) on Linux. >> At least at the time, there were two libraries (GSL itself and BLAS) that >> were inter-dependent. A library that uses both would load, but the >> individual libraries would not open via FFI. I put a bunch of my own code, >> and some proprietary code, into the library that allows the offenders to >> load. With license constraints and the joys of GPL, I need to separate these >> things before a public release. >> >> It would be nice to clean all of this stuff at one shot and get first >> releases of PLplot and GSL bindings for Pharo. Callbacks would provide >> clean use of the minimizers and solvers in GSL, allowing me to remove a lot >> of confusing junk that I added to work around the missing features. It >> should be worth the wait. >> > > Starting from Jan. i will focus on adding missing stuff to > NativeBoost, like callbacks and > code inlining. We can solve these things one by one. > >> Bill >> > > > -- > Best regards, > Igor Stasenko. > >

Nov. 13, 2011

Re: [Pharo-project] FFI wish list: double arrays and friends

by Schwab,Wilhelm K

Sig, The problem is that I can't release the current form for various reasons. My plan is to make (roughly) 2000 methods and 135 structure definitions available, plus any other wrappers that can be separated from the grip of GPL. The tangled BLAS and GSL libraries will necessitate a wrapper library of some type, but the current form needs to go on a proprietary code diet. It's a lot of work for one-at-a-time fixes. Callbacks will be a big step in the right direction. It would be nice to get the array types at the same time. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Igor Stasenko [siguctua(a)gmail.com] Sent: Sunday, November 13, 2011 12:07 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] FFI wish list: double arrays and friends On 12 November 2011 18:43, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: > Sig, > > Stef is hinting that you are going to have some good news about OpenGL and > FFI in general. One area in which I have been fumbling along is arrays of > doubles, float, signed and unsigned single and double words. Some of it is > redundant and arguably more about making code written for Dolphin happy in > Pharo, but the doubles really are missing. Alignment is a concern; I have > been lucky. It would be nice to get it right. > > I (ab)use byte arrays to hold the data, have some accessors that I seldom > use (most of the access is, thankfully for speed, through functions in > external libraries). Ideally, Pharo would provide a full range of double, > float, signed and unsigned single and double and probably quad words with > FFI awareness of all of them. > It is easy to add more types and other stuff, except that i need some real stuff to work with, like one you working on. > Where is all of this going? > > My GSL interface is scarred by the past lack of support for underscores, and > really needs to be rebuilt now that this is no longer a problem. It's even > worse with PLplot because their function names are mystifyingly cryptic; > Camel Case them and they are *completely* unrecognizable :( > > Another wrinkle with GSL is that I was unable to load it (as-is) on Linux. > At least at the time, there were two libraries (GSL itself and BLAS) that > were inter-dependent. A library that uses both would load, but the > individual libraries would not open via FFI. I put a bunch of my own code, > and some proprietary code, into the library that allows the offenders to > load. With license constraints and the joys of GPL, I need to separate these > things before a public release. > > It would be nice to clean all of this stuff at one shot and get first > releases of PLplot and GSL bindings for Pharo. Callbacks would provide > clean use of the minimizers and solvers in GSL, allowing me to remove a lot > of confusing junk that I added to work around the missing features. It > should be worth the wait. > Starting from Jan. i will focus on adding missing stuff to NativeBoost, like callbacks and code inlining. We can solve these things one by one. > Bill > -- Best regards, Igor Stasenko.

Nov. 13, 2011

Re: [Pharo-project] Broken #isPrime

by StÃ©phane Ducasse

Thanks dave http://code.google.com/p/pharo/issues/detail?id=4997 Stef On Nov 13, 2011, at 4:58 PM, David T. Lewis wrote: > Hi, > > There seems to be a problem with #isPrime in Pharo 1.4. The following example > runs apparently forever: > > 100000000000000000000000000039 isPrime. > > Unfortunately I used #isPrime to demonstrate multiprocessing with worker > images with RemoteTask. RemoteTask seems to work fine on Pharo, but the > examples run "forever" and thus appear to fail due to the #isPrime problem. > > RemoteTask is described here > <http://lists.squeakfoundation.org/pipermail/squeak-dev/2011-November/162167…> > > > Dave

Nov. 13, 2011

Re: [Pharo-project] FFI wish list: double arrays and friends

by Igor Stasenko

On 12 November 2011 18:43, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: > Sig, > > Stef is hinting that you are going to have some good news about OpenGL and > FFI in general.Â One area in which I have been fumbling along is arrays of > doubles, float, signed and unsigned single and double words.Â Some of it is > redundant and arguably more about making code written for Dolphin happy in > Pharo, but the doubles really are missing.Â Alignment is a concern; I have > been lucky.Â It would be nice to get it right. > > I (ab)use byte arrays to hold the data, have some accessors that I seldom > use (most of the access is, thankfully for speed, through functions in > external libraries).Â Ideally, Pharo would provide a full range of double, > float, signed and unsigned single and double and probably quad words with > FFI awareness of all of them. > It is easy to add more types and other stuff, except that i need some real stuff to work with, like one you working on. > Where is all of this going? > > My GSL interface is scarred by the past lack of support for underscores, and > really needs to be rebuilt now that this is no longer a problem.Â It's even > worse with PLplot because their function names are mystifyingly cryptic; > Camel Case them and they are *completely* unrecognizable :( > > Another wrinkle with GSL is that I was unable to load it (as-is) on Linux. > At least at the time, there were two libraries (GSL itself and BLAS) that > were inter-dependent.Â Â A library that uses both would load, but the > individual libraries would not open via FFI.Â I put a bunch of my own code, > and some proprietary code, into the library that allows the offenders to > load. With license constraints and the joys of GPL, I need to separate these > things before a public release. > > It would be nice to clean all of this stuff at one shot and get first > releases of PLplot and GSL bindings for Pharo.Â Callbacks would provide > clean use of the minimizers and solvers in GSL, allowing me to remove a lot > of confusing junk that I added to work around the missing features.Â It > should be worth the wait. > Starting from Jan. i will focus on adding missing stuff to NativeBoost, like callbacks and code inlining. We can solve these things one by one. > Bill > -- Best regards, Igor Stasenko.

Nov. 13, 2011