Yet another V.6 wish list

There are many ways to persist objects other than the image. If the problem
is about space you could use proxies, distribute the image or if you want
to buy something already done you could use Gemstone(*).
The problem I see with the database approach is that it means that a
system is a program + data. So is important to divide which objects are
data, and wich ones are behavior (or program, i.e. EXE). This division
causes a bad object design and compromise the future evolution of the
system.
About storing 2 gigas it would be interesting to do, because the relation
I have obtained migrating relational databases to objects was about 1/20.
2 gigas in objects is a lot, if you describe the application you have in
mind maybe I would understand.

(*) Gemstone is not a database, is a persistent Smalltalk.

Diego Coronel

Diego,

> There are many ways to persist objects other than the image. If the problem
> is about space you could use proxies, distribute the image or if you want
> to buy something already done you could use Gemstone(*).
> The problem I see with the database approach is that it means that a
> system is a program + data. So is important to divide which objects are
> data, and wich ones are behavior (or program, i.e. EXE). This division
> causes a bad object design and compromise the future evolution of the
> system.

Understood, but sometimes the injury is justified, either because there
is an external source that is relational, or the requirement is to
produce relational output.  There is also at times a performance argument.


> About storing 2 gigas it would be interesting to do, because the relation
> I have obtained migrating relational databases to objects was about 1/20.
> 2 gigas in objects is a lot, if you describe the application you have in
> mind maybe I would understand.

200,000 or more patients; find the 35 entries for a Robert Smith.  Do it
now :)  Faster =:0

BTW, I am NOT suggesting that all "document" data should be stored in a
relational format.  I get a lot of grief over that, but I agree with
you, except that I see value in letting MySQL optimize my queries,
telling me which blob to deserialize from a file to do the real work.


> (*) Gemstone is not a database, is a persistent Smalltalk.

It's also _very_ expensive.  At one point they were going to give me a
copy (hoping students would be exposed to it); I declined because I was
afraid of getting tied to something with such a big price tag.

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

Bill,
>200,000 or more patients; find the 35 entries for a Robert Smith.  Do it

now :)  Faster =:0

You could store entries in each patient, so you would not have to search,
just ask. Both indexing or adding direct references you are maintaining
redundant information to speed the system. With similar amount of work to
do and less work to the computer. Another problem of relational databases
is that they can't relate records, they only relate tables and let you put
indexes on them. So basically a database is always searching, that's why is
so importante their perfomance in that task. I think Smalltalk is more
about navigating or browsing, not searching or querying. Adding
"redundant" instance variables is less expensive in memory and proccesing
time than adding indexes to tables.
I totally agree with you that are lot of cases where you have to use
databases, and I have discarded Gemstone for the same reason than you. I
say that because I thought Kirk could be interested in take a look at a
working persistence solution.

Diego Coronel

Andy/Blair:

Will version 6 expose the compiler?  I have wanted for years to get full
Smalltalk parse trees, so that I can use my syntax coloring stuff from VW.
As I recall, Dolphin's syntax coloring was very limited, and I chose not to
use Dolphin largely for that reason.  It's one of those creature comforts
that matter greatly.

Does the current Dolphin have a full RBBrowser?  I ask because I like to use
RBConfigurableFormatter, as well.  I have customized this class just as I
want it in VW, and would like to port it to Dolphin.

Will version six have name spaces?  I'm looking for an easy way to prevent
collisions between same-name classes.  This is one big reason why I used VW.

I do a lot of math and 3D graphics (OpenGL)--Integer, Float, and Double
math, and VW has always run faster than all of the Smalltalks I've tested
(VW, VAST, Dolphin, MT, Squeak).  Though Dolphin likely has faster external
interfacing to a DLL, the number crunching has been a problem.  This would
improve with a direct-pointer model in Dolphin.  Will that happen in version
6?

I used Dolphin very intensely and with great fondness, from its beginning in
late 1995 (I was the second person to post to the original Dolphin
newsgroup!) to about 1998 when I started to become frustrated with my
ability to change certain aspects of it behavior (compiler, namespaces) and
with its speed during math operations (direct pointers).  There were some
minor UI problems involving the View Composer and modal dialogs, as I
recall.  But all of this I could have fixed if I had been able to separate
my code from the base classes.  Lack of namespaces limited my experimenting,
and lead to my disconnecting.

Except for these specific problems, which have temporarily stopped my use of
Dolphin, I think that it is the most approachable, most usable,
best-organized, most common-sense Smalltalk environment.  (My list of
complaints for VW is much longer, but they are not show-stoppers for me).

I used Dolphin more when it was free for me.  I bought a Dolphin XP Pro 5
license a couple of years ago, but have done little more than poke around
the class hierarchy, and look at the nice GUI.

How much would a Dolphin 6 upgrade cost?


Regards,

Shaping

"DiegoC" <[hidden email]> wrote
> I have discarded Gemstone for the same reason than you. I
> say that because I thought Kirk could be interested in take a look at a
> working persistence solution.

Thanks but I've learned about all I can from Gemstone from their
documentation and OOPSLA conference proceedings without actually buying or
seeing a copy.  I even interviewed with them for a job.  The database I
designed was an OODB which may differ from other's ideas of persistace.  I
haven't reviewed my code lately, perhaps I could find enough speedups to
make it worthwhile.

On Tue, 28 Dec 2004 20:26:08 -0500, Bill Schwab
<[hidden email]> wrote:


>It's also _very_ expensive.  At one point they were going to give me a

What does "very" approximately mean in this context? O:-)

Diego,

> You could store entries in each patient, so you would not have to search,
> just ask.

Consider the GC load associated with keeping 250 million or more
patients in memory at one time =:0   This is a case in which an RDB
really shines, as long as it's not taken to extremes.


 > Both indexing or adding direct references you are maintaining
> redundant information to speed the system. With similar amount of work to
> do and less work to the computer. Another problem of relational databases
> is that they can't relate records, they only relate tables and let you put
> indexes on them. So basically a database is always searching, that's why is
> so importante their perfomance in that task. I think Smalltalk is more
> about navigating or browsing, not searching or querying. Adding
> "redundant" instance variables is less expensive in memory and proccesing
> time than adding indexes to tables.

Fair enough, but again, I load only those patients currently being
accessed rather than ALL of them.

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

Fernando,

> What does "very" approximately mean in this context? O:-)

IIRC, it was $10,000 per seat plus runtime fees.  Whatever it was, it
was just too much money.

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

"True Christian" <[hidden email]> wrote
> VB.Net and Delphi code which uses advanced library functions -- I must ask
> for an equaivalent or better library in Dolphin 6.

Well at least this topic generated more interest than my requests for more
and better documentation and renaming the Smalltalk library to easier class,
variable, and method names.  Has it earned a place on the D.6 development
agenda yet?

> variable, and method names.  Has it earned a place on the D.6 development
> agenda yet?

You actually think that at this point in time, so closw to a d6 release,
that there is going to be any such major change.

Rename the classes and variables in your own image. Thats whats great about
it, if you want to, you can do it.

Go grab that thesaurus and get cracking.

True Christian wrote:

> Has it earned a place on the D.6
> development agenda yet?

You do realise that you haven't actually made any suggestions yet ?  Both this
and the documentation/renaming ideas can be paraphrased (without loosing
information) as "make it better" -- which is kind of difficult to plan, let
alone code.

    -- chris

"Shaping" <[hidden email]> wrote in message
news:41d2600e$[hidden email]...
> Andy/Blair:
>
> Will version 6 expose the compiler?  ...

No more than D5 does, however D5 already uses the RB parser in the browsers
(the classes are renamed because they have been extended and are 100%
compatible with the RB parser classes, but they are compatible enough for
the RB refactoring engine to use through aliasing).

>...I have wanted for years to get full Smalltalk parse trees, so that I can
>use my syntax coloring stuff from VW.

Assuming you've used the RB parse trees from the RB parser rather than the
Smalltalk-80 ones then you could do that in Dolphin 5. It probably wouldn't
take much effort to pull in John Brant's code to try it out.

> As I recall, Dolphin's syntax coloring was very limited, ...

Precisely how was it "very limited"?

>...and I chose not to use Dolphin largely for that reason.  It's one of
>those creature comforts that matter greatly.

Seems a bit odd, since you had to implement your own syntax colouring for VW
anyway...

Actually the default colouring in D6 occurs dynamically and is largely done
by lexical analysis. You could turn this off and do your own if you wanted.
You'd probably have to if you want to go beyond what is strictly syntax
colouring - e.g. if you wanted to colour different variable types
differently, since syntactically there is no distinction between one
variable and another.

Creating a syntax colourer using the RB parse tree that is already built by
the D5 browsers would be relatively trivial. All you need to do is build a
StParseNodeVisiter (like the RB formatters).

> Does the current Dolphin have a full RBBrowser?  I ask because I like to
> use RBConfigurableFormatter, as well.  I have customized this class just
> as I want it in VW, and would like to port it to Dolphin.

Dolphin 5 includes the RBConfigurableFormatter.

> Will version six have name spaces?  I'm looking for an easy way to prevent
> collisions between same-name classes.  This is one big reason why I used
> VW.

No.

> I do a lot of math and 3D graphics (OpenGL)--Integer, Float, and Double
> math, and VW has always run faster than all of the Smalltalks I've tested
> (VW, VAST, Dolphin, MT, Squeak).  Though Dolphin likely has faster
> external interfacing to a DLL, the number crunching has been a problem.
> This would improve with a direct-pointer model in Dolphin.  Will that
> happen in version 6?

No, although there are some performance improvements. Frankly I don't think
FP performance using boxed floats is adequate for all purposes in any
mainstream Smalltalk. It doesn't really have anything to do with whether or
not the Object Memory uses a direct-pointer model or not, the fundamental
problem is the boxing of intermediate floating point values as full objects.
Smalltalk MT is particularly targetted at that sort of work, and its code
can (I understand) be optimised to avoid boxing intermediate float values,
and so if you use it correctly I don't doubt its FP performance would be in
a different league.

>...[snip]...

Regards

Blair

Hi Blair.

>> Will version 6 expose the compiler?  ...
>
> No more than D5 does, however D5 already uses the RB parser in the
> browsers (the classes are renamed because they have been extended and are
> 100% compatible with the RB parser classes, but they are compatible enough
> for the RB refactoring engine to use through aliasing).

I don't recall the exact problem, but it was either that there were not
enough colors to choose from (limited palette) or there wasn't a detailed
parse tree available so that you could color anything you wanted.  I think
it was the latter.  Practically, can I syntax-highlight with the Dolphin RB
the way I can with the VW RB?

>
>>...I have wanted for years to get full Smalltalk parse trees, so that I
>>can use my syntax coloring stuff from VW.
>
> Assuming you've used the RB parse trees from the RB parser rather than the
> Smalltalk-80 ones then you could do that in Dolphin 5. It probably
> wouldn't take much effort to pull in John Brant's code to try it out.

I'll ask John.

>
>> As I recall, Dolphin's syntax coloring was very limited, ...
>
> Precisely how was it "very limited"?

I could not get a handle on every syntax feature.  For example, I don't
think I could distinguish between temps and block input arguments or some
other class of variable or argument (can't remember exactly).  I remember
asking Andy about the this limitation, and the discussion turned to how the
Dolphin compiler is not exposed.

>
>>...and I chose not to use Dolphin largely for that reason.  It's one of
>>those creature comforts that matter greatly.
>
> Seems a bit odd, since you had to implement your own syntax colouring for
> VW anyway...

Sorry, I just realized that I'm confusing formatting with coloring.  No,
you're right: I have not changed the RB coloring much, just a few small
tweaks.  The RBConfigurableFormatter, though, I overhauled, and I want to
port this.  I still need a parse tree for that.

>
> Actually the default colouring in D6 occurs dynamically and is largely
> done by lexical analysis. You could turn this off and do your own if you
> wanted.

Good.  Then I should be able to use the RB stuff.

> You'd probably have to if you want to go beyond what is strictly syntax
> colouring - e.g. if you wanted to colour different variable types
> differently, since syntactically there is no distinction between one
> variable and another.

Exactly.  That is what I recall.

>
> Creating a syntax colourer using the RB parse tree that is already built
> by the D5 browsers would be relatively trivial. All you need to do is
> build a StParseNodeVisiter (like the RB formatters).

RBConfigurableFormatter implements a visitor pattern.  I suppose there is
something similar in the existing RB color stuff (CodeParserHighlighter
maybe), but have not looked at it carefully.

>
>> Does the current Dolphin have a full RBBrowser?  I ask because I like to
>> use RBConfigurableFormatter, as well.  I have customized this class just
>> as I want it in VW, and would like to port it to Dolphin.
>
> Dolphin 5 includes the RBConfigurableFormatter.

Great.

>
>> Will version six have name spaces?  I'm looking for an easy way to
>> prevent collisions between same-name classes.  This is one big reason why
>> I used VW.
>
> No.

Is this planned?  Is there another way?



Makes sense.  I don't know whether VW boxes floats.

The performance problem seems not mostly math-related, but also traversal-
and definitely growth-related.  There is always much tree growth during the
calculations.  Traversal involves pointers from node to node.  Nothing is
cached; so I don't see how there could be much difference between VW and
Dolphin, respecting traversals.  Maybe I've missed something.  Perhaps VW's
compiler optimizations help significantly.  I should do another comparative
performance test, with an unchanging tree.

VW has seven or so tunable memory spaces, and this could be where I'm
getting the extra performance.  The model grows large (100s of MB), quickly
(10 minutes or so).  Each node in the tree is 80 to 100 bytes.  Perhaps
judicious handling of large numbers of objects in this size range is
helping.  I don't remember much of Dolphin's memory strategies/policies, but
do remember topping-out at one point and having to change the upper memory
limit.


> Smalltalk MT is particularly targeted at that sort of work, and its code
> can (I understand) be optimised to avoid boxing intermediate float values,
> and so if you use it correctly I don't doubt its FP performance would be
> in a different league.

Yes, I tested MT, and it is remarkably fast, but awkward in some ways.  I
couldn't get much work done, before becoming disgusted with mechanical
issues.

Dolphin is most pleasant and productive for quickly and accurately assessing
what you have, finding things, changing things, and being certain of what
you have at each step.  MT's design is very close to the metal and the class
hierarchy is not very abstract.  I don't recall much in the way of coloring
or formatting, either.  The debugger was difficult to work with at one time
(around version 3 something, I think), and would cause the image to crash
several times a day.  I had the same large model then.  MT used (and may
still use) the Windows process heap for objects.  I don't think there is any
optimized-for-Smalltalk handling of memory allocation.  If anyone knows more
about this, please tell.

How much is the D6 upgrade for a Dolphin XP Pro 5 owner?


Regards,

Shaping

Shaping wrote:

> Makes sense.  I don't know whether VW boxes floats.

IIRC, VW 7.3 introduced unboxed floats, but only in 64-bit VMs.

    -- chris

"Chris Uppal" <[hidden email]> wrote in message
news:[hidden email]...
> Shaping wrote:
>
>> Makes sense.  I don't know whether VW boxes floats.
>
> IIRC, VW 7.3 introduced unboxed floats, but only in 64-bit VMs.
>

Will Dolphin have unboxed floats in D6 (or later)?


Shaping

What I would like to see in Dolphin is the following:

1) Auto completion (intellisense) while coding in the IDE similar to
Visual Studio.
2) Namespaces and real private methods.
3) .NET libraries interface
4) Source saved as XML would be nice.
5) Simpler way to make forms. Form class?
6) Minor language enhancements E.g. built in case.

The first one is critical because it makes life easy when coding given
the thousands of classes and messages and the typing, but I can see its
a difficult one to implement without data types.  When VB programmers
complain about ease of use this is what they mean. They are spoiled by
intellisense and this capability alone would expand the user base.

I like Dolphin but I can't use it seriously at this point because of #1
and #2. Either way I will upgrade when it's out just because it's fun
to experiment with.

Thanks

<[hidden email]> wrote in message
news:[hidden email]...
> What I would like to see in Dolphin is the following:
>
> 1) Auto completion (intellisense) while coding in the IDE similar to
> Visual Studio.
...
> The first one is critical because it makes life easy when coding given
> the thousands of classes and messages and the typing, but I can see its
> a difficult one to implement without data types.  When VB programmers
> complain about ease of use this is what they mean. They are spoiled by
> intellisense and this capability alone would expand the user base.

You may find this of interest:
http://www.mitchellscientific.com/smalltalk/CJDLookUp.htm
It is something like intellisense for Dolphin.  I understand what you mean,
and I use my tool a lot.

Chris

> and real private methods.

=====:0

IMHO that would be a seriously bad idea.  The potential to break stuff
would be high.  I further suspect that it would be expensive to enforce,
though I could easily be wrong on that.  As it is, I mark things as
private just to make the public methods stand out in comparison, secure
in the knowledge that there are no "private method police" to cause trouble.


> 3) .NET libraries interface

Squeak has a start at it.  It might be possible to port it.  So far,
I've seen it invoke a message box or two, and that's about it; I have no
idea of its capabilities or limitations.


> 4) Source saved as XML would be nice.

What would you do with it?  There are already some version control
options, if that is your goal.  Otherwise, you can simply file out code,
or drag methods (or categories) to a workspace.  Ian recently added a
clipboard open command to his chunk browser, making it even easier to
browse the results of such efforts.


> 5) Simpler way to make forms. Form class?

If you are thinking of .NET forms, then I have no answer for you, but if
you want to create composite presenters, then you might want to look at
my MVP Generators base package, and AspectDrivenViewGenerator in
particular.  It might do what you want, or serve as an example for
creating a tool that would meet your needs.  I use a different
ViewGenerator subclass to place hundreds of controls and write code to
connect them to models and aspects thereof.  AspectDrivenViewGenerator
is just a quick example by comparison, but it shares a lot of code with
something that is well tested.


> 6) Minor language enhancements E.g. built in case.

Dictionaries or arrays work fairly well for that kind of thing.
#perform: has been helpful at times (e.g. state machines).  It seems
that I run into it on a large scale only when it is forced from the outside.


> The first one is critical because it makes life easy when coding given
> the thousands of classes and messages and the typing, but I can see its
> a difficult one to implement without data types.  

One wonders about performance (less typing means more possible matches,
which means more items in any lists), and about whether it would be
worth the trouble of scrolling through all of the options.  However, it
might pay to do a web search, because you are not the first to want the
capability.

It would no doubt be easier to do something like this in the debugger,
at least for the classes lurking in the stack frames.  That would be
more than adequate for many situations, especially if one is already
fond of programming in the debugger.

In the devil's advocate role, I note that absense of types and existence
of blocks results in much less code to accomplish a particular task, at
least given a design that takes advantage of Smalltalk.  Put another
way, if I had to write as much code as I did in my C++ days, then I
would be much more interested in smart completion, as it is, I really
don't miss it.


 > When VB programmers
> complain about ease of use this is what they mean.

ok.


 > They are spoiled by
> intellisense and this capability alone would expand the user base.

Not so sure.  I should think that being freed from VB's syntax and other
limitations would be cause for making some concessions; conversely,
there is never a shortage of excuses to avoid using something.  However,
I agree that done well, it would be a nice addition, provided it has an
off switch (which would be trivial).


Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

We can argue all day on the merits of intellisense but there is only
one reason it's not available in Smalltalk: It can't be implemented
without datatypes and rewriting all the classes, an unreasonable thing
to expect.

About the only suggestion I have is actually something simple:

At any workspace allow a hot key that opens an always-on-top mini
browser to allow you to choose the class/method. You can then drag and
drop (or double click) the method signature onto the workspace at the
cursor. The mini browser then closes or optionally stays open until you
close it.

As a matter of fact, if the receiver is known (e.g. a class or literal)
it could even position directly to that class.

[hidden email] wrote:
> What I would like to see in Dolphin is the following:
>
> 1) Auto completion (intellisense) while coding in the IDE similar to
> Visual Studio.
> 2) Namespaces and real private methods.
> 3) .NET libraries interface
> 4) Source saved as XML would be nice.

Using Source Tracking System you can export Dolphin packages and
projects into XML file. Projects in STS are groups of packages which can
be loaded or versioned together so that you know which package versions
belong together.

With STS you can also export multiple packages into a single XML file
and then import this file into another image. Plus, you can import
Visual Works XML source code, VAST .app exports and Squeak packages.

You can find more information about STS including screen-shots on our wiki:

http://wiki.gorisek.com

Best regards,

David Gorisek