I'm about to purchase a VMWare license, since I need to use certain
windows apps from within Linux. But, I'm currently a bit short on
cash, and though I'd like to purchase the latest and greatest Dylan
compiler for windows, I can't.

So, I'm curious. Is Harlequin Dylan 1.2 still available for free? If I
download it, what problems will I experience if I attempt to
distribute compiled binaries with it? I think I remember reading that
it currently does not work on win2k; will I be losing any additional
functionality if I don't purchase FD and instead use Harlequin?

The personal edition is still available for download from the
Harlequin ftp site.

I may be wrong but I don't think the personal edition allowed the
distribution of the compiled binaries for anything but personal use.

Yes, you will be losing additional functionality. You will not have
COM support, socket support, database support and I don't think it
allowed c-ffi usage for anything except the win32 library files that
shipped with the compiler. There are some new DUIM gadgets in FD that
are not in HD and there are some DUIM bugs that appear in practice in
HD that are fixed in FD. Incremental compilation support and macro
expansion is also supported in FD 2.0 but not HD 1.2.

All the above is from memory so I may be wrong about the distribution
conditions, functionality available, etc. What about downloading the
30 day trial of FD and using that instead?

Chris.
--
http://www/double.co.nz/dylan

  Incremental compilation?

Maury

During active development, you can set the compilation mode
to a "looser" mode in which, when you do Project->Build, the
compiler figures out which things have changes and compiles
just those things and any downstream things that might be
affected.  This can greatly improve the compilation time for
Project->Build.

But you get something much more useful when you use "loose"
mode compilation -- you get incremental *interactive* compilation
as well.  This is how it works: compile a project in "loose" mode,
and the do Project->Start.  Play with your project for a while,
then use the Application->Pause to pause it.  You can now go
into the editor, modify a method, and recompile just that one
method.  If you are using Emacs-mode, just type control-shift-C
to do this.  The recompiled method will get compiled and uploaded
into the running application, and the application will run with the
new method.

Provisos:
 - The code generated for loose mode compilation is a little
   slower than tight mode compilation
 - The compiler doesn't do quite as good a job warning you
   about type-related things
 - Recompiling methods or adding new generic functions and
   new methods is the stuff that works best.  Recompiling
   classes works, but none of the old objects get updated to
   conform to the new class.

Even with the above provisos, I believe you will find that being
able to do interactive compilation will increase your productivity
radically.

 Forgive the stupid question: isn't this how all make systems work?

  Ahhh, Link-n-Go, the mysterious vanishing feature.  Cool, I didn't know
the Dylan systems offered this.

  That seems odd - isn't this just a message to the runtime to move some
pointers?  Why is the generated code different?

  For sure, I've been asking for this one in Obj-C for a while now.  Not
trivial to implement, but doable, as Dylan demonstrates.

Maury

'make' systems generally have a compilation granularity of a single
file.  Dylan's unit of compilation, by the definition in the language, is
an entire library.  This allows, e.g., optimizations across an entire
library rather than within a single file in the library.  Thus, the default
compilation mode is a library, that is, all the files in the libary.  In
"loose" mode, the compiler tries to do less work, but also does less
optimization.

In loose mode, the compiler can do fewer optimizations, because
the type system is treated a bit more loosely.

Definitely not trivial.

Here's a feature I really like in Fun-O Dylan.  Build a project, then
open one of the files in the editor.  Click right on the name of a function
of a class, and select something like "Edit Methods" for a function, or
"Edit Superclasses" for a class, and watch what happens.

If I remember/understand correctly, the "compile just enough" operates not
just at the level of file timestamps (like usual make systems) but also at
the level of individual definitions after parsing.  I.e., if you've
changed only a couple of definitions in a file, only those ones (and any
which depend on them) will be processed after parsing.

You could get almost the same effect by storing each definition in a
separate /source record/.  The Dylan language design allows for what we
would think of as "source files" actually just being views into a
database.  FunDev's "composite buffers" produced by commands like "Edit
Methods" give you a taste of how this would work.

I think only FunDev does just now (i.e., not Mindy or Gwydion's d2c --
dunno about the fabled Apple Dylan tech. release).  BTW, I think in 2.0
you don't actually even have to pause the application manually -- the
environment pauses and resumes it for you.

Without going into detail (which I don't fully understand ;-), I think
that in "Production Mode" the compiler can sometimes optimise away the
layer of pointers it needs for interactive recompilation.  This is why
there are more restrictions on what you can do interactively in a
Production-Mode app.

HTH,
Hugh

  Ahh, I suppose it would have to be that way.  I assume it keeps some
meta-information around for this purpose?

  I've seen such dev systems before.  ObjectMaster basically did this,
although it was largely faked out back onto files, which I think is the
"right" solution.

  Neato, another small but simplifying feature.  It's always amazing about
how tiny little changes can have overall huge effects on the development
process, and yet vendors simply don't DO this in their products.

  Ahhh.

Maury

FD Personal Edition is free.

Apple Dylan actually did store all of the code in a database. There
were no source files, just database views.

Apple Dylan had it all. Oh, how I hate them for terminating the
project just when the result was finally in reach.

Andreas

--
"Anyone need a DVD decrypter for Linux?

| cut -b5-36 | perl -e 'while(<>){print pack("H32",$_)}' | gzip -d"
  -- James Brister

  Well I actually bought it at WWDC'96, and I have to say I understand their
reasoning.  I mean when you consider:

1) it didn't run well on PPC - or at all in some cases
2) the UI side was rather outdated, making it hard to use
     for "real" apps
     - and the widgets were MacOS based, with all of their
       silly limitations like 32k of text
3) it was SLOW. For what reason I can't say, but I had
     a fast PPC at the time, and it was a DOG
4) people within Apple ignored it, so it wasn't getting
     the testing it needed

  Let's also remember this was the Amelio days, the company had to shed
weight. In that light, losing Dylan seems like a no-brainer.  Yes, it's sad
what happened by doing this, but those things happen.

Maury

FWIW, one reason Harlqn Dylan/Fun-O Dylan is implemented the
way it is, is that I became convinced of the wrongness of Apple's
approach in the "corporate world".  If you had a large investment
in source code, would you rather (1) use the proprietary source
code database of some non-mainstream company, or (2) use a
widely used, well-debugged, standard system such as CVS?

Also, pure database views often miss out one very important axis,
namely, "the view the author intended you to see".  I used a large
database-backed doc system, and it did not do a good job of
this, and let me tell you that it was a nightmare.

For what its worth, VisualAge uses a source code database approach.  They
provide a hook to use an external version control system, using a Microsoft
API for doing that sort of thing, which is supported by such products as
SourceSafe and ClearCase.  (Unfortunately, CVS doesn't seem to support the
use of this API, which has kept me from going to the effort of trying any
of the VisualAge products myself, even though they look pretty spiffy.)

I assume your speed complaints have to do with the development environment.
Such complaints were well deserved, particularly running on PPC, where the
initial technology release was running emulated.  The second TR, which was
ported to a later PPC-native version of MCL, was considerably better, though
still had a lot of room for improvement.  Recall that the TR was essentially
pre-alpha.  One of the areas where substantial improvement was needed was
in the performance of the development environment.

  I agree completely.  Has anyone here seen ObjectMaster?  It really did try
t make it look like a db but be source files.

Maury