Squeak-dev July 2002

squeak-dev@lists.squeakfoundation.org

205 participants
393 discussions

Re: Exchanging Source Code between VW5i.4 and Squeak3; Best Practice?
by goran.hultgren＠bluefish.se 30 Jul '02

30 Jul '02

Hi all! "Mark A. Schwenk" <mas(a)wellthot.com> wrote: [SNIP] > I also worked a bit on the CVST project. When I was working with it we > used Eric Arseneau's SIF code for the interchange format. As far as I know CVST is live and well for both VW and Squeak (and Dolphin, and VAST and... :-=) - Martin Kobetic recently did some releases, check: https://sourceforge.net/projects/cvstproj/ CVST is a pure Smalltalk layer that essentially mirrors Smalltalk code out into the filesystem in order for it to be stored in CVS using the normal external cvs executable. AFAIK it works quite good. > I haven't used Göran Hultgren's CVS client for Squeak, so I can't > comment on its current status. Sqcvs is not a full CVS client - it's a class library for Squeak (but easily portable) implementing the CVS client/server ("pserver") protocol. It is not quite ready yet (just a few things missing, it does checkput/update/commit though) but when it is (soon hopefully, might squeeze in time this week) it will slide right in under CVST and eliminate the need for an external CVS executable. Sqcvs knows nada about storing Smalltalk code in CVS - that's what CVST does. Sqcvs will let us integrate CVS operations in say the FileList or easily build a general CVS client in Squeak. It can also be used if someone would like to use CVS as a "database backend" for some application since it doesn't need to rely on a filesystem. regards, Göran

1 0

Re: Squeak on Jornada 720!
by Russell Allen 30 Jul '02

30 Jul '02

Aaron (reic0024(a)d.umn.edu) wrote: > I'd love to have a look at your code, possibly to merge it into Dynapad. I've put up the change sets as I have them at http://russell-allen.com/squeak/faure/ You can file them into a 3.2 image; stuff should be fairly self evident (it's not a very large body of code). Think of it as a proof of concept - the functionality is a little sparse :) Feel free to do whatever you want with the code; but I don't know how much will be of any use. Regards, Russell

3 2

[OT] Sounds familiar?
by Michael Rueger 30 Jul '02

30 Jul '02

http://www.ddj.com/documents/s=7453/ddj0208q/0208q.htm That's why I always start a project in a virgin image. If there is such a thing. Enjoy Michael P.S. According to my own signature this is one of life's big problems ;-) -- "All of life's big problems include the words 'indictment' or 'inoperable'. Everything else is small stuff." -- Alton Brown +------------------------------------------------------------+ | Michael Rueger m.rueger(a)acm.org ++1 (310) 937 7196 | +------------------------------------------------------------+

1 0

Re: grabbing value of a variabe by its name?
by Richard A. O'Keefe 30 Jul '02

30 Jul '02

> This is doing things an OBJECT-ORIENTED way. You want to insert something > into a table. What do you want to insert? Variables? No: you want to > insert an OBJECT. So let there *BE* an object. Right. However I'm using the postgres bindings which as far as I can see they aren't as "objectified" as they could be (or I could be wrong), and I admit I feel quite some reluctance to start messing with them and spreading changes all over the place and ripping its guts apart. What I'm really suggesting is layering your own stuff *on top*. > For example, suppose the column 'zip' in your data base is renamed from > the US-centric 'zip' to a more globally intelligible 'postcode'. ALL of > your versions break, but the Table1 class can just add two methods You don't go around renaming columns just because one is more intelligible to you than what you "inherited", unless you are very bored. I'm not suggesting that your Squeak code use a new name; I'm pointing out that the SQL code might use a new name and your Squeak code might need to adapt to that. Just because you've "inherited" it doesn't mean the underlying data base won't change; real data bases very often do. (The BIG problem is when the semantics of the data in the real world change but for reasons of inertia the data base schema is not changed. > * It simply isn't *POSSIBLE* to use the same names in your Smalltalk code > as in your data base. It is, as long as you design your database and you dont have to access third party ones, and thats the only reason I'm comfortable with pulling tricks and "rules" out of my hat. If you are in a situation where you have full control over the names in the SQL database schemas then fine, but in that case you aren't talking about a data base you've "inherited". Even then, an SQL column name may reasonably have the form SchemaName . TableName . ColumnName and while you could easily represent that in Squeak as #(SchemaName TableName ColumnName) the result would not be a Squeak variable. The rest of my reply revolves around this, so if you agree you'll probabily agree with the rest.. and if you don't you'll never agree with anything. > -> Home_Team character(14), All the columns have no underscores in them, on purpose, just to avoid this inconvenience. If we rule out quoted identifiers and identifiers in exotic national language character sets and just stick with basic identifiers, then underscores are not an inconvenience. SQL defines names to be equal if they differ only in case. sql-to-squeak(name) = letter after underscore => capital other letter or digit => no change underscore => delete squeak-to-sql(name) = capital letter => underscore, capital letter lower case letter => capital letter digit => no change so Home_Team -> homeTeam -> HOME_TEAM. and HOME_TEAM is in fact the SQL normal form of the name Home_Team. In fact, some such rule (and the presence of an underscore in the sql name) would be the only justification for having a capital letter in the squeak name. Rather more exotic rules of this type _can_ handle quoted identifiers and accented letters, but the results tend not to be readable. If you have full and total control of the SQL names, this is not a problem. > * The trick does not particularly encourage consistency. SQL names are > not case sensitive. So homeTeam, homeTEAM would both represent the > same SQL name. How exactly does the trick encourage people to consistently > pick one of them, in a way that gentle exhortation would not? Doesnt matter as the column names get lowercased when the postgres bindings return them. Or maybe its seaside.. they get lowercased somewhere. So you are NOT in full control of the names on the Squeak side? Any interface which simply lowercases SQL names is broken; are you sure it does not do something special with underscores? In any case, it's not the trick that encourages people to use consistent capitalisation; it's some other interface you are building on that forces this. > * Sometimes in SQL you have to use qualified names. The example data base > that my example comes from includes also > create table Teams (Team ...) > create table League (Team ...) > You have not yet explained how your pun can accomodate SQL names like > Teams.Team or League.Team. select team.team as teamteam That is no answer. It says how you can avoid the problem in some cases; it does not say how the problem can be solved. > * Some names which are perfectly usable as SQL names are reserved words > in Smalltalk, such as "self", "super", "nil". That hardly counts as a valid objection. Why the **** not? Some names which are usable as SQL names are NOT usable in Smalltalk. PERIOD. This means that a simplistic identity/case mapping WILL NOT WORK IN ALL CASES. It's about as valid as an objection can get. If you are in full and total control of the SQL names, then yes, you can avoid all the Smalltalk special names as well as the dozens of SQL special names. However, you did not previously inform us that you were in full and total control of the SQL names, and the objection remains an extremely serious objection to a simplistic identity/case name mapping IN THE GENERAL CASE where people want to connect to a data base that they are NOT in full control of. The general case might reserve a prefix, such as "sQ", and map self to sQself super to sQsuper s_qfoo to sQsQfoo ... A wide range of name mapping rules can be used, but not simplistic identity mapping. > * You have not yet explained how your pun can accomodate SQL delimited > identifiers. For people who never looked at SQL 92, "foo!" (with the > double quotes) is a perfectly good SQL 92 'delimited identifier'. > Delimited identifiers may be used pretty much anywhere that simple > identifiers may be. Who wants the shotgun? I have no idea what shotgun you are talking about. Anyone who wants to talk to an SQL 92 data base that they are NOT in full control of had better be ready to cope with any legal SQL 92. Now that you inform us you ARE in the very very special case of building a Smalltalk binding to an SQL data base whose names you have full control of, that tells us that this isn't a problem *for you* and *right now*. For other people, the fact that SQL 1992 allows some rather surprising identifiers means that crude name identity hacks will not *in general* work. > * According to the SQL 1992 standard, an identifier may contain non-Latin > letters if such exist according to the <module character set specification> > or the <character set specification>; how are those to be handled by this > pun? And the shells? Again, I have no idea what you mean by "shells". However, accented letters are very much a part of SQL 1992 for very good reason. Only people who have full control of the SQL names do not need to worry about this. > In this case, the two rows happen to need the same value for their > 'team' columns. But what if they needed DIFFERENT values for their > team columns? > > winners := 'Hawkeyes'. > losers := 'Windies'. > w := Wins new. > w team: winners; against: losers. > w insert. > l := Losses new. > l team: losers; against: winners. > l insert. > > I cannot for the life of me regard any approach which would force > the entry into Wins and the entry into Losses to use the *same* local > variables for opposite purposes as 'safe'. Ah, you saved the real one for the end :) It's a poor example tho (SQL wise), but nobody is forcing you: In what way is it a poor example? All it is *supposed* to be an example of is inserting two rows that have some column names in common, and it's a simple clear example of that. If you want (or need) to write the insert statement, do. Hang on a minute, it's *you* who are writing explicit INSERT statements. Part of the point of my example is that I'm *not* writing INSERT statements; I'm constructing row objects and telling them to insert themselves. In the approach I am suggesting, no SQL syntax appears in the Smalltalk code at all. (Except in the underlying classes.) Of course the statement was more "exposed" and therefore looked more natural (or less ugly) in my example than it would if it was next to your example. I cannot understand this. You example DID have "exposed" SQL syntax, and that made it MORE ugly, not less. In fact, it's precisely the exposed SQL syntax that makes it so tricky to get right. Part of my point is that because you are interfacing to SQL code, SQL syntax has to appear *somewhere*, but it should be hidden away as deeply as possible and the great bulk of your code should look like Smalltalk. Elementary statements: INSERT INTO table (name,...) VALUES (atom,...); => newRow := Table new. newRow name: atom. ... newRow insert. UPDATE table WHERE cond SET name = value ... => Table updateWhere: [:aRow | cond] set: [:aRow | aRow name: value. ...] Table atName: atom updateWhere: [:aRow | cond] set: [...] "replace Name by any suitable column name" DELETE FROM table WHERE cond => Table deleteWhere: [:aRow | cond] Table atName: atom deleteWhere: [:aRow | cond] "replace Name by any suitable column name". SELECT gets a bit more complicated; I'd be inclined to make each SELECT be its own method, and it might make sense for it to be a method of the *result* table. Perhaps any further discussion should be in terms of actual SELECTs from your application.

1 0

Re: A problem hindering SmallTalk's popularity:
by Richard A. O'Keefe 30 Jul '02

30 Jul '02

Lily Smith <yinyuqin2000(a)yahoo.com> wrote: The major reason that why SmallTalk is way less popular as Microsoft VB is that SmallTalk lacks documentatation and a good tutorial. Lily Smith is half right, but only half. "Smalltalk" is not a product, the way Visual Basic is a product. "Smalltalk" is a *FAMILY* of programming languages with a common heritage, including but not limited to Dolphin Smalltalk VisualWorks Smalltalk <-+ IBM Visual Age Smalltalk <-+ Squeak <-- Smalltalk/X where the ones labelled "<-" are ones that I have at one time or another downloaded. The ones labelled "<-+" have copious, nay, VOLUMINOUS documentation, including lots of tutorial material. There are DOZENS of books about Smalltalk in general. The original Smalltalk books were really great and any place that requires students to learn Smalltalk probably has them. I have used "Inside Smalltalk" and found it extremely helpful. Stephane Ducasse (may he flourish like the green bay free!) provides free electronic copies of several out-of-print but still useful Smalltalk books at http://www.iam.unibe.ch/~ducasse/WebPages/FreeBooks.html Anyone who slams Smalltalk documentation and tutorials without as much as looking at this page hasn't done their homework. Where are the good free books for Visual Basic? Tutorials? Squeak has quite a few. I know SmallTalk can do almost everything that VB can, With the admittedly important exception of making it easy for people to write Word viruses, this is a masterpiece of understatement. Smalltalk in general, and Squeak in particular, makes it easy to do things that VB hackers can only dream of. The main purpose of VB is to tie developers to Microsoft's apron strings. but a newbie like me just don't know how to do it. Nor could I do anything in Visual Basic without a book. There are two or three books specifically about Squeak now. "Squeak Open Personal Computing and Multimedia", eds Guzdial & Rose, is the one I happen to have beside my keyboard at the moment. I've learned a fair bit from it, but it's not the one I'd start with. It is not easy to find the correct class and method. That's odd, even _without_ a Squeak manual I find that it usually takes only a few minutes to find these things. It really DOES pay to work through some of the Squeak tutorials before complaining about them. Even if I am lucky enough to find it, I have to spend hours to learn how to use those methods. Few documentation and examples on the web are available. There is more documentation and there are more examples on the web than I will ever have the time to read. One of my assignments was to add a radio button group and then deal with the user input. Even my teacher does not know how to implement a radio button group. He spent half an hour in class, trying to show us how to add a radio button group. He failed. I think your real problem may be with your teacher. (1) He should have solved the problem *before* the class. (2) For the old MVC framework, I'd just stretch my hand over to the other desk, pick up my copy of "Inside Smalltalk", and there it is. Now, I have never ever done this in Squeak myself, because I don't have much use for radio buttons. Here I am starting at 1:35pm, knowing only that there is a PluggableButtonMorph class. I open a Browser and read the class comment. Good. This will do what I want. Now, I'm going to create a "RadioButtonGroup" class that holds three buttons. It's going to have state "1 .. 3, initially 1" button1.. button3 "PluggableButtonMorphs" rectangle "a RectangleMorph to hold the buttons" methods: state: newState state = newState ifFalse: [ state := newState. self changed: #state1. self changed: #state2. self changed: #state3] state ^state label1 ^'1' label2 ^'2' label3 ^'3' state1 ^state = 1 state2 ^state = 2 state3 ^state = 3 action1 self state: 1 action2 self state: 2 action3 self state: 3 I'm nearly there. I now have to figure out how to create the PluggableButtonMorphs and stick them together. To see how to create them, I look in the class side of PluggableButtonMorph and notice at the very top of the method list an 'example'. At this point I kick myself, BECAUSE THE EXAMPLE OF PLUGGABLEBUTTONMORPHS RIGHT THERE IN THE SYSTEM IS A THREE-WAY RADIO BUTTON! [almost] It is now 1:51 and if I hadn't jumped into coding I'd have had the answer after five minutes!!!! What was that about documentation and tutorials? The answer is right there staring us in the face in the obvious place to look! 'example' methods and 'example' message categories *always* repay study. Oh well, let's use this example to finish my code. initialize state := 1. button1 := PluggableButtonMorph on: self getState: #state1 action: #action1 label: #label1. button2 := PluggableButtonMorph on: self getState: #state2 action: #action2 label: #label2. button3 := PluggableButtonMorph on: self getState: #state3 action: #action3 label: #label3. button1 hResizing: #spaceFill; vResizing: #spaceFill. button2 hResizing: #spaceFill; vResizing: #spaceFill. button3 hResizing: #spaceFill; vResizing: #spaceFill. rectangle := AlignmentMorph newRow hResizing: #spaceFill; vResizing: #spaceFill; addAllMorphs: {button1. button2. button3}; extent: 120@35. openInWorld rectangle openInWorld It's now 2:02pm, despite three phone calls from home. Code written and ready to test. RadioButtonGroup new initialize openInWorld Hey, great! Three buttons labelled '1', '2', '3', and the first one is pressed (dark). Clickety clickety, yep, it's working. Start to finish time: 30 minutes (including 3 1 minute phone calls). Then he wanted us to complete that assignment ourselves. God! It is even difficult for a SmallTalk senior to find out something common! Surprising as it may seem, radio buttons are NOT common in Squeak use. They have to be built from simpler components, as shown above. However, it is quite clear from my experience, as reported above, that it is NOT IN THE SLIGHTEST DIFFICULT, NOT AT ALL for a Smalltalk programmer with ___very___ modest experience to find out everything necessary and put the pieces together in just a few minutes. You should bear in mind that I have always had difficultly (mild to extreme) with GUI kits, with the notable exceptions of Interlisp-D and to a lesser extent Tcl/Tk, and you should particuarly bear in mind that I am a complete novice at doing things with Morphic. This is the first time in my life I have ever used a button in any Smalltalk dialect. Thirty minutes. You do not have a "Smalltalk senior" for a teacher. Oh yes, I did say that I was starting from the knowledge that there was a PluggableButtonMorph class. How hard is that to discover? In a browser, go to the leftmost pane and from the menu select "find class". Type "Button" into the text box that pops up and accept it. You are shown a list of all the classes that contain "Button" in their name. I wish I had done this at the beginning instead of remembering this one from an earlier "Pluggable" search, because guess what, this is the *FIRST* thing a Smalltalk beginner should think of trying and it turns up RadioButtonInput RadioButtonSetInput They are both part of the Forms support in Squeak's web browser. They are a bit specialised to use directly, but there are ideas one could steal. Narrowing things down, GUI components have names ending in "Morph", usually, so "...ButtonMorph" is something to look for. How can SmallTalk be popular? If people teach it well, and students read some of the MANY existing books and tutorials for Smalltalk. Look at how easy it is to add a radio button group in Microsoft VB! 30 minutes to build a 3-way radio button group class in Squeak really isn't bad. Now that I have one, I shall probably improve it a bit for my own education, but there are widget libraries coming along which will be much much better. For comparison, this morning I demonstrated in a class how I - found a limitation in Scamper (it doesn't support <INS> or <DEL> tags) - and fixed it in 30 minutes flat. When I _really_ did that two nights ago, it took me just five minutes more, and I have *never* modified Scamper before. You can say many things about Squeak, but "classes and methods are hard to find" really isn't one of them. That's twice this week I've found the bits I've needed and whacked them together in half an hour in areas that I have never touched before in any Smalltalk. Well, it is just my complaint on this language. I hope SmallTalk geeks should come up with a very good tutorial book for SmallTalk newbies. Otherwise, it will never be popular. The work "geek" is *EXTREMELY* offensive. It means a freak show performer whose act involves biting the heads off live chickens; we're talking serious subhumanity here. Spelling the name of the language wrong (it's "Smalltalk", not "SmallTalk") is not a good move either; if you haven't even troubled to find out what the langauge is _called_, what _have_ you troubled to find out? To repeat: there are LOTS of good (even "very good") tutorial books for Smalltalk, and there is even an introductory book for Squeak by Mark Guzdial (may the light of 6 thousand suns shine on his head, but only at night time!). If your teacher has not made sure that you have access to a copy, blame the teacher but do not blame Smalltalk. I fear that Smalltalk will never be popular with people who have inadequate teachers and are not even told where to find a good book about it. But the same could be said of anything, even Zope or PHP.

3 4

License Question
by marbusse＠t-online.de 29 Jul '02

29 Jul '02

Hi! I'm trying to port the JdmMysqlDriver to GNU Smalltalk ( http://swiki.squeakfoundation.org/gst/6 ). I got so far that I can connect to the server and the server replies 'error'. This port relies on squeak's SequenceableCollection>>#pairsDo and the methods from "ByteArray-platform independent access". Am I right that I'll have to code around this if I want to release my code (with or without all dependencies)? If yes, do I'll have to start from scratch with these methods? Some license evangelist around? :-) Kind regards, Markus

1 0

RE: Cannot install Squeak v. 3.2-4
by Jarvis, Robert P. (Contingent) 29 Jul '02

29 Jul '02

> -----Original Message----- > From: Tim Rowledge [mailto:tim@sumeru.stanford.edu] > Sent: Monday, July 29, 2002 3:53 PM > To: squeak-dev(a)lists.squeakfoundation.org > Subject: Re: Cannot install Squeak v. 3.2-4 > > > Ian Piumarta <ian.piumarta(a)inria.fr> is claimed by the > authorities to have written: > > > On Mon, 29 Jul 2002, Tim Rowledge wrote: > > > > > inisqueak is, I think, a sort of.rc file for Squeak. > > > > It's just a teeny "one-time" script to set up a dir for > Squeak by putting > > the three things you need in it: > > Ah, I must be confusing it with something else then. Maybe > windows uses > something like it. Or maybe I'm just more senile than usual today. If you've forgotten things about Windows you're less senile and more sane. Bob "...who has spent today wading hip-deep through MS docs..." Jarvis Compuware @ Timken ********************************************************************** This message and any attachments are intended for the individual or entity named above. If you are not the intended recipient, please do not forward, copy, print, use or disclose this communication to others; also please notify the sender by replying to this message, and then delete it from your system. The Timken Company **********************************************************************

1 0

Taking the world!
by Diego Gomez Deck 29 Jul '02

29 Jul '02

Hi, With the 3.2 version on the road we can publish in slashdot, freshmet, etc and take the world for us! :-P What do you think? Cheers, Diego Gomez Deck

3 2

RPMs and debs
by beoneel＠bluewin.ch 29 Jul '02

29 Jul '02

Hi, As Ian just pointed out to me, he already makes RPMs. His RPMs are perfect so now I could just use some .debs (and any other packaging scheme, someone want to try a Solaris package?) Thanks to Ian! cheers bruce

1 0

Re: Another Swiki defence idea: better tools
by Martin Drautzburg 29 Jul '02

29 Jul '02

cg(a)cdegroot.com (Cees de Groot) writes: > It's not as secure as PGP/GPG keys, but *way* more interesting (if only > to gain experience for similar collaboration environments inside Squeak) I like your ideas (and their "spirit") very much. Is there chance to really make this happen ?

1 0

← Newer
1
2
3
4
5
6
7
8
9
...
40
Older →

Jump to page: