Squeak-dev March 2008

squeak-dev@lists.squeakfoundation.org

157 participants
229 discussions

FFI and FreeTypePlus problem?
by Torsten Bergmann 23 Oct '08

23 Oct '08

I already created a bug report for this, Andreas may be able to tell you more: http://bugs.squeak.org/view.php?id=6980 As a workaround you can can use FFI-Kernel-ar6.mcz instead of FFI-Kernel-ar-8.mcz. Bye Torsten -- GMX startet ShortView.de. Hier findest Du Leute mit Deinen Interessen! Jetzt dabei sein: http://www.shortview.de/?mc=sv_ext_mf@gmx

10 13

3.10 is done
by Ralph Johnson 08 Sep '08

08 Sep '08

3.10 is done. It has been stable for a long time, and Edgar was just waiting for me to write a welcome screen. I've done that, so he can make a final image. The thing that we did that I like the best is making Package Universe prominent. While not perfect, it has worked well. The thing that disappoints me the most is that there are still a few tests that are not green. It looks like a committee has formed to work on the next release, and I wish them the best. I want to thank Edgar for all the hard work he did on 3.10. He did almost all the work, and did an excellent job. -Ralph Johnson

4 4

3.10 image
by itsme213 15 Jul '08

15 Jul '08

I the damien-3.10-web image size is quite large (129M) compared to a comparably (not identical) loaded 3.9 Ramon's image (42M). Is that expected, or is it because as a beta it has not been trimmed etc.? Thanks - Sophie

8 13

Re: [squeak-dev] Renaming "Squeak"
by Bill Schwab 20 May '08

20 May '08

Alan, Agreed. The name is not nearly so important as the fundamentals of a solid Smalltalk system. Focusing on the latter serves everyone: the children for whom all this was started; the adults who will set them up with something they can use; and other developers wanting to work in Smalltalk. If we do create a ViewPoints Smalltalk, or whatever it gets named, then we should do it right. Fix the gratuitous incompatibilities with other dialects, clean up the look and (far more important) the feel of the GUI, and arrange for the toys and the experiments to be built on top of vs. into the core language and environment. However, that is good advice whether the names changes or not. Bill ==================================== Alan Lovejoy <squeak-dev.sourcery@...> wrote: Squeak is not the most professional-sounding name that could have been chosen. One very important purpose of a name is marketing, and the name "Squeak" doesn't do that very well in a few rather important markets. Of course, if you're marketing to children (and those who educate them,) then Squeak is not at all a bad name. But that's all water under the bridge at this point. Changing the name only, in the absence of any other substantive changes, would at best be ignored as a shameless (and not well-motivated) marketing ploy. At worst, it would be seen as an act of desperation. Change Squeak so that it deserves a new name. Then the new name will be perceived as having been earned, and so will serve as an effective marketing tool to advertise the new, improved "Open Source Smalltalk." --Alan Wilhelm K. Schwab, Ph.D. University of Florida Department of Anesthesiology PO Box 100254 Gainesville, FL 32610-0254 Email: bschwab(a)anest.ufl.edu Tel: (352) 846-1285 FAX: (352) 392-7029

11 13

Renaming "Squeak"
by Michael van der Gulik 14 May '08

14 May '08

On Sun, Mar 2, 2008 at 3:22 AM, K. K. Subramaniam <subbukk(a)gmail.com> wrote: > On Saturday 01 March 2008 5:34:52 am Craig Latta wrote: > > Let's turn our attention to Squeak 4 now. Let's create a kernel > > with nothing extraneous in it, and a module system we can use to keep > > the organization clear. I think the result will be much easier to learn, > > and far more pleasant to use. Getting there will be difficult, but it > > will be worth it. > If we are going to strip Squeak down and rebuild it, should we consider > picking a new name for the project? The name Squeak has been around for > more > than a decade and has strong associations (good or bad) with certain > feature > sets and intended uses. A legally clear open source base is a good time to > invent a new platform that can consolidate the lessons learnt from the > Squeak > project and build a new system for the next generation - just as Squeak > emerged from Smalltalk-80. > > Spoon? Hydra? Athena? Phoenix? Roar :-)? > I've thought about this too. "Squeak" is a name that's hard to take seriously, and I for one would be less inclined to advertise that any product I make is based on "Squeak". However, there's a large investment in the name - URLs, source code, public awareness, etc. The name is unlikely to change. In my opinion, Squeak should be a minimal image that is used as a base or a template to create other projects that have different names. Squeak could be thought of as an internal development name that only us coders need to be aware of. What is advertised to the outside world are the names of the other projects, with a small note on the bottom of the packaging saying "Made with Squeak". Mind you, Linux is taken seriously, and they use a fat penguin as a mascot. Gulik. -- http://people.squeakfoundation.org/person/mikevdg http://gulik.pbwiki.com/

22 37

[ANN] ESUG 2008 Call for Contribution
by stephane ducasse 04 May '08

04 May '08

Hi all we are really happy to announce that ... --------------------------------------------------------------------- 16th International Smalltalk Joint Conference - Call for Contributions August 25-29, 2008 - Amsterdam, the Netherlands http://www.esug.org/conferences/2008/ ---------------------------------------------------------------------- For the past 16 years, the European Smalltalk User Group (ESUG) has organised the International Smalltalk Conference, a lively forum on cutting edge software technologies that attract people from both academia and industry for a whole week. The attendees are both engineers using Smalltalk in business and students and teachers using Smalltalk both for research and didactic purposes. As every year, this year's edition of the largest European Smalltalk event will include the regular Smalltalk developers conference with renowned invited speakers, a Smalltalk camp that proves fruitful for interactions and discussions. Besides, this year will be held the 4th edition of the Innovation Technology Awards where prizes will be awarded to authors of best pieces of Smalltalk-related projects. You can support the ESUG conference in many different ways: * Sponsor the conference. New sponsoring packages are described at http://www.esug.org/supportesug/becomeasponsor/ * Submit a talk, a software or a paper to one of the events. See below. * Attend the conference. We'd like to beat the previous record of attendance (116 people at Köthen, Germany in 2004)! * Students can get free registration and hosting if they enroll into the the Student Volunteers program. See below. The conference features the following events: * Camp Smalltalk - There will be a Smalltalk camp the 23-24th of august * Developers Forum * Technology Forum Developers Forum : International Smalltalk Developers Conference ------------------ This year we are looking for YOUR experience on using Smalltalk. The list of topics includes, but is not limited to the following: * XP practices * Development tools * Experience reports * Model driven development * Web development * Team management * Meta-Modeling * Security * New libraries & frameworks * Educational material * Embedded systems and robotics * SOA and Web services * Interaction with other programming languages Submissions due on 1st June 2008 Notification of acceptance on 15 of June 2008 More information at http://www.esug.org/conferences/2008 How to sumbit? ------------------ Pay attention: the places are limited so do not wait till the last minute to apply. Prospective presenters should submit a request to esug-info(a)esug.org following the template below. Please use this template since the email will be automatically processed! Subject: [ESUG 2008 Developers] + your name First Name: Last Name: Email where you can always be reached: Title: Abstract: Bio: Any presentation not respecting this form will be discarded automatically Technology Forum ------------------ We are proud to announce the 4th Innovation Technology Awards. The top 3 teams with the most innovative software will receive, respectively, 500 Euros, 300 Euros and 200 Euros during an awards ceremony at the conference. Developers of any Smalltalk-based software are welcome to compete. More information at http://www.esug.org/conferences/2008 Student Volunteer Program ------------------ If you are a student wanting to attend ESUG, have you considered being a student volunteer? Student volunteers help keep the conference running smoothly; in return, they have free accommodations, while still having most of the time to enjoy the conference. More information at http://www.esug.org/conferences/2008 http://www.esug.org/conferences/16thinternationalsmalltalkjointconference20… We hope to see you there and have fun together.

1 1

etoys performance problems
by Ties Stuij 11 Apr '08

11 Apr '08

He lists (crossposting to Etoys and Squeak dev due to relevance for both), One can say that I am sort of taking over from Luke (Gorrie) as OLE Nepal's Etoys performance optimizer (optimizator?). And I'd like to give a status update, but I would especially like some advice on some issues. And the sooner the better. Cause we at OLE Nepal are in dire straits; we've got major performance issues, some of which are Etoys related, and some of which are Squeak related. And the reason for the speed is that we're gonna have to have a working XO build in a few days cause we have to train teachers, and in te beginning of April we're gonna flash a build to the machines of the children of the pilot schools, who will use it in the classrooms. So without further ado, except for this redundant sentence: project loading To start with the known, I've been looking into the project loading times, and have managed to cut them in half by removing the gzipping on the project files and just using the .pr file in stead of the zip which claims to be a .pr. Now this might of course not be the perfect solution for all, I did uncover some practices on which I'd like either the opinion of Squeak people in general or that of the Etoys people in particular. First, I noticed (together with Luke, who showed me the debugging ropes) that in the method asUnzippedStream, on ReadWriteStream, the method upToEndWithProgressBar uses '/' an awful lot to give the the right approximation to the progress bar. It sucked about 20 percent of the total loading time of an activity. So I changed upToEndWithProgressBar for upToEnd. Which seems like a more reasonable default 'cause I'd guess that usually one won't actually use the progress bar functionality. But thats not the end of it Etoys-wise. 'Cause it turns out an Etoys project file is gzipped twice. First the individual file in 'writeForExportWithSources:inDirectory:' and then the containing function writeForExportWithSources:inDirectory: as part of the .pr bundle. And this for a file that already has lots of it's contents compressed, seeing that most of the project file is taken up by jpegs. And this would ideally also be the case for sound files, but more on that later. The size decrease due to zipping in general is not more than 10%. So my question on this topic is: is there an argument for retaining the double zipping? And would there be a general need for a 'just save an uncompressed .pr file, instead of a bundle' option/patch? project deletion/memory growth Our second issue is related to memory growth within the Etoys image that's causing problems for the, let us say, memory-challenged XO. First of all we've got a, say, root project, which enumerates the activities which it reads from a few directories. In that root project we've got a script running that deletes child projects. Or it should anyway. The key method here is okToChange, which i guess is a bit of a misnomer. That is it's got a bunch of code in it that should remove a project and it's content from the image, but it doesn't. To make it concrete: we've got this script running in the root project: unloadActivitiesToFreeSpace Project current children do: [:t1 | t1 okToChange] "or okToChangeSilently, but okToChange is nice for debugging" But after removing a project, executing 'Project allInstances' shows that there is still a reference to the project and when one keeps an eye on the memory usage (with an OSX utility), we see that no memory is deallocated. So the image grows and grows. So my concrete question is: how can one for once and for all delete a project instance. I was hoping to at least find some generic deleteInstance method in the image, but I couldn't find one (I'm a bit of a Squeak newbie). Then it seems to me that the image grows quite fast in general. Is there some known garbage collection problem concerning Squeak or Etoys that I should know about? And related; when I'm gonna try and trim down the image size: any suggestions on where to start? Is there any known fat waiting to be caved off? Sound format Another strategy to trimming down the image size is using a compressed sound format. At the moment we use wav for sound right? If I'm wrong, excuse me, but I haven't had time to investigate the matter to thourougly. Anyways, since a number of activities have quite a few samples in them, ranging from short utterings to long sentences, it would be very worth while if we could use a compressed format. From the mailinglist I read rumours about Ogg plugin and a gstreamer plugin... Is it already possible to use Ogg files in Etoys? If so how? I'd already be happy with general directions. Well that's perhaps a bit more than quite enough questions for one post. I'll save some for later. It goes without saying that any advice on these topics would be greatly appreciated. /Ties

8 31

[ANN] Stable 3.10 Universe finished
by Lex Spoon 08 Apr '08

08 Apr '08

I finished up the Stable 3.10 Universe last weekend and uploaded a quick-start image to this page: http://wiki.squeak.org/squeak/5918 The stable 3.10 universe is a package universe of 214 packages, all of which have been verified to at least load into Squeak 3.10. "At least load" is not a very high guarantee of quality, but it is better than what you get if you go out on the Internet and start installing random packages. Thank you to everyone who contributed packages to this universe. Damien Cassou has worked particularly hard to keep the package entries current and consistent. For my part, it has been a pleasure, as with previous stable universes, to sort through such a long list of cool Squeak software that people around the world have posted. I hope that this package universe will help some of you hack Squeak just a little more conveniently. Lex Spoon

4 8

new display driver for Syllable
by Kelly Wilson 08 Apr '08

08 Apr '08

Hello everyone, I recently ported squeak to Syllable OS and it runs with vm-display-null and vm-sound-null just fine. Now I would like to develop the video driver for Syllable.unfortunately Syllable's windowing system is written in C++ and interfacing to it could be difficult (they may have a C interface set up.I'll check). As a backup I was wondering if I can just use SDL by modifying the vm-display-custom? I tried to modify the vm-display-custom code and it compiles fine with some SDL functionality but I have one weird problem. If I add any external call into the sqUnixCustomWindow.c file then compile/link/install it, the squeak module loader can't find vm-display-custom anymore. I can modify the file by adding some structures and functions local to the file but, like I said, if I call outside this file (and then include -lSDL or whatever when linking) then the loader just can't even see vm-display-custom. I can see display_custom and display_custom_itf with the 'nm' command and the format of the shared lib looks fine??? Does the loader look for something really specific about the libs size or something strange like that? I assume it dlopens() it. Thanks, K.Wilson P.S. I am sure that I have all the libs and things in the correct places because I can just recompile by commenting out my single external function call, recompile, reinstall and things work fine.

3 2

FW: [UI] Call to arms
by Gary Chambers 08 Apr '08

08 Apr '08

-----Original Message----- From: ui-bounces(a)lists.squeakfoundation.org [mailto:ui-bounces@lists.squeakfoundation.org]On Behalf Of Gary Chambers Sent: 29 March 2008 9:50 PM To: Squeak's User Interface Subject: [UI] Call to arms Right, I think we want to improve Squeak in terms of user interaction. This may be far-ranging to start with. This is a call for discussion. Where do we want to be with Squeak, anybody with an investment it the way it currently works is welcome. We are looking at re-engineering the basics, the VM teams are welcome to add their 2 (cents, pennies, etc). I think we envisage a framework (for want of a better word) that is rather fundamental, upon which existing Morphic can live, along with opportunities for radical new ui frameworks. Hands up, and we'll see who can form a team. Gary. _______________________________________________ UI mailing list UI(a)lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/ui

4 4

Jump to page: