From ikojba at gmail.com  Fri Nov  2 07:24:27 2012
From: ikojba at gmail.com (Joop Kiefte)
Date: Fri, 2 Nov 2012 08:24:27 +0100
Subject: [mcclim-devel] Official repository lagging?
In-Reply-To: <E2D7C869-E0BE-403E-BEB1-0AA919E1934B@mikemac.com>
References: <87hars3d4f.fsf@ledu-giraud.fr> <50373DF8.2050809@bricoworks.com>
	<37CD1795-0330-4219-9BCC-7F168791780F@constantly.at>
	<87mx1ky2sw.fsf@ledu-giraud.fr>
	<CAOQbT=Ntmt602hDY1eLAKP4i+b2c=hO1b+sXT6Z1gHGU8+Qs7Q@mail.gmail.com>
	<E2D7C869-E0BE-403E-BEB1-0AA919E1934B@mikemac.com>
Message-ID: <CAAF677V5EXi6E+_jSDHFh1utcntavi-AOz+qqe714yP=eBibrg@mail.gmail.com>

After exporting to CVS, if you put it on github you can use a
subversion-client to access it iirc (they implemented that once as an april
fool joke, but it seems to really work). The only problem is that you have
Subversion's disadvantages: you need constant internet access to commit.
But that is only for the people that don't manage to make the step to git
and choose to use subversion on the repository.


2012/11/1 Michael McDonald <mikemac at mikemac.com>

>
> Personally, I hate 'git'. My old brain has a far easier time making the
> correct mental model for CVS or SVN than 'git'. But that's me.
>
> If you do decide to move to 'git', or anything else for that matter, then
> I STRONGLY suggest you do it in a fashion whereby you do NOT lose the
> history of the files. There's a lot of valuable info in the commit messages
> and the version trees. Just taking the top of trunk from CVS and making a
> 'git' repo from it is not acceptable in my opinion.
>
> Michael McDonald
> mikemac at mikemac.com
>
> On Oct 31, 2012, at 2:19 PM, John Morrison wrote:
>
> Hi;
>
> I also would like to see a single official repository, whether git/github
> or otherwise, with continued incorporation of patches/improvements.  (Some
> time ago I submitted patches for the scigraph portion of mcclim which I
> would have liked to seen included.)  Has there been any movement on this,
> especially as regards quicklisp?
>
> If there is anything I can do to help, I would certainly be happy to do
> so.  Please advise.
>
> Thanks!
>
> -jm
>
> On Fri, Aug 24, 2012 at 6:58 AM, Manuel Giraud <manuel at ledu-giraud.fr>wrote:
>
>> Rudolf Schlatte <rudi at constantly.at> writes:
>>
>> > On Aug 24, 2012, at 10:40, Timothy Moore <moore at bricoworks.com> wrote:
>> >
>> >> I was going to save this mail until my current round of mcclim hacking
>> is finished, but here
>> >> goes. I'm not particularly interested in continuing to work with CVS.
>> Are people agreeable
>> >> with moving to git? I'm not invested (at all) in having my github repo
>> become the "official"
>> >> repo, but a site like github has a lot of advantages as a host.
>> >
>> > I'm very much in favor of moving to git.  git-svn works well enough
>> > for upstream svn archives, but syncing back and forth with cvs is
>> > always uncomfortable for me.
>> >
>> > But could we leave the "official" git archive on common-lisp.net?  I
>> > like github, but when I'm checking out a project that I'm unfamiliar
>> > with, I hate having to decide between downloading (for the sake of
>> > example) onixie/mcclim, slyrus/mcclim, mmontone/mcclim and
>> > timoore/mcclim.
>>
>> Same here. I'm too in favor to switch to git (which is clearly easier
>> than CVS) but keeping the official mcclim repository where the project
>> is seems better to me. github is cool, fun, social and whatnot but I
>> find it hard to get an official software out of it.
>>
>> --
>> Manuel Giraud
>>
>> _______________________________________________
>> mcclim-devel mailing list
>> mcclim-devel at common-lisp.net
>> http://lists.common-lisp.net/cgi-bin/mailman/listinfo/mcclim-devel
>>
>
> _______________________________________________
> mcclim-devel mailing list
> mcclim-devel at common-lisp.net
> http://lists.common-lisp.net/cgi-bin/mailman/listinfo/mcclim-devel
>
>
>
>
>
> _______________________________________________
> mcclim-devel mailing list
> mcclim-devel at common-lisp.net
> http://lists.common-lisp.net/cgi-bin/mailman/listinfo/mcclim-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/mcclim-devel/attachments/20121102/27955891/attachment.html>

From moore at bricoworks.com  Fri Nov  2 07:35:27 2012
From: moore at bricoworks.com (Timothy Moore)
Date: Fri, 02 Nov 2012 08:35:27 +0100
Subject: [mcclim-devel] Official repository lagging?
In-Reply-To: <E2D7C869-E0BE-403E-BEB1-0AA919E1934B@mikemac.com>
References: <87hars3d4f.fsf@ledu-giraud.fr> <50373DF8.2050809@bricoworks.com>
	<37CD1795-0330-4219-9BCC-7F168791780F@constantly.at>
	<87mx1ky2sw.fsf@ledu-giraud.fr>
	<CAOQbT=Ntmt602hDY1eLAKP4i+b2c=hO1b+sXT6Z1gHGU8+Qs7Q@mail.gmail.com>
	<E2D7C869-E0BE-403E-BEB1-0AA919E1934B@mikemac.com>
Message-ID: <509377BF.1030009@bricoworks.com>

On 11/01/2012 12:11 AM, Michael McDonald wrote:
> 
> Personally, I hate 'git'. My old brain has a far easier time making the correct mental model for CVS or SVN than 'git'. But that's me.
> 
> If you do decide to move to 'git', or anything else for that matter, then I STRONGLY suggest you do it in a fashion whereby you do NOT lose the history of the files. There's a lot of valuable info in the commit messages and the version trees. Just taking the top of trunk from CVS and making a 'git' repo from it is not acceptable in my opinion.
> 
People who maintain their own git repos seem to have started by cloning Andreas Fuchs' mirror, which has a complete history:

commit 3cb03ba6a0bfbd54e5076b20b627905d5517f043
Author: Mike McDonald <mikemac>
Date:   Thu Jun 8 22:01:12 2000 +0000

    Initial check-in

I admit that I forget how to extract the same information out of CVS, but it looks good to me.

Tim

> Michael McDonald
> mikemac at mikemac.com <mailto:mikemac at mikemac.com>
>  commit 3cb03ba6a0bfbd54e5076b20b627905d5517f043
Author: Mike McDonald <mikemac>
Date:   Thu Jun 8 22:01:12 2000 +0000

    Initial check-in

> On Oct 31, 2012, at 2:19 PM, John Morrison wrote:
> 
>> Hi;
>>
>> I also would like to see a single official repository, whether git/github or otherwise, with continued incorporation of patches/improvements.  (Some time ago I submitted patches for the scigraph portion of mcclim which I would have liked to seen included.)  Has there been any movement on this, especially as regards quicklisp?
>>
>> If there is anything I can do to help, I would certainly be happy to do so.  Please advise.
>>
>> Thanks!
>>
>> -jm
>>
>> On Fri, Aug 24, 2012 at 6:58 AM, Manuel Giraud <manuel at ledu-giraud.fr <mailto:manuel at ledu-giraud.fr>> wrote:
>>
>>     Rudolf Schlatte <rudi at constantly.at <mailto:rudi at constantly.at>> writes:
>>
>>     > On Aug 24, 2012, at 10:40, Timothy Moore <moore at bricoworks.com <mailto:moore at bricoworks.com>> wrote:
>>     >
>>     >> I was going to save this mail until my current round of mcclim hacking is finished, but here
>>     >> goes. I'm not particularly interested in continuing to work with CVS. Are people agreeable
>>     >> with moving to git? I'm not invested (at all) in having my github repo become the "official"
>>     >> repo, but a site like github has a lot of advantages as a host.
>>     >
>>     > I'm very much in favor of moving to git.  git-svn works well enough
>>     > for upstream svn archives, but syncing back and forth with cvs is
>>     > always uncomfortable for me.
>>     >
>>     > But could we leave the "official" git archive on common-lisp.net <http://common-lisp.net/>?  I
>>     > like github, but when I'm checking out a project that I'm unfamiliar
>>     > with, I hate having to decide between downloading (for the sake of
>>     > example) onixie/mcclim, slyrus/mcclim, mmontone/mcclim and
>>     > timoore/mcclim.
>>
>>     Same here. I'm too in favor to switch to git (which is clearly easier
>>     than CVS) but keeping the official mcclim repository where the project
>>     is seems better to me. github is cool, fun, social and whatnot but I
>>     find it hard to get an official software out of it.
>>
>>     --
>>     Manuel Giraud
>>
>>     _______________________________________________
>>     mcclim-devel mailing list
>>     mcclim-devel at common-lisp.net <mailto:mcclim-devel at common-lisp.net>
>>     http://lists.common-lisp.net/cgi-bin/mailman/listinfo/mcclim-devel
>>
>>
>> _______________________________________________
>> mcclim-devel mailing list
>> mcclim-devel at common-lisp.net <mailto:mcclim-devel at common-lisp.net>
>> http://lists.common-lisp.net/cgi-bin/mailman/listinfo/mcclim-devel
> 
> 
> 
> 
> 
> _______________________________________________
> mcclim-devel mailing list
> mcclim-devel at common-lisp.net
> http://lists.common-lisp.net/cgi-bin/mailman/listinfo/mcclim-devel
> 




From john.nmi.morrison at gmail.com  Fri Nov  2 21:13:34 2012
From: john.nmi.morrison at gmail.com (John Morrison)
Date: Fri, 2 Nov 2012 17:13:34 -0400
Subject: [mcclim-devel] how to track down apparent memory leaks in drawing?
Message-ID: <201211021713.35236.john.nmi.morrison@gmail.com>

Hi All;

tl:dr; slightly revised drawing-benchmark demo (attached) from
quicklisp mcclim shows increased (leaked?) memory usage.

I am using McCLIM to deal with PostGIS (FC16, x86_64).  It appeared
that drawing vector GIS data using draw-line* leaked memory.

After doing the obvious things (see below), I slightly modified the
clim-demo::drawing-benchmark app to try and produce the smallest code
that exhibits the behavior:

1. draw lines instead of either rectangles or text
2. for 20 seconds rather than 1
3. print SBCL's (room) into the window (make your mapped window tall)
4. run a (sb-ext:gc)
5. print (room) again

lather, rinse, and repeat, by hitting the "Run" button.

I obviously didn't use the presentation system in my program (as I
presumed it would hold onto output records, etc.).  I commented out
the single draw-line* form, and that enabled my program to traverse
the entire (rather large) GIS vector dataset with no perceptible
increase in memory usage (according to the "top" UNIX utility rather
than (room).  I updated to today's SBCL (maybe it's a bug that's been
fixed), but I still observed the increasing memory usage.

Questions:

(a) Should I try any of the several forked McCLIMs mentioned recently?
Has any of them had significant work in the simple drawing area?

(b) Can anybody tell me anything that might shorten the hunt?

Thanks!!!

-jm

-- 
--- John Morrison
--- john.nmi.morrison at gmail.com
-------------- next part --------------
;;; -*- Mode: Lisp; -*-

;;;  (c) 2006 David Lichteblau (david at lichteblau.com)

;;; This library is free software; you can redistribute it and/or
;;; modify it under the terms of the GNU Library General Public
;;; License as published by the Free Software Foundation; either
;;; version 2 of the License, or (at your option) any later version.
;;;
;;; This library is distributed in the hope that it will be useful,
;;; but WITHOUT ANY WARRANTY; without even the implied warranty of
;;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
;;; Library General Public License for more details.
;;;
;;; You should have received a copy of the GNU Library General Public
;;; License along with this library; if not, write to the 
;;; Free Software Foundation, Inc., 59 Temple Place - Suite 330, 
;;; Boston, MA  02111-1307  USA.

(in-package :clim-demo)

(define-application-frame drawing-benchmark ()
    ()
  (:panes
   (canvas :application
	   :min-width 600
	   :incremental-redisplay nil
	   :display-time nil)
   (mode
    (with-radio-box ()
      (radio-box-current-selection
       (make-pane 'toggle-button :label "lines" :id :lines))
      (make-pane 'toggle-button :label "rectangle" :id :rectangle)
      (make-pane 'toggle-button :label "text" :id :text)))
   (ink
    (with-radio-box ()
      (radio-box-current-selection
       (make-pane 'toggle-button :label "random" :id :random))
      (make-pane 'toggle-button :label "red" :id +red+)
      (make-pane 'toggle-button :label "flipping ink" :id +flipping-ink+))))
  (:layouts
   (default
       (vertically ()
	 (horizontally ()
	   (labelling (:label "Mode") mode)
	   (labelling (:label "Ink") ink))
	 canvas))))

(defmethod run-drawing-benchmark (frame stream)
  (setf (stream-recording-p stream) nil)
  (window-clear stream)
  (let* ((width (rectangle-width (sheet-region stream)))
	 (height (rectangle-height (sheet-region stream)))
	 (mode (gadget-id (gadget-value (find-pane-named frame 'mode))))
	 (ink (gadget-id (gadget-value (find-pane-named frame 'ink))))
	 (itups internal-time-units-per-second)
	 (n 0)
	 (start (get-internal-real-time))
	 (stop (+ start (* 20 itups))))
    (do ()
	((>= (get-internal-real-time) stop))
      (incf n)
      (let ((ink
	     (if (eq ink :random)
		 (clim:make-rgb-color (random 1.0d0)
				      (random 1.0d0)
				      (random 1.0d0))
		 ink)))
	(ecase mode
	  (:lines
	    (draw-line* stream
			     10 10 40 40
			     :ink ink))
	  (:rectangle
	    (draw-rectangle* stream
			     10 10 (- width 10) (- height 10)
			     :ink ink
			     :filled t))
	  (:text
	    (dotimes (x 10)
	      (draw-text* stream
			  "Bla blub hastenichgesehen noch viel mehr Text so fuellen wir eine Zeile."
			  0
			  (* x 20)
			  :ink ink))))))
    (finish-output stream)
    (medium-finish-output (sheet-medium stream))
    (climi::port-force-output (car climi::*all-ports*))
    (setf stop (get-internal-real-time))
    (window-clear stream)
    (setf (stream-recording-p stream) t)
    (room)
    (sb-ext:gc)
    (room)
    (format stream "Score: ~A operations/s~%"
	    (float (/ n (/ (- stop start) itups))))))

(define-drawing-benchmark-command (com-quit-drawing-benchmark :menu "Quit") ()
  (frame-exit *application-frame*))

(define-drawing-benchmark-command (com-run-drawing-benchmark :menu "Run") ()
  (run-drawing-benchmark *application-frame*
			 (frame-standard-output *application-frame*)))

From john.nmi.morrison at gmail.com  Wed Nov 14 21:21:44 2012
From: john.nmi.morrison at gmail.com (John Morrison)
Date: Wed, 14 Nov 2012 16:21:44 -0500
Subject: [mcclim-devel] Official repository lagging?
In-Reply-To: <E2D7C869-E0BE-403E-BEB1-0AA919E1934B@mikemac.com>
References: <87hars3d4f.fsf@ledu-giraud.fr>
	<CAOQbT=Ntmt602hDY1eLAKP4i+b2c=hO1b+sXT6Z1gHGU8+Qs7Q@mail.gmail.com>
	<E2D7C869-E0BE-403E-BEB1-0AA919E1934B@mikemac.com>
Message-ID: <201211141621.44995.john.nmi.morrison@gmail.com>

Was there ever a resolution to this?  I have some bugfix/modernization
patches to scigraph made against the old CVS repo, and I think I might
need to make more, and it would be cool to know where the "official"
repo is so as to minimize forking.

-jm

On Wednesday 31 October 2012, Michael McDonald wrote:
> Personally, I hate 'git'. My old brain has a far easier time making the
> correct mental model for CVS or SVN than 'git'. But that's me.
> 
> If you do decide to move to 'git', or anything else for that matter, then I
> STRONGLY suggest you do it in a fashion whereby you do NOT lose the
> history of the files. There's a lot of valuable info in the commit
> messages and the version trees. Just taking the top of trunk from CVS and
> making a 'git' repo from it is not acceptable in my opinion.
> 
> Michael McDonald
> mikemac at mikemac.com
> 
> On Oct 31, 2012, at 2:19 PM, John Morrison wrote:
> > Hi;
> > 
> > I also would like to see a single official repository, whether git/github
> > or otherwise, with continued incorporation of patches/improvements. 
> > (Some time ago I submitted patches for the scigraph portion of mcclim
> > which I would have liked to seen included.)  Has there been any movement
> > on this, especially as regards quicklisp?
> > 
> > If there is anything I can do to help, I would certainly be happy to do
> > so.  Please advise.
> > 
> > Thanks!
> > 
> > -jm
> > 
> > On Fri, Aug 24, 2012 at 6:58 AM, Manuel Giraud <manuel at ledu-giraud.fr>
> > wrote:
> > 
> > Rudolf Schlatte <rudi at constantly.at> writes:
> > > On Aug 24, 2012, at 10:40, Timothy Moore <moore at bricoworks.com> wrote:
> > >> I was going to save this mail until my current round of mcclim hacking
> > >> is finished, but here goes. I'm not particularly interested in
> > >> continuing to work with CVS. Are people agreeable with moving to git?
> > >> I'm not invested (at all) in having my github repo become the
> > >> "official" repo, but a site like github has a lot of advantages as a
> > >> host.
> > > 
> > > I'm very much in favor of moving to git.  git-svn works well enough
> > > for upstream svn archives, but syncing back and forth with cvs is
> > > always uncomfortable for me.
> > > 
> > > But could we leave the "official" git archive on common-lisp.net?  I
> > > like github, but when I'm checking out a project that I'm unfamiliar
> > > with, I hate having to decide between downloading (for the sake of
> > > example) onixie/mcclim, slyrus/mcclim, mmontone/mcclim and
> > > timoore/mcclim.
> > 
> > Same here. I'm too in favor to switch to git (which is clearly easier
> > than CVS) but keeping the official mcclim repository where the project
> > is seems better to me. github is cool, fun, social and whatnot but I
> > find it hard to get an official software out of it.
> > 
> > --
> > Manuel Giraud
> > 
> > _______________________________________________
> > mcclim-devel mailing list
> > mcclim-devel at common-lisp.net
> > http://lists.common-lisp.net/cgi-bin/mailman/listinfo/mcclim-devel
> > 
> > _______________________________________________
> > mcclim-devel mailing list
> > mcclim-devel at common-lisp.net
> > http://lists.common-lisp.net/cgi-bin/mailman/listinfo/mcclim-devel


-- 
--- John Morrison
--- john.nmi.morrison at gmail.com



From john.nmi.morrison at gmail.com  Wed Nov 14 21:26:08 2012
From: john.nmi.morrison at gmail.com (John Morrison)
Date: Wed, 14 Nov 2012 16:26:08 -0500
Subject: [mcclim-devel] how to track down apparent memory leaks in
	drawing?
In-Reply-To: <201211021713.35236.john.nmi.morrison@gmail.com>
References: <201211021713.35236.john.nmi.morrison@gmail.com>
Message-ID: <201211141626.14910.john.nmi.morrison@gmail.com>

tl:dr; never mind.

I didn't understand the circumstances of output-record generation.  I
needed to try harder to get the pane/stream to not record output.
Works fine now (millions of drawing operations with no perceptible
long-term memory use).  Sorry.

-jm

On Friday 02 November 2012, John Morrison wrote:
> Hi All;
> 
> tl:dr; slightly revised drawing-benchmark demo (attached) from
> quicklisp mcclim shows increased (leaked?) memory usage.
> 
> I am using McCLIM to deal with PostGIS (FC16, x86_64).  It appeared
> that drawing vector GIS data using draw-line* leaked memory.
> 
> After doing the obvious things (see below), I slightly modified the
> clim-demo::drawing-benchmark app to try and produce the smallest code
> that exhibits the behavior:
> 
> 1. draw lines instead of either rectangles or text
> 2. for 20 seconds rather than 1
> 3. print SBCL's (room) into the window (make your mapped window tall)
> 4. run a (sb-ext:gc)
> 5. print (room) again
> 
> lather, rinse, and repeat, by hitting the "Run" button.
> 
> I obviously didn't use the presentation system in my program (as I
> presumed it would hold onto output records, etc.).  I commented out
> the single draw-line* form, and that enabled my program to traverse
> the entire (rather large) GIS vector dataset with no perceptible
> increase in memory usage (according to the "top" UNIX utility rather
> than (room).  I updated to today's SBCL (maybe it's a bug that's been
> fixed), but I still observed the increasing memory usage.
> 
> Questions:
> 
> (a) Should I try any of the several forked McCLIMs mentioned recently?
> Has any of them had significant work in the simple drawing area?
> 
> (b) Can anybody tell me anything that might shorten the hunt?
> 
> Thanks!!!
> 
> -jm


-- 
--- John Morrison
--- john.nmi.morrison at gmail.com