[Vm-dev] Compiling squeak-vm for Linux 64bit

[Bert Freudenberg]

On 17.03.2009, at 13:38, José L. Redrejo Rodríguez wrote:

> El mar, 17-03-2009 a las 12:45 +0100, Bert Freudenberg escribió:
>> On 17.03.2009, at 11:28, José L. Redrejo Rodríguez wrote:
>>
>>> El mar, 17-03-2009 a las 10:32 +0100, Bert Freudenberg escribió:
>>>>
>>>> That is interesting news. I was not aware anybody is seriously
>>>> wanting
>>>> to use Etoys on 64 bits. Besides, I though that amd64 is capable of
>>>> running 64 and 32 bit software side-by-side just fine so there is  
>>>> no
>>>> urgent need to clean up the VM (although I'm of course thankful to
>>>> David who is hacking away on this). As far as I know it's not
>>>> "emulation" at all, so why do you say it runs "poorly"?
>>> Not, it's not emulation, and running 32 bits applications in a 64  
>>> bits
>>> environment works, it's what I'm doing, but the perfomance is worse,
>>
>> Really? How did you measure that?
>
>
> It's a total subjetive impression: big projects take more time to load
> in this environment, than in a pure 32 bits environment.

I'd be interested in seeing benchmark numbers. If there is indeed a 32  
bit emulation layer then this is possible (although I'd find it hard  
to imagine).

>>> and
>>> the integration with the user desktop with all the applications (and
>>> the
>>> desktop itself) running in 64 bits has aesthetical issues. And you
>>> know,
>>> for end users, the way an application looks uses to be important.
>>
>> Huh? How does Etoys in 64 bits look different from 32 bits?
>>
>
>
> Obviously, it's not Etoys , but the windows that contains etoys (i.e.:
> gtk or qt theme, etc.)

Oh. Now that's silly. So you mean a 32 bit application cannot open a  
window on a display that is running a 64 bit window manager? That  
cannot be, or you could not run 64 bit and 32 bit apps side by side.

The only reason I could see is that the window manager decorates the  
Etoys window differently from other windows. Does the window  
decoration really change when you use the 64 bit VM?

Or maybe the way you run Squeak confuses the window manager - how  
exactly do you do it?

>>> So, for my end users, I've workarounded most of the problems (appart
>>> from the browser plugin that segfaults in 32 bits whenever you close
>>> the
>>> tab where it's running), but the problems are still there,
>>
>> Yes, I have not worked on the plugin in a while. Sorry. The plugin is
>> not used in Sugar, so I did not pay much attention to it. When I find
>> some spare time I will look into it. Patches welcome of course, as
>> well as links to detailed bug reports.
>
> I'll fill a bug in  mantis, but in brief, the test is pretty easy: use
> firefox, open a new tab and load a squeak project. Then try to close
> that tab, and firefox segfaults. The same if you just clic on the back
> button of the browser.
>
>
>
>
>>
>>> and everyday
>>> there are more people trying to use amd64 and don't want (or don't
>>> know)
>>> to hack the applications to make them work. And there are some
>>> projects
>>> (as the sugar project in Debian, or Debian Edu) that want to use
>>> Squeak
>>> and are stalled because of the 64 bits issues.
>>
>> Seriously, that's the first time I hear that 64 bits issues are
>> stalling anything related to Etoys.
>>
>
>
> 64 bits issues are stalling the use of etoys in Debian, and inside
> Debian it's doing it in the sugar project (it's not the only problem,
> bootstrapping of the image and license are a problem, as we both know
> well)

I am not aware of any more license issues. They still don't like the  
image concept, yes.

>>> I don't know if that's
>>> urgent for the Squeak community, but it's something that has to be
>>> known
>>> to decide if it is important or not. That's why I begun my
>>> intervention
>>> in this thread answering to David that the 64-bits are needed not  
>>> only
>>> for hobbyists, but for many more people.
>>
>>
>> Well, thanks for speaking up. You have to distinguish between the
>> squeak.org community and the Etoys community. Both talk about  
>> "Squeak"
>> but mean entirely different things. Most in the squeak.org community
>> do not think of Squeak as a product with users, but rather as a tool
>> they only use themselves. E.g., there is even resistance to  
>> creating a
>> squeak-users mailing list aimed at Smalltalk developers who just want
>> to use Squeak for developing :/
>>
>> This is different for the Etoys community. They see "Squeak Etoys" is
>> an educational tool that is used by teachers, parents, and children.
>> The new "Squeakland Foundation" was created to support that  
>> community.
>> They will have an open ear to your concerns.
>>
>> The VM guys here basically churn away on keeping up the illusion that
>> Squeak simply works ;)
>>
>
> I know, I know. For those who don't know it, my concerns are related
> only to the use  of Squeak in education. Some years ago, there was no
> difference between Squeak and eToys, today, it mainly means eToys, but
> eToys need the vm to work...


Indeed :) It helps to call it "Etoys" on Squeak mailing lists because  
not everyone can remember who is actually using Etoys and who another  
Squeak version.

- Bert -