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

Internet Message Format | 1999-11-29 | 28KB

From: tim gilman <[e-mail]>
Subject: Re: (fractdev) DPMI for DOS
Date: 01 Nov 1999 01:32:16 -0800

> [e-mail] (Tim Wegner) wrote:
> (on 10/12/99 at 5:10 PM)
> Thierry wrote:
>
> >     You can try http://www.opensource.org/ or ...
> >     ... ask Richard Stallman !
>
> Yeah right, I'm sure I know what license he advocates :-)

Is there some sort of list or outline describing what a new
license must necessarily preserve or emphasize?

> >     Oh ? It's a dream or I have really read:
> >         "an independant 32bits fractal engine" ?
>
> It's still a dream until we do it!
>
> Tim

Where can I get the latest code sync for the fp only base?
I'd like to start running this dream down..  I'll be using a
sparc10 to run and test XFract, but I'll also be building
some prototypes and developing on a Mac.

Thanks,

=- Tim
[e-mail]



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) DPMI for DOS
Date: 01 Nov 1999 20:02:31 -0600

Tim G. asked:

> Is there some sort of list or outline describing what a new
> license must necessarily preserve or emphasize?

There are some good web sites summarizing the different
licenses. I'll try to locate one and we can discuss it here.

I've read the opinion that it is very bad to create a special license,
because the waters get very muddy when you start incorporating
other open source code. So I'd like to go with a GPL license, a
BSD license, or one of the two or three main variations.

> Where can I get the latest code sync for the fp only base?
> I'd like to start running this dream down..  I'll be using a
> sparc10 to run and test XFract, but I'll also be building
> some prototypes and developing on a Mac.

I'll make this available to you as soon as I can before the weekend -
 from Friday through Sunday this week I have a lot of other
activities. Jonathan reported to me his visit with you and I am very
interested in working with you. He and I are going to start work on
a 32 bit version, probably in djgpp for starters. The important point
is to have a large core of portable 32 bit code that all 32 bit
implementations share. That's why I'd like to work with you on this.
Once we get going on any sort of 32 bit environment with
something that works, eveolution can be fast, and we can all stay
synched to the core source.

I am interested in using GTK+ for the GUI. This *may* work on
Windows also. But even if your Mac version needs separate GUI
code, there's a lot of value in sharing as much generic non-GUI
code as possible and staying together.

Tim W.


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 gilman <[e-mail]>
Subject: Re: (fractdev) DPMI for DOS
Date: 01 Nov 1999 23:16:17 -0800

> [e-mail] (Tim Wegner) wrote:
> (on 11/1/99 at 8:02 PM)
> I'll make this available to you as soon as I can before the weekend -

No hurry!

> Jonathan reported to me his visit with you and I am very
> interested in working with you. He and I are going to start work on
> a 32 bit version, probably in djgpp for starters. The important point
> is to have a large core of portable 32 bit code that all 32 bit
> implementations share. That's why I'd like to work with you on this.

I'm forcing myself to code in parallel on the Mac and my linux box.
This way I hope to keep the code base portable.  Well, or heavily
dependent on two distinct platforms.  That should force some GUI
separation, right?!   heh.

> Once we get going on any sort of 32 bit environment with
> something that works, eveolution can be fast, and we can all stay
> synched to the core source.
>
> I am interested in using GTK+ for the GUI. This *may* work on
> Windows also. But even if your Mac version needs separate GUI
> code, there's a lot of value in sharing as much generic non-GUI
> code as possible and staying together.
>
> Tim W.

Agreed!  Is there an ongoing list of desirables for this next-gen
engine?  32 bit clean is a must, but I'm curious to know if any
consideration for multiple engine instances, plug-in support for
fractal/platform-specific optimizations, and other Star Trek
technologies has been kicked around.  Granted, there's a big amount of
work to get through before this'll be close to a reality, but my brain
likes to feed on problems well in advance of actual execution.

Enough of me!  Let me know when the fp code base is ready for ftp'n, and
I'll start working on my carpel tunnel syndrome..

=- Tim G.
[e-mail]



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) DPMI for DOS
Date: 02 Nov 1999 10:20:59 -0700


Sounds like you could use the partial work I've done on separating the
GUI code from the engine code.

Should I make a diff and put it up for FTP?

What I did was abstract out the GUI/driver functions and massage the
code to call through those functions.  I haven't worked on it for some
time, as I took a job again and have been working for $$.

However, if someone else is going down that road, you would benefit
quite a bit from what I've already done.
--
<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.thewho.net>

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) DPMI for DOS
Date: 02 Nov 1999 11:10:45 -0700


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

> I've read the opinion that it is very bad to create a special license,
> because the waters get very muddy when you start incorporating
> other open source code. So I'd like to go with a GPL license, a
> BSD license, or one of the two or three main variations.

That sounds like a great idea: unifying the license to all the code
under one "standard" open source license.

Will there be difficulty obtaining permission from authors who have
slapped their own wacky open source license on their contributions?
Will some pieces need to be rewritten because of license issues?
--
<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.thewho.net>

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) DPMI for DOS
Date: 02 Nov 1999 20:13:50 -0600


> Will there be difficulty obtaining permission from authors who have
> slapped their own wacky open source license on their contributions?
> Will some pieces need to be rewritten because of license issues?

In principle there is an issue, but in practise I don't think so. There
are really not that many people who have contributed a lot of code,
and we can reach them, and the contributions of most minor
contributors was for all intents and purposes written by us because
we massaged code extensively in the process of integrating it.

We have had the understanding from contributors for quite a while
now that we could do what we want with the code. And I think we
can deal with 100% of people who have explicit copyrights in the
code. For example, Mark Peterson has his name many places, but
we have it in writing that he renounces his rights.

In any case I expect a massive rewrite that will leave no code
unchanged.

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: (fractdev) licenses
Date: 02 Nov 1999 22:25:19 -0600

Here's a list of popular licenses:

http://www.opensource.org/licenses/



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 gilman <[e-mail]>
Subject: Re: (fractdev) DPMI for DOS
Date: 03 Nov 1999 01:25:01 -0800

> [e-mail] (Phil McRevis) wrote:
> (on 11/2/99 at 10:20 AM)
>
> Sounds like you could use the partial work I've done on separating the
> GUI code from the engine code.
>
> Should I make a diff and put it up for FTP?

Yes please!  If you put up a diff, I'll definitely use it.  I would
*love* to see what you've done..

> What I did was abstract out the GUI/driver functions and massage the
> code to call through those functions.  I haven't worked on it for some
> time, as I took a job again and have been working for $$.
>
> However, if someone else is going down that road, you would benefit
> quite a bit from what I've already done.
><snip>

Yes please!  ;v)  I'm going down this road, and I'm curious to learn
about what you've done...

Yours,
-= Tim G.
[e-mail]




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) DPMI for DOS
Date: 03 Nov 1999 09:26:33 -0700


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

> In any case I expect a massive rewrite that will leave no code
> unchanged.

That is the nature of the diff that I already have ;-).

I will put that up for FTP soon, probably this weekend.
--
<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.thewho.net>

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) DPMI for DOS
Date: 03 Nov 1999 09:39:50 -0700


In article <[e-mail]>,
    tim gilman <[e-mail]>  writes:

> Yes please!  If you put up a diff, I'll definitely use it.  I would
> *love* to see what you've done..

If you peruse the list archives at
<ftp://ftp.xmission.com/pub/lists/fractdev>, you'll see me describing
the approach I have taken.

> Yes please!  ;v)  I'm going down this road, and I'm curious to learn
> about what you've done...

Coming soon... I used the xfractint code base for testing, since I
could get working quicker that way.  I don't have a DOS C compiler
environment that "works out of the box" with the fractint source code.

I spent a *lot* of time poring over a printout of the source code
before I started working on it.  (Do you realize that the fractint
source, when printed double-sided is about 7 inches thick?!?)

What I did was push all the code specific to a particular kind of I/O
into a structure through a function pointer member.  Then you initialize
the structure's function pointers based on what driver you're going to
select.

The resulting code has combined "drivers" for all the kinds of
platforms: DOS, windows, X11, etc.  The intent was that under Win32 at
least you would have the option of using GDI, OpenGL or DirectX back
ends as well.
--
<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.thewho.net>

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) initial stab at implementing drivers in fractint available
Date: 07 Nov 1999 18:19:49 -0700

OK, I've put two files in my FTP area that you'll want to look at;
<ftp://ftp.xmission.com/pub/users/l/legalize/fractals/> contains:

-rw-r--r--   1 legalize   623285 Nov  7 17:58 xfractint-19.61.66-diffs.txt
-rw-r--r--   1 legalize  4208640 Nov  7 17:57 xfractint-experimental.tar

The first is a diff against 19.61 patchlevel 66 sources.  However, I
added files to the distribution and eliminated files from the
distribution, so just in case those files are missing (d_*.c), I've
put all the source in the tar file.

Some notes:

    This limps along in X11 mode, but isn't completely finished.
    In particular, the X11 port should do away with curses completely
    for the text menus and just use native X11 text (and possibly
    dialog boxes) for the menus and parameter screens.  This would
    eliminate the kludgey way you have to run xfractint inside an
    xterm for it to work.  It also eliminates the kludgey function key
    support stuff in xfractint currently.

    The DOS related code hasn't even been compiled; it was just
    migrated there from other files/functions as I noticed it instead
    of deleting it.  Eventually we want "DOS drivers" to handle that
    environment.

    You'll see various things like ##FIXME## or ##AUTOCONF##.  These
    are notes I made to myself while changing things to remind me to
    go back and fix some issue relating to platform portability
    (usually the ##FIXME##s are of this nature) or some issue that is
    related to platform configuration that should be handled by GNU
    autoconf.  (Is autoconf available for Mac and does it make any
    sense there?  You can always manually edit config.h if you don't
    have autoconf, but that is for gurus only I think.)

    I haven't gone through the code and replaced all the wacky DOSisms
    like weird 'common area' memory allocation and stuff like that.
    I've just left the xfractint solution in place, which works.
    You'll want to remove these DOSisms in the 32-bit porting work.

    I haven't removed all the near/far crap.  The header files just
    #define these away for now, so they should just all be removed
    from the code just to make it clear that we don't give a rat's ass
    about this under a flat memory model.  Otherwise, leaving them in
    but #define'd away will just cause confusion for future
    contributors.

    I spent a lot of time thinking about the best migration path for
    the fractint code from where we are now to fancy GUI enabled
    environments and so on.  Please don't dismiss my choices with some
    discussion on this list ;-).

    There is a way to evolve the source base into a position where we
    can do all I/O as events instead of polling like is done now.
    (xfractint fakes out the polling routine by checking for events
    inside the polling routine, but this is kludgey.)  The big
    implications of leaving behind polling are:

    Code that calls 'keypressed()' needs to have its control flow
    reworked.  Surprisingly this isn't a large number of places,
    but its sprinkled around more than in a few places.  The
    easiest way to find them all is to #ifdef out keypressed() and
    look for all the places where the compile breaks ;-).

    For the DOS DPMI environment, an interrupt handling routine
    needs to be written to post events to an internal event queue
    based on user input (keyboard, mouse, etc.).  I can't believe
    that someone hasn't already done this under a GPL like
    license.  We should be able to steal code for this, not have
    to write it.  If it does have to be written, I'm not the one
    for that job as this is too far afield from my core expertise
    (DOS interrupt handlers).

    All the changes in this tar file/diff are 'infrastructure'
    changes.  They are preparing the groundwork for the Mac port and
    a 32-bit port and a DirectX port and an improved X11 port and
    so-on.

I really hope this is useful to Tim and the Mac port folks.  (Sorry, I
forgot your name!)  Please lets try and reuse what I've done so far
since its like 70% finished and unfortunately my free time kinda
evaporated since I took a full-time job which has prevented me from
finishing it before you folks took up the torch.  In particular,
please ask me questions if there is something I've done that doesn't
make sense or you're confused about my design choices.  My goals for
this effort were to make the minimal amount of changes to xfractint in
order to implement an abstract driver base, from which other ports
to other window systems (I had X11 and Win32/GDI Win32/DirectX in mind
specifically) could be done much more easily.  I also wanted to
improve the quality of the X11 port along the way, using that as my
testbed 'driver', since that's my most readily available compilation
environment and the graphics environment with which I'm most
familiar.

The guts of the driver-specific code is all in the d_*.[hc] files.
--
<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.thewho.net>

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) initial stab at implementing drivers in fractint available
Date: 07 Nov 1999 22:10:31 -0600

Rich wrote:

> OK, I've put two files in my FTP area that you'll want to look at;
> <ftp://ftp.xmission.com/pub/users/l/legalize/fractals/> contains:
>

OK, I'll have a look, and try to figure out how to merge the v20 no-
integer source.

I'll get that source up soon. This weekend was a marathon of
meetings.

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 gilman <[e-mail]>
Subject: Re: (fractdev) initial stab at implementing drivers in fractint available
Date: 09 Nov 1999 18:54:25 -0800

> [e-mail] (Phil McRevis) wrote:
> (on 11/7/99 at 6:19 PM)
> OK, I've put two files in my FTP area that you'll want to look at;
> <ftp://ftp.xmission.com/pub/users/l/legalize/fractals/> contains:
>
> xfractint-19.61.66-diffs.txt
> xfractint-experimental.tar

I'll check these out..

>     (Is autoconf available for Mac and does it make any sense there?)

Nope, no autoconf for the Mac.. It's all brute force.

>     There is a way to evolve the source base into a position where we
>     can do all I/O as events instead of polling like is done now.

The harder part is moving away from how closely coupled Fractint's state
is to the GUI.  Even GUI-less, the engine is still expecting certain
input during certain states (pressing Return/ESC in the Tab-info screen,
for example), which is a thorough pain in the bum.

>   The easiest way to find them all is to #ifdef out keypressed() and
>   look for all the places where the compile breaks ;-).

Ah, the sore-thumb philosophy of porting!

> I really hope this is useful to Tim and the Mac port folks.  (Sorry, I
> forgot your name!)  Please lets try and reuse what I've done so far
> since its like 70% finished and unfortunately my free time kinda
> evaporated since I took a full-time job which has prevented me from
> finishing it before you folks took up the torch.  In particular,

I'll definitely take a look, and work from the latest efforts.  Getting
the Mac port up and running has granted me some familiarity with the
source base, and some of its more interesting portability problems.

I'll post questions as they come up...

=- Tim Gilman
[e-mail]



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) initial stab at implementing drivers in fractint available
Date: 10 Nov 1999 08:41:49 -0700


In article <[e-mail]>,
    tim gilman <[e-mail]>  writes:

> >     (Is autoconf available for Mac and does it make any sense there?)
>
> Nope, no autoconf for the Mac.. It's all brute force.

The modifications I made don't use autoconf yet, there are only place
holders for variables and the like where autoconf should probe the
platform for reasonable defaults.

Isn't the new MacOS a variant of unix?  Do you have unix-like
utilities available?  gcc? make? bourne shell?  If you have a
unix-like environment, autoconf should come up without difficulty.

> The harder part is moving away from how closely coupled Fractint's state
> is to the GUI.  Even GUI-less, the engine is still expecting certain
> input during certain states (pressing Return/ESC in the Tab-info screen,
> for example), which is a thorough pain in the bum.

Yeah, what they did for the X11 port was to deal with the event queue
whenever a routine was called that polled for input.  Fractint polls
for input often enough that this is a reasonable place to have event
queue management.  However, I think fractint can be moved to an event
input model without a massive rewrite.  Obviously code will change,
but there are really only a few places where input is polled in the
middle of a computation.  This is because fractint abstracted most of
the fractal types into a parameterized engine.  The odd men out (from
memory) are IFS, L-system, 'ant', 'lorenz' and a few other fractal
types.  Most of the fractal types go through the engine, so its only
one place to change for most fractal types.

> >   The easiest way to find them all is to #ifdef out keypressed() and
> >   look for all the places where the compile breaks ;-).
>
> Ah, the sore-thumb philosophy of porting!

For jobs like these, I found that emacs really does improve my
productivity.  This is because you're making regular expression type
changes to the source code.  Also M-x next-error in emacs is a nice
way to navigate through the massive compiler errors you get when
taking the #ifdef approach.  MS visual studio has something similar,
but I actually prefer the emacs one.  Switching between source files
in studio still requires me to leave the keyboard and go to the mouse.
There are keyboard equivalents, but they just aren't as handy as the
ones I already know.

> I'll definitely take a look, and work from the latest efforts.  Getting
> the Mac port up and running has granted me some familiarity with the
> source base, and some of its more interesting portability problems.

I am interested in hearing of any problems that the Mac has where you
think they might be particular to the Mac.
--
<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.thewho.net>

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: WX Windows as a platform?
Date: 29 Nov 1999 20:57:32 -0600

Tim G. and all,

I had assumed that using the GTK toolkit would be the way to go
for a portable Fractint, because it supports C and has been ported
to Windows, so we could probably have essentially one set of
sources for Linux and Windows. But after asking several of my
Python guru friends at work, they said that WXWindows is a much
better way to go because it is much more platform independent. It
has ports to the Mac also. Tim G., do you know about this?

Check out:

http://www.freiburg.linux.de/~wxxt/

and

http://web.ukonline.co.uk/julian.smart/wxwin/

The downside is that this toolkit uses C++ and not C. At least I
think that is a downside :-) Of course if we wanted, the main non-
GUI sources could still be in C.

Make a note that my email address is now [e-mail]. I
will kill [e-mail] soon.

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: "Damien M. Jones" <[e-mail]>
Subject: Re: WX Windows as a platform?
Date: 29 Nov 1999 23:08:48 -0500

Tim,

 - The downside is that this toolkit uses C++ and not C. At least I
 - think that is a downside :-)

LOL--that's not a downside, that actually makes some things easier. :)

 - Of course if we wanted, the main non-GUI sources could still be in C.

Given the existing codebase that is in plain C, that's probably a good
idea. Mixing C and C++ is easy.

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"