From ktilton at nyc.rr.com Fri Oct 15 03:58:27 2004 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Thu, 14 Oct 2004 23:58:27 -0400 Subject: [cells-devel] Cello updates and... OS X or Bust!!!! Message-ID: <416F4AE3.9030906@nyc.rr.com> Just updated CVS with a long-needed refactoring of the key layout class hierarchy under IX-INLINE. Also added a new shape to the fancy Cello demo, the simple nurbs shape in the OpenGL Red Book. It turned out to be quite a poser because of my use of display lists. Kind of a gap in the OpenGL doc, but I got lucky and figured out what was going on. Turns out it is a frequent gotcha. Anyway, my once silent laptop now never shuts up, so it may be time to get a four-fan Mac desktop and start working there. I cannot tolerate Windows XP much longer anyway, as little as I interact with it. Gotta use my developer discount by November, too. And since I am starting on an educational software project, OS X compatibility is a little more urgent than would otherwise be the case. So whoop-dee-doo, Cello heads for OS X! kenny -- Cells? Cello? Celtik?: http://www.common-lisp.net/project/cells/ Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film From frank_goenninger at t-online.de Fri Oct 15 20:45:38 2004 From: frank_goenninger at t-online.de (Frank Goenninger) Date: Fri, 15 Oct 2004 22:45:38 +0200 Subject: [cells-devel] Cello updates and... OS X or Bust!!!! In-Reply-To: <416F4AE3.9030906@nyc.rr.com> References: <416F4AE3.9030906@nyc.rr.com> Message-ID: <1097873138.11350.8.camel@stargate.de.goenninger.com> Hi Kenny & all Cells/Cello fellows: On Fri, 2004-10-15 at 05:58, Kenny Tilton wrote: > Just updated CVS with a long-needed refactoring of the key layout class > hierarchy under IX-INLINE. > > Also added a new shape to the fancy Cello demo, the simple nurbs shape > in the OpenGL Red Book. It turned out to be quite a poser because of my > use of display lists. Kind of a gap in the OpenGL doc, but I got lucky > and figured out what was going on. Turns out it is a frequent gotcha. > Congrats! > Anyway, my once silent laptop now never shuts up, so it may be time to > get a four-fan Mac desktop and start working there. I cannot tolerate > Windows XP much longer anyway, as little as I interact with it. Gotta > use my developer discount by November, too. And since I am starting on > an educational software project, OS X compatibility is a little more > urgent than would otherwise be the case. > > So whoop-dee-doo, Cello heads for OS X! > Well, meanwhile I am a proud owner of a Powerbook with Mac OS X 10.3 Panther installed... I am now free to choose my computing environment as I quit my job at Deloitte Consulting to open up my own company: PRION Consulting Services AG: PLM and IT Management Consulting (Ok, enough marketing blah-blah) Obvious thing to do is expand my knowledge concerning Common Lisp to the OS X platform under OpenMCL. I already began configuring ASDF et al to have the foundation ready for my next adventure: Cello! I downloaded the Cells package via ASDF-INSTALL but just got the Cells package only, with no Cello in it (and it also seems somewhat outdated). Do I have to go to CVS checking it out manually or do you plan to make a recent release of Cells including Cello available for ASDF-INSTALL ? Thx for info. Happy hacking! > kenny Cheers Kenny, Frank -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From tfb at OCF.Berkeley.EDU Sun Oct 17 20:20:03 2004 From: tfb at OCF.Berkeley.EDU (Thomas F. Burdick) Date: Sun, 17 Oct 2004 13:20:03 -0700 Subject: [cells-devel] Cello updates and... OS X or Bust!!!! In-Reply-To: <416F4AE3.9030906@nyc.rr.com> References: <416F4AE3.9030906@nyc.rr.com> Message-ID: <16754.54259.232880.394484@conquest.OCF.Berkeley.EDU> Kenny Tilton writes: > Just updated CVS with a long-needed refactoring of the key layout class > hierarchy under IX-INLINE. > > Also added a new shape to the fancy Cello demo, the simple nurbs shape > in the OpenGL Red Book. It turned out to be quite a poser because of my > use of display lists. Kind of a gap in the OpenGL doc, but I got lucky > and figured out what was going on. Turns out it is a frequent gotcha. > > Anyway, my once silent laptop now never shuts up, so it may be time to > get a four-fan Mac desktop and start working there. I cannot tolerate > Windows XP much longer anyway, as little as I interact with it. Gotta > use my developer discount by November, too. And since I am starting on > an educational software project, OS X compatibility is a little more > urgent than would otherwise be the case. > > So whoop-dee-doo, Cello heads for OS X! Cool. What dev environment are you using over here? You mentioned on cll something about there being an aspect of asdf that you couldn't abide -- since you're now in the world of no-Allegro-IDE, what would that be? From tfb at OCF.Berkeley.EDU Sun Oct 17 20:43:29 2004 From: tfb at OCF.Berkeley.EDU (Thomas F. Burdick) Date: Sun, 17 Oct 2004 13:43:29 -0700 Subject: [cells-devel] Cello updates and... OS X or Bust!!!! In-Reply-To: <1097873138.11350.8.camel@stargate.de.goenninger.com> References: <416F4AE3.9030906@nyc.rr.com> <1097873138.11350.8.camel@stargate.de.goenninger.com> Message-ID: <16754.55665.439068.825621@conquest.OCF.Berkeley.EDU> Frank Goenninger writes: > I downloaded the Cells package via ASDF-INSTALL but just got the Cells > package only, with no Cello in it (and it also seems somewhat outdated). Yeah, that's Cells-I, and just happens to be the version used by a web app I wrote for a client (how convenient). Cello has never been asdf-install'able. > Do I have to go to CVS checking it out manually or do you plan to make a > recent release of Cells including Cello available for ASDF-INSTALL ? At the moment, you should check it out of cvs. Making the cell-cultures projects installable piecemeal will involve more hacking on asdf-aclproj because their interdependencies are specified with relative pathnames, rather than symbolically. Unless someone has a need to use asdf-install instead of cvs, I'll wait on this until either Cello is generally usable on OS X, or I get around to finishing Spider-Cell (a library to make Araneida Cells-friendly). Kenny uses the Allegro IDE, I use SBCL, so the asdf-related stuff is my fault. From ktilton at nyc.rr.com Mon Oct 18 05:55:13 2004 From: ktilton at nyc.rr.com (Kenneth Tilton) Date: Mon, 18 Oct 2004 01:55:13 -0400 Subject: [cells-devel] Cello updates and... OS X or Bust!!!! In-Reply-To: <16754.54259.232880.394484@conquest.OCF.Berkeley.EDU> References: <416F4AE3.9030906@nyc.rr.com> <16754.54259.232880.394484@conquest.OCF.Berkeley.EDU> Message-ID: <47070B47-20CA-11D9-8A12-00039387EA7A@nyc.rr.com> On Oct 17, 2004, at 4:20 PM, Thomas F. Burdick wrote: > Kenny Tilton writes: >> >> So whoop-dee-doo, Cello heads for OS X! > > Cool. What dev environment are you using over here? Undecided. Probably Lispworks, but Frank is doing OpneMCL, so I /might/ look at that to make collaboration easier. otoh, it would be sweet filling in two checkboxes on the OS x Implementation grid. Right now I am just running Fink Commander to see how far I can get with the libs. Looked like a quick win until I got some really embarrassing (for open source or fink) errors on ImageMagick. But the gaffes look manageable. > You mentioned on > cll something about there being an aspect of asdf that you couldn't > abide -- since you're now in the world of no-Allegro-IDE, what would > that be? > You probably will remember: the ACL project manager loads everything in the order the source is listed. When it gets to something out of date, it recompiles. Both ASDF and mk::defsystem first look for things out of date and try to recompile (tho dependencies are honored). I like the ACL approach because I can handle some dependencies via the order of the files. I can see the advantage of the other approach (auto handling of changes to macros), but having tried to adjust to the asdf/mk way I still find myself longing for the acl way. But I might come around on this some day. kt From ktilton at nyc.rr.com Mon Oct 18 09:37:13 2004 From: ktilton at nyc.rr.com (Kenneth Tilton) Date: Mon, 18 Oct 2004 05:37:13 -0400 Subject: [cells-devel] X11 conflict building ImageMagick Message-ID: <4A51C90D-20E9-11D9-A380-00039387EA7A@nyc.rr.com> I took all the defaults building ImageMagick via Fink Commander. It got upset because: Unpacking xfree86 (from .../xfree86_4.3.99.16-2_darwin-powerpc.deb) ... WARNING: if you compile X11 applications against this XFree86 release, you will *not* be able to run them if you decide to revert to Apple's X11 provided with Panther. You have an existing X11 installation in /usr/X11R6 and/or /etc/X11. This package refuses to overwrite these. Remove them, then tell Fink to install xfree86 again. (The package won't be recompiled.) If you want to keep your X11 installation, install system-xfree86 resp. system-xtools instead to make this known to Fink's package system. Press Return to continue. dpkg: error processing /sw/fink/dists/stable/main/binary-darwin-powerpc/x11-system/ xfree86_4.3.99.16-2_darwin-powerpc.deb (--install): subprocess pre-installation script returned error exit status 1 Unpacking xfree86-shlibs (from .../xfree86-shlibs_4.3.99.16-2_darwin-powerpc.deb) ... You have an existing X11 installation in /usr/X11R6/lib. This package refuses to overwrite these. Remove them, then tell Fink to install xfree86-shlibs again. (The package won't be recompiled.) -------------------------------- Well, at least the messages are detailed and try to be helpful. But I am left with a number of questions. Jeez. I have to throw out one X11 installation to install xfree86? Well, the first error above says I can "install system-xfree86 resp. system-xtools", but the second error says X11 must be removed. Now my guess would be to stick with Apple's own X11. Should I override the default when the ImageMagick build asks if I want to build the xfree86 dependency? If not, should I remove X11, or install system-xfree86? If the latter, what the hell does "resp. system-xtools" mean, and what made them think they could not spell out the word beginning "resp.". :) I am assuming the second error message was faulty in saying X11 had to be removed, and that the system-xfree86 install will clear that conflict as well. kt -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 2068 bytes Desc: not available URL: From ktilton at nyc.rr.com Mon Oct 18 17:16:42 2004 From: ktilton at nyc.rr.com (Kenneth Tilton) Date: Mon, 18 Oct 2004 13:16:42 -0400 Subject: [cells-devel] Building (and patching) FTGL In-Reply-To: <9CFF5D51-2110-11D9-8180-000393A7F304@gmx.de> References: <4A51C90D-20E9-11D9-A380-00039387EA7A@nyc.rr.com> <85031FC4-20FD-11D9-A380-00039387EA7A@nyc.rr.com> <9CFF5D51-2110-11D9-8180-000393A7F304@gmx.de> Message-ID: <7AE4EB86-2129-11D9-A380-00039387EA7A@nyc.rr.com> On Oct 18, 2004, at 10:18 AM, Mark Sapa wrote: > Ehhhm... As to the Project Builder stuff: I am completely naive to PB, > but at the moment > I am trying to get FTGL to work. First, it seems I have to install > cppunit for that... :( > > So far my approach to adding the includes and the library has been to > select libftgl.a > in the "Targets" Group, selecting the editor tool, selecting "Search > Paths" and then doing > the obvious thing in the Headers, Libraries, etc. subcategories. > Fantastic, it worked. And using Project Builder, which helps because I have never spent much time on Unix/Linux and I hope to avoid mastering all that as long as possible. > The funk seems to be that the Project file is expecting the header > file names to be all > UPPERCASE with _subscores_ as in > >> #include FT_GLYPH_H > > where in my /sw/lib/freetype2/include/freetype2/freetype/ > there is a ftglyph.h. > > Maybe if someone was diligent enough to fix all this... ;-) I see that funny #include, but the build error I was getting mentioned "ft2build.h" and once I added a path to that and another path to the slightly deeper freetype2 directory project builder was able to build everything. btw, I mentioned to Frank a fix to FTGL which apparently is still in testing in an upcoming FTGL 2.1. Here it is. In FTTextureGlyph.cpp, in the Render method, modify the first few lines to look like this: float FTTextureGlyph::Render( const FTPoint& pen) { //glGetIntegerv( GL_TEXTURE_2D_BINDING_EXT, &activeTextureID); //if( activeTextureID != glTextureID) //{ glBindTexture( GL_TEXTURE_2D, (GLuint)glTextureID); //} ...etc.... The original tried to avoid binding the texture if it was already the bound texture, but when one builds a display list this cannot work, because all the glGet calls run immediately instead of being added to the display list. But the glBindTexture call just gets compiled and does not execute. So glget in this case just returns whatever texture happens to be bound during the display list compilation (rather random, that). Besides, display lists just include opengl calls, so there is no way to build a display list which branches conditionally based on runtime values. A better fix might be to have the application keep track of the last texture bound during display list compilation, but the FTGL author just went for always binding the texture. My guess is there is no cost if one happens to be rebinding the same texture. Meanwhile, Doh! I just remembered I have to add my FTGLFromC.cpp suite of glue routines to FTGL so Lisp can talk to FTGL in "C". This could be a little trickier because we also have to publish the new entry points. kenny -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 3030 bytes Desc: not available URL: From ktilton at nyc.rr.com Mon Oct 18 22:09:33 2004 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Mon, 18 Oct 2004 18:09:33 -0400 Subject: [cells-devel] Emailing: fgc.def, FTGLFromC.cpp Message-ID: <41743F1D.5060908@nyc.rr.com> OK, I just got my groovy Apple flat-panel monitor today and learned my G5 has shipped, due here Friday. I am taking a break from the joys of PowerBuilder to re-execute the port to Lispworks on win32. That usually flushes a couple of FFI differences, and I would rather get those resolved before attempting the LW+OSX port. The good news for others is that this will force me to make sure an ASDF build works, if only via Thomas Burdicks cool ASDF-ACLPROJ work. Meanwhile, attached is the glue code for FTGL should anyone get that far. (There is a copy of the cpp file in the CVS tree, but it is not current.) The .def file is necessary for VC6 to set up DLLs so apps can find the entry points. I do not know if such a beast is necessary for .SO files. kt -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: fgc.def URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: FTGLFromC.cpp URL: From tfb at OCF.Berkeley.EDU Mon Oct 18 23:46:57 2004 From: tfb at OCF.Berkeley.EDU (Thomas F. Burdick) Date: Mon, 18 Oct 2004 16:46:57 -0700 Subject: [cells-devel] Cello updates and... OS X or Bust!!!! In-Reply-To: <47070B47-20CA-11D9-8A12-00039387EA7A@nyc.rr.com> References: <416F4AE3.9030906@nyc.rr.com> <16754.54259.232880.394484@conquest.OCF.Berkeley.EDU> <47070B47-20CA-11D9-8A12-00039387EA7A@nyc.rr.com> Message-ID: <16756.22001.348604.60471@conquest.OCF.Berkeley.EDU> Kenneth Tilton writes: > > On Oct 17, 2004, at 4:20 PM, Thomas F. Burdick wrote: > > > You mentioned on > > cll something about there being an aspect of asdf that you couldn't > > abide -- since you're now in the world of no-Allegro-IDE, what would > > that be? > > You probably will remember: the ACL project manager loads everything in > the order the source is listed. When it gets to something out of date, > it recompiles. Both ASDF and mk::defsystem first look for things out of > date and try to recompile (tho dependencies are honored). > > I like the ACL approach because I can handle some dependencies via the > order of the files. I can see the advantage of the other approach (auto > handling of changes to macros), but having tried to adjust to the > asdf/mk way I still find myself longing for the acl way. But I might > come around on this some day. Oh yeah, that. You can definately coerce asdf into doing it the acl way. I'm pretty sure I didn't do that for asdf-aclproj, but I thought about it and decided it was doable. From tfb at OCF.Berkeley.EDU Tue Oct 19 00:00:37 2004 From: tfb at OCF.Berkeley.EDU (Thomas F. Burdick) Date: Mon, 18 Oct 2004 17:00:37 -0700 Subject: [cells-devel] X11 conflict building ImageMagick In-Reply-To: <4A51C90D-20E9-11D9-A380-00039387EA7A@nyc.rr.com> References: <4A51C90D-20E9-11D9-A380-00039387EA7A@nyc.rr.com> Message-ID: <16756.22821.918601.250954@conquest.OCF.Berkeley.EDU> Ahem. As a non-fan of fink, I'd recommend compiling ImageMagick yourself (that's what I did). But, if you stick with fink, don't install xfree86, use Apple's. If you tell it to ignore the X11 dependancy, it *should* find the installed X11 when configuring ImageMagick. If not, I'd use fink to install all the other libraries you want, but do IM by hand (it's a simple matter of "./configure && make && make install"). (Speaking of library problems, why won't Boost build on my OS X system?!?!) From ktilton at nyc.rr.com Tue Oct 19 00:03:23 2004 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Mon, 18 Oct 2004 20:03:23 -0400 Subject: [cells-devel] Cello updates and... OS X or Bust!!!! In-Reply-To: <16756.22001.348604.60471@conquest.OCF.Berkeley.EDU> References: <416F4AE3.9030906@nyc.rr.com> <16754.54259.232880.394484@conquest.OCF.Berkeley.EDU> <47070B47-20CA-11D9-8A12-00039387EA7A@nyc.rr.com> <16756.22001.348604.60471@conquest.OCF.Berkeley.EDU> Message-ID: <417459CB.2040405@nyc.rr.com> Thomas F. Burdick wrote: >Kenneth Tilton writes: > > >> I like the ACL approach because I can handle some dependencies via the > > order of the files. I can see the advantage of the other approach (auto > > handling of changes to macros), but having tried to adjust to the > > asdf/mk way I still find myself longing for the acl way. But I might > > come around on this some day. > >Oh yeah, that. You can definately coerce asdf into doing it the acl >way. I'm pretty sure I didn't do that for asdf-aclproj, but I thought >about it and decided it was doable. > > > aw, shucks, having macro changes propagated automatically will be a clear win. let me suck it up and get the asd files working honestly (no bogus depending on the one immediately prior). might even clean things up if I end up moving a stray macro to where it should be. fair warning to everyone, tho: if I miss a dependency it will not show up immediately since the first time thru everything is .... hey, how about if I deliberately reverse the order in the asd file from the lpr file? I scare myself sometimes. :) kt -- Cells? Cello? Celtik?: http://www.common-lisp.net/project/cells/ Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film From ktilton at nyc.rr.com Tue Oct 19 00:11:35 2004 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Mon, 18 Oct 2004 20:11:35 -0400 Subject: [cells-devel] X11 conflict building ImageMagick In-Reply-To: <16756.22821.918601.250954@conquest.OCF.Berkeley.EDU> References: <4A51C90D-20E9-11D9-A380-00039387EA7A@nyc.rr.com> <16756.22821.918601.250954@conquest.OCF.Berkeley.EDU> Message-ID: <41745BB7.5030006@nyc.rr.com> Thomas F. Burdick wrote: >Ahem. As a non-fan of fink, > Just when Fink Commander was making me fall in love with open source and *nix! > I'd recommend compiling ImageMagick >yourself (that's what I did). But, if you stick with fink, don't >install xfree86, use Apple's. > Check big time. Their X11 is Aqua-friendly, yes? I went with the imagemagick-nox package, and selected the option ghostscript-nox. Love those names. Not. :) Then Mark (?) recommended system-x11, which I think was meant to be system-xfree86 since the doc for that says it will simply satisfy any dependency on xfree86. Sadly, Fink Commander tells me there is nothing to install. But does not show it as installed. kt -- Cells? Cello? Celtik?: http://www.common-lisp.net/project/cells/ Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film From moerk at gmx.de Tue Oct 19 00:55:52 2004 From: moerk at gmx.de (Mark Sapa) Date: Tue, 19 Oct 2004 02:55:52 +0200 Subject: [cells-devel] X11 conflict building ImageMagick In-Reply-To: <41745BB7.5030006@nyc.rr.com> References: <4A51C90D-20E9-11D9-A380-00039387EA7A@nyc.rr.com> <16756.22821.918601.250954@conquest.OCF.Berkeley.EDU> <41745BB7.5030006@nyc.rr.com> Message-ID: Hey there, Am 19.10.2004 um 02:11 schrieb Kenny Tilton: > > Check big time. Their X11 is Aqua-friendly, yes? > Yep. Sort of. You Do have Apples X11 installed, yes? > I went with the imagemagick-nox package, and selected the option > ghostscript-nox. Love those names. Not. :) > > Then Mark (?) recommended system-x11, which I think was meant to be > system-xfree86 since the doc for that says it will simply satisfy any > dependency on xfree86. Sadly, Fink Commander tells me there is nothing > to install. But does not show it as installed. > Yes, sorry, I was referring to system-xfree86, along with -dev and -shlibs. And FinkCommander, for all its Cocoalicious glory, seems to have a problem with showing the correct status of system- packages. Do a "fink list system" in the Terminal. That shows, amongst others, on my system: > system-viha 0.0.1a-3 Placeholder for Viha WiFi framework > i system-xfree86 2:4.3-2 [placeholder for user installed x11] > i system-xfree... 2:4.3-2 [placeholder for user installed x11 > devel... > i system-xfree... 2:4.3-2 [placeholder for user installed x11 > share... > xdvi-system-... 22.78-1 Display dvi files under X11 > (system-tetex... Even when FinkCommander claims the stuff is not installed. :| Cheers, Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 824 bytes Desc: Signierter Teil der Nachricht URL: From ktilton at nyc.rr.com Tue Oct 19 03:16:25 2004 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Mon, 18 Oct 2004 23:16:25 -0400 Subject: [cells-devel] X11 conflict building ImageMagick In-Reply-To: References: <4A51C90D-20E9-11D9-A380-00039387EA7A@nyc.rr.com> <16756.22821.918601.250954@conquest.OCF.Berkeley.EDU> <41745BB7.5030006@nyc.rr.com> Message-ID: <41748709.1040402@nyc.rr.com> Mark Sapa wrote: > packages. Do a "fink list system" in the Terminal. That shows, amongst > others, on my system: > >> system-viha 0.0.1a-3 Placeholder for Viha WiFi framework >> i system-xfree86 2:4.3-2 [placeholder for user installed x11] >> i system-xfree... 2:4.3-2 [placeholder for user installed >> x11 devel... >> i system-xfree... 2:4.3-2 [placeholder for user installed >> x11 share... > Cool. Got it all. Thx again. kt From cells-devel at common-lisp.net Thu Oct 21 15:21:10 2004 From: cells-devel at common-lisp.net (Abigail Gretzky) Date: Thu, 21 Oct 2004 09:21:10 -0600 Subject: [cells-devel] Help is on the way! Message-ID: <09b401c4b782$680ae8d0$a283a9cc@Rick> Get codeine! http://galdiobover.com/33/5/index.php?aiw90&com0 RNH815k0QQxIAe3p7e1Would I please come and do something about it?You know what? I just can't do this anymore!Men can becuase we like it.662332177 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ktilton at nyc.rr.com Thu Oct 21 17:31:05 2004 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Thu, 21 Oct 2004 13:31:05 -0400 Subject: [cells-devel] What should I do with JPGs and GIFs? Message-ID: <4177F259.7070307@nyc.rr.com> I hear CVS cannot/should not/whatever handle JPGs, GIFs, or other binary formats. Is that a stringent no-no? I just want to include a couple in the tree so downloads are as painless as possible. If it Just Won't Work, is there any standard workaround? These two do not now even reside in the same subdirectory, so something like a separate directory for binaries (to be unpacked from an FTP zip) would really make a mess of things. kt ps. This all came up because I am refactoring the existing config logic by which I hope to simplify tracking cell-cultures by CVS while at the same time configuring as necessary to site-specific requirments. -- Cells? Cello? Celtik?: http://www.common-lisp.net/project/cells/ Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film From michael at naunton.us Thu Oct 21 17:49:55 2004 From: michael at naunton.us (Michael Naunton) Date: Thu, 21 Oct 2004 17:49:55 -0000 Subject: [cells-devel] What should I do with JPGs and GIFs? In-Reply-To: <4177F259.7070307@nyc.rr.com> References: <4177F259.7070307@nyc.rr.com> Message-ID: <1098382011.14641.51.camel@micron> what's wrong with 'cvs add -kb files'? On Thu, 2004-10-21 at 13:31, Kenny Tilton wrote: > I hear CVS cannot/should not/whatever handle JPGs, GIFs, or other binary > formats. Is that a stringent no-no? I just want to include a couple in > the tree so downloads are as painless as possible. > > If it Just Won't Work, is there any standard workaround? These two do > not now even reside in the same subdirectory, so something like a > separate directory for binaries (to be unpacked from an FTP zip) would > really make a mess of things. > > kt > > ps. This all came up because I am refactoring the existing config logic > by which I hope to simplify tracking cell-cultures by CVS while at the > same time configuring as necessary to site-specific requirments. > > -- > Cells? Cello? Celtik?: http://www.common-lisp.net/project/cells/ > Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film > > > > _______________________________________________ > cells-devel site list > cells-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/cells-devel From ktilton at nyc.rr.com Thu Oct 21 18:14:32 2004 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Thu, 21 Oct 2004 14:14:32 -0400 Subject: [cells-devel] What should I do with JPGs and GIFs? In-Reply-To: <1098382011.14641.51.camel@micron> References: <4177F259.7070307@nyc.rr.com> <1098382011.14641.51.camel@micron> Message-ID: <4177FC88.8050305@nyc.rr.com> Michael Naunton wrote: >what's wrong with 'cvs add -kb files'? > probably nothing. i was aware of the option, but also recall a warning at some point from someone about not using CVS for binaries and wanted to check with youse experts before possibly making a mess of things. i'll give it a go. thx, kenny From frank_goenninger at t-online.de Thu Oct 21 18:28:27 2004 From: frank_goenninger at t-online.de (Frank Goenninger) Date: Thu, 21 Oct 2004 20:28:27 +0200 Subject: [cells-devel] What should I do with JPGs and GIFs? In-Reply-To: <4177FC88.8050305@nyc.rr.com> References: <4177F259.7070307@nyc.rr.com> <1098382011.14641.51.camel@micron> <4177FC88.8050305@nyc.rr.com> Message-ID: <1098383293.3814.3573.camel@stargate.de.goenninger.com> Hi all: If the problem persists (you never know for sure): I used the 'shar' command on Unixes to convert binary files into an ASCII representation. This creates a self-extratable file: > shar file > file.shar Just do a > sh file.shar and you will get the original file. Frank On Thu, 2004-10-21 at 20:14, Kenny Tilton wrote: > Michael Naunton wrote: > > >what's wrong with 'cvs add -kb files'? > > > probably nothing. i was aware of the option, but also recall a warning > at some point from someone about not using CVS for binaries and wanted > to check with youse experts before possibly making a mess of things. > i'll give it a go. > > thx, kenny > > > > _______________________________________________ > cells-devel site list > cells-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/cells-devel > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From gak at pobox.com Thu Oct 21 18:36:49 2004 From: gak at pobox.com (Gary Klimowicz) Date: Thu, 21 Oct 2004 11:36:49 -0700 Subject: [cells-devel] What should I do with JPGs and GIFs? In-Reply-To: <4177FC88.8050305@nyc.rr.com> Message-ID: <20041021183651.37AA627E10@gold.sasl.smtp.pobox.com> The real issue with binaries and CVS (and most other source management systems) is their difficulty in managing revisions to the binaries. If you want to just add some binary files without much intention of revising them repeatedly, you should be fine. -- gak -----Original Message----- From: cells-devel-bounces at common-lisp.net [mailto:cells-devel-bounces at common-lisp.net] On Behalf Of Kenny Tilton Sent: Thursday, October 21, 2004 11:15 AM To: Michael Naunton Cc: cells-devel Subject: Re: [cells-devel] What should I do with JPGs and GIFs? Michael Naunton wrote: >what's wrong with 'cvs add -kb files'? > probably nothing. i was aware of the option, but also recall a warning at some point from someone about not using CVS for binaries and wanted to check with youse experts before possibly making a mess of things. i'll give it a go. thx, kenny _______________________________________________ cells-devel site list cells-devel at common-lisp.net http://common-lisp.net/mailman/listinfo/cells-devel From hutch at recursive.ca Thu Oct 21 18:50:13 2004 From: hutch at recursive.ca (Bob Hutchison) Date: Thu, 21 Oct 2004 14:50:13 -0400 Subject: [cells-devel] What should I do with JPGs and GIFs? In-Reply-To: <20041021183651.37AA627E10@gold.sasl.smtp.pobox.com> References: <20041021183651.37AA627E10@gold.sasl.smtp.pobox.com> Message-ID: <0A95B9C4-2392-11D9-B38E-000A95728F12@recursive.ca> We put binaries into CVS all the time. Don't really have much of a choice. There are some catches: 1) you have to use the -kb flag or set up CVS to automatically treat some files as binary. This is done in the cvswrappers file in CVSROOT (check it out and use CVS to manage it). Part of the 'generic' bits of our cvswrappers file looks like: *.jar -k 'b' *.gif -k 'b' *.jpg -k 'b' *.png -k 'b' *.zip -k 'b' *.gz -k 'b' *.tar -k 'b' *.tgz -k 'b' *.pdf -k 'b' *.bz2 -k 'b' *.bz -k 'b' *.z -k 'b' *.doc -k 'b' *.ser -k 'b' 2) CVS won't store differences between versions, it stores the whole thing. This can chew up disk space. 3) A consequence of 2) is that you can get nasty behaviour going on with multiple people checking in changes (net effect is that you don't get very good control over these binary files with CVS). You have to manually (as far as I know) lock and unlock the file to prevent the problems. Cheers, Bob On Oct 21, 2004, at 2:36 PM, Gary Klimowicz wrote: > The real issue with binaries and CVS (and most other source management > systems) is their difficulty in managing revisions to the binaries. If > you > want to just add some binary files without much intention of revising > them > repeatedly, you should be fine. > > -- > gak > > -----Original Message----- > From: cells-devel-bounces at common-lisp.net > [mailto:cells-devel-bounces at common-lisp.net] On Behalf Of Kenny Tilton > Sent: Thursday, October 21, 2004 11:15 AM > To: Michael Naunton > Cc: cells-devel > Subject: Re: [cells-devel] What should I do with JPGs and GIFs? > > > > Michael Naunton wrote: > >> what's wrong with 'cvs add -kb files'? >> > probably nothing. i was aware of the option, but also recall a warning > at > some point from someone about not using CVS for binaries and wanted to > check > with youse experts before possibly making a mess of things. > i'll give it a go. > > thx, kenny > > > > _______________________________________________ > cells-devel site list > cells-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/cells-devel > > > _______________________________________________ > cells-devel site list > cells-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/cells-devel > From frank_goenninger at t-online.de Sat Oct 23 21:49:03 2004 From: frank_goenninger at t-online.de (Frank Goenninger) Date: Sat, 23 Oct 2004 23:49:03 +0200 Subject: [cells-devel] Re: I'm stuck ... pse help! In-Reply-To: <1098563007.1655.63.camel@stargate.de.goenninger.com> References: <416F4AE3.9030906@nyc.rr.com> <16754.54259.232880.394484@conquest.OCF.Berkeley.EDU> <47070B47-20CA-11D9-8A12-00039387EA7A@nyc.rr.com> <16756.22001.348604.60471@conquest.OCF.Berkeley.EDU> <1098563007.1655.63.camel@stargate.de.goenninger.com> Message-ID: <1098568143.15983.5.camel@stargate.de.goenninger.com> Hi again: I tried to work around the error in my previous email by simply commenting out the source line in question. No I cannot get past the call to 'glut-create-window : When I use the original code in function 'lesson-14 that provides a window title using uffi:with-cstring OpenMCL decides to die without even telling me or SLIME. I then went on to call 'glut-create-window as in (glut-create-window nil) but that obviously also does not work because "value NIL is not of the exptected type MACPTR". While this is just a question of digging into the OpenMCL specifcs of UFFI and also finding out about MACPTRs in OpenMCL I thought it's better to check if you have a solution for this already. See ya, guys. Frank On Sat, 2004-10-23 at 22:23, Frank Goenninger wrote: > Hi all: > > I'm stuck. I tried to understand what SLIME, OpenMCL and the cl-opencl > source want to tell me. Somehow this is beyond my ability to Just Get > It. > > Where I'm stuck: > > Getting glut-functions.lisp to use function 'glut-set-option which > apparently is not in Apple's GLUT. > > Of course I had to make some changes to various sources: > > Notably I found that OpenMCL does not need to use a CLOS package because > this is already built-in and accessable in the CL-USER package. Hell, > why is there no CLOS entry in the OpenMCL docs ?! > > Ehem, Kenny, I found a > > /* stencils */ > > in the gl-functions.lisp file. Where did that come from? I changed this > to use #| and |# as comment delimiters. Well, now it's fixed ;-) > > ImageMagick and FTGL also work now on Mac OS X for me. I also modified > the Imakefile in the ftgl-int directory to build a dynamic library on OS > X. So that's working also with the test program being available. > > Back to what's not working > > The error I get is: > > Can't resolve foreign symbol "_glutSetOption" > > For detailed info pls see the attached PDF file - a screen dump showing > Emacs with a backtrace. > > Also, I attached the files I changed in a tar file so you can follow my > adaptions. > > I used "nm" and "otool" on OS X to track down the glutSetOption thingy > but with no luck. > > So, my question is: > > How did you do it ???? > > Thx for any help. > > Cheers, > Frank > > > > > > > > > From ktilton at nyc.rr.com Sat Oct 23 22:28:12 2004 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Sat, 23 Oct 2004 18:28:12 -0400 Subject: [cells-devel] [Fwd: Re: [Fwd: I'm stuck ... pse help!]] Message-ID: <417ADAFC.7080504@nyc.rr.com> -------- Original Message -------- Subject: Re: [Fwd: I'm stuck ... pse help!] Date: Sat, 23 Oct 2004 18:27:15 -0400 From: Kenny Tilton To: frank_goenninger at t-online.de References: <1098563096.1653.66.camel at stargate.de.goenninger.com> Frank Goenninger wrote: >Where I'm stuck: > >Getting glut-functions.lisp to use function 'glut-set-option which >apparently is not in Apple's GLUT. > Not a problem! We need to put a #+FREEGLUT feature on any glut-set-option call, or anything else corresponding to the FG way of fixing the Glut problem with closing windows. Apple's fix was to specify a new callback, glutWMCloseFunc. We have to supply that callback to avoid the standard Glut behavior of calling exit() when a window closes, cuz that would also close the Lisp IDE after each test run. I have to do some research to find out what we should do inside our glutWMCloseFunc -- maybe nothing, maybe call glutDestroyWindow, maybe just do our Lisp housekeeping for window closes. > >Of course I had to make some changes to various sources: > >Notably I found that OpenMCL does not need to use a CLOS package because >this is already built-in and accessable in the CL-USER package. > Ah, yes, sounds familiar. > Hell, >why is there no CLOS entry in the OpenMCL docs ?! > >Ehem, Kenny, I found a > >/* stencils */ > >in the gl-functions.lisp file. Where did that come from? I changed this >to use #| and |# as comment delimiters. Well, now it's fixed ;-) > yeah, that was the right thing to do. I do not know why ACL and LW have not complained about that. > >ImageMagick and FTGL also work now on Mac OS X for me. I also modified >the Imakefile in the ftgl-int directory to build a dynamic library on OS >X. So that's working also with the test program being available. > >Back to what's not working > >The error I get is: > >Can't resolve foreign symbol "_glutSetOption" > >For detailed info pls see the attached PDF file - a screen dump showing >Emacs with a backtrace. > >Also, I attached the files I changed in a tar file so you can follow my >adaptions. > >I used "nm" and "otool" on OS X to track down the glutSetOption thingy >but with no luck. > >So, my question is: > >How did you do it ???? > ?? Is it possible I have misled you into thinking I have anything working on OS X? If so, sorry. No, all I have done is use Freeglut on win32 (and you got it working on Linux!) so fair warning: as I feared (and hoped!) you got to these Apple Glut differences before I did and are bearing the brunt. I will try to stop playing with my new G5 and help. :) More on glutWMCloseFunc ASAP...ok, here goes: Apple Glut doc says they copied Rob Fletcher's Glut fixes. Here is Rob: http://www-users.york.ac.uk/~rpf1/glut.html In there he offers WMTest.c, which I see works as I suspected: provide a callback that does nothing. So I think all we have to do is duplicate this line of code in glut-callbacks-set: (glut-callback-set 'glut-close-func close) #-FREEGLUT (glut-callback-set 'glut-wm-close-func close) I guess a danger is that both might get called under Apple's, in which case just put a #-FREEGLUT on the glut-close-func call. #+FREEGLUT (glut-callback-set 'glut-close-func close) #-FREEGLUT (glut-callback-set 'glut-wm-close-func close) btw, the (ogl::lesson-14) test requires only gl, glu and glut to run, not FTGL or ImageMagick -- it uses the limited built-in glut fonts. congrats again on the (usual ) rapid progress. now back to my G5! :) kt -- Cells? Cello? Celtik?: http://www.common-lisp.net/project/cells/ Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film -- Cells? Cello? Celtik?: http://www.common-lisp.net/project/cells/ Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film From ktilton at nyc.rr.com Sun Oct 24 01:05:24 2004 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Sat, 23 Oct 2004 21:05:24 -0400 Subject: [cells-devel] [Fwd: Re: [Fwd: I'm stuck ... pse help!]] In-Reply-To: <417ADAFC.7080504@nyc.rr.com> References: <417ADAFC.7080504@nyc.rr.com> Message-ID: <417AFFD4.1040206@nyc.rr.com> I just want to clarify a small mis-impression I created: > Apple Glut doc says they copied Rob Fletcher's Glut fixes. Here is Rob: > > http://www-users.york.ac.uk/~rpf1/glut.html > > In there he offers WMTest.c, which I see works as I suspected: provide > a callback that does nothing. So I think all we have to do is > duplicate this line of code in glut-callbacks-set: > > (glut-callback-set 'glut-close-func close) > #-FREEGLUT > (glut-callback-set 'glut-wm-close-func close) this is fine, but just in case I might have caused some confusion: Fletcher responded to wm-close by doing nothing. We respond to wm-close by losing the CLOS window instance corresponding to the Glut window, /not/ by doing nothing. What I meant was that simply providing a wm-close callback defeats the Glut default of calling exit(), which would nail the Lisp IDE as well. kt From frank_goenninger at t-online.de Sun Oct 24 15:35:43 2004 From: frank_goenninger at t-online.de (Frank Goenninger) Date: Sun, 24 Oct 2004 17:35:43 +0200 Subject: [cells-devel] [Fwd: Re: [Fwd: I'm stuck ... pse help!]] In-Reply-To: <417AFFD4.1040206@nyc.rr.com> References: <417ADAFC.7080504@nyc.rr.com> <417AFFD4.1040206@nyc.rr.com> Message-ID: <1098632143.2287.4.camel@stargate.de.goenninger.com> Hi Kenny, thx for the inputs on the window close issue. Unfortunately, I'm not getting this far. It seems it was unclear from my previous emails that I do not get any window even appearing! Any call to the glut-create-window function makes OpenMCL die, yes, really die! The process is interrupted without any signs or hints on the cause. So, I think I might also ask the OpenMCL developers list on that one. I think it's not entirely clear if that's an OpenGL or GLUT or OpenMCL problem. Question is how to make OpenMCL more verbose on when calling FFI land... Any suggestions? Thx! Cheers! Frank From ktilton at nyc.rr.com Sun Oct 24 18:18:43 2004 From: ktilton at nyc.rr.com (Kenneth Tilton) Date: Sun, 24 Oct 2004 14:18:43 -0400 Subject: [cells-devel] [Fwd: Re: [Fwd: I'm stuck ... pse help!]] In-Reply-To: <1098632143.2287.4.camel@stargate.de.goenninger.com> References: <417ADAFC.7080504@nyc.rr.com> <417AFFD4.1040206@nyc.rr.com> <1098632143.2287.4.camel@stargate.de.goenninger.com> Message-ID: <233B7F44-25E9-11D9-B572-000D936D1552@nyc.rr.com> On Oct 24, 2004, at 11:35 AM, Frank Goenninger wrote: > Hi Kenny, > > thx for the inputs on the window close issue. > > Unfortunately, I'm not getting this far. I understand, but you had asked about glutSetOption, and that is a Freeglut extension designed to address the window close issue. So I was telling you (a) you could just *feature* it out and (b) how to survive a window close /if/ we ever get that far. > It seems it was unclear from my > previous emails that I do not get any window even appearing! > > Any call to the glut-create-window function makes OpenMCL die, yes, > really die! The process is interrupted without any signs or hints on > the > cause. Boy, that sounds like Glut calling exit(), though of course that should not happen on glutCreateWindow. There is an Apple list for OpenGL. I wonder if they would have any insight. Or some of the gmane lists, which seem more numerous than comp.mac.* lists. Would it be interesting to download the Lispworks freebee and see if you get the same thing there? But first I would put in the code I suggested about setting up the glut-wm-close-func by duplicating the glut-close-func setup. And you might want to put a (break) in the callabcks to see if maybe we are getting further than we think. You can add the break to the macro you see wrapping the code in each callback so you just have to put it one place. kenny ps. I download Lisp In a Box for Max OS X and it seems to work right out of the box, as they say. I would have a lot of Emacs to learn, but I think I want to do that anyway. So maybe I will be using OpenMCL shortly.... say, you included a tar last time. I just focused on the glutSetOption problem. If I look at your code will I see how you loaded the Apple Glut? k From frank_goenninger at t-online.de Sun Oct 24 18:37:07 2004 From: frank_goenninger at t-online.de (Frank Goenninger) Date: Sun, 24 Oct 2004 20:37:07 +0200 Subject: [cells-devel] [Fwd: Re: [Fwd: I'm stuck ... pse help!]] In-Reply-To: <233B7F44-25E9-11D9-B572-000D936D1552@nyc.rr.com> References: <417ADAFC.7080504@nyc.rr.com> <417AFFD4.1040206@nyc.rr.com> <1098632143.2287.4.camel@stargate.de.goenninger.com> <233B7F44-25E9-11D9-B572-000D936D1552@nyc.rr.com> Message-ID: <1098643027.2286.18.camel@stargate.de.goenninger.com> Kenny, thx for quickly coming back. Seems as if we're back in chat mode ;-) On Sun, 2004-10-24 at 20:18, Kenneth Tilton wrote: > On Oct 24, 2004, at 11:35 AM, Frank Goenninger wrote: > > > Hi Kenny, > > > > thx for the inputs on the window close issue. > > > > Unfortunately, I'm not getting this far. > > I understand, but you had asked about glutSetOption, and that is a > Freeglut extension designed to address the window close issue. So I was > telling you (a) you could just *feature* it out and (b) how to survive > a window close /if/ we ever get that far. Ah, now I got it. Well, sometimes I am bit slow ;-) Ok. Now, not using glut-set-option doesn't hurt for what I'm trying to accomplish... > > > It seems it was unclear from my > > previous emails that I do not get any window even appearing! > > > > Any call to the glut-create-window function makes OpenMCL die, yes, > > really die! The process is interrupted without any signs or hints on > > the > > cause. > > Boy, that sounds like Glut calling exit(), though of course that should > not happen on glutCreateWindow. There is an Apple list for OpenGL. I > wonder if they would have any insight. Or some of the gmane lists, > which seem more numerous than comp.mac.* lists. > > Would it be interesting to download the Lispworks freebee and see if > you get the same thing there? This is my fallback, yes. But I'm not yet that frustrated to do so ;-) > > But first I would put in the code I suggested about setting up the > glut-wm-close-func by duplicating the glut-close-func setup. Sir. Yes, Sir. :-) > And you > might want to put a (break) in the callabcks to see if maybe we are > getting further than we think. You can add the break to the macro you > see wrapping the code in each callback so you just have to put it one > place. Sir. Yes, Sir. :-) > > kenny > > ps. I download Lisp In a Box for Max OS X and it seems to work right > out of the box, as they say. I would have a lot of Emacs to learn, but > I think I want to do that anyway. So maybe I will be using OpenMCL > shortly.... say, you included a tar last time. I just focused on the > glutSetOption problem. If I look at your code will I see how you loaded > the Apple Glut? k > You will. It's in the build.lisp file. I simply do: CL-USER > (load "config.lisp") and then CL-USER > (load "build.sys") Apple GLUT loading definitions is distributed across the cl-opengl config files (which are included also) and the glut-functions.lisp file. As always, I have marked my changes with the string "frgo" in them. You can search for that to find the places. I will now be off for our weekly dancing course doing Cha-Cha and the like. Will be back in 2 hours. Frank -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From frank_goenninger at t-online.de Sun Oct 24 22:35:37 2004 From: frank_goenninger at t-online.de (Frank Goenninger) Date: Mon, 25 Oct 2004 00:35:37 +0200 Subject: [cells-devel] [Fwd: Re: [Fwd: I'm stuck ... pse help!]] In-Reply-To: <1098643027.2286.18.camel@stargate.de.goenninger.com> References: <417ADAFC.7080504@nyc.rr.com> <417AFFD4.1040206@nyc.rr.com> <1098632143.2287.4.camel@stargate.de.goenninger.com> <233B7F44-25E9-11D9-B572-000D936D1552@nyc.rr.com> <1098643027.2286.18.camel@stargate.de.goenninger.com> Message-ID: <1098657337.2286.23.camel@stargate.de.goenninger.com> Slight correction: On Sun, 2004-10-24 at 20:37, Frank Goenninger wrote: > and then > > CL-USER > (load "build.sys") Of course, this should read: CL-USER > (load "build.lisp") ;-)) Frank -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From frank_goenninger at t-online.de Sun Oct 24 22:42:02 2004 From: frank_goenninger at t-online.de (Frank Goenninger) Date: Mon, 25 Oct 2004 00:42:02 +0200 Subject: [cells-devel] Small progress: GLUT-INIT not called due to false init value checking Message-ID: <1098657721.2286.31.camel@stargate.de.goenninger.com> Hi Kenn & all: I just discovered that GLUT wasn't initialized properly in cl-glut-init. This is due to the (zerop glut-state) which I turned into (or (eq glut-state 0) (eq glut-state -1)) Also, I found that when calling glut-init I run into a "a MACPTR cannot be coerced to INTEGER" error. So I fiddled with the call to glut-init (all in file glut-extras.lisp) and replaced the argc argument with a fixed integer value, 1. Now I see a new Dock element, a terminal that shows the OpenMCL text when going over it with the mouse. Unfortunately, OpenMCL now does not return from that call. So I suppose we have a FFI problem here, most probably some problems with pointers. Now, this is a new one for me, so it will take some time to fix it. Suggestions? Thx! Happy Hacking - Frank -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From ktilton at nyc.rr.com Mon Oct 25 08:46:03 2004 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Mon, 25 Oct 2004 04:46:03 -0400 Subject: [cells-devel] Small progress: GLUT-INIT not called due to false init value checking In-Reply-To: <1098657721.2286.31.camel@stargate.de.goenninger.com> References: <1098657721.2286.31.camel@stargate.de.goenninger.com> Message-ID: <417CBD4B.7000906@nyc.rr.com> I just realized a couple of things.... Frank Goenninger wrote: >Hi Kenn & all: > >I just discovered that GLUT wasn't initialized properly in cl-glut-init. > >This is due to the (zerop glut-state) which I turned into > >(or (eq glut-state 0) (eq glut-state -1)) > I am guessing you did this because you saw -1 coming back from (glutGet glut_init_state). That would mean glut is already initialized, and it might be an error (leading to a silent shut-down via exit()) to call glutInit when glut is already initialized (I do seem to recall that in Freeglut). This is where it gets tricky being a Lisp developer. :) Anyway, I /think/ the zerop was the correct test. If you are seeing a -1 come back when you are sure glut is not initialized, then we might have an FFI problem (I doubt -1 is being used to signify false). > >Also, I found that when calling glut-init I run into a > >"a MACPTR cannot be coerced to INTEGER" > >error. So I fiddled with the call to glut-init (all in file >glut-extras.lisp) and replaced the argc argument with a fixed integer >value, 1. > Whoa, I missed that. Two things: (1) glutInit wants a pointer to an integer. That is why we allocate an array, stuff the integer into index zero and pass the array -- that is effectively passing a pointer to the first element of the array. (2) We are not passing any argv's to glutInit, so you have to pass (a pointer to) zero as the argc. C functions have no way of knowing how many argvs are being passed, so that is why there is also the argc argument. I do not know how C survived being passed an integer address of 1, but if it does not see zero it takes the value of argv as a pointer to the first pointer to an argv. We are passing null for argv, so C would blindly be examining address 0 and thinking it was a pointer. Possibly what has happened is that glutInit saw enough to decide it should start up a proper app with window, so things happened in the dock, but when it finally got around to looking at the args, it died on a bad pointer. On win32 I was able to place breakpoints (by coding "assert( false );") in glut code in VC6 and rebuilding the DLL. (I had to call unload-foreign-library on the dll before rebuilding or VC6 would be unable to overwrite the old one). Then when I ran I could (at first) actually get into the VC6 debugger. Unfortunately, the last time I tried this I could not debug, so it was one test and then shutdown the whole Lisp IDE. To improve on this, I had Freeglut put up a win32 alert box instead of using assert( false), so I could get the DLL to report back some info before continuing execution. In this case I would add alerts to glutInit and glutCheckLoop and glutCreateWindow so I could see what was going on. Well, that is if Apple makes a Glut ProjectBuilder. I will install XCode on my new toy now and see what I can see. cheers, kt From frank_goenninger at t-online.de Mon Oct 25 09:16:43 2004 From: frank_goenninger at t-online.de (Frank Goenninger) Date: Mon, 25 Oct 2004 11:16:43 +0200 Subject: [cells-devel] Small progress: GLUT-INIT not called due to false init value checking In-Reply-To: <417CBD4B.7000906@nyc.rr.com> References: <1098657721.2286.31.camel@stargate.de.goenninger.com> <417CBD4B.7000906@nyc.rr.com> Message-ID: <1098695803.2286.39.camel@stargate.de.goenninger.com> Hi again.. On Mon, 2004-10-25 at 10:46, Kenny Tilton wrote: > I just realized a couple of things.... > > Frank Goenninger wrote: > > >Hi Kenn & all: > > > >I just discovered that GLUT wasn't initialized properly in cl-glut-init. > > > >This is due to the (zerop glut-state) which I turned into > > > >(or (eq glut-state 0) (eq glut-state -1)) > > > I am guessing you did this because you saw -1 coming back from (glutGet > glut_init_state). That would mean glut is already initialized, and it > might be an error (leading to a silent shut-down via exit()) to call > glutInit when glut is already initialized (I do seem to recall that in > Freeglut). > You're right here. My assumption (and assumptions are never an easy thing) was that -1 meant "Not initialized yet" and I didn't check the GLUT specs for that. > This is where it gets tricky being a Lisp developer. :) Well, still counting myself as a newbie I am looking for ways of learning the art of being more advanced ... > Anyway, I > /think/ the zerop was the correct test. If you are seeing a -1 come back > when you are sure glut is not initialized, then we might have an FFI > problem (I doubt -1 is being used to signify false). I will check the GLUT specs for that now. > > > >Also, I found that when calling glut-init I run into a > > > >"a MACPTR cannot be coerced to INTEGER" > > > >error. So I fiddled with the call to glut-init (all in file > >glut-extras.lisp) and replaced the argc argument with a fixed integer > >value, 1. > > > Whoa, I missed that. Two things: > > (1) glutInit wants a pointer to an integer. That is why we allocate an > array, stuff the integer into index zero and pass the array -- that is > effectively passing a pointer to the first element of the array. > > (2) We are not passing any argv's to glutInit, so you have to pass (a > pointer to) zero as the argc. C functions have no way of knowing how > many argvs are being passed, so that is why there is also the argc > argument. I do not know how C survived being passed an integer address > of 1, but if it does not see zero it takes the value of argv as a > pointer to the first pointer to an argv. We are passing null for argv, > so C would blindly be examining address 0 and thinking it was a pointer. > Fully understood so far with more than 5 years of professional C programming under my belt ;-)) > Possibly what has happened is that glutInit saw enough to decide it > should start up a proper app with window, so things happened in the > dock, but when it finally got around to looking at the args, it died on > a bad pointer. Yep. I suppose that's what is happening here. > > On win32 I was able to place breakpoints (by coding "assert( false );") > in glut code in VC6 and rebuilding the DLL. (I had to call > unload-foreign-library on the dll before rebuilding or VC6 would be > unable to overwrite the old one). Then when I ran I could (at first) > actually get into the VC6 debugger. Unfortunately, the last time I tried > this I could not debug, so it was one test and then shutdown the whole > Lisp IDE. To improve on this, I had Freeglut put up a win32 alert box > instead of using assert( false), so I could get the DLL to report back > some info before continuing execution. > > In this case I would add alerts to glutInit and glutCheckLoop and > glutCreateWindow so I could see what was going on. Well, that is if > Apple makes a Glut ProjectBuilder. I will install XCode on my new toy > now and see what I can see. Not seen any of kind of source for Apple's GLUT yet. So this will be key if we want to go the route you suggested for debugging. > > cheers, kt Now I have a busy Monday just starting with writing a proposal for a (hopefully) client to get some money flowing in ... Frank -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From cells-devel at common-lisp.net Wed Oct 27 04:23:22 2004 From: cells-devel at common-lisp.net (sophia g. iverson) Date: Wed, 27 Oct 2004 13:23:22 +0900 Subject: [cells-devel] These will help you please your partner again! 6Cd2 Message-ID: <055401c4bbdd$f9cce846$176f00a5@±èÁ¤¹Î> Grow 3 inches with our products! http://galdiobover.com/9/4/index.php?aiw90&com5& 6121fKK631Uy3J5yy48Why don't you learn this stuff? For at that time I had already made up my mind that imperialism was an evil thing and the sooner I chucked up my job and got out of it the better.I ought, therefore, as the elephant was sideways on152741015 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ktilton at nyc.rr.com Thu Oct 28 00:36:06 2004 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Wed, 27 Oct 2004 20:36:06 -0400 Subject: [cells-devel] Cello Stabilized on win32, OS X next Message-ID: <41803EF6.4060300@nyc.rr.com> Otay, a bunch of CVS stuff after redoing the ASDF definitions, the Cello configuration setup, and re-porting to Lispworks. There is a new cell-cultures-user directory under the root cell-cultures directory. Folks should move a copy out from under cell-cultures (to a place safe from your next CVS update) and tailor that to their environment, redirecting the *cell-cultures-user-directory* definition as necessary. Tomorrow I will join Frank G. on the OS X port effort, trying first on Lispworks while Frank is doing OpenMCL. Courage. kt -- Cells? Cello? Celtik?: http://www.common-lisp.net/project/cells/ Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film From frank_goenninger at t-online.de Thu Oct 28 17:56:38 2004 From: frank_goenninger at t-online.de (Frank Goenninger) Date: Thu, 28 Oct 2004 19:56:38 +0200 Subject: [cells-devel] OpenMCL porting progress update Message-ID: <1098986198.11687.9.camel@stargate.de.goenninger.com> Hi Kenny and all the other mostly read-onlies ;-) I have been digging into the GLUT-INIT issue for a couple of hours. First thing to do was to update UFFI to the current stable version of 1.4.28. This fixed a couple of things. Next surprise for me was to discover that the code in the ffi-extender package was OpenMCL/MCL unaware. So this got me into trouble as Kenny does a lot of things in that package that I call "advanced stuff". This is where I am still just completing the OpenMCL way of doing things. Along that path I had the joy of learning OpenMCL's FFI and some of UFFI's internals. Becoming better with Common Lisp, guys... Another thing I could find was an interesting part of sample code in the OpenMCL distro: x-x-x (in-package :opengl) ;; glut complains if it's initialized redundantly (let ((glut-initialized-p nil)) (defun initialize-glut () (let ((command-line-strings (list "openmcl"))) (when (not glut-initialized-p) (ccl::with-string-vector (argv command-line-strings) (rlet ((argvp (* t)) ; glutinit takes (* (:signed 32)) and (* (* (:unsigned 8))) (argcp :signed)) ; so why are these declared as (* t) and :signed? (setf (%get-long argcp) (length command-line-strings) (%get-ptr argvp) argv) (#_glutInit argcp argvp))) (setf glut-initialized-p t)))) ;; When a saved image is restarted, it needs to know that glut ;; hasn't been initialized yet. (defun uninitialize-glut () (setf glut-initialized-p nil)) ) (pushnew #'uninitialize-glut ccl::*save-exit-functions* :key #'ccl::function-name) x-x-x I am currently translating this into an UFFI-version and hope to fix the problem calling GLUT-INIT. That's it, unfortunately. I am still not at the speed I wish to be... Cheers to everybody! Frank - enjoying an all-new Powerbook G4 ... -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From ktilton at nyc.rr.com Thu Oct 28 19:41:25 2004 From: ktilton at nyc.rr.com (Kenneth Tilton) Date: Thu, 28 Oct 2004 15:41:25 -0400 Subject: [cells-devel] OpenMCL porting progress update In-Reply-To: <1098986198.11687.9.camel@stargate.de.goenninger.com> References: <1098986198.11687.9.camel@stargate.de.goenninger.com> Message-ID: <5A8AD310-2919-11D9-B24C-000D936D1552@nyc.rr.com> On Oct 28, 2004, at 1:56 PM, Frank Goenninger wrote: > Hi Kenny and all the other mostly read-onlies ;-) > > I have been digging into the GLUT-INIT issue for a couple of hours. > First thing to do was to update UFFI to the current stable version of > 1.4.28. > > This fixed a couple of things. Next surprise for me was to discover > that > the code in the ffi-extender package was OpenMCL/MCL unaware. So this > got me into trouble as Kenny does a lot of things in that package that > I > call "advanced stuff". Oops. :) Sounds like you are past that though. > > This is where I am still just completing the OpenMCL way of doing > things. Along that path I had the joy of learning OpenMCL's FFI and > some > of UFFI's internals. Becoming better with Common Lisp, guys... > > Another thing I could find was an interesting part of sample code in > the > OpenMCL distro: Ah, lucky us! Do they have a working OpenGL demo? > > x-x-x > (in-package :opengl) > > ;; glut complains if it's initialized redundantly > (let ((glut-initialized-p nil)) > (defun initialize-glut () > (let ((command-line-strings (list "openmcl"))) > (when (not glut-initialized-p) > (ccl::with-string-vector (argv command-line-strings) > (rlet ((argvp (* t)) ; glutinit takes (* (:signed 32)) > and (* (* (:unsigned 8))) > (argcp :signed)) ; so why are these declared as (* t) and :signed? > (setf (%get-long argcp) (length command-line-strings) > (%get-ptr argvp) argv) > (#_glutInit argcp argvp))) > (setf glut-initialized-p t)))) > ;; When a saved image is restarted, it needs to know that glut > ;; hasn't been initialized yet. > (defun uninitialize-glut () > (setf glut-initialized-p nil)) > ) > > (pushnew #'uninitialize-glut ccl::*save-exit-functions* > :key #'ccl::function-name) > x-x-x > > I am currently translating this into an UFFI-version and hope to fix > the problem calling GLUT-INIT. > > That's it, unfortunately. I am still not at the speed I wish to be... Can't wait to see what you do at full speed if you think this is slow. :) Over here I have managed to build enough under Lispworks to run lesson-14, except now I have to sort out glutInit and feature out glut-set-option and set up glut-wm-close etc etc., so I am right behind you. Let's keep each other posted. btw, I used the latest UFFI and this time Lispworks did not complain about anything. That made me happy. :) kt From ktilton at nyc.rr.com Fri Oct 29 05:03:23 2004 From: ktilton at nyc.rr.com (Kenneth Tilton) Date: Fri, 29 Oct 2004 01:03:23 -0400 Subject: [cells-devel] Baby steps Message-ID: Code builds Ok up to running just the Glut (no FTGL fonts, no ImageMagick). Glut loads OK (thx, Frank) and inits OK, including glutInit and a couple of parameter initializing hooks. Dies on glutCreateWindow, but that is because Apple did not follow the Glut which I simply assumed they would, that because the Freeglut crowd is obsessive about being perfectly compatible with the original, such that a binary for the original could run against a Freeglut DLL. Anyway, there is nothing very strange about Apple's glutCreateWindow, so I'll tailor that to PS X next. Courage. kenny From ktilton at nyc.rr.com Fri Oct 29 05:41:31 2004 From: ktilton at nyc.rr.com (Kenneth Tilton) Date: Fri, 29 Oct 2004 01:41:31 -0400 Subject: [cells-devel] Baby steps In-Reply-To: References: Message-ID: <301081EC-296D-11D9-97B9-000D936D1552@nyc.rr.com> On Oct 29, 2004, at 1:03 AM, Kenneth Tilton wrote: > Code builds Ok up to running just the Glut (no FTGL fonts, no > ImageMagick). > > Glut loads OK (thx, Frank) and inits OK, including glutInit and a > couple of parameter initializing hooks. > > Dies on glutCreateWindow, but that is because Apple did not follow the > Glut ... Doh! Wrong. :) Never mind. kt From frank_goenninger at t-online.de Fri Oct 29 18:54:11 2004 From: frank_goenninger at t-online.de (Frank Goenninger) Date: Fri, 29 Oct 2004 20:54:11 +0200 Subject: [cells-devel] OpenMCL porting progress update In-Reply-To: <5A8AD310-2919-11D9-B24C-000D936D1552@nyc.rr.com> References: <1098986198.11687.9.camel@stargate.de.goenninger.com> <5A8AD310-2919-11D9-B24C-000D936D1552@nyc.rr.com> Message-ID: <1099076051.9346.94.camel@stargate.de.goenninger.com> On Thu, 2004-10-28 at 21:41, Kenneth Tilton wrote: > On Oct 28, 2004, at 1:56 PM, Frank Goenninger wrote: > > > Hi Kenny and all the other mostly read-onlies ;-) > > > > I have been digging into the GLUT-INIT issue for a couple of hours. > > First thing to do was to update UFFI to the current stable version of > > 1.4.28. > > > > This fixed a couple of things. Next surprise for me was to discover > > that > > the code in the ffi-extender package was OpenMCL/MCL unaware. So this > > got me into trouble as Kenny does a lot of things in that package that > > I > > call "advanced stuff". > > Oops. :) Sounds like you are past that though. No, unfortunately I am stuck here. Kenny, it would help if you could explain the semantical differences between the following functions/macros: ffx::ff-defun-callable ffx::ff-def-call (hmm - The question mark in my faces says: When to use which?) Why are you not just using UFFI's def-function here? It seems I have missed something very fundamental here... Another PITA is the the fact that I couldn't find a way of making callbacks to simply work as expected. I figured that defcallback is a macro in OpenMCL to be wrapped around the body of the callback, not just a "register" operation as used in your ffx package... So: ??? > > > > > This is where I am still just completing the OpenMCL way of doing > > things. Along that path I had the joy of learning OpenMCL's FFI and > > some > > of UFFI's internals. Becoming better with Common Lisp, guys... > > > > Another thing I could find was an interesting part of sample code in > > the > > OpenMCL distro: > > Ah, lucky us! Do they have a working OpenGL demo? > > > > > x-x-x > > (in-package :opengl) > > > > ;; glut complains if it's initialized redundantly > > (let ((glut-initialized-p nil)) > > (defun initialize-glut () > > (let ((command-line-strings (list "openmcl"))) > > (when (not glut-initialized-p) > > (ccl::with-string-vector (argv command-line-strings) > > (rlet ((argvp (* t)) ; glutinit takes (* (:signed 32)) > > and (* (* (:unsigned 8))) > > (argcp :signed)) ; so why are these declared as (* t) and :signed? > > (setf (%get-long argcp) (length command-line-strings) > > (%get-ptr argvp) argv) > > (#_glutInit argcp argvp))) > > (setf glut-initialized-p t)))) > > ;; When a saved image is restarted, it needs to know that glut > > ;; hasn't been initialized yet. > > (defun uninitialize-glut () > > (setf glut-initialized-p nil)) > > ) > > > > (pushnew #'uninitialize-glut ccl::*save-exit-functions* > > :key #'ccl::function-name) > > x-x-x > > > > I am currently translating this into an UFFI-version and hope to fix > > the problem calling GLUT-INIT. Only a quick hack available so far. This needs a lot of polishing to be production quality. > > > > That's it, unfortunately. I am still not at the speed I wish to be... > > Can't wait to see what you do at full speed if you think this is slow. > :) > > Over here I have managed to build enough under Lispworks to run > lesson-14, except now I have to sort out glutInit and feature out > glut-set-option and set up glut-wm-close etc etc., so I am right behind > you. Let's keep each other posted. > Congrats! Yeah, but I feel we're in quite good comms. > btw, I used the latest UFFI and this time Lispworks did not complain > about anything. That made me happy. :) > > kt Well, currently I am a bit frustrated. Several pieces still to be fixed and no progress for two days... ;-) Frank -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From cells-devel at common-lisp.net Sat Oct 30 22:59:34 2004 From: cells-devel at common-lisp.net (Aurora Wolf) Date: Sat, 30 Oct 2004 21:59:34 -0100 Subject: [cells-devel] Hello Cells-devel Message-ID: An HTML attachment was scrubbed... URL: From cells-devel at common-lisp.net Wed Oct 27 04:23:22 2004 From: cells-devel at common-lisp.net (sophia g. iverson) Date: Wed, 27 Oct 2004 13:23:22 +0900 Subject: [cells-devel] These will help you please your partner again! 6Cd2 Message-ID: <055401c4bbdd$f9cce846$176f00a5@±èÁ¤¹Î> Grow 3 inches with our products! http://galdiobover.com/9/4/index.php?aiw90&com5& 6121fKK631Uy3J5yy48Why don't you learn this stuff? For at that time I had already made up my mind that imperialism was an evil thing and the sooner I chucked up my job and got out of it the better.I ought, therefore, as the elephant was sideways on152741015 -------------- next part -------------- An HTML attachment was scrubbed... URL: From cells-devel at common-lisp.net Wed Oct 27 04:23:22 2004 From: cells-devel at common-lisp.net (sophia g. iverson) Date: Wed, 27 Oct 2004 13:23:22 +0900 Subject: [cells-devel] These will help you please your partner again! 6Cd2 Message-ID: <055401c4bbdd$f9cce846$176f00a5@±èÁ¤¹Î> Grow 3 inches with our products! http://galdiobover.com/9/4/index.php?aiw90&com5& 6121fKK631Uy3J5yy48Why don't you learn this stuff? For at that time I had already made up my mind that imperialism was an evil thing and the sooner I chucked up my job and got out of it the better.I ought, therefore, as the elephant was sideways on152741015 -------------- next part -------------- An HTML attachment was scrubbed... URL: