Re: [Pharo-users] How to create a red box with text in a big font?

[Hilaire]

Le 05/09/2014 08:43, p...@highoctane.be a écrit :

Yes there is that annoying thing with windows that set things bacl to
white. Why is that indeed?


It is Window theme to keep it consistant I guess

--
Dr. Geo - http://drgeo.eu
iStoa - http://istao.drgeo.eu

Re: [Pharo-users] not a smalltalk!

[Esteban Lorenzano]

no smalltalk around is “smalltalk”, technically they are all dialects and Pharo 
is just one dialect more.
smalltalk-80 itself does not exist since… well, smalltalk-80 :)

so no, your code would not be directly portable to other smalltalks (with the 
possible exception of gemstone). 

Esteban

On 05 Sep 2014, at 20:25, Mayuresh Kathe  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
> 
> 

[Pharo-users] Syntax Error: Cannot store into

[Mark Rizun]

Hi everyone!

When loading a package via Monticello, while compiling methods it gives an
error:
Syntax Error: Cannot store into and then a method.
What does it mean?

Best,
Mark



--
View this message in context: 
http://forum.world.st/Syntax-Error-Cannot-store-into-tp4776675.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Re: [Pharo-users] Syntax Error: Cannot store into

[Esteban Lorenzano]

which package?


On 06 Sep 2014, at 10:28, Mark Rizun  wrote:

> Hi everyone!
> 
> When loading a package via Monticello, while compiling methods it gives an
> error:
> Syntax Error: Cannot store into and then a method.
> What does it mean?
> 
> Best,
> Mark
> 
> 
> 
> --
> View this message in context: 
> http://forum.world.st/Syntax-Error-Cannot-store-into-tp4776675.html
> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
> 

Re: [Pharo-users] Syntax Error: Cannot store into

[Mark Rizun]

Package of my project RewriteTool.
Here it is:
http://smalltalkhub.com/#!/~MarkRizun/RewriteTool/packages/RewriteTool


2014-09-06 11:33 GMT+03:00 Esteban Lorenzano :

> which package?
>
>
> On 06 Sep 2014, at 10:28, Mark Rizun  wrote:
>
> > Hi everyone!
> >
> > When loading a package via Monticello, while compiling methods it gives
> an
> > error:
> > Syntax Error: Cannot store into and then a method.
> > What does it mean?
> >
> > Best,
> > Mark
> >
> >
> >
> > --
> > View this message in context:
> http://forum.world.st/Syntax-Error-Cannot-store-into-tp4776675.html
> > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
> >
>
>
>

Re: [Pharo-users] Syntax Error: Cannot store into

[Esteban Lorenzano]

well, this is weird :)
the error you have is usually because you have something like this:

myMethod: aParameter
…
aParameter := something.
…

(same can happen with blocks). 

you cannot assign a parameter… and compiler protests if you try. 
but I wander how you could introduce the problem the first time. Compiler 
should deny that kind of construction. 

Anyway, your fix is to change that :)

Esteban

On 06 Sep 2014, at 10:39, Mark Rizun  wrote:

> Package of my project RewriteTool.
> Here it is: 
> http://smalltalkhub.com/#!/~MarkRizun/RewriteTool/packages/RewriteTool
> 
> 
> 2014-09-06 11:33 GMT+03:00 Esteban Lorenzano :
> which package?
> 
> 
> On 06 Sep 2014, at 10:28, Mark Rizun  wrote:
> 
> > Hi everyone!
> >
> > When loading a package via Monticello, while compiling methods it gives an
> > error:
> > Syntax Error: Cannot store into and then a method.
> > What does it mean?
> >
> > Best,
> > Mark
> >
> >
> >
> > --
> > View this message in context: 
> > http://forum.world.st/Syntax-Error-Cannot-store-into-tp4776675.html
> > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
> >
> 
> 
> 

Re: [Pharo-users] Syntax Error: Cannot store into

[Mark Rizun]

You are right there is such a code.
And it's really strange how it compiled earlier:)
Thanks


2014-09-06 11:42 GMT+03:00 Esteban Lorenzano :

> well, this is weird :)
> the error you have is usually because you have something like this:
>
> myMethod: aParameter
> …
> aParameter := something.
> …
>
> (same can happen with blocks).
>
> you cannot assign a parameter… and compiler protests if you try.
> but I wander how you could introduce the problem the first time. Compiler
> should deny that kind of construction.
>
> Anyway, your fix is to change that :)
>
> Esteban
>
> On 06 Sep 2014, at 10:39, Mark Rizun  wrote:
>
> Package of my project RewriteTool.
> Here it is:
> http://smalltalkhub.com/#!/~MarkRizun/RewriteTool/packages/RewriteTool
>
>
> 2014-09-06 11:33 GMT+03:00 Esteban Lorenzano :
>
>> which package?
>>
>>
>> On 06 Sep 2014, at 10:28, Mark Rizun  wrote:
>>
>> > Hi everyone!
>> >
>> > When loading a package via Monticello, while compiling methods it gives
>> an
>> > error:
>> > Syntax Error: Cannot store into and then a method.
>> > What does it mean?
>> >
>> > Best,
>> > Mark
>> >
>> >
>> >
>> > --
>> > View this message in context:
>> http://forum.world.st/Syntax-Error-Cannot-store-into-tp4776675.html
>> > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
>> >
>>
>>
>>
>
>

Re: [Pharo-users] Syntax Error: Cannot store into

[Yuriy Tymchuk]

If you missed our discussion with Marcus, Opal allowed constructs like that 
until week ago.

Uko

Sent from my iPhone

> On 06 Sep 2014, at 10:46, Mark Rizun  wrote:
> 
> You are right there is such a code.
> And it's really strange how it compiled earlier:)
> Thanks
> 
> 
> 2014-09-06 11:42 GMT+03:00 Esteban Lorenzano :
>> well, this is weird :)
>> the error you have is usually because you have something like this:
>> 
>> myMethod: aParameter
>>  …
>>  aParameter := something.
>>  …
>> 
>> (same can happen with blocks). 
>> 
>> you cannot assign a parameter… and compiler protests if you try. 
>> but I wander how you could introduce the problem the first time. Compiler 
>> should deny that kind of construction. 
>> 
>> Anyway, your fix is to change that :)
>> 
>> Esteban
>> 
>>> On 06 Sep 2014, at 10:39, Mark Rizun  wrote:
>>> 
>>> Package of my project RewriteTool.
>>> Here it is: 
>>> http://smalltalkhub.com/#!/~MarkRizun/RewriteTool/packages/RewriteTool
>>> 
>>> 
>>> 2014-09-06 11:33 GMT+03:00 Esteban Lorenzano :
 which package?
 
 
 On 06 Sep 2014, at 10:28, Mark Rizun  wrote:
 
 > Hi everyone!
 >
 > When loading a package via Monticello, while compiling methods it gives 
 > an
 > error:
 > Syntax Error: Cannot store into and then a method.
 > What does it mean?
 >
 > Best,
 > Mark
 >
 >
 >
 > --
 > View this message in context: 
 > http://forum.world.st/Syntax-Error-Cannot-store-into-tp4776675.html
 > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
 >
> 

Re: [Pharo-users] Syntax Error: Cannot store into

[Mark Rizun]

Now that's not strange.
Thanks for info


2014-09-06 11:49 GMT+03:00 Yuriy Tymchuk :

> If you missed our discussion with Marcus, Opal allowed constructs like
> that until week ago.
>
> Uko
>
> Sent from my iPhone
>
> On 06 Sep 2014, at 10:46, Mark Rizun  wrote:
>
> You are right there is such a code.
> And it's really strange how it compiled earlier:)
> Thanks
>
>
> 2014-09-06 11:42 GMT+03:00 Esteban Lorenzano :
>
>> well, this is weird :)
>> the error you have is usually because you have something like this:
>>
>> myMethod: aParameter
>> …
>> aParameter := something.
>> …
>>
>> (same can happen with blocks).
>>
>> you cannot assign a parameter… and compiler protests if you try.
>> but I wander how you could introduce the problem the first time. Compiler
>> should deny that kind of construction.
>>
>> Anyway, your fix is to change that :)
>>
>> Esteban
>>
>> On 06 Sep 2014, at 10:39, Mark Rizun  wrote:
>>
>> Package of my project RewriteTool.
>> Here it is:
>> http://smalltalkhub.com/#!/~MarkRizun/RewriteTool/packages/RewriteTool
>>
>>
>> 2014-09-06 11:33 GMT+03:00 Esteban Lorenzano :
>>
>>> which package?
>>>
>>>
>>> On 06 Sep 2014, at 10:28, Mark Rizun  wrote:
>>>
>>> > Hi everyone!
>>> >
>>> > When loading a package via Monticello, while compiling methods it
>>> gives an
>>> > error:
>>> > Syntax Error: Cannot store into and then a method.
>>> > What does it mean?
>>> >
>>> > Best,
>>> > Mark
>>> >
>>> >
>>> >
>>> > --
>>> > View this message in context:
>>> http://forum.world.st/Syntax-Error-Cannot-store-into-tp4776675.html
>>> > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com
>>> .
>>> >
>>>
>>>
>>>
>>
>>
>

Re: [Pharo-users] not a smalltalk!

[PBKResearch]

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-boun...@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 mailto:yuriy.tymc...@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 mailto:mayur...@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
>
>



 

Re: [Pharo-users] Syntax Error: Cannot store into

[Esteban Lorenzano]

he, I missed that discussion :)
good to know!

Esteban

On 06 Sep 2014, at 10:53, Mark Rizun  wrote:

> Now that's not strange.
> Thanks for info
> 
> 
> 2014-09-06 11:49 GMT+03:00 Yuriy Tymchuk :
> If you missed our discussion with Marcus, Opal allowed constructs like that 
> until week ago.
> 
> Uko
> 
> Sent from my iPhone
> 
> On 06 Sep 2014, at 10:46, Mark Rizun  wrote:
> 
>> You are right there is such a code.
>> And it's really strange how it compiled earlier:)
>> Thanks
>> 
>> 
>> 2014-09-06 11:42 GMT+03:00 Esteban Lorenzano :
>> well, this is weird :)
>> the error you have is usually because you have something like this:
>> 
>> myMethod: aParameter
>>  …
>>  aParameter := something.
>>  …
>> 
>> (same can happen with blocks). 
>> 
>> you cannot assign a parameter… and compiler protests if you try. 
>> but I wander how you could introduce the problem the first time. Compiler 
>> should deny that kind of construction. 
>> 
>> Anyway, your fix is to change that :)
>> 
>> Esteban
>> 
>> On 06 Sep 2014, at 10:39, Mark Rizun  wrote:
>> 
>>> Package of my project RewriteTool.
>>> Here it is: 
>>> http://smalltalkhub.com/#!/~MarkRizun/RewriteTool/packages/RewriteTool
>>> 
>>> 
>>> 2014-09-06 11:33 GMT+03:00 Esteban Lorenzano :
>>> which package?
>>> 
>>> 
>>> On 06 Sep 2014, at 10:28, Mark Rizun  wrote:
>>> 
>>> > Hi everyone!
>>> >
>>> > When loading a package via Monticello, while compiling methods it gives an
>>> > error:
>>> > Syntax Error: Cannot store into and then a method.
>>> > What does it mean?
>>> >
>>> > Best,
>>> > Mark
>>> >
>>> >
>>> >
>>> > --
>>> > View this message in context: 
>>> > http://forum.world.st/Syntax-Error-Cannot-store-into-tp4776675.html
>>> > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
>>> >
>>> 
>>> 
>>> 
>> 
>> 
> 

Re: [Pharo-users] not a smalltalk!

[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  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-boun...@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  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  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
> >
> >
> 

[Pharo-users] timing problem

[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

Re: [Pharo-users] not a smalltalk!

[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 :

> 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  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-boun...@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 
> 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  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
> >
> >
>
>
>

Re: [Pharo-users] timing problem

[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

Re: [Pharo-users] timing problem

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

werner

Re: [Pharo-users] not a smalltalk!

[Ben Coman]

Sergi Reyner wrote:

  In my opinion, this dialect thing is getting
increasingly silly. And confusing. And silly.


Identity and vision are important parts of community building.  I
wasn't around when Pharo forked from Squeak, but I can see it was
useful to build a separate identity to distinguish between the
projects.  It helps bring those with similar vision along for the
ride.  Shredding the shackles of backward compatibility required for
some projects dug deep into Squeak seems like it was a significant
factor at the time.   Today I think its remains beneficial to indicate
this vision up front, so that people considering Pharo are not later
"surprised" as Pharo moves towards its vision, if "all" they wanted was
Smalltalk-80.  

cheers -ben


  
  2014-09-06 10:01 GMT+01:00 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  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-boun...@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 
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 
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
>
>

  
  
  
  
  






  
  
  
  

Re: [Pharo-users] not a smalltalk!

[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

Re: [Pharo-users] timing problem

[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' ? 


Sorry, I can't tell across email if that  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

[Pharo-users] Weakness

[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

Re: [Pharo-users] Weakness

[Sven Van Caekenberghe]

Magnitude weakSubclass: #WeakKeyAssociation
instanceVariableNames: 'value'
classVariableNames: ''
category: 'Collections-Support'

weakSubclass: ...

On 06 Sep 2014, at 16:47, Ben Coman  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
> 

Re: [Pharo-users] Weakness

[Ben Coman]

Sven Van Caekenberghe wrote:

  Magnitude weakSubclass: #WeakKeyAssociation
	instanceVariableNames: 'value'
	classVariableNames: ''
	category: 'Collections-Support'

weakSubclass: ...
  


Oh! the shame

Thanks Sven.
 

  
On 06 Sep 2014, at 16:47, Ben Coman  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


  
  


  

Re: [Pharo-users] timing problem

[Werner Kassens]

> Sorry, I can't tell across email if that  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

Re: [Pharo-users] not a smalltalk!

[p...@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"  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 :
>>
>> 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  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-boun...@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 
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  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
 >
 >
>>
>>
>

Re: [Pharo-users] not a smalltalk!

[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

Re: [Pharo-users] not a smalltalk!

[Sven Van Caekenberghe]

On 06 Sep 2014, at 17:42, p...@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 !

Re: [Pharo-users] timing problem

[Ben Coman]

Werner Kassens wrote:

> Sorry, I can't tell across email if that  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

Re: [Pharo-users] not a smalltalk!

[Pierce Ng]

On Sat, Sep 06, 2014 at 06:09:15PM +0200, Thierry Goubier wrote:
> Yes. Who remember the differences between Envy / Parcplace /
> Digitalk / Smalltalk-mt / Smalltalk/X / Dolphin Smalltalk ?

I still play with Smalltalk/X. It is very different from Pharo, but it is an
implementation of Smalltalk nonetheless, just like Pharo is.

Is there any true/pure Smalltalk-80 implementation in use still?

Pierce