"Andreas Raab" Andreas.Raab@gmx.de wrote: Code size isn't but complexity is. Usually these two go hand in hand and therefore it's no strange argument at all. In fact I'd argue that programmer time is (in this particular case) mostly dictated by the complexity involved in the parser itself - most people will want to do pretty simple stuff. But this is precisely why a non-validating parser would be a *bad* idea. Non-validating parsers are easy to write. But if anyone were to try to process DocBook using Squeak (hey, guess what I'm trying to learn?) such a parser would be as much use as an Apple ][ simulator (maybe less, come to think of it).
If you really want to avoid complexity for people trying to use XML in Squeak, then choose a parser than implements *ALL* of XML, not just the dead easy bits. Do the hard stuff *once*.
But this is precisely why a non-validating parser would be a *bad* idea. Non-validating parsers are easy to write. But if anyone were to try to process DocBook using Squeak (hey, guess what I'm trying to learn?) such a parser would be as much use as an Apple ][ simulator (maybe less, come to think of it).
Hey! I resent that! An Apple ][ emulator is *supremely* useless.
In fact, I challenge anyone to come up with something else in Squeak less useful.
-- Duane
On Wed, 28 Nov 2001, Duane Maxwell wrote:
[snip]
Hey! I resent that! An Apple ][ emulator is *supremely* useless.
In fact, I challenge anyone to come up with something else in Squeak less useful.
Ok, I have a few IRC goodies:
1) MorseIRC. Translates all incoming and outgoing messages to morse code. 2) Er...I don't have a name for this, but I hooked up a talking head to irc, so it spoke the incoming messages from an animated head.
Cheers, Bijan Parsia.
Bijan Parsia :
Duane Maxwell wrote:
[snip]
Hey! I resent that! An Apple ][ emulator is *supremely* useless.
In fact, I challenge anyone to come up with something else in Squeak less useful.
Ok, I have a few IRC goodies:
1) MorseIRC. Translates all incoming and outgoing messages to morse code. 2) Er...I don't have a name for this, but ...
Now, now. We might continue this list for years. ZX81 emulators (they exist, sure, see the pages of XTender...). A program which computes the mileage of your mouse, all kind of silly text scramblers, etc. I could give you some hundreds of such "goodies". So why do I bother you with that? Because ALL COMP. SCI TEACHERS in this best of worlds are *obliged* to produce either directly, or through their students such wonderful pieces of software. Their purpose may be just training. We teach compilation and virtual machines. Well, now, be more ambitious, and do something which works, even if it is silly. Now I have two students who code Lindenmayer systems in Squeak. Perfectly useless as well. But 1. They will learn Smalltalk. 2. They will learn how to process quasi-paralelly a highly recursive data structure.
So, I could even defend the ZX81 emulator, which has inside the Sinclair floating-point calculator, whose architecture is a decently optimized stack-based virtual machine, interesting. Etcaetera.
Jerzy Karczmarczuk Caen, France
At Thu, 29 Nov 2001 09:01:37 +0100, Jerzy Karczmarczuk wrote:
We might continue this list for years. ZX81 emulators (they exist, sure, see the pages of XTender...). A program which computes the mileage of your mouse, all kind of silly text scramblers, etc. I could give you some hundreds of such "goodies". So why do I bother you with that? Because ALL COMP. SCI TEACHERS in this best of worlds are *obliged* to produce either directly, or through their students such wonderful pieces of software. Their purpose may be just training. We teach compilation and virtual machines. Well, now, be more ambitious, and do something which works, even if it is silly. Now I have two students who code Lindenmayer systems in Squeak. Perfectly useless as well. But
- They will learn Smalltalk.
- They will learn how to process quasi-paralelly a highly recursive data structure.
Sure! I change this year my CS1 course from functional programming (with Ocaml) to OOP (with Squeak) and last year my students have done some work on a Lindenmayer system project. This year, i would like to do the same project with Squeak.
I was just looking back at squeak 2.5 and noticed that switching the focus of system windows seems a whole lot faster than in Squeak 3.1 & 3.2. It doesn't seem like switching window focus should appear sluggish on a 1Ghz machine, but it does.
- Stephen
Stephen Pair wrote:
I was just looking back at squeak 2.5 and noticed that switching the focus of system windows seems a whole lot faster than in Squeak 3.1 & 3.2. It doesn't seem like switching window focus should appear sluggish on a 1Ghz machine, but it does.
- Stephen
If you have not already done so, try turning off "roundedWindowCorners" in the "windows" tab of preferences. It speeds up window activation on my computer.
Yes, it does speed it up. I also noticed that when pulling a window forward by clicking on the title bar, it picks up the window. I think that is what makes it seem sluggish...if I click elsewhere in the window, it's a much cleaner and faster transition. It would be nice if clicking on the title of an inactive SystemWindow brought it forward, but didn't pick it up (unless you move the a little bit). I seem to recall a discussion about this in the past.
- Stephen
-----Original Message----- From: squeak-dev-admin@lists.squeakfoundation.org [mailto:squeak-dev-admin@lists.squeakfoundation.org] On Behalf Of Steve Swerling Sent: Thursday, November 29, 2001 12:21 PM To: squeak-dev@lists.squeakfoundation.org Subject: Re: Performance of switching system window focus
Stephen Pair wrote:
I was just looking back at squeak 2.5 and noticed that
switching the
focus of system windows seems a whole lot faster than in
Squeak 3.1 &
3.2. It doesn't seem like switching window focus should appear sluggish on a 1Ghz machine, but it does.
- Stephen
If you have not already done so, try turning off "roundedWindowCorners" in the "windows" tab of preferences. It speeds up window activation on my computer.
"Stephen Pair" spair@advantive.com writes in...
I was just looking back at squeak 2.5 and noticed that switching the focus of system windows seems a whole lot faster than in Squeak 3.1 & 3.2. It doesn't seem like switching window focus should appear sluggish on a 1Ghz machine, but it does.
Absolutely.
As I've said many times, we go through periods of extension and periods of tuning, and we haven't done much serious tuning since several significant changes (though I put out three tuning updates in the last week).
If you or anyone else wants to help pursue this, put up three of your favorite windows and write a loop inside a MessageTally to cycle among the three doing
[:x | x activate. "Bring it to the front" x world doOneCycle "Repaint the display"]
Do this in both 2.5 and the very latest. Note that it's worth doing this both on a blank screen and a screen littered with other windows (preferably of a recognizably different type so they will stand out in the tally), since at various times we have been both clever and not so clever, at minimizing damage reported in the rest of the screen.
- Dan
4544Morphic-Chess-ar -- Andreas Raab -- 25 November 2001 A long-term project of mine has always been to write
a >nice little chess program for Squeak. But since I
haven't done anything on it in the last few months
I'm > just going to throw it at the community to see if
someone is interested in doing a bit more. It's a playing ... but not well :-( So, go get it
from > the objects tool and improve it!"
Smalltalk at: #ChessConstants put: Dictionary new.
Nice job Andreas! Quite impressive actually. Just discovered two small bugs : it allows castling when the king is in check and only allows you to promote pawns to queens, i.e. no subpromotion menu...
To make a long story short, I am also playing with such a beast myself.... A chess program named Lamneth which started as a bunch of experiments on alpha-beta vs NegaScout, transposition table replacement schemes, etc...
I'm curious about the speed of your chess engine... You heavily use bit shifts and bit operators and generate all moves. In my case, I tried to implement a fully legal move generator with chess piece objects... I am able to generate around 50000 positions in roughly 2.5 seconds without make/unmake mechanism, Trans. Table lookup and evaluation. From my previous tests, I'll be able to evaluate around 50000 positions in less than 5.5 seconds... Your programs reaches around 55000 positions in about 5 seconds...
My question is, how come using bit operations in Squeak is not **way** faster than creating objects ? Am I missing something ? BTW, I'm on Win 2000 with the very latest Squeak updates on a Pentium 1.7Ghz.
===== ---------------------- Benoit St-Jean bstjean@yahoo.com ICQ: 130611319 / Yahoo Mssngr: bstjean http://cactus.swiki.net "We're only immortal for a limited time", Neil Peart ----------------------
__________________________________________________ Do You Yahoo!? Yahoo! GeoCities - quick and easy web site hosting, just $8.95/month. http://geocities.yahoo.com/ps/info1
Benoit,
My question is, how come using bit operations in Squeak is not **way** faster than creating objects ? Am I missing something ?
Well, that's a good question. It most certainly _should_ be faster. In fact, I put some effort in preventing exhaustive allocations (by pre-allocating and recycling objects) since measuring showed that the overhead of allocating and garbage collecting the move, board, and player objects took roughly 80% of the overall time. And indeed - after taking care of these allocations the entire engine was four times faster.
If you have in fact a generator for legal moves only I'd be truly interested in seeing it. I found that validating moves introduces an overhead which is more than compensated by the extra ply required without validation (since almost all moves are valid). And if your allocation overhead is only remotely close to what I've measured your move generator must be three to four times faster than mine! Given that generating the moves takes roughly 50% of the overall time I'd certainly love to have one of those ;-)
BTW, the engine should run like hell with j3. I tried it once (but Win32/J3 crashed on me) so I don't know what the real outcome is. But it's all just integer arithmetic and recursion so j3 should make a _huge_ difference here (probably another factor of four or so).
Cheers, - Andreas
-----Original Message----- From: squeak-dev-admin@lists.squeakfoundation.org [mailto:squeak-dev-admin@lists.squeakfoundation.org]On Behalf Of Benoit St-Jean Sent: Thursday, November 29, 2001 6:08 AM To: squeak-dev@lists.squeakfoundation.org Cc: Andreas.Raab@gmx.de Subject: RE: XML Parser choice (was Re: [ENH] ??? MD5 in Squeak.)
4544Morphic-Chess-ar -- Andreas Raab -- 25 November 2001 A long-term project of mine has always been to write
a >nice little chess program for Squeak. But since I
haven't done anything on it in the last few months
I'm > just going to throw it at the community to see if
someone is interested in doing a bit more. It's a playing ... but not well :-( So, go get it from > the objects tool and improve it!" Smalltalk at: #ChessConstants put: Dictionary new.
Nice job Andreas! Quite impressive actually. Just discovered two small bugs : it allows castling when the king is in check and only allows you to promote pawns to queens, i.e. no subpromotion menu...
To make a long story short, I am also playing with such a beast myself.... A chess program named Lamneth which started as a bunch of experiments on alpha-beta vs NegaScout, transposition table replacement schemes, etc...
I'm curious about the speed of your chess engine... You heavily use bit shifts and bit operators and generate all moves. In my case, I tried to implement a fully legal move generator with chess piece objects... I am able to generate around 50000 positions in roughly 2.5 seconds without make/unmake mechanism, Trans. Table lookup and evaluation. From my previous tests, I'll be able to evaluate around 50000 positions in less than 5.5 seconds... Your programs reaches around 55000 positions in about 5 seconds...
My question is, how come using bit operations in Squeak is not **way** faster than creating objects ? Am I missing something ? BTW, I'm on Win 2000 with the very latest Squeak updates on a Pentium 1.7Ghz.
=====
Benoit St-Jean bstjean@yahoo.com ICQ: 130611319 / Yahoo Mssngr: bstjean http://cactus.swiki.net "We're only immortal for a limited time", Neil Peart
Do You Yahoo!? Yahoo! GeoCities - quick and easy web site hosting, just $8.95/month. http://geocities.yahoo.com/ps/info1
--- Andreas Raab Andreas.Raab@gmx.de wrote:
Well, that's a good question. It most certainly _should_ be faster. In fact, I put some effort in preventing exhaustive allocations (by pre-allocating and recycling objects) since measuring showed that the overhead of allocating and garbage collecting the move, board, and player objects took roughly 80% of the overall time. And indeed - after taking care of these allocations the entire engine was four times faster.
Yep... I came to the same conclusion... Recycle transposition table entries and limit the allocation of moves and positions through the use of recycling and make/unmake. I am not sure though as how to pre-allocate... I though about filling up some kind of stack with a zillion objects from a forked a low level process but there's something I don't like about that.
almost all moves are valid). And if your allocation overhead is only remotely close to what I've measured your move generator must be three to four times faster than mine!
Well... I am recycling a lot... I though at first that I could get around all that messy code but it looks like it's inevitable in a chess program... All coordinates and move calculations are done with Points so I guess that since all the Smalltalk windowing uses those, this class must be pretty optimized so I'm not so much penalized...
BTW, the engine should run like hell with j3. I tried it once (but Win32/J3 crashed on me) so I don't know what the real outcome is. But it's all just integer arithmetic and recursion so j3 should make a _huge_ difference here (probably another factor of four or so).
Never tried it... Will probably give it a closer look once all is glued together and can play a decent and completely valid game...
===== ---------------------- Benoit St-Jean bstjean@yahoo.com ICQ: 130611319 / Yahoo Mssngr: bstjean http://cactus.swiki.net "We're only immortal for a limited time", Neil Peart ----------------------
__________________________________________________ Do You Yahoo!? Yahoo! GeoCities - quick and easy web site hosting, just $8.95/month. http://geocities.yahoo.com/ps/info1
A chess program in squeak! That's very interesting. I was just playing with the idea of writing a go program in squeak, so definitely I could use some ideas of yours. (Particulary 'on the higher level': gui, game control and so on). Maybe I should look at the chinese checkers demo too. (By the way, does anyone happen to have the rules of that game ? )
Squeak seems better suited for go than for chess programming, because the emphasis is more on clever programming than on mere brute force. (And as we all know it is easier to be clever in squeak than it is in c!)
Just some thoughts of a squeak newbie (my first message on this list!)
Koen
Koen De Turck Koen.DeTurck@rug.ac.be wrote...
Maybe I should look at the chinese checkers demo too. (By the way, does anyone happen to have the rules of that game ? )
I don't know officially, but the way I have always understood it is...
1. Someone starts (I don't know how you are supposed to select this -- I would guess the one who lost last time), and play continues clockwise among the players. The winner is the first person to get all of his pieces into the (10) home positions directly across form his starting home triangle.
2. A move consists of making either a simple move or a jump with any one of your pieces.
3. In a simple move you move one of your pieces to any adjacent (one of the 6 nearest) cell that is unoccupied.
4. To make a jump, one of the adjacent cells must be occupied (it doesn't matter by whom), and the cell immediately beyond in that direction must be unoccupied. You move your piece over the occupied cell to the unoccupied cell. That is one leg of a jump. A jump may be extended to a sequence of any number of legs, each in any direction.
I'm not sure if it's a rule, but I've played with people who say you can't use cells that are in any home traingle other than your starting or ending home.
A very different (and wild) game is to allow any jump that is in-line and symmetric. In other words, if you drew a line 30 degrees off the forward axis, and the cells along that line were (x u u o o u u u ...), (x = where you are, u = unoccupied, o = occupied), then you could jump to the 7th cell (the last in my list), because you would be passing over the symmetric pattern (u u o o u u). That, of course, is just one leg, of a jump. This one is good with beer ;-).
Hope this helps
- Dan
I am trying to import change set that were made with Squeak 3.x into the newest image (supporting modules) and whatever I do, I keep getting the "Error: You cannot add new modules at the top level." debugger.
What should I do to properly import my change sets ?
Thanks
===== ------------------------- Benoit St-Jean bstjean@yahoo.com Yahoo! Messenger: bstjean http://cactus.swiki.net -------------------------
__________________________________________________ Do You Yahoo!? Yahoo! Movies - coverage of the 74th Academy Awards� http://movies.yahoo.com/
Hello,
Try to change category of your application by editing manually for example, and replace your old category by 'Project-MyProjectName'. And then perform : Repository importChangesFromFileNamed: 'MyGoodie.cs' intoModuleAt: #(Project MyProjectName)
Alexandre
On Sun, Mar 24, 2002 at 10:47:19AM -0800, Benoit St-Jean wrote:
I am trying to import change set that were made with Squeak 3.x into the newest image (supporting modules) and whatever I do, I keep getting the "Error: You cannot add new modules at the top level." debugger.
What should I do to properly import my change sets ?
Thanks
=====
Benoit St-Jean bstjean@yahoo.com Yahoo! Messenger: bstjean http://cactus.swiki.net
Do You Yahoo!? Yahoo! Movies - coverage of the 74th Academy Awards® http://movies.yahoo.com/
Benoit St-Jean wrote:
I am trying to import change set that were made with Squeak 3.x into the newest image (supporting modules) and whatever I do, I keep getting the "Error: You cannot add new modules at the top level." debugger.
What should I do to properly import my change sets ?
I'm not sure of the preferred way of doing this, but I'll tell you what worked for me. First, file out your changeset.
Next, search for all class definitions in the changeset. You will have to change them by: a. Getting rid of the poolDictionaries line b. Changing the category line to a module line
For example, the following class definition...
Browser subclass: #SVIBrowser instanceVariableNames: '' classVariableNames: '' poolDictionaries: '' category: 'svi-base'!
...would become:
Browser subclass: #SVIBrowser instanceVariableNames: '' classVariableNames: '' module: #(People sps svi base)!
Notice the poolDictiionaries line is gone, and the category line has been replaced by a module line. (Note: don't put single quotes around the module path array). When I do that, I can then file in the changeset . In the above example, my new class SVIBrowser would wind up in the the module hierarchy in a module called "base", which is a child of "svi", which is a child of "sps", which is a child of "People". People, as I understand it from the swiki, is the preferred place for you to put your projects.
squeak-dev@lists.squeakfoundation.org
-
Andreas Raab -
Benoit St-Jean -
Bergel Alexandre -
Bijan Parsia -
Dan Ingalls -
Duane Maxwell -
Jerzy Karczmarczuk -
Koen De Turck -
Richard A. O'Keefe -
Serge Stinckwich -
Stephen Pair -
Steve Swerling -
Steven Swerling