- Pharo-users - lists.pharo.org

Re: [Pharo-users] Encoding and conversion problem

by Sven Van Caekenberghe

> On 18 Jul 2017, at 16:10, Cyril Ferlicot <cyril.ferlicot(a)gmail.com> wrote: > > On Tue, Jul 18, 2017 at 3:54 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >> These are all aliases [ see: https://en.wikipedia.org/wiki/ISO/IEC_8859-1 ]. >> >> So you could add it, yes >> >> But why use TextConverter at all ? >> > > I used this because this is what I found while browsing for code. When > I did this code the CI was down I could not access to EnterprisePharo. > >> You could keep on using the alternative (more modern, cleaner) ZnCharacterEncoder hierarchy. >> >> Just open your streams binary and wrap a ZnCharacterReadStream around them with the encoding of your choice. >> >> fileReference binaryReadStreamDo: [ :in | (ZnCharacterReadStream on: in encoding: #latin1) ... ] >> > > I just tried to use this but it broke my code. For example, > ZnCharacterReadStream does not understand #position: while the > ReadStream hierarchy understand it. In general, the stream API is much, much too wide, IMHO. Not all streams (hence the word stream) can see all their content all the time (think of network or encrypted streams, most work with a sliding buffer, but in general the idea of a stream is to *not* hold everything in memory at the same time). If you look at it that way, many operations stop making sense. Positioning is one of them. Even in Java not every stream is positionable, and even if they are positionable, the positioning can fail because you go too far (back). In all parsing code that I write I try to only use 1 item look ahead (a single item buffer), which means you can #peek 1 item, that's it. I know that we have parsing code that was written with other assumptions. Such code is not stream based, IMHO. The solution (or rather workaround) is easy: read everything #upToEnd and turn it into a good old ReadStream again. You will give the use infinite positioning over all of the content, at the cost of more memory usage. > -- > Cyril Ferlicot > https://ferlicot.fr > > http://www.synectique.eu > 2 rue Jacques PrÃ©vert 01, > 59650 Villeneuve d'ascq France >

July 18, 2017

Re: [Pharo-users] Encoding and conversion problem

by Cyril Ferlicot

On Tue, Jul 18, 2017 at 3:54 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > These are all aliases [ see: https://en.wikipedia.org/wiki/ISO/IEC_8859-1 ]. > > So you could add it, yes > > But why use TextConverter at all ? > I used this because this is what I found while browsing for code. When I did this code the CI was down I could not access to EnterprisePharo. > You could keep on using the alternative (more modern, cleaner) ZnCharacterEncoder hierarchy. > > Just open your streams binary and wrap a ZnCharacterReadStream around them with the encoding of your choice. > > fileReference binaryReadStreamDo: [ :in | (ZnCharacterReadStream on: in encoding: #latin1) ... ] > I just tried to use this but it broke my code. For example, ZnCharacterReadStream does not understand #position: while the ReadStream hierarchy understand it. -- Cyril Ferlicot https://ferlicot.fr http://www.synectique.eu 2 rue Jacques PrÃ©vert 01, 59650 Villeneuve d'ascq France

July 18, 2017

Re: [Pharo-users] Encoding and conversion problem

by Sven Van Caekenberghe

> On 18 Jul 2017, at 15:42, Cyril Ferlicot <cyril.ferlicot(a)gmail.com> wrote: > > Hi, > > I did a refactoring in Moose in order to use the encoding detector > that Sven did some weeks ago while reading a file. > > With the latest stable version of ZincHTTPComponent, I can get the > encoding like this: > > fileReference binaryReadStreamDo: [ :in | (ZnCharacterEncoder > detectEncoding: in upToEnd) ] > > Since we need to read the files a lot, I save the identifier of the > encoder using the #identifier method. Then when I read I just want to > get the TextConverter corresponding to the encoder in order to read > the stream. > > The problem is that in the case of a file encoded in ISO-8859-1, my > instance of ZnSimplifiedByteEncoder return 'iso88591' as identifier > and Latin1TextConverter does not have this encoding name in its > possibilities. Only 'iso-8859-1'. > > Should we add 'iso88591' to the Latin1TextConverter? If yes, could we > backport this to Pharo 6 please? These are all aliases [ see: https://en.wikipedia.org/wiki/ISO/IEC_8859-1 ]. So you could add it, yes But why use TextConverter at all ? You could keep on using the alternative (more modern, cleaner) ZnCharacterEncoder hierarchy. Just open your streams binary and wrap a ZnCharacterReadStream around them with the encoding of your choice. fileReference binaryReadStreamDo: [ :in | (ZnCharacterReadStream on: in encoding: #latin1) ... ] > -- > Cyril Ferlicot > https://ferlicot.fr > > http://www.synectique.eu > 2 rue Jacques PrÃ©vert 01, > 59650 Villeneuve d'ascq France >

July 18, 2017

Re: [Pharo-users] [Seaside] [OFFTOPIC] Update: Debris Publishing / Quuve Research & Portfolio Management Platform

by Mariano Martinez Peck

On Mon, Jul 17, 2017 at 11:10 AM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > On 12 Jul 2017, at 21:53, Mariano Martinez Peck <marianopeck(a)gmail.com> > wrote: > > > > Hi all, > > > > A while back our team presented Quuve [1], a customizable investment > management ecosystem for professional investors. We also discussed the > technologies employed to build it [2] (it is developed on Pharo and > deployed on GemStone). We are reaching out again because we recently > revamped our website [3] and created a number of promotional videos that > demonstrate Quuve's power [4]. > > I finally watched the first video and I must say this is really > impressive. So cool to see Smalltalk code in scripting boxes ! > > Thanks Sven, Yes, the rule engine is with Smalltalk code. The user can write their own rules (for fundamentals, algorithms, quants, screening filters, etc). The code of these rules can be simple keys or Smalltalk blocks. When blocks, these are something like this: [ :aProcessorProxy | aProcessorProxy revenues / aProcessorProxy price ] and things like that. Basically, in general we pass by a "proxy" to a processor which then dynamically understands keys and ends up evaluating rules. Sure, we have problems with mathematical operators and their precedence etc. But we try to document this and provide many many examples. There is also a kind of debugger with some call stack about the called keys etc. See [1] (all violet are links that open popups to see more info) And if you liked to see Smalltalk, did you see the rules browser? hahah. See [2]. > How large is the technical team that built / is building this ? It looks > like a really deep/wide application. > The product started like a single-man project in 1996. It started with Python, then moved to Smalltalk. It has no UI back then. I joined them about 5 years ago and have been working for them since then. In these last years we started a new UI using Seaside and Bootstrap, start using Ajax everywhere, we started using GemStone for deploy, etc etc. The team was/is really small..... I cannot even believe myself how much we were able to do with the team size we had. And...I cannot stop thinking what we COULD do with a bigger team... I can give you more details privately if you wish. > > Anyway, great work. I hope you can make a living out of this. > > Thanks Sven for your nice words. [1] http://imgur.com/a/u57x7 [2] http://imgur.com/a/rkVoL -- Mariano http://marianopeck.wordpress.com

July 18, 2017

Encoding and conversion problem

by Cyril Ferlicot

Hi, I did a refactoring in Moose in order to use the encoding detector that Sven did some weeks ago while reading a file. With the latest stable version of ZincHTTPComponent, I can get the encoding like this: fileReference binaryReadStreamDo: [ :in | (ZnCharacterEncoder detectEncoding: in upToEnd) ] Since we need to read the files a lot, I save the identifier of the encoder using the #identifier method. Then when I read I just want to get the TextConverter corresponding to the encoder in order to read the stream. The problem is that in the case of a file encoded in ISO-8859-1, my instance of ZnSimplifiedByteEncoder return 'iso88591' as identifier and Latin1TextConverter does not have this encoding name in its possibilities. Only 'iso-8859-1'. Should we add 'iso88591' to the Latin1TextConverter? If yes, could we backport this to Pharo 6 please? -- Cyril Ferlicot https://ferlicot.fr http://www.synectique.eu 2 rue Jacques PrÃ©vert 01, 59650 Villeneuve d'ascq France

July 18, 2017

Re: [Pharo-users] get output of a forked process on windows

by Thierry Goubier

Hi Christophe, You have to use ProcessWrapper. Metacello new configuration: 'ProcessWrapper'; repository: 'http://smalltalkhub.com/mc/Pharo/MetaRepoForPharo40/main'; load (as extracted from the baseline of GitFileTree for Pharo4) Regards, Thierry 2017-07-18 15:34 GMT+02:00 Christophe Demarey <christophe.demarey(a)inria.fr>: > PharoConsole.exe is only available for image versions > 50. > I need a solution that works on older image versions. > > Thanks for the advice, > Christophe > > Le 18 juil. 2017 Ã 14:26, Guillermo Polito <guillermopolito(a)gmail.com> a > Ã©crit : > > Have you checked the Console version of the windows VM? > > On Tue, Jul 18, 2017 at 10:48 AM, Christophe Demarey < > christophe.demarey(a)inria.fr> wrote: > >> Hi, >> >> I would like to evaluate a Smalltalk expression in a forked process (i.e. >> something like OSProcess thisOSProcess waitForCommandOutput: 'pharo >> Pharo.image eval "SystemVersion current dottedMajorMinor"'). >> It is doable on linux/mac with OSProcess but not on Windows. Is there >> another way to do that on Windows? I would prefer to avoid to write to a >> file. >> >> Thanks, >> Christophe >> > > > > -- > > Guille Polito > > Research Engineer > French National Center for Scientific Research - *http://www.cnrs.fr* > <http://www.cnrs.fr/> > > > *Web:* *http://guillep.github.io* <http://guillep.github.io/> > *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013> > > >

July 18, 2017

Re: [Pharo-users] get output of a forked process on windows

by Christophe Demarey

PharoConsole.exe is only available for image versions > 50. I need a solution that works on older image versions. Thanks for the advice, Christophe > Le 18 juil. 2017 Ã 14:26, Guillermo Polito <guillermopolito(a)gmail.com> a Ã©crit : > > Have you checked the Console version of the windows VM? > > On Tue, Jul 18, 2017 at 10:48 AM, Christophe Demarey <christophe.demarey(a)inria.fr <mailto:christophe.demarey@inria.fr>> wrote: > Hi, > > I would like to evaluate a Smalltalk expression in a forked process (i.e. something like OSProcess thisOSProcess waitForCommandOutput: 'pharo Pharo.image eval "SystemVersion current dottedMajorMinor"'). > It is doable on linux/mac with OSProcess but not on Windows. Is there another way to do that on Windows? I would prefer to avoid to write to a file. > > Thanks, > Christophe > > > > -- > > Guille Polito > > Research Engineer > French National Center for Scientific Research - http://www.cnrs.fr <http://www.cnrs.fr/> > > > Web: http://guillep.github.io <http://guillep.github.io/> > Phone: +33 06 52 70 66 13

July 18, 2017

Re: [Pharo-users] get output of a forked process on windows

by Guillermo Polito

Have you checked the Console version of the windows VM? On Tue, Jul 18, 2017 at 10:48 AM, Christophe Demarey < christophe.demarey(a)inria.fr> wrote: > Hi, > > I would like to evaluate a Smalltalk expression in a forked process (i.e. > something like OSProcess thisOSProcess waitForCommandOutput: 'pharo > Pharo.image eval "SystemVersion current dottedMajorMinor"'). > It is doable on linux/mac with OSProcess but not on Windows. Is there > another way to do that on Windows? I would prefer to avoid to write to a > file. > > Thanks, > Christophe > -- Guille Polito Research Engineer French National Center for Scientific Research - *http://www.cnrs.fr* <http://www.cnrs.fr> *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

July 18, 2017

get output of a forked process on windows

by Christophe Demarey

Hi, I would like to evaluate a Smalltalk expression in a forked process (i.e. something like OSProcess thisOSProcess waitForCommandOutput: 'pharo Pharo.image eval "SystemVersion current dottedMajorMinor"'). It is doable on linux/mac with OSProcess but not on Windows. Is there another way to do that on Windows? I would prefer to avoid to write to a file. Thanks, Christophe

July 18, 2017

In Praise of the Very Best Programming Language

by horrido

My farewell article? https://medium.com/@richardeng/in-praise-of-the-very-best-programming-langu… <https://medium.com/@richardeng/in-praise-of-the-very-best-programming-langu…> -- View this message in context: http://forum.world.st/In-Praise-of-the-Very-Best-Programming-Language-tp495… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

July 18, 2017