Re: Serious bug in 3.10

2008/8/1 Ramon Leon <ramon.leon <at> allresnet.com>:
>
>> askoh wrote:
>> > | block |
>> > block := [:i | Transcript cr; show: i].
>> > 1 to: 10 do: [:i | block value: i+1]
>> >
>> > The above should print ten times. But it only prints the
>> five even numbers.
>> > That is a bug isn't it?
>> >
>> > Aik-Siong Koh
>> >
>> More of a "known limitation" than a bug... due to the fact
>> that squeak
>> does not have proper closures.
>>
>> try
>>
>> | block |
>> block := [:j | Transcript cr; show: j].
>> 1 to: 10 do: [:i | block value: i+1]
>>
>> Keith
>
> I was going to say that, but why does it work using (1 to: 10) do: rather
> than 1 to: 10 do:, seems related to #to:do: being inlined?
>

#to:do: is a hacky compiler optimization, which replaces true messages. :)

Re: Serious bug in 3.10

Re: Serious bug in 3.10

Re: Serious bug in 3.10

Ramon Leon <ramon.leon <at> allresnet.com> writes:

> 
> > Sent: Thursday, July 31, 2008 3:33 PM
> > To: squeak-dev <at> lists.squeakfoundation.org
> > Subject: [squeak-dev] Serious bug in 3.10
> > 
> > 
> > | block |
> > block := [:i | Transcript cr; show: i].
> > 1 to: 10 do: [:i | block value: i+1]
> > 
> > The above should print ten times. But it only prints the five 
> > even numbers.
> > That is a bug isn't it?
> > 
> > Aik-Siong Koh
> 
> Try this..
> 
> block := [:f | Transcript cr; show: f].
> (1 to: 10) do: [:f | block value: f+1]
> 
> And you'll see that likely, to:do: is being inlined by the compiler and
> causing something funny like allowing you to increment the loops index var
> causing it to skip a number each iteration.
> 
> Ramon Leon
> http://onsmalltalk.com
> 
> 

Yes but:

block := [:f | Transcript cr; show: f].
(1 to: 10) do: [:f | block value: f+1. block value: f].

does not behave much better...
the 10 loops are performed, but since the blocks share same temporary f, things
are still a bit strange.

You need to use different argument names, NewCompiler or Eliot's closures.

Conditions for infinite recursion in TTCFont>>ascent

[squeak-dev] Q: Is it all right for TTCfonts to have non-integer heights?

Hi Yoshiki,

Thanks for the reply and the clues. 

Yoshiki Ohshima yoshiki at vpri.org 
Thu Jul 31 22:45:58 UTC 2008 

> >  In the Squeak world, it is ok if it works^^;
> 
> I know. But I doesn't quite. 
> TTCFont>>ascent has a code hole
>  that leads to infinite recursion under certain conditions. 
> There are several different versions of TTCFont>>ascent.
> AFAIK all the ones currently in use including oplc/3.8 have this property. 
> Ralph Johnson patched around this in 3.10. 
> To prevent the certain condition, fallback fonts are limited to strikefonts.
>  IMO this is unsatisfactory and undesirable.

Youshiki:>  Could you tell me the certain condition?

See Mantis: 
0006664: TTCFont>ascent can be infinitely recursive.
http://bugs.squeak.org/view.php?id=6664
for all the gory details. 

For strikefonts ascent is just a variable accessor wherever it is used.
This should probably be the case for TTCFonts too. 
(i.e. ascent should be the straight forward calculation
 without involving the fall back font.
For some reason a caluclation for ascent involves
 the calculation of the fixed fonts ascent. 
Which means a calculation of the fixed fonts basefont ascent.
If we and the basefont are the same, kaboom, infinite recursion.
If ascent were just a calculation
 and the picking of the maximum height happened elsewhere
 that would be IMO be the elegant fix.

In 3.9 - 3.10  I wrote a test which set up these conditions, 
then left them there in the image. 

(Not intentionally, but my friend Puck holds
 I just wrote a better test than I had imagined.
 And caught this second bug as well.
 I'm afraid Puck likes the tests that smoke the image best. 

On the second pass of testing everything blew up on the poor harvesters.
Thus finding the recursion bug.

> So if you could give this matter a little more serious thought
>  and help my quest for understanding with a clue or two? 
> It would be appreciated.

Youshiki:> Sorry if my previous message sounded ignorant.

I asked the question non-urgently. 
Your first response led to the second, which has been helpful.

Thank you.

Yours in curiosity and service, --Jerome Peace

RE: Re: Serious bug in 3.10

> > 
> > And you'll see that likely, to:do: is being inlined by the 
> compiler and
> > causing something funny like allowing you to increment the 
> loops index var
> > causing it to skip a number each iteration.
> > 
> > Ramon Leon
> > http://onsmalltalk.com
> > 
> > 
> 
> Yes but:
> 
> block := [:f | Transcript cr; show: f].
> (1 to: 10) do: [:f | block value: f+1. block value: f].
> 
> does not behave much better...
> the 10 loops are performed, but since the blocks share same 
> temporary f, things
> are still a bit strange.
> 
> You need to use different argument names, NewCompiler or 
> Eliot's closures.

Oh I agree, I wasn't suggesting a solution, I know the scope of the args is
shared because of the lack of real closures.  I was more inquiring why the
behavioral difference between (to:) do: and to:do: since the latter is
inlined but normally you'd expect them to be equivalent.

Ramon Leon
http://onsmalltalk.com

RepeatTimesMorphicTile

Re: RepeatTimesMorphicTile

El 8/1/08 8:21 AM, "Luis Valente" <is.valente <at> gmail.com> escribió:

> Hi,
> 
> I recently found the RepeatTimesMorphicTile in SqueakMap but can´t figure out
> how to use it in Squeak 3.9. Since it is supposed to have a place in the tile
> to put a number of times to repeat the script I couldn't discover how to
> achieve this. Is there any missing trick?
> Squeak OLPC has a tile to control the times we want to repeat a script, but
> the same functionality isn't present in Squeak 3.9 etoys. A similar feature
> will be useful.
> Any hel welcome.
> 
> -- 
> All the best,
> Luis Valente

Luis:
If you understand Spanish, could join to

http://ar.groups.yahoo.com/group/squeakRos/ (Group)

And have few help here.

http://wiki.gnulinex.org/squeakros (Swiki in Spain)
http://ar.geocities.com/edgardec2001/Welcome.html (Beginners tutorials ,
most in Spanish)

3.9 and 3.10 was over, no people work on Etoys here.

OLPC  guys was who knows more and any future Etoys have is on his images.
3.10 have Etoys only for Ralph and me wish be more compatible as at the time
all the reload part was unfinished.
I don't have idea about 3.11 , my own SqueakLightII try to be and don't have
Etoys or Nebraska (and not others packages) but could be reload at will.

I have the last OLPC and have plans to my pet was useful to people wishing
Etoys, to people wishing Web, to people liking Test, etc.

So if you like go to http://wiki.squeak.org/squeak/6056 and add your
request.
I see how to have into the image.

Edgar

Re: Immutability (was Re: About String vs Symbols)

On Jul 30, 2008, at 9:06 AM, Colin Putney wrote:

>
> On 29-Jul-08, at 1:24 PM, Eliot Miranda wrote:
>
>> BTW, immutability involves primitive error codes and I will be  
>> introducing primitive error codes, because the performance hit is  
>> essentially zero and there is no backward compatibility issue  
>> (strange but true :) ).
>
> I'm all for general immutability support in the VM.
>
> I suspect, though, that this isn't what Stéphane was driving at.  
> Immutable strings is kind of a language-level thing, and could be  
> done without VM support.  One way would be to factor out a  
> MutableString class and keep it distinct from regular strings. Going  
> further, we could just remove the mutation protocol and require all  
> string creation to be either stream-based or functional (ie,  
> producing new strings rather than mutating existing ones).

for example.
>
>
> Once strings are immutable, interning them is a useful space  
> optimization, and that *would* make symbols redundant.
>
> Clearly there are huge compatibility issues here, but it's a  
> reasonable thing to consider if building a system from scratch.
>
> Colin
>

Re: Help: need pangocairo.pc

  Subbu,

> The Etoys vm (3.10-3/squeak) reports the following error on Ubuntu Gutsy when 
> running etoys-dev-3.0 image:
> >ioFindExternalFunctionIn(primitiveUTF8StringWithIndex, 0x810ccf8):
> >  /usr/local/lib/squeak/3.10-3/RomePlugin: undefined symbol: 
> primitiveUTF8StringWithIndex

  This looks like you are not using the very latest RomePlugin (The
squeaksource seems to be down at the moment, but you can get it from
there).  Also, make sure that the image is fully updated (which I
think you did).

-- Yoshiki