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

Re: [Pharo-dev] a Pharo talk from a ruby conference

by Hilaire Fernandes

Once, when I told an old friend I was doing Smalltalk, he asked me "Are you doing computer archeology?" It is difficult to fight this. Hilaire Le 15/05/2014 22:09, Sergi Reyner a Ã©crit : > "Pharo is a Smalltalk for the 21st century." - Sergi Reyner. > > Cheers, > Sergi -- Dr. Geo http://drgeo.eu

May 16, 2014

Re: [Pharo-dev] a Pharo talk from a ruby conference

by Sean P. DeNigris

Esteban A. Maringolo wrote > All the previous dialects were advertised as "a new Smalltalk dialect" > ... > This time we could, at least, try to advertise it differently. +1. I think that delaying the Smalltalk conversation a bit a la Clojure might be the sweet spot. A good time to mention it might be in describing the language, since it's obviously Smalltalk. I'll reiterate that I strongly feel that the language - which has always been the least interesting thing - should be introduced /last/, after the environment - which is the real blue plane idea here - and the libraries, which are of practical importance. ----- Cheers, Sean -- View this message in context: http://forum.world.st/a-Pharo-talk-from-a-ruby-conference-tp4756805p4759290… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

May 16, 2014

Re: [Pharo-dev] 32 bits and 64 bits VM

by Damien Cassou

On Wed, May 14, 2014 at 9:08 PM, Hilaire Fernandes <hilaire.fernandes(a)gmail.com> wrote: > Yesterday my boss asked me to see DrGeo on his Ununtu 14.04LTS 64 bits > machine. I could not get it working Following these simple instructions would have fixed the problem in 2 minutes: http://www.pharo-project.org/pharo-download/ubuntu I run the exact same OS and Pharo works perfectly. -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill

May 16, 2014

Re: [Pharo-dev] 32 bits and 64 bits VM

by Esteban Lorenzano

I wonder how. AFAIK different length of word will warranty that you cannot use most of the plugins (in the case you actually can compile the vm without made any change). I know Dave made the interpreter vm compilable in 64bits, with a flag or something. But that not talks about the plugins (FFI, in particular, I do not think will work). For compiling the stack/cog there are other problems, I think. I may be wrong, but even the StackVM will have some problems because registers change in 64bits. â¦ or Iâm having wrong assumptions, and it is easily feasible, but I do not think so. Esteban On 16 May 2014, at 16:31, Chris Cunningham <cunningham.cb(a)gmail.com> wrote: > Right. Running an image natively in 64 bits doesn't mean you have to have a 64 bit image as well. > http://timmydosmalltalk.wordpress.com/2014/03/13/howto-build-a-64-native-st… > (not my work at all - just sharing). > > -cbc > > > On Fri, May 16, 2014 at 6:33 AM, Hilaire Fernandes <hilaire.fernandes(a)gmail.com> wrote: > the SqueakVM https://packages.debian.org/sid/amd64/squeak-vm/download > is linked against 64bits libraries, at least as far as I am correct this > is what say: > > ldd squeakvm > > Next I tested I can run DrGeo (1.4 pharo based, 32 bits image) with this > VM on a 64 bits host (uname -a). > > Pharo 2 does not work as this vm is too old. > > Where am I wrong? > > Hilaire > > Le 16/05/2014 10:20, Esteban Lorenzano a Ã©crit : > > I do not understand. To compile a regular vm in a 64bits platform is trivial. You just need to have the 32bits library installed. > > But to have a 64bits vm that runs on 64bitsâ¦ thatâs another very different history: > > -- > Dr. Geo http://drgeo.eu > > >

May 16, 2014

Re: [Pharo-dev] 32 bits and 64 bits VM

by Chris Cunningham

Right. Running an image natively in 64 bits doesn't mean you have to have a 64 bit image as well. http://timmydosmalltalk.wordpress.com/2014/03/13/howto-build-a-64-native-st… (not my work at all - just sharing). -cbc On Fri, May 16, 2014 at 6:33 AM, Hilaire Fernandes < hilaire.fernandes(a)gmail.com> wrote: > the SqueakVM https://packages.debian.org/sid/amd64/squeak-vm/download > is linked against 64bits libraries, at least as far as I am correct this > is what say: > > ldd squeakvm > > Next I tested I can run DrGeo (1.4 pharo based, 32 bits image) with this > VM on a 64 bits host (uname -a). > > Pharo 2 does not work as this vm is too old. > > Where am I wrong? > > Hilaire > > Le 16/05/2014 10:20, Esteban Lorenzano a Ã©crit : > > I do not understand. To compile a regular vm in a 64bits platform is > trivial. You just need to have the 32bits library installed. > > But to have a 64bits vm that runs on 64bitsâ¦ thatâs another very > different history: > > -- > Dr. Geo http://drgeo.eu > > >

May 16, 2014

Re: [Pharo-dev] 32 bits and 64 bits VM

by Hilaire Fernandes

the SqueakVM https://packages.debian.org/sid/amd64/squeak-vm/download is linked against 64bits libraries, at least as far as I am correct this is what say: ldd squeakvm Next I tested I can run DrGeo (1.4 pharo based, 32 bits image) with this VM on a 64 bits host (uname -a). Pharo 2 does not work as this vm is too old. Where am I wrong? Hilaire Le 16/05/2014 10:20, Esteban Lorenzano a Ã©crit : > I do not understand. To compile a regular vm in a 64bits platform is trivial. You just need to have the 32bits library installed. > But to have a 64bits vm that runs on 64bitsâ¦ thatâs another very different history: -- Dr. Geo http://drgeo.eu

May 16, 2014

R: a Pharo talk from a ruby conference

by Lorenzo Schiavina

+1 Lorenzo Schiavina -----Messaggio originale----- Da: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] Per conto di kmo Inviato: giovedÃ¬ 15 maggio 2014 20:03 A: pharo-dev(a)lists.pharo.org Oggetto: Re: [Pharo-dev] a Pharo talk from a ruby conference Looking at the new pharo website (itâs great, by the way), I found I was more upset than I thought I would be by the total absence of the s-word. Perhaps lots of people think smalltalk is a dead language but thatâs not the only view of smalltalk that people have out there. I came to pharo looking for a new, better way of developing applications. I knew from reading about the history of computing that smalltalk was the purest object oriented language. I knew that it had pioneered many advanced ideas in program development. I knew that it was so far ahead of its time that other languages were still hobbling along behind it trying to catch up. I knew that java and C# were constantly trying to be more smalltalk-like. So I looked for a smalltalk â ideally an open source smalltalk that I could use on Linux. And so I came to pharo. If someone had told me that pharo was not smalltalk, I would not have been interested, I would have though pharo was just a niche product (like Rebol, say) - something that might simply fade away with no history behind it. And Iâm sure there are other people like me out there who also have heard of the smalltalk mystique. This heritage is something to be proud of. So why hide what pharo is? Itâs not smalltalkâs reputation as /dead/ that I think is likely to put people off. Itâs more smalltalksâs reputation as an academicâs language, used to investigate abstruse computer science problems, but unsuitable for mundane day-to-day development. The sort of language that cannot produce a stand-alone executable (a myth - but pharo could do with a deployment wizard of some kind). The sort of language that can produce incredible data visualisations (Roassal) but is unable to put up a decent data entry screen (Spec). (Sorry, that's unfair but I could not resist it! ) Rather than hide the smalltalk origins of pharo, I think they should be shouted from the rooftops. I would add something like this to the web page. */Pharo is an alive-and-kicking, developer-focused, version of smalltalk â the most beautiful idea in the history of computing./* Just my two cents. By the way, I really don't like the idea of using /agile /as a description of pharo. Agile means almost nothing now - it's just a management buzzword for nothing in particular. -- View this message in context: http://forum.world.st/a-Pharo-talk-from-a-ruby-conference-tp4756805p4759204… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

May 16, 2014

Re: [Pharo-dev] 32 bits and 64 bits VM

by phil＠highoctane.be

On Fri, May 16, 2014 at 12:38 PM, Andres Valloud < avalloud(a)smalltalk.comcastbiz.net> wrote: > * 64-bit aware hashing functions as the current ones are 32-bit centric. >> > > This issue might not be the most urgent because the 32 bit hash functions > should be sufficient to deal with at least moderately sized 64 bit images. > But how much stuff would you have to allocate before seeing a problem? > > Suppose object headers are 16 bytes and your hash functions are producing > 28 bits' worth of data. Clearly hashing 2^28 objects with zero instance > variables and zero byte data is kind of silly, so we put in at least one > instance variable making those objects at least 24 bytes. Then you also > need a hashed collection with a single table large enough to hold all those > objects (ignoring e.g. hash buckets), the load factor of which will be kept > at 80%. So... > > 24 * 2^28 * 4 // 5 + (2^28 * 8) => about 7gb > > So, the current hash functions should be fine for images up to 7gb in > size, and probably much larger than that because 7gb is the rock bottom low > estimate. Probably one might hash strings or other objects with more data > than 8 bytes. In that case, the low bound in that case will be higher. Thanks for this, always enlightening. Phil > > > Andres. > >

May 16, 2014

Re: [Pharo-dev] 32 bits and 64 bits VM

by Andres Valloud

> * 64-bit aware hashing functions as the current ones are 32-bit centric. This issue might not be the most urgent because the 32 bit hash functions should be sufficient to deal with at least moderately sized 64 bit images. But how much stuff would you have to allocate before seeing a problem? Suppose object headers are 16 bytes and your hash functions are producing 28 bits' worth of data. Clearly hashing 2^28 objects with zero instance variables and zero byte data is kind of silly, so we put in at least one instance variable making those objects at least 24 bytes. Then you also need a hashed collection with a single table large enough to hold all those objects (ignoring e.g. hash buckets), the load factor of which will be kept at 80%. So... 24 * 2^28 * 4 // 5 + (2^28 * 8) => about 7gb So, the current hash functions should be fine for images up to 7gb in size, and probably much larger than that because 7gb is the rock bottom low estimate. Probably one might hash strings or other objects with more data than 8 bytes. In that case, the low bound in that case will be higher. Andres.

May 16, 2014

Re: [Pharo-dev] Spotlight

by phil＠highoctane.be

On Fri, May 16, 2014 at 11:28 AM, Sven Van Caekenberghe <sven(a)stfx.eu>wrote: > Cool ! > > I haven't loaded your change set yet, but your ideas are good - I agree > with all of them. > Maybe it would be better to make the placement a setting (a bit like for > the growl widget). > Yeah, sure. But this really came for a persistent annoyance when doing my dev. Next in line are TWM window keybindings when I'll have time in order to shuffle my windows left right and center with the keypad. There is something wrong with accelerators and the equivalent of the OSX Cmd key on the Linux VM. So, I'll not go in that hole right now. > > What I find annoying is that the shortest match is not always chosen, for > example when you type String, the String class is not in the top matches, > and you have to type a space before hitting return. > Yeah, same story with Dictionary that I had to look up a damn number of places. But if you know the class, typing: Dictionary<Space><Enter> gets you there. So, that's kind of a workaround. That is in XXCompletion (OC, EC, well, I am lost there). Have a nice day. Phil > On 16 May 2014, at 11:02, phil(a)highoctane.be wrote: > > > Hello, > > > > There are a couple of things that do get on my nerves with Spotlight, > namely that it lists all kinds of symbols that have nothing to do in the > search list, > > > > e.g. Globals (Display), old classes that aren't there anymore etc. > > > > that it is on the top right,making me look away from the code etc. > > I want this in the middle of the screen, like in Eclipse for example. > > > > Also, if I type in Display, I'd like to inspect it right away (I know I > can do that with :<expr> but still> as I forget it all the time, I've put a > reminder in the box). > > > > Next, I do not want to search, I want to find, so, ghosttext changed > accordingly. > > > > So, I had a look and changed it to be the way I wanted. > > > > It is much more usable that way as far as I am concerned. > > > > If you want to try this, just file in the attached change set or get > https://gist.github.com/philippeback/f43447ec2bddcd3f9b84 > > > > What would also nice it to be able to have the autocompletion list > wider. Any idea on how to do just that? (yes, I have long class names...) > > > > Feedback welcome. > > > > Phil > > > > <Screenshot-13.png><Spotlight.st> > > >

May 16, 2014