Re: Design Principles Behind Smalltalk, Revisited

Re: Design Principles Behind Smalltalk, Revisited

>From: Todd Blanchard <tblanchard <at> mac.com>
>Reply-To: The general-purpose Squeak developers 
>list<squeak-dev <at> lists.squeakfoundation.org>
>To: The general-purpose Squeak developers 
>list<squeak-dev <at> lists.squeakfoundation.org>
>Subject: Re: Design Principles Behind Smalltalk, Revisited
>Date: Sun, 31 Dec 2006 21:26:22 -0800
>
>
>On Dec 30, 2006, at 9:09 AM, Jimmie Houchin wrote:
>
>>I've avoided RDBMS because I read a lot about the Object Relational  
>>mismatch in Squeak, Ruby, Python, etc. mailing lists. So how do I  store 
>>my millions of objects, search and access them. I could  easily store them 
>>in files and search via Swish-e. But managing  millions of files in the 
>>file system is kludge. Ugh. So I've been  thinking that I'm working harder 
>>on a kludge than it would be to  learn SQL and use PostgreSQL.
>
>>So with that nudge from you, I sit at my desk right now reading one  of my 
>>several SQL books. Thanks. :)
>
>Put down the book.
>
>You want to load up GLORP.  It rocks.  It is as easy to work with as  an 
>OODB, but much more flexible and is backed by PostgreSQL.  Grab a  copy of 
>squeak, load the postgres client, then load up glorp.  You're  golden.
>
>Except you need a meta model.  You can write one in glorp, you can  build 
>one with a GUI like Apple's EOModeler - free with WebObjects.   The EOGlorp 
>package will let GLORP work off of your EOModel files.   Once you have your 
>meta model, glorp is just like working with  objects.  You write queries in 
>Smalltalk like
>
>aDatabase readOneOf: User where: [:user | user login = 'jhouchin'].
>
>-Todd Blanchard

Tools like GLORP are very nice: they save you writing SQL directly.  But 
look at your line of code:  it is SQL in message form.

I wasn't talking about using embedded SQL in code.  I was talking about the 
back end data store.  IMO the data is often best modeled relationally.  Then 
you can set up any views you want and then use something like GLORP to 
access it.

_________________________________________________________________
Find sales, coupons, and free shipping, all in one place!  MSN Shopping 
Sales & Deals 
http://shopping.msn.com/content/shp/?ctid=198,ptnrid=176,ptnrdata=200639

ANN: separate Squeak packages created for different Debian vesions

Friends,

To make sure that Squeak can be installed on every relevant Debian
(GNU/Linux) version, I decided to create builds for all the three Debian
versions:
Sarge (known as "stable")
Etch (known as "testing")
Sid (known as "sid")

It was not necessary because the same squeak binaries worked quite well
on all of these Debian versions but it might have been confusing to add

  deb http://ftp.squeak.org/debian/ sid main
  deb-src http://ftp.squeak.org/debian/ sid main

to `sarge' or `etch'. Additionally, the fact that the same set of
prebuilt binaries worked well on all the three Debian versions is more
coincidence than a rule. It is safer to distribute separate binaries
because of the possible (non-)availability dynamic libraries against
which our (Squeak virtual machine) binary is linked. This set of dynamic
libraries in general differs from Debian version to Debian version.

Details (what to write to your /etc/apt/sources.list file) are explained
in http://wiki.squeak.org/squeak/3616

I have tried to install and use the following three packages:
squeak
squeak-plugin
seaside
on all the three Debian versions:
stable
testing
unstable
I have noticed no problems. If anyone does, let me know.

When new Debian version rotation occurs (testing becomes stable,
unstable becomes testing and new unstable will be forked), those
repositories will be properly rotated to reflect that too.

New packages (if some will have to be created) and enhancements of the
existing ones will be put to the `unstable' subdirectory.

If Squeak relicensing to Apache License 2.0 succeeds, that will also
open new possibilities.

Regards
--
Matej Kosik

Re: Design Principles Behind Smalltalk, Revisited

On Jan 1, 2007, at 1:23 AM, J J wrote:

>> From: Todd Blanchard <tblanchard <at> mac.com>
>>
>> aDatabase readOneOf: User where: [:user | user login = 'jhouchin'].
>>
>> -Todd Blanchard
>
> Tools like GLORP are very nice: they save you writing SQL  
> directly.  But look at your line of code:  it is SQL in message form.

You know, that is a good point.  I think it would be easy to emulate  
the squeak collections operations though.
ie

database users detect: [:ea | ea login='todd'] -> readOneOf: User  
where:...
database users select: [] -> readManyOf:...
reject:....

Basically treating each entity as a collection.  That might be worth  
doing and should be pretty easy.
Good idea.

-Todd Blanchard

Symbol>>capitalized?

Squeak 3.7 ish -
I've got this meta model that stores attribute names as symbols.

I frequently derive labels from the attribute names and this often  
ends up calling #capitalized on the symbol.

I generally figure any string manipulation on a symbol results in a  
string but Symbol>>capitalized is implemented as

capitalized

	^self asString capitalized asSymbol

I found this while watching the process browser running a lengthy  
script in the background and found about 80% of time was spent in  
WeakSet scanFor:

I did a search of the image and couldn't find a single instance of  
sending capitalized to a symbol where the caller was going to use it  
as a symbol rather than a string.

So, in the name of performance, I vote to nuke this method or change  
it to just return a string.

Re: Design Principles Behind Smalltalk, Revisited

Hi!

Todd Blanchard <tblanchard <at> mac.com> wrote:
> 
> On Jan 1, 2007, at 1:23 AM, J J wrote:
> 
> >> From: Todd Blanchard <tblanchard <at> mac.com>
> >>
> >> aDatabase readOneOf: User where: [:user | user login = 'jhouchin'].
> >>
> >> -Todd Blanchard
> >
> > Tools like GLORP are very nice: they save you writing SQL  
> > directly.  But look at your line of code:  it is SQL in message form.
> 
> You know, that is a good point.  I think it would be easy to emulate  
> the squeak collections operations though.
> ie
> 
> database users detect: [:ea | ea login='todd'] -> readOneOf: User  
> where:...
> database users select: [] -> readManyOf:...
> reject:....
> 
> Basically treating each entity as a collection.  That might be worth  
> doing and should be pretty easy.
> Good idea.

Magma uses a similar trick in its query capabilities (in order to make
seemingly iterative block-code actually generate a query with
optimization and index-support). See here:
	http://wiki.squeak.org/squeak/5859

(search for #where: down that page)

I don't have time right now posting in this thread, let me just mention
that I disagree with JJ :) regarding the arguments for using an RDB
instead of an ODB. There are of course arguments in both directions -
depending on context - but IMHO the lifecycle-argument is not as clear
cut as described.

regards, Göran

Re: Symbol>>capitalized?

> I generally figure any string manipulation on a symbol results in a
> string but Symbol>>capitalized is implemented as
>
> capitalized
>
>         ^self asString capitalized asSymbol
>
> I found this while watching the process browser running a lengthy
> script in the background and found about 80% of time was spent in
> WeakSet scanFor:
>
> I did a search of the image and couldn't find a single instance of
> sending capitalized to a symbol where the caller was going to use it
> as a symbol rather than a string.
>
> So, in the name of performance, I vote to nuke this method or change
> it to just return a string.

I would be much more convinced if you had said "I've been making this
change to all my programs for the past year and have never ran into
any difficulty because of it."

There isn't much risk if you make that change to your image because
you will remember that you made the change and if you run into a
problem because of it, you'll probably catch it right away.  However,
if we make the change to the standard image then it might change the
behavior of someone's application who doesn't know the change was made
and so will have a hard time figuring out what happened.

I suggest you make that change in all your programs and report back
next year.  In fact, I encourage lots of people to make that change.
Then, when we have a debate in a year we can have testimonials like "I
tried it and everything was fine" or "I tried it and it broke XXX".
That would be the right time to make the change.  Or not.

Performance improvements are good, and we want to be continually
making them.  Hoever, they are rarely critical, and it is better to
check them out carefully before making them.

-Ralph Johnson

Re: Design Principles Behind Smalltalk, Revisited

>From: goran <at> krampe.se
>Reply-To: The general-purpose Squeak developers 
>list<squeak-dev <at> lists.squeakfoundation.org>
>To: The general-purpose Squeak developers 
>list<squeak-dev <at> lists.squeakfoundation.org>
>Subject: Re: Design Principles Behind Smalltalk, Revisited
>Date: Tue, 2 Jan 2007 10:56:23 +0200
>
>I don't have time right now posting in this thread, let me just mention
>that I disagree with JJ :) regarding the arguments for using an RDB
>instead of an ODB. There are of course arguments in both directions -
>depending on context - but IMHO the lifecycle-argument is not as clear
>cut as described.

Well, let me clarify my position a little.  I don't feel that ODB's are 
useless or anything.  Things you see in the Rails demo's should probably 
have been in an ODB (or even just objects, as Ramon's "blog in 15 minutes" 
showed).  I simply believe in the right tool for the right job, and you 
can't beat an RDB in it's domain.

It depends on what you are doing.  Sometimes in a powerful language like 
smalltalk you just keep your data in objects and let image persistence 
handle it.  Sometimes you want a little more so you write the data out to 
files.  Sometimes you want to go even further, and this is when an ODB can 
be a great solution.

But at the enterprise level (i.e. lots of different programs over a large 
organization) I still see RDBMS as the winner.  And the reason I see it this 
way is simply: SQL/RDB can be seen as a DSL system for dealing with set 
data.  There is a tremendous amount of power built into it for this 
particular domain that would be difficult to make more concise in another 
way.  I suppose it is just a question of how comfortable one is with SQL.

_________________________________________________________________
Get FREE Web site and company branded e-mail from Microsoft Office Live 
http://clk.atdmt.com/MRT/go/mcrssaub0050001411mrt/direct/01/

relational for what? [was: Design Principles Behind Smalltalk, Revisited]

J J wrote:
>> ... I simply believe in the right tool for the right job, 
> and you can't beat an RDB in it's domain. ...

That's something I've never really understood: what is the domain in 
which Relational Databases excel?

- Data too large to fit in memory? Well, most uses today may have been 
too large to fit in memory 20 years ago, but aren't today. And even for 
really big data sets today, networks are much faster than disk drives, 
so a distributed database (e.g., a DHT) will be faster.   Sanity check: 
Do you think Google uses an RDB for storing indexes and a cache of the WWW?

- Transactional processing with rollback, three-phase commit, etc? 
Again, these don't appear to actually be used by the application servers 
that get connected to the databases today. And if they were, would this 
be a property of relational databases per se? Finally, in world with 
great distributed computing power, is centralized transaction processing 
really a superior model?

- Set processing? I'm not sure what you mean by set data, JJ. I've seen 
set theory taught in a procedural style, a functional style, and in an 
object oriented style, but outside of ERP system training classes, I've 
never seen it taught in a relational style. I'm not even sure what that 
means. (Tables with other than one key, ...) That's not a proof that 
relational is worse, but it does suggest to me that the premise is worth 
questioning.

- Working with other applications that are designed to use RDB's? Maybe, 
but that's a tautology, no?

I'm under the impression (could be wrong) that RDBMS were created to 
solve a particular problem that may or may not have been true at the 
time, but which is no longer the situation today. And what are called 
RDBMS no longer actually conform to the original problem/solution space 
anyway.

Regards,
-Howard

Re: heading = forwardDirection + rotationDegrees (was Re: How can we deal with Message rot?)

On 2006 December 29 01:27, Jerome Peace wrote:
<<snip>>
> Many of the deep bugs I run into have the
> TransformationMorph decorator as their root.
> Lots of the gribble leaving problems come from a
> mismatch of assumptions between TfMorph ( which
> believes you can translate the origin into the 3rd
> quadrant) while every body else believes that truncate
> is the same as floor  because all points are in the
> 1st quadrant. Clipping boxes get calculated wrong and
> are often of by one just when you need them not to be.

Jerome,

Could you point out a few concrete examples (class, method) of this behaviour? 
I started work on a (exteremely limited) set of tests for etoys and morphic, 
and perhaps it would make sense to document what you found in a test; 
although documenting something that is (if I understand) considered broken 
may not be as valuable,  it should be easy to convert the test code if/once 
the code under test is refactored.

Thanks Milan

>
>
> Results: screen gribbles abound.
>
> >- inEtoys they are not used directly, but through the
>
> Player, and this is
>
> >why your equation does not hold for each individual
>
> morph. I think
>
> >you would have to eliminate TransformMorph
>
> completely, which might
>
> >complicate other Morphs - until now, that "ugly"
>
> transformation stuff
>
> >was factored out.
>
> As I look at the code I see constant attempts to worry
> about which morph is actually being talked to renderer
> or renderee. The code practically begs to be
> refactored. Its just a big job at the moment.
> I await enlightenment and inspiration. Meanwhile I am
> trying refactorings that lay the ground work for the
> simplification of the Tf mess.
>
> Yours in service, --Jerome Peace
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com