- Pharo-users - lists.pharo.org

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

Re: [Pharo-users] not a smalltalk!

by stepharo

> 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. 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 :) Stef

Sept. 6, 2014

Re: [Pharo-users] not a smalltalk!

by Ben Coman

Sept. 6, 2014

Re: [Pharo-users] timing problem

by Werner Kassens

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> and what is the disadvantage of the simple first solution, i have to admit i never looked at these fork things? werner

Sept. 6, 2014

Re: [Pharo-users] timing problem

by Ben Coman

Werner Kassens wrote: > Hi, > i ran a program that did some calculations for about an hour. in > between i occasionally moved the cursor (so that the computer did not > go to sleep) and probably clicked occasionally on the browser. after > some time this resulted in several errors from the browser (the > program itself does nothing with the browser). when i tried to > reproduce this, the program ran flawlessly (i retried it in 4.0., as i > thought it happened there but perhaps it happened in 3.0, and btw it > was much faster in 4.0 than in earlier versions). now i wonder whether > i should regularly cede some time to other processes, and if yes, how > does one do that? > werner > > 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? 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. cheers -ben

Sept. 6, 2014

Re: [Pharo-users] not a smalltalk!

by Sergi Reyner

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 > <pharo-users-bounces(a)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

timing problem

by Werner Kassens

Hi, i ran a program that did some calculations for about an hour. in between i occasionally moved the cursor (so that the computer did not go to sleep) and probably clicked occasionally on the browser. after some time this resulted in several errors from the browser (the program itself does nothing with the browser). when i tried to reproduce this, the program ran flawlessly (i retried it in 4.0., as i thought it happened there but perhaps it happened in 3.0, and btw it was much faster in 4.0 than in earlier versions). now i wonder whether i should regularly cede some time to other processes, and if yes, how does one do that? werner

Sept. 6, 2014

Re: [Pharo-users] not a smalltalk!

by Esteban Lorenzano

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