Compiling squeak-vm for Linux 64bit
Locked
12
12
Re: Compiling squeak-vm for Linux 64bit
 
|
On 16.03.2009, at 23:26, whaevr wrote:
Ah, right, that was fixed only 3 weeks ago, and there was no point release since. - Bert - |
Squeak users (was Re: Compiling squeak-vm for Linux 64bit)
|
|
In reply to this post by Göran Krampe
On 17.03.2009, at 13:36, Göran Krampe wrote: > Hi! > > Really wrong forum, but what the heck. Wrong indeed. Reply-to set to squeak-dev. For those coming late: the original thread starts to get interesting around here: http://lists.squeakfoundation.org/pipermail/vm-dev/2009-March/002427.html > Bert Freudenberg wrote: >> 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 :/ > > Interesting. I wonder if I am one of those "resisting". When I heard > the idea of creating a squeak-users list I first thought that, no, > Squeak is not polished enough to be just "used" as a multimedia > environment. > > Because I didn't think of "using" to possibly could have meant > "using for development"! Yeah, call me daft. Hehe. Well, at least I am trying to always distinguish between "Etoys" and "Squeak". This was not always necessary, and in particular the education community refers to Etoys as Squeak out of habit. But around here "Squeak" means Smalltalk development. > Another reason is probably that I don't understand why anyone would > only want to "use" Squeak without any interest in how it is being > moved forward nor how it works inside. When you develop in Squeak > you typically invest in its future, so why on earth would you not be > considering yourself a member of the "squeak-dev" community? Good question. But when you develop in, say, Python, don't you "invest in its future"? Still, most Python users would not contribute to Python directly, right? But indirectly they do. In my opinion broadening the user base of Squeak would have long-term benefits. Yes you may get more annoying questions, but that's what the proposed users list would be for (initially anyway - there might even be more books if there was a real market). With more Squeak users there also would be more who jump the fence and become Squeak developers. Which would cover your next point ... > Anyway, for other "development tools" I can see myself more clearly > as a "user" - but a Smalltalk environment is so intertwined with > itself that I don't see that separation. I also do not like squeak- > dev turning into some kind of "club for the mighty developers". > Which is why I was hesitant about the beginners list too - although > I probably was wrong there. > > [SNIP] >> They will have an open ear to your concerns. > > I do think Squeakers in general have a very "open ear" - it is not > ears we lack, it is time to spend in solving problems that someone > else has that we lack. :) At least most of us lack it. > > regards, Göran ... which is that each individual only has so much time. But if we had a larger community and made it really easy to contribute, we'd still move much faster. - Bert - |
Re: Compiling squeak-vm for Linux 64bit
|
|
In reply to this post by José "L. Redrejo" Rodríguez
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 - |
Re: Compiling squeak-vm for Linux 64bit
|
|
In reply to this post by José "L. Redrejo" Rodríguez
On Tue, Mar 17, 2009 at 08:37:00AM +0100, Jos? L. Redrejo Rodr?guez wrote: > > And many other places using Debian Edu now know of Squeak and, whenever > they want to use a good ltsp server for the classes, they can not use > Squeak. So, from my point of view, at least fixing sound and pango is > urgent in 64 bits VMs, as both things are used by default in the etoys > image. Fixing the browser plugin should be done also for all the archs, > obviously. Jos??, Thank you for bringing this up. It's good to know that this is important, and as you can see, most of us on this list were not aware of the interest. For my part, I will try to resolve the issues on 64-bit sound and pango when I get some free time. But this will not be until April because I will be away on vacation until then. And of course I am just a hobby hacker so don't expect too much right away ;) Dave |
|
|
In reply to this post by José "L. Redrejo" Rodríguez
Someone might want to look into if the project read is using the multibyte streams in text mode. If so in my past experience with Sophie is that a read requires reading byte by byte, which actually ends up reading a byte by byte from the file system. Although this is *fast* (a relative term) because stdio caches data for reading, perhaps the 32 to 64 thunking between the C code and the 32/64 stdio is intensive. For Sophie and other products we would suck the entire file into a read//write internal stream, then pass that to the multibyte stream reader. For writing the pattern is even worse because the multi-byte logic in text mode writes one byte at a time. Write 5 mb and it's 5 million system calls and the overhead is quite large. For Sophie we built a caching output stream that would stream out to memory, then at close time flush the contents to the file stream. PS you can see this on unix systems by looking at system calls (or the like). On 17-Mar-09, at 5:38 AM, José L. Redrejo Rodríguez wrote: > It's a total subjetive impression: big projects take more time to load > in this environment, than in a pure 32 bits environment. -- = = = ======================================================================== John M. McIntosh <[hidden email]> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ======================================================================== |
«
Return to Squeak VM
|
1 view|%1 views
| Free forum by Nabble | Edit this page |