ftp.xmission.com/2014.06.ftp.xmission.com.tar/ftp.xmission.com/pub/lists/fractdev/archive/fractdev.199904

Internet Message Format | 1999-04-30 | 110KB

From: Phil McRevis <[e-mail]>
Subject: (fractdev) xfractint 19.61 pl66 fixes
Date: 28 Apr 1999 14:12:52 -0600

OK, I compiled the 19.61pl66 version of xfractint and found some minor
bugs which I worked around.

I also added support for default visuals that aren't pseudocolor (i.e.
truecolor, directcolor etc.) to xfractint.  One step closer to
rendering in any visual.

Also, I've been looking at xfractint's guts to determine how one could
separate out the O/S & graphics dependencies.  It doesn't look too bad
actually.  More on that later.

Tim, do I send diffs to you?  I tried sending to fractdev, but I guess
it was bounced because the diffs made the message too large.
--
<http://www.xmission.com/~legalize/>    Legalize Adulthood!
    ``Ain't it funny that they all fire the pistol,
      at the wrong end of the race?''--PDBT
          <http://www.eden.com/~thewho>

Thanks for using Fractdev, The Fractint Developer's Discussion List
Post Message:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractdev"


-------------------------------------------------------------------------------

From: "Tim Wegner" <[e-mail]>
Subject: Re: (fractdev) xfractint 19.61 pl66 fixes
Date: 28 Apr 1999 17:16:26 -0600

"Phil" wrote:

> Tim, do I send diffs to you?  I tried sending to fractdev, but I guess
> it was bounced because the diffs made the message too large.

Yes send them to me, but since I administrate the list, I already
have them because your too-large message bounced to me <g!>

I'll look at it right away. Thanks very much. Interest on our end in
Xfractint has increased a lot. Jonathan and I both have Linux.

I'll merge your changes along with some of our own and re-upload
the Xfractint source file.

Tim


Thanks for using Fractdev, The Fractint Developer's Discussion List
Post Message:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractdev"


-------------------------------------------------------------------------------

From: Phil McRevis <[e-mail]>
Subject: Re: (fractdev) xfractint 19.61 pl66 fixes
Date: 28 Apr 1999 16:25:13 -0600


In article <[e-mail]>,
    "Tim Wegner" <[e-mail]>  writes:

> Yes send them to me, but since I administrate the list, I already
> have them because your too-large message bounced to me <g!>

OK, inspect that diff carefully.  I think some stuff that was supplied
in the patch ended up in my diff because of my poor attempt at
branching the source in my VCS.  (I'm trying to maintina a "pristine"
branch of blessed code as the trunk with my changes on a concurrent
branch.  Somehow I've got the two mixed up and things aren't working
right for me yet.)

> I'll look at it right away. Thanks very much. Interest on our end in
> Xfractint has increased a lot. Jonathan and I both have Linux.

If you get my diffs in there and it compiled OK for you, I'd really
like to know how well fractint behaves when the default visual is
truecolor or directcolor.  (Or StaticGray, StaticColor, and GrayScale
for that matter.)

I'm finally digging into the entire fractint source base and getting
up to speed in how the routines interact.  The bad news is that there's
a LOT of code and a fairly good amount of programming crumbs have been
left laying around as each coder does battle with the program!  The
good news is that I'm finally starting to see how everything is linked
together in fractint and I feel much more optimistic about the
flat-model port and a move to a GUI environment.
--
<http://www.xmission.com/~legalize/>    Legalize Adulthood!
    ``Ain't it funny that they all fire the pistol,
      at the wrong end of the race?''--PDBT
[e-mail]    <http://www.eden.com/~thewho>

Thanks for using Fractdev, The Fractint Developer's Discussion List
Post Message:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractdev"


-------------------------------------------------------------------------------

From: Phil McRevis <[e-mail]>
Subject: (fractdev) DOS support via allegro?
Date: 28 Apr 1999 16:45:31 -0600

I know we've talked about this before, but now I'm digging into the
code and looking to get really specific about stuff.  Taking Tim's
suggestion of using the xfractint code base as a start, the question
becomes "how to provide a DOS driver through that code base?".

In the past, we've talked about fancy GUI toolkits (i.e. gimp toolkit)
and so-on.  But what I'm faced with right now is this question: "What's
the smallest code delta that makes the xfractint code compile and work
under a DOS protected-mode extender environment like djgpp?".  In
other words: first get it right, then get it tight.  Assembly is the
tool you use for getting it "tight" after you've gotten it right.
Fractint currently interacts with the keyboard, mouse and display
through 16-bit assembly routines:

    general.asm
    handles keyboard, audio and mouse support
        keypressed(), getakey(),
        buzzer(), delay(), tone(), snd(), nosnd()
    video.asm
    video display support
        setvideomode(), setvideotext(), getcolor(), putcolor()
        out_line(), drawbox(), home(), movecursor(), keycursor()
        putstring(), setattr(), scrollup(), scrolldown()
        putstr(), loaddac(), spindac(), adapter_init, adapter_detect
        setnullvideo
            setfortext(), setforgraphics(), setclear(), findfont()

Allegro, the gaming library for DJGPP, lists the kinds of monitors it
supports.  I'm not up to speed on all the specifics of these monitors
and so-on.  Can someone out there provide guidance to say "yes,
Allegro covers a suficient portion of the existing fractint users, so
you can provide DOS driver support through allegro" or
"no, fractint provides much more extensive video support with its
assembly, so you should port the assembly"

Thanks in advance.

from the readme.txt in the allegro distribution:

   Supports VGA mode 13h, mode-X (twenty three tweaked VGA resolutions plus
   unchained 640x400 Xtended mode), and SVGA modes with 8, 15, 16, 24, and
   32 bit color depths, taking full advantage of VBE 2.0 linear framebuffers
   and the VBE/AF hardware accelerator API if they are available. Additional
   video hardware support is available from the FreeBE/AF project
   (http://www.talula.demon.co.uk/freebe/).

   Drawing functions including putpixel, getpixel, lines, rectangles, flat
   shaded, gouraud shaded, and texture mapped polygons, circles, floodfill,
   bezier splines, patterned fills, masked, run length encoded, and compiled
   sprites, blitting, bitmap scaling and rotation, translucency/lighting,
   and text output with proportional fonts. Supports clipping, and can draw
   directly to the screen or to memory bitmaps of any size.

   Hardware scrolling, mode-X split screens, and palette manipulation.

    [...]

   Plays background MIDI music and up to 64 simultaneous sound effects, and
   can record sample waveforms and MIDI input. Samples can be looped
   (forwards, backwards, or bidirectionally), and the volume, pan, pitch,
   etc, can be adjusted while they are playing. The MIDI player responds to
   note on, note off, main volume, pan, pitch bend, and program change
   messages, using the General MIDI patch set and drum mappings. Currently
   supports Adlib, SB, SB Pro, SB16, AWE32, MPU-401, ESS AudioDrive, Ensoniq
   Soundscape, and software wavetable MIDI.

   Easy access to the mouse, keyboard, joystick, and high resolution timer
   interrupts, including a vertical retrace interrupt simulator.

    [...]

   Math functions including fixed point arithmetic, lookup table trig, and
   3d vector/matrix manipulation.
--
<http://www.xmission.com/~legalize/>    Legalize Adulthood!
    ``Ain't it funny that they all fire the pistol,
      at the wrong end of the race?''--PDBT
          <http://www.eden.com/~thewho>

Thanks for using Fractdev, The Fractint Developer's Discussion List
Post Message:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractdev"


-------------------------------------------------------------------------------

From: Phil McRevis <[e-mail]>
Subject: (fractdev) FCODE
Date: 28 Apr 1999 16:48:56 -0600

Am I correct in assuming all this FCODE business is to exploit the
code segment for string storage to avoid memory-model ceilings?
--
<http://www.xmission.com/~legalize/>    Legalize Adulthood!
    ``Ain't it funny that they all fire the pistol,
      at the wrong end of the race?''--PDBT
          <http://www.eden.com/~thewho>

Thanks for using Fractdev, The Fractint Developer's Discussion List
Post Message:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractdev"


-------------------------------------------------------------------------------

From: "Tim Wegner" <[e-mail]>
Subject: Re: (fractdev) DOS support via allegro?
Date: 28 Apr 1999 22:44:50 -0600

Rich wrote:

> In the past, we've talked about fancy GUI toolkits (i.e. gimp toolkit)
> and so-on.  But what I'm faced with right now is this question: "What's
> the smallest code delta that makes the xfractint code compile and work
> under a DOS protected-mode extender environment like djgpp?".

1. You have to undo any specifically X code and
2. You have to implement video modes and graphics read write.

Also note that the text writing in Xfractint uses curses. However I
believe there are djgpp versions of curses if we want to go that
route.

While #2 is easily done with SVGA lib, it isn't worth the effort. You
have to solve all over again the problems with DOS video modes we
have long since solved.

I suggest the following. In Xfractint's -disk mode, no screen
graphics is done. In this mode Xfractint doesn't do any X stuff and
is probably close to being portable to djgpp. The one warning is
that Xfractint doesn't use Fractint's diskvideo code which has it's
own cache. I don't know if diskvideo should use the DOS code or
the XFractrint code. Apparently the caching isn't needed in Linux.
In DOS it is essential since some of the passes options cause
writing all over the file, and it is horribly slow. That's the reason for
the cache.

Try building a video-less version first.

Tim


Thanks for using Fractdev, The Fractint Developer's Discussion List
Post Message:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractdev"


-------------------------------------------------------------------------------

From: "Tim Wegner" <[e-mail]>
Subject: Re: (fractdev) FCODE
Date: 28 Apr 1999 22:44:50 -0600


> Am I correct in assuming all this FCODE business is to exploit the
> code segment for string storage to avoid memory-model ceilings?

The FCODE typedef allows data to be placed in overlays. This
means that data does not eat into Fractint's limited supply of near
memory, since in the medium memory model the is a total of 64K
of near memory, and data not explicitly declared far is in the near
data segment.

Since the FCODE data is in an overlay, it can't be changed, and
least not for long. Once that overlay is reloaded, the data reverts to
its permananent value. This is ideal for things like menu prompts.

It is the use of tricks like this that has allowed Fractint to survive so
long and well with a really restrictive memory model.

For Xfractint or any other 32 bit memory model purpose, FCODE is
just a normal type. There are versions of it for char, int, etc.

Tim



Thanks for using Fractdev, The Fractint Developer's Discussion List
Post Message:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractdev"


-------------------------------------------------------------------------------

From: "Tim Wegner" <[e-mail]>
Subject: Re: (fractdev) xfractint 19.61 pl66 fixes
Date: 28 Apr 1999 22:44:50 -0600


> OK, inspect that diff carefully.  I think some stuff that was supplied
> in the patch ended up in my diff because of my poor attempt at
> branching the source in my VCS.

I have no way of dealing with the diff you sent except to implement
it by hand (which I could do). It is nearly a context diff, but "nearly"
scores only in horseshoes :-) I need either a true context diff (diff -c
old new > changes.dif) or just sent a zipped version of the
complete changed files. I like emails to be encapsulated in zips;
I'm never sure when my mailer is going to wrap lines and mess
things up.

Tim


Thanks for using Fractdev, The Fractint Developer's Discussion List
Post Message:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractdev"


-------------------------------------------------------------------------------

From: Phil McRevis <[e-mail]>
Subject: Re: (fractdev) DOS support via allegro?
Date: 29 Apr 1999 01:54:21 -0600


In article <[e-mail]>,
    "Tim Wegner" <[e-mail]>  writes:

> 1. You have to undo any specifically X code and
> 2. You have to implement video modes and graphics read write.

These are actually one and the same.  As I say, going through the code
has reduced a job of Everest proportions to one of less than Whitney
proportions.  (Mt. Whitney is the highest point in the continental 48
states, its in California.)

> Also note that the text writing in Xfractint uses curses. However I
> believe there are djgpp versions of curses if we want to go that
> route.

Yeah, personally I consider the curses thing a bug.  It should just
open up a separate X window and do X text in that window, or it should
do X text in the graphic window, similar to XaoS' "ugly interface".
And yes, there are oodles of open source curses implementations.  GNU
has one, in fact (ncurses-4.2).

However, replacing the text interface (which currently calls curses
functions) with a function that does X11 text instead of curses
shouldn't be very hard.  Fractint calls only a handful of curses
functions.  Some of the existing text mode support that could be
handled by curses is #ifdef'd out in the patch 66 snapshot.  You still
need an ability to run "text only" when doing disk video, so you'll
still want the curses support, I believe.  Just that you won't be
putting the main menu up with curses unless you're using disk video or
"curses video" if we implement a XaoS-style text-only mode.  (I don't
see why not.)

In this respect, XaoS and fractint actually have that in common: the
number of functions you must change in order to add a new driver is
not that many.  Reading/writing a pixel, switching to "text" mode and
back, reading the keyboard/mouse, getting an 8x8 font bitmap,
positioning the text cursor and drawing characters with text
attributes.  That's about all you need to do.

I've been studying the XaoS source code since they have dealth with
the same problem.  They did what I was thinking fractint should do:
they built a structure with attributes of the driver (data members)
and function pointers to the driver's functions that implement the
interface (member functions).  Fractint just needs the structure that
groups the related information about a driver together along with a
slight adjustment to its control logic.  At that point, every "#ifdef
XFRACT" that is there for reasons of X11 and not unix-vs-dos will
disappear.  Only one "#ifdef XFRACT" will remain which is wrapped
around the X11 initializer in the list of drivers (which is static
at compile time).

When I looked at the places where "unix" code was substituted for
"dos" code, what I found was that some of the "unix" code was really
just X11 code, not specific to unix.  (You can compile X11 clients for
DOS and Win32, X11 is just a protocol built on TCP/IP, so anything
that can talk TCP/IP can talk X11.)  Other times the XFRACT was
isolating some difference between unix and dos.

Tim, I think we talked earlier about autoconf; I've successfully
switched over one open-source program to autoconf and I think I've got
a handle on it.  We could do xfractint over to autoconf, but I'd
definately need to consult with some other fractint code gurus to
understand how the different #define's interact.  There's no reason
why a good configure script couldn't enable/disable long double
support when a long double is distinct from a double.  This isn't so
much an x86 vs. other CPU argument either, xmission's sparc solaris
reports sizeof(long double) as 16 and sizeof(double) as 8.

However, autoconf is a bit ahead of my current position on things, but
with a little more practice on autoconf for my other projects, that
will carry over to xfractint.  And also I believe that autoconf is
getting improved DOS support to support building code on DOS as well
as unix portably.  The makefile templates now include the ability to
specify an alternate to the usual unix executable, object and library
filename extensions (i.e. use 'exe', 'obj', 'lib' instead of '', '.o',
'.a').

> While #2 is easily done with SVGA lib, it isn't worth the effort. You
> have to solve all over again the problems with DOS video modes we
> have long since solved.

Right, but I have to get something up on the screen.  Yes, I could
start with a "videoless" fractint.  But here's what I'm seeing now
that I look into the code: changing the X-specific code once to
support a "videoless" fractint is epsilon easier than changing the
X-specific code to support a driver harness.  With the driver harness
I'm thinking of, disk "video" is always present regardless of anything
else with the code.

Next is to add a driver instance that encapsulates the existing X11
interface.  This is like a 15 minute job, once the harness is in
place.  Next is what's needed for some minimal DOS display support,
which is nothing harder than a handful of functions now that I'm
seeing it more clearly.

> I suggest the following. In Xfractint's -disk mode, no screen
> graphics is done. In this mode Xfractint doesn't do any X stuff and
> is probably close to being portable to djgpp.

Actually where I'm starting is to get a working harness + X11 driver
instance going on the X side and then take it over to a disk video
only version with djgpp.

> own cache. I don't know if diskvideo should use the DOS code or
> the XFractrint code.

The disk video caching is an O/S issue, not a graphics issue.  There
are a few little things that need to be factored out because of O/S
platform differences, not because of differences in the graphics
environment.  Memory management, timers, date and time manipulation,
file system I/O are some examples, there are probaly some more.  These
also need to be factored out into an "OS" module, with the configure
(manual or otherwise) picking one of them to compile.

> Apparently the caching isn't needed in Linux.

In linux, you have the virtual memory system of the O/S to deal with
it, so you don't need to write it yourself.  You can just mmap() the
file and use it like a char *.

> In DOS it is essential since some of the passes options cause
> writing all over the file, and it is horribly slow. That's the reason for
> the cache.

The code could still be retained.  You'd just be managing the cache in
a flat memory model rather than in a segmented straightjacket.
--
<http://www.xmission.com/~legalize/>    Legalize Adulthood!
    ``Ain't it funny that they all fire the pistol,
      at the wrong end of the race?''--PDBT
[e-mail]    <http://www.eden.com/~thewho>

Thanks for using Fractdev, The Fractint Developer's Discussion List
Post Message:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractdev"


-------------------------------------------------------------------------------

From: Phil McRevis <[e-mail]>
Subject: Re: (fractdev) FCODE
Date: 29 Apr 1999 01:55:29 -0600


Err... I'll take that as a yes. :)
--
<http://www.xmission.com/~legalize/>    Legalize Adulthood!
    ``Ain't it funny that they all fire the pistol,
      at the wrong end of the race?''--PDBT
[e-mail]    <http://www.eden.com/~thewho>

Thanks for using Fractdev, The Fractint Developer's Discussion List
Post Message:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractdev"


-------------------------------------------------------------------------------

From: Phil McRevis <[e-mail]>
Subject: Re: (fractdev) xfractint 19.61 pl66 fixes
Date: 29 Apr 1999 02:00:25 -0600


In article <[e-mail]>,
    "Tim Wegner" <[e-mail]>  writes:

> I have no way of dealing with the diff you sent except to implement
> it by hand (which I could do).

Really?  Did your patch utility give you an error or what?  If you're
using an old version of patch that doesn't ignore leading/trailing
garbage outside of a context diff, you should get a newer version.
GNU patch doesn't suffer from any such deficiencies.

> I need either a true context diff (diff -c
> old new > changes.dif) or just sent a zipped version of the

What problem exactly are you having?  The problem with zipping up
source code is the end-of-line convention gets stored binary in the
file and you end up having to constantly convert back and forth
between unix and DOS line conventions.

We could setup a CVS server here on xmission and people could just
update/checkin/checkout to that directly without you having to process
the diffs manually.  Just a thought.
--
<http://www.xmission.com/~legalize/>    Legalize Adulthood!
    ``Ain't it funny that they all fire the pistol,
      at the wrong end of the race?''--PDBT
[e-mail]    <http://www.eden.com/~thewho>

Thanks for using Fractdev, The Fractint Developer's Discussion List
Post Message:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractdev"


-------------------------------------------------------------------------------

From: Phil McRevis <[e-mail]>
Subject: (fractdev) portability thoughts
Date: 29 Apr 1999 16:41:31 -0600

Lets separate graphic driver (anything to do with mouse/display) issues
from operating system issues.  Here are the operating system issues as
I see them at my current level of understanding of the source:

    file system I/O
    max. filename path len
    path element separator
    directory reading/scanning

The path separator thing becomes painful under unix.  Fractint uses
'/' to separate the parameter name from a parameter file, for
isntance.  It happens to look for a '/', and if it sees one, it
assumes that the argument is ``@parfile/entry'', but if one naively
specified a full-path of a parfile under xfractint, you'd have a '/'
as part of the parfile name and xfractint will become confused.  A
workaround is to always have parfiles specified in this manner in the
current directory.  Either fractint's syntax will have to be adjusted
slightly, or some quoting mechanism must be installed to allow a full
pathname for a unix file to be specified in these instances.

The filename length is rather standard; stdio.h defines FILENAME_MAX.

The directory scanning/reading issue is one of differences between
unices.  Some use readdir that returns a DIRENT, some return a DIR.
Autoconf has all the ability to isolate the differences and provide a
snippet of code that always works.

    memory allocation
    memory "models"
    virtual memory: mmap vs. home-brew file I/O cache

Memory models disappear completely when dealing with a DPMI extender
port.

Fractint has elaborate strategies for coping with limited amounts of
memory for various situations.  Would a flat-model port eliminate the
need for this parsimony?  Do the DPMI's provide virtual memory?  If
so, then I'd suggest ditching the parsimonious behavior in favor of
the VM from the DPMI.  If the flat-model only eliminates near/far/huge
business but still leaves the need for being parsimonious, then the
disk caching logic and so-on should remain.

    time and date / timers

Fractint uses the PC's timer -- I believe it only uses it in a
stopwatch manner, not to control I/O polling.  (Keyboard polling is
controlled by an internal counter which is adjusted by various
computation routines.  When the counter reaches zero, the keyboard is
checked for input.)  Providing an interface to a system stopwatch is
relatively straightforward.  This would be needed even under a Win32
port since fractint's idea of accessing the timer relies on a DOS
model, which accesses the timer directly (or does it use BIOS?).

    signals

There are differences between unices.  Some signal handlers return
void, some return int.  Autoconf can handle this.

    compilation issues / portability / assembler
    autoconf
        probably lots of include files to sort out.
        driver options
        autodiscover drivers?
        libraries: math library, gmp?
        building help compiler to build help file
        building help file with help compiler
        data files: frmfiles, ifsfiles, lfiles, mapfiles, parfiles
        wipe out default .l.o rule;
        .l files here aren't lex files, they're lsys files
        documentation rule: fractint.doc

The stuff under autoconf -- if you're not familiar with autoconf, see
bwlo(*) -- is a list of things that need to be done to use autoconf
for fractint.

    trig constants
        why use homebrew PI, etc.?  use M_PI, M_PI_2, etc. instead

I'm not sure why fractint defines its own value for PI.  Maybe because
when fractint was first compiled, there weren't any good math.h's for
the PC?  At any rate, I think M_PI and friends from math.h should be
preferred unless there is a significant reason not to.  Again, autconf
can detect the absence of a defined M_PI and define one for that case.

    void * != int

Lots of places in the code there are implicit assumptions about
sizeof(int) == sizeof(void *).  This isn't good for portability in
general, and in the L-system code I think it actually causes a crash
in xfractint that shouldn't be there.

    data type support: int, long, long long, float, double, long double

Autoconf can detect the sizes of all these data types and distinguish
which ones embody more precision.  Conditional compilation of long
double support could be added through the code as a function of the
compiler rather than a "DOS/XFRACT" switch as is currently done.

    arbitrary precision arithmetic
    gmp only provides integers, rationals, fixed.  Doesn't provide
    trig functions.  Contribute complex, trig implementations back
    to FSF.

The arbitrary precision arithmetic routines used by fractint aren't
portable to non-x86 platforms.  However, the gmp (GNU multiple
precision) library *is* portable to a large number of platforms -- it
has assembly for the inner loops for a variety of CPUs:  a29k, alpha,
arm, clipper, cray, hppa, i960, m68k, m88k, mips2, mips3, ns32k,
powerpc32, powerpc64, pyr, sh, sparc32, sparc64, vax, x86 (includes
pentium support), z8000, and z8000x.  I think fractint should adopt
gmp, but this will mean a fair bit of work.

gmp provides arbitrary precision integer, rational and floating point
representations.  It does not provide a complex representation
(although making one is straightforward), nor does it provide
trigonometric functions for any of the data types.  Fractint's bignum
implementation provides both of these.  If it were up to me, I'd take
the complex and trig support impemented in fractint, port that onto
the gmp library and contribute it back as GPL'ed source to the gmp
maintainers.  Then I'd move fractint to using gmp completely.

Given the other items on the portability menu, I'd rank this as a
rather low-priority item.  (On the other hand, if you deseperately
want xfractint calculating arbitrary precision M-sets on a cray, you
might prioritize it higher. :-)

(*) ==== About autoconf

There are lots of minor nagging differences between unix
implementations.  This was what vendors did to "add value" during the
pre-POSIX days.  Now people realize that consistency of an interface is
more valuable than any value "added" by deviating in a non-portable
manner.  At any rate, we're now stuck with how to resolve all these
niggling little differences between unix boxes.  Autoconf was invented
to solve this problem as open source software evolved and was ported to
more and more platforms.

Rather than try and identify the feature sets provided by all possible
OS and hardware combinations ahead of time, autoconf builds a
configuration script based on knowledge of the source code's
requirements.  The configure script knows what the source code needs
(or what alternatives the source code implements) and probes the
system at compile time to see if the system provides facilities
sufficient for the compilation of the package.  It identifies
alternatives available in the system and marks them in a configuration
header file.  The header file is included by the source code to select
between alternatives or conditionally compile snippets of code based
on the configuration.

Mechanically, it works like this:

    configure.in is a file you edit that specifies your software's
    feature requirements (include files, typedefs, functions,
    libraries, etc.)

    Makefile.in, config.h.in, etc.
    Remaining *.in files are templates containing autoconf
    variables.  When the source code is configured, the configure
    script will process the template files and expand the autoconf
    macros to the appropriate values for the system.

    autoconf generates a configure script from configure.in, since
    a configure script is a big hairy /bin/sh script that is too
    cumbersome to write by hand.  Configure.in serves as a
    template that is macro expanded through m4 to obtain
    configure.

    configure is run on the target system, identifying available
    features for the software. *.in template files are processed
    and autoconf variables are substituted by their appropriate
    values in the templates.  This step usually creates your
    Makefile and config.h

    now you're ready to run make and install the target.

The end user (the person compiling your source distribution) isn't
required to have "autoconf" installed unless they want to change the
source code's configuration process.  One generally distributes source
after you've run autoconf so that a configure script comes with the
source code.  An end-user obtains the source, runs configure, types
"make" and then "make install" to install the software.  No more
editing of include files and/or Makefiles to configure your package!

There is an additional GNU tool called "automake" that simplifies the
details of writing a makefile compliant with the GNU coding standards.
(This provides standard targets for actions like "install",
"uninstall", conventions for locations of binary files, installed
header files, installed libraries, and so-on.) Automake works in
conjuction with autoconf, but autoconf doesn't require automake.

Thanks for using Fractdev, The Fractint Developer's Discussion List
Post Message:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractdev"


-------------------------------------------------------------------------------

From: Phil McRevis <[e-mail]>
Subject: (fractdev) C++ templates and generic programming and fractint! :)
Date: 29 Apr 1999 17:00:17 -0600

Just an observation... fractint already embodies the concept of
"generic programming with template classes" as closely as C can deal
with it.

Think about it... fractint has different code blocks implementing the
mathematics of long (integer), double, long double, bignum and bigfloat
number representations.  Fractint evolved in C what one would do in
C++ with a template class: provide different implementations of the
same set of operations for different underlying representations.o

As I'm scanning through the fractint source code, I'm looking at
things that go like this alot:

    if (integer math)
    do some setup calculation using an integer representation
    else if (floating point math)
    do some setup calculation using a double representation
#ifndef XFRACT
    else if (extended precision fp math)
    do some setup calculation using a long double representation
#endif
    else if (bignum math)
    do some setup calculation using a bignum representation
    else if (bigfloat math)
    do some setup calculation using a bigfloat representation

Variables also exist in multiple representations like the complex-plane
coordinates identifying the current zoom box.  What fractint is really
doing is using an arbitrary precision datatype that adapts its
computation based on the amount of precision required.  Based on the
zoom box, fractint decides how many decimals of precision it needs and
swaps the representation as needed while zooming if the pixel's inner
loop can handle it.

If at some point fractint evolves into using C++, I think this would be
the strongest argument for such a move.  The template classes of C++
allow for a much cleaner representation of this idea.  It would also be
much less error-prone when making modifications to the code.  Consider
the setup calculation example above.  With a template implementation,
we would have a single expression for the setup calculation.  If this
calculation needed to change, only one expression would need to be
edited and tested.  With the existing method, all the expressions have
to be edited and tested separately.

Adding a new fractal type would imply that the formula would be
implemented for *all* supported representations with a single template
function.  (This is the power of generic programming using templates.)
Each new fractal type would get arbitrary precision arithmetic "for
free".

--
<http://www.xmission.com/~legalize/>    Legalize Adulthood!
    ``Ain't it funny that they all fire the pistol,
      at the wrong end of the race?''--PDBT
          <http://www.eden.com/~thewho>

Thanks for using Fractdev, The Fractint Developer's Discussion List
Post Message:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractdev"


-------------------------------------------------------------------------------

From: "Damien M. Jones" <[e-mail]>
Subject: Re: (fractdev) C++ templates and generic programming and
Date: 29 Apr 1999 18:01:30 -0500

Rich,

 - If at some point fractint evolves into using C++, I think this would
 - be the strongest argument for such a move.  The template classes of
 - C++ allow for a much cleaner representation of this idea.

(laughing) I seem to recall this topic being brought up some time ago. I'm
glad to see it raised again. It's also the model I used for JuliaSaver,
which implements a base class with all the guessing logic and a good chunk
of the setup code, and the individual fractal type classes just override
the actual iteration routines and any other setup routines they need to
modify. (In case there was any question about the efficiency of C++.)

Damien M. Jones   \\
[e-mail]  \\  Fractalus Galleries & Info:
                    \\  http://www.fractalus.com/

Please do not post my e-mail address on a web site or
in a newsgroup.  Thank you.

Thanks for using Fractdev, The Fractint Developer's Discussion List
Post Message:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractdev"


-------------------------------------------------------------------------------

From: Phil McRevis <[e-mail]>
Subject: Re: (fractdev) C++ templates and generic programming and fractint! :)
Date: 29 Apr 1999 17:17:00 -0600


In article <[e-mail]>,
    "Damien M. Jones" <[e-mail]>  writes:
> (laughing) I seem to recall this topic being brought up some time ago.

I must have missed that, or perhaps it appeared on another list.  I
rank contributions to fractdev of higher importance than the other
fractal lists :-).

But its nice to see someone's reading all this stuff I've been sending
out.  Sometimes its nice to hear back an "echo". :-)

> I'm
> glad to see it raised again. It's also the model I used for JuliaSaver,
> which implements a base class with all the guessing logic and a good chunk
> of the setup code, and the individual fractal type classes just override
> the actual iteration routines and any other setup routines they need to
> modify. (In case there was any question about the efficiency of C++.)

Ah, but here you're using the inheritence/OOness of C++ to exploit
reuse.  The generic programming/template model, as embodied by the STL
for example, is really quite a different kind of reuse than that
provided by class hierarchies.  If anyone out there reading this
hasn't read Stroustrop's "C++ Programming Language", 3rd ed., section
on the STL, go out and get it and read it!  After you've read it the
first time and thought about it for a few months, go back and read it
again!

Despite all the different programming languages and circumstances in
which I've exercised my skill, the concepts embodied by the STL really
changed the way I looked at certain programming problems.  STL is
written in C++, but it isn't "object oriented".  There is a minor use
of class inheritance to exhibit some reuse, but this is rare and only
in places where it makes sense for the problem.  STL has some aspects
of "functional" programming languages, especially adaptors, binders,
unary_function, binary_function, and so-on.

The model of the STL is powerful, richly expressive, composable and
adaptable all while being efficient!  Provided of course you have a
decent STL implementation, but the open source SGI implementation is
pretty good at this point if you happen to be stuck with a sucky STL.
You will need a good template-aware C++ compiler or you'll be hosed.

Somewhere buzzing around my brain is the zygotal code of a
template-based library that exploits generic programming techniques to
deal with the explosion of concrete types (bitmap, grayscale,
luminance + alpha, rgb, rgb15, rgb16, rgb24, rgba, abgr, bgr,
rrr....bbb...ggg..., etc., images) in imaging and graphics.
--
<http://www.xmission.com/~legalize/>    Legalize Adulthood!
    ``Ain't it funny that they all fire the pistol,
      at the wrong end of the race?''--PDBT
[e-mail]    <http://www.eden.com/~thewho>

Thanks for using Fractdev, The Fractint Developer's Discussion List
Post Message:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractdev"


-------------------------------------------------------------------------------

From: Humberto Rossetti Baptista <[e-mail]>
Subject: Porting Fractint (was Re: (fractdev) DOS support via allegro?)
Date: 29 Apr 1999 21:16:20 -0300 (EST)


    Hi All,

    Good to the the list moving :-)

    "Phil" I've browsed in to the XaoS code (alnd I wrote the author for
more info but haven't got an answer yet). It uses a nice approach to isolate
OS-specifica prats from the main program, what makes porting easy if the C style
isn't plataform specific or makes assumptions on sizeof things etc.

    I have managed to compile hc (and it works) and fractint (it does not
work yet) qith DJGPP and I was writing a small quick intro to those that want to
experiment with DJGPP. I'll post it to the list as it is fairly small.

    If we can use a similar approach: an API to handel OS-specific stuff I
guess the rest of the problem would be clean the code from plataform assumtions
and we could have Fractint running in several platforms (like XaoS for
instance).

    []'s

    Humberto R. Baptista
    [e-mail]

Insite - Solucoes Internet                         http://www.insite.com.br

-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GB/C/CA/CM/CS/CC/ED/FA/H/IT/L/M/MU/P/S d?>dpu s:- a->!@ C++++$ USL+++$ P+++@
L+++@ !E W++@ N++(+)@ o+>++++$ K? w>---$ O-@$ M--@ V-- PS@ PE@ Y+>+++$ PGP+@
t+++ 5+@ X+ R>+++$ tv@ b+>++++$ DI++$ D++>++++$ G e+++>++++ h(---)>*$ r+++
y+++*
------END GEEK CODE BLOCK------



Thanks for using Fractdev, The Fractint Developer's Discussion List
Post Message:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractdev"


-------------------------------------------------------------------------------

From: Humberto Rossetti Baptista <[e-mail]>
Subject: (fractdev) Preliminar DJGPP howto :-))
Date: 29 Apr 1999 21:18:52 -0300 (EST)

HOWTO work with GCC in DOS - for the Fractint Devel Team

1. Getting the Tools

    Go to DJGPP (Delorie's GCC port to DOS)

    http://www.delorie.com/djgpp/

    And select the /Zip Picker/ there choose your preferred SimTel
mirror and pick (at least) the options:

    -Build and run programs with DJGPP
    -<your operating system>
    -<documentation if you do not use emacs/rhide>
    -C
    -RHide <recommended> or Emacs <for those used to it>
    -<gdb if not using RHide>
    -Allegro Toolkit
    -GRX

    And download the files.

2. Install

    From the result of /Zip Picker/:
"
You need to update your C:\AUTOEXEC.BAT to include the following lines:

set PATH=C:\DJGPP\BIN;%PATH%
set DJGPP=C:\DJGPP\DJGPP.ENV

Note that the PATH statement should follow any other PATH statements, or you may
edit an existing PATH
statement.

You'll need to restart your computer for these changes to take effect.
"

3. Build and test Allegro & GRX

    Go to the allegro directory:

    c:
        cd \DJGPP\ALLEGRO

    and make all files:

    make

    This should produce all binaries using your newlyn installed
DJGPP and all the examples too, do a CD EXAMPLES and experiment with all
the examples: ex*.exe Some of them will give good implementations ideas
besides showing what allegro can do.

    []'s

    HB


Thanks for using Fractdev, The Fractint Developer's Discussion List
Post Message:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractdev"


-------------------------------------------------------------------------------

From: Phil McRevis <[e-mail]>
Subject: Re: Porting Fractint (was Re: (fractdev) DOS support via allegro?)
Date: 29 Apr 1999 18:19:38 -0600


Humberto, if you're also working on DJGPP issues, that would be great
to coordinate.  My primary development platform is Borland C++ tools
on the PC.  I have downloaded djgpp but haven't installed it from the
zips yet.

In article <[e-mail]>,
    Humberto Rossetti Baptista <[e-mail]>  writes:
> If we can use a similar approach: an API to handel OS-specific stuff I
> guess the rest of the problem would be clean the code from plataform
> assumtions
> and we could have Fractint running in several platforms (like XaoS for
> instance).

That's the idea exactly.  I've outlined what I see (so far) as the OS
specific issues in another message.
--
<http://www.xmission.com/~legalize/>    Legalize Adulthood!
    ``Ain't it funny that they all fire the pistol,
      at the wrong end of the race?''--PDBT
[e-mail]    <http://www.eden.com/~thewho>

Thanks for using Fractdev, The Fractint Developer's Discussion List
Post Message:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractdev"


-------------------------------------------------------------------------------

From: Humberto Rossetti Baptista <[e-mail]>
Subject: Re: (fractdev) portability thoughts
Date: 29 Apr 1999 21:29:55 -0300 (EST)

On Thu, 29 Apr 1999, Phil McRevis wrote:

>     memory allocation
>     memory "models"
>     virtual memory: mmap vs. home-brew file I/O cache
>
> Memory models disappear completely when dealing with a DPMI extender
> port.

    Yep.

> Fractint has elaborate strategies for coping with limited amounts of
> memory for various situations.  Would a flat-model port eliminate the
> need for this parsimony?  Do the DPMI's provide virtual memory?  If
> so, then I'd suggest ditching the parsimonious behavior in favor of
> the VM from the DPMI.  If the flat-model only eliminates near/far/huge
> business but still leaves the need for being parsimonious, then the
> disk caching logic and so-on should remain.

    The "extender" used to put a app in flat mode (32 bit) in DOS and the
DPMI server should handle ALL memory stuff. Other platforms do this nicely
(linux for instance) so we shoud invest as little as possible in this. As the
DPMI + extender do this for uss let's not mess more with overlays, memory
models and disk caching strats.

>     signals
>
> There are differences between unices.  Some signal handlers return
> void, some return int.  Autoconf can handle this.

    As of now fractint does not need to handle them except in specific
platforms (unix) so we could leave them to be dealt with later.

>     compilation issues / portability / assembler

    I was converned w/ the assembly part of fractint, but is easy to avoid
it completly as the Xfractint code already does. As tim pointed out this is the
way we should go: Make Xfractint more portable, maybe running in DOS and Linux
and then clean things up.

>     autoconf

    I've never dealt w/ autoconf in the developpers role, but I  am seing a
lot of stuff here that isn't essential to put things up and running in a
portable manner.

> The arbitrary precision arithmetic routines used by fractint aren't
> portable to non-x86 platforms.  However, the gmp (GNU multiple

    Why not? I havent checked this myself but if I recall right it has a
nice C version of everything that is MP related. Tim?

> Given the other items on the portability menu, I'd rank this as a
> rather low-priority item.  (On the other hand, if you deseperately
> want xfractint calculating arbitrary precision M-sets on a cray, you
> might prioritize it higher. :-)

    Yesssss. And also I think gmp is C++ isnt' it?

    Humberto R. Baptista
    [e-mail]

Insite - Solucoes Internet                         http://www.insite.com.br

-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GB/C/CA/CM/CS/CC/ED/FA/H/IT/L/M/MU/P/S d?>dpu s:- a->!@ C++++$ USL+++$ P+++@
L+++@ !E W++@ N++(+)@ o+>++++$ K? w>---$ O-@$ M--@ V-- PS@ PE@ Y+>+++$ PGP+@
t+++ 5+@ X+ R>+++$ tv@ b+>++++$ DI++$ D++>++++$ G e+++>++++ h(---)>*$ r+++
y+++*
------END GEEK CODE BLOCK------



Thanks for using Fractdev, The Fractint Developer's Discussion List
Post Message:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractdev"


-------------------------------------------------------------------------------

From: Humberto Rossetti Baptista <[e-mail]>
Subject: (fractdev) Porting fractint strategies (32bit flat mem. model etc.)
Date: 29 Apr 1999 21:37:20 -0300 (EST)


    List,

    I wish to help a little with some simple suggestions to all that are
thinking/working with the portability issue:

    a) let's release a "last" 16 bit versino ASAP (Tim?) and feature freeze
it (just correct bugs).

    b) Let's concentrate in put up a version running in DJGPP/DOS (or
gcc/Linux, wichever has the larger number of developpers willing to help) with
the LEAST modiffications needed. I think this should be done in the api manner
XaoS does as "Phil" pointed, but without adding to much fuzz to the process and
then
    c) Hunt down all others platform-centric issues and remove historic code
(that wont'be used any more) together with:

    d) work on the low level drivers to several platforms (using the API) to
spread the Fractint development further more.

    The b) item seems like a bottleneck point to me, that's why i'm
insisting in the simplicity approach :-)

    After it is done we can work in paralell, cleaning code, porting, and
(of COURSE) coding new stuff for Fractint :->>>

    []'s

    Humberto R. Baptista
    [e-mail]

Insite - Solucoes Internet                         http://www.insite.com.br

-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GB/C/CA/CM/CS/CC/ED/FA/H/IT/L/M/MU/P/S d?>dpu s:- a->!@ C++++$ USL+++$ P+++@
L+++@ !E W++@ N++(+)@ o+>++++$ K? w>---$ O-@$ M--@ V-- PS@ PE@ Y+>+++$ PGP+@
t+++ 5+@ X+ R>+++$ tv@ b+>++++$ DI++$ D++>++++$ G e+++>++++ h(---)>*$ r+++
y+++*
------END GEEK CODE BLOCK------



Thanks for using Fractdev, The Fractint Developer's Discussion List
Post Message:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractdev"


-------------------------------------------------------------------------------

From: Humberto Rossetti Baptista <[e-mail]>
Subject: Re: Porting Fractint (was Re: (fractdev) DOS support via allegro?)
Date: 29 Apr 1999 21:46:19 -0300 (EST)

On Thu, 29 Apr 1999, Phil McRevis wrote:

> Humberto, if you're also working on DJGPP issues, that would be great
> to coordinate.  My primary development platform is Borland C++ tools
> on the PC.  I have downloaded djgpp but haven't installed it from the
> zips yet.

    Frankly I've been using Borland tools anlo and just recently downloaded
the djgpp (and Allegro and rhide a nice IDE for DJGPP, very similar to
borland's) and it is GREAT. Works very well.

    See if my draft of DJGPP howto helps! :-))))) (it's already posted).

> That's the idea exactly.  I've outlined what I see (so far) as the OS
> specific issues in another message.

    Speaking of "echo" :-)

    Right I've read it and I think I've being doing it wrong in not sharing
the experiences with the list, so all of you jus cope w/ me while I compensate
for that :-)

    XaoS approach to the platform-api is to put all variables and function
adresess specifict to that platform in a big struct and go for it. I am thinking
if we should do the same or if there would be any gain to slpit the api in
several areas (for instance graphics, sound, mice/keyboard, disk related etc.)
What do you think??

    []'s

    Humberto R. Baptista
    [e-mail]

Insite - Solucoes Internet                         http://www.insite.com.br

-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GB/C/CA/CM/CS/CC/ED/FA/H/IT/L/M/MU/P/S d?>dpu s:- a->!@ C++++$ USL+++$ P+++@
L+++@ !E W++@ N++(+)@ o+>++++$ K? w>---$ O-@$ M--@ V-- PS@ PE@ Y+>+++$ PGP+@
t+++ 5+@ X+ R>+++$ tv@ b+>++++$ DI++$ D++>++++$ G e+++>++++ h(---)>*$ r+++
y+++*
------END GEEK CODE BLOCK------



Thanks for using Fractdev, The Fractint Developer's Discussion List
Post Message:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractdev"


-------------------------------------------------------------------------------

From: Phil McRevis <[e-mail]>
Subject: Re: (fractdev) portability thoughts
Date: 29 Apr 1999 18:50:31 -0600


In article <[e-mail]>,
    Humberto Rossetti Baptista <[e-mail]>  writes:
>     I've never dealt w/ autoconf in the developpers role, but I  am seing a
> lot of stuff here that isn't essential to put things up and running in a
> portable manner.

What things are you seeing that aren't essential?  All the things I
listed are portability issues.

> > The arbitrary precision arithmetic routines used by fractint aren't
> > portable to non-x86 platforms.  However, the gmp (GNU multiple
>
>     Why not? I havent checked this myself but if I recall right it has a
> nice C version of everything that is MP related. Tim?

Some low-level stuff is written in assembly, see bigflta.asm and
bignuma.asm.  Poking around a little more, it looks like bigfltc.c
implements C versions of the assembly routines.  As I say, I consider
switching to gmp to be a very low-priority item, i.e. one of
optimization not one of correctness.  You want to do it eventually to
get fast MP support on more than just x86 DOS platforms.  (Even x86
linux can't take advantage of the x86 assembly for fractint's MP math
since the assembly is 16-bit!)

>     Yesssss. And also I think gmp is C++ isnt' it?

gmp is ANSI C.
--
<http://www.xmission.com/~legalize/>    Legalize Adulthood!
    ``Ain't it funny that they all fire the pistol,
      at the wrong end of the race?''--PDBT
[e-mail]    <http://www.eden.com/~thewho>

Thanks for using Fractdev, The Fractint Developer's Discussion List
Post Message:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractdev"


-------------------------------------------------------------------------------

From: Phil McRevis <[e-mail]>
Subject: Re: (fractdev) Porting fractint strategies (32bit flat mem. model etc.)
Date: 29 Apr 1999 18:53:51 -0600


Humberto, what you propose is exactly inline with my thinking.  I'm
already signed up for the "driver harness" a la XaoS and adjusting the
existing xfract code to use the harness.  Then I'll remove all memory
model stuff.  That should serve as the starting point for whoever adds
display driver support back in for the DOS DJGPP side of things.
There are places where parallel developers can work without bumping
into each other (different display driver implementations), but its
probably best to have just one person overhaul the central control
logic and associated glue to the driver.  We've kinda talked about
this forever so I just got sick of talking about it and I'm doing it.
:-)
--
<http://www.xmission.com/~legalize/>    Legalize Adulthood!
    ``Ain't it funny that they all fire the pistol,
      at the wrong end of the race?''--PDBT
[e-mail]    <http://www.eden.com/~thewho>

Thanks for using Fractdev, The Fractint Developer's Discussion List
Post Message:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractdev"


-------------------------------------------------------------------------------

From: Phil McRevis <[e-mail]>
Subject: Re: Porting Fractint (was Re: (fractdev) DOS support via allegro?)
Date: 29 Apr 1999 19:03:41 -0600


In article <[e-mail]>,
    Humberto Rossetti Baptista <[e-mail]>  writes:
>     XaoS approach to the platform-api is to put all variables and function
> adresess specifict to that platform in a big struct and go for it. I am think
ing
> if we should do the same or if there would be any gain to slpit the api in
> several areas (for instance graphics, sound, mice/keyboard, disk related etc.
)
> What do you think??

I'm thinking that the driver keeps private any data that it needs only
to get its job done.  Under X11, that means things like pixel lookup
tables, dynamically allocated X resources (windows, pixmaps,
colormaps, GCs, etc.) and so-on.  These are visible only to the
driver.

Then there is a collection of stuff that is supplied to fractint for
handling the video driver support.  This is basically an array of
structures that define video mode characteristics.  Currently this
collection of settings is couched in very PC-centric terms, right down
to the interrupt call arguments!

That basic idea would remain the same with display drivers, however.
What changes is the control logic that initializes the table at
program startup-time (and possibly updating it during runtime).  Right
now the table is created from fractint.cfg as a fixed list.  Some of
the data currently stored in the table (like PC interrupt arguments)
becomes private data of the driver.  The rest remains relevant as a
result from a driver when its queried from fractint.
--
<http://www.xmission.com/~legalize/>    Legalize Adulthood!
    ``Ain't it funny that they all fire the pistol,
      at the wrong end of the race?''--PDBT
[e-mail]    <http://www.eden.com/~thewho>

Thanks for using Fractdev, The Fractint Developer's Discussion List
Post Message:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractdev"


-------------------------------------------------------------------------------

From: Humberto Rossetti Baptista <[e-mail]>
Subject: Re: (fractdev) Porting fractint strategies (32bit flat mem. model
Date: 29 Apr 1999 22:06:12 -0300 (EST)

On Thu, 29 Apr 1999, Phil McRevis wrote:

> Humberto, what you propose is exactly inline with my thinking.  I'm

    excelent.

> probably best to have just one person overhaul the central control
> logic and associated glue to the driver.  We've kinda talked about

    This is exatcly why i called this a bottleneck.

> this forever so I just got sick of talking about it and I'm doing it.
> :-)

    Cool. I do not have a lot of time spare right now, but if you need any
help just say so. PS: got the DJGPP howto?

    []'s

    Humberto R. Baptista
    [e-mail]

Insite - Solucoes Internet                         http://www.insite.com.br

-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GB/C/CA/CM/CS/CC/ED/FA/H/IT/L/M/MU/P/S d?>dpu s:- a->!@ C++++$ USL+++$ P+++@
L+++@ !E W++@ N++(+)@ o+>++++$ K? w>---$ O-@$ M--@ V-- PS@ PE@ Y+>+++$ PGP+@
t+++ 5+@ X+ R>+++$ tv@ b+>++++$ DI++$ D++>++++$ G e+++>++++ h(---)>*$ r+++
y+++*
------END GEEK CODE BLOCK------



Thanks for using Fractdev, The Fractint Developer's Discussion List
Post Message:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractdev"


-------------------------------------------------------------------------------

From: Humberto Rossetti Baptista <[e-mail]>
Subject: Re: (fractdev) portability thoughts
Date: 29 Apr 1999 22:18:19 -0300 (EST)

On Thu, 29 Apr 1999, Phil McRevis wrote:

> What things are you seeing that aren't essential?  All the things I
> listed are portability issues.

    Yes, but you have already pointed that some are less priority than
others :-)

    Also some things are not done properly but are done like the handling of
\ and / (i guess it is in port.h as several other stuff like data types are also
defined).

    []'s

    Humberto R. Baptista
    [e-mail]

Insite - Solucoes Internet                         http://www.insite.com.br

-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GB/C/CA/CM/CS/CC/ED/FA/H/IT/L/M/MU/P/S d?>dpu s:- a->!@ C++++$ USL+++$ P+++@
L+++@ !E W++@ N++(+)@ o+>++++$ K? w>---$ O-@$ M--@ V-- PS@ PE@ Y+>+++$ PGP+@
t+++ 5+@ X+ R>+++$ tv@ b+>++++$ DI++$ D++>++++$ G e+++>++++ h(---)>*$ r+++
y+++*
------END GEEK CODE BLOCK------



Thanks for using Fractdev, The Fractint Developer's Discussion List
Post Message:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractdev"


-------------------------------------------------------------------------------

From: "Damien M. Jones" <[e-mail]>
Subject: Re: (fractdev) C++ templates and generic programming and
Date: 29 Apr 1999 20:27:53 -0500

Rich,

 - Ah, but here you're using the inheritence/OOness of C++ to exploit
 - reuse.  The generic programming/template model, as embodied by the STL
 - for example, is really quite a different kind of reuse than that
 - provided by class hierarchies.

My mistake, I thought you were referring to inheritance with different
terminology, and not the STL. You're right, that IS different. And yes, I
was using inheritance to exploit reuse.

Damien M. Jones   \\
[e-mail]  \\  Fractalus Galleries & Info:
                    \\  http://www.fractalus.com/

Please do not post my e-mail address on a web site or
in a newsgroup.  Thank you.

Thanks for using Fractdev, The Fractint Developer's Discussion List
Post Message:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractdev"


-------------------------------------------------------------------------------

From: Phil McRevis <[e-mail]>
Subject: (fractdev) driver characteristics
Date: 29 Apr 1999 19:55:01 -0600

Since Humberto brought up some specifics of drivers, I'll say a little
about how I'm implementing the driver harness.  Naturally we'll be
able to change the harness later.  The point is not to design some
end-all be-all graphics API.  The idea is just to get things going
incrementally.  Feel free to kibitz, if its a big issue, something can
be done now, but please consider this more of a 'status report' for
your information on what I'm doing, more than a design review where
I'm proposing the idea. :-)

Existing video mode glue logic in fractint is currently implemented in
select_video_mode().  It walks through the table stored in memory and
creates the scrollable display of available video modes.  When you
select a mode from the list (or by some other means like video=), then
the proper parameters are snatched out of the table and sent to the
assembly routine setvideomode (video.asm), which issues the
appropriate commands to the video card.

With the harness, select_video_mode() instead walks a list of drivers
and queries each driver about the modes supported by the driver.  It
then displays a scrolling list created from the driver responses.
When the user selects an item on the list, select_video_mode() calls
through the driver harness to set the video mode.

This means that when we get to the point of having all (or several) or
the drivers I list below, under win98 you could have the choice of
the same video modes supported by multiple drivers.  The video display
list might look like this:

key...driver...name.................xdot.ydot.color.comment.............
SF1   win32    GDI Surface          1024x768  5:6:5
SF2   directx  Windowed             1024x768  5:6:5
SF3   directx  Full Screen          1024x768  8     256 colors
SF4   directx  Full Screen          1024x768  5:6:5 16-bit RGB
SF5   directx  Full Screen          1024x768  5:5:5 15-bit RGB
SF6   opengl   Full Screen          1024x768  8     256 color indexed
SF7   opengl   Full Screen          1024x768  8:8:8 24-bit RGB

(This is an ASCII graphic mockup; not a screen dump.)

Xdot and ydot take on a subtle meaning in a windowed environment, but
window systemless drivers still need to be able to report device
dimensions.

The video parameter ('video=<key>') currently only specifies a function
key which is bound to a video mode.  It doesn't force a particular
video mode, just selects one from the key list.  If you want to write a
script or parameter file that uses a particular video mode, you have to
ensure the proper key assignment is setup first.  To set the function
key assignment you have to get into the fractint.cfg file.  Icky!

With the harness, the video parameter is updated to specify both the
driver and the desires video mode provided by the driver.  So you'd
say something like "video=directx/1024x768/8".  A new method for
binding the keys to video modes will have to be provided, as the old
method depended on fractint.cfg which is now specific to the fractint
driver.

But what about the stuff the fractint.cfg file did?  That's used by the
"fractint" driver (see blow) as input to decide what video modes it
lists when queried.

Some really random ideas:

should image and model formats (3D raytracing files, etc) be
    supported as compile-time modules like drivers?

should drivers be allowed to invoke the engine distinct from
    fractint's gui?  Is the engine a client of the driver, or is the
    driver a client of the engine?  Fractint is currently architected
    towards the latter.  Reversing the assumption would be difficult.

should 3D drivers subsume 2D functionality?
    Is there any reason you'd want to use ogl for 3D, but x11 for 2D?
    If not, then "x11" and "opengl" drivers will provide everything
    you need.  Select an "x11' driver video mode for 2D stuff and an
    "opengl" driver video mode for 3D stuff.  Fractint doesn't (yet)
    mix 2D and 3D rendering together.

Drivers
-------
display drivers I think should be done, in no particular order:
    "curses"
    possibly uses curses, but only has character I/O.
    Displays "pixels" using characters as similar to XaoS.
    Enumerate text vide modes (DOS) or screen sizes (curses?) to
        form "video modes" table.
    Works in DOS (pd curses) and unix (native curses).

    "fractint"
    port existing fractint assembly code to 32-bit flat model.
    Included is the native video and mouse support coded in
    assembly.

    "allegro"
    Uses Allegro library under DJGPP to enumerate video formats
    and provide video/mouse/sound support.

    "disk"
    Video modes contain list of standard image sizes and "custom",
    letting you set the size.

    "win32"
    text menus are displayed graphically somehow.
    graphics display native to GDI presented as video mode.
    Emulate other modes?  Only if someone desperate for it --
    directx would be the preferred solution!

    "directx"
    text menus are displayed using a regular win32 window on GDI
        surface, or as graphic text on graphics screen (driver
        option).
    graphics display is done through full-screen with DirectDraw.
    DirectDrawDevices enumerated by DDraw are the video modes.

    "direct3d"
    Same as directx, but uses D3D for 3D effects.

    "x11"
    Text menus are displayed graphically using X11.
    Available visuals on the screen are the video modes.

    "opengl"
    Same as X11, only OGL-capable visuals are video modes.
    Uses OGL for all pixel I/O and 3D.

like XaoS, more that one driver can be available, but only one driver
can be active at once in any given graphic window.

Thanks for using Fractdev, The Fractint Developer's Discussion List
Post Message:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractdev"


-------------------------------------------------------------------------------

From: Humberto Rossetti Baptista <[e-mail]>
Subject: Re: (fractdev) driver characteristics
Date: 29 Apr 1999 23:44:47 -0300 (EST)

On Thu, 29 Apr 1999, Phil McRevis wrote:

[... description of select_video_mode]

    Just to clear things for me: are you taking for a staring point the
fractint or the xfractint code (the 2 are the same, but w/ different #defines )

[... harnessing the video mode]
> With the harness, the video parameter is updated to specify both the
> driver and the desires video mode provided by the driver.  So you'd
> say something like "video=directx/1024x768/8".  A new method for
> binding the keys to video modes will have to be provided, as the old
> method depended on fractint.cfg which is now specific to the fractint
> driver.

    That is very nice. Seems ok, but in one given platform there will be all
the drivers to all the platforms or just the ones concerning that one platform?

> should image and model formats (3D raytracing files, etc) be
>     supported as compile-time modules like drivers?

    That is also a nice idea.
[...]

> Drivers
> -------
> display drivers I think should be done, in no particular order:
>     "curses"
>     possibly uses curses, but only has character I/O.
>     Displays "pixels" using characters as similar to XaoS.

    I guess this is aalib ?? It is not curses but i guess if could be seen
as though it is.

    Wouldn't it be interesting to abandon the text mode completly and user
the graphic mode for messages also? This could lead with work and time to an
uniform fractint gui look all across different platforms.

    []'s

    Humberto R. Baptista
    [e-mail]

Insite - Solucoes Internet                         http://www.insite.com.br

-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GB/C/CA/CM/CS/CC/ED/FA/H/IT/L/M/MU/P/S d?>dpu s:- a->!@ C++++$ USL+++$ P+++@
L+++@ !E W++@ N++(+)@ o+>++++$ K? w>---$ O-@$ M--@ V-- PS@ PE@ Y+>+++$ PGP+@
t+++ 5+@ X+ R>+++$ tv@ b+>++++$ DI++$ D++>++++$ G e+++>++++ h(---)>*$ r+++
y+++*
------END GEEK CODE BLOCK------



Thanks for using Fractdev, The Fractint Developer's Discussion List
Post Message:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractdev"


-------------------------------------------------------------------------------

From: Phil McRevis <[e-mail]>
Subject: Re: (fractdev) driver characteristics
Date: 29 Apr 1999 21:15:56 -0600


In article <[e-mail]>,
    Humberto Rossetti Baptista <[e-mail]>  writes:
>     Just to clear things for me: are you taking for a staring point the
> fractint or the xfractint code (the 2 are the same, but w/ different #defines
 )

The answer to your question is yes and no. :-)

I'm using xfractint 19.61 pl66 code.  The differences between xfractint
19.61 pl66 and fractint 19.61 pl66 are the inclusion of assembly files
on the fractint side, with corresponding .c files on the xfractint
side.  For instance, here's the source in my xfractint directory
(datafiles removed for clarity):

    3d.c          end1.c        hc*           lsys.h        rotate.c
                  evolve.c      hc.c          lsysf.c       slideshw.c
                  externs.h     hcmplx.c      makefile      soi.c
    ant.c         f16.c         help.c        memory.c      soi1.c
    big.h         file_id.diz   help.src      miscfrac.c    stereo.c
    bigflt.c      fpu087.c      help2.src     miscovl.c     targa.c
    biginit.c     frachelp.mak  help3.src     miscres.c     targa.h
    biginit.h     fracsuba.c    help4.src     mpmath.h      targa_lc.h
    bignum.c      fracsubr.c    help5.src     mpmath_c.c    testpt.c
    bignumc.c     fractalb.c    helpcom.h     parser.c      tgaview.c
    bigport.h     fractalp.c    helpdefs.h    parserfp.c    tplus.c
    calcfrac.c    fractals.c    intro.c       plot3d.c      tplus.h
    calcmand.c    fractint.c    jb.c          port.h        tplus_a.c
    calmanfp.c    fractint.h    jiim.c        port.new      tru.c
    cmdfiles.c    fractint.ifs  line3d.c      printer.c     unix.c
    cmplx.h       fractype.h    loadfdos.c    prompts1.c    unix.h
    decoder.c     framain2.c    loadfile.c    prompts2.c    unixscr.c
    diskvid.c     frasetup.c    loadmap.c     prototyp.h    video.c
    diskvidu.c                  lorenz.c      read.me       yourvid.c
    editpal.c     general.c     lsys.c        realdos.c     zoom.c
    encoder.c     gifview.c

And here's fractint 19.61 source:

    3d.c          calmanfp.asm  fractint.h    loadfile.c    port.h
                  cmdfiles.c    fractint.mak  loadmap.c     printer.c
    ant.c         cmplx.h       fractype.h    lorenz.c      prompts1.c
    bcauto.bat    decoder.c     framain2.c    lsys.c        prompts2.c
    bcfract.bat   diskvid.c     frasetup.c    lsys.h        prototyp.h
    bcfract.cfg   editpal.c     general.asm   lsysa.asm     realdos.c
    bcfract.mak   encoder.c     gifview.c     lsysaf.asm    rotate.c
    bcfract2.cfg  externs.h     hc.c          lsysf.c       slideshw.c
    bclinkf.bat   f16.c         hcmplx.c      lyapunov.asm  stereo.c
    bcmakall.bat  fmath.h       help.c        makefrac.bat  targa.c
    bigflt.c      fpu087.asm    help.src      miscfrac.c    targa.h
    bigflt.h      fpu387.asm    help2.src     miscovl.c     targa_lc.h
    bigflta.asm   fr8514a.asm   help3.src     miscres.c     testpt.c
    bigfltc.c     frachelp.mak  help4.src     mpmath.h      tgaview.c
    biginit.c     fracsuba.asm  help5.src     mpmath_a.asm  tplus.c
    biginit.h     fracsubr.c    helpcom.h     mpmath_c.c    tplus.dat
    bignum.c      fractalb.c    hgcfra.asm    newton.asm    tplus.h
    bignum.h      fractalp.c    intro.c       parser.c      tplus_a.asm
    bignuma.asm   fractals.c    jb.c          parsera.asm   video.asm
    bignumc.c     fractint.c    jiim.c        parserfp.c    yourvid.c
    calcfrac.c    fractint.cfg  line3d.c      plot3d.c      zoom.c
    calcmand.asm  fractint.def  loadfdos.c

I think the makefiles are also different; otherwise they share
all the same .h and .c source with #ifdef XFRACT in the few places
where it matters.

The driver harness goes in some of the places where XFRACT is
currently used.  Then fractint and xfractint will be using the same
source with even fewer #ifdef XFRACT's sprinkled around the code.

>That is very nice. Seems ok, but in one given platform there will be all
> the drivers to all the platforms or just the ones concerning that one
>platform?

Its identical to what XaoS does.  (XaoS uses autoconf)  The configure
script probes the compilation system to determine what features are
available.  configure determines what drivers will be available at
runtime.  Alternatively, you can set #defines in your build process to
attempt to compile support for a particular driver.  Of course,
someone will have to implement the driver before it can be compiled
:-).

> > Drivers
> > -------
> > display drivers I think should be done, in no particular order:
> >     "curses"
> >     possibly uses curses, but only has character I/O.
> >     Displays "pixels" using characters as similar to XaoS.
>
>     I guess this is aalib ?? It is not curses but i guess if could be seen
> as though it is.

Umm... oh yeah, I think I looked at aalib, which is a full-blown 2D
graphics package that renders to text.  Kinda cool, but no its not
necessarily to use something that fancy for a curses driver.  Fractint
really doesn't need anything more fancy than getpixel and putpixel for
graphics it turns out.

Amazingly modular... I'm surprised more people didn't just assume they
could bcopy() indices straight onto the display.

>     Wouldn't it be interesting to abandon the text mode completly and user
> the graphic mode for messages also? This could lead with work and time to an
> uniform fractint gui look all across different platforms.

What I suggested for the window system drivers is that they do exactly
that.  Curses may or may not be available on the system (system
dependency).  But a window system driver has the capacity to draw text
into its window directly.  It doesn't need curses to draw text.  In
fake, it gets more complicated (to me anyway) to have curses doing
text and X11 doing graphics.
--
<http://www.xmission.com/~legalize/>    Legalize Adulthood!
    ``Ain't it funny that they all fire the pistol,
      at the wrong end of the race?''--PDBT
[e-mail]    <http://www.eden.com/~thewho>

Thanks for using Fractdev, The Fractint Developer's Discussion List
Post Message:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractdev"


-------------------------------------------------------------------------------

From: Phil McRevis <[e-mail]>
Subject: (fractdev) the credits screen
Date: 29 Apr 1999 21:21:21 -0600

Tim, the credits screen just smacked me in the face like a conceptual
ton of bricks.  The stone soup tradition of fractint is more than just
a concept of open source software, its the cumulative non-violent
cooperative effort of all those *people* in the credits screen.

I know on some of the other fractal lists there's been heated debate
about fractint's open source tradition vs. the new kids on the block.
:-).  But I couldn't think of another program that starts up with a
credits screen, the way a good action movie blasts the credits up
quick in the beginning so that you can be on the edge of your seat for
the entire ride.  Sure, lots of programs have about boxes and thanks
lists and so on.  But of all the open source software I use, I
couldn't think of one that embodies the stone soup tradition of mutual
cooperation more than fractint.
--
<http://www.xmission.com/~legalize/>    Legalize Adulthood!
    ``Ain't it funny that they all fire the pistol,
      at the wrong end of the race?''--PDBT
          <http://www.eden.com/~thewho>

Thanks for using Fractdev, The Fractint Developer's Discussion List
Post Message:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractdev"


-------------------------------------------------------------------------------

From: Phil McRevis <[e-mail]>
Subject: (fractdev) 'xfractint makedoc' segfaults around page 220
Date: 29 Apr 1999 23:32:15 -0600

Has anyone else seen this?  It chunks away seemingly normally for about
222 pages in Appendix H when it crashes with a seg fault.

Program received signal SIGSEGV, Segmentation fault.
0x98294 in printerc (info=0xeffff0d8, c=12, n=0) at help.c:1113
(gdb) where
#0  0x98294 in printerc (info=0xeffff0d8, c=12, n=0) at help.c:1113
#1  0x98acc in print_doc_output (cmd=1, pd=0xeffff008, info=0xeffff0d8)
    at help.c:1254
#2  0x944c4 in process_document (get_info=0x9848c <print_doc_get_info>,
    output=0x98808 <print_doc_output>, info=0xeffff0d8) at helpcom.h:459
#3  0x99100 in print_document (
    outfname=0x756d6d61 <Address 0x756d6d61 out of bounds>,
    msg_func=0x7279206f <_end+42538935>, save_extraseg=1713391218)
    at help.c:1403
#4  0x52498 in cmdarg (curarg=Cannot access memory at address 0x230044.
) at cmdfiles.c:1158
Cannot access memory at address 0x230038.
(gdb) l help.c 1110
Junk at end of line specification.
(gdb) l "help.c":1110
No source file named "help.c".
(gdb) l help.c:1110
1105          {
1106          if (c==' ')
1107             ++info->spaces;
1108
1109          else if (c=='\n' || c=='\f')
1110             {
1111             info->start_of_line = 1;
1112             info->spaces = 0;   /* strip spaces before a new-line */
1113             putc(c, info->file);
1114             }
#1  0x98acc in print_doc_output (cmd=1, pd=0xeffff008, info=0xeffff0d8)
    at help.c:1254
(gdb) l
1249             return ( keep_going );
1250             }
1251
1252          case PD_FOOTING:
1253             info->margin = 0;
1254             printerc(info, '\f', 1);
1255             info->margin = PAGE_INDENT;
1256             return (1);
1257
1258          case PD_PRINT:
#2  0x944c4 in process_document (get_info=0x9848c <print_doc_get_info>,
    output=0x98808 <print_doc_output>, info=0xeffff0d8) at helpcom.h:459
(gdb) l
454          if ( !output(PD_START_SECTION, &pd, info) )
455             return (0);
456
457          if ( pd.new_page && pd.lnum != 0 )
458             {
459             if ( !output(PD_FOOTING, &pd, info) )
460                return (0);
461             ++pd.pnum;
462             pd.lnum = 0;
463             if ( !output(PD_HEADING, &pd, info) )
#3  0x99100 in print_document (
    outfname=0x756d6d61 <Address 0x756d6d61 out of bounds>,
    msg_func=0x7279206f <_end+42538935>, save_extraseg=1713391218)
    at help.c:1403
(gdb) l
1398
1399       info.margin = PAGE_INDENT;
1400       info.start_of_line = 1;
1401       info.spaces = 0;
1402
1403       success = process_document((PD_FUNC)print_doc_get_info,
1404                                  (PD_FUNC)print_doc_output,   &info);
1405       fclose(info.file);
1406
1407       if ( save_extraseg )
#4  0x52498 in cmdarg (curarg=Cannot access memory at address 0x230044.
) at cmdfiles.c:1158
(gdb) l
1153             escape_exit = yesnoval[0];
1154             return 3;
1155             }
1156
1157          if (far_strcmp(variable,s_makedoc) == 0) {
1158             print_document(*value ? value : "fractint.doc", makedoc_msg_func, 0);
1159    #ifndef WINFRACT
1160             goodbye();
1161    #endif
1162             }
(gdb) q
The program is running.  Quit anyway (and kill it)? (y or n) y

Debugger finished
--
<http://www.xmission.com/~legalize/>    Legalize Adulthood!
    ``Ain't it funny that they all fire the pistol,
      at the wrong end of the race?''--PDBT
          <http://www.eden.com/~thewho>

Thanks for using Fractdev, The Fractint Developer's Discussion List
Post Message:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractdev"


-------------------------------------------------------------------------------

From: [e-mail] (Kragen Sitaker)
Subject: Re: (fractdev) everything
Date: 30 Apr 1999 12:35:54 -0400 (EDT)

Fill wrote:
> The path separator thing becomes painful under unix.  Fractint uses
> '/' to separate the parameter name from a parameter file, for
> isntance.  It happens to look for a '/', and if it sees one, it
> assumes that the argument is ``@parfile/entry'', but if one naively
> specified a full-path of a parfile under xfractint, you'd have a '/'
> as part of the parfile name and xfractint will become confused.  A
> workaround is to always have parfiles specified in this manner in the
> current directory.  Either fractint's syntax will have to be adjusted
> slightly, or some quoting mechanism must be installed to allow a full
> pathname for a unix file to be specified in these instances.

Everything can work with no user-visible changes.

In the general case @a/b/c/d/e, a/b/c/d must be either be a file or a
directory -- it can't be both, right?  (No "parfile paths", right?  I
haven't used fractint in a while.)  If it's a file, @a/b/c/d/e means
the entry e in the file a/b/c/d; if it's a directory, @a/b/c/d/e means
the file a/b/c/d/e.

>         void * != int
>
> Lots of places in the code there are implicit assumptions about
> sizeof(int) == sizeof(void *).  This isn't good for portability in
> general, and in the L-system code I think it actually causes a crash
> in xfractint that shouldn't be there.

It's true that it's not good for portability in general, but it's true
afaik on all 32-bit Intel platforms, the Sparc, and 32-bit MIPS
machines.  I don't know if it's true on various Alpha platforms,
various UltraSparc platforms, various 64-bit MIPS platforms (OK I mean
IRIX) etc.  I know it's not true on some memory models of 16-bit Intel
chips and the AS/400.

What I wanted to know is, what platform are you running xfractint on
that this crash occurs?

> I think fractint should adopt gmp, but this will mean a fair bit of work.

I think everyone doing arbitrary-precision math should adopt GMP.
However, you should be aware that adopting GMP will mean that Fractint
has to be released under the GNU General Public License, which allows
anyone to sell copies of Fractint.  IMHO this would be a good thing
(e.g. it could be included with Red Hat Linux and Debian GNU/Linux).
Some other people may not think so, and Fractint's current license
forbids this.

Also, who holds the copyright on Fractint?  Remember that copyright
inheres in a copyrightable work as soon as it is created, and cannot be
transferred implicitly.  (You can give an implicit license, but you
can't implicitly give away your copyright rights.)  For the Stone Soup
Group to legitimately hold copyright to all of Fractint, everyone who
has contributed a chunk of code big enough to be copyrightable needs to
have signed legal papers to transfer their copyright ownership to the
Stone Soup Group.  That probably doesn't mean everybody in the credits,
but certainly a significant number of them.

The reason I ask is that only the holder of a copyright can license the
copyrighted work.  If Jonathan decides he wants to license the Fractint
code he wrote under the GPL, that's fine, but if Tim doesn't like it,
Jonathan can't license Tim's code under the GPL.  If it turns out that
50 different people own the copyrights to various parts of Fractint,
you'll need all 50 of their signatures or the signatures of their heirs
(or you'll need to discard the code they wrote) in order to release
Fractint under the GPL.

Linux uses the same technique to make it impossible to release Linux
under a non-GPL license.  I understand environmental activists have
used a similar technique -- selling individual square feet of land to
many different people -- to slow down condemnation proceedings.

These same problems do not attend releasing a fractint including
autoconf scripts for building or built with gcc and GNU libc, because
of licensing or linking differences.  They *may* attend releasing a
fractint linked against the DJGPP libraries or Allegro -- are these
licensed under the GPL?

Summary: using gmp (and possibly djgpp or allegro) may be extremely
difficult for legal reasons.  I am not a lawyer, and this is not legal
advice.  Hit the books and make your own decisions.

> If it were up to me, I'd take
> the complex and trig support impemented in fractint, port that onto
> the gmp library and contribute it back as GPL'ed source to the gmp
> maintainers.

Bruno Haible's CLN (see clisp.cons.org) is a GPLed library built on gmp
that provides (among other things) complex support, and I think trig
too.  It's written in C++ though.

> Just an observation... fractint already embodies the concept of
> "generic programming with template classes" as closely as C can deal
> with it.

Generally this is done in C with #define macros or m4.  (The latter can
produce code that works better with most debuggers.)

> Ah, but here you're using the inheritence/OOness of C++ to exploit
> reuse.  The generic programming/template model, as embodied by the STL
> for example, is really quite a different kind of reuse than that
> provided by class hierarchies.

Mechanically it's implemented differently.  Conceptually it's the same
thing.  More advanced OO environments (like Self, notably) dynamically
pick and mix specialization (generating multiple copies of the same
code to deal with different data types) and dynamic dispatch
(generating a single copy of the code which calls different code
depending on the types of the data it's handling) to dynamically
balance speed and code size/compile time.

> Despite all the different programming languages and circumstances in
> which I've exercised my skill, the concepts embodied by the STL really
> changed the way I looked at certain programming problems.

Me too.  (Although I can't really talk much about exercising my skill.  ;)

>  STL is written in C++, but it isn't "object oriented".  There is a
> minor use of class inheritance to exhibit some reuse, but this is rare
> and only in places where it makes sense for the problem.  STL has some
> aspects of "functional" programming languages, especially adaptors,
> binders, unary_function, binary_function, and so-on.

Well, like I said, it's a different way to implement the same thing.
(STL implements several things that would be extremely slow if they
were implemented with dynamic dispatch instead of specialization, and
since "int" is not a class in C++, also very inconvenient to use.)

It's not very functional; the whole programming model is deeply based
on mutation.

Looks like, by "binder", STL means something like "a curried function".

Humberto Rossetti Baptista wrote:
>         Yesssss. And also I think gmp is C++ isnt' it?

No, C.

Fill wrote:
>     "allegro"
>         Uses Allegro library under DJGPP to enumerate video formats
>         and provide video/mouse/sound support.

Could also work under X.

> But of all the open source software I use, I
> couldn't think of one that embodies the stone soup tradition of mutual
> cooperation more than fractint.

I think I agree.  But be careful -- Fractint is not now, and never has
been, Open Source (tm) software, because people are not free to sell
it.

--
<[e-mail]>       Kragen Sitaker     <http://www.pobox.com/~kragen/>
TurboLinux is outselling NT in Japan's retail software market 10 to 1,
so I hear.
-- http://www.performancecomputing.com/opinions/unixriot/981218.shtml


Thanks for using Fractdev, The Fractint Developer's Discussion List
Post Message:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractdev"


-------------------------------------------------------------------------------

From: Phil McRevis <[e-mail]>
Subject: Re: (fractdev) everything
Date: 30 Apr 1999 12:55:28 -0600


In article <[e-mail]>,
    [e-mail] (Kragen Sitaker)  writes:

> Everything can work with no user-visible changes.

Yeah, but the code has to change, which was my real point.

> >         void * != int
> >
> > Lots of places in the code there are implicit assumptions about
> > sizeof(int) == sizeof(void *).  This isn't good for portability in
> > general, and in the L-system code I think it actually causes a crash
> > in xfractint that shouldn't be there.
>
> It's true that it's not good for portability in general, but it's true
> afaik on all 32-bit Intel platforms, the Sparc, and 32-bit MIPS
> machines.

Nope, its not true on sparc, or MIPS.  Why?  Because a pointer has
alignment restrictions that constrain its valid value and an integer
does not.  In other words, the following is most certainly going to
cause a crash on a sparc or mips platform:

    int i = 3;
    void *p = (void *) i;
    *p = 1;

On the x86, you can address 16/32/etc. sized quantities at any memory
location.  The CPU does the necessary word twiddling to get the
operand of the appropriate type.  Misaligning data on an x86 affects
performance but doesn't crash.  On a non-x86 it almost certainly
causes a crash or exception.

> What I wanted to know is, what platform are you running xfractint on
> that this crash occurs?

I found a crash in L-systems on a sparc running solaris 2.7.  When I
looked at it in the debugger, a quick 6-minute analysis figured the
problem to be related to pointer casting due to the attempt to
conserve memory in the medium model.  If the memory had just simply
been malloc'ed instead, then it works fine.

> [long worry about the GPL and its implications]

This sounds like the typical misunderstanding of what the GPL really
says.  I'd get a clarification from the FSF on that before I worried
about it, but I personally believe it to be a non-issue.

> Bruno Haible's CLN (see clisp.cons.org) is a GPLed library built on gmp
> that provides (among other things) complex support, and I think trig
> too.  It's written in C++ though.

That URL just talks about a common lisp implementation, no mention of
CLN or anything for C++.

> Mechanically it's implemented differently.  Conceptually it's the same
> thing.

I disagree.  Generic programming is conceptually and syntactically
different from OO programming in C++.  The only thing they have in
common is a desire for reuse.

> It's not very functional; the whole programming model is deeply based
> on mutation.

Adaptors, binders, etc., are all very much in the style of functional
programming.  Its where they get their inspiration from.

> Looks like, by "binder", STL means something like "a curried function".

Yes.

> [Allegro]
>
> Could also work under X.

Yeah, but using allegro for fractint's X interface wouldn't be the
right way to do it, I think.  Seriously folks, fracint's existing UI
needs are not elaborate!  That's because fractint built everything
itself on top of the basic functionality of being able to read/write
single pixels into a memory-mapped VGA display.  The whole idea of
modern UI needs is foreign to fractint.

> I think I agree.  But be careful -- Fractint is not now, and never has
> been, Open Source (tm) software, because people are not free to sell
> it.

We already went through this once before.  If someone is going to sue
my ass becuase I consider fractint to be "open source", I wish they'd
just get off their lazy butts and do it.  Otherwise, if you care to
have a debate about the meaning of the GPL or the legal phrase "open
source", then it'll be a one-sided debate since I consider engaging in
such a debate to be a waste of time that only distracts me from the
real issues facing fractint right now.
--
<http://www.xmission.com/~legalize/>    Legalize Adulthood!
    ``Ain't it funny that they all fire the pistol,
      at the wrong end of the race?''--PDBT
[e-mail]    <http://www.eden.com/~thewho>

Thanks for using Fractdev, The Fractint Developer's Discussion List
Post Message:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractdev"


-------------------------------------------------------------------------------

From: [e-mail] (Kragen Sitaker)
Subject: Re: (fractdev) everything
Date: 30 Apr 1999 16:51:16 -0400 (EDT)

Legalize Adulthood writes:
> > Everything can work with no user-visible changes.
>
> Yeah, but the code has to change, which was my real point.

Of course you are correct.

> > > Lots of places in the code there are implicit assumptions about
> > > sizeof(int) == sizeof(void *).  This isn't good for portability in
> > > general, and in the L-system code I think it actually causes a crash
> > > in xfractint that shouldn't be there.
> >
> > It's true that it's not good for portability in general, but it's true
> > afaik on all 32-bit Intel platforms, the Sparc, and 32-bit MIPS
> > machines.
>
> Nope, its not true on sparc, or MIPS. [because of alignment]

When I said "it's true", I just meant the sizes were the same, not the
alignment constraints, because that's what you said in the text I
responded to.  Of course you are correct that arbitrary integers can't
be used as pointers on most machines.  Often, however, this is a
dangerous practice even on Intel hardware, because arbitrary integers
are not likely to point at anything useful.  ;)

> > [long worry about the GPL and its implications]
>
> This sounds like the typical misunderstanding of what the GPL really
> says.

It's not.

> I'd get a clarification from the FSF on that before I worried
> about it, but I personally believe it to be a non-issue.

I've sent them an email, saying,
    Someone's proposing replacing Fractint's arbitrary-precision
    math routines with routines from the GMP library.  My
    understanding is that this would require Fractint to be
    licensed under the GPL, which would lift the restriction
    against commercial sale of Fractint in Fractint's current
    license.  Is this correct?  Is it possible to link Fractint
    with GMP and continue to distribute Fractint executables under
    the current Fractint license?

I will forward the response to this list.

> > Bruno Haible's CLN (see clisp.cons.org) is a GPLed library built on gmp
> > that provides (among other things) complex support, and I think trig
> > too.  It's written in C++ though.
>
> That URL just talks about a common lisp implementation, no mention of
> CLN or anything for C++.

The Common Lisp implementation in question is implemented in C++ and
uses CLN for its numeric processing.  I can't seem to find links to CLN
from the home page, but CLN's home page is at
http://clisp.cons.org/~haible/packages-cln.html.

> > Mechanically it's implemented differently.  Conceptually it's the same
> > thing.
>
> I disagree.  Generic programming is conceptually and syntactically
> different from OO programming in C++.  The only thing they have in
> common is a desire for reuse.

Unarguably, C++ syntax for template-based polymorphism is different
from C++ syntax for dynamic-method-dispatch-based polymorphism.  And
underneath the hood, they are unarguably different things.  But they
are two ways of doing the same thing: specifying what you want to do
to an object and letting the object decide what the most appropriate
way of doing that thing is, and allowing different objects to do the
same thing differently without any change in the calling code.

> We already went through this once before.  If someone is going to sue
> my ass becuase I consider fractint to be "open source",

I thought I forwarded you the response I got from OSI.  They said they
couldn't do anything about posts on private mailing lists.  So noone
will sue your ass.  :)

> I consider engaging in such a debate to be a waste of time that only
> distracts me from the real issues facing fractint right now.

Bravo, concentrate on the real issues, then.  The work you're doing is
certainly important.  Have fun.

--
<[e-mail]>       Kragen Sitaker     <http://www.pobox.com/~kragen/>
TurboLinux is outselling NT in Japan's retail software market 10 to 1,
so I hear.
-- http://www.performancecomputing.com/opinions/unixriot/981218.shtml


Thanks for using Fractdev, The Fractint Developer's Discussion List
Post Message:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractdev"


-------------------------------------------------------------------------------

From: [e-mail] (Kragen Sitaker)
Subject: (fractdev) GPL clarification
Date: 30 Apr 1999 18:01:55 -0400 (EDT)

The response to my email to [e-mail]:

If GMP is under the GPL, then Fractint would have to be
GPLed to use GMP code.  Under the GPL you can have
commercial sale, although license fees are illegal of
course.

--
                                   Brian Youmans
                                   FSF Office Staff

--
<[e-mail]>       Kragen Sitaker     <http://www.pobox.com/~kragen/>
TurboLinux is outselling NT in Japan's retail software market 10 to 1,
so I hear.
-- http://www.performancecomputing.com/opinions/unixriot/981218.shtml


Thanks for using Fractdev, The Fractint Developer's Discussion List
Post Message:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractdev"


-------------------------------------------------------------------------------

From: "Tim Wegner" <[e-mail]>
Subject: Re: (fractdev) portability thoughts
Date: 30 Apr 1999 17:15:46 -0600

Phil said:

> Some low-level stuff is written in assembly, see bigflta.asm and
> bignuma.asm.  Poking around a little more, it looks like bigfltc.c
> implements C versions of the assembly routines.

Fractint's arbitrary precision is already portable, as far as we know.
I will say that it is optimized for little endian and probably is less
efficient on big endian.

The main reason for not going to another arbitrary precision library
is that Wes has implemented a slew of transcendental functions.

Tim


Thanks for using Fractdev, The Fractint Developer's Discussion List
Post Message:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractdev"


-------------------------------------------------------------------------------

From: Humberto Rossetti Baptista <[e-mail]>
Subject: Re: (fractdev) GPL clarification
Date: 30 Apr 1999 22:25:55 -0300 (EST)

On Fri, 30 Apr 1999, Kragen Sitaker wrote:
[Brian quote:]
> If GMP is under the GPL, then Fractint would have to be
> GPLed to use GMP code.  Under the GPL you can have
> commercial sale, although license fees are illegal of
> course.

    Brian is being lazy in his response since gmp is a "recommended"free
program on the fsf site.

    It is not on GPL (what would indeed require fractint to become GPL), but
it is LGPL (http://www.fsf.org/manual/gmp/html_chapter/gmp_1.html#SEC1 and the
definition of LGPL is in http://www.fsf.org/copyleft/lgpl.html).

    The LGPL is the Library Gnu Policy License and it provide mechanisms to
link agains a free library a non-GPL program, such as Fractint.

    In the spirit of freedom I agree with "Phil" when he says that fractint
is free software, bu I guess our licence is more radical than GNU :-))))

    In short: we an link agains GMP w/ no problems.

    []'s

    Humberto R. Baptista
    [e-mail]

Insite - Solucoes Internet                         http://www.insite.com.br

-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GB/C/CA/CM/CS/CC/ED/FA/H/IT/L/M/MU/P/S d?>dpu s:- a->!@ C++++$ USL+++$ P+++@
L+++@ !E W++@ N++(+)@ o+>++++$ K? w>---$ O-@$ M--@ V-- PS@ PE@ Y+>+++$ PGP+@
t+++ 5+@ X+ R>+++$ tv@ b+>++++$ DI++$ D++>++++$ G e+++>++++ h(---)>*$ r+++
y+++*
------END GEEK CODE BLOCK------



Thanks for using Fractdev, The Fractint Developer's Discussion List
Post Message:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractdev"


-------------------------------------------------------------------------------

From: Phil McRevis <[e-mail]>
Subject: Re: (fractdev) everything
Date: 30 Apr 1999 20:16:56 -0600


In article <[e-mail]>,
    [e-mail] (Kragen Sitaker)  writes:

> > I'd get a clarification from the FSF on that before I worried
> > about it, but I personally believe it to be a non-issue.
>
> I've sent them an email, saying [...]

Actually you needn't even bother.  All you have to do is read the
license in the gmp-2.0.2 distribution.  It says quite clearly that
linking against the library doesn't mean your program is bound by the
GPL.  Like I said, it sounds like you have a misconception about the
GPL covering gmp-2.0.2.

> [generic programming and oo programming]
> are two ways of doing the same thing: specifying what you want to do
> to an object and letting the object decide what the most appropriate
> way of doing that thing is, and allowing different objects to do the
> same thing differently without any change in the calling code.

It sounds like we don't have a common accepted definition of "generic
programming".  At any rate, its not relevant to anything
fractdev-related.

> > We already went through this once before.  If someone is going to sue
> > my ass becuase I consider fractint to be "open source",
>
> I thought I forwarded you the response I got from OSI. [...]

Yes, so why did you bring it up again?  There's no point in rehashing
this stuff every time I happen to type the phrase "open source".

You know, the kind of feedback I wanted was about specific things in
the fractint code that I should be paying attention to now, so as not
to avoid some problem that occurs to another mind familiar with the
source.  I'm afraid your response just wasn't helpful, only time
consuming.
--
<http://www.xmission.com/~legalize/>    Legalize Adulthood!
    ``Ain't it funny that they all fire the pistol,
      at the wrong end of the race?''--PDBT
[e-mail]    <http://www.eden.com/~thewho>

Thanks for using Fractdev, The Fractint Developer's Discussion List
Post Message:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractdev"


-------------------------------------------------------------------------------

From: Phil McRevis <[e-mail]>
Subject: Re: (fractdev) GPL clarification
Date: 30 Apr 1999 20:19:00 -0600

Like I said, please read the COPYING file in the gmp-2.0.2
distribution.  It states quite clearly that you can link against the
library without having to adopt the GPL in your code.

Thanks for reporting me to the FSF police.
--
<http://www.xmission.com/~legalize/>    Legalize Adulthood!
    ``Ain't it funny that they all fire the pistol,
      at the wrong end of the race?''--PDBT
[e-mail]    <http://www.eden.com/~thewho>

Thanks for using Fractdev, The Fractint Developer's Discussion List
Post Message:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractdev"


-------------------------------------------------------------------------------

From: Phil McRevis <[e-mail]>
Subject: Re: (fractdev) portability thoughts
Date: 30 Apr 1999 20:24:01 -0600


In article <[e-mail]>,
    "Tim Wegner" <[e-mail]>  writes:

> Fractint's arbitrary precision is already portable, as far as we know.

As I guessed after a little browsing.

> I will say that it is optimized for little endian and probably is less
> efficient on big endian.

And no assembly support is provided for anything other than 16bit x86.
GMP's main advantage is its wide support for assembly on different
CPUs.

> The main reason for not going to another arbitrary precision library
> is that Wes has implemented a slew of transcendental functions.

Yep, which is why my note in my "thoughts" file also contained wording
to the effect that in the true stone soup tradition, fractint's
contribution to gmp could be adding the complex and transcendental
function support back to gmp.  Then fractint would just link against
gmp like any other gmp client.

Naturally the authors of that code would have to agree to this before
their code could be used directly in such an effort.  However, I don't
see the "stone soup tradition" and the FSF's goals to be at
cross-purposes, more like cousins in the same family.  At any rate, I
have no idea why this has become the hot potato issue from all the stuff
I wrote when its like item #682 on the agenda.
--
<http://www.xmission.com/~legalize/>    Legalize Adulthood!
    ``Ain't it funny that they all fire the pistol,
      at the wrong end of the race?''--PDBT
[e-mail]    <http://www.eden.com/~thewho>

Thanks for using Fractdev, The Fractint Developer's Discussion List
Post Message:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractdev"


-------------------------------------------------------------------------------

From: [e-mail] (Kragen Sitaker)
Subject: Re: (fractdev) everything
Date: 30 Apr 1999 22:36:27 -0400 (EDT)

You wrote:
> At any rate, I have no idea why this has become the hot potato issue
> from all the stuff I wrote when its like item #682 on the agenda.

Yeah, it puzzled me a bit, too.  I didn't mean for it to be, and I
certainly didn't mean to waste your time.

I'm not sure why I thought gmp was GPLed -- I think it might have been
several years ago.  I'll let you know (in private so as not to use up
more list bits) when I find out.

--
<[e-mail]>       Kragen Sitaker     <http://www.pobox.com/~kragen/>
TurboLinux is outselling NT in Japan's retail software market 10 to 1,
so I hear.
-- http://www.performancecomputing.com/opinions/unixriot/981218.shtml


Thanks for using Fractdev, The Fractint Developer's Discussion List
Post Message:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractdev"


-------------------------------------------------------------------------------

From: Phil McRevis <[e-mail]>
Subject: Re: (fractdev) everything
Date: 30 Apr 1999 20:39:13 -0600


In article <[e-mail]>,
    [e-mail] (Kragen Sitaker)  writes:
> I'm not sure why I thought gmp was GPLed -- I think it might have been
> several years ago.  I'll let you know (in private so as not to use up
> more list bits) when I find out.

Please don't bother.  I'm not really interested.
--
<http://www.xmission.com/~legalize/>    Legalize Adulthood!
    ``Ain't it funny that they all fire the pistol,
      at the wrong end of the race?''--PDBT
[e-mail]    <http://www.eden.com/~thewho>

Thanks for using Fractdev, The Fractint Developer's Discussion List
Post Message:   [e-mail]
Get Commands:   [e-mail] "help"
Administrator:  [e-mail]
Unsubscribe:    [e-mail] "unsubscribe fractdev"