Menu
▾
▴
gusi-discussion
|
From: Joshua J. <wan...@me...> - 2004-11-15 04:35:36
|
Hello, The list has been dormant for well over a year, and the CVS has been inactive for almost two. Is this project dead, or just resting? I've built GUSI as a shared library, and now I'm interested in Carbon support, using CFMLateImport to get native POSIX on Mac OS X. I'm willing to contribute code, and I understand some of the work has already been done. Who's interested? Josh -- Joshua Juran Metamage Software Creations - Mac Software and Consulting http://www.metamage.com/ * Creation at the highest state of the art * |
|
From: Matthias N. <nee...@ma...> - 2004-11-15 05:51:01
|
On Nov 14, 2004, at 8:35 PM, Joshua Juran wrote: > The list has been dormant for well over a year, and the CVS has been=20= > inactive for almost two. Is this project dead, or just resting? An excellent question, and thanks for bringing it up! For a variety of reasons, I never did any Carbon development =96=A0I=20 basically moved from Classic directly to Cocoa/BSD. I have no further=20 plans with GUSI, but I definitely wouldn't want to stand in the way of=20= anybody who wants to take the code forward in any way. The GUSI license=20= should be liberal enough to permit pretty much any conceivable use=20 (Including printing out the source code onto heavy paper stock and=20 clubbing baby seals with it, although that would sadden me). I'd also be happy to turn over the Sourceforge project over to anybody=20= interested. Matthias Neeracher |
|
From: Jack J. <Jac...@cw...> - 2004-11-15 08:55:19
|
On 15 Nov 2004, at 06:50, Matthias Neeracher wrote: > > On Nov 14, 2004, at 8:35 PM, Joshua Juran wrote: >> The list has been dormant for well over a year, and the CVS has been=20= >> inactive for almost two. Is this project dead, or just resting? > > An excellent question, and thanks for bringing it up! > > For a variety of reasons, I never did any Carbon development =96=A0I=20= > basically moved from Classic directly to Cocoa/BSD. Alexandre Parenteau did a Carbon port, with some help from me and a few=20= other people. It's in the CVS repository as tag CARBON-BRANCH. It's been used in MacPython for MacOS9 for years, so it should be=20 fairly stable (at least, in as far as Python exercises the parts). -- Jack Jansen, <Jac...@cw...>, http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma=20 Goldman |
|
From: Joshua J. <wan...@me...> - 2004-11-16 09:56:23
|
On Nov 15, 2004, at 12:50 AM, Matthias Neeracher wrote: > On Nov 14, 2004, at 8:35 PM, Joshua Juran wrote: >> The list has been dormant for well over a year, and the CVS has been=20= >> inactive for almost two. Is this project dead, or just resting? > > An excellent question, and thanks for bringing it up! Thanks for the quick response. > For a variety of reasons, I never did any Carbon development =96=A0I=20= > basically moved from Classic directly to Cocoa/BSD. I have no further=20= > plans with GUSI, but I definitely wouldn't want to stand in the way of=20= > anybody who wants to take the code forward in any way. The GUSI=20 > license should be liberal enough to permit pretty much any conceivable=20= > use (Including printing out the source code onto heavy paper stock and=20= > clubbing baby seals with it, although that would sadden me). SourceForge lists the zlib/libpng license for GUSI. I think it's even=20= GPL-compatible. > I'd also be happy to turn over the Sourceforge project over to anybody=20= > interested. I'm interested in and willing to contribute official support for Carbon=20= and shared library deployment. As maintainer, though, I would want to=20= make some significant changes. I found SIOUX difficult to work with. I would integrate GUSI with=20 Genie (my command shell app for OS 9) instead. Programs with a=20 command-line interface would be Genie plugins. Maybe I just haven't given it a chance, but I'm not fond of the=20 literate programming style. I'm quite comfortable with straight=20 source, and it's one less tool to maintain. I use templates rather than virtual methods where possible (i.e. for=20 static dispatch) I prefer to use Nitrogen <http://sourceforge.net/projects/nitric/>, a=20 C++ wrapper API for the Mac Toolbox. This would rule out weak=20 compilers like MrC. CodeWarrior Pro 6 (the last version to support 68K=20= development) is supported. I wonder if it makes sense to start a new project GUSI3. Josh --=20 Joshua Juran Metamage Software Creations - Mac Software and Consulting http://www.metamage.com/ * Creation at the highest state of the art * |
|
From: Matthias N. <nee...@ma...> - 2004-11-18 23:10:29
|
On Nov 16, 2004, at 1:56 AM, Joshua Juran wrote: >> I'd also be happy to turn over the Sourceforge project over to >> anybody interested. > > I'm interested in and willing to contribute official support for > Carbon and shared library deployment. As maintainer, though, I would > want to make some significant changes. That would definitely be your prerogative. My comments on the specific issues your raise are meant to be purely advisory, the decision would entirely be yours: > I found SIOUX difficult to work with. I would integrate GUSI with > Genie (my command shell app for OS 9) instead. Programs with a > command-line interface would be Genie plugins. That's an interesting idea. I think there would be value in supporting both kinds of console interface (The console interface in GUSI is somewhat modular, since it also has to support e.g. the MacPerl console). People testing a one-shot program may not want to learn Genie. > Maybe I just haven't given it a chance, but I'm not fond of the > literate programming style. I'm quite comfortable with straight > source, and it's one less tool to maintain. Yes, I think the LP style was one of the barriers to accessibility for other programmers (although arguably, GUSI 2 is somewhat better commented than GUSI 1, which might be due to LP). > I use templates rather than virtual methods where possible (i.e. for > static dispatch) > > I prefer to use Nitrogen <http://sourceforge.net/projects/nitric/>, a > C++ wrapper API for the Mac Toolbox. This would rule out weak > compilers like MrC. CodeWarrior Pro 6 (the last version to support > 68K development) is supported. I find that supporting a free set of development tools has considerable advantages, but it certainly wouldn't be unprecedented to go CW-only (which GUSI was a for several years in its existence). > I wonder if it makes sense to start a new project GUSI3. Yes. That's one of the points on which I have a somewhat stronger opinion: I'd prefer that you substantially bump the version number if the code changes in ways as significant as what you're discussing here. Matthias |
|
From: Joshua J. <wan...@me...> - 2004-11-19 00:55:17
|
On Nov 18, 2004, at 6:10 PM, Matthias Neeracher wrote: > On Nov 16, 2004, at 1:56 AM, Joshua Juran wrote: >>> I'd also be happy to turn over the Sourceforge project over to >>> anybody interested. >> >> I'm interested in and willing to contribute official support for >> Carbon and shared library deployment. As maintainer, though, I would >> want to make some significant changes. > > That would definitely be your prerogative. My comments on the specific > issues your raise are meant to be purely advisory, the decision would > entirely be yours: > >> I found SIOUX difficult to work with. I would integrate GUSI with >> Genie (my command shell app for OS 9) instead. Programs with a >> command-line interface would be Genie plugins. > > That's an interesting idea. I think there would be value in supporting > both kinds of console interface (The console interface in GUSI is > somewhat modular, since it also has to support e.g. the MacPerl > console). People testing a one-shot program may not want to learn > Genie. My objection is not general to all standalone console interfaces; rather that SIOUX had some default behavior I didn't care for (e.g. modal "Are you sure" dialog on quit) and I had difficulty correctly integrating it with GUSI when I ported TinyMUSH. Of course, that was almost a decade ago. My other thought is, why use a proprietary library when we can code something at least as good, if not better? Double-clicking a Genie plugin or script causes Genie to run it (with no arguments), opening a new window if any console I/O occurs. Genie's API is POSIX, as close as I can make it. That's about what you'd expect from a standalone console app. The current behavior resembles MacPerl droplets; if MacPerl-runtime-like deployment was desired, that would be possible too, either by grouping files together in a bundle (OS X) or package (OS 9), by installing a plugin fragment or script into a resource in the runtime, or by static linking the whole thing. In the next few weeks, I'll put some serious work into Genie's Web page, so I'm not the only one who knows what I'm talking about. :-) >> I use templates rather than virtual methods where possible (i.e. for >> static dispatch) >> >> I prefer to use Nitrogen <http://sourceforge.net/projects/nitric/>, a >> C++ wrapper API for the Mac Toolbox. This would rule out weak >> compilers like MrC. CodeWarrior Pro 6 (the last version to support >> 68K development) is supported. > > I find that supporting a free set of development tools has > considerable advantages, but it certainly wouldn't be unprecedented to > go CW-only (which GUSI was a for several years in its existence). GCC front-end compilers all compile to a platform-independent syntax tree. All we have to do is port g++ to Genie (or any other POSIXish environment for Mac OS *smirk*), run a back-end 'compiler' that produces standard C, feed that into an MPW-provided compiler, and Bob's your uncle. :-) I just checked: LLVM may do the trick of compiling C++ into C. The LLVM Compiler Infrastructure Project <http://llvm.cs.uiuc.edu/> >> I wonder if it makes sense to start a new project GUSI3. > > Yes. That's one of the points on which I have a somewhat stronger > opinion: I'd prefer that you substantially bump the version number if > the code changes in ways as significant as what you're discussing > here. GUSI Aleph Null? :-) Josh -- Joshua Juran Metamage Software Creations - Mac Software and Consulting http://www.metamage.com/ * Creation at the highest state of the art * |
Thanks for helping keep SourceForge clean.
X