What Would Make D6 The best overall ST/Dev environment?

Guys - I am interested in building up a list of things we could rally round
to make Dolphin 6 the best overall development environment in 2006.

I'm not talking about little UI tweaks here and there, but large labraries
and ways of working that are holding us back from convincing Ruby
programmers that we are much more productive.

On my list are the following (and they aren't that hard to implement I don't
think):

- A decent Web Framework (either a port of Seaside that works, or additons
to Swazoo to provide maintable templating like Velocity or FreeMarker).
Along with this, a convincing (or well documented) mechanism for deplying
new apps to a webserver so it just reloads them and keeps working. I want to
compete with Ruby on Rails

- A public Store of apps. Like SqueakMap or Cincom store - I can connect,
get a list of the latest apps and just download the versions from there.
Possibly having Config maps of known working components too - so I can just
get a web development environment into my image

- I think databases are covered with ReStore (not sure if Glorp has been
properly ported to D6 or not yet)

- A continous integration solution. I want Cruise Control for dolphin (but
with a better solution than nasty Ant) so I can save packages and have them
built and tested automatically in a fresh image (continously)

- Breakpoints (its a small one, but it does get on my nerves typing self
halt all the time, and it spoils demo's to other developers)

Those are the ones that come immediately to mind. I am interested in this
list as in the new year maybe we can rally resources to know things off the
list and win some awards in 2006.

Tim

"TimM" <[hidden email]> wrote in message
news:dob25a$u0n$[hidden email]...
> Guys - I am interested in building up a list of things we could rally
round
> to make Dolphin 6 the best overall development environment in 2006.

 From the community area, I miss dolphin wiki. It is true that there were not
many contributions, but thiose that were there really helped me to cut
through on several occasions.

 From the library point of view I think that it is esseintial that we find a
way for Dolphin harbour projects to remain maintained and further
developed.I was allways amazed by amount of work and knowledge that had been
put into them. On the other hand most of goodies found there are essential
to make modern apps quickly.

Other libs that I think would be needed:
-  SSL
-  LDAP
-  IIOP

Now moving of the tangent here is one othe things that I wondered about
(from the bin - "take any 12 ideas for a cent"). For some other purpose, I
have thought of kind of holder that can host various php libraries, and make
them available to the Dolphin. It would be somewhat similar to the
ExternalLibrary, but it could generate all its methods from the meta
information that each php library caries (names and signatures of
functions). While not perfect, and less efficient than writing wrappers
directly , this might allow us to tap the very large pool of php extension
libraries quickly.

rush
--
http://www.templatetamer.com/
http://www.folderscavenger.com/

Tim,

I am thinking about something similar. Please send me your e-mail
address for further discusion.

Best regards,

David Gorisek

TimM wrote:

Hi TimM,

TimM escribió:
> Guys - I am interested in building up a list of things we could rally round
> to make Dolphin 6 the best overall development environment in 2006.

Isn't it already? ;-)

> I'm not talking about little UI tweaks here and there, but large labraries
> and ways of working that are holding us back from convincing Ruby
> programmers that we are much more productive.

The evangelization or propaganda may sound good at first, but in the
long term may be counter productive, you can get swarms of
developers that add noise. Publicity, and person to person
communication will be best in the long time, IMVHO.

> On my list are the following (and they aren't that hard to implement I don't
> think):

> - A decent Web Framework (either a port of Seaside that works, or additons
> to Swazoo to provide maintable templating like Velocity or FreeMarker).

With good winds, and some OA support in the first quarter of 2006,
Seaside port can be completed.

About the swazoo templating, it is achievable.

> Along with this, a convincing (or well documented) mechanism for deplying
> new apps to a webserver so it just reloads them and keeps working.
 > I want to compete with Ruby on Rails

Can you explain a little more about this?

> - A public Store of apps. Like SqueakMap or Cincom store - I can connect,
> get a list of the latest apps and just download the versions from there.
> Possibly having Config maps of known working components too - so I can just
> get a web development environment into my image

I agree with this.

> - I think databases are covered with ReStore (not sure if Glorp has been
> properly ported to D6 or not yet)

Databases support is built-in through ODBC support and ADODB interfaces.
For persistence on RDBMS the more "mature" frameworks are ReStore
and GLORP.
For object persistence OmniBase is the only choice.

> - A continous integration solution. I want Cruise Control for dolphin (but
> with a better solution than nasty Ant) so I can save packages and have them
> built and tested automatically in a fresh image (continously)

Does a Cruise Control like system couple with the smalltalk philosophy?
The integration could be done through dolphin packages, the build is
done by shrinking, so no "integration" problems would exist.

> - Breakpoints (its a small one, but it does get on my nerves typing self
> halt all the time, and it spoils demo's to other developers)

This is a must. Implementing tracing and breakpoint support is a
true need. Considering that using a versioning system such as STS
would add a new version on each method save.

> Those are the ones that come immediately to mind. I am interested in this
> list as in the new year maybe we can rally resources to know things off the
> list and win some awards in 2006.

The awards will come.

Best regards,

--
Esteban.

> - I think databases are covered with ReStore (not sure if Glorp has been
> properly ported to D6 or not yet)

Has GLORP been succesfully ported to Dolphin 5.1 in the first place ?
Because I have tried to use the port of Glorp 0.3.71 I found in SourceForge
with Dolphin 5.1, but after a couple of hours of fixing little things, half
of the unit tests still didn't pass, and I reached the point where I
couldn't fix anything else without some understanding of the framework, and
needed a working framework to be able to understand it. So I gave up.
Did anyone have more luck with this port ?

TimM wrote:

- a report library such like JFreeReport (http://www.jfree.org/jfreereport)
or JasperReports (http://jasperreports.sourceforge.net)

Andreas

TimM wrote:
I haven't heard of ReStore for quite a while. I have the impression that it
is not actively maintained anymore.
GLORP in its current state is neither maintained (at least the Dolphin port)
nor documented. Such a beast needs an active maintainer and decent
documentation. IMO it is not usable in a production environment today.
Thus, there is a strong need for a (working and maintained) O/R mapper
library...

Andreas Wacknitz <[hidden email]> wrote in
news:[hidden email]:
>> - I think databases are covered with ReStore (not sure if Glorp has
>> been properly ported to D6 or not yet)
> I haven't heard of ReStore for quite a while. I have the impression
> that it is not actively maintained anymore.
> GLORP in its current state is neither maintained (at least the Dolphin
> port) nor documented. Such a beast needs an active maintainer and
> decent documentation. IMO it is not usable in a production environment
> today. Thus, there is a strong need for a (working and maintained) O/R
> mapper library...
 
The Glorp Dolphin port hasn't been actively worked on in a while, as people
have noticed. I have many excuses, if anyone cares. I haven't even upgraded
to D6 yet, and the last release that was really tested against Dolphin 5
was a while ago.  

I do try to keep the code portable, and if anyone tells me about things
that are broken, I will get them fixed, I just haven't gotten around to
doing the testing, and no one else has either.  Most of the things are
pretty simple, amounting to dialect portability issues around e.g. meta-
protocol or exceptions. Also, the way Glorp is broken up into packages, you
can get some out of scope reference issues in Dolphin, which I mostly solve
either by sneaky meta-programming or by moving methods into class
extensions (not necessarily in that order). I also haven't tested the file-
out packages from VW to Dolphin against D6.

There are some larger things that could use porting, e.g. the use of weak
references in caches, or better support for binding or other driver-level
features, but the framework is such that those can easily be left out and
it uses lowest common denominator.

So, I'd agree that Glorp definitely needs a Dolphin maintainer. Volunteers
heartily welcomed, please queue on the left. Documentation is also an
issue, especially as far as the sorts of internals that are likely to break
when porting across dialects. The documentation that exists is definitely
user-level. There are people using it in production (although I don't know
offhand of any in Dolphin) but it's still in many respects bleeding-edge.

I have no idea at all about the state of ReStore, but I did see the
Smalltalk Solutions presentation on it a couple of years back, and it
looked really cool.

--
Alan Knight [|], Cincom Smalltalk Development
[hidden email]
[hidden email]
http://www.cincom.com/smalltalk

"The Static Typing Philosophy: Make it fast. Make it right. Make it run." -
Niall Ross

> > - Breakpoints (its a small one, but it does get on my nerves typing self
> > halt all the time, and it spoils demo's to other developers)
>
> This is a must. Implementing tracing and breakpoint support is a
> true need. Considering that using a versioning system such as STS
> would add a new version on each method save.
>

+100000000000000000  This is a must.

"David Gorisek" <[hidden email]> wrote in message
news:43a93493$[hidden email]...
> Tim,
>
> I am thinking about something similar. Please send me your e-mail address
> for further discusion.

Me too!

"TimM" <[hidden email]> wrote in message
news:dob25a$u0n$[hidden email]...
> Guys - I am interested in building up a list of things we could rally
> round to make Dolphin 6 the best overall development environment in 2006.
...
> - A public Store of apps. Like SqueakMap or Cincom store - I can connect,
> get a list of the latest apps and just download the versions from there.
> Possibly having Config maps of known working components too - so I can
> just get a web development environment into my image
...

I would like to see this happen.  I think it is important that it be
sanctioned by OA, perhaps they could provide a link to it in Dolphin.  Also
there needs to be some degree of security.  I do not think it should be
completely open, like a Wicki.  Smalltalk packages are fundamentally
executable code, and just the act of loading them executes code.  I would
not want someone else being able to replace my goodie packages with
something potentially malicious.

It seems like there is some interest in using STS to facilitate a central
code repository.  That is an interesting idea, but there are some concerns
that need to be explored.  I think there needs to be a good way of searching
and classifying goodies.  There should also be a way of easily providing a
link to a webpage with more information, perhaps documentation, screen
captures, etc...  I don't think Dolphin CE will have built-in support for
STS and I think the repository should be accessible to Dolphin CE users.
There should be some protection against filing-in of malicious code.  There
should at least be a way to view the code before executing any part of it.
It might also be good if there were a way to rate the usefulness of goodies.
This could lead newbies to the goodies that the Dolphin community finds most
generally useful.

Chris

TimM wrote:
> ... not talking about little UI tweaks here and there, but large labraries
> and ways of working that are holding us back from convincing Ruby
> programmers that we are much more productive.


I understand Ruby is quite close to Smalltalk, supporting blocks etc.
So it should be a 'relatively' simple matter to modify the Smalltalk
compiler to parse Smalltalk, but at the same time produce Ruby
source-code.

After this the Ruby programmers could do most of their Ruby programming
& debugging in the best-of-breed Dolphin 6 environemnt. Especially
the Community Edition might get a big user-base & publicity via
this trick.

A complementary project, perhaps more demanding, would be to
modify the Ruby parser so it actually produces Smalltalk code.
This would provide a way to import most (?) existing Ruby libraries
into Smalltalk.

And now that I'm into this, let me be a little schizophrenic, and say
that in fact Groovy might be a better 'peer-language' after all.

Thanks
-Panu Viljamaa

> I understand Ruby is quite close to Smalltalk, supporting blocks etc.
> So it should be a 'relatively' simple matter to modify the Smalltalk
> compiler to parse Smalltalk, but at the same time produce Ruby
> source-code.

Thats an interesting thought - although I think that most Ruby programmers
are "so caught up in their world" that they wouldn't quite see it that way.
To them Ruby is the savior language - and while it is re-teaching every one
that dynamic languages have always been good, its created a wave of
programmers who are pretty caught up in their world (so I think they would
sniff at it). Still you are right - it would be a nice advertising gimmick
;-)

Generating Ruby Smalltalk shouldn't be too bad, doing it the other way
around might be quite difficult. The language is notoriously hard to parse,
and lacks the simplicity of the Smalltalk grammer (so I've been told, and
some of the examples my Ruby friends have shown me seem to confirm this).
There are strange things going on with blocks, and lots of extras added to
the language that don't need to be there.

This said, that community has done a lot with what they've got - and I want
to both learn from where they've been successful, and copy the best bits.

This community (e.g. Smalltalk) has rested on its laurels for too long -
there is lots of good stuff, packaged up quite badly which is fairly
unapproachable to the mass of programmers. Some might argue this is a good
thing (many programmers aren't) - however for the good ones, that little
extra oomph that the ruby community has created is whats needed here.

So rather than helping the Ruby community (it has enough help) I would like
to see Smalltalk standup and become well again. We can all chip in by fixing
someof the basic tools that modern programmers expect. Make them work well
together, and provide "configuration maps" of tools that can be simply
loaded into an image in one hit. Provide a video/screencast to show how to
use them and a sample app to show it all working in action. Thats what Ruby
on Rails does - and it embarrasses me that Smtalltalk is not lke this, when
it obviously should be.

Tim

Two datapoints from me:

On Wed, 04 Jan 2006 08:34:02 +0000, TimM wrote:

> Thats an interesting thought - although I think that most Ruby programmers
> are "so caught up in their world" that they wouldn't quite see it that
> way. To them Ruby is the savior language - and while it is re-teaching
> every one that dynamic languages have always been good, its created a wave
> of programmers who are pretty caught up in their world (so I think they
> would sniff at it). Still you are right - it would be a nice advertising
> gimmick ;-)

In Ruby-dom you can find more open-minded people than in other lang-doms.

Most Ruby programmers came to Ruby from other languages with a low entry
barrier. Being a "scripting language", however, implies/requires/enforces
a specific mindset of problem solving that is different from one suitable
with an image based language, be it Smalltalk, Lisp, Forth (to some extent).

FWIW, I learned Smalltalk *after* a first flirt with Ruby some years back,
when it was at version 1.2 or so... Having worked with blocks in Ruby, I
found that blocks in Smalltalk were "that cool thing I remember from
Ruby", only more consistent and elegant.

> Provide a
> video/screencast to show how to use them and a sample app to show it all
> working in action. Thats what Ruby on Rails does - and it embarrasses me
> that Smtalltalk is not lke this, when it obviously should be.

You know what? This over-professional marketing is a major turn-off for me
when I am asked to do some Rails stuff. Videos can be so misleading...
make everything look so simple, which it is not.

Your SMock presentation is actually good, as I can take time off to read
up on concepts that I'm not up to speed with or try things out... I even
let the browser sleep in vmware for two days, while I was offline. Nice.

So if you want to put work into presenting/documenting Smalltalk, please
use a format, where the reader can decide the speed.

Kind regards,
s.

TimM wrote:
...
> Generating Ruby Smalltalk shouldn't be too bad, doing it the other way
> around might be quite difficult.

Yes, that's the weak part of my proposal. Riby programmers would
not want to leave all their existing Ruby classes and libraries
behind.

But on the other hand Ruby has also features which standard ST
does not have like 'mixins' and runtime class-extension.  There
are ways to do similar things in Smalltalk, but they are not (?)
well-supported by language vendors, and not portable across
dialects.

  ...
> So rather than helping the Ruby community (it has enough help) I would like
> to see Smalltalk standup and become well again. We can all chip in by fixing
> someof the basic tools that modern programmers expect.

It's a bit of a chicken-egg problem. To get lots of open source
projects going there needs to be a lot of programmers, to
attract even more programmers.

Dolphin 6 looks great, and with the community edition, there's
now a good chance of the community growing and thriving. one
thing which I'd hope to see more, is articles in the press
about it.


-Panu Viljamaa

TimM wrote:
> Guys - I am interested in building up a list of things we could rally round
> to make Dolphin 6 the best overall development environment in 2006.


Here's some of my favorite wishes:

1) Interoperability with Java VM, servlets.
     (perhaps unreasonable to ask for, but).

2) Integrated SQLLite database.
     This is a cool product in the public domain
     http://www.sqlite.org/. Integrating it
     to Dolphin would allow us to create
     standalone apps with an embeddded database.

3)  Supporting memory-mapped files.
     This way part of the image could be stored
     directly to disk, making objects 'transparently
     persistent. The image as an object-database.


Wish #1 would increase the commercial viability
of Dolphin a lot. #2 would add a 'missing feature'
(embedded SQL database) to it.  #3 would increase
its wow -factor (which is good for marketing)
even further.

-Panu Viljamaa

"panu" <[hidden email]> wrote in message
news:43c5ed40$[hidden email]...
> TimM wrote:
>> Guys - I am interested in building up a list of things we could rally
>> round to make Dolphin 6 the best overall development environment in 2006.
>
> Here's some of my favorite wishes:
>
> 1) Interoperability with Java VM, servlets.
>     (perhaps unreasonable to ask for, but).

This may be of interest to you, though it says it does not work in Dolphin 6
(yet?):
http://www.metagnostic.org/DolphinSmalltalk/JNIPort.html

> 2) Integrated SQLLite database.
>     This is a cool product in the public domain
>     http://www.sqlite.org/. Integrating it
>     to Dolphin would allow us to create
>     standalone apps with an embeddded database.

It sounds like someone is working on SQLite for Dolphin.
http://www.arcturus.com.au/dolphin/

> 3)  Supporting memory-mapped files.
>     This way part of the image could be stored
>     directly to disk, making objects 'transparently
>     persistent. The image as an object-database.

See the class MemoryMappedFile in Dolphin 6.0.  I am not sure of the extent
of the implementation, but it is there.

It seems like Dolphin may be close to having these features.

Chris

>> 2) Integrated SQLLite database.
>>     This is a cool product in the public domain
>>     http://www.sqlite.org/. Integrating it
>>     to Dolphin would allow us to create
>>     standalone apps with an embeddded database.
>
> It sounds like someone is working on SQLite for Dolphin.
> http://www.arcturus.com.au/dolphin/

rush was working on it too. I sat down one night and started to play, (hence
the note about it on my site) but I never finished it. I probably should
given that when I originally started it I had a poor understanding of C, and
the troubles I had were mainly to do with the external calls I was making. I
could probably finish the work in a weekend now; Only problem is I'd rather
use either ReStore or OmniBase.

Sean M wrote:
> ... I could probably finish the work in a weekend now; Only problem is I'd rather
> use either ReStore or OmniBase.

I think OO databases are better in principle too, yet not for
all audiences and all customers.

The reason I like the idea of using SqlLite as an embedded database
with Smalltalk is that it would make my code-base ready for use with
any other SQL-database as well (hopefully via a simple configuration
switch). For a corporate customer it is often  a requirement that the
data can be available to other enterprise systems in a seamless fashion,
meaning Oracle etc.

On the other hand having an embedded database means we can build
a product that it the simplest possible to install as a desktop
application for the end-user. Thhey don't want to be bothered
with gettting the ODBC configuration correct, installing a separate
database etc.

When comparing to Java, it has Derby and HSQL available as
free embeddable SQL databases.

Dolphin + Embedded SQL-Lite could be a killer product for
developing desktop database applications for Windows.

-Panu Viljamaa

panu wrote:

> On the other hand having an embedded database means we can build
> a product that it the simplest possible to install as a desktop
> application for the end-user. Thhey don't want to be bothered
> with gettting the ODBC configuration correct, installing a separate
> database etc.

Agreed that there is a need for a lightweight, installation-free,
zero-maintenance, invisible-to-the-user, database.  SQLite appears to me (I've
never used it) to fit that requirement well, and it would be nice to have a
well-engineered interface to it from Dolphin.

But...

> The reason I like the idea of using SqlLite as an embedded database
> with Smalltalk is that it would make my code-base ready for use with
> any other SQL-database as well (hopefully via a simple configuration
> switch). For a corporate customer it is often  a requirement that the
> data can be available to other enterprise systems in a seamless fashion,
> meaning Oracle etc.

Not a chance.  Databases are not /that/ interchangeable, and simply swapping a
real DB for SQLite isn't an option (different semantics for one thing,
different API for another).  The problem of making databases interchangeable,
at least minimally, is precisely what ODBC is for, and Dolphin already has a
good wrapper for that.  So why not use that ?  The DB (in most cases) would not
be zero-maintenance, so that administration would become an issue -- but that's
because administering a real database /is/ an issue.

BTW, in case you don't already know, you can use ODBC without setting up an
explicit ODBC "datasource".

    -- chris