June 2014 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] NaCL crypto_auth_hmacsha256

by Frank Shearar

On 9 June 2014 11:37, FranÃ§ois Stephany <tulipe.moutarde(a)gmail.com> wrote: > Does anyone use the NaCl package to sign with HMAC SHA256 but we can't find > what we need. > > We've naively added: > > apiCryptoAuthHMACSha256Output: outByteArray input: inByteArray inputLength: > inByteArrayLength key:keyByteArray > <apicall: long 'crypto_auth_hmacsha256' (byte* byte* ulonglong byte*) > module: 'libsodium'> > ^self externalCallFailed > > which failed with 'Unable to find function address'. > > Any hint of how to do that? Have you tried pinging Tony Garnock-Jones? Not because this is a problem unique to libsodium, but since he wrote Smalltalk bindings for it (http://www.eighty-twenty.org/index.cgi/tech/smalltalk/nacl-for-squeak-and-p…) he should know... frank

June 9, 2014

NaCL crypto_auth_hmacsha256

by FranÃ§ois Stephany

Does anyone use the NaCl package to sign with HMAC SHA256 but we can't find what we need. We've naively added: apiCryptoAuthHMACSha256Output: outByteArray input: inByteArray inputLength: inByteArrayLength key:keyByteArray <apicall: long 'crypto_auth_hmacsha256' (byte* byte* ulonglong byte*) module: 'libsodium'> ^self externalCallFailed which failed with 'Unable to find function address'. Any hint of how to do that?

June 9, 2014

Re: [Pharo-dev] Pipe operator

by Frank Shearar

On 8 June 2014 19:46, Camille Teruel <camille.teruel(a)gmail.com> wrote: > > On 8 juin 2014, at 19:20, Garth Holland <steve9571952(a)hotmail.com> wrote: > >> The pipe operator appears in many languages (F#, Haskell, Elixir, Clojure >> (threading macro)). It's an elegant way of chaining method/function calls in >> the presence of additional parameters. The reddit example could be written >> using a pipe operator |> >> >> #('apple' 'peach' 'banana') >> |> groupedBy: #size >> |> select: [:each | each size even] >> |> values >> |> collect: #asCommaString. > > The pipe operator is implemented as one of the examples of LanguageBox, a tool that permits to scope language extensions (it's a part of Helvetia made by Lucas Renggli). > > I once thought that the pipe operator could be useful. But now I notice that the main (if not the only) recurrent use case I found is chaining queries on collections. > If you have another recurrent use case (that is not purely idiomatic :) ) please let me know. The pipe operator is just a variant of the flip combinator: Object >> >>> aBlock "Obviously just a strawman implementation" ^ aBlock value: self. lets you write 1 >>> [:x | x + 1] >>> [:x | x * 2] >>> [:x | x + 1] which is easier to read than [:x | x + 1] value: ([:x | x * 2] value: ([:x | x + 1] value: 1)) both because you have less ()s and because it reads left->right. (OK, easier for people whose scripts are left->right.) It's so potent an idiom in F# not only because you can remove a bunch of ()s but also because F# automatically curries all functions. It's this - handling keyword selectors - where the problem comes in for Smalltalk. As Vassili Bykov mentions in his post. > So yes, using the pipe operator make the snippet more readable but still has much inefficient: at each step a new collection is created just to be trashed afterward. > Here it's not a problem but not all collections only have 3 elements ;). > > For me it's a sign that the collection libraries lack a simple abstraction: composable filters (that is, iterators) to make complex queries. > We could have collections answering #query that would responds a QueryBuilder object that would understand common enumeration methods, for example: > > #('apple' 'peach' 'banana') query > groupedBy: #size; > select: [:each | each size even]; > values; > collect: #asCommaString. > > This would return a CollectFilter on a ValuesFilter on a SelectFilter on a GroupedByFilter on the input collection. > The QueryBuilder could then answer a message like #endQuery to compute and return the values obtained by the lastly created filter (embedded in a collection that conforms to the input collection's #species). The key part of this example is the use of the Builder pattern to let you use cascades. The equivalent in Xtreams would be as lazy, as performant, but require lots of ()s: (something like:) (((#('apple 'peach' banana') groupingBy: #size) selecting: [:each | each size even]) rest) asCommaString (Your #values is Xtreams' #rest. You could also pull off less than the entire stream with #read:.) > Since it's just a composition of filter objects over the input collection, no useless intermediate collection is created: better performances & less stress on the GC. Also, using these lazy streams also lets you both unfold and fold without creating intermediate collections: http://www.lshift.net/blog/2012/04/30/hylomorphisms-through-lazy-streams frank > Of course this idea is acceptable only if they are no other use cases where the pipe operator is a must. > >> >> /Garth >> >> >> >> >> -- >> View this message in context: http://forum.world.st/Pipe-operator-tp4762106p4762182.html >> Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >> > >

June 9, 2014

Re: [Pharo-dev] Bench comparing Pahro 1.4 and 3.0.

by Hilaire Fernandes

Hi Nicolai, No, check on Smalltalk Hub. You will find instruction to install it as well. The ConfigurationOfDrGeo will not fetch the latest code, but once installed you can update the packages -Core and -Polymorph throught Monticello. Hilaire Script to try for rendering slowness (replace "figure do:" with "MessageTally spyOn:" to measure) |canvas s stats points| points :=Array new: 12. stats := Array new: 12 withAll: 0. canvas := DrGeoCanvas new. canvas scale: 20; fullscreen ; centerTo: 6@10. 2 to: 12 do: [:i | points at: i put: (canvas point: i(a)0.1) (points at: i) square; color: Color blue. s := canvas segment: i@0 to: (points at: i). s color: Color red]. figure do: [ 1 to: 10000 do: [:i| s := 6 atRandom + 6 atRandom. stats at: s put: ((stats at: s)+1). (points at: s) name: (stats at: s) asString; moveTo: s @ ((stats at: s) / 100). canvas update]]. Or another script to stress other aspect: | figure triangle | figure := DrGeoCanvas new fullscreen. triangle := [ ]. triangle := [:p1 :p2 :p3 :n | |s1 s2 s3 perp cercle p4 | s1 := figure segment: p1 to: p2. s2 := (figure segment: p2 to: p3) color: Color red; large. s3 := figure segment: p3 to: p1. perp := figure perpendicular: s3 at: p3. cercle := figure circleCenter: p3 to: p2. p4 := figure altIntersectionOf: cercle and: perp. perp hide. cercle hide. p4 hide. n > 0 ifTrue: [triangle value: p1 value: p3 value: p4 value: n -1]]. MessageTally spyOn: [triangle value: 0@0 value: -1@0 value: -1@1 value: 50] Le 08/06/2014 23:07, Nicolai Hess a Ã©crit : > > I would like to take a look at this, can > you provide me your current DrGeo version you are using > for this. (I guess it is not http://www.squeaksource.com/DrGeoII) -- Dr. Geo http://drgeo.eu iStoa - https://launchpad.net/istoa

June 9, 2014

Re: [Pharo-dev] Understanding the System Browser

by Benjamin

On 07 Jun 2014, at 13:03, Nicolai Hess <nicolaihess(a)web.de> wrote: > > --- Part 1 --> Methods ---- > > 1) What "Browser full" really means ? and whats the difference with plain browsing ? > > I would say "Browse Full" is the "normal" browser, no scope and other (older) SystemBrowser had some > special views, like hierarchy browser, version browserâ¦ Thatâs something like that :) Actually it opens a new browser, with the exact same state as the current one. Kind of a `Nautilus clone`. > > 7) why "rename method all" is in the main menu and in the sub menu ârefactoring" The refactoring engine comes as a plugin/layer on top of the bare Nautilus. So some actions are implemented without the refactoring engine (the `Analyse` menu) and some are implemented with the Refactoring engine. Moreover, some actions are in the main menu and the refractoring menu because itâs a refactoring often used, and you do not want 5 clicks to reach it. > > 8) "add in Group" throws me an error listmanager is nil. > > Groups are buggy, I am about to refactor and fix this. Feel free to file some bug reports if they are missing. They use to work :P > > > -- Part 2 --> Classes ---- > > 9) In analyze sub menu there is a "Force the generation of intialize method" what this means ? > > generates an initialze method which calls super initialize and initialize all instvars with nil, > helpful if you make a new subclass with additional inst vars. What you describe is `Generate initialize method`. If you already have an `initialize` method, doing `Generate initialize method` will only jump to the method, while the `Force the generation of initialize method` will empty it and fill it with the default pattern once more. > > > 10) In refactoring > coder rewriting . How all options work ? Whats their purpose ? > They use to work, but I never use them so I can not be sure they still work :P It brings some DSL for AST manipulation. I think there is a chapter about that in PBE > > > > 11) In refactoring > class refactoring what Realize really does ? It goes for all the `shouldBeImplemented` in the superclasses, and create a method for it. It turns an abstract class into a concrete one :) Ben

June 9, 2014

Re: [Pharo-dev] Pipe operator

by merlyn＠stonehenge.com

>>>>> "Garth" == Garth Holland <steve9571952(a)hotmail.com> writes: Garth> The pipe operator appears in many languages (F#, Haskell, Elixir, Clojure Garth> (threading macro)). And Perl6. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <merlyn(a)stonehenge.com> <URL:http://www.stonehenge.com/merlyn/> Perl/Unix consulting, Technical writing, Comedy, etc. etc. Still trying to think of something clever for the fourth line of this .sig

June 9, 2014

Re: [Pharo-dev] Bench comparing Pahro 1.4 and 3.0.

by Nicolai Hess

Hi Hilaire, I would like to take a look at this, can you provide me your current DrGeo version you are using for this. (I guess it is not http://www.squeaksource.com/DrGeoII) Nicolai 2014-06-08 22:42 GMT+02:00 Hilaire Fernandes <hilaire.fernandes(a)gmail.com>: > Le 08/06/2014 22:02, ClÃ©ment Bera a Ã©crit : > > Some collection protocols were optimized so your result makes sense. > > The profiles show it is faster on 1.4! > > > > The current performance bottleneck for your application definitely comes > > from the use of isKindOf: based on your profiles. inheritsFrom: is > > called by isKindOf: I guess. > > Although there are use of iskindOf: in the image (384), there are > exactly 0 use case from DrGeo source code directly, but still impacted I > guess. The situation is not different from 1.4, only inheritsFrom: seems > a lot slower in 3.0. > > What is strange, and may give some indication about what is happening > underneath, the script as execution goes on, is slower and slower under > Pharo 3.0. With Pharo 1.4, the execution speed is completely constant > (as perceived). > > > > Now be very careful the current GC has very strange side effect. Did you > > perform manually a full GC before each bench ? > > > Ok. I added at the begining of the script a garbage collection. The > result are more or less the same. Now I wonder could it be related to > collection during execution: > > > **Memory** > old +461,292 bytes > young -1,436,444 bytes > used -975,152 bytes > free +975,152 bytes > > **GCs** > full 0 totalling 0ms (0.0% uptime) > incr 48 totalling 213ms (19.0% uptime), avg 4.0ms > tenures 8 (avg 6 GCs/tenure) > root table 0 overflows > > > > Hil > > >

June 8, 2014

Access to XMLPullParser

by Serge Stinckwich

Can someone add me to XMLPullParser: http://smalltalkhub.com/#!/~hernan/XMLPullParser There is a red test and I want to correct it. Regards, -- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/

June 8, 2014

Re: [Pharo-dev] Bench comparing Pahro 1.4 and 3.0.

by Hilaire Fernandes

Le 08/06/2014 22:02, ClÃ©ment Bera a Ã©crit : > Some collection protocols were optimized so your result makes sense. The profiles show it is faster on 1.4! > The current performance bottleneck for your application definitely comes > from the use of isKindOf: based on your profiles. inheritsFrom: is > called by isKindOf: I guess. Although there are use of iskindOf: in the image (384), there are exactly 0 use case from DrGeo source code directly, but still impacted I guess. The situation is not different from 1.4, only inheritsFrom: seems a lot slower in 3.0. What is strange, and may give some indication about what is happening underneath, the script as execution goes on, is slower and slower under Pharo 3.0. With Pharo 1.4, the execution speed is completely constant (as perceived). > Now be very careful the current GC has very strange side effect. Did you > perform manually a full GC before each bench ? Ok. I added at the begining of the script a garbage collection. The result are more or less the same. Now I wonder could it be related to collection during execution: **Memory** old +461,292 bytes young -1,436,444 bytes used -975,152 bytes free +975,152 bytes **GCs** full 0 totalling 0ms (0.0% uptime) incr 48 totalling 213ms (19.0% uptime), avg 4.0ms tenures 8 (avg 6 GCs/tenure) root table 0 overflows Hil

June 8, 2014

Re: [Pharo-dev] Pipe operator

by Nicolas Cellier

2014-06-08 20:46 GMT+02:00 Camille Teruel <camille.teruel(a)gmail.com>: > > On 8 juin 2014, at 19:20, Garth Holland <steve9571952(a)hotmail.com> wrote: > > > The pipe operator appears in many languages (F#, Haskell, Elixir, Clojure > > (threading macro)). It's an elegant way of chaining method/function > calls in > > the presence of additional parameters. The reddit example could be > written > > using a pipe operator |> > > > > #('apple' 'peach' 'banana') > > |> groupedBy: #size > > |> select: [:each | each size even] > > |> values > > |> collect: #asCommaString. > > The pipe operator is implemented as one of the examples of LanguageBox, a > tool that permits to scope language extensions (it's a part of Helvetia > made by Lucas Renggli). > > I once thought that the pipe operator could be useful. But now I notice > that the main (if not the only) recurrent use case I found is chaining > queries on collections. > If you have another recurrent use case (that is not purely idiomatic :) ) > please let me know. > > So yes, using the pipe operator make the snippet more readable but still > has much inefficient: at each step a new collection is created just to be > trashed afterward. > Here it's not a problem but not all collections only have 3 elements ;). > > Of course, there are lazy implementations for streams and collections... For me it's a sign that the collection libraries lack a simple abstraction: > composable filters (that is, iterators) to make complex queries. > We could have collections answering #query that would responds a > QueryBuilder object that would understand common enumeration methods, for > example: > > #('apple' 'peach' 'banana') query > groupedBy: #size; > select: [:each | each size even]; > values; > collect: #asCommaString. > > This would return a CollectFilter on a ValuesFilter on a SelectFilter on a > GroupedByFilter on the input collection. > The QueryBuilder could then answer a message like #endQuery to compute and > return the values obtained by the lastly created filter (embedded in a > collection that conforms to the input collection's #species). > Since it's just a composition of filter objects over the input collection, > no useless intermediate collection is created: better performances & less > stress on the GC. > > Of course this idea is acceptable only if they are no other use cases > where the pipe operator is a must. > > Yes, Michael Lucas Smith proposed selecting: collecting: ... in the thread from 97. At least for Streams that became a real implementation (Xtreams) > > > > /Garth > > > > > > > > > > -- > > View this message in context: > http://forum.world.st/Pipe-operator-tp4762106p4762182.html > > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > > > > >

June 8, 2014