Squeak-dev November 2007

squeak-dev@lists.squeakfoundation.org

142 participants
155 discussions

OT - Mailing List Admin question
by Brad Fuller 11 Nov '07

11 Nov '07

I started the UI mailing list, and that makes me the admin. The mailing list is rcv'ing a ton of spam that I have to take care of everyday. Do other admins find the same thing on their lists? If so, what do you do about it? brad

10 14

Mantis Experiment a Failure? Are we ready yet to move on?
by Jerome Peace 11 Nov '07

11 Nov '07

Mantis Experiment a Failure? Are we ready yet to move on? Hi Frank, Thanks for your support. Hi Goran, Thanks for your time and reply. I knew my comments might be taken as disparaging Gjallar. I have not looked into Gjallar and don't have an opinion on it. I do have an opinion about the wisdom of integrating it into squeak here and now. Which is what my comments refered to. In the future it might be worth trying. But as you say it wasn't written for squeak and there would be efforts needed to integrate it. And they would have to be your efforts. Which right now I hope to see applied to elsewhere so we can get beyond a difficult maintainence system for squeak. *** >goran at krampe.se goran at krampe.se >Wed Nov 7 09:34:57 UTC 2007 replies: > >> I don't want to eat more squeak project dog food. At >> least not here. Not now. Dog food is being forced to use as tools, projects that are still in development. This gives feedback to the development project at the cost of time and focus for the work at hand. And puts pressure on the developers of those tools to fix the problems immediately. The best time to do this is when there is "time to spare" and space for play. > >Gjallar is not built for the Squeak community. It just happens to be an >issue tracker, so it is not dog food "for its own sake". > > >> Each problem in squeak seems to cause some in the >> community to try to solve it with a squeak tool that >> hasn't been invented yet. > >Again, if you mean Gjallar (which you may not mean) then it was not >created for the Squeak community - it is a system built for the needs of >a customer. I was talking generally and as you say Gjallar was not made to solve a squeak problem. Which is to its favor. The current problems and solutions to those problems are both following this pattern. MC and its repositories and browsers are such tools and so is Delta Streams. An annoyance followed by code to fix the annoyance is squeaks method of evolution. The problem right now is that we have a very inapporpriate way of maintaining the current image which has superceded the older known ways of doing it. Until the next tool proves itself we will have a very tortured way of producing releases. >> All experience has shown >> that integrating a new tool into squeak comes with >> risks and problems and diverts efforts from finding >> current bugs into finding the newly introduced bugs. >> >> I use mantis all the time it works fine for my >> purposes, which is reporting, analysing and fixing >> problems. >> The release teams use mantis and it works well for the >> purpose of finding fixes in a harvestable state. > >Mantis is quite fine for most stuff if you ask me. But it fails for some >things IMHO - mainly lack of email integration and/or doesn't fit our >rather distributed package world. I don't know if it lacks hooks for email integration or if we just don't know how to access them yet. Mantis has all sorts of capabilities we have not tried to learn how to tap. ><...> Some of this we (me and Matthew) want to >fix with DeltaStreams in fact. Yes. I am praying for and counting on your success. > >> The meta-problem is not that mantis is not used by >> many of the community because they have not caught on >> to is merits and usefulness. >> The problem is simply that they have not caught on to >> its merits and its usefulness. > >Ehm... lost me there. > Um. Maybe a little too zen? In English: The problem is we have to train them to use it. And they have to learn. The mailing list is a good place to discuss a problem but Mantis is a good place to solve it and to archive the solution. >> The other meta-problem is communication to and >> training of the community. >> >> Squeak-dev has scarce resources. Mantis is maintained >> by a large resourceful group of folks outside of the >> squeak community. >> They can provide better support for a bug tracker that >> we can even if our development tools are better. >> >> Maybe we are not using the mantis communication >> resources we have in the best way? >> >> Mantis not only allows accumulating information on a >> single topic. It can also write letters to those who >> should know about them. >> But nobody is maintaining the list of reporters to see >> if we have current emails. Or live reporters for that >> matter. >> >> (This requires the same thing we do with mailling >> lists send out occasional reminders and are you still >> there mail). > >Would just like to also mention that Gjallar has far more advanced email >capabilities than Mantis has. Which people would not use any more than they use mantis's. The problem with mantis's mail abilities is the quality and maintainence of the list as much as anything else. Also, I would like to find a good nuts and bolts users documentation for mantis. Right now all I see seems aimed toward administrators rather than reports, updaters and developers. As Gjallar is a commercial project I wonder if it has overcome the user's guide problem? >> You could also sign up mailing lists as reporters so >> reminders (I E. bug reports) could be sent to those >> lists. This would need to be done cautiously lest a >> list get swamped with mantis spam. But it could be >> done and it would increase communication and >> awareness. >> >> The current urgent problem in developing squeak images >> is the mess that the MC decision in 3dot9 made of >> image maintainence. >> That is where I would hope to see the effort of the >> communities best and brightest go. > >I try to pull my share of that particular load in the DeltaStreams >effort. Please do. I am pinning my hopes on Delta streams. > >> Please use mantis now. It serves its purpose well. > >I will never advocate Gjallar unless there are willing souls helping out >with such an endeavour btw. And also, it needs some testing and >adaptation etc. That was my point. Right now I prefer a tracker that leverages the resources of another community for its maintainence issues. > >But Gjallar continues completely independent on the Squeak community's >need for issue tracking - it is driven mainly by business opportunities. > A source for funding one's efforts always helps the quality. Again thanks for your response. Yours in curiosity and service, --Jerome Peace __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

1 0

Fwd: [Newcompiler] The decompiler for the old block is ready to test
by Stéphane Ducasse 10 Nov '07

10 Nov '07

Begin forwarded message: > From: Mathieu Suen <mathk.sue(a)gmail.com> > Date: 10 novembre 2007 01:28:21 HNEC > To: "The New Compiler, AST, IRBuilder, Closures..." > <newcompiler(a)lists.squeakfoundation.org> > Subject: [Newcompiler] The decompiler for the old block is ready to > test > Reply-To: "The New Compiler, AST, IRBuilder, Closures..." > <newcompiler(a)lists.squeakfoundation.org> > > Hi All, > > I have recently made some changes in the decompiler and now the > image can decompile. > This time the decompiler tests the equality of the method decompile > and the original method to see if they match. > If you take a 3.10 image all the image could be decompiled.(Except > for method with undefined class. see ScriptLoader>>unloadToolPlus > for an example) > > The latest version can be load either from the univers browser or > from squeaksource: > http://www.squeaksource.com/NewCompiler > > If you load from squeaksource we provide you a package loader. Load > the NewCompilerLoader and execute: > > NewCompilerLoader new loadPackages. > > This loads all the needed dependencies > > Remember the dependency are: > - NewParser > - AST > - SmaCC > - RefactoringEngine > > Mth > > >

3 2

Alan Kay's static typing sytem quote...
by Blake 10 Nov '07

10 Nov '07

Hey, all, I'm trying to find Alan Kay's static typing system quote ("more trouble than they're worth"?) somewhere on the 'net so I can link to it for an article. Does anyone remember what it was, exactly? ===Blake===

6 10

( picoVerse-:( Squeak documentation ) )
by Kjell Godo 10 Nov '07

10 Nov '07

Hi squeak-dev list ( contents-- ( The problem with Documentation ) ( The easy FragmentMap solution ) ( A question about loose methods in Squeak ) ) I find software documentation in general to be lacking. somewhere between lacking and abysmal. Like this Prolog compiler I saw recently that used nothing but single Character variable names and not one single comment in the whole thing. Just endless reams of short Prolog queries. AquariusProlog. It was supposed to be really great but I don't see how anybody but the original programmer could maintain it or adapt it. Most software seems to be designed to rot quickly once the original programmer moves on. When the original programmer for this thing stops maintaining it how can it do anything but die. The only software that I thought was well documented was Dolphin Smalltalk. Each and every method in there had a somewhat good comment in there and most of the important Classes also had comments in them. I found that I could figure most things out without too much trouble and without asking questions on the newsgroup. Smalltalk/V was also good this way. With Squeak my first impression several times was that I was totally and completely lost. So I would like to ask how the Squeak documentation is supposed to work. It seems like one is expected to rely heavily on the mailing lists. I have not found that the documentation jumps out at me so this would seem to be the case. The Visual Works documentation jumped out at me and seemed to be pretty good. Each major addon had its own .pdf file that tells you all about how to use it. The problem with this approach is that .pdf files are hard to make. The problem with documentation in general is that it is hard to make and tends to quickly lose its coupling with the source code. It seems like wasted effort so programmers don't do it. No matter how much their professors and bosses scream/prod at them to do so. When I program i use the Class and Method comments as a kind of running design document that helps me stay on track. My comments are much bigger than the actual code. If I don't do this I forget what I was doing months or years ago and start doing something awkward. I start coding at cross purposes. My Method comments come after the Method code and can be as long as I like. So you could stick a short comment at the top and a longer one after the body of the Method. Lately I have been commenting each line a lot using "<---( ... )" comments on hard to follow bits. This works because comments are colored green in Dolphin. It also helps if you can turn the wordwrap on and off. I notice that wordwarp is always on in Squeak. Another thing that I have been doing for the picoLARC Lisp Smalltalk Prolog ML compiler interpreter is to have a sequence of test cases that serves as a guided tour of how the compiler interpreter works. picoLARC can be found on sourceforge.net for the community version of Dolphin Smalltalk. So far only the Smalltalk Lisp parts are started there. A more recent version that includes a start at a lispy Prolog is not yet uploaded. I will make it so that each lambda function in picoLARC has to have a trailing comment after it of 60 words or more or else the compiler signals a fatal error. I think that there should be a way of putting Designs into Smalltalk. That seems to be highly lacking. The lack of it makes the barrier for people trying to come into Smalltalk higher. And it probably makes Smalltalk coding proceed at a slower less confident pace than it could. In 1990 I went to California and was able at one point to talk with Adele Goldberg in person for 30 minutes or so. She co wrote the Smalltalk 80 books. So my idea for putting Designs into Smalltalk was to have lists of related methods in things called FragmentMaps. Later she came to Boeing and reiterated what I said as being something that would be good. But I haven't seen it yet. So each Package or Project or Parcel would have a list or tree of FragmentMaps. Each FragmentMap would have a comment about what the methods in it are supposed to be up to and maybe there might be a HotDrawn diagram that also shows what is going on. These methods might be in different Classes and the fact that they are related probably is opaque to everybody but the original programmer. But putting them in a FragmentMap makes the relationship clear. At least it points out that there is a relationship. The lack of this FragmentMap means that there is a steap learning curve in front of anyone trying to understand this code. I'm saying that this learning curve should not be. And a simple FragmentMap would get rid of it. Almost. FragmentMaps might also have other FragmentMaps in them. A FragmentMap could also be a way to keep a train of thought in focus. So that you could leave it and come back to it without being afraid that by the time you come back you will have lost it. It would be a good way to let other people know what you are thinking too. So it would seem that this tendency to not document is highly dependent on the original programmer(s) sticking around the mailing lists. Once they leave then their work tends to die. Unless others keep it in their minds. This could be why it is common for programmers to think that rewriting is easier than reading. That by the time you figure out how some code works you could have rewritten it. I have heard that this happens a lot in corporate C programming. It got so bad that Boeing decided that they mostly no longer want to have any programmers. Just system analysts and software development tools that program themselves. First of all most of the projects would fail and second of all the ones that didn't fail would quickly die once the original programmers left. and then they would have to be rewritten. The software development department was losing so much money and not producing anything much good so they tried to get rid of it. But you can't do that. Another problem is that they put managers in charge who know nothing about software. Bad move. People who know nothing about software making important software decissions. Can you say dissaster? Would Microsoft do that? How can this be a good thing? How can it be the accepted practice? So in corporate they have tried all sorts of different intense ways to keep software from rotting. But none of it really seems to work. Maybe something simple like FragmentMaps would help. Maybe FragmentMaps could solve it. mostly. FragmentMaps are simple. Maybe a simple thing would work best. Programmers like the first simplest thing they can find. And then they just do that. From then on. The problem is: How are all these methods related? And how do you communicate that? The problem is: That many subsystems can be scattered across several different Classes. And the fact that they are related is completely opaque to everyone but the original programmer(s). FragmentMaps would make it a lot easier for new programmers to get up to speed. It would also make it a lot easier for Projects to stay on track and to keep new programmers from straying a lot from the original design ideas by pure accident. Protocals in Dolphin perhaps are like FragmentMaps. But Protocals are about public interfaces. If usage comments could be attatched to Protocals that would be good. If they were used. But FragmentMaps could describe both interface and implemenation designs. They would make coding easier and would make designs more public and easily accessible. FragmentMaps would be easy to implement too. It's just a named list of methods with one or more comments attatched. A brief comment. A details comment. And a usage comment. Even without the comments FragmentMaps would still be highly useful both for coding and for communicating. If you wanted to get fancy you could make it so that text selections within each Method are displayed which can drill down into the details. When you pass over a text selection a comment comes up in a ballon or something. When you click on a selection all the Methods in it are displayed. If you wanted to get fancy but this is not needed. There could be a tree Pane and a text Pane. The tree Pane has a tree of FragmentMaps and Methods in it. Each FragmentMap can have other FragmentMaps or Methods indented under it as its children in the tree Pane. Each FragmentMap gets a name. If you click on a Method the source code for the Method comes up. If you click on a FragmentMap the comments for the FragmentMap come up. Then you just need Add and Delete. Each Project could get a tree of FragmentMaps. Add could just put up a Prompter where you type in Class>>method Class class>>method If you wanted to get fancy you could add drag and drop. The Prompter comes up with an example in it: Class>>method or Class class>>method How about a Prompter where you can input multiple Class>>method strings. FragmentMaps could be labelled [Imp] or [Implementation] or [Int] or [Interface]. I include the short versions because I know how you hackers love to make and use conflicting ambiguous cryptic and contradictory lingo with lots of special cases. I suggest a two button Dialog comes up that enforces the long versions. All that typing you know. And that's it. You don't need more than that. A Squeak interface expert aught to be able to implement this in a day or three. And a Project expert aught to be able to add FragmentMaps to Projects in a day or three by just having the FragmentMap tree binary dumped into the Project file at first and then later a textual version of the dump that would last could be added. Dolphin has a textual way of doing binary dumps. FragmentMaps I would like to see are for the interfaces and implementations related to the >>future Method and all related Methods in the Croquet and also the routing and controlling in Croquet. Both the interface protocals and the implementation details in FragmentMap form. Also a sequence of test cases that goes from simple to complex and demonstrates all the major usages if that is possible would also help new programmers get up to speed and serves as an interactive way to show how these things should be used. I have seen Demos in Squeak and that is good. And Test Classes and that is good but a lot of the time these Classes are not very full and I am guessing that there is not really a sequence of test cases that a newbie could use to find out all the different usages. I am very methodical when I program. I single step all the test cases to make sure they are running the way that I think they should. When my stuff works it tends to have no bugs from then on. I can't really be very random. I have to be able to trust things that I have finished. Because it is hard for me to figure out what is going wrong if there are lots of bugs coming in from things I have already finished. So usually things I finished have no bugs. Once they run they run without bugs from then on. They can only have missing features. But no bugs. I am mystified by programmers who can take a program and shoot random fixes at it and somehow make it work. It seems like most programmers are like that but I am not. I need to be able to understand everything at once so I can know that new things are not contradicting old things. I need FragmentMaps. In Dolphin Packages can contain loose Methods. That's where a method is put into a Class that is owned by a different Package. In Squeak Packages seem to be called Projects. In most of my Packages it is impossible to go without loose Methods. It would seem to me that in Squeak the only way this could work was if all methods were loose in Squeak Projects. In other words no single Project owns a Class. Therefore all Projects can stick a method into any Class. Is this in fact the case? So, I would like to propose that something like FragmentMaps would be a good dynamic way to document Smalltalk Design in Packages Projects and Parcels. It would also be easy for programmers to use since all they have to do is stick related methods into a tree by dragging and clicking. It would be good if programmers could comment what the FragmentMap was about but even if they didn't the FragmentMaps would still be good. FragmentMaps would be an easy way to both aid in coding by keeping trains in focus and FragmentMaps would aid in telling others what is going on. Code reviews would be a lot easier. Simple to implement. Please do it somebody. If nobody does it then perhaps I could do it as a way of learning about >>future and routers and controllers. maybe then people would tell me what was going on so I could put it all into a FragmentMap tree(s). Perhaps FragmentMaps should also be called AspectMaps. Maybe Aspect is a better word. But Fragment has the word Frag in it. So that is also good. -Kjell

1 0

[ANN] Smalltalk Party Berne, 17th of November 2007
by Marcus Denker 10 Nov '07

10 Nov '07

SSUG is organizing a Smalltalk Gathering. We invite all Smalltalkers to join this event to share their enthusiasm and knowledge about Smalltalk. Where Software Composition Group Schuettzenmattstrasse 14 3012 Bern Switzerland When Saturday, 17th of November 2007 10h Start 14h Presentations / Demos Please send an email to denker(a)iam.unibe.ch if you plan to attend and especially when you plan to give a demo/talk. More infos: http://smallwiki.unibe.ch/ssug/smalltalkparty17thofnovember2007/ Marcus -- Marcus Denker -- denker(a)iam.unibe.ch http://www.iam.unibe.ch/~denker

1 1

[ANN] SIXX 0.3 has been released
by Masashi UMEZAWA 10 Nov '07

10 Nov '07

Hi all, I've updated SIXX to 0.3. This version includes a new feature "Formatter". By using it, you can customize SIXX format dynamically without subclassing. <<New Features in 0.3>> - "Formatter" support. Formatter is a new SIXX function for customizing SIXX format without subclassing. - "Object>>sixxIgnorableInstVarNames" now works on class instance variables also. - Added a new hook "Object>>sixxNonReferencableInstVarNames" for supporting non shared objects. - ShapeChanger can be used more easily (almost the same API as Formatter). <<Download>> - Squeak - SqueakMap and Universe - ftp://swikis.ddo.jp/SIXX/squeak/SIXX20071110.sar - VisualWorks - Cincom Public Store Repository - ftp://swikis.ddo.jp/SIXX/vw/SIXX-VW0.3-20071110.zip - Dolphin Smalltalk - ftp://swikis.ddo.jp/SIXX/dolphin/SIXX0.3-Dolphin20071110.zip About SIXX: http://www.mars.dti.ne.jp/~umejava/smalltalk/sixx/index.html Other features are listed at: http://swikis.ddo.jp/umejava/46 Enjoy! -- [:masashi | ^umezawa]

1 0

EndOfStream unused
by nicolas cellier 09 Nov '07

09 Nov '07

EndOfStream Exception seems to be unused in 3.10 My understanding was that: [[aStream next doSomething] repeat] on: EndOfStream do: [:exc | exc return: nil]. would be more efficient than testing atEnd at each loop: (would only the EndOfStream be signalled!) [aStream atEnd] whileFalse: [aStream next doSomething]. Especially, I have stream wrappers (to select:) with costly atEnd test! Maybe isNil test is efficient but I want to be able to stream on nil! | nxt | [nxt := aStream next. nxt == nil] whileFalse: [aStream next doSomething]. Am I all wrong? What do you think? Nicolas

8 24

[ANN] Nile 0.9.5
by Damien Cassou 09 Nov '07

09 Nov '07

Hi, Nile is a complete reimplementation of the squeak stream hierarchy. It's based on traits. You can find it on Universe, SqueakMap, and SqueakSource (http://www.squeaksource.com/Nile/) A new class diagram is available at: http://damien.cassou.free.fr/documents/internship_2007/nile/complete_hierar… Changes includes: * Only one class for collection-based streams (0 trait) * Only one class for file-based streams (0 trait) * Three new traits to put common behavior (6 traits in the core now) We did these simplifications following Andreas Raab suggestions. It proved to be a very good idea as a lot of entities (either class or trait) has been removed. We are not ANSI compatible anymore but we don't think it's a real problem in our case. There is also a backward compatibility package (not loaded by default) which contains collection-based stream classes to mimic ANSI behavior: NSReadableCollectionStream, NSWriteableCollectionStream and NSReadWriteableCollectionStream. They are using the new core. Please see package NileBackwardCompatibility on SqueakSource. If you want to experiment ideas with Streams, you can do that on Nile (for example, using a StreamAtEnd exception to avoid testing for #atEnd). Please comment on this. -- Damien Cassou

3 5

[ANN] DeltaStreams release 0.1
by Matthew Fulmer 09 Nov '07

09 Nov '07

This is the first alpha release of delta streams, a change management and distribution tool. Delta streams aims to be a compelling replacement to change sets and the update stream. Delta streams are analogous to the update stream, and deltas are analogous to change sets. A more complete feature comparison is at http://wiki.squeak.org/squeak/DeltasVsChangeSets Please note that this is an alpha release, and not all features we have been bragging about are implemented. For the rundown, see http://wiki.squeak.org/squeak/6013 ========== Installation ========== DeltaStreams 0.1 is available for Squeak 3.9, Squeak 3.10, and Croquet. It is available as a .sar installer for each platform. It is not available through universes at this time. - Get the .sar from http://wiki.squeak.org/squeak/6013 - drop it into the image, or load it with the file list - If you get a popup asking whether to automatically define the pool dictionary EditorSubjectPool, answer no. This only seems to happen on Croquet - When you get a popup asking which tool set you would prefer, answer #StandardToolSet, not #PlusToolSet --------------------------------------------------------------------- For more information about this release, especially what features are not yet implemented, see: http://wiki.squeak.org/squeak/6013 The delta streams user guide is on the Swiki: http://wiki.squeak.org/squeak/DeltaStreamsUserGuide The homepage for DeltaStreams is http://wiki.squeak.org/squeak/DeltaStreams -- Matthew Fulmer -- http://mtfulmer.wordpress.com/ Help improve Squeak Documentation: http://wiki.squeak.org/squeak/808

7 12

← Newer
1
...
9
10
11
12
13
14
15
16
Older →

Jump to page: