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

Re: [Pharo-project] Decimal comma

by John Toohey

Very nice, many thanks. I'm curious as to why this has not come up before. Any program getting data from a screen or from a file could contain numbers in this format. Thanks again. On Tue, Feb 22, 2011 at 17:57, Ricardo Moran <richi.moran(a)gmail.com> wrote: > Ok, ignore my last message, this new change set I'm attaching is a little > nicer. It doesn't add an unnecessary SqNumberParser subclass and it lets you > write something like this: > Number readFrom: '3,14' decimalPoint: $, > > I also tried configuring the decimal point with a preference but the result > was a little dangerous because new code using the wrong decimal point > wouldn't compile, so I think this is a reasonable good solution to your > problem. I hope it helps. > Cheers > Richo > > On Tue, Feb 22, 2011 at 7:30 PM, Ricardo Moran <richi.moran(a)gmail.com> > wrote: >> >> I don't know if there is already a way of doing this, but I attached a >> simple hack that lets you read commas as decimal points by executing >> something like this: >> (DecimalCommaNumberParser on: '3,14') nextNumber -> 3.14 >> I know this is not elegant, but it works. There seems to be some other >> places where the decimal point is hardcoded.Â Maybe we should make >> SqNumberParser take the decimal point as a parameter. Or have a preference >> to choose that. I don't know... >> Cheers >> Richo >> >> On Tue, Feb 22, 2011 at 5:53 PM, John Toohey <jt(a)parspro.com> wrote: >>> >>> Without changing the OS locale, is there an easy was to have Pharo >>> recognize a comma as a decimal point, i.e. '2,13' asNumber -> 2,13. I >>> am receiving number from a Seaside app, in this format, and I need to >>> convert them before storing them in Postgres. Currently '2,12' >>> asNumber gives 2. >>> >>> -- >>> ~JT >>> >> > > -- ~JT

Feb. 22, 2011

Re: [Pharo-project] Cobol is the new language to know?

by Schwab,Wilhelm K

+1 overall, and to seeking better socket streams. FFI+Callbacks too. ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Casimiro de Almeida Barreto [casimiro.barreto(a)gmail.com] Sent: Tuesday, February 22, 2011 3:47 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Cobol is the new language to know? Em 22-02-2011 14:58, Eliot Miranda escreveu: > > > (...) > > IMO, while important, this misses the most important features which > together provide a useful platform: > > 1. excellent FFI (including threading support) so that the system can > be integrated with other code, both as a user of libraries and as a > provider of libraries > 2. support for foreign files in Monticello so that Monticello can be > used to manage complete projects, not just the Smalltalk assets > 3. scripting and excellent file system facilities so that one can > easily interact with the file system, still a vital part of the > majority of software systems (the Squeak file system code is a cruel > joke, still resembling the original Smalltalk-80 code from the late 70's). > +1 here. (1) and (3) are really important. I'd add enhancing network streams too. One thing that's overseen but is extremely important for developing commercial software is full internationalization support (like i18n) and its a major task since large sections of "foundation classes" (TimeAndDate for instance) would have to be adapted/changed. > Without the necessary functionality people simply can't use Squeak to > produce their applications and are forced to choose something else. > These features, along with good web support, are what I understand by > "platform". The web support is also pretty good, with Seaside, SSL, > ODBC, HTTP connectivity, etc being pretty good. The community has > made excellent progress over recent years. The "well documented", > "supported" and stable" features are not terrible. Yes they can > always be improved but on the whole that's not the fundamental block > to effective use of Squeak/Pharo. > > Performance is also not an issue to getting started; plenty of Ruby > and PHP projects sow that one can tackle performance later on. Performance is a relative thing. As far as there are no limitations to performance imposed by VM (and squeakvm/cogvm are really generous), things can be continually improved. There's one aspect of performance that can be an important show stopper for pharo/squeak/cog: memory usage ceil at 4GBytes. > Fundamental is providing a platform and we're not there yet. > > 2Â¢ > Eliot > >

Feb. 22, 2011

Re: [Pharo-project] Pharo Sources Google Hit Ratio

by StÃ©phane Ducasse

what is squeaksource3? when did it start? Stef >>>> I do not know the exact circumstances of squeaksource's amazing low >>>> google index, but I think we can change this. >>> >>> Set up some Seaside servers for Google to crawl? >> >> New SqueakSource currently in development by Iliad guys will have nice >> REST-full Urls for the Smalltalk code. Google searchable therefore! > > > so will squeaksource3 > > so long, > -tobias

Feb. 22, 2011

Re: [Pharo-project] Decimal comma

by Ricardo Moran

Ok, ignore my last message, this new change set I'm attaching is a little nicer. It doesn't add an unnecessary SqNumberParser subclass and it lets you write something like this: Number readFrom: '3,14' decimalPoint: $, I also tried configuring the decimal point with a preference but the result was a little dangerous because new code using the wrong decimal point wouldn't compile, so I think this is a reasonable good solution to your problem. I hope it helps. Cheers Richo On Tue, Feb 22, 2011 at 7:30 PM, Ricardo Moran <richi.moran(a)gmail.com>wrote: > I don't know if there is already a way of doing this, but I attached a > simple hack that lets you read commas as decimal points by executing > something like this: > > (DecimalCommaNumberParser on: '3,14') nextNumber -> 3.14 > > I know this is not elegant, but it works. There seems to be some other > places where the decimal point is hardcoded. Maybe we should make > SqNumberParser take the decimal point as a parameter. Or have a preference > to choose that. I don't know... > > Cheers > Richo > > > On Tue, Feb 22, 2011 at 5:53 PM, John Toohey <jt(a)parspro.com> wrote: > >> Without changing the OS locale, is there an easy was to have Pharo >> recognize a comma as a decimal point, i.e. '2,13' asNumber -> 2,13. I >> am receiving number from a Seaside app, in this format, and I need to >> convert them before storing them in Postgres. Currently '2,12' >> asNumber gives 2. >> >> -- >> ~JT >> >> >

Feb. 22, 2011

Re: [Pharo-project] Decimal comma

by Ricardo Moran

I don't know if there is already a way of doing this, but I attached a simple hack that lets you read commas as decimal points by executing something like this: (DecimalCommaNumberParser on: '3,14') nextNumber -> 3.14 I know this is not elegant, but it works. There seems to be some other places where the decimal point is hardcoded. Maybe we should make SqNumberParser take the decimal point as a parameter. Or have a preference to choose that. I don't know... Cheers Richo On Tue, Feb 22, 2011 at 5:53 PM, John Toohey <jt(a)parspro.com> wrote: > Without changing the OS locale, is there an easy was to have Pharo > recognize a comma as a decimal point, i.e. '2,13' asNumber -> 2,13. I > am receiving number from a Seaside app, in this format, and I need to > convert them before storing them in Postgres. Currently '2,12' > asNumber gives 2. > > -- > ~JT > >

Feb. 22, 2011

Re: [Pharo-project] Accessing OS windows within smalltalk VM

by Igor Stasenko

On 22 February 2011 19:59, Nathan Tuttle <nathan.tuttle(a)gmail.com> wrote: > Is it possible to access operating system windows (screen captures) in > pharo. Since this would be OS specific does anyone know of a primitive > plugin that would allow this? > there is no such primitive. -- Best regards, Igor Stasenko AKA sig.

Feb. 22, 2011

Re: [Pharo-project] Cobol is the new language to know?

by Eliot Miranda

On Tue, Feb 22, 2011 at 12:47 PM, Casimiro de Almeida Barreto < casimiro.barreto(a)gmail.com> wrote: > Em 22-02-2011 14:58, Eliot Miranda escreveu: > > > > > > (...) > > > > IMO, while important, this misses the most important features which > > together provide a useful platform: > > > > 1. excellent FFI (including threading support) so that the system can > > be integrated with other code, both as a user of libraries and as a > > provider of libraries > > 2. support for foreign files in Monticello so that Monticello can be > > used to manage complete projects, not just the Smalltalk assets > > 3. scripting and excellent file system facilities so that one can > > easily interact with the file system, still a vital part of the > > majority of software systems (the Squeak file system code is a cruel > > joke, still resembling the original Smalltalk-80 code from the late > 70's). > > +1 here. (1) and (3) are really important. I'd add enhancing network > streams too. > One thing that's overseen but is extremely important for developing > commercial software is full internationalization support (like i18n) and > its a major task since large sections of "foundation classes" > (TimeAndDate for instance) would have to be adapted/changed. > Agreed. I knew I didn't have a complete list :) Where is there a good place to list what work towards a platform needs to be done? I'm not sure that the 4Gb limit is a block to many projects. It's certainly important to some. But I think it can be excluded from the must-have platform requirements. A native 64-bit implementation is probably ore important, and is an aspect of the FFI, i.e. the ability to interface with 64-bit libraries. Sp so far we have 1. excellent FFI (including threading support) so that the system can be integrated with other code, both as a user of libraries and as a provider of libraries 2. support for foreign files in Monticello so that Monticello can be used to manage complete projects, not just the Smalltalk assets 3. scripting and excellent file system facilities so that one can easily interact with the file system, still a vital part of the majority of software systems (the Squeak file system code is a cruel joke, still resembling the original Smalltalk-80 code from the late 70's). 4. excellent internationalization support > > Without the necessary functionality people simply can't use Squeak to > > produce their applications and are forced to choose something else. > > These features, along with good web support, are what I understand by > > "platform". The web support is also pretty good, with Seaside, SSL, > > ODBC, HTTP connectivity, etc being pretty good. The community has > > made excellent progress over recent years. The "well documented", > > "supported" and stable" features are not terrible. Yes they can > > always be improved but on the whole that's not the fundamental block > > to effective use of Squeak/Pharo. > > > > Performance is also not an issue to getting started; plenty of Ruby > > and PHP projects sow that one can tackle performance later on. > Performance is a relative thing. As far as there are no limitations to > performance imposed by VM (and squeakvm/cogvm are really generous), > things can be continually improved. > > There's one aspect of performance that can be an important show stopper > for pharo/squeak/cog: memory usage ceil at 4GBytes. > > > Fundamental is providing a platform and we're not there yet. > > > > 2Â¢ > > Eliot > > > > > > >

Feb. 22, 2011

[Pharo-project] Decimal comma

by John Toohey

Without changing the OS locale, is there an easy was to have Pharo recognize a comma as a decimal point, i.e. '2,13' asNumber -> 2,13. I am receiving number from a Seaside app, in this format, and I need to convert them before storing them in Postgres. Currently '2,12' asNumber gives 2. -- ~JT

Feb. 22, 2011

Re: [Pharo-project] Cobol is the new language to know?

by Casimiro de Almeida Barreto

Em 22-02-2011 14:58, Eliot Miranda escreveu: > > > (...) > > IMO, while important, this misses the most important features which > together provide a useful platform: > > 1. excellent FFI (including threading support) so that the system can > be integrated with other code, both as a user of libraries and as a > provider of libraries > 2. support for foreign files in Monticello so that Monticello can be > used to manage complete projects, not just the Smalltalk assets > 3. scripting and excellent file system facilities so that one can > easily interact with the file system, still a vital part of the > majority of software systems (the Squeak file system code is a cruel > joke, still resembling the original Smalltalk-80 code from the late 70's). > +1 here. (1) and (3) are really important. I'd add enhancing network streams too. One thing that's overseen but is extremely important for developing commercial software is full internationalization support (like i18n) and its a major task since large sections of "foundation classes" (TimeAndDate for instance) would have to be adapted/changed. > Without the necessary functionality people simply can't use Squeak to > produce their applications and are forced to choose something else. > These features, along with good web support, are what I understand by > "platform". The web support is also pretty good, with Seaside, SSL, > ODBC, HTTP connectivity, etc being pretty good. The community has > made excellent progress over recent years. The "well documented", > "supported" and stable" features are not terrible. Yes they can > always be improved but on the whole that's not the fundamental block > to effective use of Squeak/Pharo. > > Performance is also not an issue to getting started; plenty of Ruby > and PHP projects sow that one can tackle performance later on. Performance is a relative thing. As far as there are no limitations to performance imposed by VM (and squeakvm/cogvm are really generous), things can be continually improved. There's one aspect of performance that can be an important show stopper for pharo/squeak/cog: memory usage ceil at 4GBytes. > Fundamental is providing a platform and we're not there yet. > > 2Â¢ > Eliot > >

Feb. 22, 2011

Re: [Pharo-project] like Finder Tool

by Benjamin Van Ryseghem

Thank you :) Ben 2011/2/22 laurent laffont <laurent.laffont(a)gmail.com> > It's good to have this in Pharo 1.2. I like it. Thank you. > > > Laurent Laffont - @lolgzs <http://twitter.com/#!/lolgzs> > > Pharo Smalltalk Screencasts: http://www.pharocasts.com/ > Blog: http://magaloma.blogspot.com/ >

Feb. 22, 2011