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

Re: [Pharo-dev] Pharo-Business: a new mailing-list

by phil＠highoctane.be

Exactly. But it is a step. In a polyglot IT environment (Java , CRuby, Python, Scala, Perl, R...) there is a place for Pharo I am sure. Especially for dealing with 'meta' things with a fast delivery cycle. Phil On Thursday, February 27, 2014, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi, > > You will not get people to send business ideas in a development list :). > > We need to start the conversation of what makes Pharo profitable as > opposed to geeky cool. The mailing is an effort in this direction. > > Doru > > > On Wed, Feb 26, 2014 at 10:13 PM, Esteban A. Maringolo < > emaringolo(a)gmail.com<javascript:_e(%7B%7D,'cvml','emaringolo(a)gmail.com');> > > wrote: > >> I don't see the point of having another list, I don't see many >> business related topics going on in the dev or users lists. In fact >> they have moderate traffic (and could even converge). >> >> However, if the idea is to foster business talk, maybe a separate list is >> okay. >> >> I'm in. >> Esteban A. Maringolo >> >> >> 2014-02-26 17:45 GMT-03:00 Santiago Bragagnolo < >> santiagobragagnolo(a)gmail.com<javascript:_e(%7B%7D,'cvml','santiagobragagnolo(a)gmail.com');> >> >: >> > Make a list where the main point is about industry issues, share >> knowledge >> > and experience about general implications of pharo in a full project. >> > Recommend frameworks for specific domains. And then also soft knowledge, >> > know who is working with pharo in business to know to who ask for help >> in >> > case of over. >> > >> > What we will gain is as beginning, order in our knowledge database. Then >> > knowledge related with pharo but not from technical point, but business. >> > >> > Finally, the Pharo powered is about 'branding'. In both cases we are >> getting >> > knowledge scoped and ordered and almost free, more visible movement >> related. >> > >> > >> > >> > >> > >> > >> > 2014-02-26 21:27 GMT+01:00 Esteban A. Maringolo <emaringolo(a)gmail.com<javascript:_e(%7B%7D,'cvml','emaringolo(a)gmail.com');> >> >: >> > >> >> Hi Stef, >> >> >> >> Can you explain what's the purpose of this list? >> >> >> >> I don't fully get it. What is to be discussed there? Market for Pharo? >> >> Derived businesses from pharo? (like pharocloud?). >> >> >> >> Thank you! >> >> >> >> >> >> Regards! >> >> Esteban A. Maringolo >> >> >> >> >> >> 2014-02-26 16:05 GMT-03:00 Pharo4Stef <pharo4Stef(a)free.fr<javascript:_e(%7B%7D,'cvml','pharo4Stef(a)free.fr');> >> >: >> >> > Dear Pharoers and Smalltalkers from all over the world >> >> > >> >> > We would really like to push business in our community and we believe >> >> > that it is important to create a community around business questions. >> >> > We created a new mailing-list >> >> > >> >> > >> >> > >> http://lists.pharo.org/mailman/listinfo/pharo-business_lists.pharo.org >> >> > >> >> > The idea is to identify >> >> > - potential market >> >> > - missing technical solutions that we could build together >> >> > - share technical assets from a business perspective (which >> >> > frameworks for what). >> >> > >> >> > We hope that you will like the idea and that more business can >> emerge! >> >> > >> >> >> > >> >> > > > -- > www.tudorgirba.com > > "Every thing has its own flow" > -- --- Philippe Back Visible Performance Improvements Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail:phil@highoctane.be | Web: http://philippeback.eu Blog: http://philippeback.be | Twitter: @philippeback Youtube: http://www.youtube.com/user/philippeback/videos High Octane SPRL rue cour Boisacq 101 | 1301 Bierges | Belgium Pharo Consortium Member - http://consortium.pharo.org/ Featured on the Software Process and Measurement Cast - http://spamcast.libsyn.com Sparx Systems Enterprise Architect and Ability Engineering EADocX Value Added Reseller

Feb. 27, 2014

Re: [Pharo-dev] Floats problem with SIXX between Pharo and GemStone

by Pharo4Stef

On 26 Feb 2014, at 23:08, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > That's exactly for this kind of reasons that I developped an ExtendedNumberParser connected to Number class>>readFrom:, to allow a variety of formats used in the rest of the world. > > It would have been easy to allow upper letter exponents in this parser, but the class was considered superfluous and removed from Pharo 3.0â¦ Nicolas to explain a bit the removal of that class. I do not think that Java has three different parser for number in its core or ruby? >From a maintenance perspective this is a lot of stress on us (not only at the code level the conceptually). If we do not have a guy like you taking care of such issues in Pharo daily how can we continue maintaining different parser? This is why we should simplifiy. Why this is the not the job of a GemstoneToPharoPharo to do that? Or ExternalNumberParser (to me it if conceptually different than ExtendedNumberParser) and it should be packaged somewhere else. We got at least two ASTs, three parsers and this cannot be. Stef > > > 2014-02-26 22:38 GMT+01:00 Mariano Martinez Peck <marianopeck(a)gmail.com>: > Hi guys, > > When I export SmallDoubles with SIXX in GemStone it generates something like this: > > <sixx.object sixx.id="15" sixx.name="close" sixx.type="SmallDouble" >1.0000000000000000E-02</sixx.object> > > This is because "0.01 asString" -> '1.0000000000000000E-02' > > > > Then I want to load this in Pharo. So first problem is that of course SmallDouble doesn't exist. So I did: > > > > aSixxShapeChangeStream shapeChangers at: #SmallDouble put: Float. > > But then, SIXX use Float >> readFrom: aStream > "Answer a new Float as described on the stream, aStream." > > ^(super readFrom: aStream) asFloat > > > So, of course " Float readFrom: '1.0000000000000000E-02' " -> 1.0 > > So my 0.01 in gemstone become 1.0 in Pharo.... > > Am I doing something wrong or this is expected? What is the best workaround? > > In GemStone I could print the SmallDouble in the XML with a method like > > Float >> xmlRepresentation > ^ String streamContents: > [:strm | self printOn: strm base: 10] > > Is this the correct approach? If true, I guess I should define: > > Float >> sixxContentOn: aStream indent: level context: dictionary > aStream nextPutAll: self xmlRepresentation > > > Thoughts? > > Thanks in advance, > > -- > Mariano > http://marianopeck.wordpress.com >

Feb. 27, 2014

Re: [Pharo-dev] about dateAndTime and TimeStamp

by Pharo4Stef

On 26 Feb 2014, at 23:03, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > I share the same idiomatic feeling with Norbert. > > However it is completely counter-intuitive (and counter productive > too) that you can't instantiate a DateAndTime using the class side > builder #date:time:, it is available in Pharo 2.0, but #date:time: was > removed in a 3.0 image I tried a month ago. strange, Did you report it before? Stef > > Regards! > > > > Esteban A. Maringolo > > > 2014-02-26 17:36 GMT-03:00 Norbert Hartl <norbert(a)hartl.name>: >> >> Am 26.02.2014 um 21:29 schrieb Pharo4Stef <pharo4Stef(a)free.fr>: >> >>> one of these days we will have to remove TimeStamp because it just adds noise to the system (in fact I would not have any problem to see DateAndTime renamed as timestamp - but having the two for nothing looks useless to me). >> >> +100 >> >> I don't really get what the use of it is, too. The mere fact that DateAndTime printString returns ISO8601 dates and TimeStamp does not makes me always use DateAndTime instead. My problem is that I often take a "snapshot of time" (like in a log event) that for me as a non-native speaker is more related to the word timeStamp than DatenAndTime which sounds like a date and time management object. But everytime I write >> >> timeStamp := DateAndTime now >> >> it feels wrong. So I would be glad if there would be some clarification here. >> >> Norbert >> >> >> >

Feb. 27, 2014

Re: [Pharo-dev] How to upload some version from the package-cache to a StHub project

by Pharo4Stef

This is also explained in the gofer chapter in the deepintopharo book Stef On 26 Feb 2014, at 22:53, MartinW <wm(a)fastmail.fm> wrote: > Gabriel Cotelli-3 wrote >> I have a whole package history in my local package cache and I want to >> upload it to a new SmalltalkHub project. I've tried using the Monticello >> browser but it insists in creating a new version of the package when I do >> the "Save" to the new repository. >> >> Is there some option to do something like this? Or some script? > > If you have several packages you can use this script: > > Gofer new > package: 'MyProject-Core'; > package: 'MyProject-Tests'; > url: 'http://smalltalkhub.com/mc/USER/MyProject/main/' username: 'USER' > password: '***'; > push. > > (Thanks again to Camillo Bruni: > http://stackoverflow.com/questions/17454965/how-to-copy-several-monticello-…) > > m. > > > > -- > View this message in context: http://forum.world.st/How-to-upload-some-version-from-the-package-cache-to-… > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >

Feb. 27, 2014

Re: [Pharo-dev] Pharo-Business: a new mailing-list

by Tudor Girba

Hi, You will not get people to send business ideas in a development list :). We need to start the conversation of what makes Pharo profitable as opposed to geeky cool. The mailing is an effort in this direction. Doru On Wed, Feb 26, 2014 at 10:13 PM, Esteban A. Maringolo <emaringolo(a)gmail.com > wrote: > I don't see the point of having another list, I don't see many > business related topics going on in the dev or users lists. In fact > they have moderate traffic (and could even converge). > > However, if the idea is to foster business talk, maybe a separate list is > okay. > > I'm in. > Esteban A. Maringolo > > > 2014-02-26 17:45 GMT-03:00 Santiago Bragagnolo < > santiagobragagnolo(a)gmail.com>: > > Make a list where the main point is about industry issues, share > knowledge > > and experience about general implications of pharo in a full project. > > Recommend frameworks for specific domains. And then also soft knowledge, > > know who is working with pharo in business to know to who ask for help in > > case of over. > > > > What we will gain is as beginning, order in our knowledge database. Then > > knowledge related with pharo but not from technical point, but business. > > > > Finally, the Pharo powered is about 'branding'. In both cases we are > getting > > knowledge scoped and ordered and almost free, more visible movement > related. > > > > > > > > > > > > > > 2014-02-26 21:27 GMT+01:00 Esteban A. Maringolo <emaringolo(a)gmail.com>: > > > >> Hi Stef, > >> > >> Can you explain what's the purpose of this list? > >> > >> I don't fully get it. What is to be discussed there? Market for Pharo? > >> Derived businesses from pharo? (like pharocloud?). > >> > >> Thank you! > >> > >> > >> Regards! > >> Esteban A. Maringolo > >> > >> > >> 2014-02-26 16:05 GMT-03:00 Pharo4Stef <pharo4Stef(a)free.fr>: > >> > Dear Pharoers and Smalltalkers from all over the world > >> > > >> > We would really like to push business in our community and we believe > >> > that it is important to create a community around business questions. > >> > We created a new mailing-list > >> > > >> > > >> > > http://lists.pharo.org/mailman/listinfo/pharo-business_lists.pharo.org > >> > > >> > The idea is to identify > >> > - potential market > >> > - missing technical solutions that we could build together > >> > - share technical assets from a business perspective (which > >> > frameworks for what). > >> > > >> > We hope that you will like the idea and that more business can emerge! > >> > > >> > > > > -- www.tudorgirba.com "Every thing has its own flow"

Feb. 27, 2014

Re: [Pharo-dev] Pharo-Business: a new mailing-list

by Tudor Girba

Thanks Stef! Doru On Wed, Feb 26, 2014 at 8:05 PM, Pharo4Stef <pharo4Stef(a)free.fr> wrote: > Dear Pharoers and Smalltalkers from all over the world > > We would really like to push business in our community and we believe that > it is important to create a community around business questions. > We created a new mailing-list > > > http://lists.pharo.org/mailman/listinfo/pharo-business_lists.pharo.org > > The idea is to identify > - potential market > - missing technical solutions that we could build together > - share technical assets from a business perspective (which > frameworks for what). > > We hope that you will like the idea and that more business can emerge! > > -- www.tudorgirba.com "Every thing has its own flow"

Feb. 27, 2014

Re: [Pharo-dev] [ANN] Fuel 1.9.3

by Tudor Girba

Thanks a lot for this effort! Doru On Wed, Feb 26, 2014 at 10:13 PM, Max Leske <maxleske(a)gmail.com> wrote: > Dear fellow Smalltalkers > > Mariano, Martin and myself are happy to announce Fuel version 1.9.3 which > includes the follwing changes to 1.9 (1.9.1 and 1.9.2 were never officially > announced): > > - (feature) the #fuelReplacement selector offers the ability to statically > replace an object (e.g. with nil) during analysis. This can lead to > significantly smaller graphs and improved speed when serializing large > graphs > - (feature) serialize the same graph that was analyzed instead of > retrazing the graph during serialization. This prevents changes in the > graph from happening between analysis and serialization > - (change) store source when serializing CompiledMethod objects. Needed > because Opal does not allow decompilation > - (fix) migrate variables across hierarchy > - (feature) Object>>serializeToFileNamed: shortcut for serializing > arbitrary objects > - (fix) better compression for LargeNegativeIntegers ( > https://pharo.fogbugz.com/f/cases/12052/Fuel-could-store-LargeNegativeInteg… > ) > > Pharo30 already includes most of these changes (integration request: > https://pharo.fogbugz.com/f/cases/13000/Integrate-Fuel-1-9-3) > > This release runs with: > - Pharo: 1.1.1, 1.1.2, 1.2, 1.2.2, 1.3, 1.4, 2.0, 3.0 > - Squeak: 4.1, 4.2, 4.3, 4.4, 4.5 > > The documentation is not up to date yet but we will remedy that situatoin > within the next couple of days ( > http://rmod.lille.inria.fr/web/pier/software/Fuel) > If you encounter any bugs or have suggestions, please contact us on the > Fuel mailing list ( > http://lists.gforge.inria.fr/cgi-bin/mailman/roster/pharo-fuel) or create > a new issue in our bug tracker (https://code.google.com/p/fuel/) > > We want to thank everyone who contributed to this release (by keyboard or > opinion) and also all of those people who actively use Fuel. > > Cheers, > Max > -- www.tudorgirba.com "Every thing has its own flow"

Feb. 27, 2014

Re: [Pharo-dev] [Pharo-users] Pharo 3.0 on Mac OS X 10.9

by Tudor Girba

Nice. Thanks! Doru On Wed, Feb 26, 2014 at 11:52 PM, Sven Van Caekenberghe <sven(a)stfx.eu>wrote: > Pharo 3.0 on Mac OS X 10.9 > > The out of the box experience. Installing and running Pharo 3.0 on a blank > Mac OS X 10.9 account in 40 seconds. > > https://www.youtube.com/watch?v=xxljgugI4c4 > > With 3 extra minutes to demo some networking and image manipulation > interactions. > > Sven > > -- > Sven Van Caekenberghe > Proudly supporting Pharo > http://pharo.org > http://association.pharo.org > http://consortium.pharo.org > > > > > > -- www.tudorgirba.com "Every thing has its own flow"

Feb. 27, 2014

Re: [Pharo-dev] [fun] Sparkline in Pharo

by Tudor Girba

Nice :) Doru On Wed, Feb 26, 2014 at 9:40 PM, Alexandre Bergel <alexandre.bergel(a)me.com>wrote: > Hi! > > I am playing with unicode characters: > > -=-=-=-=-=-=-=-=-=-=-=-= > Gofer new > url: 'http://smalltalkhub.com/mc/abergel/Sparkline/main'; > addPackage: 'Sparkline'; > load. > -=-=-=-=-=-=-=-=-=-=-=-= > > #( 1 2 3 4) spark => 'âââââ > #(-5 10 0) spark => 'âââ' > RxsNode withAllSubclasses spark: #numberOfMethods => 'âââââââââââââ > > > I got the inspiration from https://github.com/holman/spark > > By the way, I would love to have a short tutorial about unicode characters > at esug. > > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > -- www.tudorgirba.com "Every thing has its own flow"

Feb. 27, 2014

Re: [Pharo-dev] hashMultiply

by Andres Valloud

Hello again... > For what occurs in modern CPUs, well, no. Surprising to see that a mul > would be faster than a shr or shl. How comes? No, not faster. But definitely way faster than >30 cycles not so long ago. > I used to be ok with these things when I was writing demoscene code a > loong time ago but I'd need an extremely serious refresh. You said "demoscene"?!... do you have a handle??? Andres. > As a side note, there is a huge uptake in the BigData/mapreduce/hadoop > environment where Smalltalk is sorely absent. Scala seems to fill the > void on the JVM. > There hashing is quite key, to remap all of the mapping phase results to > the reduce nodes. I am surprised to see that Smalltalk vendors haven't > jumped in that space. > > Phil > > > On Wed, Feb 26, 2014 at 2:04 AM, Andres Valloud > <avalloud(a)smalltalk.comcastbiz.net > <mailto:avalloud@smalltalk.comcastbiz.net>> wrote: > > Hello... > > On 2/25/14 1:17 , phil(a)highoctane.be <mailto:phil@highoctane.be> wrote: > > I am currently reading through the Hashing in Smalltalk book > (http://www.lulu.com/shop/__andres-valloud/hashing-in-__smalltalk-theory-and… > <http://www.lulu.com/shop/andres-valloud/hashing-in-smalltalk-theory-and-pra…>__) > and, my head hurting notwithstanding, there are indeed a ton of > gems in > this system. As he mentions, doing the exercises brings a lot of > extra :-) > > > :) thank you. > > When going to 64-bit, and with the new ObjectMemory scheme, I > guess a > couple of identity hashing functions will come under scrutiny. > > e.g. > > SmallInteger>>hashMultiply > | low | > > low := self bitAnd: 16383. > ^(16r260D * low + ((16r260D * (self bitShift: -14) + (16r0065 * low) > bitAnd: 16383) * 16384)) > bitAnd: 16r0FFFFFFF > > > which will need some more bits. > > > IMO it's not clear that SmallInteger>>identityHash should be > implemented that way. Finding a permutation of the small integers > that also behaves like a good quality hash function and evaluates > quickly (in significantly less time and complexity than, say, Bob > Jenkins' lookup3) would be a really interesting research project. I > don't know if it's possible. If no such thing exists, then getting > at least some rough idea of what's the minimum necessary complexity > for such hash functions would be valuable. > > Looking at hashMultiply as a non-identity hash function, one would > start having problems when significantly more than 2^28 objects are > stored in a single hashed collection. 2^28 objects with e.g. 12 > bytes per header and a minimum of one instance variable (so the hash > value isn't a instance-constant) stored in a hashed collection > requires more than 4gb, so that is clearly a 64 bit image problem. > In 64 bits, 2^28 objects with e.g. 16 bytes per header and a > minimum of one instance variable each is already 6gb, and a minimum > of 8gb with the hashed collection itself. > > Because of these figures, I'd think improving the implementation of > hashed collections takes priority over adding more non-identity hash > function bits (as long as the existing hash values are of good quality). > > Did you look at the Hash Analysis Tool I wrote? It's in the Cincom > public Store repository. It comes in two bundles: Hash Analysis > Tool, and Hash Analysis Tool - Extensions. With everything loaded, > the tool comes with 300+ hash functions and 100+ data sets out of > the box. The code is MIT. > > I had a look at how it was done in VisualWorks; > > > The implementation of hashMultiply, yes. Note however that > SmallInteger>>hash is ^self. > > hashMultiply > "Multiply the receiver by 16r0019660D mod 2^28 > without using large integer arithmetic for speed. > The constant is a generator of the multiplicative > subgroup of Z_2^30, see Knuth's TAOCP vol 2." > <primitive: 1747> > | low14Bits | > low14Bits := self bitAnd: 16r3FFF. > ^16384 > * (16r260D * (self bitShift: -14) + (16r0065 * low14Bits) > bitAnd: 16r3FFF) > + (16r260D * low14Bits) bitAnd: 16rFFFFFFF > > The hashing book version has: > > multiplication > "Computes self times 1664525 mod 2^38 while avoiding overflow into a > large integer by making the multiplication into two 14 bits > chunks. Do > not use any division or modulo operation." > | lowBits highBits| > > lowBits := self bitAnd: 16r3FFF. > highBits := self bitShift: -14. > ^(lowBits * 16r260D) > + (((lowBits * 16r0065) bitAnd: 16r3FFF) bitShift: 14) > + (((highBits * 16r260D) bitAnd: 16r3FFF) bitShift: 14) > bitAnd: 16rFFFFFFF > > So, 16384 * is the same as bitShift: 14 and it looks like done once, > which may be better. > > > It should be a primitive (or otherwise optimized somehow). At some > point though that hash function was implemented for e.g. ByteArray > in Squeak, I thought at that point the multiplication step was also > implemented as a primitive? > > Also VW marks it as a primitive, which Pharo does not. > > > In VW it is also a translated primitive, i.e. it's executed directly > in the JIT without calling C. > > Keep in mind that the speed at which hash values are calculated is > only part of the story. If the hash function quality is not great, > or the hashed collection implementation is not efficient and induces > collisions or other extra work, improving the efficiency of the hash > functions won't do much. I think it's mentioned in the hash book > (I'd have to check), but once I made a hash function 5x times slower > to get better quality and the result was that a report that was > taking 30 minutes took 90 seconds instead (and hashing was gone from > the profiler output). > > Would we gain > some speed doing that? hashMultiply is used a lof for identity > hashes. > > Bytecode has quite some work to do: > > 37 <70> self > 38 <20> pushConstant: 16383 > 39 <BE> send: bitAnd: > 40 <68> popIntoTemp: 0 > 41 <21> pushConstant: 9741 > 42 <10> pushTemp: 0 > 43 <B8> send: * > 44 <21> pushConstant: 9741 > 45 <70> self > 46 <22> pushConstant: -14 > 47 <BC> send: bitShift: > 48 <B8> send: * > 49 <23> pushConstant: 101 > 50 <10> pushTemp: 0 > 51 <B8> send: * > 52 <B0> send: + > 53 <20> pushConstant: 16383 > 54 <BE> send: bitAnd: > 55 <24> pushConstant: 16384 > 56 <B8> send: * > 57 <B0> send: + > 58 <25> pushConstant: 268435455 > 59 <BE> send: bitAnd: > 60 <7C> returnTop > > > If this is a primitive instead, then you can also avoid the overflow > into large integers and do the math with (basically) > > mov eax, smallInteger > shr eax, numberOfTagBits > mul eax, 1664525 "the multiplication that throws out the high bits" > shl eax, 4 "throw out bits 29-32" > shr eax, 4 > lea eax, [eax * 2^numberOfTagBits + smallIntegerTagBits] > > Please excuse trivial omissions in the above, it's written only for > the sake of illustration (e.g. it looks like the 3 last instructions > can be combined into two... lea followed by shr). Also, did you see > the latency of integer multiplication instructions in modern x86 > processors?... > > I ran some experiments timing things. > > It looks like that replacing 16384 * by bitShift:14 leads to a small > gain, bitShift (primitive 17) being faster than * (primitive 9) > > > Keep in mind those operations still have to check for overflow into > large integers. In this case, large integers are not necessary. > > Andres. > > The bytecode is identical, except send: bitShift instead of send: * > > multiplication3 > | low | > > low := self bitAnd: 16383. > ^(16r260D * low + ((16r260D * (self bitShift: -14) + (16r0065 * low) > bitAnd: 16383) bitShift: 14)) > bitAnd: 16r0FFFFFFF > > > > [500000 timesRepeat: [ 15000 hashMultiply ]] timeToRun 12 > [500000 timesRepeat: [ 15000 multiplication ]] timeToRun 41 (worse) > [500000 timesRepeat: [ 15000 multiplication3 ]] timeToRun 10 > (better) > > It looks like correct for SmallInteger minVal to: SmallInteger > maxVal > > Now, VW gives: [500000 timesRepeat: [ 15000 hashMultiply ]] > timeToRun > 1.149 milliseconds > > Definitely worth investigating the primitive thing, or some NB > Asm as > this is used about everywhere (Collections etc). > > Toughts? > > Phil > > >

Feb. 27, 2014