Squeak-dev May 2008

squeak-dev@lists.squeakfoundation.org

141 participants
174 discussions

Cleaning up lava code and unsent messages.
by Jerome Peace 02 Dec '08

02 Dec '08

Cleaning up lava code and unsent messages. Hi all, This was an after thought from my previous post. It deserved its own topic. Lava code is code left over from historical times which has no use in the current image and yet no one is willing to take responsiblity for removing it. For the record squeak has historically had about one sixth of its messages as unsent methods. Some of which is lava code others of which are examples, probes, utilities and tests. It would be nice to clean things up so there are no unsent messages. This could be done simply by creating a (pseudo-recursive) message #legitamatelyUnsentMethods (one method say for each class.) That sends for any legitimate examples, etc. Then anything that shows up as unsent would be illegitamate and removeable. >From time to time you would look at the implementors of the legitamatelyUnsentMethods to clean out what no longer belongs. a legitamatelyUnsentMethods method would be packagable if care were take that it mentions only the unsent methods of that package. My proposal is that package maintainers should take the responsibility for doing this in their own packages and the release team should reject any code that contains unsent messages. An Sunit test could be provided to check. I am also hoping to recruit those who would be willing to sort out the unsent messages in core packages and either write legitamatelyUnsentMethods methods for them or flag them as lava code for removal. It is a good way to gain an insight into a lot of squeak code while helping the community. If this task appeals to you please start it by planting a seed on mantis. Yours in service and curiosity, --Jeorme Peace ____________________________________________________________________________________ Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs

6 5

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

FFI problem: "could not coerce arguments"
by Mariano Martinez Peck 19 Aug '08

19 Aug '08

sorry...now it goes in English... I have a problem trying to invoke a function through FFI. I have bee using FFI y some functions with no problem but now I have "could not coerce arguments". This is the first time I have a void* parameter, so I believe that could be the problem. The function definition is: int *odbx_set_option*( odbx_t* *handle*, unsigned int *option*, void* *value* ) Here is an example that shows how to use it in C: option = ODBX_TLS_ALWAYS; if( ( err = odbx_set_option( handle, ODBX_OPT_TLS, (void*) &option ) ) < 0 ) { fprintf( stderr, "odbx_set_option(): %s\n", odbx_error( handle, err ) ); odbx_finish( handle ); return err; } This is my method that map that function with FFI: apiSetOption: handle option: anOption value: aValue "int odbx_unbind(odbx_t*)" <cdecl: long 'odbx_set_option' (ulong ulong void*) module: 'opendbx' > ^self externalCallFailed I proobed void*, void, ulong y ulong* but I had that error in all cases. Here is how my method is used: err := OpenDBX apiSetOption: self option:32 value:1. So, can someone help me? thanks, mariano

2 8

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

Squeak News Team Report - April 2008
by Michael Davies 10 Jul '08

10 Jul '08

Hello All, This is your monthly News report for April 2008. The purpose of the News Team is to publish news regarding Squeak and Smalltalk development and use. It aims to provide a service to the Squeak community, highlighting anything which Squeak users may find interesting in The Weekly Squeak newszine. It will also try to promote Squeak and Smalltalk outside its own community, by submitting articles and news items to mainstream websites such as Slashdot and OSNews. We had 11,972 direct page views for the month of April, this is slightly down from March, but better than the figure for the same month last year. In total, ten articles were posted. Our top three articles were (figures includes RSS views): Free Smalltalk books - 3,780 hits http://weeklysqueak.wordpress.com/wp-admin/post.php?action=edit&post=391 Video of Newspeak lecture now available - 3,630 hits http://weeklysqueak.wordpress.com/wp-admin/post.php?action=edit&post=396 The Year of Smalltalk - 3,051 hits http://weeklysqueak.wordpress.com/wp-admin/post.php?action=edit&post=387 If you have any news that you think that others may find interesting or useful, please feel free to drop the News Team a line. If you're planning any publicity for new releases, book launches, we can work with you to co-ordinate publication. Happy Squeaking, Michael Davies Squeak News Team Leader.

1 1

Smalltalk images considered harmful
by Bert Freudenberg 20 Jun '08

20 Jun '08

Etoys was being considered to get into Debian. Now it may be rejected, because an image file is not "transparent enough" (see below). It was suggested to discuss this issue on the debian-devel list. Do any of you have ideas how to respond? Are there perhaps other Debian packages that have a similar issue of accountability? And how hard would it actually be to bootstrap a fresh Squeak image from sources nowadays? - Bert - Begin forwarded message: > From: Thomas Viehmann <tv(a)beamnet.de> > Date: 21. Mai 2008 23:06:38 MESZ > To: "José L. Redrejo Rodríguez" <jredrejo(a)edu.juntaextremadura.net> > Cc: Bert Freudenberg <bert(a)freudenbergs.de>, ftpmaster(a)debian.org, holger(a)layer-acht.org > Subject: etoys_3.0.1916+svn132-1_amd64.changes (almost) REJECTED > Reply-To: ftpmaster(a)debian.org > > (OK, for technical reasons, this is not the REJECT, but there is > little point in delaying this mail now that I have written it.) > > Hi José, Bert, Holger, > > this is, unfortunately, the REJECT of etoys. > First of all, thanks Bert, Holger, José for the discussion of some of > the concepts. However, I am afraid that there are some fundamental > concerns that have not been eliminated (yet). As such I would like to > invite you to start a discussion on the packaging of squeak session > images on debian-devel(a)lists.debian.org. Feel free to forward this > mail if you consider it useful as a starting point. > > It seems to me that the method of distributing VM sessions in .image > files as the preferred form of modification does not match too well > with Debian practices of compiling packages from source and having > easy access to the differences between various versions of a package. > > So as far as I understand it it seems like a typical squeak image > cannot be bootstrapped[1] from (textual) source and that the typical > mode of operation is to modify some known image and distribute the > result. As such, the preferred form of modification is indeed the > image file. > > This, in my opinion, raises at least the following questions that seem > fundamental to me: > > - How easy should it be to figure out what is in an image? > While the source code to any class seems to be available, the > image is more than that. Does that matter? Should source of Debian > packages be auditable and is etoys currently auditable easily > enough? > > - Does Debian (including the various teams that might have to take > a look at your packages) want to have easy access to the > differences between upstream version, one Debian revision and > another? Do squeak session images provide this in a way that > is acceptable to Debian? > > From the squeak wiki pages and your explanations it seems that what I > would consider at least partial solutions exist, but it seems that > either I am still lacking understanding of important concepts or > that the etoys packaging (Debian and maybe also upstream) could > possibly be made a bit more transparent. > Of course, we might find out that my difficulties with the > perspective of squeak images in Debian originate in misconceptions of > Debian packaging and maintenance that I may have. Either way, I would > appreciate if we could discuss this with the Debian development public > at large and draw on their additional expertise. > > Kind regards > > Thomas > > 1. http://wiki.squeak.org/squeak/769 > -- > Thomas Viehmann, http://thomas.viehmann.net/

22 38

squeak image sometimes takes very long to be responsive after XO suspend
by Ties Stuij 17 Jun '08

17 Jun '08

Hey dear lists, We at OLE Nepal have some trouble with squeak images coming out of XO suspend. Basically when coming out of suspend, the Squeak process takes up lots of cpu power and can be unresponsive for about a minute on build 703 (other builds not yet tested). Also we loose sound. Which sometimes comes back after a while. Either on it's own or perhaps because another application is opened. This could be a coincidence though. Especially the unresponsiveness is a problem, because it messes up the classes. Typically a teacher will explain a concept after which the students will do an activity for a short while. After which they will close the XO again to go on with the rest of the course. The XO's can't stay open because they are to distractive and because they eat battery power, and perhaps take up to much space (the benches these children work at are tiny). Having to either wait for the activity, or restart the image (or XO, whatever the child feels comfortable with) kills the flow, and the children get very impatient. Any pointers to the cause and/or solutions would be greatly appreciated. I'll add appropriate tickets to trac shortly. /Ties

3 6

[ANN] ESUG Awards 2008
by Noury Bouraqadi 11 Jun '08

11 Jun '08

Dear Smalltalkers, You are invited to submit your nice Smalltalk based software to the 5th ESUG 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 16th International Smalltalk Joint Conference 2008. More details on the web : http://www.esug.org/conferences/awards2008/ Regards, Noury ------------------------------------------------------------------ Dr. Noury Bouraqadi - Enseignant/Chercheur Responsable de l'enseignement de l'informatique ARMINES - Ecole des Mines de Douai - Dept. I.A. http://vst.ensm-douai.fr/noury European Smalltalk Users Group Board http://www.esug.org ------------------------------------------------------------------

3 3

Process bug introduced in 3.10
by bryce＠kampjes.demon.co.uk 10 Jun '08

10 Jun '08

Run the following in a 3.10 image: 100 timesRepeat: [processes := (1 to: 10) collect: [:each| [[(MessageTally spyOn: [(Delay forMilliseconds: 500) wait]) ] repeat] fork ]. (Delay forSeconds: 1) wait. processes do: [:each| each terminate].] It locks up the image, debuggers will start popping up at some stage. This works on 3.9. I've run the code above in a fresh 3.10 image and reproduced the problem. I'll try to find time to investigate further. It's probably the final showstopper to me upgrading to 3.10. The code above is reworked from on of Exupery's SUnits which locks up the image intermittently. Bryce

7 20

Jump to page: