September 2014 - Pharo-users

article about mongodb

by Pablo R. Digonzelli

It may be a little off topic for the list, but i am think will be interesting for users of mongotalk and voyage. http://www.infoq.com/news/2013/02/MongoDB-Fault-Tolerance-Broken Ing. Pablo Digonzelli Software Solutions IP-Solutiones SRL Metrotec SRL 25 de Mayo 521 Email: pdigonzelli(a)softsargentina.com pdigonzelli(a)gmail.com Cel: 5493815982714

Sept. 7, 2014

Re: [Pharo-users] timing problem

by Ben Coman

Werner Kassens wrote: > > Sorry, I can't tell across email if that <stupid grin> is > > tongue-in-cheek since you know exactly what to do, or you are looking > > for advice :) > > Hi Ben, > i did not want to irritate you, i just thought perhaps i need to do > some sort of clean up with that fork thing afterwards (like deleting a > process or whatever), but your answer makes it clear that this is not > necessary. many thanks for your detailed answer, i guess i can deal > with the problem now. > werner > > No problem at all. btw, I wasn't irritated (maybe just another example of limits of email), just letting you know I was uncertain as to what you required. Looking forward to your next questions. cheers -ben

Sept. 6, 2014

Re: [Pharo-users] not a smalltalk!

by Sven Van Caekenberghe

On 06 Sep 2014, at 17:42, phil(a)highoctane.be wrote: > At the moment I am running Pharo every single day for all day long and it is a great recurring experience. Good for you !

Sept. 6, 2014

Re: [Pharo-users] not a smalltalk!

by Thierry Goubier

Le 06/09/2014 16:36, stepharo a Ã©crit : > >> In my opinion, this dialect thing is getting increasingly silly. And >> confusing. And silly. >> > It is not getting. It was like that already back in 1998 and before too. Yes. Who remember the differences between Envy / Parcplace / Digitalk / Smalltalk-mt / Smalltalk/X / Dolphin Smalltalk ? > > The syntax is one thing the libraries are another one! > > BTW I opened last year a VW from 1994 and I do not want to live there :) But in 1992 it was a great place to be :) Thierry > > Stef > > >

Sept. 6, 2014

Re: [Pharo-users] not a smalltalk!

by phil＠highoctane.be

I find myself saying Pharo Smalltalk and Github marks our code as Smalltalk. Which is fine. "Pharo is Pharo" indeed. But the contents of the Blue Book still holds true. What I do know is that I enjoy programming in Pharo more than with anything else. VisualWorks may have more power but I can't stand its UI. And who can beat such an all MIT codebase that one can actually make sense of? At the moment I am running Pharo every single day for all day long and it is a great recurring experience. Long live Pharo! And to hell with that Smalltalk or not thing. Phil Le 6 sept. 2014 15:32, "Sergi Reyner" <sergi.reyner(a)gmail.com> a Ã©crit : > > In my opinion, this dialect thing is getting increasingly silly. And confusing. And silly. > > > 2014-09-06 10:01 GMT+01:00 Esteban Lorenzano <estebanlm(a)gmail.com>: >> >> yesâ¦ 99% of the time Pharo and Squeak will be compatible. >> we share the vm and a large part of the codebase. >> but libraries are slowly diverging so you might find that what works in the one does not works automatically in the other. >> >> but againâ¦ my point is that all smalltalks are dialectsâ¦ there is no such thing as a reference implementation :) >> >> Esteban >> >> On 06 Sep 2014, at 10:54, PBKResearch <peter(a)pbkresearch.co.uk> wrote: >> >>> I donât know what technical incompatibilities may exist, but for many practicalities Pharo is compatible with Squeak and other dialects. I am using an application (Todd Blanchardâs HTMCSS parser and validator) which was originally written for Squeak. Some years ago I ported it to Dolphin Smalltalk, with no change other than replacing Squeakâs left-arrow assignment with :=, and just two weeks ago I downloaded it from the Squeak repository on smalltalkhub.com and installed it in Pharo 3.0; it is now working perfectly with no changes from the Squeak version. If someone were developing such a package now in Pharo, it might be tempting to use the Zinc library for the input of web pages, and that might cause portability problems. Similarly, if you develop something with an elaborate user interface in Pharo, you may find that the UI code does not port easily (or at all). But the core language of Pharo (and the language in which the libraries are written) is definitely Smalltalk. >>> >>> In reply to Yuriy, there are languages around which do call themselves Smalltalk, but which do not implement essential parts of standard Smalltalk. So where does the âhave to make it compatibleâ come from? >>> >>> Peter Kenny >>> >>> From: Pharo-users [mailto:pharo-users-bounces@lists.pharo.org] On Behalf Of kilon alios >>> Sent: 05 September 2014 19:46 >>> To: Any question about pharo is welcome >>> Subject: Re: [Pharo-users] not a smalltalk! >>> >>> AFAIK Pharo technically is not even compatible with Squeak which is where it forks form. >>> >>> You assume the code you write will automatically be incompatible to smalltalk-80 but since pretty much a huge percentage of the functionality of Pharo and Smalltalk is in libraries since the language itself is so minimal , I dont think it would be so hard to make your Pharo code smalltalk-80 friendly. >>> >>> I advice doing your own tests and seeing for yourself. Then ask questions how to solve problems you encounter. No reason to panic before facing the facts :) >>> >>> >>> >>> On Fri, Sep 5, 2014 at 9:33 PM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: >>>> >>>> There is a long story about all that. >>>> >>>> But to be short: >>>> - if you call it Smalltalk then you have to make it compatible with other Smalltalks. And they are a lot in the 80sâ¦ >>>> - we want to make something new and cool what may be not always compatible. >>>> >>>> So yeah >>>> >>>> >>>> On 05 Sep 2014, at 20:25, Mayuresh Kathe <mayuresh(a)kathe.in> wrote: >>>> >>>> > hey, i've just been reading up the pharo forums, and one of the posts/entries mentions something about pharo not being a smalltalk, but instead a dialect! >>>> > >>>> > is it true? >>>> > >>>> > that would mean, all or any code i write for pharo would not be portable to other smalltalk-80 systems! >>>> > >>>> > hmnn... >>>> > >>>> > ~mayuresh >>>> > >>>> > >> >> >

Sept. 6, 2014

Re: [Pharo-users] timing problem

by Werner Kassens

> Sorry, I can't tell across email if that <stupid grin> is > tongue-in-cheek since you know exactly what to do, or you are looking > for advice :) Hi Ben, i did not want to irritate you, i just thought perhaps i need to do some sort of clean up with that fork thing afterwards (like deleting a process or whatever), but your answer makes it clear that this is not necessary. many thanks for your detailed answer, i guess i can deal with the problem now. werner

Sept. 6, 2014

Re: [Pharo-users] Weakness

by Ben Coman

Sept. 6, 2014

Re: [Pharo-users] Weakness

by Sven Van Caekenberghe

Magnitude weakSubclass: #WeakKeyAssociation instanceVariableNames: 'value' classVariableNames: '' category: 'Collections-Support' weakSubclass: ... On 06 Sep 2014, at 16:47, Ben Coman <btc(a)openInWorld.com> wrote: > > I'd like to learn a bit more about the implementation of Weak objects. For example, I see... > > Magnitude>LookupKey>Associaton >> key: aKey value: anObject > key := aKey. > value := anObject > > Magnitude>LookupKey>WeakValueAssociaton >> key: aKey value: anObject > key := aKey. > self value: anObject > Magnitude>LookupKey>WeakValueAssociaton >> value: anObject > self at: 1 put: anObject > > Magnitude>WeakKeyAssociation >> key: aKey value: anObject > self basicAt: 1 put: aKey. > value := anObject > > The class definitions don't look any different to normal? I can see that the weak classes are doing an #at:put: for their respective weak attribute, but lots of non-weak classes also use that. > So what is it that makes WeakValueAssociaton & WeakKeyAssociation weak ? > > cheers -ben >

Sept. 6, 2014

Weakness

by Ben Coman

I'd like to learn a bit more about the implementation of Weak objects. For example, I see... Magnitude>LookupKey>Associaton >> key: aKey value: anObject key := aKey. value := anObject Magnitude>LookupKey>WeakValueAssociaton >> key: aKey value: anObject key := aKey. self value: anObject Magnitude>LookupKey>WeakValueAssociaton >> value: anObject self at: 1 put: anObject Magnitude>WeakKeyAssociation >> key: aKey value: anObject self basicAt: 1 put: aKey. value := anObject The class definitions don't look any different to normal? I can see that the weak classes are doing an #at:put: for their respective weak attribute, but lots of non-weak classes also use that. So what is it that makes WeakValueAssociaton & WeakKeyAssociation weak ? cheers -ben

Sept. 6, 2014

Re: [Pharo-users] timing problem

by Ben Coman

Werner Kassens wrote: > Hi, > > On 09/06/2014 03:35 PM, Ben Coman wrote: > >> Just to be clear, by "did some calculations for an hour" do you mean the >> Image basically locked up during the calculation, and the mouse clicks >> were queued until the calculation ended? > > exactly, after the calculation different windows spring into the > foreground, if i redo that. the strange thing though is, that the > errormessages came during the calculation and although (they added up > fast) i did not really look at them (i just cklicked them away, after > having interrupted the program) in the end they originated from the > browser. > >> Anyhow, there are two general approaches I am familiar with. >> 1. Add " Processor yield " within your calculation loop. >> 2. Run your calculation at a priority lower than the UI. For example, " >> result := nil. calculationProcess := [ result := self myCalculation ] >> forkAt: Processor userBackgroundPriority " , then periodically test for >> " result ~= nil " , maybe from a "step" method in your own subclass of >> some Morph. > > and what do i do after 'result ~= nil' ? <stupid grin> Sorry, I can't tell across email if that <stupid grin> is tongue-in-cheek since you know exactly what to do, or you are looking for advice :) It depends... How would you deal with the result of your calculation (assuming you didn't fork it)? In very general terms you'd have MyMorph>>step (result ~= nil) ifTrue: [ "do stuff to update my 'StringMorph' submorphs with result data I now have" "or do stuff to write results to disk or database, and display 'FINISHED', and sound a beep" ] > and what is the disadvantage of the simple first solution, i have to > admit i never looked at these fork things? > werner > > I'm not sure if there is any practical disadvantage**. Again, it depends... on how tight your loops are, and exactly where you put the "Processor yeilds". You'd need to suck-it-and-see. But speaking generally, you calculation is still competing with the UI loop. If you yield every 100ms and you click the mouse immediately after the calculation starts, then the click will** not be seen by the UI for 100ms, so you will see some lag. There may be downsides to yielding more often**, and it may take some effort to determine cycle period of various parts of your loops to get it working smoothly, if even these remain consistent across the life and use of your application. With the second approach, any mouse click will interrupt the calculation and be handled immediately** so its likely the UI will remain more responsive. With the second approach, it is also easier to suspend and continue the calculation, if you so desired. ** These are my beliefs I've picked as I've looked into some parts of Pharo internals, but I don't know enough to be sure. Others might correct me. cheers -ben

Sept. 6, 2014