From patrice.lespagnol at obs-nancay.fr Thu Feb 5 19:09:24 2009 From: patrice.lespagnol at obs-nancay.fr (patrice.lespagnol at obs-nancay.fr) Date: Thu, 5 Feb 2009 19:09:24 -0000 (UTC) Subject: [mcclim-devel] OpenGL backend Message-ID: <4ee16fec851e4e1cfda5bb24b4241c1f.squirrel@www.obs-nancay.fr> Hello, I'am interessed in using the OpenGL backend of McCLIM : what is its state currently ? What would be a good start point to work on it ? Thanks for your advices. From strandh at labri.fr Fri Feb 6 04:23:38 2009 From: strandh at labri.fr (Robert Strandh) Date: Fri, 6 Feb 2009 05:23:38 +0100 Subject: [mcclim-devel] OpenGL backend In-Reply-To: <4ee16fec851e4e1cfda5bb24b4241c1f.squirrel@www.obs-nancay.fr> References: <4ee16fec851e4e1cfda5bb24b4241c1f.squirrel@www.obs-nancay.fr> Message-ID: <18827.47946.757716.510360@serveur5.labri.fr> Hello, patrice.lespagnol at obs-nancay.fr writes: > > I'am interessed in using the OpenGL backend of McCLIM : what is its state > currently ? What would be a good start point to work on it ? The state is that it hasn't been worked on for a number of years, and that it is unclear how much of it is working. Your best bet would be to send email to moore at bricoworks.com or simply to experiment with it to find out what is working and what isn't. Good luck! -- Robert Strandh --------------------------------------------------------------------- Greenspun's Tenth Rule of Programming: any sufficiently complicated C or Fortran program contains an ad hoc informally-specified bug-ridden slow implementation of half of Common Lisp. --------------------------------------------------------------------- From demmeln at in.tum.de Fri Feb 6 20:11:41 2009 From: demmeln at in.tum.de (Nikolaus Demmel) Date: Fri, 06 Feb 2009 21:11:41 +0100 Subject: [mcclim-devel] Non shrinking panes Message-ID: <1233951101.8377.13.camel@atradig111.informatik.tu-muenchen.de> Hi list In the following when i talk about width of the pane, i mean the value returned by (bounding-rectangle-width pane). I have an application pane with not much output (which is not very wide and definately not as wide as the pane) at the beginning. When i resize (shrink) the whole frame (manually, using the mouse), the application pane adapts in size until it is as wide as the intial output, then the scrolling kicks in, but the size of the pane doesn't shrink further. This makes sense. Now if after a while (or due to some user action) the output on the pane becomes wider, then the "minimum pane width" that i can achieve with shrinking the frame as above becomes this new withs of the output. This also makes sense. Now if the output changes to something not as wide again, then the "minimum pane width" acheived by resizing the whole window as above doesn't shrink. It stays at the maximum width of output over the whole lifetime of the application. Does this have to do with output recording? How can i make the pane become less wide again? The background is, that i want to draw some lines as wide as the pane that adapt in size, when i resize the window. This works with enlarging the window, but as described above not with shrinking it. How could i acheive that. Regards, Niko Demmel From csr21 at cantab.net Mon Feb 9 16:35:34 2009 From: csr21 at cantab.net (Christophe Rhodes) Date: Mon, 09 Feb 2009 16:35:34 +0000 Subject: [mcclim-devel] Drei gadgets Message-ID: <87r6274lgp.fsf@cantab.net> Hi, For the revival of an application (an editor for lute tablature) whose previous incarnation was as a Climacs syntax, I'm trying to use a Drei gadget pane. I've found the attached patch necessary: the first hunk to prevent an infinite loop in command lookup, and the second to use the minibuffer stream for extended commands. I'm not sure if either of these patches is correct. Any advice would be welcome. Best, Christophe -------------- next part -------------- A non-text attachment was scrubbed... Name: tab.diff Type: text/x-diff Size: 1382 bytes Desc: patches URL: From demmeln at in.tum.de Wed Feb 11 20:23:59 2009 From: demmeln at in.tum.de (Nikolaus Demmel) Date: Wed, 11 Feb 2009 21:23:59 +0100 Subject: [mcclim-devel] Non shrinking panes In-Reply-To: <1233951101.8377.13.camel@atradig111.informatik.tu-muenchen.de> References: <1233951101.8377.13.camel@atradig111.informatik.tu-muenchen.de> Message-ID: <5BF0C6AE-2AC7-4102-9DF1-B2A596C502E8@in.tum.de> I have gained some confidence, that the issue has to do with output recording. Unfortunately neither calling (climi:reset-output-history pane) nor (clear-output-record (stream-output-history pane)) seems to do anything... Anyone know how to clear the output history? Regards, Niko Demmel Am 06.02.2009 um 21:11 schrieb Nikolaus Demmel: > Hi list > > In the following when i talk about width of the pane, i mean the value > returned by (bounding-rectangle-width pane). > > I have an application pane with not much output (which is not very > wide > and definately not as wide as the pane) at the beginning. When i > resize > (shrink) the whole frame (manually, using the mouse), the application > pane adapts in size until it is as wide as the intial output, then the > scrolling kicks in, but the size of the pane doesn't shrink further. > This makes sense. > > Now if after a while (or due to some user action) the output on the > pane > becomes wider, then the "minimum pane width" that i can achieve with > shrinking the frame as above becomes this new withs of the output. > This > also makes sense. > > Now if the output changes to something not as wide again, then the > "minimum pane width" acheived by resizing the whole window as above > doesn't shrink. It stays at the maximum width of output over the whole > lifetime of the application. > > Does this have to do with output recording? > > How can i make the pane become less wide again? > > The background is, that i want to draw some lines as wide as the pane > that adapt in size, when i resize the window. This works with > enlarging > the window, but as described above not with shrinking it. How could i > acheive that. > > Regards, > Niko Demmel > > > _______________________________________________ > mcclim-devel mailing list > mcclim-devel at common-lisp.net > http://common-lisp.net/cgi-bin/mailman/listinfo/mcclim-devel From demmeln at in.tum.de Wed Feb 11 21:40:28 2009 From: demmeln at in.tum.de (Nikolaus Demmel) Date: Wed, 11 Feb 2009 22:40:28 +0100 Subject: [mcclim-devel] Non shrinking panes In-Reply-To: <5BF0C6AE-2AC7-4102-9DF1-B2A596C502E8@in.tum.de> References: <1233951101.8377.13.camel@atradig111.informatik.tu-muenchen.de> <5BF0C6AE-2AC7-4102-9DF1-B2A596C502E8@in.tum.de> Message-ID: <1D3C591B-D1FC-4315-9F7D-281E7B8B2CBE@in.tum.de> False alarm. (clear-output-record (stream-output-history pane)) does work. But the pane is still refusing to shrink in size, even if i manually call (resize-sheet pane a b) the pane is still back to its maximum ever size on next redisplay. What causes the pane to keep its size? Regards, Niko Demmel Am 11.02.2009 um 21:23 schrieb Nikolaus Demmel: > I have gained some confidence, that the issue has to do with output > recording. > > Unfortunately neither calling > > (climi:reset-output-history pane) > > nor > > (clear-output-record (stream-output-history pane)) > > seems to do anything... > > Anyone know how to clear the output history? > > Regards, > Niko Demmel > > > Am 06.02.2009 um 21:11 schrieb Nikolaus Demmel: > >> Hi list >> >> In the following when i talk about width of the pane, i mean the >> value >> returned by (bounding-rectangle-width pane). >> >> I have an application pane with not much output (which is not very >> wide >> and definately not as wide as the pane) at the beginning. When i >> resize >> (shrink) the whole frame (manually, using the mouse), the application >> pane adapts in size until it is as wide as the intial output, then >> the >> scrolling kicks in, but the size of the pane doesn't shrink further. >> This makes sense. >> >> Now if after a while (or due to some user action) the output on the >> pane >> becomes wider, then the "minimum pane width" that i can achieve with >> shrinking the frame as above becomes this new withs of the output. >> This >> also makes sense. >> >> Now if the output changes to something not as wide again, then the >> "minimum pane width" acheived by resizing the whole window as above >> doesn't shrink. It stays at the maximum width of output over the >> whole >> lifetime of the application. >> >> Does this have to do with output recording? >> >> How can i make the pane become less wide again? >> >> The background is, that i want to draw some lines as wide as the pane >> that adapt in size, when i resize the window. This works with >> enlarging >> the window, but as described above not with shrinking it. How could i >> acheive that. >> >> Regards, >> Niko Demmel >> >> >> _______________________________________________ >> mcclim-devel mailing list >> mcclim-devel at common-lisp.net >> http://common-lisp.net/cgi-bin/mailman/listinfo/mcclim-devel > > > _______________________________________________ > mcclim-devel mailing list > mcclim-devel at common-lisp.net > http://common-lisp.net/cgi-bin/mailman/listinfo/mcclim-devel From ahefner at gmail.com Thu Feb 12 03:29:29 2009 From: ahefner at gmail.com (Andy Hefner) Date: Wed, 11 Feb 2009 22:29:29 -0500 Subject: [mcclim-devel] Non shrinking panes In-Reply-To: <1D3C591B-D1FC-4315-9F7D-281E7B8B2CBE@in.tum.de> References: <1233951101.8377.13.camel@atradig111.informatik.tu-muenchen.de> <5BF0C6AE-2AC7-4102-9DF1-B2A596C502E8@in.tum.de> <1D3C591B-D1FC-4315-9F7D-281E7B8B2CBE@in.tum.de> Message-ID: <31ffd3c40902111929n23252c43oedb00907e6d63661@mail.gmail.com> After redisplay, McCLIM resizes the pane to fit the bounding rectangle of the output history. If you're redisplaying the pane from scratch, I don't understand why the bounding rectangle shouldn't be tightened - it'd probably a bug. A small test case to demonstrate would be helpful. Also, the behavior here changed recently, and maybe I didn't think thoroughly through what I was doing. If you clear the output history and (bounding-rectangle (stream-output-history stream)) doesn't shrink afterward, it's definitely a bug. The thing to do here, I think, is to call change-space-requirements, not resize-sheet. If the parent of your pane is some kind of layout pane, the space will be reallocated top-down based on the space requirements, with the layout pane itself calling resize-sheet on your pane, overriding your change. As you've probably figured out, adapting recorded output to the pane size is tricky. The status bar in the listener used to do this to justify the memory usage to the right, but occasionally it would find a new way to recursively blow up. I decided it was more trouble than it was worth and ripped it out. Still, you might make it work for your application. It's certainly something we *should* support, but no one has really worked out the best way to do it and carved a safe path through McCLIM to make sure it works. On Wed, Feb 11, 2009 at 4:40 PM, Nikolaus Demmel wrote: > False alarm. > > (clear-output-record (stream-output-history pane)) > > does work. But the pane is still refusing to shrink in size, even if > i manually call > > (resize-sheet pane a b) > > the pane is still back to its maximum ever size on next redisplay. > What causes the pane to keep its size? > > Regards, > Niko Demmel > > > Am 11.02.2009 um 21:23 schrieb Nikolaus Demmel: > >> I have gained some confidence, that the issue has to do with output >> recording. >> >> Unfortunately neither calling >> >> (climi:reset-output-history pane) >> >> nor >> >> (clear-output-record (stream-output-history pane)) >> >> seems to do anything... >> >> Anyone know how to clear the output history? >> >> Regards, >> Niko Demmel >> >> >> Am 06.02.2009 um 21:11 schrieb Nikolaus Demmel: >> >>> Hi list >>> >>> In the following when i talk about width of the pane, i mean the >>> value >>> returned by (bounding-rectangle-width pane). >>> >>> I have an application pane with not much output (which is not very >>> wide >>> and definately not as wide as the pane) at the beginning. When i >>> resize >>> (shrink) the whole frame (manually, using the mouse), the application >>> pane adapts in size until it is as wide as the intial output, then >>> the >>> scrolling kicks in, but the size of the pane doesn't shrink further. >>> This makes sense. >>> >>> Now if after a while (or due to some user action) the output on the >>> pane >>> becomes wider, then the "minimum pane width" that i can achieve with >>> shrinking the frame as above becomes this new withs of the output. >>> This >>> also makes sense. >>> >>> Now if the output changes to something not as wide again, then the >>> "minimum pane width" acheived by resizing the whole window as above >>> doesn't shrink. It stays at the maximum width of output over the >>> whole >>> lifetime of the application. >>> >>> Does this have to do with output recording? >>> >>> How can i make the pane become less wide again? >>> >>> The background is, that i want to draw some lines as wide as the pane >>> that adapt in size, when i resize the window. This works with >>> enlarging >>> the window, but as described above not with shrinking it. How could i >>> acheive that. >>> >>> Regards, >>> Niko Demmel >>> >>> >>> _______________________________________________ >>> mcclim-devel mailing list >>> mcclim-devel at common-lisp.net >>> http://common-lisp.net/cgi-bin/mailman/listinfo/mcclim-devel >> >> >> _______________________________________________ >> mcclim-devel mailing list >> mcclim-devel at common-lisp.net >> http://common-lisp.net/cgi-bin/mailman/listinfo/mcclim-devel > > > _______________________________________________ > mcclim-devel mailing list > mcclim-devel at common-lisp.net > http://common-lisp.net/cgi-bin/mailman/listinfo/mcclim-devel > From demmeln at in.tum.de Sat Feb 14 16:39:11 2009 From: demmeln at in.tum.de (Nikolaus Demmel) Date: Sat, 14 Feb 2009 17:39:11 +0100 Subject: [mcclim-devel] Non shrinking panes In-Reply-To: <31ffd3c40902111929n23252c43oedb00907e6d63661@mail.gmail.com> References: <1233951101.8377.13.camel@atradig111.informatik.tu-muenchen.de> <5BF0C6AE-2AC7-4102-9DF1-B2A596C502E8@in.tum.de> <1D3C591B-D1FC-4315-9F7D-281E7B8B2CBE@in.tum.de> <31ffd3c40902111929n23252c43oedb00907e6d63661@mail.gmail.com> Message-ID: <125933F5-0828-4118-9786-9D385AF6DD02@in.tum.de> Hi Andy, > After redisplay, McCLIM resizes the pane to fit the bounding rectangle > of the output history. If you're redisplaying the pane from scratch, I > don't understand why the bounding rectangle shouldn't be tightened - > it'd probably a bug. A small test case to demonstrate would be > helpful. Also, the behavior here changed recently, and maybe I didn't > think thoroughly through what I was doing. Essentially that is what I'm doing. Here is a small test application to play around with: http://paste.lisp.org/display/75476 With the latest mcclim cvs snapshot I get the following behaviour: Press "inc" a couple of times and the "dec" again. If you resize the window accordingly (and maybe press "redisplay") I see that the pane size doesn't decrease beyond the prior maximum. I included the "clear" history button, but now found out, that the history is cleared anyway on complete redisplay (i guess this makes sense, otherwise your history would soon get huge). Can you reproduce that behaviour? If I understand you correctly it is a bug. > > If you clear the output history and (bounding-rectangle > (stream-output-history stream)) doesn't shrink afterward, it's > definitely a bug. > > The thing to do here, I think, is to call change-space-requirements, > not resize-sheet. If the parent of your pane is some kind of layout > pane, the space will be reallocated top-down based on the space > requirements, with the layout pane itself calling resize-sheet on your > pane, overriding your change. > > As you've probably figured out, adapting recorded output to the pane > size is tricky. The status bar in the listener used to do this to > justify the memory usage to the right, but occasionally it would find > a new way to recursively blow up. I decided it was more trouble than > it was worth and ripped it out. Still, you might make it work for your > application. It's certainly something we *should* support, but no one > has really worked out the best way to do it and carved a safe path > through McCLIM to make sure it works. Oh I haven't even gotten this far. At the moment I'm displaying things from scratch most of the time. This might be an issue later, when I need to optimize for speed. I will report back if I have trouble/success in that direction. Actually I might need something like that soon. I'm implementing a "timeline" and want a vertical line to follow the cursor, when in the timeline-pane. As I understand it my options are either incremental- redisplay and redisplay that single line only when the cursor moves, or use +flipping-ink+ ink somehow to remove the old line and draw it again at the new position.... Anyways thanks for your answer. It explained a couple of things I didn't fully understand! Best Regards, Niko Demmel From demmeln at in.tum.de Tue Feb 17 19:17:58 2009 From: demmeln at in.tum.de (Nikolaus Demmel) Date: Tue, 17 Feb 2009 20:17:58 +0100 Subject: [mcclim-devel] :scrollbars option vs (scrolling () ...) Message-ID: <1797125F-BD44-4216-976D-14F2775C3140@in.tum.de> Hi, can anyone explain to me the difference between using the application- pane's :scrollbar option or alternatively setting it to nil and using a (scrolling () ...) macro around that application pane in the layout? It looks a bit different (the scrolling macro comes with a black padding i think), but in essence, it is the same funktionality, right? Best regards, Niko Demmel From csr21 at cantab.net Sun Feb 22 11:24:34 2009 From: csr21 at cantab.net (Christophe Rhodes) Date: Sun, 22 Feb 2009 11:24:34 +0000 Subject: [mcclim-devel] unsupplied-argument-marker Message-ID: <87ljryaf4d.fsf@cantab.net> Hi, I think that *unsupplied-argument-marker* (and *numeric-argument-marker*) should not be uninterned symbols or conses. The basic reason is that (define-command-table foo-menu-table :menu (("Foo" (com-foo #.*unsupplied-argument-marker*)))) or any other use of the literal value of the markers will not survive a compile-file/load-fasl cycle: a "similar" but not EQ value will be constructed. This causes PARTIAL-COMMAND-P to fail, and confusion to reign. Patch attached (making the markers uninterned symbols -- one could imagine cleverer, interned struct representations, but that's probably overkill). Also attached is a proposed adjustment to the READ-FRAME-COMMAND :AROUND handling of menu-items and partial commands. At the moment, the method only attempts to fill in partial command arguments if the input stream is an interactor-pane; and command-line-read-arguments is hardcoded. The second piece of the attached patch removes both of these restrictions, which is what is needed for my application, but I'm unsure of the general ramifications. (I need the removal of the interactor-pane requirement because esa:minibuffer-pane is not a clim:interactor-pane. I'm not sure why not, nor what the protocol requirements on interactor-panes are.) Comments? I think that these changes are fairly safe, but there might be better fixes that are less conservative. Best, Christophe -------------- next part -------------- A non-text attachment was scrubbed... Name: pcp.diff Type: text/x-diff Size: 1842 bytes Desc: proposed fixes URL: From turbo24prg at web.de Sun Feb 22 17:10:09 2009 From: turbo24prg at web.de (=?ISO-8859-1?Q?Bastian_M=FCller?=) Date: Sun, 22 Feb 2009 18:10:09 +0100 Subject: [mcclim-devel] OpenGL backend In-Reply-To: <18827.47946.757716.510360@serveur5.labri.fr> References: <4ee16fec851e4e1cfda5bb24b4241c1f.squirrel@www.obs-nancay.fr> <18827.47946.757716.510360@serveur5.labri.fr> Message-ID: <49A186F1.3000001@web.de> Robert Strandh wrote: Hi, > patrice.lespagnol at obs-nancay.fr writes: > > > > I'am interessed in using the OpenGL backend of McCLIM : what is its state > > currently ? What would be a good start point to work on it ? > > The state is that it hasn't been worked on for a number of years, and > that it is unclear how much of it is working. > > Your best bet would be to send email to moore at bricoworks.com or > simply to experiment with it to find out what is working and what > isn't. After seeing some conversations about the OpenGL backend at #lisp and finally here, I'd really like to get some people together to work on it. The current OpenGL backend is based on CLX' OpenGL bindings. Currently there's far more activity at the cl-opengl project, which is more lispy and cross-platform, ie. not bound to X. McCLIM should use that instead. I really like Inertia (http://www.mike-austin.com/inertia/), which is a OpenGL based User Interface written in different languages, like Ruby and Dylan. The code is small, simple, very clean, really good comprehensible. Porting the snippets should work easily. Reading http://kantz.com/jason/clim-primer/application-frames.htm: " Frame Managers -------------- * control the realization of the look and feel of a frame * interpret the specification of the application frame in the context of the available window system facilities * take care of attaching the pane hierarchy of an application frame to an appropriate place in a window hierarchy Kinds of Frame Managers ----------------------- * desktop manager or window manager o allows a user to manipulate the frames of other applications o is usually a non-Lisp application o acts as a mediator between the Lisp application and the host desktop manager o application acting as frame managers o allow frames of other applications to be displayed within the host application " I'd like to use the OpenGl backend both in two "modes": a.) for each frame: ask the window manager to get a window (via glut) and draw the frames contents (text, buttons, ... ) inside the window. That's how the CLX and gtkairo backend work. b.) ask the window manager for *one* window (via glut) and for each frame draw a "window" (in the glut window) it's contents. That's what inertia does. Does a CLIM frame-manager support these modes or is the spec just based on the concept a.)? If both are possible: What mode is more favorable? Or work on both and have a common code base? For fonts ZPB-TTF (http://www.xach.com/lisp/zpb-ttf/) should be used, it's native lisp and works very well. For graphics there are two possibilities: a.) software-based: Vecto (http://www.xach.com/lisp/vecto/) is great for vector graphics. Don't know what to use for bitmaps. b.) hardware-accelerated: as we're already working with hardware-accelerated 3D graphics, we could also use hw-accelerated 2D graphics. There's the unfortunately unknown OpenVG (http://www.khronos.org/openvg/) specification, available from Khronos, the consortium that also makes OpenGL. There are some open-source implementation, the best being currently ShivaVG (http://ivanleben.blogspot.com/2007/07/shivavg-open-source-ansi-c-openvg.html) written in C and based on OpenGL. It's simple, fast and has at least most of the functionality needed. I've written a cl-opengl-like wrapper library cl-openvg, which works very well. I really like CLIM and it's features, but both gtkairo and CLX are not cross-platform and not appealing. With OpenGl both is possible. If we make McCLIM pretty and cross-platform, it'll attract more developers and users So, anyone interested in this possible project, please comment and give feedback. Any help is appreciated. Thanks! kind regards, Bastian From stassats at gmail.com Mon Feb 23 18:49:19 2009 From: stassats at gmail.com (Stas Boukarev) Date: Mon, 23 Feb 2009 21:49:19 +0300 Subject: [mcclim-devel] [Patch] run-program for CCL for Listener Message-ID: <87skm5q98w.fsf@gmail.com> Patch attached. -------------- next part -------------- A non-text attachment was scrubbed... Name: listener-ccl.patch Type: text/x-diff Size: 705 bytes Desc: not available URL: -------------- next part -------------- -- With Best Regards, Stas. From strandh at labri.fr Tue Feb 24 05:44:40 2009 From: strandh at labri.fr (Robert Strandh) Date: Tue, 24 Feb 2009 06:44:40 +0100 Subject: [mcclim-devel] [Patch] run-program for CCL for Listener In-Reply-To: <87skm5q98w.fsf@gmail.com> References: <87skm5q98w.fsf@gmail.com> Message-ID: <18851.35144.312110.109810@serveur5.labri.fr> Stas Boukarev writes: > Patch attached. Committed! Thanks! -- Robert Strandh --------------------------------------------------------------------- Greenspun's Tenth Rule of Programming: any sufficiently complicated C or Fortran program contains an ad hoc informally-specified bug-ridden slow implementation of half of Common Lisp. --------------------------------------------------------------------- From csr21 at cantab.net Sat Feb 28 16:51:06 2009 From: csr21 at cantab.net (Christophe Rhodes) Date: Sat, 28 Feb 2009 16:51:06 +0000 Subject: [mcclim-devel] unsupplied-argument-marker In-Reply-To: <87ljryaf4d.fsf@cantab.net> (Christophe Rhodes's message of "Sun\, 22 Feb 2009 11\:24\:34 +0000") References: <87ljryaf4d.fsf@cantab.net> Message-ID: <87wsbazerp.fsf@cantab.net> Christophe Rhodes writes: > Comments? I think that these changes are fairly safe, but there might > be better fixes that are less conservative. Absent comments, I have committed these changes. Best, Christophe PS: I know that this is a little bit of a reversal for me, but I begin to see the advantages of bug trackers even if they are not blessed with perfect interfaces. Does the McCLIM project have one, and if not would there be objections simply to turning on Trac on common-lisp.net? From brian at mastenbrook.net Sat Feb 28 17:52:54 2009 From: brian at mastenbrook.net (Brian Mastenbrook) Date: Sat, 28 Feb 2009 11:52:54 -0600 Subject: [mcclim-devel] unsupplied-argument-marker In-Reply-To: References: <87ljryaf4d.fsf@cantab.net> <87wsbazerp.fsf@cantab.net> Message-ID: <7F7F6E06-1587-4E91-9163-1149E7D09BBE@mastenbrook.net> On Feb 28, 2009, at 11:18 AM, Andreas Davour wrote: > What is Trac? http://lmgtfy.com/?q=trac -- Brian Mastenbrook http://brian.mastenbrook.net/ brian at mastenbrook.net From ahefner at gmail.com Sat Feb 28 18:04:52 2009 From: ahefner at gmail.com (Andy Hefner) Date: Sat, 28 Feb 2009 13:04:52 -0500 Subject: [mcclim-devel] unsupplied-argument-marker In-Reply-To: <87wsbazerp.fsf@cantab.net> References: <87ljryaf4d.fsf@cantab.net> <87wsbazerp.fsf@cantab.net> Message-ID: <31ffd3c40902281004h2628ad6cm9158d2a62fad7ed5@mail.gmail.com> On Sat, Feb 28, 2009 at 11:51 AM, Christophe Rhodes wrote: > PS: I know that this is a little bit of a reversal for me, but I begin > to see the advantages of bug trackers even if they are not blessed > with perfect interfaces. ?Does the McCLIM project have one, and if not > would there be objections simply to turning on Trac on common-lisp.net? Trac was set up for mcclim some time ago, although it hasn't seen a lot of use. From moore at bricoworks.com Sat Feb 28 19:49:17 2009 From: moore at bricoworks.com (Timothy Moore) Date: Sat, 28 Feb 2009 20:49:17 +0100 Subject: [mcclim-devel] unsupplied-argument-marker In-Reply-To: <87wsbazerp.fsf@cantab.net> References: <87ljryaf4d.fsf@cantab.net> <87wsbazerp.fsf@cantab.net> Message-ID: <49A9953D.3010801@bricoworks.com> Christophe Rhodes wrote: > Christophe Rhodes writes: > >> Comments? I think that these changes are fairly safe, but there might >> be better fixes that are less conservative. > > Absent comments, I have committed these changes. > > Best, > > Christophe > > PS: I know that this is a little bit of a reversal for me, but I begin > to see the advantages of bug trackers even if they are not blessed > with perfect interfaces. Does the McCLIM project have one, and if not > would there be objections simply to turning on Trac on common-lisp.net? See http://intertwingly.net/blog/2008/07/18/Life-after-Bug-Tracking-Systems :) Tim From csr21 at cantab.net Sat Feb 28 20:22:52 2009 From: csr21 at cantab.net (Christophe Rhodes) Date: Sat, 28 Feb 2009 20:22:52 +0000 Subject: [mcclim-devel] unsupplied-argument-marker In-Reply-To: <49A9953D.3010801@bricoworks.com> (Timothy Moore's message of "Sat\, 28 Feb 2009 20\:49\:17 +0100") References: <87ljryaf4d.fsf@cantab.net> <87wsbazerp.fsf@cantab.net> <49A9953D.3010801@bricoworks.com> Message-ID: <87sklyz4yr.fsf@cantab.net> Timothy Moore writes: > Christophe Rhodes wrote: >> PS: I know that this is a little bit of a reversal for me, but I begin >> to see the advantages of bug trackers even if they are not blessed >> with perfect interfaces. Does the McCLIM project have one, and if not >> would there be objections simply to turning on Trac on common-lisp.net? > See http://intertwingly.net/blog/2008/07/18/Life-after-Bug-Tracking-Systems Heh. I think the value of a bug tracking system increases as the inverse of the number of people who have the knowledge and the time to deal with bug reports. Why? Because if there's someone, or more than one, who looks at a bug report and either fixes it or ignores it, the problem has essentially gone away: either the bug is gone or it probably wasn't that important in the larger scheme of things. What we have in McCLIM now is \epsilon active developers. This makes a bug tracker infinitely more useful, because it can then act (if people get on board, anyway; that's usually the difficult bit) as a repository of knowledge, even if that knowledge is "this doesn't work" -- and when the blue moon in the month of Sundays comes around and someone has some time to spend on fixing something (because, say, they're using McCLIM in some random project of theirs), less time needs to be spent wondering what it was in the first place that wasn't working any more. Of course, my perception is coloured by the fact that, at least this month, it's me who's finding bugs, hacking around them, wondering whether what I'm fixing is actually a bug rather than someone's intentional behaviour, and generally getting all angsty that people might think that I'm taking responsibility... > :) Bah. Looks like you're having way to much fun. Best, Christophe