Approximity blog home
799 to 808 of 903 articles

Using SVG in Borges   25 Sep 04
[print link all ]
Interesting blog-entry on naseby + ruby + stuff. link

[Squeak-ev] Deutsches 3.7g zum testen   25 Sep 04
[print link all ]
Markus Denker posted this to the Squeak-ev list
 Ich habe mal ein erstes deutsches 3.7g zusammengestellt:

 Das ist einfach das letzte 3.7g Full Image + deutsche uebersetzungen.
 Die englischen Fenster habe ich geloescht, die engl. Demo-Projekte sind
 aber noch drin.

 Was wir brauchen ist

 -> Eine deutscher Willkommen-text
 -> ein paar deutsche Demo Projekte
 -> am besten ein deutsches tutorial...

 Bi den Einfuehrungs-texten sollten wir uns nicht an den englischen orientieren,
 die sind naemlich eher sinnlos, denke ich.

Smalltalk must be dead because ...   25 Sep 04
[print link all ]
Donald Raab posted this goodie to the st-mailinglist.

It’s probably because in order to post in the Java ng he has to be 10x as verbose as in the Smalltalk ng.

He probably has to declare himself, cast himself, wrap himself in a try catch block, bubble up any exceptions, use some external iterators, implement some interfaces, and wrap up his primitives in real objects. Maybe after auto-boxing and generics are supported, he’ll only have to post 7 or 8x as often.

Don’t worry James, we appreciate and understand your terseness over here. ;-)

Squeak is a toy - so ?   25 Sep 04
[print link all ]
(source: email from Martin Drautzburg to stx-users ML; Oct, 22, 2003)
 > PPS:
 > I remember working for a company, where it took the make utility3/4 of
 > an hour to figure out *what* to compile, and the compilers a day to
 > compile- it was a C++ project b.t.w. which was canceled and replaced by
 > a Smalltalk program after they spent 50man-years on a non-working
 > program - so much for non-toy languages !

Yeah and I just spent 3 days in an inhouse J2EE workshop held by one of our chief architects. We spent most of our time fighting with the tools. Changed setting over and over. The goal of the workshop was to demonstrate how to insert a row into an oracle table. At the end of the 2 days the table was still empty. Another non-toy language.

I have written two small apps (apx 5000 LOC) one in squak and one in stx. It was a dream. Got up in the morning and fixed two or three bugs before breakfast. You can only do this with a real cool environment.

Smalltalk isKindOfLike: Yogurt   25 Sep 04
[print link all ]
(Source: Stefan, comp.lang.smalltalk) Smalltalk is like an Apache hellicopter. Java is like a B52 bomber with pretty heavy duty jet engines.

Smalltalk is very well thought out, extremely well engineered, very flexible, and generally gives quite good performance in a multitude of situations. It’s very adaptable to many different situations, and has lots of tricks up it’s sleeve. Driving it is a bit of a paradigm shift from driving your average plane, it has some new fancy controls, but once you get the hang of it, it can be totally amazing and really fun. Even if you don’t totally know what you’re doing you can still get yourself out of a jam. Given that you’ve got a good pilot you can launch off to a quick start and really do some very heavy and impressive damage in a very short time. It also tends to perform quite impressively if you’ve got a few of them around, and easier to coordinate an army of them.

Java is pretty difficult to drive, and once you get it going in a certain direction it’s pretty hard to get it going somewhere else. It has a few turbo buttons on it so that if you really know when and where to use it, it can fly pretty well. You can surely get it going really fast if you fly it high enough and then point it straight into the ground. It’s generally not very flexible and often a real pain to deal with, but overall once you’ve got a flightplan fixed in stone you can fly it reasonably well and run it reasonably efficiently. If you are meticulous in your planning and implementation, it can really deliver the goods. If you make some mistakes, things can go very wrong that may become almost impossible to correct. Don’t count on any big changes, quick maneuvers, or any sort of fancy tricks that just might save the day, and leave yourself a good bit of time for planning and implementation before you expect to be able to deliver the goods. If you come accross any surprise attacks or come up against an Apache hellicopter, you could be doomed.

On reading a text file in Smalltalk   25 Sep 04
[print link all ]
(Source: comp.lang.smalltalk, Lex Spoon) If you accept losing one notch of performance, then you can make much clearer code in Smalltalk. The "file lines" idiom in this thread is very useful, because you can then use collect:, select:, etc., on the resulting collection of lines.

And it is important to consider that once you commit to, say, iterating over an entire file, that the file must be reasonably small anyway to get decent performance. The same issue exists with collections. Who cares if collect: creates an extra collection or if WriteStream wastes space at the end of a long underlying collection; if these concerns are really so important then probably this huge collection should not exist and/or you should not be iterating over the entire thing anyway.

To put it very simply: you just can not expect a program to work on large data structures just because you micro optimized everywhere. If you want to handle large data structures then it takes planning and specialized algorithms and test cases. If you are not going to put in that effort, then don’t sweat the small stuff. It is very liberating to code with an eye towards correctness and towards algorithmic performance, and not to worry about getting down the constant factor. It seems to lead to lower stress, faster code production, and fewer bugs generated.

DE: Squeak Artikel C't   25 Sep 04
[print link all ]
In der C’t 7/2004 erschien ein Artikel ueber Squeak. Programmieren lernen mit Squeak: Von kleinen und grossen Erfindern. pdf

Alan Kay's talk at O'Reilly Emerging Technology Conference 2003   25 Sep 04
[print link all ]
(Source: Cory Doctorow) Notes from "Daddy, Are We There Yet?"

The last 20 years of the PC have been boring. PC vendors aim at businesses, who aren’t creative in their tool-use. They’re adults: they learn a system and stick to it. We should think about children. The printing revoltuion didn’t happen in Gutenberg’s day, it happened 150 years later, long after Gutenberg was dead, when all the pople alive had grown up with the press.

A small minority of Gutenberg’s contemporaries got the printing press, but it wasn’t until they were dead that the children who grew up with the press were able to put the ideas into practice.

James Licklieder: in a couple of years, human brains and computers will be coupled. It hasn’t happened yet. Except in science, where scientists and computers are indeed thinking as no human brain has ever thought before. ..

[ANN] rpa-base 0.1.0 "kitanai"   25 Sep 04
[print link all ]
(Source: Mauricio Fernandez)
 The Ruby Production Archive (RPA) will provide packages of Ruby
 libraries and programs in a form that allows production use, engineered
 through a stringent process resembling FreeBSD's or Debian's.

 rpa-base is a port/package manager designed to support RPA. Its scope and
 purposes are different to those of other systems like RubyGems.

 rpa-base 0.1.0 is now available on .
 Please keep in mind that this is *not* a RPA release (that is, a release
 of the repository) but just a release of the rpa-base tool itself. We
 have provided several sample ports/packages for testing purposes, but
 they don't formally belong to RPA. Read below for information on the
 libs/apps packaged so far.

 rpa-base requires Ruby 1.8.1 (certainly 1.8 at least, it might work on
 1.8.0); it has been tested on several Linux distributions, FreeBSD and
 win32. We would appreciate feedback (both positive and negative) under
 those or any other architecture.

 It takes but a couple minutes to install and will allow you to do

 rpa install instiki ruvi

 (NOTE: ruvi, the cool pure-Ruby vim clone, won't work on win32)


 rpa-base is a port/package manager designed to support RPA's client-side
 package management. You can think of it as RPA's apt-get + dpkg. It
 features the following (working right now):

  * sane dependency management: rpa-base installs dependencies as needed,
    keeps track of reverse dependencies on uninstall, and will remove no
    longer needed dependencies
  * atomic (de)installs: operations on the local RPA installation are atomic
    transactions; the system has been designed to survive ruby crashes (OS
    crashes too on POSIX systems)
  * modular, extensible design: the 2-phase install is similar to FreeBSD and
    Debian's package creation; rpa-base packages need not be restricted
    to installing everything under a single directory ("1 package, 1 dir"
  * rdoc integration: RDoc documentation for libraries is generated at install
    time (currently disabled on win32)
  * ri integration: ri data files are generated for all the libraries managed
    by RPA; you can access this information with ri-rpa (currently disabled on
  * handling C extensions: if you have the required C toolchain, rpa-base can
    compile extensions as needed
  * unit testing: when a library is installed, its unit tests are run; the
    installation is canceled if they don't pass

WebDav in 10 minutes: HTTP gave you read, now DAV gives you write access   25 Sep 04
[print link all ]
The stated goal of the WebDAV (DAV) working group is (from the charter) to "define the HTTP extensions necessary to enable distributed web authoring tools to be broadly interoperable, while supporting user needs", and in this respect DAV is completing the original vision of the Web as a writeable, collaborative medium.

But, people working on DAV have had goals which extend beyond simple web page authoring. Some view DAV as a network filesystem suitable for the Internet, one that works on entire files at a time, with good performance in high-latency environments. Others view DAV as a protocol for manipulating the contents of a document management system via the Web. An important goal of DAV is to support virtual enterprises, being the primary protocol supporting a wide range of collaborative applications. Importantly, a major goal is the support of remote software development teams. A final goal of DAV is to leverage the success of HTTP in being a standard access layer for a wide range of storage repositories — HTTP gave them read access, while DAV gives them write access.

Well, the website clains WebDAV in 2 minutes .. I think 10-20 minutes is more realistic :-). A good starter.

Apache2 already comes with mod_dav.


powered by RubLog
799 to 808 of 903 articles Syndicate: full/short