--- Log opened Wed Apr 18 00:00:00 2007
00:02 -!- zotz [n=zotz@24.244.163.157] has quit ["Leaving"]
01:06 -!- pabs3 [i=daemon@mail.inpho.com.au] has joined #synfig
03:08 -!- pxegeek [n=chatzill@c-71-59-140-184.hsd1.or.comcast.net] has joined #synfig
03:29 < pxegeek> Hi Pabs!
03:30 < pabs3> heya :)
03:30  * pabs3 at work
03:30 < pxegeek> Enjoying it?
03:31 < pxegeek> I won't keep you then. Take a look at the new icons when you get a chance
--- Log closed Wed Apr 18 03:54:51 2007
--- Log opened Wed Apr 18 07:27:28 2007
07:27 -!- dooglus [n=dooglus@rincevent.net] has joined #synfig
07:27 -!- Irssi: #synfig: Total of 13 nicks [1 ops, 0 halfops, 0 voices, 12 normal]
07:27 -!- Irssi: Join to #synfig was synced in 31 secs
08:02 < dooglus> I found a way of fixing the rendering of curve gradients, but it's quite slow.
08:03 < dooglus> I was thinking I could check it in as an extra parameter on the curve gradient layer - what do you think?
08:03 < dooglus> See http://dooglus.rincevent.net/synfig/gradient.html#fast for screenshots of before/after
08:03 < igli> heh saw that dooglus looked nice. maybe i could help with optimising bits if you like?
08:04 < dooglus> igli: the problem is, it's having to solve a 5th-degree polynomial for each pixel in the image
08:05 < dooglus> I don't think there's a general solution for that, is there?
08:05 < igli> ew that sounds wrong?
08:05 < dooglus> and so it's iterating
08:05 < dooglus> it needs to find which point on a bezier curve is closest to each point in the canvas
08:06 < igli> well even if we have to use that algorithm, we should be able to reduce cycles.
08:06 < igli> hmm i left you a msg about that in away log; first guess is annealing, altho i don't like it personally.
08:06 < dooglus> I saw that
08:06 < dooglus> but I don't know what that means, and the "i don't like it" put me off looking it up - if you don't like it, why should I?  :)
08:07 < igli> lol
08:07 < igli> it's the standard technique for graphs like the one on your pages, to get out of a local min/maximum and hopefully find the global one.
08:07 < dooglus> the existing code decides which bezier is closest by looking at just 7 points on each bezier, and picking the line which is closest from that sample.  that can obviously get the wrong line sometimes
08:07 < igli> or at least a better one
08:08 < igli> hmm since we draw the bezier, we know all the points
08:08 < dooglus> well, we can calculate them all - but that takes time
08:08 < igli> even with just control points, we have a bounding box which we should be able to project to i'd think?
08:09 < igli> could be wrong (coming from 3D here)
08:10 < igli> hmm need to scribble something i guess
08:11 < dooglus> my solution was based on this code: http://www.acm.org/tog/GraphicsGems/gems/NearestPoint.c
08:12 < igli> nice one!
08:12 < igli> looks perfect to me?
08:13 < dooglus> it works fine - but it's a lot slower than the existing code
08:13 < igli> Given a 5th-degree equation in Bernstein-Bezier form, find all of the roots in the interval [0, 1].
08:14 < igli> heh that's the bit that needs speeding up?
08:14 < dooglus> it does it by recursively dividing the [0,1] interval into 2 halves
08:14 < dooglus> yes
08:14  * igli nods: please go over it
08:14 < igli> heh thought it would be recursive
08:14 < dooglus> see the FindRoots() function, and how it calls itself twice:
08:14 < dooglus>     left_count  = FindRoots(Left,  degree, left_t, depth+1);
08:14 < dooglus>     right_count = FindRoots(Right, degree, right_t, depth+1);
08:16 < igli> yeah looking at. it has to be 5th-degree? (this is all a bit new to me atm)
08:16 < dooglus> I believe so
08:17 < igli> just cos it has the #define
08:17 < igli> brb (phone)
08:18 < dooglus> "To quote Press, et al., in _Numerical Methods in C_, "There are *no* good,
08:18 < dooglus> general methods for solving systems of more than one nonlinear equation ...
08:18 < dooglus> there *never will be* any good, general methods ..."
08:19 < dooglus> http://groups.google.com/group/comp.graphics.algorithms/browse_thread/thread/19105107cae8b40b/6495ca69427e3b60?lnk=gst&rnum=1#6495ca69427e3b60
08:21 < dooglus> the #define can be used to make the code work for higher order bezier curves
08:21 < dooglus> synfig uses cubic bezier curves (4 control points)
08:26 < igli> hmm well cubic is 3 no- or am i missing something? (wouldn't be the first time :)
08:26 < dooglus> "3 no-"?
08:27 < igli> er cubic is equation in 3 ?
08:28  * igli checks url
08:29 < dooglus> it takes 2 points to define a line, even though a linear is "equation in 1"
08:30 < dooglus> similarly it takes 4 points to define a cubic curve
08:30 < igli> sure got the def'n of bezier via control points.
08:30 < igli> In 2D, for example, the x(t) and y(t) polynomials bear no relation to each 
08:30 < igli>  other at all.  Nothing less than mapping the full range of a 3-dimensional 
08:30 < igli>  surface will do.  Bisection does this efficiently by discarding big hunks 
08:30 < igli>  at once. 
08:30 < igli> sorry for paste
08:31 < igli> just putting up stuff to think over ;)
08:31 < dooglus> it's fine - this is hardly a high-volumne channel )
08:31 < dooglus> :)
08:31 < igli> heh nice one :D
08:32 -!- spaceinvader [n=server@unaffiliated/spaceinvader] has joined #synfig
08:32  * dooglus hides under a base
08:33 < igli> dooglus: meet spaceinvader, he's hot with C
08:33 < spaceinvader> ALL YOUR BASE ARE BELONG TO US
08:33 < igli> lol
08:33 < spaceinvader> erm, i mean hi
08:33 < igli> all your *data* are belong to us (TM) silly ;)
08:33 < igli> all your *data* belongs to us (TM) ;)
08:33  * dooglus counts to 23
08:34 < spaceinvader> noo he was hiding under base
08:34 < igli> sorry man
08:34 < igli> oic
08:35 < igli> spaceinvader: did you look at the C - http://www.acm.org/tog/GraphicsGems/gems/NearestPoint.c
08:35 < dooglus> are there any obvious inefficiencies in it?
08:35 < igli> dooglus: tbh the first thing i'd try is changing that define and see what happens
08:35 < spaceinvader> i have to go soon so i didnt boot my laptop
08:35 < spaceinvader> serial terminal++
08:35 < igli> it's the quickest thing to try
08:35 < dooglus> would it be significantly sped up if the recursion was replaced with a loop?
08:36 < spaceinvader> what does it use?
08:36 < dooglus> igli: change it to what?
08:36 < igli> thing is some problems need recursion, i haven't looked at it properly yet.
08:36 < igli> dooglus: i'd bring it down one at a time and see what difference it made to the output
08:37 < dooglus> igli: you mean #defineW_DEGREE 5/*  Degree of eqn to find roots of */ ?
08:38 < igli> yeah that one. try it all the way down to 1 since it's so trivial to change it, imo. only on one test case.
08:41 < igli> int MAXDEPTH = 64; # that should be #define and you can try halving it etc
08:41 < igli> #define will make it quicker in and of itself
08:42 < igli> 64 48 32 .. would be a good test
08:43 < igli> that one will make the most difference in run-time imo
08:43 < dooglus> reducing W_DEGREE to 4 from 5: http://dooglus.rincevent.net/synfig/1176878546.png
08:43 < dooglus> messes things right up
08:43 < igli> lol
08:43 < dooglus> I tried various values for MAXDEPTH
08:43 < igli> yeah awful, change MAX_DEPTH then
08:43 < igli> ok
08:44 < dooglus> it doesn't make a lot of difference to the speed
08:44 < igli> yeah i'd imagine it doesn't get hit very often then. hmm
08:44 < dooglus> MAXDEPTH=6 is still very slow, and also gives poor results
08:44 < dooglus> there's very little difference in speed between MAXDEPTH=32 and 64
08:44 < dooglus> probably because the recursion bottoms out before it gets that deep
08:44 < igli> ok np then
08:44 < igli> yeah
08:45 < igli> changing to define will at least take out one access in the unoptimised case. i don't know what CFLAGS people use i thought -O1 which should sort that tbh,
08:46 < igli> minor point for this.
08:47 < igli> spaceinvader: you still there; we can send the C file if you like?
08:49 < dooglus> what does seem to make it faster without breaking the output is to make EPISON bigger
08:49 < dooglus> EPSILON
08:51 < igli> really? cool.
08:51 < igli> why do you think that is?
08:53 < igli> if (error < EPSILON) {
08:53 < dooglus> EPSILON is the other thing that controls how deep it recurses
08:53 < igli> it's allowingmore stuff to count as successful
08:53 < dooglus> it recurses to a depth of MAXDEPTH, or until the error is < EPSILON
08:53 < dooglus> right
08:53 < dooglus> and I can see slight errors in the render
08:53 < igli> ah
08:54 < igli> maybe have it as a config then
08:54 < igli> so preview is rough, final render is solid.
08:54 < igli> ?
08:54 < igli> but yeah, we should make it a loop. lots of malloc fun :D
08:55  * igli would rather sort the C version than use constructors
08:56 < dooglus> I removed all the malloc and free calls already
08:59 < dooglus> here's my version: http://dooglus.rincevent.net/synfig/_bezier.h
08:59 < igli> cool :D
09:01 < igli> we'll need to use malloc if we want to do it non-recursively i think. alloca might be quicker tho. hmm glib has all that stuff sorted if we need it.
09:03 < igli> where is affine_func() defined?
09:05 < dooglus> oh, most of that file is pre-existing synfig stuff
09:05 < dooglus> I just added in the NearestPointOnCurve stuff at the end
09:05 < dooglus> don't worry about all the other stuff in there
09:05 < igli> ok, i'd still like to see it, if i'm going to help out at all ;)
09:06 < igli> i'm curious tbh; it must be from ETL since those are the only includes?
09:06 < igli> well it says any system, so it's probably from system, sorry.
09:10 < dooglus> I don't know where it is - I can't find it
09:11 < igli> don't worry i'm just asking questions atm :)
09:11 < dooglus> I guess "affine_combo<value_type,time_type> affine_func;" is its definition, as well as its declaration
09:11 < dooglus> that must result in its default constructor being called
09:13 < dooglus> see http://svn.voria.com/code/ETL/trunk/ETL/_curve_func.h for template <class T, class K=float> struct affine_combo{};
09:13 < igli> lovely :D
09:14 < igli> well we can definitely optimise the array copies out, that's a complete waste of time. no wonder it runs slowly.
09:15 < dooglus> where?
09:15 < igli> probably some functional programmer, or someone fed up of 'em ;)
09:15 < igli> ll 232-8 (Gather sol'ns)
09:17 < dooglus> in the C code?
09:17 < dooglus> or bezier.h?
09:17 < igli> yeah, we can pre-alloc (MAXDEPTH*W_DEGREE) for a start (or maybe W_DEGREE+1 not sure why they do that.)
09:18 < igli> something along those lines, not sure of exact numbers basically :D
09:19 < igli> hmm do you mind if i bring in friendlyToaster, and we can work on adding synfig/ETL dox to him? would be useful imo.
09:21 < igli> sorry it's just i can't say !tea in here ;)
09:21 < dooglus> go ahead
09:22 < igli> eg: 
09:22 < igli> !php SWFShape.drawCurveTo
09:22 < igli> [08:18] <friendlyToaster> class SWFShape { int drawCurveTo(int controlx, int controly, int anchorx, int anchory [, int targetx, int targety]) } # Draws a quadratic curve (using the current line style, set by swfshape->setline) from the current pen position to (anchorx,anchory) using (controlx,controly) as a control point. That is, head towards the control point, then smoothly turn to th... http://www.php.net/manual/en/function.swfshape.drawcurveto.php
09:22 < igli> thanks
09:22 -!- friendlyToaster [n=toaster@82.152.195.77] has joined #synfig
09:22 < igli> i'm working on a new version, but this is stable
09:23 < igli> !version
09:23 < friendlyToaster> FriendlyToaster V6a, maintained by igli and fragalot
09:23 < igli> adding a doc module for synfig won't be hard, just a bit tedious i reckon.
09:24 < igli> hmm that php function looks quite interesting actually :D
09:25 < igli> just thinking about SWF output; has synfig got that already?
09:25 < dooglus> no
09:26 < igli> anyone working on it?
09:27 < igli> if not, wouldn't mind doing that module. be a good way to learn your api too.
09:28 < igli> you'd have to help a lot tho dooglus ;) dunno if you're up for it.
09:29 < pabs3> no-one has started on it (or SVG) AFAIK
09:30 < igli> ooh SVG would be fun too. i'll only write C that you guys can call tho.
09:30 < igli> which means you have to spec the functionality dooglus.
09:33 < dooglus> I don't think anyone knows the synfig api :)
09:33 < igli> hehe
09:33 < dooglus> the source code is all available in svn - so it's possible to work things out
09:33 < igli> !php SWFMovie
09:33 < friendlyToaster> SWFMovie swfmovie(void) # Swfmovie creates a new movie object, representing an SWF version 4 movie. * EXPERIMENTAL * http://www.php.net/manual/en/function.swfmovie.php
09:33 < igli> ^ might be handy for animations
09:33 < dooglus> it's mostly marked up for doxygen too, so you can use that, too
09:34 < igli> sure, but you're going to have to help me with gluing it in, or i'll fail.
09:35 < igli> :oops: http://www.php.net/manual/en/ming.swfmovie.php
09:35 < igli> hmm that other one should have been marked EXPERIMENTAL too (had too much info for one line, so it got chopped.) least the url worked..
09:41 < dooglus> flv and svg output would be new modules, going into svn/synfig-core/src/modules/mod_{svg,flv}
09:41 < dooglus> there are a few other modules you can look at for examples of how things are connected in
09:41 < igli> tsk tsk ;)
09:41 < igli> so long as i can pick your brains, i'm cool dooglus :D
09:45 < dooglus> ok
09:47 < igli> hmm one other thing: does synfig use wX? (i know i can dig thru src, but i can also ask you lots of q's quickly which helps me a lot ;)
09:52 < dooglus> is that the python gtk interface thing?
09:52 < dooglus> synfig uses gtkmm
09:53 < igli> i thought it ran on doze tho?
09:54 < dooglus> yes
09:54 < dooglus> gtkmm is available for windows
09:55 < dooglus> http://www.gtkmm.org/docs/gtkmm-2.4/docs/tutorial/html/ch02s03.html
09:55 < dooglus> GTK+ and gtkmm were designed to work well with Microsoft Windows, and the developers encourage its use on the win32 platform.
09:55 < igli> oh ok, just that wX is a nicer toolkit imo; native look on Win
09:55 < igli> not pertinent, sorry
09:55 < igli> er what i'm saying that is :)
09:56 < dooglus> :)
10:12 < pabs3> yo dooglus 
10:12 < pabs3> notice the CIA bot?
10:24 < dooglus> yes
10:24 < dooglus> know anything about it?
10:25 < pabs3> darco set it up today. there is a delay before changes show up, cus he set it to poll instead of email for now
10:26 < dooglus> I'm not with you.  What's it do?
10:26 < pabs3> reports changes to our svn repo (and many others) to this channel and #commits (iirc) and the cia.nv website
10:27 < dooglus> oh, good
10:27 < dooglus> cia.vc you mean?
10:28 < pabs3> er, woops, yep
10:28 < dooglus> like 'version control'
10:28 < dooglus> http://cia.vc/stats/project/synfig
10:36  * pabs3 off home
10:36 -!- pabs3 [i=daemon@mail.inpho.com.au] has quit ["Don't rest until all the world is paved in poems."]
10:49 < dooglus> igli: are you interested in trying to speed up that bezier code?
10:49 < dooglus> I can check it what I've got if you want to take a look at it - it works, and defaults to using the old fast-but-wrong code, so I don't think checking it in is a problem
11:06 < igli> yeah cool, give me an hour or so, gotta sort some work out.
11:15 < dooglus> OK, it's commited as revision 472.
11:17 < CIA-12> synfig: dooglus * r472 / (4 files in 4 dirs): Added a slower but more accurate find_closest() routine to _bezier.h. Added a parameter to the curve gradient layer to optionally use the new code.
11:18 < dooglus> ooh, nice.
11:18 < dooglus> in-channel commit notices :)
11:19  * dooglus finally understands what pabs was telling him an hour ago...
11:32 < CIA-12> synfig: dooglus * r473 /synfig-studio/trunk/src/synfigapp/actions/valuenodedynamiclistinsertsmart.cpp: Partially fix 1702760: stop compiler warning about valuenodedynamiclistinsertsmart.cpp.
11:46 < CIA-12> synfig: dooglus * r474 /synfig-core/trunk/src/modules/mod_png/trgt_png.cpp: Partially fix 1702760: stop compiler warning about trgt_png.cpp.
12:01 < CIA-12> synfig: dooglus * r475 /synfig-studio/trunk/src/gtkmm/renderer_canvas.cpp: Partially fix 1702760: stop compiler warning about renderer_canvas.cpp.
12:01 < CIA-12> synfig: dooglus * r476 /synfig-core/trunk/src/modules/ (3 files in 2 dirs): Partially fix 1702760: stop compiler warning about mod_openexr/mptr_openexr.cpp, mod_openexr/trgt_openexr.cpp, and mod_ppm/trgt_ppm.cpp.
12:09 < igli> ooh loverly :D
12:16 < CIA-12> synfig: dooglus * r477 /synfig-studio/trunk/src/gtkmm/dockmanager.cpp: Partially fix 1702760: stop compiler warning about dockmanager.cpp.
12:27 < igli> dooglus: what i don't get is why you don't use the code the same guy posted earlier in the page which is: "a well-tested implementation in 2D"
12:31 < CIA-12> synfig: dooglus * r478 /synfig-studio/trunk/src/gtkmm/dockmanager.cpp: Oops. Correcting previous commit.
12:38 < dooglus> oh, I just used the code I found first.
12:39 < igli> heh :)
12:39 < dooglus> also, the code I used clearly said that it could be "used without restriction"
12:39 < dooglus> I don't know about the other code
12:39 < igli> well, it looks pretty optimised to me.
12:40 < igli> 3 msgs up from that google groups one.
12:43 < dooglus> ok
12:43 < dooglus> have you tried compiling it?
12:43 < dooglus> it's not complete, is it?
12:43 < igli> hmm no haven't sorry
12:45 < igli> there's a } missing at the end if that's what you mean?
12:46 < dooglus> I mean there's no 'struct knot' declared, for a start
12:46 < CIA-12> synfig: dooglus * r479 /synfig-studio/trunk/src/gtkmm/layeractionmanager.cpp: Partially fix 1702760: stop compiler warning about layeractionmanager.cpp.
12:46 < dooglus> there are plenty of '}'s though
12:46 < dooglus> the indentation of the closing '}' is off, but that's no problem
12:47 < igli> :oops:
12:47 < igli> silly me
12:47 < igli> trying compile now
12:48 < igli> hmm we need his type definitions i guess
12:49 < igli> H as well (looks like a macro)
12:50 < dooglus> here's a version which builds: http://dooglus.rincevent.net/synfig/kinch.cpp
12:50 < dooglus> I just added #defines for all the missing things
12:51 < dooglus> I guess 'H' is short for 'halfway between'
12:51 < dooglus> so H(x, y) = (x+y)/2
12:52 < igli> heh could be.. ;) nice one, i'll try it (although it should be .c ;)
12:58 < dooglus> what's a good implementation for max(a, b, c, d)?
12:59 < dooglus> I suppose #define max4(a,b,c,d) max2(max2(a,b),max2(c,d)) is good enough
13:02 < igli> is max2 a macro too?
13:02 < dooglus> I used #define max2(a,b) ((a>b)?a:b)
13:03 < igli> should be fine then
13:03 < dooglus> http://dooglus.rincevent.net/synfig/kinch.cpp is updated
13:25 -!- zotz [n=zotz@24.244.163.157] has joined #synfig
13:49 < dooglus> igli: http://dooglus.rincevent.net/synfig/kinch.cpp works now
13:49 < igli> excellent!
13:51 < igli> can you not make it a C file and put an extern "C" { in #ifdef CPP?
13:51 < dooglus> why would I?
13:51 < dooglus> synfig is c++
13:57 < dooglus> I guess the question now is: is it any faster :)
14:01 < igli> cos it's better form :)
14:01 < igli> well, is it faster?
14:01 < dooglus> I don't know yet
14:01 < dooglus> I think I'll integrate it into synfig and see
14:02 < igli> fingers crossed :)
14:03 < dooglus> the sqrt() here won't help though: #define pdist(x1,y1,x2,y2) sqrt((x1-x2)*(x1-x2)+(y1-y2)*(y1-y2))
14:04 < dooglus> how do you implement pdist (distance between 2 points) without a sqrt?
14:04 < dooglus> I guess it should just deal in distance-squared everywhere instead
14:04 < igli> hmm
14:04 < igli> just try it first with -O1 and see how it goes
14:08 < dooglus> 900k runs: -O0 9.495s   -O1 6.083s   -O0 9.082s   -O1 6.114s   -O0 9.057s
14:11 < dooglus> 900k runs with the graphics gems code:  (still running!)
14:12 < igli> heh
14:12 < igli> those numbers mean nothing to me btw :)
14:13 < igli> also try -ffast-math etc just for that one file
14:13 < dooglus> it's just the time in seconds to find the distance 900,000 times
14:13 < igli> what was the previous code times?
14:13 < igli> were*
14:14 < dooglus> I was running them with different epsilon values, so can't really compare
14:15 < dooglus> using the same epsilon for both:
14:15 < dooglus> previous code 0m11.665s; new code 0m10.302s
14:15 < dooglus> but the new code is using doubles, and the previous code floats
14:15 < igli> hmm :D
14:15 < igli> which CPU are you on?
14:16 < dooglus> it's a 2GHz core duo
14:16 < dooglus> but only using one core
14:16 < igli> EM64T?
14:16 < dooglus> "model name: Genuine Intel(R) CPU           T2500  @ 2.00GHz" if that tells you anything
14:16 < igli> don't think that's 64 bit tbh.
14:17 < igli> i know 3000+ definitely is, and <2500 not
14:17 < igli> if 32 bit, double is twice as large iirc, and a real PITA for efficiency
14:17 < igli> at least, won't fit in reg
14:18 < dooglus> the new code seems a little faster, even though it's using doubles, which should make it slower
14:20 < dooglus> running tests alternately: old 11.908s   new 10.654s   old 11.330s   new 10.789s   old 11.420s   new 10.513s   old 11.229s   new 10.507s   old 11.236s
14:21 < dooglus> switching to float doesn't change much
14:21 < dooglus> 9.8s instead of 10.6
14:30 < igli> hmm
14:31 < igli> can you profile it?
14:33 < dooglus> I'm not even sure it's working now :)
14:35 < dooglus> or rather, it seems to be working, but I've no idea how it can be when one of the crucial lines is commented out!
14:50 < igli> lmao
14:50 < igli> Housemates - Power of music
14:50 < igli> http://195.140.140.187:8010
14:52 < igli> !chill
14:52 < friendlyToaster> Take it easy. You've got somewhere, so now relax, take a walk, have a cuppa, do whatever. You'll think of something new as soon as you take a step back. Well done for getting this far :D
14:52 < igli> :D
14:53 -!- zotz [n=zotz@24.244.163.157] has quit [Read error: 104 (Connection reset by peer)]
15:15 < dooglus> grrr.
15:15 < dooglus> I'm going to have to give up for now - gotta go out.
15:15 < dooglus> the old code and the new code are giving completely different results
15:16 < dooglus> I've obviously got something wrong somewhere, but I'll sort it out later.
15:16 < igli> cool - in a bit ;)
16:43 -!- zipola [n=zipola@zip.kortex.jyu.fi] has joined #synfig
17:08 -!- igli [n=igli@unaffiliated/igli] has quit [Read error: 104 (Connection reset by peer)]
17:17 -!- friendlyToaster [n=toaster@82.152.195.77] has quit [Remote closed the connection]
17:55 -!- darco [n=darco@dsl081-054-146.sfo1.dsl.speakeasy.net] has left #synfig []
19:52 -!- darco [n=darco@dsl081-054-146.sfo1.dsl.speakeasy.net] has joined #synfig
20:33 -!- zipola [n=zipola@zip.kortex.jyu.fi] has quit ["Abiit"]
21:12 -!- omry [n=omry@l85-130-137-23.broadband.actcom.net.il] has quit [Remote closed the connection]
23:13 -!- omry [n=omry@l85-130-137-23.broadband.actcom.net.il] has joined #synfig
23:40 -!- zotz [n=zotz@24.244.163.157] has joined #synfig
--- Log closed Thu Apr 19 00:00:24 2007