--- Log opened Fri Sep 07 00:00:10 2007
--- Day changed Fri Sep 07 2007
00:00 -!- MangoFusion [n=jamesu@host217-44-186-233.range217-44.btcentralplus.com] has quit ["ttg"]
00:04 -!- ZanQdo [n=Daniel@201.201.2.22] has joined #synfig
00:13 -!- xerakko [n=xerakko@debian/developer/xerakko] has quit ["Ex-Chat"]
00:26 -!- zotz [n=zotz@24.244.163.157] has quit ["Leaving"]
00:34 < ulrikboden> good night! d:) 
00:35 < dooglus> 'night :)
00:44 -!- tokyo [n=tokyo@c-67-186-99-98.hsd1.il.comcast.net] has joined #synfig
01:30 -!- Netsplit calvino.freenode.net <-> irc.freenode.net quits: rore, tokyo, Klowner, omry, Gatonegro, Bombe, dyloxin, @ChanServ, jarrwlee, zipola,  (+2 more, use /NETSPLIT to show all of them)
01:31 -!- Netsplit over, joins: Bombe, tokyo, Gatonegro, zipola, Klowner
01:32 -!- Netsplit over, joins: @ChanServ, ZanQdo, jarrwlee, ulrikboden, rore, dyloxin, omry
02:05 -!- Gatonegro [n=denis@79.Red-83-45-233.dynamicIP.rima-tde.net] has quit [Read error: 110 (Connection timed out)]
02:23 -!- pxegeek [n=chatzill@c-71-59-140-184.hsd1.or.comcast.net] has joined #synfig
02:36 < pxegeek> dooglus - you still around?
02:36 < pxegeek> 1:30, probably not...
02:38 < pxegeek> I can export a canvas.  Is there anyway I can import it into another sif file?  Or can I only create sub canvases within the same sif file?
02:48 < dooglus> I am
02:48 < dooglus> and you can
02:48 < dooglus> use File>Import
02:49 < dooglus> you can only import whole .sif files I think, but then you can probably 'unexport' the bits you don't want
02:49 < dooglus> I've not played with it much
02:52 -!- KiBi [n=kibi@maisel-gw.enst-bretagne.fr] has joined #synfig
02:52 < KiBi> o<
02:57 < dooglus> o==O==o
03:11 < KiBi> dooglus: Do you have in mind the event pabs talked about, taking place in an European city, where a synfig demonstrator could be invited?
03:43 -!- rore [n=rore@d77-216-195-13.cust.tele2.fr] has quit [Read error: 110 (Connection timed out)]
03:49 -!- crazy_bus [n=philip@CPE-58-170-30-128.nsw.bigpond.net.au] has joined #synfig
03:55 -!- zotz [n=zotz@24.244.163.157] has joined #synfig
04:07 < pxegeek> KiBi - Sofia, Bulgaria
04:07 < KiBi> pxegeek: Do you by chance have the date in mind?
04:08  * pxegeek says "rasha frasha @#$% @#$%$$#$ $$#@#$ - the stupid thing didn't work the last time I tried that, I swear"
04:09 < pxegeek> KiBi - I don't think there was a date set yet.  Or at least not one communicated.
04:09 < KiBi> Oh, I see. Not even a rough estimation?
04:12 < pxegeek> http://tosmi.org/home/ - looks like they did two sessions this year May and August?
04:13 < pxegeek> I was thinking about it, but would have to figure out my sabbatical plans first to see if it would coincide...
04:13 < KiBi> thanks for the pointer
04:13  * KiBi almost has one.
04:13 < KiBi> (such sabbatical plan)
04:13 < KiBi> \o_ FLOSS internship accepted :)
04:13 < pxegeek> OOohh!  Go you!
04:23  * KiBi is crawling epiphany's bugzilla and planning feature implementations. :)
04:32 -!- crazy_bus [n=philip@CPE-58-170-30-128.nsw.bigpond.net.au] has quit [Remote closed the connection]
04:43 -!- rore [n=rore@d90-144-96-49.cust.tele2.fr] has joined #synfig
05:11 -!- zotz [n=zotz@24.244.163.157] has quit ["Leaving"]
05:24 < pxegeek> Yay for timeloops! Yay for imported sif files! Yay for walkcycles!
05:24 < pxegeek> http://home.comcast.net/~pxegeek/synfig/walk.mpg
05:25 < KiBi> heh!
05:30 < pxegeek> KiBi - should I tell you to go to bed or marvel that you got up at 2 in the morning?  
05:31 < KiBi> 2nd solution :)
05:31 < KiBi> I felt asleep round 10pm, IIRC.
05:33 < pxegeek> !
05:33 < pxegeek> Well it's getting late here and I'm not feeling great so I'm going to sign off.
05:38 < KiBi> Bye pxegeek
05:38 < KiBi> Have a nice rest
05:44 -!- Zelig [n=Zelig@ip68-108-123-29.lv.lv.cox.net] has joined #synfig
05:44 < Zelig> Sup all
05:55 -!- pxegeek [n=chatzill@c-71-59-140-184.hsd1.or.comcast.net] has quit [Read error: 113 (No route to host)]
06:22 < KiBi> http://people.freedesktop.org/~krh/akamaru.git/ funny one.
06:26 < Zelig> heh. I saw that before in a demo of Beryl. Cute.
06:36 -!- zipola [n=zipola@zip.kortex.jyu.fi] has quit ["Abiit"]
06:37 < KiBi> Not that I'm a great fan of OS X, but its panel is quite funny.
06:37 < KiBi> But after a week, I was using debian. :)
06:38 < KiBi> (anyway, I'm merely using a mouse, so... :))
06:39 < Zelig> Is there any way to delete a sub-canvas?
06:42  * KiBi doesn't know anything about synfig, just a bit about building it on Linux. Sorry.
06:42 < KiBi> (yet)
06:47 < Zelig> Well, fine tuned Sy more. Result is here:
06:47 < Zelig> www.hoodyhoo.com/toons/syNfig01b.sif
06:47 < Zelig> Now I can work on Fig.
07:43 -!- ulrikboden [n=ulrikbod@81-231-118-204-no53.tbcn.telia.com] has quit ["I'm closing down"]
08:19 -!- Zelig [n=Zelig@ip68-108-123-29.lv.lv.cox.net] has quit ["Night all"]
10:02 -!- KiBi [n=kibi@maisel-gw.enst-bretagne.fr] has quit [Remote closed the connection]
10:07 -!- Gatonegro [n=denis@79.Red-83-45-233.dynamicIP.rima-tde.net] has joined #synfig
11:04 -!- xerakko [n=xerakko@lpauna.gva.es] has joined #synfig
11:04 -!- xerakko [n=xerakko@lpauna.gva.es] has quit [Client Quit]
11:13 -!- Gatonegro [n=denis@79.Red-83-45-233.dynamicIP.rima-tde.net] has quit [Read error: 110 (Connection timed out)]
12:14 -!- ZanQdo [n=Daniel@201.201.2.22] has quit ["Adios"]
12:20 -!- xerakko [n=xerakko@lpri.gva.es] has joined #synfig
12:22 -!- xerakko [n=xerakko@lpri.gva.es] has left #synfig []
12:26 -!- ZanQdo [n=Daniel@201.201.2.22] has joined #synfig
12:58 -!- zotz [n=zotz@24.244.163.157] has joined #synfig
13:47 -!- ZanQdo [n=Daniel@201.201.2.22] has quit ["Adios"]
14:16 < dooglus> the wiki and svn machines are both unavailable?
14:19 < rore> it seems so 
14:20 < dooglus> :(
14:20 < dooglus> I just rebuilt synfig and none of the icons appeared when I ran it :)
14:20 < dooglus> the FAQ tells me this was fixed in svn r486
14:21  * dooglus is trying to fix the 'plant' layer now
14:29 -!- omry [n=omry@bzq-84-108-20-56.cablep.bezeqint.net] has quit ["Leaving"]
14:29 -!- omry [n=omry@bzq-84-108-20-56.cablep.bezeqint.net] has joined #synfig
14:39 < dooglus> does anyone know C++ here?
14:39 < dooglus> I see code like this all over:
14:39 < dooglus> String ValueNode_Linear::link_name(int i)const { if(i==0) return "slope"; return String(); }
14:40 < dooglus> that's OK, because the function is returning a String, not a reference, right?
14:40 < dooglus> (otherwise it would be returning a reference to something that was about to disappear)
14:45 < omry> dooglus, it depends on the String class.
14:45 < dooglus> omry: really?
14:45 < omry> yes.
14:45 < dooglus> how can that be?
14:46 < omry> check its operator=
14:46 < omry> copy constructor etc.
14:46 < dooglus> omry: but synfig-studio/src/gtkmm/cellrenderer_value.cpp has "const synfig::ValueBase &get_value() { [...]; return new synfig::ValueBase(); }" - can that be right?
14:46 < dooglus> sorry - the "new" isn't there really.
14:47 < omry> so what is there?
14:47 < dooglus> it's a function that returns a reference to a newly constructed temporary variable.
14:47 < dooglus> just delete "new " and that's what's there
14:47 < omry> normally this would be a mistake because the object is detroyed as soon as it goes out of scope.
14:47 < dooglus> yes
14:48 < omry> BUT, if the object defines operator= and copy constructor, it may pass the actual data on.
14:48 < dooglus> copy-constructors and operator=s aren't used are they?  because we're dealing with a reference, not the object itself
14:48 < omry> good point.
14:48 < omry> I think you are right.
14:48 < dooglus> are you familiar with the ETL template library that synfig uses?
14:48 < omry> no.
14:49 < dooglus> me either :(
14:49 < dooglus> I don't want to add the "new " that you see above, because that would introduce a memory leak
14:49 < dooglus> I think the ETL library is all about reference-counted objects, automatic deallocation, etc
14:50 < omry> unless this object is copied immediately, there is a problem there.
14:50 < dooglus> it defines handles, loose_handles, rhandles, etc, and makes my head spin
14:50 < omry> if it is copied right away, it may be okay.
14:51 < omry> what is it assigned to?
14:51 < dooglus> I imagine the reference is copied immediately - I'll check
14:52 < dooglus> omry: looks like it's OK then:
14:52 < dooglus> ValueBase value(value_entry->get_value());
14:52 < omry> check the copy constructor for value.
14:52 < omry> see that it actually copies the data.
14:52 < omry> its still dubious.
14:52 < omry> but maybe it's ok
14:53 < dooglus> it doesn't have a copy constructor
14:54 < dooglus> http://svn.voria.com/code/synfig-core/trunk/src/synfig/value.h
14:54 < dooglus> class ValueBase
14:55 < omry> now opening the url here
14:55 < omry> is it's fields all primitives?
14:55 < dooglus> http://dooglus.rincevent.net/random/value.h
14:56 < dooglus> members:
14:56 < dooglus> 	Type type;
14:56 < dooglus> 	void *data;
14:56 < dooglus> 	etl::reference_counter ref_count;
14:56 < dooglus> 	bool loop_;
14:56 < omry> HM
14:56 < dooglus> Type is an enum
14:56 < omry> it has a data field. 
14:56 < omry> that function assigns something to it?
14:57 < omry> an empty object may be safe to copy by value.
14:57 < dooglus> class reference_counter
14:57 < dooglus> {
14:57 < dooglus> private: int* counter_;
14:57 < dooglus> ...
14:57 < dooglus> that function makes a 'blank' one, I guess
14:57 < omry> dunno. better ask someone who knows the code :)
14:58 < dooglus> the default constructor does nothing much:
14:58 < dooglus> ValueBase::ValueBase():type(TYPE_NIL),data(0),ref_count(0),loop_(0) {}
14:59 < dooglus> but it's still constructing its sub-object ref_count, which the copy won't copy, right?
14:59 < dooglus> so it'll get an undefined ref_count.counter_?
15:00 < dooglus> I think the intersection of {people who know the code} and {people who are still interested in synfig} is the empty set
15:03 -!- zotz [n=zotz@24.244.163.157] has quit ["Leaving"]
15:29 < dooglus> omry: what do you think about this line of C++ code?
15:29 < dooglus> 			float radius(radius);
15:30 < omry> that it does not compile.
15:30 < dooglus> omry: is that initialising radius from the previous radius, or from the new one?
15:30 < dooglus> (it compiles)
15:30 < omry> unless it's a function.
15:30 < dooglus> it's in a function
15:30 < omry> so I don't get it
15:31 < dooglus> suppose you have:
15:31 < omry> how can you declare a variable and initialize it with itself at the same time?
15:31 < dooglus> float radius = 1.0f;
15:31 < dooglus> then float radius(radius);
15:31 < omry> you now how two radiuses
15:31 < dooglus> does that declare a 2nd 'radius' and initialise it to 1.0f?
15:31 < omry> what are the scopes?
15:31 < omry> is the first radius out a lower scope?
15:32 < omry> {float r = 1; {float r(r);}}
15:32 < omry> would work. this this case similar?
15:32 < dooglus> yes
15:32 < dooglus> it is in a sub-block
15:32 < omry> I would expect it to do the right thing.
15:32 < dooglus> here's a test program:
15:32 < dooglus> #include <stdio.h>
15:32 < dooglus> int main(void) {float r(1.0f); { float r(r); printf("r = %f\n"); }}
15:32 < omry> but test it.
15:33 < omry> easy to test.
15:33 < dooglus> r = -0.102373
15:33 < dooglus> ie. uninitialised...
15:33 < omry> good catch.
15:33 < omry> so it's a bug.
15:35 < dooglus> right
15:35 < dooglus> I found a whole bunch of such things over a year ago.  obviously missed this one.
15:36 < dooglus> I thought I had grepped the whole source for \([a-z][a-z]*\)(\1)
15:36 < omry> I am sure static code scanners can detect this bug.
15:37 < dooglus> example?
15:37 < dooglus> like lint you mean?
15:39 < omry> maybe.
15:39 < dooglus> hmmm, that grep is a problem, 'cos it finds hundreds of legal cases, where constructors are initializing their members
15:39 < omry> I don't know of a specific tool tool for C++
15:39 < omry> but I am sure such tools exist.
15:39 < dooglus> like the value_node(value_node) in:
15:39 < dooglus> ValueNode_DynamicList::ListEntry::ListEntry(const ValueNode::Handle &value_node): value_node(value_node) {}
15:39 < dooglus> that's fine, right?
15:39 < omry> search for "static C++ code analysis"
15:40 < omry> dunno
15:40 < dooglus> http://en.wikipedia.org/wiki/List_of_tools_for_static_code_analysis#Open-source_products
15:40 < omry> my C++ is rusty
15:40 < omry> yup
15:40 < omry> that will be a good list to start with :)
15:41 < omry> that particular case with the radius is easy to spot.
15:41 < dooglus> 'splint' is in the ubuntu repos
15:41 < omry> not for grep though.
15:41 < omry> for grep it's impossible.
15:41 < omry> it needs context, which grep lacks.
15:42 < omry> so give it a tr.y
15:42 < dooglus> will do
15:43 < dooglus> what does this mean?
15:43 < dooglus> virtual void push_task(const std::string &task,int start=0, int end=100, int total=100) { task(task); }
15:43 < dooglus> the task(task) bit, I mean
15:43 < omry> tsk tsk tsk.
15:43 < dooglus> oh, it's calling a member ('task') with an argument ('task')?
15:43 < omry> this is very bad shit.
15:44 < omry> why would you put your balls on the line with this kind if stuff, this I wonder.
15:44 < omry> just use a different name. so hard? :)
15:44 < omry> m_task comes into mind, or just _task.
15:44 < dooglus> probably renaming the parameter is better, isn't it?
15:45 < omry> right here? maybe
15:45 < omry> as a general rule, no.
15:46 < omry> there are few members and many parameters.
15:46 < omry> so better rename the member.
15:48 < dooglus> woo - I just rendered a tree :)
15:48 < dooglus> so that was the bug
15:48 < dooglus> radius(radius)
15:48 < dooglus> I wonder what's up with the svn server
15:52 < dooglus> so my fix is the following:
15:52 < dooglus> -			float radius(radius);
15:52 < dooglus> +			temp_radius = radius;
15:52 < dooglus> +			float radius(temp_radius);
15:53 < dooglus> copy the old value before hiding it with the new value - makes sense?
15:54  * dooglus wonders how this code ever worked...
15:54 < rore> bye(bye); 
15:54 < dooglus> (I've seen screenshots of it working)
15:54 < dooglus> cau(cau)
15:54 < rore> (well, see you later - but I *needed* to make a pun :) )
15:55 < rore> caucau ? coucou ? :)
16:00 < dooglus> cau cau
16:00 < dooglus> czech for bye bye
16:00 < dooglus> the c has a little 'v' on top of it, making it sound like a 'ch'
16:00 < dooglus> like the italian ciau (or however you spell it)
16:01 < dooglus> look, a plant!  http://dooglus.rincevent.net/random/plant.png
16:03 < dooglus> "ciao (pronounced "chow" /t?ao/)" < wikipedia
16:04 < omry> dooglus, maybe it worked before the radius member was introduced.
16:04 < omry> :)
16:07 < dooglus> ah, could be
16:07 < dooglus> or maybe they were using a compiler that treated radius(radius) differently (wrongly)
16:13 < omry> possible.
16:13 < omry> this is really walking on the edge.
16:13 < omry> I am not even sure how well this is defined in C++
16:14 < dooglus> I looked it up when I first came across it in synfig, and it's pretty clearly defined
16:15 < dooglus> as soon as you say "float radius", the new 'radius' is in scope for the rest of the block
16:15 < omry> clear enough
16:17 < dooglus> is the spec available on-line?
16:18 < dooglus> I can only find books for sale containing it
16:20 < omry> dunno. I am not doing much C++.
16:20 < omry> I`d expect that it is.
16:22 < dooglus> http://www.open-std.org/jtc1/sc22/open/n2356/
16:27 < dooglus> http://www.open-std.org/jtc1/sc22/open/n2356/basic.html#basic.scope is the part we're concerned with here
16:29 < dooglus> in particular: "1 A name declared in a block (_stmt.block_) is local to that block.  Its potential   scope    begins    at    its    point    of    declaration (_basic.scope.pdecl_) and ends at the end of its declarative region.
16:29 < dooglus> "
16:29 < dooglus> and "1 A name declared in a block (_stmt.block_) is local to that block.  Its potential   scope    begins    at    its    point    of    declaration (_basic.scope.pdecl_) and ends at the end of its declarative region.
16:29 < dooglus> "
16:29 < dooglus> um.  "1 The point of declaration for a name is immediately after its  complete declarator (_dcl.decl_) and before its initializer (if any), except as noted below.
16:30 < dooglus> "
16:30 < dooglus> so the scope begins between the "float radius" and the "(radius);"
16:32 < omry> It would be even nicer to ban default copy of objects of a class with pointer members,
16:32 < omry> but that would bring up nasty compatibility problems. Remedying long-standing
16:32 < omry> problems is harder than it looks, especially if C compatibility enters into the picture.
16:32 < omry> stroustroup
16:33 < dooglus> compiler flags are the answer to that one, no?
16:33 < dooglus> --disallow-copy-blah-blah
16:33 < omry> no
16:33 < omry> this is about the language.
16:33 < dooglus> oh
16:34 < omry> http://www.google.com/url?sa=t&ct=res&cd=3&url=http%3A%2F%2Fwww.research.att.com%2F~bs%2FDnE2005.pdf&ei=emHhRqG4H6f8wwHtyOjXDA&usg=AFQjCNFEqXxlMASpq8vk95aR3a1f2iGVoA&sig2=z0_u7W3ZzrC0KFUsJmDbZw
16:34 < omry> nice read.
16:35 < omry> curse google and their redirection
16:35 < omry> www.research.att.com/~bs/DnE2005.pdf
16:40 < dooglus> thanks
17:21 < rore> boo!
17:21 < rore> oh, still no wiki
17:21 < rore> http://dooglus.rincevent.net/random/plant.png - but very nice plant :)
17:23 < dooglus> thanks :)
17:25 < dooglus> rore: I can't commit the fix, but it's quite simple: http://dooglus.rincevent.net/random/plant.txt
17:25 < rore> ok, I'll try the patch
17:28 < dooglus> rore: it still crashes if you decrease 'Step' much from the default, but I think that's a separate bug
17:28 < dooglus> probably it's running out of memory, due to allocating objects for every point in the plant
17:29 < rore> well, that seems to work so far - I didn't change any param
17:33 < dooglus> ok
17:34 < dooglus> have you updated from svn recently?
17:35 < rore> no
17:35 < rore> http://rore.dyndns.org/rore/synfig/plant.png yeeeehaa
17:36 < rore> revision 597, that was 2 days ago 
17:37 < dooglus> how has stability been since then?
17:37 < dooglus> cool!
17:38 < rore> I didn't played enough with synfig today and yesterday to give a good answer. But it didn't seem to crash more than before
17:38 < dooglus> ok
17:38 < dooglus> I didn't much either
17:38 < dooglus> but I saw a few crashes yesterday that I didn't recognise
17:41 < rore> BTW, a couple of days ago I saw an "Error" message during the compilation (yay for colormake), but strangely enough the compilation didn't fail  
17:42 < rore> I thought that errors always stopped the compilation :)
17:44 < rore> ahah, crash \o/
17:45 < rore> (trying to link a plant and a Bline)
17:45 < dooglus> oh
17:46 < dooglus> I'll off out for the evening now, but will read the channel logs later, so please carry on mentioning anything you discover :)
20:07 -!- omry [n=omry@bzq-84-108-20-56.cablep.bezeqint.net] has quit [Remote closed the connection]
20:18 -!- zotz [n=zotz@24.244.163.157] has joined #synfig
20:37 -!- zotz [n=zotz@24.244.163.157] has quit ["Leaving"]
20:53 -!- omry [n=omry@bzq-84-108-20-56.cablep.bezeqint.net] has joined #synfig
21:05 < dooglus> omry: I just discovered that g++ -O -Wall will warn about that "float bye(bye)" problem, but if you don't use -O it doesn't.
21:05 < dooglus> omry: and of course, for debugging I never use -O
21:05 < omry> -O = optiimize?
21:05 < dooglus> yes; when optimizing g++ looks 'closer' at the code flow, so it can work out which stuff isn't needed, etc.  in the process it can notice which vars get used before set, etc.
21:06 < omry> ah
21:06 < omry> so it's really dump that -O gives more warnings.
21:06 < dooglus> I didn't find any source code analyser that could detect the problem.  I tried a few.
21:06 < omry> there isn't another way to turn off those warnings?
21:07 < dooglus> you can turn the warnings off, yes
21:07 < omry> sorry
21:07 < dooglus> -O does extra work - it runs slower
21:07 < omry> to turn them on
21:07 < omry> I meant
21:07 < dooglus> from the manual:      These warnings are possible only in optimizing compilation, because they require data flow information that is computed only when optimizing.  If you don't specify `-O', you simply won't get these warnings.
21:08 < omry> well
21:08 < omry> static code checkers does data flow analysis.
21:08 < dooglus> there's even:
21:08 < dooglus>      If you want to warn about code which uses the uninitialized value
21:08 < dooglus>      of the variable in its own initializer, use the `-Winit-self'
21:08 < dooglus>      option.
21:08 < omry> ha
21:08 < omry> so it is possible.
21:08 < omry> cool.
21:09 < dooglus> no - -Winit-self is one of "these warnings" refered to in the previous para
21:09 < omry> oh
21:09 < omry> bugger.
21:15 < dooglus> heh
21:17 < CIA-28> synfig: dooglus * r619 /synfig-core/trunk/src/synfig/loadcanvas.cpp: 
21:17 < CIA-28> synfig: Prevent a warning from the compiler. It warns that "loadcanvas.cpp:349:
21:17 < CIA-28> synfig: warning: 'color.synfig::Color::r_' may be used uninitialized in this function"
21:17 < CIA-28> synfig: (and g_, b_ and a_, too), whereas so long as the .sif file isn't corrupted, this
21:17 < CIA-28> synfig: won't happen.
21:31 -!- zotz [n=zotz@24.244.163.157] has joined #synfig
21:32 < CIA-28> synfig: dooglus * r620 /synfig-core/trunk/src/modules/mod_particle/plant.cpp: Fix the 'plant' layer.
21:32 < CIA-28> synfig: dooglus * r621 /synfig-core/trunk/src/modules/mod_particle/plant.cpp: Allow plant blines to have 2 points in them. Previously a minimum of 3 was enforced, even though the comment says "Bline must have at least 2 points in it".
21:32 < CIA-28> synfig: dooglus * r622 /synfig-core/trunk/src/modules/mod_particle/plant.cpp: Tidying.
21:47 < CIA-28> synfig: dooglus * r623 /synfig-core/trunk/src/modules/mod_noise/distort.cpp: 
21:47 < CIA-28> synfig: Fixed another instance of the bug which was causing the plant layer to break.
21:47 < CIA-28> synfig: When initialising a variable at the same time as declaring it, it's not possible
21:47 < CIA-28> synfig: to use the previous variable of the same name in the initialiser.
21:47 < CIA-28> synfig: dooglus * r624 /synfig-core/trunk/src/modules/lyr_std/julia.cpp: Prevent a compiler warning. (variable mag is used uninitialised if iterations is set to zero or less).
21:47 < CIA-28> synfig: dooglus * r625 /synfig-core/trunk/src/modules/lyr_std/mandelbrot.cpp: Prevent a compiler warning. (variable 'mag' is used uninitialised if iterations is less than 1)
21:59 < dooglus> another case of trying to use a variable in its own declaration:
21:59 < dooglus> time_type t=(t-get_r())/get_dt();
22:03 < dooglus> (in ETL/ETL/_bezier.h)
22:03 < dooglus> except that looks more like a typo than a thinko
22:03 < dooglus> the inside 't' should be 'time'?
22:17 < CIA-28> synfig: dooglus * r626 /synfig-studio/trunk/src/gtkmm/about.cpp: Fix a couple of compiler warnings ("passing 'float' for argument 1 to 'void Pango::FontDescription::set_size(int)" twice)
23:17 < CIA-28> synfig: dooglus * r627 /ETL/trunk/ETL/_bezier.h: This looks like a typo. I don't think this function is ever used, anyway (other than by a few other functions which are never used (other than by a few functions that ...)).
23:30 -!- rore_ [n=rore@d77-216-184-53.cust.tele2.fr] has joined #synfig
23:31 -!- rore [n=rore@d90-144-96-49.cust.tele2.fr] has quit [Nick collision from services.]
23:31 -!- rore_ is now known as rore
23:34 -!- xerakko [n=xerakko@58.pool85-54-245.dynamic.orange.es] has joined #synfig
23:51 < dooglus> the draw tool code hurts my brain
--- Log closed Sat Sep 08 00:00:16 2007