July 2017 - Pharo-users - lists.pharo.org

bitAnd: Documentation

by Koos Brandt

Hi I am new to this environment I am on Pharo 6.0 - 64 Mac OSX version, Downloaded over the weekend. Just did some learning and found that the description for bitAnd: is probably wrong. It reads exactly the same as bitOr: here are some tests as performed in the workspace Also included bitXor: for the fun of it bitAnd: arg Primitive. Answer an Integer whose bits are the logical OR of the receiver's bits and those of the argument, arg. Numbers are interpreted as having 2's-complement representation. Essential. See Object documentation whatIsAPrimitive. <primitive: 14> self >= 0 ifTrue: [^ arg bitAnd: self]. ^ (self bitInvert bitOr: arg bitInvert) bitInvert. 0 bitAnd: 0 -> 0 1 bitAnd: 0 -> 0 2 bitAnd: 0 -> 0 3 bitAnd: 0 -> 0 0 bitAnd: 1 -> 0 1 bitAnd: 1 -> 1 2 bitAnd: 1 -> 0 3 bitAnd: 1 -> 1 bitOr: arg Primitive. Answer an Integer whose bits are the logical OR of the receiver's bits and those of the argument, arg. Numbers are interpreted as having 2's-complement representation. Essential. See Object documentation whatIsAPrimitive. <primitive: 15> self >= 0 ifTrue: [^ arg bitOr: self]. ^ arg < 0 ifTrue: [(self bitInvert bitAnd: arg bitInvert) bitInvert] ifFalse: [(self bitInvert bitClear: arg) bitInvert] 0 bitOr: 0 -> 0 1 bitOr: 0 -> 1 2 bitOr: 0 -> 2 3 bitOr: 0 -> 3 0 bitOr: 1 -> 1 1 bitOr: 1 -> 1 2 bitOr: 1 -> 3 3 bitOr: 1 -> 3 bitXor: arg Primitive. Answer an Integer whose bits are the logical XOR of the receiver's bits and those of the argument, arg. Numbers are interpreted as having 2's-complement representation. Essential. See Object documentation whatIsAPrimitive. <primitive: 16> self >= 0 ifTrue: [^ arg bitXor: self]. ^ arg < 0 ifTrue: [self bitInvert bitXor: arg bitInvert] ifFalse: [(self bitInvert bitXor: arg) bitInvert]. 0 bitXor: 0 -> 0 1 bitXor: 0 -> 1 2 bitXor: 0 -> 2 3 bitXor: 0 -> 3 0 bitXor: 1 -> 1 1 bitXor: 1 -> 0 2 bitXor: 1 -> 3 3 bitXor: 1 -> 2 Picked it up when I was trying to explain the simplicity of the even method on smallInteger. Methods work just fine, but the description is wrong regards Koos brandt

July 18, 2017

Re: [Pharo-users] [Pharo-dev] [Ann] Keccak hashing algorithm

by Sven Van Caekenberghe

Great work. I love libraries like these. I am a bit confused though, in your #updateString: you seem to be implementing UTF-8 encoding, something we already have. Normally, hashing algorithms are defined on bytes and result in bytes (yours returns a plain Array, which is also strange). It seems (Keccak hashMessage: 'foo bar') = (Keccak hashMessage: 'foo bar' asByteArray). is true, but (Keccak hashMessage: 'Les Ã©lÃ¨ves FranÃ§aises') = (Keccak hashMessage: 'Les Ã©lÃ¨ves FranÃ§aises' utf8Encoded). is false. How come ? Is this UTF-8 encoding really part of the algorithm ? Do your tests cover it ? Another question, how would you compute the invariants given here ? https://en.wikipedia.org/wiki/SHA-3#Examples_of_SHA-3_variants SHAKE128("The quick brown fox jumps over the lazy dog", 256) f4202e3c5852f9182a0430fd8144f0a74b95e7417ecae17db0f8cfeed0e3e66e SHAKE128("The quick brown fox jumps over the lazy dof", 256) 853f4538be0db9621a6cea659a06c1107b1f83f02b13d18297bd39d7411cf10c > On 18 Jul 2017, at 18:32, Santiago Bragagnolo <santiagobragagnolo(a)gmail.com> wrote: > > Hi there! > > I am just releasing the first version of the Keccak-256 hashing algorithm. https://en.wikipedia.org/wiki/SHA-3 > > You can find it at: https://github.com/sbragagnolo/Keccak > > This version is based on a javascript implementation: https://github.com/emn178/js-sha3 > > This implementation supports as message: bytearray and ascii and utf-8 strings. > > > Soon i will be adding support to the rest of the Keccak family of hashing functions, since the implementations is quite configurable, is just need to add some constructors with specific configurations and tests for this other cases of usage. > > > Here a onliner for building an image with the version v0.1: > > wget -O- https://raw.githubusercontent.com/sbragagnolo/Keccak/v0.1/build.sh | bash > > Hope you find it useful :) > > > Santiago > >

July 18, 2017

[Ann] Keccak hashing algorithm

by Santiago Bragagnolo

Hi there! I am just releasing the first version of the Keccak-256 hashing algorithm. https://en.wikipedia.org/wiki/SHA-3 You can find it at: https://github.com/sbragagnolo/Keccak This version is based on a javascript implementation: https://github.com/emn178/js-sha3 This implementation supports as message: bytearray and ascii and utf-8 strings. Soon i will be adding support to the rest of the Keccak family of hashing functions, since the implementations is quite configurable, is just need to add some constructors with specific configurations and tests for this other cases of usage. Here a onliner for building an image with the version v0.1: wget -O- https://raw.githubusercontent.com/sbragagnolo/Keccak/v0.1/build.sh | bash Hope you find it useful :) Santiago

July 18, 2017

Re: [Pharo-users] Mysterious problem in loading Pharo

by Herby VojÄÃk

It is a real problem (I was getting it in 100% of the cases, restart did not help, restore of system disk image from last (this monday, so including the recent update) helped. What I wanted to point to, is, at stack overflow they mentioned this error happens when dlls depend on each other, are loaded via LoadLibrary and access their memory before they are actually loaded (something like that). Maybe it would be beneficial to look at how dlls (especially in combination with FT2Plugin.dll) are loaded, and somehow force some order there. Herby -- View this message in context: http://forum.world.st/Mysterious-problem-in-loading-Pharo-tp4954998p4955544… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

July 18, 2017

Re: [Pharo-users] Encoding and conversion problem

by Cyril Ferlicot

On Tue, Jul 18, 2017 at 4:27 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > 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. When I'll have time I'll check if we can avoid the use of #position:, but in any case we cannot use #upToEnd because we need to stay optimized. At the begining we where doing that but it's too long for our algos. Sometime we just want to read what it between the line 3, column 5 and the line 6, column 9. If the file has thousands of line we lose to much time to read everything. -- 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 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