home *** CD-ROM | disk | FTP | other *** search
/ ftp.xmission.com / 2014.06.ftp.xmission.com.tar / ftp.xmission.com / pub / lists / fractdev / archive / v01.n022 < prev    next >
Internet Message Format  |  1999-05-02  |  41KB

  1. From: owner-fractdev-digest@lists.xmission.com (fractdev-digest)
  2. To: fractdev-digest@lists.xmission.com
  3. Subject: fractdev-digest V1 #22
  4. Reply-To: fractdev-digest
  5. Sender: owner-fractdev-digest@lists.xmission.com
  6. Errors-To: owner-fractdev-digest@lists.xmission.com
  7. Precedence: bulk
  8.  
  9.  
  10. fractdev-digest          Monday, May 3 1999          Volume 01 : Number 022
  11.  
  12.  
  13.  
  14.  
  15. ----------------------------------------------------------------------
  16.  
  17. Date: Fri, 30 Apr 1999 12:35:54 -0400 (EDT)
  18. From: kragen@pobox.com (Kragen Sitaker)
  19. Subject: Re: (fractdev) everything
  20.  
  21. Fill wrote:
  22. > The path separator thing becomes painful under unix.  Fractint uses
  23. > '/' to separate the parameter name from a parameter file, for
  24. > isntance.  It happens to look for a '/', and if it sees one, it
  25. > assumes that the argument is ``@parfile/entry'', but if one naively
  26. > specified a full-path of a parfile under xfractint, you'd have a '/'
  27. > as part of the parfile name and xfractint will become confused.  A
  28. > workaround is to always have parfiles specified in this manner in the
  29. > current directory.  Either fractint's syntax will have to be adjusted
  30. > slightly, or some quoting mechanism must be installed to allow a full
  31. > pathname for a unix file to be specified in these instances.
  32.  
  33. Everything can work with no user-visible changes.
  34.  
  35. In the general case @a/b/c/d/e, a/b/c/d must be either be a file or a
  36. directory -- it can't be both, right?  (No "parfile paths", right?  I
  37. haven't used fractint in a while.)  If it's a file, @a/b/c/d/e means
  38. the entry e in the file a/b/c/d; if it's a directory, @a/b/c/d/e means
  39. the file a/b/c/d/e.
  40.  
  41. >         void * != int
  42. > Lots of places in the code there are implicit assumptions about
  43. > sizeof(int) == sizeof(void *).  This isn't good for portability in
  44. > general, and in the L-system code I think it actually causes a crash
  45. > in xfractint that shouldn't be there.
  46.  
  47. It's true that it's not good for portability in general, but it's true
  48. afaik on all 32-bit Intel platforms, the Sparc, and 32-bit MIPS
  49. machines.  I don't know if it's true on various Alpha platforms,
  50. various UltraSparc platforms, various 64-bit MIPS platforms (OK I mean
  51. IRIX) etc.  I know it's not true on some memory models of 16-bit Intel
  52. chips and the AS/400.
  53.  
  54. What I wanted to know is, what platform are you running xfractint on
  55. that this crash occurs?
  56.  
  57. > I think fractint should adopt gmp, but this will mean a fair bit of work.
  58.  
  59. I think everyone doing arbitrary-precision math should adopt GMP.
  60. However, you should be aware that adopting GMP will mean that Fractint
  61. has to be released under the GNU General Public License, which allows
  62. anyone to sell copies of Fractint.  IMHO this would be a good thing
  63. (e.g. it could be included with Red Hat Linux and Debian GNU/Linux).
  64. Some other people may not think so, and Fractint's current license
  65. forbids this.
  66.  
  67. Also, who holds the copyright on Fractint?  Remember that copyright
  68. inheres in a copyrightable work as soon as it is created, and cannot be
  69. transferred implicitly.  (You can give an implicit license, but you
  70. can't implicitly give away your copyright rights.)  For the Stone Soup
  71. Group to legitimately hold copyright to all of Fractint, everyone who
  72. has contributed a chunk of code big enough to be copyrightable needs to
  73. have signed legal papers to transfer their copyright ownership to the
  74. Stone Soup Group.  That probably doesn't mean everybody in the credits,
  75. but certainly a significant number of them.
  76.  
  77. The reason I ask is that only the holder of a copyright can license the
  78. copyrighted work.  If Jonathan decides he wants to license the Fractint
  79. code he wrote under the GPL, that's fine, but if Tim doesn't like it,
  80. Jonathan can't license Tim's code under the GPL.  If it turns out that
  81. 50 different people own the copyrights to various parts of Fractint,
  82. you'll need all 50 of their signatures or the signatures of their heirs
  83. (or you'll need to discard the code they wrote) in order to release
  84. Fractint under the GPL.
  85.  
  86. Linux uses the same technique to make it impossible to release Linux
  87. under a non-GPL license.  I understand environmental activists have
  88. used a similar technique -- selling individual square feet of land to
  89. many different people -- to slow down condemnation proceedings.
  90.  
  91. These same problems do not attend releasing a fractint including
  92. autoconf scripts for building or built with gcc and GNU libc, because
  93. of licensing or linking differences.  They *may* attend releasing a
  94. fractint linked against the DJGPP libraries or Allegro -- are these
  95. licensed under the GPL?
  96.  
  97. Summary: using gmp (and possibly djgpp or allegro) may be extremely
  98. difficult for legal reasons.  I am not a lawyer, and this is not legal
  99. advice.  Hit the books and make your own decisions.
  100.  
  101. > If it were up to me, I'd take
  102. > the complex and trig support impemented in fractint, port that onto
  103. > the gmp library and contribute it back as GPL'ed source to the gmp
  104. > maintainers.
  105.  
  106. Bruno Haible's CLN (see clisp.cons.org) is a GPLed library built on gmp
  107. that provides (among other things) complex support, and I think trig
  108. too.  It's written in C++ though.
  109.  
  110. > Just an observation... fractint already embodies the concept of
  111. > "generic programming with template classes" as closely as C can deal
  112. > with it.
  113.  
  114. Generally this is done in C with #define macros or m4.  (The latter can
  115. produce code that works better with most debuggers.)
  116.  
  117. > Ah, but here you're using the inheritence/OOness of C++ to exploit
  118. > reuse.  The generic programming/template model, as embodied by the STL
  119. > for example, is really quite a different kind of reuse than that
  120. > provided by class hierarchies.
  121.  
  122. Mechanically it's implemented differently.  Conceptually it's the same
  123. thing.  More advanced OO environments (like Self, notably) dynamically
  124. pick and mix specialization (generating multiple copies of the same
  125. code to deal with different data types) and dynamic dispatch
  126. (generating a single copy of the code which calls different code
  127. depending on the types of the data it's handling) to dynamically
  128. balance speed and code size/compile time.
  129.  
  130. > Despite all the different programming languages and circumstances in
  131. > which I've exercised my skill, the concepts embodied by the STL really
  132. > changed the way I looked at certain programming problems.
  133.  
  134. Me too.  (Although I can't really talk much about exercising my skill.  ;)
  135.  
  136. >  STL is written in C++, but it isn't "object oriented".  There is a
  137. > minor use of class inheritance to exhibit some reuse, but this is rare
  138. > and only in places where it makes sense for the problem.  STL has some
  139. > aspects of "functional" programming languages, especially adaptors,
  140. > binders, unary_function, binary_function, and so-on.
  141.  
  142. Well, like I said, it's a different way to implement the same thing.
  143. (STL implements several things that would be extremely slow if they
  144. were implemented with dynamic dispatch instead of specialization, and
  145. since "int" is not a class in C++, also very inconvenient to use.)
  146.  
  147. It's not very functional; the whole programming model is deeply based
  148. on mutation.
  149.  
  150. Looks like, by "binder", STL means something like "a curried function".
  151.  
  152. Humberto Rossetti Baptista wrote:
  153. >         Yesssss. And also I think gmp is C++ isnt' it?
  154.  
  155. No, C.
  156.  
  157. Fill wrote:
  158. >     "allegro"
  159. >         Uses Allegro library under DJGPP to enumerate video formats
  160. >         and provide video/mouse/sound support.
  161.  
  162. Could also work under X.
  163.  
  164. > But of all the open source software I use, I
  165. > couldn't think of one that embodies the stone soup tradition of mutual
  166. > cooperation more than fractint.
  167.  
  168. I think I agree.  But be careful -- Fractint is not now, and never has
  169. been, Open Source (tm) software, because people are not free to sell
  170. it.
  171.  
  172. - -- 
  173. <kragen@pobox.com>       Kragen Sitaker     <http://www.pobox.com/~kragen/>
  174. TurboLinux is outselling NT in Japan's retail software market 10 to 1,
  175. so I hear. 
  176. - -- http://www.performancecomputing.com/opinions/unixriot/981218.shtml
  177.  
  178.  
  179. - --------------------------------------------------------------
  180. Thanks for using Fractdev, The Fractint Developer's Discussion List
  181. Post Message:   fractdev@lists.xmission.com
  182. Get Commands:   majordomo@lists.xmission.com "help"
  183. Administrator:  twegner@phoenix.net
  184. Unsubscribe:    majordomo@lists.xmission.com "unsubscribe fractdev"
  185.  
  186. ------------------------------
  187.  
  188. Date: Fri, 30 Apr 1999 12:55:28 -0600
  189. From: Phil McRevis <legalize@xmission.com>
  190. Subject: Re: (fractdev) everything 
  191.  
  192. In article <Pine.GSU.4.10.9904301128390.8775-100000@picard.dnaco.net>,
  193.     kragen@pobox.com (Kragen Sitaker)  writes:
  194.  
  195. > Everything can work with no user-visible changes.
  196.  
  197. Yeah, but the code has to change, which was my real point.
  198.  
  199. > >         void * != int
  200. > > 
  201. > > Lots of places in the code there are implicit assumptions about
  202. > > sizeof(int) == sizeof(void *).  This isn't good for portability in
  203. > > general, and in the L-system code I think it actually causes a crash
  204. > > in xfractint that shouldn't be there.
  205. > It's true that it's not good for portability in general, but it's true
  206. > afaik on all 32-bit Intel platforms, the Sparc, and 32-bit MIPS
  207. > machines.
  208.  
  209. Nope, its not true on sparc, or MIPS.  Why?  Because a pointer has
  210. alignment restrictions that constrain its valid value and an integer
  211. does not.  In other words, the following is most certainly going to
  212. cause a crash on a sparc or mips platform:
  213.  
  214.     int i = 3;
  215.     void *p = (void *) i;
  216.     *p = 1;
  217.  
  218. On the x86, you can address 16/32/etc. sized quantities at any memory
  219. location.  The CPU does the necessary word twiddling to get the
  220. operand of the appropriate type.  Misaligning data on an x86 affects
  221. performance but doesn't crash.  On a non-x86 it almost certainly
  222. causes a crash or exception.
  223.  
  224. > What I wanted to know is, what platform are you running xfractint on
  225. > that this crash occurs?
  226.  
  227. I found a crash in L-systems on a sparc running solaris 2.7.  When I
  228. looked at it in the debugger, a quick 6-minute analysis figured the
  229. problem to be related to pointer casting due to the attempt to
  230. conserve memory in the medium model.  If the memory had just simply
  231. been malloc'ed instead, then it works fine.
  232.  
  233. > [long worry about the GPL and its implications]
  234.  
  235. This sounds like the typical misunderstanding of what the GPL really
  236. says.  I'd get a clarification from the FSF on that before I worried
  237. about it, but I personally believe it to be a non-issue.
  238.  
  239. > Bruno Haible's CLN (see clisp.cons.org) is a GPLed library built on gmp
  240. > that provides (among other things) complex support, and I think trig
  241. > too.  It's written in C++ though.
  242.  
  243. That URL just talks about a common lisp implementation, no mention of
  244. CLN or anything for C++.
  245.  
  246. > Mechanically it's implemented differently.  Conceptually it's the same
  247. > thing.
  248.  
  249. I disagree.  Generic programming is conceptually and syntactically
  250. different from OO programming in C++.  The only thing they have in
  251. common is a desire for reuse.
  252.  
  253. > It's not very functional; the whole programming model is deeply based
  254. > on mutation.
  255.  
  256. Adaptors, binders, etc., are all very much in the style of functional
  257. programming.  Its where they get their inspiration from.
  258.  
  259. > Looks like, by "binder", STL means something like "a curried function".
  260.  
  261. Yes.
  262.  
  263. > [Allegro]
  264. >
  265. > Could also work under X.
  266.  
  267. Yeah, but using allegro for fractint's X interface wouldn't be the
  268. right way to do it, I think.  Seriously folks, fracint's existing UI
  269. needs are not elaborate!  That's because fractint built everything
  270. itself on top of the basic functionality of being able to read/write
  271. single pixels into a memory-mapped VGA display.  The whole idea of
  272. modern UI needs is foreign to fractint.
  273.  
  274. > I think I agree.  But be careful -- Fractint is not now, and never has
  275. > been, Open Source (tm) software, because people are not free to sell
  276. > it.
  277.  
  278. We already went through this once before.  If someone is going to sue
  279. my ass becuase I consider fractint to be "open source", I wish they'd
  280. just get off their lazy butts and do it.  Otherwise, if you care to
  281. have a debate about the meaning of the GPL or the legal phrase "open
  282. source", then it'll be a one-sided debate since I consider engaging in
  283. such a debate to be a waste of time that only distracts me from the
  284. real issues facing fractint right now.
  285. - --
  286. <http://www.xmission.com/~legalize/>    Legalize Adulthood!
  287.     ``Ain't it funny that they all fire the pistol,     
  288.       at the wrong end of the race?''--PDBT     
  289. legalize@xmission.com    <http://www.eden.com/~thewho>
  290.  
  291. - --------------------------------------------------------------
  292. Thanks for using Fractdev, The Fractint Developer's Discussion List
  293. Post Message:   fractdev@lists.xmission.com
  294. Get Commands:   majordomo@lists.xmission.com "help"
  295. Administrator:  twegner@phoenix.net
  296. Unsubscribe:    majordomo@lists.xmission.com "unsubscribe fractdev"
  297.  
  298. ------------------------------
  299.  
  300. Date: Fri, 30 Apr 1999 16:51:16 -0400 (EDT)
  301. From: kragen@pobox.com (Kragen Sitaker)
  302. Subject: Re: (fractdev) everything
  303.  
  304. Legalize Adulthood writes:
  305. > > Everything can work with no user-visible changes.
  306. > Yeah, but the code has to change, which was my real point.
  307.  
  308. Of course you are correct.
  309.  
  310. > > > Lots of places in the code there are implicit assumptions about
  311. > > > sizeof(int) == sizeof(void *).  This isn't good for portability in
  312. > > > general, and in the L-system code I think it actually causes a crash
  313. > > > in xfractint that shouldn't be there.
  314. > >
  315. > > It's true that it's not good for portability in general, but it's true
  316. > > afaik on all 32-bit Intel platforms, the Sparc, and 32-bit MIPS
  317. > > machines.
  318. > Nope, its not true on sparc, or MIPS. [because of alignment]
  319.  
  320. When I said "it's true", I just meant the sizes were the same, not the
  321. alignment constraints, because that's what you said in the text I
  322. responded to.  Of course you are correct that arbitrary integers can't
  323. be used as pointers on most machines.  Often, however, this is a
  324. dangerous practice even on Intel hardware, because arbitrary integers
  325. are not likely to point at anything useful.  ;)
  326.  
  327. > > [long worry about the GPL and its implications]
  328. > This sounds like the typical misunderstanding of what the GPL really
  329. > says.
  330.  
  331. It's not.
  332.  
  333. > I'd get a clarification from the FSF on that before I worried
  334. > about it, but I personally believe it to be a non-issue.
  335.  
  336. I've sent them an email, saying,
  337.     Someone's proposing replacing Fractint's arbitrary-precision
  338.     math routines with routines from the GMP library.  My
  339.     understanding is that this would require Fractint to be
  340.     licensed under the GPL, which would lift the restriction
  341.     against commercial sale of Fractint in Fractint's current
  342.     license.  Is this correct?  Is it possible to link Fractint
  343.     with GMP and continue to distribute Fractint executables under
  344.     the current Fractint license?
  345.  
  346. I will forward the response to this list.
  347.  
  348. > > Bruno Haible's CLN (see clisp.cons.org) is a GPLed library built on gmp
  349. > > that provides (among other things) complex support, and I think trig
  350. > > too.  It's written in C++ though.
  351. > That URL just talks about a common lisp implementation, no mention of
  352. > CLN or anything for C++.
  353.  
  354. The Common Lisp implementation in question is implemented in C++ and
  355. uses CLN for its numeric processing.  I can't seem to find links to CLN
  356. from the home page, but CLN's home page is at
  357. http://clisp.cons.org/~haible/packages-cln.html.
  358.  
  359. > > Mechanically it's implemented differently.  Conceptually it's the same
  360. > > thing.
  361. > I disagree.  Generic programming is conceptually and syntactically
  362. > different from OO programming in C++.  The only thing they have in
  363. > common is a desire for reuse.
  364.  
  365. Unarguably, C++ syntax for template-based polymorphism is different
  366. from C++ syntax for dynamic-method-dispatch-based polymorphism.  And
  367. underneath the hood, they are unarguably different things.  But they
  368. are two ways of doing the same thing: specifying what you want to do
  369. to an object and letting the object decide what the most appropriate
  370. way of doing that thing is, and allowing different objects to do the
  371. same thing differently without any change in the calling code.
  372.  
  373. > We already went through this once before.  If someone is going to sue
  374. > my ass becuase I consider fractint to be "open source",
  375.  
  376. I thought I forwarded you the response I got from OSI.  They said they
  377. couldn't do anything about posts on private mailing lists.  So noone
  378. will sue your ass.  :)
  379.  
  380. > I consider engaging in such a debate to be a waste of time that only
  381. > distracts me from the real issues facing fractint right now.
  382.  
  383. Bravo, concentrate on the real issues, then.  The work you're doing is
  384. certainly important.  Have fun.
  385.  
  386. - -- 
  387. <kragen@pobox.com>       Kragen Sitaker     <http://www.pobox.com/~kragen/>
  388. TurboLinux is outselling NT in Japan's retail software market 10 to 1,
  389. so I hear. 
  390. - -- http://www.performancecomputing.com/opinions/unixriot/981218.shtml
  391.  
  392.  
  393. - --------------------------------------------------------------
  394. Thanks for using Fractdev, The Fractint Developer's Discussion List
  395. Post Message:   fractdev@lists.xmission.com
  396. Get Commands:   majordomo@lists.xmission.com "help"
  397. Administrator:  twegner@phoenix.net
  398. Unsubscribe:    majordomo@lists.xmission.com "unsubscribe fractdev"
  399.  
  400. ------------------------------
  401.  
  402. Date: Fri, 30 Apr 1999 18:01:55 -0400 (EDT)
  403. From: kragen@pobox.com (Kragen Sitaker)
  404. Subject: (fractdev) GPL clarification
  405.  
  406. The response to my email to gnu@gnu.org:
  407.  
  408. If GMP is under the GPL, then Fractint would have to be
  409. GPLed to use GMP code.  Under the GPL you can have
  410. commercial sale, although license fees are illegal of
  411. course.
  412.  
  413. - --
  414.                                    Brian Youmans
  415.                                    FSF Office Staff
  416.  
  417. - -- 
  418. <kragen@pobox.com>       Kragen Sitaker     <http://www.pobox.com/~kragen/>
  419. TurboLinux is outselling NT in Japan's retail software market 10 to 1,
  420. so I hear. 
  421. - -- http://www.performancecomputing.com/opinions/unixriot/981218.shtml
  422.  
  423.  
  424. - --------------------------------------------------------------
  425. Thanks for using Fractdev, The Fractint Developer's Discussion List
  426. Post Message:   fractdev@lists.xmission.com
  427. Get Commands:   majordomo@lists.xmission.com "help"
  428. Administrator:  twegner@phoenix.net
  429. Unsubscribe:    majordomo@lists.xmission.com "unsubscribe fractdev"
  430.  
  431. ------------------------------
  432.  
  433. Date: Fri, 30 Apr 1999 17:15:46 -0600
  434. From: "Tim Wegner" <twegner@phoenix.net>
  435. Subject: Re: (fractdev) portability thoughts 
  436.  
  437. Phil said:
  438.  
  439. > Some low-level stuff is written in assembly, see bigflta.asm and
  440. > bignuma.asm.  Poking around a little more, it looks like bigfltc.c
  441. > implements C versions of the assembly routines.
  442.  
  443. Fractint's arbitrary precision is already portable, as far as we know. 
  444. I will say that it is optimized for little endian and probably is less 
  445. efficient on big endian.
  446.  
  447. The main reason for not going to another arbitrary precision library 
  448. is that Wes has implemented a slew of transcendental functions.
  449.  
  450. Tim
  451.  
  452.  
  453. - --------------------------------------------------------------
  454. Thanks for using Fractdev, The Fractint Developer's Discussion List
  455. Post Message:   fractdev@lists.xmission.com
  456. Get Commands:   majordomo@lists.xmission.com "help"
  457. Administrator:  twegner@phoenix.net
  458. Unsubscribe:    majordomo@lists.xmission.com "unsubscribe fractdev"
  459.  
  460. ------------------------------
  461.  
  462. Date: Fri, 30 Apr 1999 22:25:55 -0300 (EST)
  463. From: Humberto Rossetti Baptista <humberto@insite.com.br>
  464. Subject: Re: (fractdev) GPL clarification
  465.  
  466. On Fri, 30 Apr 1999, Kragen Sitaker wrote:
  467. [Brian quote:]
  468. > If GMP is under the GPL, then Fractint would have to be
  469. > GPLed to use GMP code.  Under the GPL you can have
  470. > commercial sale, although license fees are illegal of
  471. > course.
  472.  
  473.     Brian is being lazy in his response since gmp is a "recommended"free
  474. program on the fsf site.
  475.  
  476.     It is not on GPL (what would indeed require fractint to become GPL), but
  477. it is LGPL (http://www.fsf.org/manual/gmp/html_chapter/gmp_1.html#SEC1 and the
  478. definition of LGPL is in http://www.fsf.org/copyleft/lgpl.html).
  479.  
  480.     The LGPL is the Library Gnu Policy License and it provide mechanisms to
  481. link agains a free library a non-GPL program, such as Fractint.
  482.  
  483.     In the spirit of freedom I agree with "Phil" when he says that fractint
  484. is free software, bu I guess our licence is more radical than GNU :-))))
  485.  
  486.     In short: we an link agains GMP w/ no problems.
  487.  
  488.     []'s
  489.  
  490.     Humberto R. Baptista
  491.     humberto@insite.com.br
  492.  
  493. - ---------------------------------------------------------------------------
  494. Insite - Solucoes Internet                         http://www.insite.com.br
  495.  
  496. - -----BEGIN GEEK CODE BLOCK-----
  497. Version: 3.1
  498. GB/C/CA/CM/CS/CC/ED/FA/H/IT/L/M/MU/P/S d?>dpu s:- a->!@ C++++$ USL+++$ P+++@ 
  499. L+++@ !E W++@ N++(+)@ o+>++++$ K? w>---$ O-@$ M--@ V-- PS@ PE@ Y+>+++$ PGP+@ 
  500. t+++ 5+@ X+ R>+++$ tv@ b+>++++$ DI++$ D++>++++$ G e+++>++++ h(---)>*$ r+++ 
  501. y+++*
  502. - ------END GEEK CODE BLOCK------
  503.  
  504.  
  505.  
  506. - --------------------------------------------------------------
  507. Thanks for using Fractdev, The Fractint Developer's Discussion List
  508. Post Message:   fractdev@lists.xmission.com
  509. Get Commands:   majordomo@lists.xmission.com "help"
  510. Administrator:  twegner@phoenix.net
  511. Unsubscribe:    majordomo@lists.xmission.com "unsubscribe fractdev"
  512.  
  513. ------------------------------
  514.  
  515. Date: Fri, 30 Apr 1999 20:16:56 -0600
  516. From: Phil McRevis <legalize@xmission.com>
  517. Subject: Re: (fractdev) everything 
  518.  
  519. In article <Pine.GSU.4.10.9904301510500.15300-100000@picard.dnaco.net>,
  520.     kragen@pobox.com (Kragen Sitaker)  writes:
  521.  
  522. > > I'd get a clarification from the FSF on that before I worried
  523. > > about it, but I personally believe it to be a non-issue.
  524. > I've sent them an email, saying [...]
  525.  
  526. Actually you needn't even bother.  All you have to do is read the
  527. license in the gmp-2.0.2 distribution.  It says quite clearly that
  528. linking against the library doesn't mean your program is bound by the
  529. GPL.  Like I said, it sounds like you have a misconception about the
  530. GPL covering gmp-2.0.2.
  531.  
  532. > [generic programming and oo programming]
  533. > are two ways of doing the same thing: specifying what you want to do
  534. > to an object and letting the object decide what the most appropriate
  535. > way of doing that thing is, and allowing different objects to do the
  536. > same thing differently without any change in the calling code.
  537.  
  538. It sounds like we don't have a common accepted definition of "generic
  539. programming".  At any rate, its not relevant to anything
  540. fractdev-related.
  541.  
  542. > > We already went through this once before.  If someone is going to sue
  543. > > my ass becuase I consider fractint to be "open source",
  544. > I thought I forwarded you the response I got from OSI. [...]
  545.  
  546. Yes, so why did you bring it up again?  There's no point in rehashing
  547. this stuff every time I happen to type the phrase "open source".
  548.  
  549. You know, the kind of feedback I wanted was about specific things in
  550. the fractint code that I should be paying attention to now, so as not
  551. to avoid some problem that occurs to another mind familiar with the
  552. source.  I'm afraid your response just wasn't helpful, only time
  553. consuming.
  554. - --
  555. <http://www.xmission.com/~legalize/>    Legalize Adulthood!
  556.     ``Ain't it funny that they all fire the pistol,     
  557.       at the wrong end of the race?''--PDBT     
  558. legalize@xmission.com    <http://www.eden.com/~thewho>
  559.  
  560. - --------------------------------------------------------------
  561. Thanks for using Fractdev, The Fractint Developer's Discussion List
  562. Post Message:   fractdev@lists.xmission.com
  563. Get Commands:   majordomo@lists.xmission.com "help"
  564. Administrator:  twegner@phoenix.net
  565. Unsubscribe:    majordomo@lists.xmission.com "unsubscribe fractdev"
  566.  
  567. ------------------------------
  568.  
  569. Date: Fri, 30 Apr 1999 20:19:00 -0600
  570. From: Phil McRevis <legalize@xmission.com>
  571. Subject: Re: (fractdev) GPL clarification 
  572.  
  573. Like I said, please read the COPYING file in the gmp-2.0.2
  574. distribution.  It states quite clearly that you can link against the
  575. library without having to adopt the GPL in your code.
  576.  
  577. Thanks for reporting me to the FSF police.
  578. - --
  579. <http://www.xmission.com/~legalize/>    Legalize Adulthood!
  580.     ``Ain't it funny that they all fire the pistol,     
  581.       at the wrong end of the race?''--PDBT     
  582. legalize@xmission.com    <http://www.eden.com/~thewho>
  583.  
  584. - --------------------------------------------------------------
  585. Thanks for using Fractdev, The Fractint Developer's Discussion List
  586. Post Message:   fractdev@lists.xmission.com
  587. Get Commands:   majordomo@lists.xmission.com "help"
  588. Administrator:  twegner@phoenix.net
  589. Unsubscribe:    majordomo@lists.xmission.com "unsubscribe fractdev"
  590.  
  591. ------------------------------
  592.  
  593. Date: Fri, 30 Apr 1999 20:24:01 -0600
  594. From: Phil McRevis <legalize@xmission.com>
  595. Subject: Re: (fractdev) portability thoughts 
  596.  
  597. In article <199904302215.RAA12205@voyager.c-com.net>,
  598.     "Tim Wegner" <twegner@phoenix.net>  writes:
  599.  
  600. > Fractint's arbitrary precision is already portable, as far as we know. 
  601.  
  602. As I guessed after a little browsing.
  603.  
  604. > I will say that it is optimized for little endian and probably is less 
  605. > efficient on big endian.
  606.  
  607. And no assembly support is provided for anything other than 16bit x86.
  608. GMP's main advantage is its wide support for assembly on different
  609. CPUs.
  610.  
  611. > The main reason for not going to another arbitrary precision library 
  612. > is that Wes has implemented a slew of transcendental functions.
  613.  
  614. Yep, which is why my note in my "thoughts" file also contained wording
  615. to the effect that in the true stone soup tradition, fractint's
  616. contribution to gmp could be adding the complex and transcendental
  617. function support back to gmp.  Then fractint would just link against
  618. gmp like any other gmp client.
  619.  
  620. Naturally the authors of that code would have to agree to this before
  621. their code could be used directly in such an effort.  However, I don't
  622. see the "stone soup tradition" and the FSF's goals to be at
  623. cross-purposes, more like cousins in the same family.  At any rate, I
  624. have no idea why this has become the hot potato issue from all the stuff
  625. I wrote when its like item #682 on the agenda.
  626. - --
  627. <http://www.xmission.com/~legalize/>    Legalize Adulthood!
  628.     ``Ain't it funny that they all fire the pistol,     
  629.       at the wrong end of the race?''--PDBT     
  630. legalize@xmission.com    <http://www.eden.com/~thewho>
  631.  
  632. - --------------------------------------------------------------
  633. Thanks for using Fractdev, The Fractint Developer's Discussion List
  634. Post Message:   fractdev@lists.xmission.com
  635. Get Commands:   majordomo@lists.xmission.com "help"
  636. Administrator:  twegner@phoenix.net
  637. Unsubscribe:    majordomo@lists.xmission.com "unsubscribe fractdev"
  638.  
  639. ------------------------------
  640.  
  641. Date: Fri, 30 Apr 1999 22:36:27 -0400 (EDT)
  642. From: kragen@pobox.com (Kragen Sitaker)
  643. Subject: Re: (fractdev) everything
  644.  
  645. You wrote:
  646. > At any rate, I have no idea why this has become the hot potato issue
  647. > from all the stuff I wrote when its like item #682 on the agenda.
  648.  
  649. Yeah, it puzzled me a bit, too.  I didn't mean for it to be, and I
  650. certainly didn't mean to waste your time.
  651.  
  652. I'm not sure why I thought gmp was GPLed -- I think it might have been
  653. several years ago.  I'll let you know (in private so as not to use up
  654. more list bits) when I find out.
  655.  
  656. - -- 
  657. <kragen@pobox.com>       Kragen Sitaker     <http://www.pobox.com/~kragen/>
  658. TurboLinux is outselling NT in Japan's retail software market 10 to 1,
  659. so I hear. 
  660. - -- http://www.performancecomputing.com/opinions/unixriot/981218.shtml
  661.  
  662.  
  663. - --------------------------------------------------------------
  664. Thanks for using Fractdev, The Fractint Developer's Discussion List
  665. Post Message:   fractdev@lists.xmission.com
  666. Get Commands:   majordomo@lists.xmission.com "help"
  667. Administrator:  twegner@phoenix.net
  668. Unsubscribe:    majordomo@lists.xmission.com "unsubscribe fractdev"
  669.  
  670. ------------------------------
  671.  
  672. Date: Fri, 30 Apr 1999 20:39:13 -0600
  673. From: Phil McRevis <legalize@xmission.com>
  674. Subject: Re: (fractdev) everything 
  675.  
  676. In article <Pine.GSU.4.10.9904302234010.29558-100000@kirk.dnaco.net>,
  677.     kragen@pobox.com (Kragen Sitaker)  writes:
  678. > I'm not sure why I thought gmp was GPLed -- I think it might have been
  679. > several years ago.  I'll let you know (in private so as not to use up
  680. > more list bits) when I find out.
  681.  
  682. Please don't bother.  I'm not really interested.
  683. - --
  684. <http://www.xmission.com/~legalize/>    Legalize Adulthood!
  685.     ``Ain't it funny that they all fire the pistol,     
  686.       at the wrong end of the race?''--PDBT     
  687. legalize@xmission.com    <http://www.eden.com/~thewho>
  688.  
  689. - --------------------------------------------------------------
  690. Thanks for using Fractdev, The Fractint Developer's Discussion List
  691. Post Message:   fractdev@lists.xmission.com
  692. Get Commands:   majordomo@lists.xmission.com "help"
  693. Administrator:  twegner@phoenix.net
  694. Unsubscribe:    majordomo@lists.xmission.com "unsubscribe fractdev"
  695.  
  696. ------------------------------
  697.  
  698. Date: Sat, 1 May 1999 10:31:21 -0600
  699. From: "Tim Wegner" <twegner@phoenix.net>
  700. Subject: Re: (fractdev) GPL clarification
  701.  
  702. Kragen wrote:
  703.  
  704. > The response to my email to gnu@gnu.org:
  705. > If GMP is under the GPL, then Fractint would have to be
  706. > GPLed to use GMP code.  Under the GPL you can have
  707. > commercial sale, although license fees are illegal of
  708. > course.
  709. > --
  710. >                                    Brian Youmans
  711. >                                    FSF Office Staff
  712.  
  713.  
  714. Folks if you want to kill the idea of Fractint's using somebody's 
  715. code, quote some bureaucrat who uses unintelligible  acronyms 
  716. who is trying to tell us what to do.
  717.  
  718. As Rich said, arbitrary precision is very low on our list of priorities. 
  719. We have working portable code written by ourselves. At some 
  720. future time we might rework it. 
  721.  
  722. FWIW, Fractint has the policy of not using any libraries that we 
  723. can't provide in source form. We do have a need to redo our license 
  724. agreement, which is very badly written. However this interchange 
  725. has not warmed me up to  FSF (Free Software Foundation???).
  726.  
  727. Tim Wegner
  728.  
  729.  
  730.  
  731.  
  732. - --------------------------------------------------------------
  733. Thanks for using Fractdev, The Fractint Developer's Discussion List
  734. Post Message:   fractdev@lists.xmission.com
  735. Get Commands:   majordomo@lists.xmission.com "help"
  736. Administrator:  twegner@phoenix.net
  737. Unsubscribe:    majordomo@lists.xmission.com "unsubscribe fractdev"
  738.  
  739. ------------------------------
  740.  
  741. Date: Sun, 02 May 1999 19:26:30 -0600
  742. From: Phil McRevis <legalize@xmission.com>
  743. Subject: Re: (fractdev) GPL clarification 
  744.  
  745. Don't worry about what Brian Youmans said.  He hasn't read the license
  746. file that comes with GMP.  That file really is the last word on this
  747. subject.  <ftp://mirrors.xmission.com/gnu/gmp/gmp-2.0.2.tar.gz>
  748. - --
  749. <http://www.xmission.com/~legalize/>    Legalize Adulthood!
  750.     ``Ain't it funny that they all fire the pistol,     
  751.       at the wrong end of the race?''--PDBT     
  752. legalize@xmission.com    <http://www.eden.com/~thewho>
  753.  
  754. - --------------------------------------------------------------
  755. Thanks for using Fractdev, The Fractint Developer's Discussion List
  756. Post Message:   fractdev@lists.xmission.com
  757. Get Commands:   majordomo@lists.xmission.com "help"
  758. Administrator:  twegner@phoenix.net
  759. Unsubscribe:    majordomo@lists.xmission.com "unsubscribe fractdev"
  760.  
  761. ------------------------------
  762.  
  763. Date: Mon, 03 May 1999 08:08:40 -0600
  764. From: Phil McRevis <legalize@xmission.com>
  765. Subject: (fractdev) device extraction -- 2nd try
  766.  
  767. - ------- =_aaaaaaaaaa0
  768. Content-Type: text/plain; charset="us-ascii"
  769. Content-ID: <6646.925740513.1@xmission.xmission.com>
  770.  
  771. Looks like my first try was too long again, here we go...
  772.  
  773. Well I've made the first pass through the code and ripped out the
  774. XFRACT specific parts and separated the code into two and a half
  775. drivers: "disk", "x11", and "fractint".  Its only two and a half
  776. drivers because the "fractint" driver hasn't had its guts (i.e. the
  777. existing video drivers written in assembly) ported to a 32bit DPMI
  778. environment, which is the target of this effort.
  779.  
  780. "disk" uses curses for text I/O, uses a piece of memory as a
  781. framebuffer for graphical output and uses the diskvideo code already in
  782. fractint.
  783.  
  784. "x11" has the X11 graphical output code, but none of the curses text
  785. I/O code.  Next for X11 will be to have its text I/O implemented with
  786. X text.
  787.  
  788. "fractint" won't work completely in this flat-memory model port (i.e.
  789. djgpp) until the assembly code is ported for the video drivers.  Where
  790. there was a routine that was only partially #ifdef'ed on XFRACT, the
  791. non-XFACT version of the routine went into the fractint driver.  This
  792. code has not been compiled, but would serve a useful scaffold to
  793. whoever wanted to port the assembly. ;-)
  794.  
  795. I've only gone so far as to make the edits to the code (quite a lot)
  796. and verify that everything compiles like it should.  I ran the curses
  797. version and it came up like it should, although it didn't save a proper
  798. GIF correctly when I typed 's'.
  799.  
  800. FYI Attachments: driver header file
  801. - --
  802. <http://www.xmission.com/~legalize/>    Legalize Adulthood!
  803.     ``Ain't it funny that they all fire the pistol, 
  804.       at the wrong end of the race?''--PDBT
  805.           <http://www.eden.com/~thewho>
  806.  
  807. - ------- =_aaaaaaaaaa0
  808. Content-Type: text/plain; name="drivers.h"; charset="us-ascii"
  809. Content-ID: <6646.925740513.2@xmission.xmission.com>
  810.  
  811. #if !defined(DRIVERS_H)
  812. #define DRIVERS_H
  813.  
  814. /*------------------------------------------------------------
  815.  * Driver Methods:
  816.  *
  817.  * init
  818.  * Initialize the driver and return non-zero on success.
  819.  *
  820.  * terminate
  821.  * flush
  822.  * schedule_alarm
  823.  * start_video
  824.  * end_video
  825.  
  826.  * window
  827.  * Do whatever is necessary to open up a window after the screen size
  828.  * has been set.  In a windowed environment, the window may provide
  829.  * scroll bars to pan a cropped view across the screen.
  830.  *
  831.  * resize
  832.  * redraw
  833.  * read_palette, write_palette
  834.  * read_pixel, write_pixel
  835.  * read_span, write_span
  836.  * set_line_mode
  837.  * draw_line
  838.  * get_key
  839.  * shell
  840.  * set_video_mode
  841.  * put_string
  842.  * set_for_text, set_for_graphics, set_clear
  843.  * find_font
  844.  * move_cursor
  845.  * hide_text_cursor
  846.  * set_attr
  847.  * scroll_up
  848.  * stack_screen, unstack_screen, discard_screen
  849.  */
  850. struct tagDriver {
  851.   const char *name;            /* name of driver */
  852.   int (*init)(int *argc, char **argv);  /* init the driver */
  853.   void (*terminate)(void);        /* shutdown the driver */
  854.   void (*flush)(void);            /* flush pending updates */
  855.   void (*schedule_alarm)(int secs);    /* refresh alarm */
  856.  
  857.   int (*start_video)(void);
  858.   int (*end_video)(void);
  859.  
  860.   void (*window)(void);            /* creates a window */
  861.   int (*resize)(void);            /* handles window resize.  */
  862.   void (*redraw)(void);            /* redraws the screen */
  863.  
  864.   int (*read_palette)(void);        /* reads palette into dacbox */
  865.   int (*write_palette)(void);        /* writes dacbox into palette */
  866.  
  867.   int (*read_pixel)(int x, int y);
  868.   void (*write_pixel)(int x, int y, int color);
  869.                     /* reads a line of pixels */
  870.   void (*read_span)(int y, int x, int lastx, BYTE *pixels);
  871.                     /* writes a line of pixels */
  872.   void (*write_span)(int y, int x, int lastx, BYTE *pixels);
  873.  
  874.   void (*set_line_mode)(int mode);    /* set copy/xor line */
  875.   void (*draw_line)(int x1, int y1, int x2, int y2); /* draw line */
  876.   
  877.   int (*get_key)(int block);        /* poll or block for a key */
  878.   void (*shell)(void);            /* invoke a command shell */
  879.   void (*set_video_mode)(int ax, int bx, int cx, int dx);
  880.   void (*put_string)(int row, int col, int attr, const char *msg);
  881.  
  882.   void (*set_for_text)(void);        /* set for text mode & save gfx */
  883.   void (*set_for_graphics)(void);    /* restores graphics and data */
  884.   void (*set_clear)(void);        /* clears text screen */
  885.  
  886.   BYTE *(*find_font)(int parm);        /* for palette editor */
  887.  
  888.   /* text screen functions */
  889.   void (*move_cursor)(int row, int col);
  890.   void (*hide_text_cursor)(void);
  891.   void (*set_attr)(int row, int col, int attr, int count);
  892.   void (*scroll_up)(int top, int bot);
  893.   void (*stack_screen)(void);
  894.   void (*unstack_screen)(void);
  895.   void (*discard_screen)(void);
  896.  
  897.   /* sound routines */
  898.   int (*init_fm)(void);
  899.   void (*buzzer)(int kind);
  900.   void (*sound_on)(int frequency);
  901.   void (*sound_off)(void);
  902.   
  903. };
  904. typedef struct tagDriver Driver;
  905.  
  906. #define STD_DRIVER_STRUCT(name_) \
  907.   { \
  908.     "##name_##", \
  909.     name_##_init, \
  910.     name_##_terminate, \
  911.     name_##_flush, \
  912.     name_##_schedule_alarm, \
  913.     name_##_start_video, \
  914.     name_##_end_video, \
  915.     name_##_window, \
  916.     name_##_resize, \
  917.     name_##_redraw, \
  918.     name_##_read_palette, \
  919.     name_##_write_palette, \
  920.     name_##_read_pixel, \
  921.     name_##_write_pixel, \
  922.     name_##_read_span, \
  923.     name_##_write_span, \
  924.     name_##_set_line_mode, \
  925.     name_##_draw_line, \
  926.     name_##_get_key, \
  927.     name_##_shell, \
  928.     name_##_set_video_mode, \
  929.     name_##_put_string, \
  930.     name_##_set_for_text, \
  931.     name_##_set_for_graphics, \
  932.     name_##_set_clear, \
  933.     name_##_find_font, \
  934.     name_##_move_cursor, \
  935.     name_##_hide_text_cursor, \
  936.     name_##_set_attr, \
  937.     name_##_scroll_up, \
  938.     name_##_stack_screen, \
  939.     name_##_unstack_screen, \
  940.     name_##_discard_screen, \
  941.     name_##_init_fm, \
  942.     name_##_buzzer, \
  943.     name_##_sound_on, \
  944.     name_##_sound_off \
  945.   }
  946.  
  947. #define HAVE_X11_DRIVER 1
  948. #define HAVE_DISK_DRIVER 1
  949.  
  950. extern int init_drivers(int *argc, char **argv);
  951. extern void close_drivers(void);
  952.  
  953. #define USE_DRIVER_FUNCTIONS 1
  954.  
  955. #if defined(USE_DRIVER_FUNCTIONS)
  956.  
  957. extern void driver_terminate(void);
  958. extern void driver_flush(void);
  959. extern void driver_schedule_alarm(int secs);
  960. extern int driver_start_video(void);
  961. extern int driver_end_video(void);
  962. extern void driver_window(void);
  963. extern int driver_resize(void);
  964. extern void driver_redraw(void);
  965. extern int driver_read_palette(void);
  966. extern int driver_write_palette(void);
  967. extern int driver_read_pixel(int x, int y);
  968. extern void driver_write_pixel(int x, int y, int color);
  969. extern void driver_read_span(int y, int x, int lastx, BYTE *pixels);
  970. extern void driver_write_span(int y, int x, int lastx, BYTE *pixels);
  971. extern void driver_set_line_mode(int mode);
  972. extern void driver_draw_line(int x1, int y1, int x2, int y2);
  973. extern int driver_get_key(int block);
  974. extern void driver_shell(void);
  975. extern void driver_set_video_mode(int ax, int bx, int cx, int dx);
  976. extern void driver_put_string(int row, int col, int attr, const char *msg);
  977. extern void driver_set_for_text(void);
  978. extern void driver_set_for_graphics(void);
  979. extern void driver_set_clear(void);
  980. extern BYTE *driver_find_font(int parm);
  981. extern void driver_move_cursor(int row, int col);
  982. extern void driver_hide_text_cursor(void);
  983. extern void driver_set_attr(int row, int col, int attr, int count);
  984. extern void driver_scroll_up(int top, int bot);
  985. extern void driver_stack_screen(void);
  986. extern void driver_unstack_screen(void);
  987. extern void driver_discard_screen(void);
  988. extern int driver_init_fm(void);
  989. extern void driver_buzzer(int kind);
  990. extern void driver_sound_on(int frequency);
  991. extern void driver_sound_off(void);
  992.  
  993. #else
  994.  
  995. extern Driver *display;
  996. #define driver_terminate()        (*display->terminate)()
  997. #define driver_flush()            (*display->flush)()
  998. #define void driver_schedule_alarm(_secs) \
  999.     (*display->schedule_alarm)(_secs)
  1000. #define driver_start_video()        (*display->start_video)()
  1001. #define driver_end_video()        (*display->end_video)()
  1002. #define driver_window()            (*display->window)()
  1003. #define driver_resize()            (*display->resize)()
  1004. #define driver_redraw()            (*display->redraw)()
  1005. #define driver_read_palette()        (*display->read_palette)()
  1006. #define driver_write_palette()        (*display->write_palette)()
  1007. #define driver_read_pixel(_x, _y)    (*display->read_pixel)(_x, _y)
  1008. #define driver_write_pixel(_x, _y, _color) \
  1009.     (*display->write_pixel)(_x, _y, _color)
  1010. #define driver_read_span(_y, _x, _lastx, _pixels) \
  1011.     (*display->read_span(_y, _x, _lastx, _pixels)
  1012. #define driver_write_span(_y, _x, _lastx, _pixels) \
  1013.     (*display->write_span)(_y, _x, _lastx, _pixels)
  1014. #define driver_set_line_mode(_m)    (*display->set_line_mode)(_m)
  1015. #define driver_draw_line(x1_, y1_, x2_, y2_) \
  1016.     (*display->draw_line)(x1_, y1_, x1_, y2_)
  1017. #define driver_get_key(_block)        (*display->get_key)(_block)
  1018. #define driver_shell()            (*display->shell)()
  1019. #define driver_set_video_mode(_ax, _bx, _cx, _dx) \
  1020.     (*display->set_video_mode)(_ax, _bx, _cx, _dx)
  1021. #define driver_put_string(_row, _col, _attr, _msg) \
  1022.     (*display->put_string)(_row, _col, _attr, _msg)
  1023. #define driver_set_for_text()        (*display->set_for_text)()
  1024. #define driver_set_for_graphics()    (*display->set_for_graphics)()
  1025. #define driver_set_clear()        (*display->set_clear)()
  1026. #define driver_find_font(_parm)        (*display->find_font)(_parm)
  1027. #define driver_move_cursor(_row, _col)    (*display->move_cursor)(_row, _col)
  1028. #define driver_hide_text_cursor()    (*display->hide_text_cursor)()
  1029. #define driver_set_attr(_row, _col, _attr, _count) \
  1030.     (*display->set_attr)(_row, _col, _attr, _count)
  1031. #define driver_scroll_up(_top, _bot) \
  1032.     (*display->scroll_up)(_top, _bot)
  1033. #define driver_stack_screen()        (*display->stack_screen)()
  1034. #define driver_unstack_screen()        (*display->unstack_screen)()
  1035. #define driver_discard_screen()        (*display->discard_screen)()
  1036. #define driver_init_fm()        (*display->init_fm)()
  1037. #define driver_buzzer(_kind)        (*display->buzzer)(_kind)()
  1038. #define driver_sound_on(_freq)        (*display->sound)(_freq)
  1039. #define driver_sound_off()        (*display->sound_off)()
  1040.  
  1041. #endif
  1042.  
  1043. #endif /* DRIVERS_H */
  1044.  
  1045. - ------- =_aaaaaaaaaa0--
  1046.  
  1047. - --------------------------------------------------------------
  1048. Thanks for using Fractdev, The Fractint Developer's Discussion List
  1049. Post Message:   fractdev@lists.xmission.com
  1050. Get Commands:   majordomo@lists.xmission.com "help"
  1051. Administrator:  twegner@phoenix.net
  1052. Unsubscribe:    majordomo@lists.xmission.com "unsubscribe fractdev"
  1053.  
  1054. ------------------------------
  1055.  
  1056. End of fractdev-digest V1 #22
  1057. *****************************
  1058.  
  1059.