--- Day changed Sat Sep 30 2006
04:43 -!- cnieves [~cnieves@28.pool85-57-133.dynamic.uni2.es] has joined #geda
04:43 < cnieves> Good morning!
04:46 < cnieves> oh, seems people is sleeping yet... :-)
05:15 < Igor2_off> hi :)
05:15 < Igor2_off> yeah, Ales was here a few hours ago, he was going to sleep :)
05:22 < cnieves> Hi! 
05:22 < cnieves> Yes, it's too early for them to be here :-)
05:22 < cnieves> have you been here for a long time?
05:32 < Igor2_off> yeah :)
05:32 < Igor2_off> i'm here every day
05:32 < Igor2_off> set my irc client to join here
05:32 < Igor2_off> today from 5:30 am :)
05:33 < cnieves> wow! why so early?
05:33 < Igor2_off> going to sleep early, getting up early, like peasants or chickens :>
05:34 < Igor2_off> (but when needed, i can do 24 or even >36 hours in a row:)
05:35 < cnieves> amazing! too early for me (at least I need a good reason to wake up so early) ;-)
05:36 < Igor2_off> i remember challenge24: my team members were too tired so they went home after the 24h coding (~28h uptime) but i stayed to learn the results in live, then when i came home, i sat down and coded a bit :>
05:36 < Igor2_off> :)
05:36 < Igor2_off> so you are the evening-kind guy :)
05:36 < Igor2_off> there are scientific researches on this topic, some people have their optimal performance in the morning so they wake up early, others rather stay up for late 
05:37 < Igor2_off> some researchers even say that schools should respect this, since children belonging to the latter group have hard time trying to concentrate at 8 am :)
05:39 < Igor2_off> what will you do for the code sprint?
05:39 < cnieves> bug hunting ;-)
05:40 < cnieves> I'll try to reduce the number of open bugs and patches in the tracker...
05:40 < Igor2_off> nice :)
05:40 < Igor2_off> in pcb or in gschem? :)
05:41 < cnieves> gaf but pcb. I haven't looked at pcb source code yet.
05:43 < Igor2_off> good, i will spectate :>
05:44 < cnieves> didn't you choose something you want to do?
05:45 < Igor2_off> hmmz, how to say it in english
05:45 < Igor2_off> i'll be cooking my own meal (sorry for the 1:1 translation:)
05:45 < Igor2_off> I'll work on the scriptable external hid stuff :)
05:48 < cnieves> nice! look forward to see it integrated in PCB. It seems it can open the door for a new set of features.
05:50 < Igor2_off> i rather see it as a co-project which should never integrate :)
05:50 < Igor2_off> not that i wouldn't like to see integration, but you know, the dependency-panic :)
05:52 < Igor2_off> i mean half of the community behind gEDA would happily create a new scripting language just to avoid dependencies, since "this is what makes gEDA easier for the end users" :)
05:52 < Igor2_off> (while i rather use GPMI and let the users use their favorit languages like perl, python, tcl)
05:54 < Igor2_off> haha, just found a DOS User's Guide from 1986 in a nice box, with a chinese license paper :)
05:56 < cnieves> I meant "having PCB use the gpmi mode". I don't care if the code is integrated or not.  why do you want a DOS user's guide?
05:57 < Igor2_off> i'm a collector of old computer related stuff
05:57 < Igor2_off> like there's a DEC vt420 near my bed, still in use :)
05:58 < cnieves> :) . Next time I will ask you before throwing away some computer stuff... ;-)
05:59 < Igor2_off> thanx :)
06:00 < Igor2_off> even my desktop computer doesn't have any part younger than 10 years, hehe :)
06:00 < Igor2_off> ok, that's false, it has a dvd rom now, as it was almost as cheap as a cdrom :)
06:02 < Igor2_off> btw, are you willing to test my stuff?
06:03 < Igor2_off> John stopped testing it suddenly and i think i've found and killed the last bug :)
06:04 < cnieves> I should confess I've not ever used pcb, so I'm not the best choice to test it... :-)
06:04 < Igor2_off> :)
06:05 < Igor2_off> it should be "download pcb source, install it, download my source, compile it, make test, if a menu appears, it works" :>
06:06 < cnieves> I'm curious. have you seen swig (www.swig.org) before? It seems both projects share the same goals...
06:07 < Igor2_off> yes :)
06:07 < Igor2_off> there are some basic differences
06:07 < Igor2_off> last time i've checked, they went only for the languages and they made a wrapper-generator
06:08 < Igor2_off> while languages is only 50% of what gpmi offers while gpmi is strictly a lib so adding a new language won't trigger recompile of all applications using gpmi
06:10 < Igor2_off> also i am not sure swig allows language/application independent packages like gpmi does :)
06:11 < cnieves> I see. Of course it's better if you don't have to recompile. I'm going to try a quick test (just compiling and run)
06:11 < Igor2_off> thanx :)
06:11 < Igor2_off> currently it doesn't have the gpmi part
06:11 < Igor2_off> only the external HID part
06:12 < Igor2_off> so one can inject a HID into PCB without recompiling PCB
06:12 < Igor2_off> (and i have a dummy HID that prints the number of holes, as shown in the report window, into a text file)
06:18 < cnieves> ok, I installed PCB. Now, what have I to do?
06:18 < Igor2_off> do you have an svn client or should i tar the current version?
06:19 < cnieves> I have svn, but you have to tell me the exact line I should type (I'm more familiar with cvs)
06:20 < Igor2_off> ok :)
06:20 < Igor2_off> svn checkout svn://igor2.peticio.hu/pcb-gpmi/trunk
06:21 < cnieves> got it. cd trunk/src;make install?
06:21 < Igor2_off> in doc/ there's a Readme that should guide you; if anything is unclear or fails, just feed back and i'll fix it instantly :)
06:22 < Igor2_off> you'll need to symlink or copy pcb source so it can find it :)
06:22 < Igor2_off> (alternatively you can tell configure where to look for the sources: ./configure /full/path/to/pcb/source
06:23 < cnieves> Mmm... I have problems:
06:24 < cnieves> $ make test
06:24 < cnieves> cd host_lib; make
06:24 < cnieves> make[1]: se ingresa al directorio `/home/cnieves/temp/libgpmi/trunk/src/host_lib'
06:24 < cnieves> make[1]: No se hace nada para `all'.
06:24 < cnieves> make[1]: se sale del directorio `/home/cnieves/temp/libgpmi/trunk/src/host_lib'
06:24 < cnieves> cd board_summary; make
06:24 < cnieves> make[1]: se ingresa al directorio `/home/cnieves/temp/libgpmi/trunk/src/board_summary'
06:24 < cnieves> make[1]: `board_summary.so' está actualizado.
06:24 < cnieves> make[1]: se sale del directorio `/home/cnieves/temp/libgpmi/trunk/src/board_summary'
06:24 < cnieves> cd host_lib; ./test.sh
06:24 < cnieves> PCB-GPMI [2]: PCB-GPMI HID booter loaded.
06:24 < cnieves> PCB-GPMI [4]: [host-lib] strrchr("pcb-bin",'/')
06:24 < cnieves> PCB-GPMI [4]: [host-lib] resolving real strrchr()
06:24 < cnieves> PCB-GPMI [4]: [host-lib] found real strrchr: 0x406fcb30
06:24 < cnieves> PCB-GPMI [4]: [host-lib] resolving gui
06:24 < cnieves> ./test.sh: line 10:  6497 Violación de segmento   (core dumped) pcb-bin
06:24 < cnieves> make: *** [test] Error 139
06:24 < Igor2_off> ohh, segfault! :)
06:24 < Igor2_off> did it find the same version of pcb sources that is run when you type pcb in a shell?
06:26 < Igor2_off> (meanwhile adding some more debug output)
06:28 -!- Igor2_off is now known as Igor2Code
06:31 < cnieves> I had pcb 20050609 installed from the distribution package. I got the lastest source snapshot, and installed it. The pcb I installed was not in the path, so I added the bin directory to the path and rerun make test: it failed with a segfault.
06:32 < Igor2Code> ok, i think i've found a bug near the line that was the last for you before it crashed :)
06:32 < Igor2Code> please do "svn up" in pcb-gpmi dir and run make; make test
06:33 < Igor2Code> (i've also added more debug text so we'll se what happens after resolving gui:)
06:38 < cnieves> I got the PCB window!! :-) 
06:38 < cnieves> PCB log window shows:
06:38 < cnieves> illegal fileformat
06:38 < cnieves> Can't find font-symbol-file 'default_font'
06:38 < Igor2Code> great :)
06:38 < Igor2Code> please open the file menu
06:38 < Igor2Code> or, wait,
06:38 < Igor2Code> first put down some vias or whatever
06:38 < Igor2Code> draw something random :0
06:38 < Igor2Code> then open the file menu and choose export
06:38 < Igor2Code> if there's an exporter called "board-summary"
06:39 < Igor2Code> it works :)
06:40 < cnieves> file->export only shows gerber, bom, ps and eps (I didn't compile the png support since I didn't have libgd installed)
06:40 < Igor2Code> hmmz, then something went wrong :)
06:40 < Igor2Code> could you mail me the output of the test? 
06:42 < Igor2Code> meanwhile i update pcb sources to cvs head to see whether it still works (I have a few days old version:)
06:46 < Igor2Code> dcc, even better :)
06:46 < Igor2Code> nice big log it created, hehe :)
06:46 < cnieves> :-)
06:48 < Igor2Code> now i see your window/desktop manager makes the loading different
06:49 < Igor2Code> and finally, it couldn't find the gui symbol, this why it didn't load the board-summary HID
06:49 < Igor2Code> so i will check what version the latest snapshot was made from
06:50 < Igor2Code> and what the symbol was called there :)
06:52 < Igor2Code> 20060822?
06:53 < Igor2Code> is that what you are trying with?
06:55 < cnieves> I think so. I downloaded the last snapshot, not the CVS.... should I try with the CVS?
06:55 < Igor2Code> wait with that please :)
06:55 < Igor2Code> first i wait the cvs version to finish compile
06:55 < Igor2Code> then i check the diff between that 20060822 version and the cvs one
06:56 < Igor2Code> maybe i can make the loader work with both versions, who knows :)
06:56 < Igor2Code> (i guess most of the potential users/testers don't use the cvs version anyway)
07:00 < Igor2Code> haha, gcc on one terminal, gzip -d on the other and i still can play mp3 :)
07:00 < Igor2Code> 166 MHz is much :)
07:01 < cnieves> only for text terminals ;-)
07:01 < Igor2Code> actually i also run X on it :)
07:02 < Igor2Code> (because now i'm testing pcb)
07:02 < cnieves> :-)
07:05 < Igor2Code> strange, the symbol didn't get renamed
07:07 < Igor2Code> could you copy the output of uname --all?
07:08 < cnieves> Linux otilio 2.6.16.20 #4 Sat Jun 24 19:33:12 CEST 2006 i686 GNU/Linux
07:08 < cnieves> 19:33??
07:09 < Igor2Code> heh, it works on another comp i have access to with Linux JAIL 2.6.16.16bea4 #4 PREEMPT Tue Jun 27 10:56:30 CEST 2006 i686 GNU/Linux
07:09 < Igor2Code> so i guess it's not the kernel :)
07:10 < cnieves> what time does 'uname -a' return? a 'date' command gives the correct time...
07:11 < Igor2Code> it returns info about your kernel, when it was built
07:12 < Igor2Code> if you have some more time, I am going to implement a different method for resolving the symbol that might work better :)
07:16 < Igor2Code> commited, svn up; make; make test please :)
07:19 < cnieves> got the same result...
07:20 < Igor2Code> what distrib do you use?
07:20 < Igor2Code> maybe i should install the same distrib/version in a virtual server to reproduce this
07:21 < Igor2Code> yeah, it couldn't find the symbol with this method either :(
07:45 < cnieves> I'm going to lunch. See you later!
07:45 < Igor2Code> cu, thanx for the testing :)
08:20 < Igor2Code> maybe i've found the problem, but i'm not sure :)
08:34 < cnieves> I'm back, so I can do some more test if you want.
08:35 < Igor2Code> thanx, i ran some tests on sourceforge compile farm and found that some compile time flags in pcb are important
08:36 < Igor2Code> so unless you don't compile pcb by hand, you can't guarantee it works
08:36 < Igor2Code> however, i have a separate test suite
08:36 < Igor2Code> it would help if you could try that :)
08:38 < Igor2Code> svn checkout svn://igor2.peticio.hu/pcb-gpmi/branches/hook-test
08:38 < Igor2Code> make; ./test.sh
08:38 < Igor2Code> it should produce a ~15 lines output which i'm interested in :)
08:39 < cnieves> Here are:
08:39 < cnieves> PCB-GPMI [2]: PCB-GPMI HID booter loaded.
08:39 < cnieves> main.
08:39 < cnieves> main_register called from main
08:39 < cnieves> strrchr 1: tring
08:39 < cnieves> strrchr 2: tring
08:39 < cnieves> strrchr 3: tring
08:39 < Igor2Code> hmmz, looks too short :>
08:40 < cnieves> I know, but there are no more... :-)
08:40 < Igor2Code> what distrib are you using? :)
08:41 < cnieves> debian unstable.  What more output weere you expecting? I only see 4 printf in the test.c file...
08:41 < Igor2Code> great, debian, i love debian :)
08:41 < Igor2Code> i use debian too, but stable
08:41 < Igor2Code> sooo, it should be relatively easy to reproduce your system on my university comp...
08:42 < Igor2Code> open main.c :)
08:42 < Igor2Code> the trick is this:
08:42 < Igor2Code> test.c doesn't know that an external .so would be loaded into the same process image
08:43 < Igor2Code> main.c should try to hook on test.c in a way that it is called transparently trough strrchr() libc calls
08:43 < Igor2Code> on every strrchr() call main.c does some work then calls real strrchr()
08:44 < Igor2Code> main.c tries to resolve symbol called "gui" (defined in test.c) and waits until it gets initialized (by test.c)
08:44 < Igor2Code> when it's already initialized, main.c calls a function from test.c demonstrating it has access to test.c's stuff :)
08:46 < Igor2Code> Need to get 61.4MB of archives.
08:46 < Igor2Code> haha, it was long ago i've last upgraded my unstable chroot :)
08:53 < Igor2Code> great, i can reproduce the problem
08:56 < Igor2Code> omg, omg, OMG!
08:57 < Igor2Code> want to laugh? :)
08:57 < Igor2Code> in the new version of glibc, strrchr became a macro, this why it failed :)
08:58 < cnieves> :-)
08:58 < Igor2Code> at least this why the test case fails badly :)
08:59 < cnieves> what makes the difference? the use should be the same... are you doing some test to see if it's really a function?
09:00 < Igor2Code> nope :)
09:01 < Igor2Code> the trick is that the lib tries to be transparent so you don't need to patch/recompile the program (pcb)
09:01 < Igor2Code> for this, i use dirty tricks
09:01 < cnieves> oh, you load the function using dlopen.... but it fails because it is a macro... isn't that?
09:01 < Igor2Code> i need a dynamic library call which the program does, and there my lib can stand between the program and the librrary (libc6 in this case)
09:01 < Igor2Code> no :)
09:02 < Igor2Code> the actual method i use for standing between the program and libc6
09:02 < Igor2Code> is that i redefine a standard function call, strrchr in this case
09:02 < Igor2Code> so when the program calls strrchr and the programmer assumes it's a whatever call to libc6
09:02 < Igor2Code> i say i assume it is a function call, and i will catch that function call from my lib :)
09:03 < Igor2Code> as soon as it becomes a macro, no function call is performed so there's nothing i could catch :)
09:03 < Igor2Code> it seems you have an strrchr function in your libc, and it is used by the precompiled pcb binary you used so there my lib could stand in between pcb and libc6 (the logs showed that)
09:03 < cnieves> :) funny thing!
09:04 < Igor2Code> but when you compile the test case, strrchr is a macro :)
09:04 < Igor2Code> the precompiled thing can't work, since it was not compiled using the -rdynamic gcc option :)
09:04 < Igor2Code> if you compile pcb from source,  it won't work because the macro :)
09:04 < Igor2Code> so i need to find another entry point...
09:05 < Igor2Code> (actually long term i hope that the devs are willing to apply a few line patch that provides a real interface for this and i don't need this library hacking)
09:05 -!- sdb [~sdb@WHITAKER-THREE-SEVENTY-EIGHT.MIT.EDU] has joined #geda
09:05 < sdb> Hi Guys --
09:05 < sdb> I just got everything set up here at MIT.
09:05 < cnieves> Hi Stuart! welcome!
09:05 < Igor2Code> hi :)
09:05 < sdb> Ales is on the way, and I suppose DJ is coming, although I don't know where he is.
09:06 < sdb> Hi Carlos, Hi Igor!
09:06 < cnieves> good morning (for you)! did you have enough coffee today? ;-)
09:07 < sdb> Not enough coffee yet. . . .  :-(
09:07 < sdb> So the first thing I am going to do is fix the issues gattrib has with 
09:08 < sdb> adding and deleting columns, and the problem that that changes the attribute text visibility
09:08 < sdb> This is a bug I discovered some weeks ago. . . . .
09:08 < sdb> BTW, Carlos, I saw your stuff come across the cvs mailing list this morning.  I am
09:08 < sdb> updating right now.  Is there anything I should test for?
09:10 < cnieves> I don't think so, I just improved the mechanism for adding the titleblock when a new page is created. Now it's only added when an empty page is created. It's disabled by default, so you should see no difference.
09:11 < cnieves> I saw a bug report about gattrib crashing when no file is loaded... do you also plan to fix that?
09:11 < sdb> I think I fixed that, but I need to close the bug report.
09:12 < sdb> First I'll just run through the buggy use case again and then I'll close it if
09:12 < sdb> the bug is gone.
09:12 < cnieves> oh! ok
09:13 < Igor2Code> >cnieves> I've found the best way to search for a new entry point: I am running ltrace on pcb to see what library calls does it do then will check whether they are macros in the new libc version :)
09:14 < cnieves> igor: ok. Tell me if you want to do some testing.
09:15 < Igor2Code> ok, thanx :)
09:15 < Igor2Code> i think i'll use fopen
09:15 -!- Cesar [~Cesar@c9344c0b.virtua.com.br] has joined #geda
09:16 < Igor2Code> hi Cesar :)
09:16 < Cesar> hi to all ;-)
09:18 < cnieves> Hi Cesar!
09:19 < sdb> Hi Cesar!
09:20 < Cesar> Hi cnieves, hi sdb!
09:20 < Cesar> Anything you want to test on Windows, just ask.
09:23 < cnieves> I left the patch regarding stricmp opened just in case there was some problem. Did you test it on both mingw and cygwin?
09:26 < Cesar> Cygwin is fine. I will test it on MinGW now.
09:31 < Igor2Code> >cnieves> please "svn up" in hook-test
09:31 < Igor2Code> make clean; make; ./test.sh should work now
09:34 < cnieves> igor: the output is:
09:34 < cnieves> PCB-GPMI [2]: PCB-GPMI HID booter loaded.
09:34 < cnieves> main.
09:34 < cnieves> PCB-GPMI [2]: PCB-GPMI HID Trying to resolve gui ((nil))
09:34 < cnieves> PCB-GPMI [4]: PCB-GPMI HID resolved gui: 0x804998c
09:34 < cnieves> PCB-GPMI [2]: PCB-GPMI HID searching main_register_ptr
09:34 < cnieves> PCB-GPMI [2]: PCB-GPMI HID found main_register_ptr 0x8048644
09:34 < cnieves> PCB-GPMI [2]: PCB-GPMI HID Registering...
09:34 < cnieves> main_register called from .so
09:34 < cnieves> main_register called from main
09:34 < Igor2Code> great, thanx :)
09:34 < Igor2Code> now i am going to test it on sourceforge compile farm
09:35 < Igor2Code> i'm sure it would fail on half of the systems in the current form :>
09:35 <@Ales> hi everybody
09:35 < Igor2Code> hi Ales :)
09:35 < cnieves> igor: well, at least you have 50% of the job done!
09:35 < cnieves> Hi Ales! welcome!
09:35 <@Ales> Hi Igore
09:35 <@Ales> Igor
09:35 <@Ales> Hi Carlos
09:36 <@Ales> how is everybody?
09:36 < Cesar> Hi Ales.
09:36 <@Ales> Hi Cesar
09:37 < cnieves> I've been up and coding all this morning, so I'm ready... and you? everything right at MIT?
09:37 <@Ales> yup, Stuart and I are here at MIT
09:38 <@Ales> hey Carlos, are we ready to apply the "Zooming/panning while moving/copying" patch?
09:39 < cnieves> I'd love it. What are your feelings about it?
09:39 <@Ales> I'm looking at it right now.
09:39 <@Ales> if you want, I would be happy to apply it, that way I can get familiar with the changes
09:40 < cnieves> ok, do it. I'll need some help to track the drawing bug I found... 
09:41 <@Ales> is this drawing bug present in non-patched gschem? or is it something new?
09:41 < cnieves> new, and related with panning while rotating, so it couldn't show in the non-patched version.
09:42 <@Ales> okay
09:42 <@Ales> I'll spend time getting this into CVS today, but first I want to test out the new hook stuff you added
09:43 < cnieves> ok. Then update your CVS copy. I improved it this morning.
09:43 <@Ales> yeah, just did that
09:44 <@Ales> though I might pick a different titleblock for the default. :)
09:44 <@Ales> I would like to make this enabled by default
09:47 < cnieves> No problem. I took it just for showing the feature. One thing we should discuss: what should be the default placement position?
09:48 < cnieves> I set it to (1000,1000) because I like to have some free space around the titleblock, and because there were some drawing problems setting it to (0,0) (try it and you'll see).
09:48 <@Ales> I would also prefer it not at 0,0
09:48 <@Ales> 1000, 1000 is just fine
09:48 <@Ales> it won't really matter, as long as the zoom extents works correctly
09:50 < cnieves> ok. there is still the drawing problem near (0,0). Maybe nobody use to work there....
09:52 < Igor2Code> hah, my code dies on alpha :)
09:52 <@Ales> I will move it further into the middle only becuase on larger title blocks, zoom extents isn't so far out
09:54 <@Ales> yeah 10000,10000 works get
09:54 <@Ales> great
09:55 < cnieves> Ales: ok. One question: I'm taking a look at the bug "gschem should display schematics after window maximize"
09:55 < cnieves> do you want to do a zoom extents for all the schematics opened?
09:55 <@Ales> Carlos: yes, that's the bug fix
09:56 < sdb> Carlos,  Ales just showed me your new feature -- when you open gschem it loads
09:56 < sdb> a titleblock.  That's a great feature!  We love it!
09:56 < sdb> Thanks!
09:56 < cnieves> :-) Happy to know! it was a long standing bug, and this way it allows user customization... :-)
09:59 < sdb> Yeah, we like the way you can set the default titleblock in the system-gschemrc
10:00 <@Ales> Carlos: try this please.  Open up gschem with your new hook enabled, place a component, and redraw the display
10:00 <@Ales> or just draw a net...
10:00 <@Ales> I'm seeing the titleblock disappear
10:02 <@Ales> Carlos, you need to add the newly created object to the object_list for it to persist
10:04 < cnieves> I thought I did it... I tested the object list before and after running the hook, and it was one complex object more afterwards.... 
10:05 < cnieves> yeah, I have the same behaviour.
10:06 < cnieves> Ales, are you changing it?
10:09 < Igor2Code> >cnieves> new version is up, please svn up in pcb-gpmi
10:10 < Igor2Code> you will need to compile pcb from source unfortunately, to make sure -rdynamic is added
10:10 <@Ales> yeah, I'll fix it
10:10 < Igor2Code> >cnieves> if you are busy doing something, i could test it first on the unstable chroot i have (which should act just as your system:)
10:12 <@Ales> I think I can just fix it by changing new_object = ... to 
10:12 <@Ales> page->object_tail = o_complex_add(....
10:13 < cnieves> Igor:
10:13 < cnieves> cc -g -Wall -I /home/cnieves/temp/pcb-20060822//src   -c -o main.o main.c
10:13 < cnieves> main.c: In function 'pcb_gpmi_init':
10:13 < cnieves> main.c:14: warning: implicit declaration of function 'printf'
10:13 < cnieves> main.c:14: warning: incompatible implicit declaration of built-in function 'printf'
10:14 < cnieves> the errors continue (with fopen, feof,...)
10:15 < Igor2Code> yeah, but these are only warnings :)
10:15 < Igor2Code> does the compile stop because these?
10:16 < cnieves> Igor: not, it stops because of this
10:16 < cnieves> main.c: At top level:
10:16 < cnieves> main.c:67: error: conflicting types for 'fopen'
10:16 < cnieves> main.c:27: error: previous implicit declaration of 'fopen' was here
10:16 < Igor2Code> ohh, checking
10:17 < Igor2Code> fixed, svn up please :)
10:18 < cnieves> Ales: yeah, that's the fix.
10:20 <@Ales> and it's working... I'll check it in
10:20 < cnieves> Igor: I still see _only_ the other exporters.
10:21 <@Ales> note, there's a little bit more to adding complex objects if they have nets etc... in them... but for a simple titleblock this code works great
10:22 < cnieves> I'd prefer it to be a generic function. What more is needed?
10:25 <@Ales> lemme look what else is needed
10:28 <@Ales> yeah, the other parts are in o_complex_end for example.
10:28 <@Ales> I'll check in my fix first
10:28 <@Ales> most of the missing things deal with the connections to other objects
10:29 < Igor2Code> >cnieves> did you recompile pcb? :)
10:30 < cnieves> Igor: why? I got the CVS version this morning and it havent' changed.... did it?
10:31 < Igor2Code> because the compile time flags, i am not sure, but i suspect it was not compiled with -rdynamic and this why my lib can't find the gui symbol in it :)
10:31 < Igor2Code> let me do an experiment...
10:33 <@Ales> fix commited.
10:33 <@Ales> now I'll play with it some more and change the defaults in system-gschemrc
10:33 < Igor2Code> >cnieves> yeah, -rdynamic in pcb CFLAGS is mandatory :)
10:33 < Igor2Code> now i will need to find out how to make it
10:37 < cnieves> Igor: No rdynamic flags in either configure neither makefile. Is there an easy way?
10:37 < Igor2Code> don't know yet, i'm trying it :)
10:39 < Igor2Code> first i'm trying if it works without modification when compiled from source
10:43 <@Ales> Carlos, I'm seeing some flicker due to the o_redraw_single, I think I'm going to comment that out for now, since you don't necessarily want to redraw everytime a component is added
10:43 <@Ales> if this becomes more general, it might be a good idea to added a g_redraw_all scheme function
10:46 <@Ales> hmmm.. still seeing some flicker; apparently not due to the o_redraw_single...
10:46 <@Ales> I'll keep looking for it
10:47 < Igor2Code> pcb's ./configure is hell slow :)
10:48 <@Ales> okay, the flicker is unavoidable... I'll leave things alone
10:49 < cnieves> Ales: why? what's the problem?
10:51 <@Ales> when you run gschem for the first time, the zoom is all the way out... 
10:52 <@Ales> then the component is added (and you see it all small), and then the zoom extents happens
10:52 <@Ales> ^component^titleblock
10:52 <@Ales> it's not a problem really
10:54 < Igor2Code> >cnieves> found an easy way for adding rdynamic
10:54 < cnieves> so are there 3 redraws: empty, small component and after zoom extents?
10:54 < Igor2Code> (but it's generally bad to force the user to recompile pcb for any reason)
10:54 <@Ales> yup
10:55 <@Ales> that's the way it seems.
10:55 < cnieves> Igor: You can talk about it with DJ. Maybe it can be the default way. what's the way?
10:55 <@Ales> I'm not quite sure why it is showing up small since there is no redraw between the adding of the component and the zoom extents
10:55 <@Ales> (once I commented out the o_redraw_single)
10:56 < Igor2Code> >cnieves> the first way is to edit the Makefile in pcb/src/
10:56 <@Ales> I'll debug this to see what the heck it is doing
10:56 < Igor2Code> there's a line LDFLAGS=
10:56 < Igor2Code> you can add -rdynamic there
10:56 < cnieves> Ales: Maybe is there any other piece of code redrawing it?
10:56 <@Ales> that's what I'm thinking
10:57 <@Ales> it's not critical the way it is, but I would like to understand it
10:57 < Igor2Code> i am not sure, but i think another possible way is to export CC to be "gcc -rdynamic" before ./configure or mybe tell configure to use this as a compiler usign configure's command line arguments
11:00 <@Ales> okay, I understand it better now... 
11:00 < cnieves> Igor: I got a board summary exporter, and put a board_summary.txt filename. where did the file go? it is not in the current directory. I can send you the log.
11:01 < Igor2Code> it's in src/, near test.sh
11:01 < Igor2Code> (make test cds there :)
11:02 < Igor2Code> if the exporter appeared, i don't need the log, it all worked :)
11:03 < cnieves> Igor: Yes, it appeared. I expected a board_summary.txt file, but in the src directory I only have:board_summary/  configure*  host_lib/  log.txt  Makefile  Makefile.config 
11:03 <@Ales> the extra redraw was happening in i_callbacks_file_new when updating the scrollbars and such... 
11:03 <@Ales> these calls are not necessary
11:03 < Igor2Code> sorry, in host_lib/ :)
11:04 < Igor2Code> (after noon I can't even follow my own naming conventions:)
11:04 < cnieves> Igor: :-) Ok. It's there, and it is a report of the vias.
11:04 < cnieves> Igor: time for a "siesta" ;-)
11:04 < Igor2Code> thanx :)
11:04 < Igor2Code> too bad DJ is not here :)
11:06 <@Ales> yeah, where is DJ?
11:06 <@Ales> he's not here.. :(
11:08 < cnieves> Ales: I commented the *scrollbar_update and repaint_background in i_callbacks_file_new and it looks much better.
11:10 < cnieves> Ales: how do you debug the drawing code?
11:13 <@Ales> gdb. :)
11:13 <@Ales> I think I will also comment out the redraw in g_add_component
11:13 <@Ales> that way people can add N compomnents without redrawing inbetween
11:14 <@Ales> at some point, yeah, a g_redraw_all will be needed.
11:14 <@Ales> is this okay with you?
11:17 < cnieves> yes. I think it works without the redraw, because afterwards calling the function, a zoom extents is done, thus redrawing all the screen.
11:17 <@Ales> okay
11:18 <@Ales> yes, it does work correctly without the redraw because in all cases (now) a redraw happens afterwords
11:18 <@Ales> as you stated
11:18 < Igor2Code> -rdynamic increases the executable size by 1.7% :>
11:27 < cnieves> Ales: regarding doing zoom_extents whem maximizing/minimizing:
11:28 < cnieves> The signal which monitors this event is the  window_state_event, so I set a callback handler for it.
11:29 < cnieves> Just testing, I used a g_signal_connect and a g_signal_connect_after, both pointing to the same callback.
11:29 < cnieves> The callback is called, but it fails to make the zoom_extents, so I added a check for the main_window size.
11:30 < cnieves>   gtk_window_get_size(GTK_WINDOW(w_current->main_window),
11:30 < cnieves> 		      &(w_current->win_width),
11:30 < cnieves> 		      &(w_current->win_height));
11:31 < cnieves> I get the callback called twice for each maximize or minimize event, which is fine (before and after the default callback), but I get always the small size of the window.
11:31 < cnieves> It has no sense for me, unless the callback is not called really before or after doing the window resizing....
11:33 <@Ales> Carlos, there is a signal handler in x_event for handling window resize... it's called x_event_configure
11:33 <@Ales> that gets called everytime the window is resized
11:34 < cnieves> ok, so I should put the code there, instead adding a new handler... thanks for the pointer.
11:35 <@Ales> but, I am not so convinced that doing a zoom extents everytime a window is resized is the right thing to do.
11:35 <@Ales> there probably should be some logic to figure out if the window has been maximized
11:38 <@Ales> there must be a way to tell if the window has been maximized in gtk+
11:41 -!- jegc [~jegc@201.244.254.120] has joined #geda
11:46 <@Ales> yes:
11:46 <@Ales> You can track maximization via the "window_state_event" signal on GtkWidget
11:47 <@Ales> http://www.gtk.org/api/2.6/gtk/GtkWidget.html#GtkWidget-window-state-event
11:47 <@Ales> http://www.gtk.org/api/2.6/gdk/gdk-Event-Structures.html#GdkEventWindowState
11:47 <@Ales> http://www.gtk.org/api/2.6/gdk/gdk-Event-Structures.html#GdkWindowState
11:48 < cnieves> yes, that's what I was trying to do. However, I think that x_event_configure is interfering with the handler of the window_state signal
11:48 <@Ales> specifically: GDK_WINDOW_STATE_MAXIMIZED
11:48 <@Ales> hmmm really?
11:48 <@Ales> hmmm
11:49 < cnieves> I'll test. I just set a callback of the window_state signal which calls a_zoom_extents, and it didn't work.
11:49 < cnieves> I'm making some experiments in x_event_configure now.
11:49 <@Ales> either way, upload a patch of your work in progress (even if it doesn't work) and maybe somebody will have a brilliant idea. :)
11:49 <@Ales> I'm all out of ideas. :)
11:51 <@Ales> I wonder if the event mask is incorrect
11:53 < cnieves> the gdk event type that x_event_configure sees for a maximize event is the same as the resizing (the configure event type). There is no event mask for the window_state event...
11:54 <@Ales> so, you were monitoring the window state on the toplevel window right?
11:54 <@Ales> (not on the drawing area)
11:55 < cnieves> yes
11:59 <@Ales> maybe the return value from the configure event on the drawing_area is wrong?
11:59 <@Ales> currently it is false
12:04 < cnieves> I think the matter is that both signals are sent when maximizing. Both signal handlers are executed, first the window_state handler, and then the configure handler...
12:06 <@Ales> ugg
12:06 <@Ales> maybe the window_state handler should set a flag that can be handled in the configure handler
12:06 <@Ales> I just sent some e-mail to geda-dev about the new hook Carlos, 
12:07 <@Ales> question I had, can users override this hook in a ~/.gEDA/gschemrc or local gschemrc file?
12:08 < cnieves> I think so, but I can't remember how. I'll check later.
12:08 < cnieves> Maybe I can play with this (in x_event_configure):
12:08 < cnieves>   if (new_width == w_current->win_width &&
12:08 < cnieves>       new_height == w_current->win_height) {
12:08 < cnieves>     return(0);
12:08 < cnieves>   }
12:09 < cnieves> so if the window_state handler set w_current->win_width and win_height , then maybe the configure event is not done?
12:11 <@Ales> ah
12:12 <@Ales> add a printf in there and see if it gets in there
12:14 <@Ales> Stuart: here's a link to that site with gEDA and PCB mods:
12:14 <@Ales> http://www.minermade.com/pcb-geda/pcb-geda.html
12:14 < cnieves> Both handlers are being executed. Don't get distracted by this. I'll keep trying.
12:17 <@Ales> okay
12:17 < cnieves> If you finished with the new page hook, could you please take a look at the zooming while panning.
12:18 < cnieves> ?
12:18 < cnieves> It's a huge patch and I'd love to see it inside the CVS asap... (so I don't have to change it again)
12:18 <@Ales> here's another link for you Stuart for a new spice: 
12:18 <@Ales> http://www.thedigitalmachine.net/eispice.html
12:19 <@Ales> Carlos: is that the thing related to your new patch?
12:19 <@Ales> oh yes
12:19 <@Ales> okay
12:19 <@Ales> lemme checkin a memory leak fix
12:19 <@Ales> first :)
12:23 -!- wexi [~Debugger@cpe-24-90-166-82.nj.res.rr.com] has joined #geda
12:23 <@Ales> hi wexi
12:24 < wexi> Hi Ales, Have a successful coding day.
12:24 <@Ales> thanks!
12:25 <@Ales> yeah, things are going well... getting lots of things done
12:25 < wexi> The entire world is looking up to you :-)
12:25 <@Ales> I wouldn't go that far... :)
12:25 < Igor2Code> I got only one thing done, with the kind help ov Carlos :)
12:25 < Igor2Code> s/ov/of/
12:26 < cnieves> Hi wexi!
12:27 -!- mike [~mike@i216-58-18-43.cybersurf.com] has joined #geda
12:27 < wexi> Hi Carlos, Good luck to you too!
12:27 <@Ales> Hi Mike
12:27 < Igor2Code> hi Mike :)
12:27 < cnieves> Thank you!, all is going pretty well!
12:27 < cnieves> Hi Mike!
12:27 < mike> Hi!
12:28 < sdb> Hi Mike!
12:28 < Igor2Code> wow, i haven't seen so many people on this channel ever :)
12:28 < sdb> This is nothing ... we had about 11 max at the last code sprint!
12:28 <@Ales> I'm going to go out to grab a quick bite to eat... be back in a little bit
12:28 < sdb> However, we spent too much time talking to get things done. . . . 
12:28 < mike> I have to apologize, but I am busy packing things.  I have a new job and I have to move by the end of the year.
12:28 < sdb> Where
12:29 < sdb> Where;s the new job?
12:29 -!- Levente [~Levente@wifi-58d1faca.obudanet.hu] has joined #geda
12:29 < Igor2Code> hi Levente :)
12:29 < Levente> Hi!
12:29 < sdb> Hi Levente!
12:29 < mike> I am moving from Ottawa to Waterloo Ontario, and I am working for Research In Motion..
12:29 < Levente> Hihi
12:29 < mike> Hi Levente.
12:29 < Igor2Code> hah, obudanet, the DC hub provider :>
12:29 < Levente> hi all!
12:30 < Levente> Igor2Code: You know them?
12:30 < Igor2Code> >Levente> i have a friend who worked there for a while
12:30 < Igor2Code> he had a number of nice stories... :>
12:30 < Levente> I have too... they stop providing every know and then...
12:31 < Igor2Code> stop providing internet or stop providing dc? :)
12:31 < Levente> internet...
12:31 < Igor2Code> uhh
12:31 < Igor2Code> i guess their mian profile is going to be the dc servers then :>>>
12:32 < Levente> I didn't know... but I am using just their IP service....
12:32 < Igor2Code> they sell IPs?
12:32 < Levente> How is the codesprint going on?
12:33 < Levente> Igor2Code: providing IP...
12:33 < Igor2Code> the guys are coding hard... :)
12:33 < sdb> The codesprint is going well. . . . .   Lots of hands mean lots of work gets done!
12:34 < sdb> Carlos has introduced a very nice feature -- open a schematic and automatically get
12:34 < Levente> This is very good! I wish I was there...
12:34 < sdb> a titleblock.  I fixed a little bug in gatttrib, and am playing with the 
12:34 < sdb> new project manager from Cambridge Univ.
12:34 < sdb> It is alpha quality, but will be very nice indeed when finished.
12:35 < Levente> sdb: Ahh... that is great. I've seen the feature mentioned on the list.
12:35 < sdb> We also did an install on a fresh FC5 machine using yum.  If you don't know
12:35 < Igor2Code> i've evem tried it out :)
12:35 < sdb> it, geda is now in Fedora Extras; to get it you just have to do 
12:35 < sdb> yum install geda-*
12:35 < sdb> yum install libgeda-*
12:36 < sdb> And you get it.  Very nice.  The install is pretty smooth.
12:36 < Levente> I failed installing it on FC5. But I had bad luck with source... Monday, I'll try it with yum..
12:36 < Levente> Nice work!
12:36 < sdb> Later I intend to edit the "download" webpage to reflect this new install method.
12:36 < sdb> Yeah, try with yum.  You can also do rpm --install , but then you need to 
12:37 < sdb> pick up the two dependencies:  libstroke and libguile-devel
12:37 < sdb> before installing libgeda-* and geda-*.
12:37 < Levente> okay.
12:37 < Levente> sure.
12:37 < sdb> Also, PCB installs nicely using yum:
12:37 < sdb> yum install pcb-*
12:38 < Levente> I am raly crasy about Harry's dead polygon removal code in PCB.
12:39 < Levente> Ohh... my spelling...
12:39 < Igor2Code> I hope DJ will show up today
12:40 < Levente> sdb: thanks for the news! You all do great work!
12:40 < sdb> Yeah, I thought DJ was coming, but he's not here . . . .  :-(
12:40 < sdb> Perhaps he got busy at home.
12:46 -!- mike [~mike@i216-58-18-43.cybersurf.com] has quit [Quit: using sirc version 2.211+KSIRC/1.3.12]
12:47 -!- mike [~mike@i216-58-18-43.cybersurf.com] has joined #geda
12:48 -!- mike [~mike@i216-58-18-43.cybersurf.com] has quit [Client Quit]
12:51 <@Ales> here's a link to a tutorial on treeview's Stuart:
12:51 <@Ales> http://scentric.net/tutorial/sec-sel-click-menus.html
13:02 <@Ales> okay, back to work.
13:44 < cnieves> Ales, could you make a test:
13:45 <@Ales> sure
13:45 < cnieves> in x_event.c, x_event_configure, replace the a_pan_general call at the end of the function by:
13:45 < cnieves> a_zoom_extents(w_current, w_current->page_current->object_head, 0);
13:45 < cnieves> it should be doing zoom extents whenever you resize the window.
13:45 < cnieves> but it doesn't work for me.
13:49 < cnieves> we were all wondering where DJ is... he just answered a mail to the list, so he seems to be connected somewhere!
13:49 < Igor2Code> :>
13:49 < Igor2Code> he is hiding! :)
13:50 <@Ales> yeah it doesn't zoom extents for me either
13:52 <@Ales> hmmm that's curious
13:53 <@Ales> wait... I wasn't built correctly... lemme try again
14:01 < sdb> I sent DJ a mail asking him to visit us here on IRC.  I am not certain he will
14:01 < sdb> show up . . . .
14:03 <@Ales> that's for the override capability Carlos
14:03 <@Ales> ^that's^thanks
14:03 < cnieves> Cesar, did you test the CVS version on mingw? Tell me when you do it, so I can close the patch report
14:03 < Cesar> Carlos: I just now finished checking the strcasecmp status on MinGW.
14:03 < Cesar> Carlos: I just now finished checking the strcasecmp status on MinGW.
14:04 < Cesar> It took me a bit longer, has been a while since I built the MinGW port.
14:04 <@Ales> Carlos: yeah, that zoom extents isn't zooming extents (even though I know it is executing)
14:04 < Cesar> Although strcasecmp doesn't exists in Windows, the MinGW team already provided an implementation in a compatibility library.
14:05 < Cesar> Although strcasecmp doesn't exists in Windows, the MinGW team already provided an implementation in a compatibility library.
14:05 < Cesar> So, strcasecmp and strncasecmp can be used in both Cygwin and MinGW. There are no special cases.
14:05 < Cesar> It will possibly not work on compilers besides gcc, but I am not too worried about that.
14:06 <@Ales> for the mingw port, I don't care about any other compiler but gcc
14:06 < cnieves> Cesar: the code uses strcasecmp, but if it's not available, there is a macro defining strcasecmp as stricmp. The latter seems to exist on Windows, so it may work.
14:07 < cnieves> So, I guess I can close the patch report. Right?
14:08 < cnieves> Ales: something strange is happenning, that zoom_extents should work. I think there is no other function triggered by the resize event.... 
14:08 < Cesar> Carlos: You can also remove the #defines, if you wand. I tested without that and it works on MinGW too.
14:08 <@Ales> I'm looking at this oddness right now
14:10 < cnieves> Cesar: I think I'll leave the defines there until someone tell us about some problem because of them.... :-) they don't hurt by now. I'll close the patch report.
14:10 <@Ales> Carlos: If I add the zoom_extents to the end of the configure event, it works correctly
14:12 < Cesar> Carlos: Sure, thanks.
14:12 <@Ales> ha. 
14:12 <@Ales> ah, it is the combination of the two calls that makes it work
14:12 <@Ales> I don't understand that at all
14:13 < cnieves> what two calls? Do you mean doing:     o_redraw_all_fast(w_current);
14:13 < cnieves>     x_scrollbars_update(w_current);
14:13 < cnieves> and afterwards zoom_extents?
14:13 <@Ales> no, just add:
14:13 <@Ales>   a_zoom_extents(w_current,
14:13 <@Ales>                  w_current->page_current->object_head, 0);
14:13 <@Ales> right before the o_redraw_all
14:14 <@Ales> not that this is right solution... :)
14:14 < cnieves> but then the backingstore won't be correct...
14:15 <@Ales> backingstore just gets created there
14:15 <@Ales> it gets drawn to in o_redraw_all
14:15 <@Ales> I don't understand why two calls are necessary
14:16 < sdb> John Luciani arrived here at MIT.  He wants to talk to DJ, but DJ is MIA!
14:17 < cnieves> Ales, could be that zoom_extents didn't work because the backingstore is being freed afterwards?
14:18 <@Ales> ah.. maybe that's the issue... the old contents are being pushed to the display 
14:18 <@Ales> and then backing store is destroyed, and then you zoom extents again and the right display values get setup
14:18 -!- wexi [~Debugger@cpe-24-90-166-82.nj.res.rr.com] has quit [Quit: Client exiting]
14:19 < cnieves> then why was there a a_pan_general call? was it a bug?
14:19 <@Ales> that might be there to normalize the values that were calculated above
14:19 <@Ales> it's been a while since I've played with the zoom/pan code
14:21 -!- dj [~dj@envy.delorie.com] has joined #geda
14:22 <@Ales> hi DJ
14:22 < sdb> Hi DJ!   We're all missing you!
14:22 < dj> May not get to stay long, I'm inbetween things waiting for a phone call.
14:22 <@Ales> John is here now... with a LARGE list of usability issues... 
14:22 < Igor2Code> hi dj :)
14:22 < dj> Hi, folks!
14:22 < cnieves> Hi dj!
14:22 < Igor2Code> and i'm here for -rdynamic :>
14:23 < dj> Well, I have no specific things to work on.
14:24 -!- jegc [~jegc@201.244.254.120] has quit [Quit: Leemos luego]
14:26 < dj> FYI the challenge boards should be on their way here soon: http://www.delorie.com/pcb/smd-challenge/chal01.html
14:28 < Igor2Code> looks great
14:28 < dj> Thanks!  I wish they'd scan the other side also (pcbpool) but it's neat to see it at each step in the manufacturing process.
14:29 -!- jcl [~jcl@WHITAKER-ONE-SEVENTY-FOUR.MIT.EDU] has joined #geda
14:29 < Igor2Code> my father is interested as well so I should order at least two :)
14:30 < dj> I've already gone through enough parts for three, and I don't even have the boards yet!
14:31 < Igor2Code> :)
14:31 < dj> You have to be really careful with the small ones; they have no real mass, so any oops and they go flying across the room.
14:31 < Igor2Code> will you provide extgra amount of those?
14:31 < Igor2Code> btw, how one can pay if he doesn't have a credit card? :)
14:32 <@Ales> send gold
14:32 < Igor2Code> hehe :)
14:32 <@Ales> :)
14:33 < dj> No, the smallest ones are the most expensive (0.15 each).  There are two in there already, but you need both to make a working circuit.
14:33 < Igor2Code> uhh :)
14:33 < jcl> I am in Cambridge with a two page list to pester DJ with but DJ is MIA!
14:33 < dj> As for payment, I was thinking check or paypal.  I'm still targetting $2 each, but I need to think about packaging.
14:34 < dj> Hey, I replied to the announcement saying I'd be busy today.  Email me the list ;-)
14:35 < jcl> I only have a printed copy right now but I will email it to you when I get home.
14:35 <@Ales> I don't remember seeing that e-mail... was it a while ago?
14:35 < dj> Ok.
14:35 < dj> Er, when the first notice came out.
14:35 < Igor2Code> I remember that mail
14:35 <@Ales> oh.. I can't remember that far back
15:05 < cnieves> Ales, I think I got it. Update to CVS and check it (bug #1527465:  Do a zoom extents for all pages when the
15:05 < cnieves> main window is maximized)
15:05 <@Ales> looking at it
15:09 <@Ales> building it now
15:09 < cnieves> Can I close bug #1508402: segfault when writing png? it seems to be a g_slice bug.
15:10 < cnieves> Forget it, it's already closed.
15:11 <@Ales> yup. Stuart and I have been closing updating bugs. :)
15:11 <@Ales> oops:x_window.c: In function 'x_window_setup_draw_events':
15:11 <@Ales> x_window.c:362: error: 'x_event_window_state' undeclared (first use in this function)
15:11 <@Ales> x_window.c:362: error: (Each undeclared identifier is reported only once
15:11 <@Ales> x_window.c:362: error: for each function it appears in.)
15:11 < cnieves> I noticed it! :-)
15:13 < cnieves> I committed the changes manually and I forgot the prototype.h. Update your CVS copy  and try again.
15:14 <@Ales> updating and building
15:15 < cnieves> do you have libgd installed?
15:16 < cnieves> I'm going to eat something. See you in some minutes...
15:19 <@Ales> I just install libgd
15:19 <@Ales> the maximize patch looks good
15:37 < cnieves> back again
15:38 < cnieves> Regarding the gdk-pixbuf and libgd differences, there are mainly two:
15:39 < cnieves> gdk-pixbuf output has less border than libgd output. See x_image.c: lines 649 to 684.
15:40 < cnieves> the other is that you noticed some diferences in net thicknesss, I think, but I don't see that... do you have an example.
15:40 < cnieves> ?
15:40 < cnieves> then if everything is ok with the maximize patch, I can close the bug...
15:49 <@Ales> sure, close the bug. :)  Thanks for the patch
15:50 <@Ales> Carlos: I don't have an example at the moment
15:52 < cnieves> what do you think about the border. Maybe it's better if the gdk-pixbuf output shows the same border as the libgd output, so users don't notice the difference.
15:53 < cnieves> If you have libgd installed and a version of gaf compiled with it, and you could make some images, I could compare them with the gdk-pixbuf version I have here...
15:54 <@Ales> Carlos: oh yes, the border, there was a Bug filed against that
15:54 <@Ales> I'll make some images with a comparison and post them
15:55 < cnieves> to fix the border is very easy: just #if 0 the lines in x_image.c I told you. I'm going to do it if you don't object.
15:59 < Cesar> Goodbye. See you next time.
15:59 < cnieves> bye Cesar. Thank you!
15:59 <@Ales> I don't object. :)
16:00 <@Ales> See ya Cesar.  Thanks for the cygwin patchs!
16:00 -!- Cesar [~Cesar@c9344c0b.virtua.com.br] has quit [Quit: Advanced IRC 2.0.4 - don't ask, don't tell]
16:00 <@Ales> I'm going to show John some videos... back in a little bit
16:03 < Igor2Code> >DJ> thanx again for -rdynamic :)
16:03 < Igor2Code> i'm going to sleep now, have fun coding
16:03 -!- Igor2Code [~igor2@catv-506284ed.catv.broadband.hu] has quit [Quit: good night]
16:03 < dj> Bye!  Too late.
16:05 < cnieves> bye! see you!
16:07 < cnieves> sdb: did you noticed bug [ 1472541 ] spice-sdb mutates x->dx ?
16:08 < dj> Hey, anyone here do any heat-vacuum-forming?  Thinking about that for protecting the components when I ship out the challenge board.
16:28 < sdb> Hi Carlos,
16:28 <@Ales> I'm back
16:28 < sdb> I have noticed the bug report.    I haven't done anything about it yet.
16:29 < cnieves> sdb: ok. Just wondering... I was choosing the next victim... :-)
16:30 < cnieves> (victim = bug to fix)
16:31 < cnieves> Ales: I'd like to change the button order and use GTK functions to change it if needed (as described in the comments of bug 1553483). What do you think=
16:34 <@Ales> sure, go ahead and do that, but make sure all the dialog boxes get changed and that whatever change you make works correctly for gtk+ 2.4.x
16:34 <@Ales> or later
16:42 < sdb> I gotta go!  My boss is waiting for me.
16:42 < sdb> Bye guys -- it was a great hacking session!
16:42 < dj> bye!
16:43 < cnieves> bye stuart!
16:43 -!- sdb [~sdb@WHITAKER-THREE-SEVENTY-EIGHT.MIT.EDU] has quit [Quit: Leaving]
16:43 < jcl> bye, bye.
16:43 < dj> bye!
16:43 -!- jcl [~jcl@WHITAKER-ONE-SEVENTY-FOUR.MIT.EDU] has quit [Quit: Leaving]
16:44 <@Ales> okay I'm out of here too
16:44 < dj> bye!
16:44 <@Ales> It has been a very good code sprint...
16:44 <@Ales> see ya all at the next one
16:44 <@Ales> or just stop by here anytime.
16:44 < dj> [even if I wasn't here]
16:44 <@Ales> thanks all!
16:45 < cnieves> bye! thanks!
16:52 < dj> Bye, all.
16:52 -!- dj [~dj@envy.delorie.com] has quit [Quit: Leaving]
16:56 < cnieves> bye all!
16:56 -!- cnieves [~cnieves@28.pool85-57-133.dynamic.uni2.es] has quit [Quit: Abandonando]
18:17 -!- Levente [~Levente@wifi-58d1faca.obudanet.hu] has quit [Quit: Leaving]