--- Log opened Mon Feb 18 00:00:19 2008
--- Day changed Mon Feb 18 2008
00:00 < genete> please look the icons and tell me what you think: http://i85.photobucket.com/albums/k74/Genete/Pantallazo-Capas-2.png
00:00 < Yoyobuae> OMG, set curve gradient blend method to composite (on dooglus example) =D
00:02 < dooglus> Yoyobuae: I never added any new converts from scratch - it's all copy/paste/edit stuff :)
00:04 < Yoyobuae> dooglus: i guess it's just me being too scared of messing up XD
00:05 < dooglus> Yoyobuae: that's quite a mess - turning blend to composite :)
00:07 < dooglus> I was contemplating a more subtle mess: http://dooglus.rincevent.net/random/dotted-2.png
00:07 < genete> how do you call the yellow message that appears when you still over a button for a while?
00:07 < dooglus> http://dooglus.rincevent.net/random/dotted-2.sifz
00:07 < dooglus> that's a 'tooltip'
00:07 < genete> thanks
00:07 < dooglus> and it appears when you 'hover' over a button
00:08 < genete> ok, you have a new bug
00:08 < dooglus> that's where the bline is looped
00:09 < genete> dooglus:  it is normal. You cannot set a stripes gradient to be exactly a integer of the curve lenght
00:10 < dooglus> aah
00:10 < dooglus> I see
00:10 < dooglus> so once Yoyobuae has finished his bline-speed improvements, this will be solved?  ;)
00:11 < dooglus> Yoyobuae: interesting point - did you look at how the curve-gradient does its thing in perpendicular mode?  these stripes are evenly spaced...
00:11 < CIA-27> synfig: dooglus * r1737 /synfig-studio/trunk/src/gtkmm/ (app.h toolbox.cpp app.cpp): Link to a few wiki pages directly from the Help menu.
00:11 < CIA-27> synfig: dooglus * r1738 /synfig-studio/trunk/images/encapsulate_icon.sif: Mirrored encapsulate icon left-right. Thanks genete.
00:11 < CIA-27> synfig: dooglus * r1739 /synfig-studio/trunk/src/gtkmm/duckmatic.cpp: "Select All Ducks" only selects ducks which are "group selectable" but it used to leave other ducks selected if they were already selected. Now it doesn't.
00:11 < CIA-27> synfig: dooglus * r1740 /synfig-studio/trunk/src/synfigapp/canvasinterface.cpp: Add a few comments.
00:11 < CIA-27> synfig: dooglus * r1741 /synfig-studio/trunk/src/synfigapp/canvasinterface.cpp: 
00:11 < CIA-27> synfig: Convert static lists entirely consisting of blinepoints into 'bline' valuenodes,
00:11 < CIA-27> synfig: not 'dynamic_list' valuenodes. This will allow outlines, plants, etc. to be
00:11 < dooglus> to be...?
00:12 < CIA-27> synfig: directly editable as soon as they're created from the 'new layer' menu.
00:12 < CIA-27> synfig: dooglus * r1742 /synfig-studio/trunk/images/encapsulate_icon.sif: New simplified version from genete.
00:13 < Yoyobuae> dooglus: yeah if you try the same with a regular gradient, the stripes get compresed/expanded
00:15 < dooglus> what do you mean?
00:15 -!- Yoyobuae [n=Yoyobuae@201.224.135.156] has quit [Read error: 104 (Connection reset by peer)]
00:17 < genete> dooglus: I cannot reproduce the dashed line visual problem
00:17 -!- Yoyobuae [n=Yoyobuae@201.224.135.156] has joined #synfig
00:17 < genete> the looped one I mean
00:17 < genete> can you upload the file?
00:17 < dooglus> genete: I did
00:18 < dooglus> dotted-2.sifz
00:18 < genete> oops sorry
00:19 < Yoyobuae> dooglus: use the bline tool to make a line and a gradien
00:20 < dooglus> Yoyobuae: that makes a curvegradient, just the same
00:20 < dooglus> do you mean with 'perpendicular' unchecked?
00:21 < dooglus> http://dooglus.rincevent.net/random/dotted-3.png
00:22 < Yoyobuae> weird, my bline tool makes regular gradients
00:24 < Yoyobuae> i have studio r1680
00:24 < genete> dooglus: stripes has not the loop problem of the dotted-2.sifz file
00:24 < Yoyobuae> was the bline tool changed since?
00:26 < dooglus> no
00:26 < dooglus> what's a regular gradient?
00:28 < dooglus> does it make gradients with a 'Vertices' parameter?  if so, those are curvegradients...
00:28 < dooglus> to find out the type of a layer, rename it to "" (nothing)
00:28 < dooglus> ie. select its name, hit backspace and return
00:33 < genete> (but backspace, not delete!!)
00:36 < genete> night all :)
00:36 -!- genete [n=Genete@84.122.41.172.dyn.user.ono.com] has quit ["Abandonando"]
00:45 < Yoyobuae> dooglus: yeah you're right
00:48 < dooglus> the bug I found with the dotted-2.png above seems to be a bug with the repeat-gradient valuenode, not curvegradients
00:50 < dooglus> 'specify start' is overriding the cpoint at 0.000
00:52 < Yoyobuae> i have to go, cya tomorrow =)
00:52 < dooglus> ta ta
00:52 -!- Yoyobuae [n=Yoyobuae@201.224.135.156] has quit ["ChatZilla 0.9.80 [Firefox 2.0/2006101023]"]
01:04 -!- ZanQdo [n=Daniel@201.201.2.22] has quit ["Adios"]
01:47 < CIA-27> synfig: dooglus * r1743 /synfig-studio/trunk/src/gtkmm/keyframeactionmanager.cpp: Fix 1895689: Add a tooltip for the 'keyframe properties' icon.
01:47 < CIA-27> synfig: dooglus * r1744 /synfig-studio/trunk/src/gtkmm/keyframeactionmanager.cpp: Fix capitalization.
02:00 < pixelgeek> (synfigstudio.exe:1960): Gtk-CRITICAL **: gtk_tree_view_column_cell_layout_pack_
02:00 < pixelgeek> start: assertion `! gtk_tree_view_column_get_cell_info (column, cell)' failed
02:00 < pixelgeek> synfig(1960) [4:53:54 PM] info: STATE SKETCH: entering state
02:00 < pixelgeek> (synfigstudio.exe:1960): Gdk-WARNING **: ../../../../gtk+/gdk/win32/gdkdrawable-
02:00 < pixelgeek> win32.c:1723: CreateRectRgn failed: The parameter is incorrect.
02:01 < pixelgeek> dooglus: any reason why I get that when my blank canvas starts up.  the state sketch and warning message only appears when my mouse pointer meets the canvas area
02:01 < pixelgeek> And for all those that are curious, the Windows help compiles and works perfectly!
03:29 -!- ZanQdo [n=Daniel@201.201.2.22] has joined #synfig
04:49 -!- pabs3 [i=pabs@d122-105-74-150.per9.wa.optusnet.com.au] has quit ["Don't rest until all the world is paved in moss and greenery."]
05:17 -!- pabs3 [i=pabs@d122-105-74-150.per9.wa.optusnet.com.au] has joined #synfig
05:23 < pixelgeek> pabs3: so is 'make' intelligent enough to only rebuild things when it needs?  If I'm using Yoyobuae's script and not deleting the build dirs, I should just be able to make core & studio, right?
05:23 < pixelgeek> (for small changes of core or studio)
05:24 < pabs3> only rebuilding when needed is the whole reason for make
05:25 < pabs3> only catch is when updating configure.ac or any Makefile.am you need to regenerate and run configure 
05:58 < pixelgeek> but when I svn up, the _src dir is the one that gets updated, so I still have to copy files over to the build dir, right?
05:59 < pabs3> do you have *.cpp files in the build dir? IIRC Atrus' scripts only put the binaries there
06:00 < pixelgeek> yup cpp files & headers.  so SVN up, copy across, make and I should be good to go?
06:03 < pabs3> weird, there is no reason to have them there. does the script copy them there?
06:03 < pabs3> automake supports building outside of the source directory just fine
06:10  * pixelgeek shrugs
06:13 < pabs3> so yeah, yr plan sounds good
06:48 -!- factor [n=factor@ip68-14-160-70.ok.ok.cox.net] has quit ["Ex-Chat"]
06:57 -!- factor [n=factor@ip68-14-160-70.ok.ok.cox.net] has joined #synfig
07:09 -!- Yoyobuae [n=Yoyobuae@201.224.135.156] has joined #synfig
07:10 < Yoyobuae> pixelgeek: the sources_core.sh and sources_studio.sh scripts i gave you copy over the sources from the svn dirs.
07:12 < Yoyobuae> pixelgeek: it only copies the updated files only
07:48 < pixelgeek> Ah!   Neat
07:50 < pixelgeek> That would be the -u option in cp, then.  Makes sense
07:51  * pixelgeek finally got through War of the Worlds.
07:51 < pixelgeek> Pretty good, but they stole the ending from Independance Day
07:52 < pixelgeek> And now, to bed....
07:55 < factor> see ya
08:44 -!- jcome [n=jcome@124.240.92.46] has joined #synfig
08:50 < pabs3> hi jcome 
08:51 < jcome> :)
08:53 -!- genete [i=d90c1036@gateway/web/ajax/mibbit.com/x-9f9ba2de71eabbcf] has joined #synfig
08:53 -!- genete [i=d90c1036@gateway/web/ajax/mibbit.com/x-9f9ba2de71eabbcf] has left #synfig []
08:53 -!- genete [i=d90c1036@gateway/web/ajax/mibbit.com/x-7f17e07095e7367e] has joined #synfig
08:54 < genete> morning!
08:55 < genete> dooglus, Yoyobuae: I think that the solution to solve the BLine speed equation is hidden in the cuved gradient code.
08:56 < genete> a perpendicular curved gradient knows exactly how to map the gradient onto the Bline lenght regardless its bline segments lenghts
08:57 < genete> so, I suspect that there is the solution for the bline speed equation.
09:01 -!- pixelgeek [n=chatzill@c-71-59-140-184.hsd1.or.comcast.net] has quit [Read error: 113 (No route to host)]
09:08 -!- Yoyobuae [n=Yoyobuae@201.224.135.156] has quit [Read error: 110 (Connection timed out)]
09:30 -!- pabs3 [i=pabs@d122-105-74-150.per9.wa.optusnet.com.au] has quit [Read error: 104 (Connection reset by peer)]
09:37 -!- Zelgadis [n=Zelgadis@87.103.170.55] has joined #synfig
09:53 -!- pabs3 [i=pabs@d122-105-74-150.per9.wa.optusnet.com.au] has joined #synfig
09:54 -!- crazy_bus [n=philip@CPE-121-217-73-102.nsw.bigpond.net.au] has joined #synfig
10:02 -!- jcome [n=jcome@124.240.92.46] has quit ["Ex-Chat"]
10:08 -!- crazy_bus [n=philip@CPE-121-217-73-102.nsw.bigpond.net.au] has quit [Read error: 104 (Connection reset by peer)]
10:22 -!- genete [i=d90c1036@gateway/web/ajax/mibbit.com/x-7f17e07095e7367e] has left #synfig []
10:22 -!- genete [i=d90c1036@gateway/web/ajax/mibbit.com/x-68ec89bc54cfa29c] has joined #synfig
10:56 -!- mib_oe7v99bl [i=4e582106@gateway/web/ajax/mibbit.com/x-5aa676809a99d344] has joined #synfig
10:57 < mib_oe7v99bl> hello anybody' here?;)
10:57 < pabs3> hi mib_oe7v99bl 
10:57 < mib_oe7v99bl> aloha:)
10:57 < genete> hi mib_oe7v99bl :)
10:58 < mib_oe7v99bl> i have problem with installation synfig studio
10:58 < mib_oe7v99bl> some error from ms dos?:/
10:58 < mib_oe7v99bl> ntvdm cpu inlegal instruction
10:58 < mib_oe7v99bl> and some variables
10:58 < mib_oe7v99bl> are in communicate
10:59 < mib_oe7v99bl> anyone knows what's about?
11:00 < pabs3> what are you installing in? Windows?
11:01 < mib_oe7v99bl> synfigstudio
11:02 < mib_oe7v99bl> oh sorry , yes in windows
11:02 < mib_oe7v99bl> it's too early;)
11:02 < pabs3> :) our windows users aren't here at the moment
11:03 < pabs3> but I'd try searching google for the error message
11:03 < mib_oe7v99bl> write here variables from this error?
11:03 < mib_oe7v99bl> after when i click ignore it's show me next error from cpu
11:04 < mib_oe7v99bl> might it be problem with graphic drivers?
11:09 < pabs3> hmmm
11:09 < pabs3> can you paste the error here: http://pastebin.ca/
11:10 < genete> mib_oe7v99bl: does it happen when you do a speciphic task or just after run studio?
11:11 < mib_oe7v99bl> only when i try to install synfigstudio or synfig
11:12 < mib_oe7v99bl> 16 bit subsystem ms dos - header of error
11:12 < mib_oe7v99bl> ntvdm cpu illegal instruction
11:12 < pabs3> can you make a screenshot of the error?
11:12 < mib_oe7v99bl> cs:0f94 IP: 0659 OP 63 75 6d 65 6e
11:12 < mib_oe7v99bl> yes i can
11:13 < mib_oe7v99bl> i wrote u all what is in comunicate
11:13 < mib_oe7v99bl> o is path to the file also
11:13 < mib_oe7v99bl> but i think it's doesn't matter
11:16 < mib_oe7v99bl> still need screenshot?
11:16 < pabs3> yeah
11:17 < pabs3> I don't see why there is an msdos error, synfig doesn't use 16bit/msdos stuff as far as I know
11:20 < mib_oe7v99bl> i don't know also..might it be infected files at your server?
11:21 < pabs3> I don't think so, does your virus checker say anything?
11:21 < mib_oe7v99bl> i read about such errors..it is eror from command but old version in windows 95-98
11:21 < mib_oe7v99bl> nothing
11:21 < pabs3> are you on vista, or xp?
11:21 < mib_oe7v99bl> xp
11:21 < pabs3> hmm
11:24 < mib_oe7v99bl> is possible that gtk environment is the problem?
11:24 < mib_oe7v99bl> one i have inside of gimp
11:24 < mib_oe7v99bl> but next i had to install becouse gtkmm didn't see then
11:24 < mib_oe7v99bl> them
11:27 < dooglus> genete: morning
11:28 < dooglus> genete: that problem I was having with my 'dotted line' last night was due to the 'specify start / end' parameters of the repeat gradient
11:28 < pabs3> mib_oe7v99bl: as long as you installed the ones linked from the download page, I don't think it is the problem
11:29 < mib_oe7v99bl> ms say that isn't problem with windows but something with app which i want to install
11:30 < dooglus> turn them both off and the 'bug' goes away
11:32 < dooglus> mib_oe7v99bl: do you have an old version of gtk and a new version of gtkmm?
11:32 < dooglus> I wonder if mixing the versions causes a problem
11:32 < mib_oe7v99bl> i made it and problem is still allive;)
11:32 < mib_oe7v99bl> 2.10 both
11:33 < mib_oe7v99bl> but gtk is 2.10.11
11:33 < mib_oe7v99bl> gtkmm 2.10.8
11:35 < dooglus> from a web page: "You are getting this error because the file you are trying to run is trying to access the computers memory. Because you are not running the file on a DOS or Win 3.X machine, NTVDM will not allow this. NTVDM allows a 16-bit DOS program to execute on Windows. It is basically a DOS emulator."
11:35 < dooglus> but synfig doesn't do anything like that
11:36 < dooglus> could it be that your machine is infected with something already that isn't compatible with synfig?
11:38 < mib_oe7v99bl> no i don't think so
11:38 < mib_oe7v99bl> u think about some malware?
11:40 < dooglus> yes, possibly
11:40 < dooglus> http://www.techspot.com/vb/all/windows/t-5039-NTVDM-CPU-illegal-instruction-.html
11:42 < mib_oe7v99bl> i'm reading this:)
11:42 < mib_oe7v99bl> system variable fp no host check is correct for windows?
11:43 < dooglus> I don't know what you mean
11:44 < rore> hello everyone
11:44 < dooglus> I would suggest updating your antivirus software and running a full scan
11:45 < dooglus> hi rore.  didn't see you sneak in :)
11:45 < mib_oe7v99bl> they said about checking variables in system environment
11:45  * rore reads the last link and think it really looks like a malware pb 
11:45 < pabs3> hi rore !
11:45 < rore> :)
11:45 < pabs3> I'd get a linux livecd, scan your windows partition with clamav and then go looking for suspicious files
11:48 -!- AkhIL [n=AkhIL@90.188.195.134] has quit [Remote closed the connection]
11:48 < dooglus> mib_oe7v99bl: did you make the screenshot?
11:49 < dooglus> mib_oe7v99bl: I'm wonder what the path it shows is
11:50 -!- Zelgadis [n=Zelgadis@87.103.170.55] has quit ["Leaving."]
11:51 < mib_oe7v99bl> path to install file <:)
11:51 -!- AkhIL [n=AkhIL@90.188.195.134] has joined #synfig
11:51 < dooglus> what is the URL of the install file you downloaded?
11:51 < mib_oe7v99bl> might it be that it's missing some files from system
11:51 < mib_oe7v99bl> as i read this article
11:52 < mib_oe7v99bl> http://synfig.org/Download#Download
11:52 < dooglus> mib_oe7v99bl: I don't think so.  synfig shouldn't be doing any 'WOW' stuff at all
11:53 < mib_oe7v99bl> but system can do if something need this file which is missing
11:53 < mib_oe7v99bl> i try to find malware and take this missing files
11:54 < dooglus> can you paste the reference to missing files you're talking about?
11:54 < dooglus> http://www.annoyances.org/exec/forum/winxp/1101648483 has a good list of steps for finding malware
11:58 < mib_oe7v99bl> shit it'slook that all files are:/
11:59 < dooglus> are what?
11:59 < dooglus> are infected?
12:01 < mib_oe7v99bl> heh
12:01 < mib_oe7v99bl> amazing
12:01 < mib_oe7v99bl> i downloaded another files synfig studio and it's work:)
12:02 < mib_oe7v99bl> it's look that during transfer something was missed
12:02 < dooglus> what are the URLs of the two files you downloaded?
12:02 < mib_oe7v99bl> the same :)
12:02 < mib_oe7v99bl> first i saved by right click mouse on link to the file
12:02 < mib_oe7v99bl> these time i just click and downloaded
12:03 < mib_oe7v99bl> so different ways to have correctly work file;)
12:03 < mib_oe7v99bl> i think that during transef something was missed
12:03 < dooglus> sounds like the first download failed
12:03 < mib_oe7v99bl> in firefox last time often do something like this
12:03 < mib_oe7v99bl> files are empty (zips) or corrupted
12:04 < mib_oe7v99bl> or incomplete
12:04 < dooglus> firefox saves the file as filename.part while it's downloading, and only renames it to filename once it has finished
12:04 < mib_oe7v99bl> no i say about different thing
12:04 < mib_oe7v99bl> in firefox somtimes when you save files
12:04 < mib_oe7v99bl> after donwloading are incomplete or corrupted
12:05 < mib_oe7v99bl> and then you must make it another time
12:05 < mib_oe7v99bl> but usually i had this problem when transfer where too slow
12:06 < mib_oe7v99bl> never like this :)
12:06 < mib_oe7v99bl> ok so another question;)
12:06 < mib_oe7v99bl> what is difference between synfig and synfig studio?
12:07 < mib_oe7v99bl> :)
12:07 < dooglus> synfig core is the command line program and rendering library; synfig studio is the gui
12:07 < mib_oe7v99bl> so i need both?
12:07 < mib_oe7v99bl> or only one?;)
12:07 < dooglus> the gui is optional
12:08 < dooglus> if you like writing XML in an undocumented format, all you need is synfig core :)
12:08 < mib_oe7v99bl> synfig must be? i good understand?
12:08 < mib_oe7v99bl> i don't like;)
12:08 < dooglus> yes, you need synfig
12:08 < dooglus> and if you want a gui, you need studio too
12:09 < mib_oe7v99bl> i want ;)
12:09 < pabs3> dooglus: or if you have a renderfarm you might just want synfig :)
12:09 < mib_oe7v99bl> renderfarm?..what is it?;)
12:09 < dooglus> pabs3: yes, fair enough.  but you probably still want studio on at least one computer to create the file you're going to render
12:10 < dooglus> mib_oe7v99bl: a collection of computers all running synfig to render a movie
12:10 < pabs3> dooglus: true :)
12:10 < mib_oe7v99bl> i don't have such:)
12:10  * pabs3 brb, restarting
12:10 -!- pabs3 [i=pabs@d122-105-74-150.per9.wa.optusnet.com.au] has quit ["restart"]
12:10 < mib_oe7v99bl> in future i will transform my famr to linux
12:10 < mib_oe7v99bl> farm
12:11 < mib_oe7v99bl> but i have too much data to transfer to it
12:11 < dooglus> make a backup of the data you want to keep anyway - hard drives can die at any time
12:12 < mib_oe7v99bl> i know it
12:12 < mib_oe7v99bl> i hope that it's fats way to learn synfig;)
12:12 < mib_oe7v99bl> hyhy
12:13 < mib_oe7v99bl> it's nice to make vector animations;)
12:16 < mib_oe7v99bl> and works similar to inkscape;) 
12:16 < mib_oe7v99bl> ok it was nice to meet you
12:16 -!- pabs3 [i=pabs@d122-105-74-150.per9.wa.optusnet.com.au] has joined #synfig
12:16 < mib_oe7v99bl> have a nice day
12:16 < dooglus> enjoy synfig
12:16 < mib_oe7v99bl> cye ya
12:16 < dooglus> we'll be here if you need help
12:16 < dooglus> bye
12:16 < mib_oe7v99bl> i will try;)
12:16 < mib_oe7v99bl> yes i know it:P
12:17 -!- mib_oe7v99bl [i=4e582106@gateway/web/ajax/mibbit.com/x-5aa676809a99d344] has quit ["http://www.mibbit.com ajax IRC Client"]
12:26 < CIA-27> synfig: dooglus * r1745 /synfig-studio/trunk/src/gtkmm/layertree.cpp: Prevent warning: "Gtk-CRITICAL **: gtk_tree_view_column_cell_layout_pack_start: assertion `! gtk_tree_view_column_get_cell_info (column, cell)' failed".
12:45 < pabs3> http://jimmac.musichall.cz/log/?p=415
12:46 < genete> dooglus: did you read my comments on curve gradient and find the solution for Bline speed equation?
12:46 -!- mib_v8f81ifx [i=59b01c9c@gateway/web/ajax/mibbit.com/x-e025920e10506d4f] has joined #synfig
12:47 < mib_v8f81ifx> is this anonymous?
12:47 < dooglus> no, your IP address is showing
12:49 -!- mib_v8f81ifx [i=59b01c9c@gateway/web/ajax/mibbit.com/x-e025920e10506d4f] has quit [Client Quit]
14:13 -!- Greunlis [n=Greunlis@97.24.broadband4.iol.cz] has joined #synfig
14:19 < Greunlis> HI.
14:26 < genete> hi Greunlis
14:28 < Greunlis> I have a problem with Synfig. It crashes too often, when I just slide on the timeline. I have a Windows version 0.61.07. The movie is not longer then 8s. Do you have any suggestion how to solve this problem please?
14:33 < genete> I use the linux version. anyway there are some hints to "try" to make the windows version more stable.
14:35 < genete> Read the http://synfig.org/FAQ
14:37 < Greunlis> Of course I already read it. But I don't use multi-core CPU :(
14:38 < genete> Try to see if enable or disable multitrheads (Main menu->Settings->second TAB ->checkbox) helps.
14:39 < genete> other thing is download the unofficial svn version and install them. They are very close to the latest svn revisions so all the improvements of stability since 0.61.07 is there.
14:40 < genete> there are two maintainers: Atrus and pixelgeex.
14:42 < Greunlis> I'l try it, thanks. Anyway, what does SVN mean?
14:42 < genete> svn = subversion
14:43 < Greunlis> I see.
14:43 < genete> it is the last revision of the code and you usually should compile and install by your self.
14:46 < genete> Read this to know more a bout that: http://synfig.org/Source_code
14:50 < Greunlis> Thanks, now i know what to do all the night.
14:53 < factor> off to work
14:53 -!- factor [n=factor@ip68-14-160-70.ok.ok.cox.net] has left #synfig ["Ex-Chat"]
14:58 -!- genete [i=d90c1036@gateway/web/ajax/mibbit.com/x-68ec89bc54cfa29c] has quit ["http://www.mibbit.com ajax IRC Client"]
15:01 -!- Zelgadis [n=zelgadis@87.103.170.190] has joined #synfig
15:07 < Greunlis> Have to go.
15:07 -!- Greunlis [n=Greunlis@97.24.broadband4.iol.cz] has left #synfig []
15:53 -!- genete [n=Genete@84.122.49.193.dyn.user.ono.com] has joined #synfig
16:03 < dooglus> hi genete 
16:03 < genete> hi dooglus 
16:03 < Zelgadis> hi
16:04 < genete> dooglus: I think you did not read my comments on bline speed
16:05 < dooglus> genete: I saw you saying that curvegradient sets the speed right
16:05 < dooglus> Zelgadis: hi
16:05 < genete> hi Zelgadis 
16:05 < dooglus> genete: did I miss something?
16:05 < genete> no, nothing. Only miss your comment on that
16:13 < dooglus> genete: I think I had made the same comment earlier :)
16:14 < genete> oops :) I loose it in all this logs
16:20 < genete> dooglus: I still seeing strange things meanwhile using the Bline tool
16:20 < genete> sometimes some of the vertice ducks becomes green
16:20 < dooglus> genete: what kind of strange?
16:20 < dooglus> I see that sometimes when I loop
16:20 < Zelgadis> the firs one
16:21 < Zelgadis> yeah, the first one
16:21 < genete> sometines it is the first vertex sometimes it is the just inserted one... it changes
16:21 < genete> not always the first one
16:22 < dooglus> ok
16:22 < dooglus> I've seen it too
16:22 < dooglus> is it a new bug?
16:22 < dooglus> I'm working on the history panel at the moment
16:22 < dooglus> it was annoying me how it doesn't scroll to show 'new' history
16:22 < genete> it is a strange thing in any case
16:23 < genete> scroll vertically?
16:24 -!- factor [n=Factor@32.144.79.118] has joined #synfig
16:27 < dooglus> yes
16:27 < dooglus> I watch it sometimes to see how studio interprets what I'm clicking
16:27 < dooglus> and it doesn't scroll once the window is filled up
16:27 < genete> ah 
16:35 -!- ZanQdo [n=Daniel@201.201.2.22] has quit ["Adios"]
16:47 < factor> not at my linux box right now. Does synfig do all  the sif rendering
16:47 < factor> i.e can i make a server side render with it
16:47 < dooglus> yes
16:48 < factor> cool
16:48 < dooglus> you don't need studio to render, only to edit .sifz files
16:48 < factor> yup ok good
16:54 -!- xerakko [n=Miguel@debian/developer/xerakko] has joined #synfig
17:04 -!- Zelgadiss [n=zelgadis@87.103.169.189] has joined #synfig
17:06 -!- Zelgadis [n=zelgadis@87.103.170.190] has quit [Read error: 110 (Connection timed out)]
17:40 < dooglus> genete: from what I see in the bline, it's always the first vertex that's green.  it's only the 'just inserted' one if you insert a new first vertex, right?
17:41 < genete> yes, other one that is not the first one is not green
17:43 < dooglus> so maybe it's a good thing?  it shows which duck is the 'joining' point
17:44 < genete> yes it is. But is doesn't show it as green always
17:44 < dooglus> oh, I see
17:44 < dooglus> even if you loop?
17:44 < genete> sometimes it is like normal vertices ducks
17:44 < dooglus> what do you think about vertex and tangent duck colors?
17:45 < dooglus> yellow/orange/red - are they different enough colors?
17:45 < genete> I see the vertex one green sometimes  and sometimes orange
17:45 < genete> but when it is orange it becomes green if the mouse is over it
17:46 < genete> the other normal ones not
17:47 < dooglus> I don't see green at all any more now I'm trying to fix it :)
17:48 < CIA-27> synfig: dooglus * r1746 /synfig-studio/trunk/src/gtkmm/ (4 files): Scroll the History panel to keep the border between 'done' and 'undone' in the centre of the panel if possible. Also, select the most recently 'done' action, if any.
17:48 < genete> I see it sometimes green sometimes orange 
17:49 < genete> regarding to ducks colors they are fine
17:49 < genete> if there is any improvement in that area maybe distinguish one dusck from others based on its shape not its color. 
17:50 < genete> like other programs do
17:52 < genete> About the 8% of men are color blindness
17:52 < genete> http://en.wikipedia.org/wiki/Color_blindness
18:09  * genete is away: Estoy ocupado
18:15 < Zelgadiss> night all
18:15 -!- Zelgadiss [n=zelgadis@87.103.169.189] has quit ["????!"]
18:19 < factor> see ya z
18:40 < dooglus> genete: so
18:40 < dooglus> I found why the joined vertex is sometimes green
18:40 < genete> dooglus: so?
18:40 < dooglus> and the question is...  should it always been green?  or never?  or only when looped?
18:40  * genete is back (gone 00:30:56)
18:41 < genete> I think it would be green only when the mouse is over
18:41 < genete> if not you can  confuse it with the OffSet one
18:42 < dooglus> ah, I was talking about in the bline tool only
18:42 < dooglus> there's no offset duck in that tool
18:43 < genete> during creation it should be green always then. After that during edition it should be green when the mouse is over
18:44 < dooglus> I don't know how easy the mouse-over thing is
18:44 < dooglus> but in the bline tool - the first duck can always be green - or only when looped
18:46 < dooglus> I guess it's clearer if it's always green
18:46 < genete> it is weird. Try to move the first duck when the bline is looped. It gets orange / green during dragging...
18:46 < dooglus> what's happening is there are two ducks on top of each other
18:46 < dooglus> one's green, one isn't
18:48 < genete> always green for creation and edition tasks?
18:48 < dooglus> green is the default color for ducks if they're not set to be anything else
18:49 < dooglus> the duck put at the end of the bline in the bline tool isn't told what color to be
18:49 < dooglus> so it's green
18:49 < dooglus> sometimes it's visible, other times the duck at the start of the line obstructs it
18:49 < dooglus> it looks like a bug to me - the duck's color was forgotten, so it comes out green
18:52 -!- xerakko [n=Miguel@debian/developer/xerakko] has quit ["Ex-Chat"]
18:54  * genete is away: Estoy ocupado
19:03 < factor> afk
19:18 < CIA-27> synfig: dooglus * r1747 /synfig-studio/trunk/src/gtkmm/state_bline.cpp: The bline tool was sometimes showing the first duck in the new bline as green once the line was looped. This change makes it always do that.
19:18 < CIA-27> synfig: dooglus * r1748 /synfig-studio/trunk/src/gtkmm/duck.h: Commented the Duck::Type enum.
19:18 < CIA-27> synfig: dooglus * r1749 /synfig-studio/trunk/src/gtkmm/historytreestore.h: A previous commit made curr_row public, but it isn't used.
19:18 < CIA-27> synfig: dooglus * r1750 /synfig-studio/trunk/src/gtkmm/state_bline.cpp: r1747 left the green duck feature disabled. This enables it.
19:37 -!- Yoyobuae [n=Yoyobuae@201.224.135.156] has joined #synfig
19:43 < Yoyobuae> genete: i also noted that curve gradien seems to do a good job spacing stripes evenly over a bline
19:44 < Yoyobuae> genete: but i think the code cheats in order to do that.  =)
19:44 < Yoyobuae> It seems to work by dividing the bline in small pieces and calculating an approximate distance for each section
19:45 < Yoyobuae> if a bline section is curved enough, curve gradient doesn't place stripes properly
19:53 < Yoyobuae> try using: http://members.lycos.co.uk/yoyobuae/bline_spacing.sif 
19:53 < Yoyobuae> add a curve gradient on top of the bline, and connect  the bline to it
19:54 < Yoyobuae> set it to perpendicular, and set the gradient to stripes with 20 stripes
19:58 < dooglus> oh yeah
19:59 < Yoyobuae> dooglus: btw, i tested my method using 2nd derivative. speed still changes =(
20:00 < Yoyobuae> in using the same bline as above, the max speed is 1.5 times the min
20:00 < Yoyobuae> min speed
20:01 < dooglus> did you look at the curvegradient code?
20:01 < dooglus> it's an odd effect - I don't remember how it works exactly
20:01 < Yoyobuae> nope
20:02 < Yoyobuae> doesnt it just find the point on the curve closest, then find the distance on the curve to that point?
20:02 < Yoyobuae> that's what it seems to be doing
20:09 < dooglus> so how do you explain the evenness of the stripe widths?
20:10 < Yoyobuae> the code works, as long as the curve is not too curvy
20:11 < Yoyobuae> also if you uncheck "Fast" on the curve gradient it works even in bline_spacing.sif
20:11 < Yoyobuae> but then it's VERY slow
20:15 < CIA-27> synfig: dooglus * r1751 /synfig-studio/trunk/src/gtkmm/ (dock_history.h dock_history.cpp): Added a new icon to the History panel to clear out all the undo and redo history at once.
20:21 < dooglus> that 'fast' checkbox was one of the first things I added to synfig
20:22 < dooglus> http://dooglus.rincevent.net/synfig/gradient.html
20:32 < Yoyobuae> so you're the one that made the NearestPointOnCurve function =)
20:36 < dooglus> I guess so
20:36 -!- xerakko [n=Miguel@debian/developer/xerakko] has joined #synfig
20:40 -!- pixelgeek [n=chatzill@c-71-59-140-184.hsd1.or.comcast.net] has joined #synfig
20:55 -!- xerakko [n=Miguel@debian/developer/xerakko] has quit [Read error: 110 (Connection timed out)]
20:55 -!- xerakko [n=Miguel@debian/developer/xerakko] has joined #synfig
21:13  * genete is back (gone 02:19:06)
21:14 < genete> I noticed also that render with fast uncheked is more accurate but slower.
21:15 < pixelgeek> Makes sense to me...
21:18 < pixelgeek> I just realized that I've been using svn co to update to the latest each time.  Does that 'touch' each file so they all have to be rebuilt? 
21:18 < pixelgeek> It seems like co -uv is copying more files than it needs to.
21:45 < Yoyobuae> for me "svn co" only updates the changed files
21:45 < Yoyobuae> but there are files specific to svn that are also inside the sources folders
21:45 < Yoyobuae> the ones under the directory named ".svn"
21:49 < Yoyobuae> if you want you can grep the output of sources_*.sh scripts, eliminating the lines with ".svn" on them
21:51 < pixelgeek> so it appeared to me that svn co updated around 15 files from 1741 to 1751.  All in studio
21:51 < pixelgeek> when I ran sources_core, it copied sveral files over, even though none had changed AFAIK
21:52 < pixelgeek> when I ran sources_studio, it seemed a lot more files than svn co got copied over.  
21:52 < pixelgeek> And studio still took 25 minutes to make.  How does dooglus rebuild in a matter of seconds?
21:55 < genete> have anyone tried to convert an inline canvas into a Time Loop type? It seems to be buggy.
21:56 < genete> The first strange thing is that when you convert the canvas it does't loose the waypoints as the rest of parameters
21:56 < genete> and the second thing is that the time loop seems not to work
22:01 < genete> http://www.darthfurby.com/genete/synfig/canvaslooptime.sifz
22:01 < genete> that's the file. Can anyone load it and verify what I say?
22:02 < genete> I expect that both circles have the same loop movement
22:02 < genete> they have same waypoints on center parameter
22:03 < genete> but one of them uses the time loop convert type at the center (the red one) and the other uses the time loop convert at the paste canvas (the red one).
22:04 < genete> The red one doesn't repeat the cycle
22:04 < dooglus> pixelgeek: it depends what files changed
22:04 < dooglus> if only a few .cpp files change, make will rebuild just those and relink
22:05 < dooglus> but if a .h file changes, and that file is used by lots of .cpp files, all the cpp files will need rebuilding
22:06 < dooglus> pixelgeek: r1748 changed duck.h (for no good reason, too!) and so resulted in quite a large rebuild
22:06 < dooglus> pixelgeek: the other thing is that I tend to run 'make install' only in the folders I know need rebuilding
22:07 < dooglus> if I didn't touch studio/src/synfigapp, I'll build only in studio/src/gtkmm for instance
22:08 < dooglus> a bigger time saving - if I edited only in core/src/synfig, I won't build any of the core/src/modules/mod_*/... stuff, which can take a while to run through even if nothing has changed, since it seems to like to relink everything anyway
22:16 < dooglus> genete: I see the same as you
22:16 < genete> so it is a bug?
22:16 < dooglus> I guess so
22:16 < genete> ok
22:17 < genete> I've solved the problem jsut inserting a time loop layer on top of the ancapsulated version of the circle
22:17 < genete> so I can continue working on my animaiton
22:17 < genete> but it is a new bug
22:18 < dooglus> what's the fix?  make 'time loop' not allowable for canvases?  :)
22:18 < genete> heeh
22:18 < genete> :)
22:19 < genete> I'll post the bug traker
22:19 < dooglus> did you see the waypoints in the children dialog and params panel now too?
22:20 < genete> yes I see them. Also see them overlapping the type column when add a forward time loop layer...
22:20 < genete> sorry
22:20 < genete> when I modify the time offset
22:23 < genete> http://i85.photobucket.com/albums/k74/Genete/synfig/Pantallazo-Parmetros-2.png
22:23 < genete> like that
22:23 < dooglus> nice
22:23 < pixelgeek> hmmmm...  One character change in the about file still takes about a minute and a half to recompile.   
22:23 < genete> that happen too to the child Valuenodes
22:24 < dooglus> pixelgeek: it has to re-link all the .o files into a new executable
22:24 < dooglus> genete: yes - a single fix will probably fix both problems
22:24 < pixelgeek> So that's about as fast as it gets?
22:24  * genete thinks pixelgeek is compile time obssesed ;)
22:24 < dooglus> pixelgeek: it depends on the speed of your hard drive I guess
22:25 < pixelgeek> I thought you said that you could turn around builds in seconds....
22:26 < pixelgeek> genete: I want to understand if there are any optimizations in the process.  It takes way too long for me to use my typical programming style with this large a program.'
22:26 < genete> pixelgeek: (/me just kidding) ;)
22:26 < dooglus> pixelgeek: here's a test I just ran (in the 'gtkmm' dir:
22:26 < dooglus> $ date && touch about.cpp && make | wc && date && make install | wc && date
22:26 < dooglus> Mon Feb 18 22:25:43 CET 2008
22:26 < dooglus>       9     520   12638
22:26 < dooglus> Mon Feb 18 22:26:01 CET 2008
22:26 < dooglus>       6      33     582
22:26 < dooglus> Mon Feb 18 22:26:13 CET 2008
22:26 < dooglus> 18 seconds to build; 12 seconds to install; 30 seconds total
22:27 -!- xerakko_ [n=Miguel@119.pool80-103-172.dynamic.orange.es] has joined #synfig
22:27 < pixelgeek> So it probably takes a little longer to make the windows installer....
22:27 < dooglus> without the 'touch':
22:27 < dooglus> $ date && make | wc && date && make install | wc && date
22:27 < dooglus> Mon Feb 18 22:27:10 CET 2008
22:27 < dooglus>       1       7      36
22:27 < dooglus> Mon Feb 18 22:27:12 CET 2008
22:27 < dooglus>       6      33     582
22:27 < dooglus> Mon Feb 18 22:27:24 CET 2008
22:27 < dooglus> 2 seconds to build; 12 seconds to install
22:28 < dooglus> you shouldn't need to be building the windows installer every time though should you?
22:28 < dooglus> you just need to build the executables and libraries
22:29 < dooglus> that 30 second build doesn't include packaging up into a .deb for distribution
22:31 < pixelgeek> yes - I need to tweak the scripts to make that optional
22:35 < pixelgeek> Looks like it's part of 'make package'
22:37 < dooglus> I don't seem to have copies of the scripts any more
22:41 < pixelgeek> so Makefile.am has an "if WIN32_PKG" to make the installer.  But where is Win32_PKG defined?
22:44 -!- MangoFusion [n=jamesu@host81-132-205-163.range81-132.btcentralplus.com] has joined #synfig
22:44 -!- xerakko [n=Miguel@debian/developer/xerakko] has quit [Read error: 110 (Connection timed out)]
22:45 < dooglus> which Makefile.am?
22:45 < dooglus> none of mine have it
22:45 -!- xerakko_ is now known as xerakko
22:46 < Yoyobuae> wouldn't the configuration step detect a windows build and insert it into makefiles?
22:52 < dooglus> yes, but not into Makefile.am - they're source controlled
22:52 < dooglus> Makefile.in or Makefile are the 'derived objects'
22:52 < Yoyobuae> hmm, you're right
22:55 < pixelgeek> makefile.am in _src/syfig-studio
22:56 < Yoyobuae> i also have it
22:56 < pixelgeek> win32build.sh calls make package as a last step.  
22:56 < pixelgeek> I think I'm looking at this backwards.  I need to step through from the beginning...
22:57 < Yoyobuae> i think both, synfig-core and synfig-studio have a "make install" target
22:57 < Yoyobuae> that "should" install them inside MSYS
22:58 < Yoyobuae> then it would be possible to copy over binaries into the real Windows install
22:58 < dooglus> I see:
22:58 < dooglus> make install prefix=${SYN_TEMP_INSTALL}/synfig-devel
22:58 < dooglus> it's specifying where to install to
22:59 < dooglus> is there any need for all this copying around?  why not just build in the svn directory?
22:59 < pixelgeek> ask darco?  ;)
23:00 < dooglus> genete: this inline-canvas thing - I'm wondering what it should do
23:00 < genete> dooglus: I guess it should to the same as any other param
23:00 < dooglus> genete: what if the canvas wasn't in-line, but was switching between different exported canvases?  you wouldn't expect it to time-shift the exported canvases would you?
23:01 < dooglus> genete: the 'canvas' parameter is a contant: "for all time, use this inline canvas"
23:01 < dooglus> so time-looping it doesn't affect it, since the parameter is constant
23:02 < dooglus> if the canvas parameter was "at 0s use can1; at 1s use can2", then I would expect your 2s time loop to make it uses can1 at 3s, 5s, 7s, etc.
23:02 < dooglus> but your canvas parameter is just "whatever the time, use this inline canvas"
23:02 < genete> ok, it makes sense
23:02  * pixelgeek gets a cupful of liquid that is almost, but not quite, entirely like tea.
23:03 < Yoyobuae> actually the paste canvas uses "time offset" to set the time of its canvas
23:03 < dooglus> genete: what about a pastecanvas layer's "offset" - the inline canvas itself is animated, say, but the offset is constant
23:03 < dooglus> time-looping the offset doesn't change anything
23:03 < Yoyobuae> remember fingers.sif?
23:04 < dooglus> Yoyobuae: it does, yes.  is it consistent in doing that?
23:04 < Yoyobuae> the thing is that time offset is an offset from the current time
23:05 < Yoyobuae> first it's needed to add a negative linear with rate -1s
23:05 < dooglus> not the current time, I don't think - the parent's time
23:05 < genete> I think that time looping time ofset will work. I did it previously for particles.
23:05 < dooglus> ie. they nest...  if you embed a series of encapsulations, each with a small time offset, the offsets are cumulative
23:06 < Yoyobuae> the "current time" as far as the layer is concerned =)
23:06 < dooglus> right
23:06 < dooglus> Yoyobuae: it gets messy - what if a layer is used in 2 different places?
23:07 < dooglus> Yoyobuae: ie. inside 2 different encapsulations, which have 2 different time offsets.  what's the time in that layer then?
23:07 < Yoyobuae> both
23:07 < dooglus> you would hope so - but I don't think it si
23:07 < Yoyobuae> it happens like it does with a duplicate
23:07 < dooglus> I think synfig sets the time first, then renders
23:10 < dooglus> http://dooglus.rincevent.net/random/3layers.sifz
23:10 < dooglus> one circle, used in 3 places, with 3 different time offsets
23:10 < dooglus> they shouldn't move as one, but they do
23:12 < genete> but look at the canvas parameter waypoints
23:12 < genete> they are placed properly
23:14 < Yoyobuae> uhmm, the canvas is exported
23:14 < Yoyobuae> they are all linked together
23:14 < dooglus> if you don't export it, how would you use a layer in 2 different places?
23:15 < Yoyobuae> need a "duplicate canvas" command
23:16 < Yoyobuae> in fingers.sif i had to manually duplicate the canvases as "finger1", "finger2", "finger3"
23:16 < dooglus> I want to be able to have the first second of my canvas be a walk cycle, and re-use that wherever I want my character walking?
23:16 < Yoyobuae> you can, just no more than one at a time
23:18 < Yoyobuae> the code in accelerated_render of paste layer goes like:
23:18 < Yoyobuae> canvas->set_time(curr_time+time_offset);
23:18 < Yoyobuae> ...
23:18 < Yoyobuae> context.accelerated_render(surface,quality,renddesc,&stageone)
23:18 < Yoyobuae> ...
23:18 < Yoyobuae> canvas->get_context().accelerated_render(&pastesurface,quality,desc,&stagetwo)
23:19 < Yoyobuae> the time for the canvas is set in the top layer, then the lower layer renders setting time AGAIN
23:19 < Yoyobuae> that might be a problem
23:19 < genete> interesting... try to encapsulate the second circle layer (the child one). 
23:20 < genete> it encapsulates the first one.
23:20 < genete> now undo that action. Then a ghost Inline canvas layer appears a the second and third cicle canvases.
23:23 < Yoyobuae> saving then reverting seems to correct the problems
23:23 < genete> yes
23:24 -!- xerakko [n=Miguel@debian/developer/xerakko] has quit ["Ex-Chat"]
23:25 < Yoyobuae> genete: what do you think? should the 3 circles be different on dooglus's example?
23:26 < genete> I think that according to the waypoints positions of the canvas parameter the animation should be different for each one.
23:26 < dooglus> Yoyobuae: notice the 'muck_with_time' variable?
23:26 < dooglus> Yoyobuae: I think the idea is that all the set_time() tree happens first, and then all the acc_render() happens after
23:26 < Yoyobuae> dooglus: but why?
23:26 < dooglus> Yoyobuae: I see there's a set_time() inside acc_rendeR() for pastecanvases, but it's guarded by that 'muck' variable (whatever that's for)
23:27 < dooglus> Yoyobuae: the "why" is never really explained.  all we have is the "what", in the form of a big lump of source code :)
23:28 < Yoyobuae> dooglus: then the question is: should it be changed? =)
23:29 < Yoyobuae> i think its logical that the canvas is rendered according to the time offset of the parent paste layer
23:29 < dooglus> Yoyobuae: right.  and I don't know the answer to that one.
23:30 < dooglus> what could be the reason for having 2 separate sweeps of the tree (set time, then render)
23:30 < Yoyobuae> why should things inside a paste canvas be affected by some unrelated paste canvas that just happened to be rendered first?
23:30 < Yoyobuae> assuming but paste layers have the same canvas
23:32 < dooglus> I'm not clear on the way the tree is traversed
23:32 < dooglus> there are links between values, etc.
23:32 < dooglus> how is that handled?
23:32 < Yoyobuae> parameter tree or layer tree?
23:32 < dooglus> if we set-time-and-render as a single step
23:33 < dooglus> but the first layer we render has a parameter which is the sum of 2 parameters in layers we didn't render yet...
23:34 < Yoyobuae> that parameter is evaluated in its parent layer's time
23:34 < Yoyobuae> the parameters in the other layer are also evaluated in that same time
23:34 < Yoyobuae> in a sense, valuenodes are independent of time
23:35 < Yoyobuae> the layer evaluating the valuenodes sets the time they use
23:36 < dooglus> is this what 'muck with time' is all about?
23:40 < Yoyobuae> muck_with_time_ is only set directly to "true" on the constructor
23:41 < Yoyobuae> and set_muck_with_time gets called only twice on canvas.cpp
23:41 < Yoyobuae> setting muck_with_time_ to false, doing some stuff, then setting it back to true
23:45 < dooglus> I'm thinking the idea is that if muck_with_time is true then each pastecanvas gets to see its own local time, and my circles move separately
23:45 -!- Yoyobuae [n=Yoyobuae@201.224.135.156] has quit [Read error: 104 (Connection reset by peer)]
23:46 < factor> I hate it when i realize idefined both true and false to 0
23:47 -!- Yoyobuae [n=Yoyobuae@201.224.135.156] has joined #synfig
23:47 < factor> heh, muck ewith time an actual value
23:48 < Yoyobuae> muck_with_time_ is pretty much always "true"
23:49 < Yoyobuae> except during the small piece of code inside synfig::optimize_layers on canvas.cpp
23:51 < dooglus> ok, so why isn't the time being mucked with?
23:52 < dooglus> aah, because "canvas->get_time()!=curr_time+time_offset" isn't being reevaluated
23:55 < Yoyobuae> hmm, i personally would re-write that as "canvas->get_time()!=(curr_time+time_offset)"
23:56 -!- MangoFusion [n=jamesu@host81-132-205-163.range81-132.btcentralplus.com] has quit ["Not here"]
23:56 < Yoyobuae> it helps clarity
23:56 < Yoyobuae> even if precedence rules make it work like intended
23:57 < dooglus> g++-4.3 adds quite a lot of similar warnings
23:57 < dooglus> but it doesn't go quite that far
23:57 < dooglus> it tells me it doesn't like x&&y||z
23:57 < dooglus> and tells me to put brackets around the &&
23:58 < dooglus> but it doesn't complain about x!=y+z
23:59 < Yoyobuae> i usually go overboard with parentheses, its better to have too many than too little of them
--- Log closed Tue Feb 19 00:00:00 2008