[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
gEDA-cvs: CVS update: irclog_sprint_20061021.txt
User: ahvezda
Date: 07/03/07 17:33:42
Added: . irclog_sprint_20061021.txt
irclog_sprint_20070210.txt
Log:
Misc updates
Revision Changes Path
1.1 eda/geda/website/sprints/irclog_sprint_20061021.txt
Index: irclog_sprint_20061021.txt
===================================================================
09:06 -!- cnieves [~cnieves@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx] has joined #geda
09:06 < cnieves> Hi
09:10 <@Ales> good morning Carlos
09:10 <@Ales> well.. morning for me at least. :)
09:11 < cnieves> Good morning!
09:11 < cnieves> I expect you a bit later...
09:12 <@Ales> yeah, I got a up a little earlier. :)
09:12 < cnieves> did you have your breakfast? :-)
09:12 <@Ales> not yet.. going to go get some cereal right now.
09:13 < cnieves> then, take your time! we can start when you are ready :-)
09:13 <@Ales> I'm ready now.
09:14 <@Ales> long story short, I did make a release last night
09:14 < cnieves> yeah, I saw the mail and the cvs logs... quite a bit of work, wasn't it?
09:15 <@Ales> no, not really, just the usual, version numbers, a few last minute patches, and doc updates
09:15 <@Ales> I did apply Patrick's dialog button reorder patch.
09:15 <@Ales> it was about 3 hours of work
09:16 < cnieves> yes, I liked that. I'm going to add the gtk dialog button reordering (later)
09:16 <@Ales> that's fine
09:16 < cnieves> well, regarding the patch we are dealing with today, I have the following plan:
09:17 < cnieves> Look at: http://sourceforge.net/tracker/index.php?func=detail&aid=1551233&group_id=161080&atid=818428 , first apply the least intrusive patches
09:18 < cnieves> which are:
09:18 < cnieves> - improve_o_text_error_detection
09:18 < cnieves> - dont_redraw
09:18 < cnieves> - don't duplicate code in o_redraw
09:18 < cnieves> - selection_glist
09:18 < cnieves> - copy_using_complex_place_list
09:19 <@Ales> I'm giving the patches a once over look again
09:19 < cnieves> I have here an updated CVS version for each patch, except the last one, which depends on the others.
09:19 < cnieves> Yes, look at them (in this order). The first ones are quite simple.
09:22 <@Ales> first two look okay
09:22 < cnieves> ok, should I commit them?
09:22 <@Ales> yeah
09:24 < cnieves> I doubt about the fprintf(stder,"..."); lines. Should they go into the log as well?
09:25 <@Ales> It's a toss up. those are kind of critical and I usually look at errors in the console window
09:25 <@Ales> at some point we should go through the entire code base and change all printfs to log
09:25 <@Ales> third patch looks okay, although, I will look at it again when it's commited using tkdiff
09:26 < cnieves> ok, I'll add it as is.
09:27 < cnieves> First one commited.
09:28 <@Ales> I'm rebuilding right now, should be ready to test it in about 7 mins
09:28 < Igor2_off> hi
09:28 <@Ales> hi
09:28 < Igor2_off> >ales> i have a problem with gaf
09:28 < Igor2_off> autoconf-problem
09:29 < Igor2_off> it puts [config.h].in in the Makefile instead of config.h
09:29 < Igor2_off> or config.h.in or anything
09:29 < Igor2_off> if i symlink or copy my config.h.in to [config.h].in prior to starting the autoconf stuff, it works, but it doesn't seem intended :>
09:29 <@Ales> huh
09:30 <@Ales> what version of autoconf/automake?
09:30 < Igor2_off> (booting the comp to find out)
09:32 <@Ales> I don't recall ever hearing of such a problem
09:32 < cnieves> Second one too.
09:32 <@Ales> updating now
09:33 <@Ales> for some odd reason my cvs updates have been taking longer and longer
09:33 <@Ales> lemme test this change a little and then you can apply the next one
09:33 < cnieves> maybe because it is checking the wiki pages as well?
09:33 <@Ales> maybe
09:34 <@Ales> yeah, there are a lot of files in there
09:34 <@Ales> I should try to restrict my update to just code
09:34 < cnieves> ok. I'll prepare the 3rd while you test this one (or these two?).
09:34 <@Ales> k
09:34 < cnieves> You can do a cvs update gschem libgeda, since today we are going to change only those directories.
09:34 <@Ales> yup
09:34 < Igor2_off> $ autoconf --version
09:34 < Igor2_off> autoconf (GNU Autoconf) 2.60a
09:34 < Igor2_off> Written by David J. MacKenzie and Akim Demaille.
09:35 < Igor2_off> i'm logged in now so i can try reproducing the problem
09:35 <@Ales> some version now
09:35 <@Ales> same version as you
09:35 < Igor2_off> or i can even give you shell account to test
09:35 < cnieves> Igor, I have the same version too.
09:35 <@Ales> what about automake?
09:36 < Igor2_off> $ automake --version
09:36 < Igor2_off> automake (GNU automake) 1.4-p6
09:37 < Igor2_off> now i try to reproduce the error to be able to copy the results here
09:37 < cnieves> I wonder if automake is too old. I have 1.9.6 version here, and I remember there were some problems with old versions....
09:38 < Igor2_off> we will see :)
09:38 < Igor2_off> now, i have run distclean in gaf/gattrib
09:38 < Igor2_off> $ ./autogen.sh
09:38 < Igor2_off> find: warning: Unix filenames usually don't contain slashes (though pathnames do). That means that '-name ./CVS' will probably evaluate to false all the time on this system. You might find the '-wholename' test more useful, or perhaps '-samefile'. Alternatively, if you are using GNU grep, you could use 'find ... -print0 | grep -FzZ ./CVS'.
09:38 < Igor2_off> processing .
09:38 < Igor2_off> autogen.sh running: aclocal ...
09:38 < Igor2_off> autogen.sh running: autoheader ...
09:38 < Igor2_off> autogen.sh running: automake ...
09:38 < Igor2_off> configure.ac: 14: required file `./[config.h].in' not found
09:38 < Igor2_off> autogen.sh running: autoconf ...
09:39 <@Ales> ah, I have a much never version of automake as well.
09:39 <@Ales> I have 1.7.9
09:39 <@Ales> could you upgrade your automake?
09:40 < Igor2_off> checking
09:40 <@Ales> is this your first time building gEDA/gaf?
09:40 <@Ales> what linux distribution?
09:40 <@Ales> first two patches seem to be okay carlos
09:40 < Igor2_off> debian testing (etch)
09:40 < Igor2_off> yes, my first time
09:40 < Igor2_off> doing this because i need to put new versions to my geda live cd
09:41 < Igor2_off> because xgsch2pcb for my students :>
09:41 <@Ales> yeah, definately upgrade your automake then, I'm using etch as well
09:41 < Igor2_off> # automake --version
09:41 < Igor2_off> automake (GNU automake) 1.8.5
09:41 < Igor2_off> yeah, it seems they have different packages
09:41 < Igor2_off> automake1.4 i had
09:42 < Igor2_off> now installed this automake1.8 and there's automake1.9 available
09:42 < Igor2_off> $ ./autogen.sh
09:42 < Igor2_off> find: warning: Unix filenames usually don't contain slashes (though pathnames do). That means that '-name ./CVS' will probably evaluate to false all the time on this system. You might find the '-wholename' test more useful, or perhaps '-samefile'. Alternatively, if you are using GNU grep, you could use 'find ... -print0 | grep -FzZ ./CVS'.
09:42 < Igor2_off> processing .
09:42 < Igor2_off> autogen.sh running: aclocal ...
09:42 < Igor2_off> run info '(automake)Extending aclocal'
09:42 < Igor2_off> or see http://sources.redhat.com/automake/automake.html#Extending%20aclocal
09:42 < Igor2_off> autogen.sh running: autoheader ...
09:42 < Igor2_off> autogen.sh running: automake ...
09:42 < Igor2_off> oops, one line missing from the dump
09:42 < Igor2_off> /usr/share/aclocal/glib.m4:8: warning: underquoted definition of AM_PATH_GLIB
09:43 < Igor2_off> so still not perfect, but the [] bug is gone
09:43 < Igor2_off> i believe autogen.sh should check for automake version and warn the user or something :)
09:44 < Igor2_off> (and i don't see any reference in the docs about which version is required, so it's not too trivial:)
09:44 <@Ales> I see similar warnings sometimes too, probably due to the new version of automake, but it should work
09:45 < cnieves> I'm getting a lot of "underquoted definition" warning too. Automake became stricter, and there are some macros out there which haven't been updated.
09:45 < Igor2_off> ok
09:45 < Igor2_off> then i check the find error
09:45 < Igor2_off> what about the version check, is it possible? :)
09:45 < Igor2_off> i think it would help newcomers like it would have helped me :)
09:47 < Igor2_off> ok, about find:
09:48 < Igor2_off> this is the original version, in the for:
09:48 < Igor2_off> find $srcdir -name $srcdir/CVS -prune -o -name $configure_script -print
09:48 < Igor2_off> if you use -wholename instead of -name, it works
09:48 < Igor2_off> (without warning)
09:48 <@Ales> but the problem is that -wholename might not be present in all version of find
09:48 < Igor2_off> i'm not sure if it's a portable solution, if you want, i can check it on a few hosts
09:48 < Igor2_off> ohh
09:48 <@Ales> I think it's a gnu extension.
09:49 < Igor2_off> well, what scares me is not the fact it gives a warning
09:49 <@Ales> carlos: I looked over the commited changes again. look reasonable.
09:49 < Igor2_off> but that it says it will fail anyway :)
09:50 <@Ales> this is kind of a fun... a mini code sprint. :)
09:51 < cnieves> Ales: yes, :-) . ok, should I commit the 3rd (o_redraw) one?
09:51 < Igor2_off> >ales> i'm for this kind of code sprints any time if it doesn't annoy you ;)
09:52 < Igor2_off> (trying to find a solution that actually works without a warning and is portable)
09:52 <@Ales> what is the purpose of the flag on o_redraw?
09:52 < cnieves> let the caller choose wether draw the selected objects or not.
09:52 <@Ales> yeah, I wouldn't mind getting rid of the warning as long as the solution is portable :)
09:52 <@Ales> okay
09:53 < Igor2_off> so far i couldn't think anything better than testing what version of find we have, hehe
09:53 < Igor2_off> hmmz
09:53 < Igor2_off> why do we need $src/CVS, why not just CVS?
09:53 <@Ales> carlos: commit away on o_redraw patch
09:54 <@Ales> Igor: just to filter the find down a little bit
09:54 <@Ales> keep in mind I didn't really write the autogen.sh scripts, I snagged them from glade a while ago and make some changes here and there
09:55 < Igor2_off> ok
09:56 < Igor2_off> `find $srcdir -name $configure_script -print | grep -v "^$srcdir/CVS"`
09:56 < cnieves> Ales: o_redraw_patch commited.
09:56 < Igor2_off> what about this one?
09:56 < Igor2_off> it runs 2 processes
09:56 < Igor2_off> but filters out CVS :)
09:59 < Igor2_off> (less elegant than the original, for sure)
10:01 <@Ales> carlos: okay, this patch builds and seems to be okay
10:02 <@Ales> is selection_glist next?
10:02 < cnieves> Ales, the next one is to convert the selection list into a glist...
10:02 <@Ales> the big one..
10:02 < cnieves> maybe it's better if I send you the patch first, instead of commiting it directly.
10:02 < cnieves> not really. The last is the big one. :-)
10:02 -!- patb [~patb@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx] has joined #geda
10:03 < patb> hello all
10:03 <@Ales> Hi Patrick
10:03 < cnieves> Hi Patrick
10:03 < Igor2_off> >ales> so is that grep-approach ok? :)
10:03 <@Ales> boy, everybody is coming. :)
10:03 < Igor2_off> hi :)
10:03 < Igor2_off> :>
10:03 <@Ales> Igor: send me an e-mail with the modifications and I'll take a look
10:03 < Igor2_off> >Ales> everyone comes here to overload you! :)
10:03 <@Ales> or better yet, post it to geda-dev
10:03 < cnieves> patb: we have some kind of mini code-sprint here.
10:03 <@Ales> no no, the more the merrier!
10:03 < Igor2_off> ok :>
10:03 < patb> cnieves: on your patch?
10:04 < Igor2_off> yeah, patb, you just came the right moment :)
10:04 <@Ales> Patrick: Thanks for fixing those gtk+ issues.
10:04 < cnieves> patb: yes, we have just committed some few changes.
10:04 < patb> cnieves: for zooming/panning
10:04 < patb> ok
10:04 <@Ales> we are getting ready to do the big one
10:04 < patb> yes I noticed them coming
10:04 <@Ales> carlos: yeah send me the patch
10:04 < patb> cnieves: I was just reviewing your patches
10:05 <@Ales> Patrick: any comments on the patches?
10:05 < patb> cnieves: but I failed to convert the time of the meeting
10:05 < patb> I expected it one hour later :)
10:05 < Igor2_off> bah, i hate cvs :)
10:05 <@Ales> I got here a little early, so we started earlier
10:05 <@Ales> my fault
10:06 <@Ales> I have to disappear around 11ish or so my time.
10:06 < patb> so I got the time conversion right?
10:06 <@Ales> Yes you did.
10:06 <@Ales> perfectly
10:06 <@Ales> anybody object if I post the log of this mini-sprint after we are done?
10:06 < patb> Good, I really hate these time conversion, never sure I am right
10:07 < patb> I can not stay too much too
10:07 <@Ales> sorry about startting too early.
10:07 < Igor2_off> no objection on my side :)
10:07 < patb> in fact I would have suggested the patch to be applied to a branch instead of the main trunk
10:08 <@Ales> well so far the patches have been fairly straightforward
10:08 <@Ales> however, the next ones are the biggies
10:08 <@Ales> so we could still branch
10:08 < cnieves> Ales: no objection to the log.
10:08 <@Ales> k
10:09 <@Ales> I wouldn't be opposed to a branch for this
10:09 <@Ales> thoughts carlos?
10:09 < Igor2_off> >Ales> btw, xgsch2pcb doesn't have ./configure nor a script that i could run to generate it so it's not trivial what to do there (the doc sais i should just run ./configure)
10:10 <@Ales> Igor: take that up with PeterC or PeterB :)
10:10 < cnieves> agree. It's a better way.
10:10 <@Ales> okay, I'm going to create the branch
10:10 <@Ales> what should I call it?
10:11 < Igor2_off> (and cvs hangs)
10:11 < cnieves> Ales: we have two patches left: one to convert the selection into a glist, and the other is to make copy use the complex place list....
10:12 <@Ales> how about glist_dev?
10:12 < cnieves> ok
10:15 <@Ales> creating branch now
10:15 < cnieves> Ales: I'm having problems using a cvs diff. It doesn't do anything. does the CVS live in moria? a ping doesn't show any answer...
10:16 <@Ales> yup it's on moria
10:16 <@Ales> it might be a little slow right now
10:17 <@Ales> try it now
10:17 < Igor2_off> yeah, i can't access the cvs server either
10:17 < Igor2_off> or hmmz
10:17 -!- patb2 [~patb@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx] has joined #geda
10:17 < Igor2_off> actually i can access it trough the university network
10:17 < Igor2_off> but not from home
10:18 <@Ales> branch created
10:18 <@Ales> please update your working directory by running: cvs update -r glist_dev
10:18 -!- patb [~patb@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx] has quit [Ping timeout: 622 seconds]
10:18 <@Ales> that'll switch you to the new branch
10:19 < cnieves> no answer... :(
10:19 < patb2> well I am having problems with my connection
10:19 < patb2> good I was saying I am going to post my notes on the SF tracker
10:19 <@Ales> ack
10:19 <@Ales> maybe something has gone bad on the net
10:20 <@Ales> can you ping moria.mit.edu?
10:20 < cnieves> yes, it works.
10:20 < patb2> Ales, works for me too
10:21 -!- patb2 is now known as patb
10:21 <@Ales> how about a cvs diff?
10:22 < cnieves> it works too. Wait a moment and I'll post the diff.
10:22 < Igor2_off> ok, can access the cvs server now
10:22 <@Ales> okay, remember to switch to the glist_dev branch so that your changes go there
10:24 < cnieves> I was going to send you (Ales and patb) the patch...
10:24 < cnieves> before committing
10:24 <@Ales> k
10:26 <@Ales> or better yet, create a new checkout using cvs checkout -r glist_dev
10:26 <@Ales> and name the directory properly
10:28 < Igor2_off> sent the mail to geda-dev :)
10:32 < cnieves> I'm checking out the new branch. If the diff is the same, I can send it now.
10:33 <@Ales> okay
10:34 <@Ales> yeah, I'm checking out the branch as well
10:37 < cnieves> Ales: I'm trying to send you the patch using DCC... can you accept the connection?
10:38 <@Ales> got it
10:38 < cnieves> patb: you have the patch waiting for you...
10:39 < patb> got it too
10:40 <@Ales> I would say apply it to the glist_dev branch, unless somebody objects
10:41 < cnieves> the checkout is still running... so it could take a while.
10:49 < cnieves> I'm compiling. Patrick, I saw your comments on the SF page. I'll take a look at them as soon as the compiling finishes...
10:50 < patb> ok great
10:54 <@Ales> okay, I have to run. I look forward to playing with the changes
10:55 <@Ales> take care everybody
10:56 < patb> have a nice day ales. I will also leave soon, I have walnut to gather and chestnut to prepare
10:56 <@Ales> enjoy
10:56 <@Ales> see ya Carlos and Igor. this was fun
10:56 < cnieves> patb: your comment: why not keeping the SELECTION type as an alias to GList?
10:56 < cnieves> it would
10:56 < cnieves> help differentiate selections from other kind of lists.
10:57 < patb> cnieves: yes?
10:57 < patb> we are already using GList for conns and we are likely to use it elsewhere
10:57 < cnieves> I don't object. What I think is that the code would be better if we avoid to embed the lists pointers into the objects.
10:57 < cnieves> Bye Ales, thank you.
10:58 < cnieves> I hope for objects too, sometime in the future. That will solve the current OBJECT* list and GList * duality.
10:59 < patb> I do not want that. What I meant was: typedef GList SELECTION;
10:59 < patb> BTW your patch is only against gschem, not libgeda
10:59 < patb> it complains it has not the right version of o_complex_add
11:01 < cnieves> I'll do a diff for libgeda.
11:02 < patb> well as long as you commit to the branch I have no problem with applying your patch
11:03 < patb> I consider it as some kind of sandbox
11:04 < cnieves> what do you mean?
11:06 < patb> you can try/broke things in a branch it does not mess with the main trunk
11:07 < patb> so you have all the time you need to fix at later time
11:07 < cnieves> yes, that's the benefits of branches...
11:07 < patb> indeed
11:07 < cnieves> If I understood correctly, you don't want to use glists for objects lists. why?
11:09 < patb> Maybe not for objects lists (the prev and next in OBJECT) but they are great for selections
11:10 < patb> As you said the problem is that we have to keep a reference on the GList in OBJECT if we want to traverse an object list from an OBJECT
11:10 < patb> There is no such problem with selections
11:12 < cnieves> The reason why I didn't use a typedef for the GList was that if, in the future, we use a GList for other things than selections, we won't need to change the name again.
11:13 < patb> yes but not in libgeda/o_selection.c and gschem/o_select.c
11:14 < patb> And it is purely cosmetic
11:14 < cnieves> well, it's a matter of taste. If I'm going to use glib's glist functions with selections, I should know they are selections. The typedef hides it.
11:15 < patb> then just ignore this point of my comments
11:15 < cnieves> I mispelled "I should know they are selections": I meant "I should know they are glists"
11:16 < cnieves> Regarding the names of get_object_complex_bounds, and get_object_glist_complex_bounds..
11:17 < cnieves> what name do you suggest?
11:18 < cnieves> Maybe get_bounds_of_object and get_bounds_of_object_glist ?
11:18 < patb> at least scrap the complex from their names: they do not work specifically on complex
11:18 < cnieves> IIRC, the complex was there before, so I just kept it there.
11:19 < patb> what about get_list_bounds() and get_glist_bounds()
11:19 < patb> I know it was there
11:20 < cnieves> As they are a lists of OBJECTs, I'd prefer get_object_list_bounds and get_object_glist_bounds...
11:21 < patb> sounds good to me
11:24 < cnieves> ok.
11:24 < cnieves> get_object_glist_complex_bounds() and get_complex_bounds_selection() are the same. I'll change that.
11:24 < patb> Ok I really have to go now. If you have other questions on my comments, mail them to me.
11:25 < patb> BTW it compiles fine but some of the crash I reported are still valid.
11:25 < cnieves> ok. I'll review your comments and mail you.
11:25 < patb> have fun
11:25 < cnieves> Thank you for your work.
11:25 -!- patb [~patb@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx] has quit [Quit: Leaving]
11:27 -!- cnieves [~cnieves@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx] has quit [Quit: Abandonando]
1.1 eda/geda/website/sprints/irclog_sprint_20070210.txt
Index: irclog_sprint_20070210.txt
===================================================================
--- Day changed Sat Feb 10 2007
01:25 -!- Bert [~e234574@xxxxxxxxxxxxxxxxxxxxxxxxxxxx] has joined #geda
01:33 < igor2_off> hi
01:33 < Bert> hi Igor
01:59 < Bert> hi
01:59 * igor2_off is waiting for the code spring to begin :>
02:21 -!- Bert [~e234574@xxxxxxxxxxxxxxxxxxxxxxxxxxxx] has quit [Remote host closed the connection]
02:35 -!- Bert [~e234574@xxxxxxxxxxxxxxxxxxxxxxxxxxxx] has joined #geda
02:38 < igor2_off> wb :)
02:50 < Bert> hi
02:52 < Bert> Still waiting for the code sprint ?
02:53 < igor2_off> yes
02:54 < Bert> It will take some time before the East coast wakes up ;-)
02:55 < igor2_off> yeah, at least 7 hours diff from my local time :)
02:57 < Bert> See if I can do some coding on my dxf exporter for pcb in the mean time
03:01 < igor2_off> good luck :)
03:02 < igor2_off> if john comes around, we'll try to make some progression in the sciptable plugin :)
03:18 < Bert> signing off for now, have to go shopping for the weekend
03:18 -!- Bert [~e234574@xxxxxxxxxxxxxxxxxxxxxxxxxxxx] has quit [Remote host closed the connection]
03:34 -!- werner2101 [~Werner@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx] has joined #geda
03:36 < igor2_off> hi
04:53 -!- peterbrett [~peter@xxxxxxxxxxxxxxxxxxxxxx] has joined #geda
04:54 < igor2_off> hi peter! :)
04:54 < peterbrett> hello
04:55 < peterbrett> I'm just off to go shooting, but I'm going to sit in channel logging while the code sprint gets going.
04:56 < peterbrett> speak later
04:56 < igor2_off> ok :)
05:02 -!- cnieves [~cnieves@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx] has joined #geda
05:03 < cnieves> Good morning!
05:04 < igor2_off> hi, howdy?
05:04 < cnieves> waking up! ;-)
05:04 < cnieves> well, not really...
05:05 < cnieves> I'm setting up all the devel stuff now...
05:05 < cnieves> :)
05:05 < cnieves> and you?
05:05 < igor2_off> when the code sprint starts?
05:05 < igor2_off> i'm coding :)
05:06 < cnieves> well, it depends. What time it is in your zone?
05:06 < igor2_off> 11:06, but if you tell a relative time like "in 2 hours", i can do the transformation :>
05:07 < cnieves> the same as mine. I think it'll start in 4 hours
05:08 < igor2_off> great
05:11 < igor2_off> i am trying to get user-mode-linux to work in the way i want it to work :)
05:11 < cnieves> what do you want to do?
05:11 < igor2_off> test my kernel module :)
05:12 < igor2_off> i just finished compiling my own uml kernel on a server and transferring the stuff onto my comp
05:12 < igor2_off> it took a hour to find out how to make it work on stdio (i don't want xterms and X in general:)
05:13 < cnieves> never done kernel dev. but it sounds hard...
05:13 < igor2_off> nah
05:14 < igor2_off> it's surprisingly easy
05:14 < igor2_off> i am doing it in qemu for now
05:14 < igor2_off> but UML would be at least 4x faster
05:14 < igor2_off> and i think i could debug the module easier
05:15 < igor2_off> the only hard part is the kernel panic you get for your bugs :>
05:15 < cnieves> :) not really a problem if you are under UML.
05:16 < igor2_off> yeah, i hope so :)
05:16 < igor2_off> the long years i got used to gdb and valgrind, and in general that software will find my bugs and tell me what to fix so it's a bit strange that i need to read over my code 10 times again :>
05:17 < cnieves> that always happens when you go to low-level programming... :)
05:18 < igor2_off> yup, but i love low-level :)
05:18 < cnieves> then you have to get used to it!
05:18 < igor2_off> actually i can't really do UI at all so i don't have too many choices, libs, daemons, drivers
05:18 < igor2_off> yup
05:18 < igor2_off> get used to it ... again
05:19 < igor2_off> i remember doing the same in dos and assembly, there i didn't get kernel panic but lockups :)
05:19 < cnieves> that's more or less the same as a kernel panic if you are not under UML
05:19 < igor2_off> yup
05:20 < igor2_off> so it feels somewhat nostalgic :)
05:20 < igor2_off> hmmz
05:20 < igor2_off> i've just found out my ISP has raised my downstream again
05:21 < igor2_off> (now that i download 140 megs of compressed kernel sources and binaries:)
05:22 < cnieves> doesn't your ISP want heavy transfers?
05:23 < igor2_off> dunny, i'm not interested in p2p and i'm not watrching movies on my pc so i have no idea about bandwiths and traffic limits :)
05:23 < igor2_off> s/dunny/dunno/
05:23 < igor2_off> well, now i'm off for 30 minutes, bbl
05:24 < cnieves> ok. see you later!
06:08 < igor2_off> back :)
06:08 < igor2_off> so, what will you do during this code sprint? :)
06:10 -!- Bert [~e234574@xxxxxxxxxxxxxxxxxxxxxxxxxxxx] has joined #geda
06:11 < cnieves> I'm fixing some issues of gnet-drc2 with guile-1.8, and I'll see if I can work some more time in the attribute autoplacing.
06:11 < igor2_off> nice :)
06:11 < cnieves> currently I'm drawing some tests for drc2
06:39 < igor2_off> and i'm currently (re)reading the hitchiker's guide to the galaxy
06:40 < igor2_off> just at the part where it turns out that marvin is actually 37 times older than the universe itself :>
06:41 < cnieves> nice. I've not read it myself, but I've heard about it. Do you like it?
06:42 < igor2_off> yup
06:42 < igor2_off> my favorite "trilogy" :>
06:42 < igor2_off> (and i generally hate sci-fi anyway)
06:43 < cnieves> :) I may give it a try some day...
06:43 < igor2_off> you should, Adams is very clever using any idea to make up good jokes :)
06:44 < igor2_off> like this one, sci-fi writers usually talk about travelling in time to make the story more interesting - in this book it is used to make a paranoid robot 37 times older than the universe or to have a restaurant from which you can watch the end of the universe "every night"... :)
06:45 < igor2_off> and actually
06:46 < igor2_off> this is the _only_ book i have ever read and really answered the Ultimate Question (what's the purpose of life, the universe and everything) so you can't skip it :>
06:46 < cnieves> :) have I to read the book to get the answer? ;)
06:47 < igor2_off> well, actually no, i can tell it
06:47 < igor2_off> it's very short and very preceise
06:47 < igor2_off> it's 42 :)
06:47 < cnieves> :o
06:48 < cnieves> so the purpose of everything is... 42?
06:48 < igor2_off> no, the Answer is 42
06:48 < igor2_off> to the Ultimate Question
06:48 < igor2_off> 'Life, Universe and Everything' :)
06:48 < igor2_off> a very big supoercomputer had calculated it
06:48 < cnieves> I think I have to read the book to understand that!
06:49 < igor2_off> it was running for 7.5 million years so it had enough time to double check whether the answer was correct :)
06:49 < igor2_off> yes, you definetly should :)
06:49 < igor2_off> but actually answering the ultimat question is only a very small part of the book, suhc issues pop up and gets elaborate every few pages :>
06:50 < cnieves> I never found a good answer to such questions... I'm curious!, I'll write it down in my book list :)
06:51 < igor2_off> ok :)
06:51 < igor2_off> it's important to read the books one by one, and the first one is the hitchiker's guide to the galaxy
06:52 < igor2_off> you wouldn't understand the restaurant at the end of the world or mostly harmless unless you read the first one first :)
06:52 < igor2_off> ohh, and
06:52 < igor2_off> recently there was a movie made from this series of book, in hollywood
06:52 < igor2_off> do not ever watch it
06:53 < igor2_off> or if you do, make sure you already had read all the books before :>
06:53 < cnieves> I'm reading the wikipedia entry for this "trilogy in 5 parts" :)
06:53 < igor2_off> :)
06:53 < cnieves> It's funny it's a trilogy, but it is actually composed of 5 books... :)
06:54 < igor2_off> anyway besides every page offers something i could laugh for minutes on, the book also has some deeper meaning
06:55 < igor2_off> like after I have laughed my ass off about some part, i suddenly realized it's the same in the real world as well, just we usually fail to notice the funny part of it :)
06:57 < cnieves> it seems a book to be read alone... if you don't want people looking at you and wondering what are you laughing so much about! :)
06:58 < igor2_off> but the real brilliant part is how he can make a joke of _everything_
06:58 < igor2_off> one of my personal favorite is this theory:
06:58 < igor2_off> if we assume the universe is infinite in size, we do not have to manufacture anything
06:59 < igor2_off> we just need to go out and find a planet where those things are, because there's a finite probability those things evolved somewhere in an inifinte universe
06:59 < igor2_off> so noone manufactures matrasses but they go to a swampy planet where matrasses live, they hunt down some, dry them and that's it
06:59 < igor2_off> because all matrasses are called tom, they can live their happy lives in the swamp because they don't notice which one of their folks had disappeared, tom, tom or tom ;)
07:01 < cnieves> :)
07:01 < cnieves> there is a finite probability such things exist, but you have a near 0 probability of finding them!
07:02 < cnieves> you've convinced me... I'll search the books!
07:03 < igor2_off> well, of course there's a solution for increasing the probability of finding them
07:04 < igor2_off> you just need to have an infinite-improbability device drivven space ship
07:04 < igor2_off> tht crosses every single point of the universe in the same time... :>
07:04 < igor2_off> well, read the book, you will find such a foolisnhess on every page ;)
07:07 < cnieves> ok :)
07:11 < cnieves> I'm going off for a while. See you later!
07:11 < igor2_off> cu
07:41 < Bert> Hi Peter, are you listening in ?
07:45 < Bert> I read your e-mail regarding git
07:50 < igor2_off> me too ;)
07:51 < Bert> Hi Igor
07:51 < igor2_off> hi Bert :)
07:51 < Bert> I started using git on my latest project
07:51 <@Ales> ah, everybody is here already. :)
07:51 < Bert> before that I was unsing gcvs which worked fine for me.
07:51 < igor2_off> and did you like it? :)
07:51 < igor2_off> hi Ales! :)
07:52 <@Ales> good morning. I'm still at home, but I will be leaving soon
07:52 < igor2_off> looking forward for the code sprint! :)
07:52 < Bert> Well it depends, it's only a couple of commits (20 or so) and I'm using the CLI
07:53 < igor2_off> CLI rules (i use svn cli:)
07:53 < Bert> Oh sorry, Hi Ales
07:53 <@Ales> hi Bert
07:54 <@Ales> carlos: take a look at this: http://lists.gnu.org/archive/html/guile-user/2007-01/msg00066.html thread
07:54 <@Ales> basically, they broke stable-sort
07:55 <@Ales> so we have to protect against passing a null
07:55 <@Ales> or we just wait for new version of guile (which may take forever)
07:55 < igor2_off> hehe :)
07:58 < cnieves> Ales: I'm on and off by now. I have just fixed that one, and another one Stuart reported.
07:58 < cnieves> I'm preparing a regression test suit for the drc2 backend.
08:01 < Bert> Igor: about git, I miss the $Id: irclog_sprint_20070210.txt,v 1.1 2007/03/07 22:33:42 ahvezda Exp $ tag being uodated after every commit, is is possible for git to do this as well
08:02 < igor2_off> svn doesn't do that either (but i didn't miss it:)
08:07 <@Ales> carlos: excellent. Thank you!
08:30 -!- pcjc2 [~pcjc2@xxxxxxxxxxxxxxxxxxxx] has joined #geda
08:30 < pcjc2> hi all
08:32 < Bert> Hi pcj2 ;)
08:38 < pcjc2> Looks like I have to nip out.. can't code without tea, can't make tea without milk ;)
08:39 < igor2_off> ;.
08:41 -!- mcmahill [~mcmahill@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx] has joined #geda
08:41 < mcmahill> good morning
08:42 < igor2_off> welcome :)
08:42 < Bert> Good day Dan :)
09:00 < cnieves> back again. Good day to everybody.
09:00 < igor2_off> wb :)
09:01 -!- igor2_off is now known as Igor2
09:15 -!- sdb [~sdb@xxxxxxxxxx] has joined #geda
09:15 < sdb> Hi guys!
09:16 < Igor2> hi
09:16 < cnieves> Hi Stuart!
09:17 < sdb> Carlos, thanks for fixing drc2! I worked on it for a while some weeks ago, but
09:18 < sdb> fixing it got too involved.
09:18 < sdb> Guile (Scheme) has the problem that it tends to generate extremely convoluted
09:18 < sdb> code, and it's hard to separate operations to fix them.
09:18 <@Ales> hi all again
09:18 < sdb> Today I will try to fix some of the problems which have affected spice-sdb
09:19 <@Ales> Hi Dan
09:19 < sdb> over the last year or so. In particular, the examples have broken due to bit-rot.
09:19 < cnieves> yeah, I see. I understand if they force it to be stricter, but I don't understand why they changed the behaviour with stable-sort, for example. Thanks for reporting it.
09:19 <@Ales> stable-sort breakage was definately an oops
09:19 < cnieves> hi Ales
09:20 < cnieves> ok. I thought it was intentional.
09:21 < cnieves> sdb: I think there are a couple of spice-sdb related bugs in SF. if you are going to work on it, could you take a look at them as well? At least one report has a patch as well, so it can be straightforward.
09:23 < cnieves> Ales, what do you think about: http://www.seul.org/pipermail/geda-dev/2006-October/001152.html
09:25 <@Ales> if we add the checks into autogen.sh, that'll be fine
09:27 < cnieves> ok. I'm preparing some tests for the drc2 backend, to be included into gnetlist/tests/drc2 directory.
09:27 <@Ales> nice
09:28 < cnieves> dumb question: can I do a for loop in the makefile, like this:
09:28 < cnieves> for file in *.sch; do \
09:28 < cnieves> gnetlist -g drc2 -o new_$file_basename.drc2 $file; \
09:28 < cnieves> diff $file_basename.drc2 new_$file_basename.drc2; \ done
09:29 <@Ales> not really, but you can use a sh script with continuation characters
09:30 < mcmahill> Ales: I saw your stable-sort post on the guile list where I'm a lurker.
09:31 < mcmahill> carlos: for loops in makefiles are make dependendent
09:31 < mcmahill> in BSD make it is
09:31 < cnieves> I don't get you. Do you mean to have a separate script out of the makefile and run it from the makefile?
09:31 < mcmahill> .for f in ${foo}
09:31 < mcmahill> echo "do something with ${f}"
09:31 < mcmahill> .endfor
09:31 < mcmahill> in GNU make it is different
09:31 < mcmahill> but if you want to do a shell for, you can do like you said
09:31 < mcmahill> but you need to replace $ with $$
09:32 <@Ales> but I don't really want to have dependancy on gnu make
09:32 <@Ales> or a specific version of make
09:32 <@Ales> the shell approach is portable
09:32 < mcmahill> right, so use a shell loop like what you have in your example
09:32 < mcmahill> just use $$ instead of $
09:32 <@Ales> okay I understand
09:32 < mcmahill> make will turn $$ into $ when it feeds it to the shell
09:33 < cnieves> ok, thanks!
09:33 < mcmahill> carlos: mmmmmm testsuites :) I'm glad you're adding something there.
09:33 < mcmahill> thats something I keep thinking I should spend some time on
09:34 < cnieves> I'm adding tests for the drc2 backend only... after Stuart's report I thought it would be nice to have them :)
09:35 < mcmahill> I wonder if anyone would find it useful for us to provide a makefile fragment to help manage gschem+gnetlist+gsch2pcb+pcb design projects
09:35 < Igor2> i actually have such a Makefile which i always keep on copiong
09:35 < Igor2> there are pros and contras
09:35 < mcmahill> something where the user would create a makefile that defines a couple of variables and then includes the makefile fragment
09:36 < Igor2> adventage is that one doesn't need to spend time creating his own and it gets updated with the changes of command line arguments / behaviour changes
09:36 < mcmahill> I put together such a thing for latex (latex-mk.sf.net) and I've found it really useful
09:36 < Igor2> also many people would test it
09:36 < mcmahill> I haven't thought clearly enough through the geda case to think of everything I'd put in it
09:36 < Igor2> but then it would rapidly become a big Makefile and if it doesn't do what you want, you will end up spending more time trying to fix it instead of having a fewliners
09:37 < mcmahill> Ales, are you at MIT?
09:37 <@Ales> yup
09:37 < mcmahill> who all is there?
09:37 <@Ales> Stuart, DJ and myself
09:37 <@Ales> the usual list of suspects
09:37 < mcmahill> yeah.
09:37 <@Ales> DJ is getting online
09:39 < cnieves> another question for the makefile experts.... when running gnetlist with the drc2 backend, the returning value forces "make" to stop running. Is there any way to ignore the returning value?
09:39 <@Ales> put a - in front of the command
09:40 < mcmahill> you can also do things like
09:40 < mcmahill> gnetlist .... || true
09:40 <@Ales> or that :)
09:40 < mcmahill> silly question... don't you want to stop on a non-zero return?
09:40 < cnieves> I prefer the second one. Thanks!
09:40 < Igor2> bah, where is John?
09:41 <@Ales> which John?
09:41 < mcmahill> or does drc2 give you non-zero return on warnings as well as errors?
09:41 < Igor2> John Griessen
09:41 < cnieves> usually yes, but gnetlist will return a non-zero value if there are DRC errors...
09:41 < Igor2> i wanted to meet him to work on the scriptable plugin of PCB together :)
09:43 < mcmahill> the latest pcb snapshot can build a non-cygwin windows installer. So my wifes pc promptly had a hardware failure. Perhaps it is a sign I shouldn't put up a binary windows installer for pcb...
09:43 < Igor2> :>
09:44 <@Ales> I'm doing a release today
09:46 -!- lares [~lares@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx] has joined #geda
09:46 < lares> G'Morning all
09:47 <@Ales> hi
09:47 < mcmahill> hello
09:47 < cnieves> good morning
09:47 < Bert> hello
09:47 < lares> so the code sprint has begun...
09:48 < lares> I'm new to this code, and an intermedate coder. THis should be interesting
09:48 < mcmahill> yep. although I used up most of my hacking time last night. I'll be in and out today.
09:49 < lares> life obligations just get in the way
09:54 -!- dj [~dj@xxxxxxxxxxx] has joined #geda
09:54 <@Ales> Hi DJ
09:55 < dj> hi
09:55 < lares> G'Morning dj
09:55 < Igor2> hi dj :)
09:55 < cnieves> hi!
09:55 < Bert> hi :)
09:55 < dj> mumble mumble morning mumble
09:56 < Bert> dj: had some coffee yet ?
09:56 * lares walks up to DJ, hands him a cup and fills it with coffee
09:56 < Bert> LOL
09:59 < mcmahill> hi dj
10:12 <@Ales> it's nice when people use the sourceforge patch tracker to upload patches
10:13 < cnieves> yeah, we should review them. There are quite a lot bugs and patches there...
10:13 <@Ales> I'm working on the patch list right now
10:13 < dj> Feel free to browse the pcb bug list too :-)
10:13 < peterbrett> 'lo all
10:14 < peterbrett> How's the sprint going?
10:14 <@Ales> dj: haha. No. :)
10:14 < mcmahill> oh yeah.. speaking of the geda sf tracker...
10:14 < Igor2> hi peter :)
10:14 <@Ales> peter: going well
10:14 < cnieves> hi peter
10:14 < dj> it's just like coding at home, but with people
10:14 < peterbrett> So, about git u.s.w.
10:14 < mcmahill> I think I have a bug report there that could use review by someone who knows more about gdk than me
10:15 <@Ales> what's the bug?
10:15 <@Ales> submit the bug, it's always easy to mark it as not a bug
10:15 < mcmahill> I was digging through compiler warnings (yeah, it's getting to be a habit) and there were complaints about values passed to some gdk functions
10:15 <@Ales> oh yeah
10:15 < mcmahill> oh, I did submit it
10:15 <@Ales> that bug
10:15 <@Ales> yeah, I'll take a look at it too
10:16 < peterbrett> Can I suggest that -pedantic gets added to the default compiler options if the compiler is GCC?
10:16 < mcmahill> I think Carlos fixed a bunch of the things in that pr but not all
10:16 < mcmahill> has anyone tried building with -pedantic?
10:16 < dj> do we really want to be that anal?
10:16 <@Ales> I do that sometimes
10:16 < mcmahill> I think I tried with pcb and there were a lot of complaints
10:17 < dj> -pedantic turns on a lot of ANSI requirements that nobody really likes.
10:17 < mcmahill> and some of them like long strings, I just don't see changing
10:17 < dj> It's there mostly for pedants ;-)
10:17 < peterbrett> dj: I've never had any problems writing code that -pedantic likes
10:18 < dj> Do you use trigraphs?
10:18 < peterbrett> dj: And I can't claim not to write horrible code.
10:18 * peterbrett confesses to not knowing what trigraphs are
10:18 < peterbrett> Ah, a character representation
10:18 < dj> Remember (* *) for pascal, when you didn't have { } ? Similar.
10:19 < dj> Unfortunately, the trigger is "??" so a lot of sane comments get flagged.
10:19 < peterbrett> Which leads me on to my first onerous feature request of the day: UNICODE.
10:19 < dj> Not in C.
10:19 < dj> As for the UI, patches welcome ;-)
10:20 < peterbrett> dj: As far as the core is concerned, surely unicode strings can be represented as character arrays
10:20 < peterbrett> dj: So **in theory** there should be no need to make core changes.
10:20 < peterbrett> dj: The one concern would be action strings
10:20 < dj> Almost. You have to be careful of multi-byte characters where one of the bytes is \0
10:21 < peterbrett> So some sort of unicode-safe strlen()-equivalent would be needed.
10:21 < dj> mbstrlen()
10:21 < dj> for example
10:21 < dj> wcslen()
10:23 * peterbrett can't find docs for mbstrlen()
10:23 < dj> not that one, wcslen()
10:24 < peterbrett> what happens if you pass a standard string to wcslen()? The documentation doesn't say...
10:24 < dj> it interprets it as a wide string.
10:24 < dj> it does NOT convert it.
10:24 < cnieves> I finished the drc2 regression tests, anyone wants to check them? Dan, are you working now in BSD?
10:25 < pcjc2> is wcslen for UFT8 or UTF16?
10:25 < peterbrett> pcjc2: it doesn't say, it just specifies "wide characters"
10:25 <@Ales> gschem is more or less unicode friendly
10:25 <@Ales> specifically UTF8
10:25 < dj> UTF8 is single byte. wide characters are (or used to be) platform-specific as to width.
10:25 <@Ales> carlos, just check them in and I'll run them.
10:26 < pcjc2> if you end up using utf8, standard ascii should work, so long as Bit #7=0
10:26 <@Ales> utf8 is nice.
10:26 < pcjc2> IIRC, bit#7 != 0 implies another byte coming - but this is just from a vague memory
10:27 < peterbrett> We really ought to get some Japanese & Chinese translators onboard.
10:27 < mcmahill> carlos, I have a geda work area both on solaris and NetBSD
10:27 < pcjc2> just don't talk to me about fonts, or character codings.. I was at the lab until 2:30am trying to get LaTeX to use a particular font
10:28 < peterbrett> pcjc2: You were using raw LaTeX rather than something like LyX?
10:28 < mcmahill> heh
10:28 < pcjc2> LyX actually
10:28 * peterbrett raises eyebrows
10:28 < mcmahill> I really like LaTeX except for nfss
10:28 < peterbrett> pcjc2: LyX bug, or LaTeX bug?
10:28 < pcjc2> but the font I wanted was a true-type, so had to be converted to a Type1 font. Then had to persuede TeX to find it
10:29 < pcjc2> When it eventually did, something was still very broken, so I gave up.
10:29 < peterbrett> pcjc2: Ouch.
10:30 < peterbrett> So, what are we going to do about git?
10:30 < pcjc2> I also spent hours banging my head regarding embeded Type1 fonts in postscript. Seemed like I couldn't make it work. Turns out that psmerge was distilling, and bitmapping them
10:30 < pcjc2> I'd like to see it continue
10:31 < peterbrett> Okay... what was the outcome of possibly getting it hosted on srcf?
10:31 < pcjc2> I have access to a server at the Electrical Engineering division (belongs to my supervisor, but I've got root). I can ask (he won't mind) if you can have an account
10:31 < pcjc2> Internal only though, so you'd have to cron an update to a public facing web-server
10:31 < mcmahill> btw. on this computer sizeof(wchar_t) = 4
10:31 < pcjc2> srcf is a possible
10:32 < pcjc2> To those non- cambridge people, "srcf" is student run computing facility, and they have a server we might use
10:32 < cnieves> Ales, Dan: I have committed the drc2 test suite. Can you run it?
10:32 < mcmahill> how?
10:33 <@Ales> isn't it just make test in gnetlist/tests ?
10:33 < mcmahill> that is on a NetBSD-4.0_BETA2 system running on a strongArm based computer (the wchar_t size)
10:33 < pcjc2> ok... srcf:
10:33 < pcjc2> -rwxr-sr-x 1 root crontab 29928 2006-07-21 03:38 /usr/bin/crontab
10:33 < pcjc2> and it appears to run, so we should be able to set up jobs
10:34 < cnieves> Ales,Dan: yes, or go directly to tests/drc2 and execute "make tests"
10:35 < peterbrett> Ales: How would you feel about hosting the git mirror on seul?
10:35 <@Ales> don't forget about doing a cvs update -d to get the new directory
10:36 <@Ales> peter: I don't have any objections, but there is some doubt about the future of the machine at seul
10:36 < mcmahill> carlos: could the target be changed so I can just run "make check" from the top level gnetlist directory?
10:36 < mcmahill> that would be a litle more standard
10:36 < peterbrett> Ales: that's inconvenient
10:36 <@Ales> dan: yes
10:36 <@Ales> we should change that
10:36 < mcmahill> peter: you know seul lives in a dorm room?
10:36 < peterbrett> mcmahill: I had no idea
10:37 < Igor2> hey, in a month or two i will have a new, stable server on 100 mbit (however internation line will be slower), so if the project needs a mirror or backup or aux git/cvs/whatever in hungary, just tell me
10:37 < peterbrett> pcjc2: Can we get gitweb up and running on SRCF this afternoon with a gitweb frontend?
10:37 < pcjc2> I talked to Peter long about servers.
10:38 < peterbrett> pcjc2: I don't want to have anything to do with PLong ever again.
10:38 < pcjc2> He agreed that Engineering probably wouldn't allow it here, but said he'd talk to people
10:38 < pcjc2> Still not been paid?
10:38 < peterbrett> pcjc2: Nope
10:38 < cnieves> mcmahill: how can I add it to the "make check"?
10:39 < Igor2> btw i have a server to offer at the moment as well, but it's getting unstable and there'll be a transition time when i get the new server when neithre would work
10:39 < Igor2> (on the new server i could provide a dedicated vserver for geda)
10:39 < peterbrett> Igor2: A mirror would be good, let me know when it's set up
10:39 < Igor2> ok
10:39 < pcjc2> peterbrett: I already have my work on srcf, but its not automatically updated http://www.srcf.ucam.org/~pcjc2/geda/gitweb.cgi
10:40 < Igor2> i'm waiting for an ATX PSU for the new server which i should get next week :)
10:41 < peterbrett> pcjc2: When are we likely to be able to get a cron job set up on your server for updating the SRCF repo?
10:42 < pcjc2> I could ssh in
10:42 < pcjc2> it is a virgin server though, so probably needs some packages installing
10:42 < pcjc2> Easiest is to see if the SRCF mind us running cron jobs
10:43 <@Ales> I've been thinking about moving all of gEDA to sourceforge
10:43 <@Ales> that is assuming the seul situation goes bad
10:43 < pcjc2> Ales: Oh dear.... they are very slow
10:43 <@Ales> slow in what way?
10:43 < Igor2> sourceforge... has a pretty time-wasting web interface :>
10:43 * peterbrett asks on #srcf
10:43 < peterbrett> Ales: I'm really not a fan of SF
10:43 < Igor2> btw
10:44 < Igor2> i have a small irc network of a .hu and a .nl server
10:44 < pcjc2> Stuff hosted on sourceforge tends to be very slow at peak times
10:44 < Igor2> i can offer that for #geda if seul goes down
10:44 <@Ales> okay, two votes against sourceforge
10:44 < Igor2> (as sourceforge doesn't have irc)
10:44 <@Ales> Igor2: that'll be nice
10:45 <@Ales> I did register geda on google code, maybe that'll be okay
10:45 < pcjc2> I'm ambivilant towards sourceforce, the plus side, is they probably take care of backups etc..
10:45 < peterbrett> pcjc2: We should be good to run cron jobs on SRCF
10:45 <@Ales> and I don't have to admin anything on sf :)
10:45 < dj> and lots of people would notice if it suddenly went away
10:45 < Igor2> sf also has a compile farm where you can test your projects cross-compiling
10:46 < peterbrett> What we really want to do is raise enough money to get a properly-hosted server
10:46 <@Ales> carlos: if I run make test in tests/drc2, make finishes successfully
10:46 <@Ales> is that the expected result?
10:46 < cnieves> Ales: yes.
10:47 < Igor2> >peter> actually that is what i am planning to do too, that's how i will have my server soon :)
10:47 < pcjc2> peterbrett: did repo.or.cz fall through?
10:47 < Igor2> in hungary hosting is relatively cheap
10:47 < dj> If we can just raise $0, we can host it on sourceforge...
10:47 < cnieves> Ales: do you know how are targets added to "make check"?
10:47 < peterbrett> pcjcs: http://repo.or.cz/w/geda-gaf.git
10:48 < mcmahill> pcjc2: sf does not take care of backups
10:48 <@Ales> I backup the sf manually for geda
10:49 < mcmahill> I rsync the repository and create a tarball nightly
10:49 < pcjc2> ok
10:49 < mcmahill> I have not been backing up the trackers although I need to
10:49 < pcjc2> peterbrett: http://repo.or.cz/w/geda-gaf.git is not up to date.. did you have to push it manually from CUED?
10:49 <@Ales> that reminds me I should do tha tnow
10:49 <@Ales> now
10:49 < peterbrett> It needs manual pushing
10:50 < peterbrett> But there's no reason we can't create a cron job that pushes to it
10:50 < pcjc2> indeed
10:50 < mcmahill> carlos: how do I know if it was a pass or fail?
10:50 < pcjc2> peterbrett: do you have a srcf account already?
10:51 < peterbrett> pcjc2: not yet
10:51 < cnieves> mcmahill: the "make tests" is like when you run make for compiling. If there is any error, it stops and you will see some message showing the error.
10:51 < pcjc2> my quota is nearly used unfortunately, so might be good for you to get an account
10:51 < mcmahill> oh, I see. Might I suggest that you always run all the tests and give an explicit PASS/FAIL output for each one
10:51 < mcmahill> and then at the end throw an error code if any failed?
10:52 -!- rikster [~rik@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx] has joined #geda
10:52 < cnieves> mcmahill: I'll see how to do it. Do you know how to add the tests to the main "make check".
10:52 < cnieves> ?
10:52 < mcmahill> yeah. let me look
10:53 <@Ales> carlos: I don't remember that either
10:54 < mcmahill> check_SCRIPTS= script1 script2 ...
10:54 < pcjc2> peterbrett: Ok, some more quota now... SRCF guys kindly installed cogito and git for me, so I can drop the binaries in my user-area
10:54 < mcmahill> check_DATA= list of golden files
10:54 < peterbrett> pcjc2: Woo
10:54 <@Ales> dan: does that mean that you need to have scripts that do the checking?
10:54 <@Ales> instead of having them inline in the makefile
10:54 < mcmahill> yes
10:54 <@Ales> okay
10:54 <@Ales> that's fine with me
10:55 < dj> pcb center cursor: center the mouse pointer, or the grid crosshair?
10:55 < cnieves> can't they be inline?
10:55 < mcmahill> you might find it useful for the test script to have a --regen option to regenerate the golden files
10:55 < mcmahill> carlos: I don't think so but I could be wrong
10:56 < mcmahill> there is also a TESTS_ENVIRONMENT you can set for any environment variables you need
10:57 <@Ales> Carlos: I added a .cvsignore and I removed *.drc2 files in tests/drc2/Makefile.am
10:57 < mcmahill> alright. the kids are revolting. biaw
10:57 < peterbrett> pcjc2: I've e-mailed sys-admin@eng to get the cron job removed
10:57 <@Ales> no sorry
10:57 <@Ales> I am stupid. ignore that last bit
10:57 < cnieves> Ales: why? they are the golden files!
10:58 <@Ales> doh! I am not doing that now.. :)
10:58 < peterbrett> pcjc2: Now I have to sit around until they approve my application...
10:59 < peterbrett> s/they/SRCF/
10:59 <@Ales> I meant to say I added code to Makefile.am to remove the new_*.drc2 files
11:00 < cnieves> what do you think about: for file in *.sch; do \
11:00 < cnieves> file_basename=`basename $$file .sch`; \
11:00 < cnieves> echo Checking test in $$file_basename.sch; \
11:00 < cnieves> gnetlist -g drc2 -o new_$$file_basename.drc2 $$file || true; \
11:00 < cnieves> test -f $$file_basename.drc2 && \
11:00 < cnieves> diff $$file_basename.drc2 new_$$file_basename.drc2; \
11:00 < cnieves> if [ $$? -ne 0 ]; then \
11:00 < cnieves> echo "Test in $$file_basename.sch FAILED!!"; \
11:00 < cnieves> break; \
11:00 < cnieves> else \
11:00 < cnieves> echo "Test in $$file_basename.sch PASSED."; \
11:00 < cnieves> fi; \
11:00 < cnieves> done
11:00 < peterbrett> cnieves: Gaaaah!!! pastebin!!!
11:00 < cnieves> sorry!
11:00 <@Ales> carlos: I like it the implementation
11:01 < peterbrett> http://pastebin.co.uk/
11:01 < cnieves> is it necessary another sentence like: all tests passed, or similar?
11:01 < peterbrett> cnieves: (also, that way you get syntax highlighting)
11:02 <@Ales> carlos: you can if you wish, but usually when make completes with an zero exit status, that's good enough for me
11:02 < cnieves> peterbrett: thank you, I didn't know about this.
11:02 < peterbrett> pcjc2: CVS is so slow compared to git :(
11:02 < cnieves> Ales: I agree. Dan?
11:04 < cnieves> Ales: what have you changed in Makefile.am?
11:04 < peterbrett> Any sign of Patrick today?
11:04 <@Ales> I added new_*.drc2 to the clean targets at the bottom
11:04 <@Ales> is that okay?
11:05 < cnieves> weren't they already? (as new_*)
11:05 <@Ales> nope
11:05 < cnieves> do you mean DISTCLEANFILES, then?
11:05 <@Ales> dang.
11:06 <@Ales> I'm sorry, yes they were...
11:06 <@Ales> I have made no changes to Makefile.am (now :)
11:06 <@Ales> maybe I should stop making changes now.
11:06 < rikster> Who should I talk to on the channel about a patch for gnet-bom.scm?
11:06 <@Ales> I have added a .cvsignore though
11:07 < cnieves> or maybe you need another cup of coffee?
11:07 <@Ales> I don't drink coffee. :)
11:07 < cnieves> Ales: I forgot to cvs add that file. I have it with Makefile and Makefile.in. Is that fine?
11:08 <@Ales> please also add new_*.drc2
11:08 <@Ales> then I'll remove my file
11:08 < cnieves> then, what do you drink instead?
11:08 < cnieves> are wildcards accepted in .cvsignore?
11:08 <@Ales> water. :)
11:08 <@Ales> yes
11:10 < pcjc2> I'm just trying water now.. tea didn't cure my headache
11:11 < cnieves> rikster: there is no special maintaner for gnet-bom.scm. Just tell us about the patch.
11:12 <@Ales> rikster: and submit it to the http://sourceforge.net/tracker/?atid=818428&group_id=161080&func=browse
11:13 < rikster> The patch is a simple one-liner for gnet-bom.scm and gnet-bom2.scm to have it print "refdes" instead of "package" on the title line.
11:14 < rikster> This is truth-in-advertising since the database key being used is in fact the refdes.
11:15 * peterbrett is compiling libgeda with -pedantic
11:15 < peterbrett> Okay, libgeda is clean with -pedantic
11:16 <@Ales> rikster: sounds good, please submit. :)
11:17 < peterbrett> Actually it's not :-(
11:17 < dj> yes! no! yes! no!
11:17 < peterbrett> dj: I thought I'd enabled it when I hadn't
11:18 < dj> Use -Wall and -Werror too. IIRC there's a -Wpedantic. Also, use -ansi or -pedantic doesn't do anything. One of the -std= might be helpful too.
11:19 < peterbrett> dj: It works fine with -pedantic :-/
11:19 < peterbrett> dj: I assume we're on std=C99?
11:19 < peterbrett> Also, are we permitting GNU extensions?
11:21 < sdb> Guys -- Does anybody have any spice-sdb bugs they'd like to raise?
11:21 < sdb> I fixed the one in Bugzilla about x -> dx
11:21 < sdb> and I also made the examples/TwoStageAmp example work again.
11:21 < sdb> But before I turn my attention to some other project I'd like
11:22 -!- pat [~pat@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx] has joined #geda
11:22 < cnieves> sdb: do you accept new feature request as well?
11:23 < pat> hi everyone
11:23 < Igor2> hi pat
11:23 < cnieves> hi
11:23 < Bert> hi
11:23 < lares> G'Morning
11:24 < pcjc2> hi
11:24 < peterbrett> hi pat
11:24 < peterbrett> Hmm... interesting... libgeda won't compile with -std=c99
11:24 <@Ales> Hi Patrick
11:24 <@Ales> peterb: No GNU extensions if at all possible
11:25 < sdb> to make sure there are no outstanding problems.
11:25 < sdb> Hi Patrick!
11:25 < peterbrett> Ales: yes, using -std=c99 disables GNU extensions IIRC
11:25 < sdb> Carlos, I do accept feature requests!
11:25 < peterbrett> Ales: Which version of ISO C do we want gEDA to conform to?
11:27 <@Ales> C90
11:27 <@Ales> (just a guess)
11:27 -!- rikster [~rik@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx] has quit [Remote host closed the connection]
11:27 < peterbrett> well GCC doesn't fully support C99 yet, so C90 is probably a safe bet
11:27 <@Ales> PeterC: is this patch still valid? http://sourceforge.net/tracker/index.php?func=detail&aid=1527420&group_id=161080&atid=818428
11:28 <@Ales> [ 1527420 ] New (testing) layout of the component picker
11:28 < pcjc2> no
11:28 < cnieves> sdb: a lot of time ago, we talked about a new symbol the user connects to those signals he wants to plot. I don't use spice-sdb, so I never need that. Could it be a short-time doable thing?
11:28 < pcjc2> that was a layout I explored before Patrick re-wrote the dialog
11:28 <@Ales> Carlos: is this patch still valid? http://sourceforge.net/tracker/index.php?func=detail&aid=1551233&group_id=161080&atid=818428
11:28 <@Ales> [ 1551233 ] Zooming/panning while moving/copying
11:28 <@Ales> Peter: I'm going to close this patch without doing anything with it then (?)
11:29 < pcjc2> The concept is still valid, a narrow, tall window for component picking, which could get turned into a side-pane
11:29 <@Ales> C90 compliance should be good enough
11:29 < pcjc2> but the patch would be way out of date
11:29 <@Ales> okay thanks
11:29 < sdb> Carlos, yes I can do that. Maybe not today. I will make it a feature request on
11:29 < pcjc2> Go ahead and close it - I have a screenshot somewhere
11:29 < cnieves> Ales: no. that patch was the root of the glist-dev branch.
11:29 < sdb> SF and also put it in my ToDo list, where it will follow me around everywhere
11:29 < peterbrett> ../include/defines.h:346:23: warning: anonymous variadic macros were introduced in C99
11:30 < cnieves> sdb: thanks!
11:30 < peterbrett> Can compiler pedants please suggest what to do about this?
11:30 < sdb> I go! That's how I manage to keep track of everything I'm working on....
11:30 < pcjc2> I'm struggling a little here, as I'm battling a stonking headache, but I'm attempting to resolve the noscreen work - today is the first free time I've had in ages!
11:31 <@Ales> carlos: so can I close the patch without doing anything with it?
11:31 < lares> Help.. what 'modulename' for trunk?
11:31 < cnieves> Ales: yes.
11:31 <@Ales> thanks.
11:31 < lares> I'm a SVN guy
11:31 <@Ales> lares: gEDA/gaf or PCB?
11:31 < lares> pcb
11:32 < dj> pcb
11:32 < lares> lol
11:32 < dj> or "."
11:32 < lares> okay
11:33 < Igor2> so i'm not alone with svn here :>
11:33 < dj> I get to use both on a daily basis :-)
11:33 < Igor2> but they are similar, aren't they?
11:33 < Igor2> i think cvs was a bit weaker in offline working (needs net access for more things)
11:33 < dj> Each has its ups and downs.
11:37 < lares> I've never really 'used' cvs. All my repos are svn
11:39 < werner2101> Hi all,
11:40 < cnieves> hi werner
11:40 < peterbrett> Hi werner
11:40 < werner2101> just tried to compile gaf but gattrib failed.
11:40 < werner2101> anyone else has problems with it?
11:40 < werner2101> s_object.c:319: error: 'PAGE' has no member named 'selection_list'
11:41 < werner2101> Igor2: I've read Adams trilogie, too. Very nice books.
11:42 < Igor2> :)
11:42 <@Ales> werner, gattrib builds fine for me... lemme try again
11:42 <@Ales> did you rebuild and install libgeda too?
11:42 < werner2101> yes
11:43 < pat> werner2101, Ales: PAGE do have a selection_list member
11:43 <@Ales> I'm going to rebuild everything now.
11:43 < werner2101> Ok. I'm rerebuilding everthing now too.
11:43 <@Ales> Hi Werner
11:44 < werner2101> Hi Ales, long time since last chat
11:44 <@Ales> yeah, how have you been?
11:45 < mcmahill> I'm a bit late on the "me too", but please no gcc extensions.
11:45 < mcmahill> I know for a fact some users use sun's compilers
11:45 < dj> Solaris?
11:45 <@Ales> Dan: yes, we know how you feel about GNU extensions... :)
11:45 < cnieves> I manage to add the tests to the make check. can anyone run "make tests" in gnetlist/tests/hierarchy? it fails for me
11:46 < mcmahill> gcc is the primary compiler I use, but its still nice to work with some others
11:46 < peterbrett> Folks, CVS gschem won't compile for me... 8-O
11:48 <@Ales> I'm building now
11:48 <@Ales> carlos: once I have a build, I'll try it out
11:49 < peterbrett> BTW, is anyone doing bug triage for geda?
11:50 <@Ales> I haven't gotten to that yet. I've been applying patches. :)
11:50 < peterbrett> Ales: :)
11:50 < peterbrett> Ales: Most of them were opened by you, so I guess you're probably the best one to work out if they're still current
11:51 < peterbrett> cnieves: is this still current? http://sourceforge.net/tracker/index.php?func=detail&aid=1553483&group_id=161080&atid=818426
11:51 <@Ales> peter: lucky me. :)
11:52 < cnieves> peterbrett: I think so. I didn't fix it.
11:53 < cnieves> werner and pat: you were changing the dialogs. Did you do anything else to change the ok/cancel button order depending on gtk settings?
11:53 < peterbrett> k
11:54 < pat> peterbrett: not all dialog in gschem are GtkDialog derived, so the change of button order will not work on all dialogs
11:54 < peterbrett> pat: So the first step is to change all dialogs to be GtkDialog derived?
11:54 < pat> peterbrett: yes
11:55 < pat> peterbrett: this is what I have done so far with the one I modified
11:55 < lares> dj: add busy cursor to applyvendorMap?
11:55 < dj> How long does it take to run?
11:55 <@Ales> okay, CVS gEDA/gaf built fine for me
11:55 < pat> werner2101: gattrib does build fine for me
11:55 < lares> minute or so
11:56 < peterbrett> pat: That's what I'd thought
11:56 < pat> werner2101: anyway the selection stuff in gattrib is not needed at all
11:56 < peterbrett> Ales: Wierd. I get a failure in gschem
11:56 < werner2101> pat: I still have problems, I will remove the rpms of gaf and try again.
11:56 < pat> werner2101: it is not used at all
11:56 < peterbrett> Ales: When I've got the git mirror working again, I'll see if I can track it down
11:56 < pat> werner2101: part of my last changes to selection was to remove it from gattrib
11:57 < werner2101> regarding the dialogs: only the attribedit dialog is not gtkdialog based.
11:57 < dj> ok, apply vendor map gets busy cursor too.
11:57 < pat> werner2101: the find dialog for example is a GtkDialog?
11:58 < werner2101> yes.
11:58 < lares> dj thax
11:58 < pat> werner2101: ok sorry I thought there were more in that case
11:58 < dj> hey, vendor mapping is a linear search...
11:59 <@Ales> carlos: I checked in a fixed golden file. make tests in hierarchy should work now
11:59 <@Ales> peter: yes, let me know what I've broken. :)
11:59 < werner2101> pat: I've changed most of the dialogs after christmas
12:00 < dj> lares: how many drills in your vendor map?
12:00 < peterbrett> sdb: Do you have any plans to add gattrib's functionality into gschem?
12:00 < peterbrett> sdb: It would be nice not to have to keep switching between the two
12:00 < pat> werner2101, peterbrett: very nice so we are close to being able to change the order of buttons in dialog
12:00 < cnieves> Ales: not it passes ok. I'll commit the "make check" changs
12:01 < sdb> No. I have no plan on integrating gattrib into gschem. Indeed, I am (slightly)
12:01 < sdb> against doing it, since it breaks the unix philosophy.
12:01 <@Ales> but we could provide a menu option (like the pcb option) for launching gattrib from gschem
12:01 < sdb> OTOH, if somebody else did the work, I wouldn't get in the way.
12:02 < peterbrett> sdb: Having GUIs breaks the UNIX philosophy, really :)
12:02 < sdb> And, as DJ says: Think DBUS -- run them simultaneiously and let them communicate.
12:02 < Igor2> i think integrating in a way xgsch2pcb does is a good approach
12:02 < sdb> Yea, launching gattrib from gschem is OK. I just don't envision combining the two.
12:03 < peterbrett> sdb: pcjc2 and I do have a cunning plan regarding that -- make libgeda DBUS-aware, so that apps based on it don't have to do anything special to be able to share state -- but that would be pretty evil :D
12:03 <@Ales> evil! :)
12:03 < sdb> One other thing: I *do* intend on creating lockfiles for gattrib/gschem, since
12:03 < sdb> lots of people -- me too -- run the two programs simultaneously in separate windows and
12:03 < lares> dj: about 12 different drills, 5.5x8" w/1200 drills
12:03 < sdb> it's too easy to get confused and save the wrong version.
12:03 < lares> err holes
12:04 < dj> the map search is linear, I'm changing it to binary but with only 12 drills it shouldn't add up to that much.
12:04 < dj> maybe we need a hash on the lookup.
12:04 < sdb> Peterbrett: Yes, making libgeda DBUS aware is the way to go! I also
12:04 < sdb> like it since it will enable a new project manager.
12:05 < lares> I have a slower computer anyway.
12:05 < Igor2> how slow?
12:06 < peterbrett> http://xkcd.com/c215.html
12:07 < dj> www.schlockmercenary.com
12:09 < lares> 2.4Ghz.
12:09 < lares> so not really that slow.
12:10 < werner2101> gattrib compiles after uninstalling all gaf rpms. I'll try to reproduce this tomorrow.
12:12 < Igor2> then i still have the slowest computer here, probably :)
12:12 < sdb> Werner -- Any idea why that would be the case? Is there source code in those
12:12 -!- mike [~mike@xxxxxxxxxxxxxxxxxxxxxxxxxxx] has joined #geda
12:12 < sdb> RPMs?
12:12 < pcjc2> Hi Mike
12:12 < sdb> Hi Mike!
12:12 < mike> Hi!
12:12 < cnieves> hi!
12:13 < werner2101> sdb: no, maybe the build looks in the libdir path?
12:13 < mike> I finally got moved in enough to get my internet connection up, and all the machines working here.
12:14 <@Ales> Hi Mike
12:14 < werner2101> rpms = redhat packages that I've installed outside of $home
12:14 < sdb> Werner, the gattrib build is straight GNU automake stuff, so if gschem compiles,
12:14 < sdb> then gattrib shoudl work.
12:15 < dj> lares: please try http://www.delorie.com/pcb/vendor.c.patch (I have no vendor maps to test with)
12:15 < werner2101> that's why I'm curious, gschem builded, gattrib not. I'll look at it tomorrow, compiling takes lot of time.
12:16 <@Ales> you need to cvs update -d
12:17 < werner2101> Ales: I did that today before compiling the first time but not before removing my rpms
12:18 < werner2101> I'm still confused.
12:20 < lares> dj: will do
12:21 < mike> I have the patch from Wojciech Kazubski for the misaglined printing bug, #160757. Can I commit it?
12:21 <@Ales> sorry, I was talking to DJ. :)
12:21 <@Ales> mike: yes please
12:21 < mike> Will do as soon as my build completes here.
12:21 <@Ales> DJ and Stuart went to lunch
12:21 < lares> dj: boo to you and your wget killing !
12:22 < mike> I had thought I would tackle adding an rc setting that sets the scaling factor for the PS output text. There was a complaint a while ago about the relative sizes of the fonts.
12:23 < Igor2> >lares> -U mozilla? :)
12:23 <@Ales> lares: do -U blah and you should be okay
12:23 < lares> I'll give it a try.
12:24 <@Ales> worked for me (with DJ standing over my shoulder) this morning
12:24 < cnieves> Ales: I have a check of automake version that could go into autogen.sh. Where can we put it? in libgeda only (it's the first app to be built), or in every autogen.sh?
12:25 <@Ales> I'm okay with just in libgeda
12:26 < pcjc2> Can I bother people about bounding boxes and coordinates....
12:27 <@Ales> sure
12:27 < pcjc2> The present situation in libgeda, is that we have a "world_get_..._bounds()" function for various objects, which calculates the bounding box for the object
12:28 < pcjc2> we have an o_..._recalc() function for objects, where (usually), the (world_)_get_..._bounds() function is called, and the result cached. (I say (world), as my caching now works with world bounds)
12:29 <@Ales> okay
12:29 < pcjc2> So... for much usage in the application, getting the bounds of an object causes it to be calculated. Often using "MIN(...) and MAX(...)" macros
12:29 < pcjc2> For certain tasks, such as mouse hit detection, a cached value is used
12:30 < pcjc2> Where I got stuck with re-working the noscreen patches, is whether or not I have refactored these bits correctly
12:30 <@Ales> is this code checked in on your branch?
12:30 < pcjc2> I said (to myself): o_..._recalc() should do the calculation, with the MIN, MAX.. and cache the results
12:31 < pcjc2> Ales: no, the git repository I have on the web has the code up to this point. I'm just describing the patches I've got outstanding
12:31 <@Ales> I would think that o_..._recalc be the lowest level
12:31 < pcjc2> The stuff checked into CVS is stable, and could be merged
12:31 < pcjc2> so...
12:31 <@Ales> I want to do one more release before I merge your branch
12:31 <@Ales> I'm working on that release now. :)
12:32 < pcjc2> My patches _REMOVE_ the (world_)get_..._bounds() functions, for all but a couple of objects
12:32 < pcjc2> (This is where alarm bells start to ring)
12:32 <@Ales> hmmm
12:32 < pcjc2> I should have by this point, ensured that the bounds are always kept up to date in the cache, (in the st_object struct)
12:33 <@Ales> so how I just need to call o_..._recalc to update the world bounding boxes?
12:33 < pcjc2> should be
12:33 <@Ales> no reason to have two functions
12:33 < werner2101> Ales: we should update all i18n stuff before releasing
12:33 <@Ales> when you say update.. what do you mean?
12:33 < pcjc2> There is a helper function which retrieves the bounds for a "generic" object
12:34 <@Ales> I haven't had much success in getting the various translators to give me regular updates
12:34 < pcjc2> which checks the type of object, and in most cases, just grabs the cached bounds. In the case of text, it checks visibility first, in the case of complex, it recurses.
12:34 <@Ales> sounds reasonable
12:34 < werner2101> Ales: regenerating the pot files and give the translators one week to translate.
12:34 < pcjc2> What bothered me was the potential special-casing
12:35 <@Ales> Werner: I could do that. but that means the release will be delayed by one week
12:35 <@Ales> I know that Stuart is itching to do another suite version
12:35 <@Ales> and the work that Dan did for gsch2pcb is quite nice
12:35 <@Ales> I will discuss this with Stuat
12:35 <@Ales> r
12:36 < werner2101> Can you give me a day?
12:36 < pcjc2> I don't think anything outside libgeda needs to access a given object's specific implementation though, so this really relates to how the object "classes" are handled
12:36 < lares> dj: patch looks good to me.
12:36 <@Ales> the problem is that I'm away next week
12:36 <@Ales> weekend
12:36 < peterbrett> CVS server is being slow :(
12:36 <@Ales> lemme talk to Stuart when he returns
12:37 <@Ales> I do agree that it would be nice to have all those translations up to date
12:41 < lares> dj: good for lesstif, no for gtk.
12:41 < pcjc2> Ales: to give you an idea of my patchset, http://www.pastebin.ca/349250
12:42 < lares> It seems that gtk redraws after every drillsize change. and lesstif does it all then redraws.
12:42 < peterbrett> pcjc2: That's pretty epic
12:42 < pcjc2> peterbrett: It represents the majority of the architectural changes for the noscreen work
12:43 < mike> I made the commit of Wojciech's patch.
12:43 <@Ales> mike great
12:43 < peterbrett> pcjc2: I'm ~90% of the way to getting the new repo working
12:43 < pcjc2> I had to write a file to keep track of what I was doing... I started with the git log from my nearly working tree, then re-ordered and grouped them by logical change, and to keep each commit working
12:44 < pcjc2> cool
12:44 < pcjc2> peterbrett: Any chance that the SHA1 will match up? I guess they should?
12:44 < peterbrett> They will
12:44 < peterbrett> (a) because I copied the tree from eng.cam (I didn't want to spend 4 hours waiting for it to strip CVS)
12:45 < peterbrett> (b) because it's generated from exactly the same data
12:45 < pcjc2> if all settings are the same, it stands a good chance of being the same;)
12:47 <@Ales> okay, Stuart and DJ are back
12:47 <@Ales> I will delay the release by a week.
12:48 < Igor2> so, does pcb already have a GTK programmer?
12:48 < werner2101> Thanks Ales
12:48 <@Ales> Release date for gEDA/gaf is 20070216
12:48 <@Ales> I will update the configure scripts as appropriate
12:48 < sdb> Igor, for GTK, PCB has Dan.
12:48 < sdb> I have also volunteered to work on it, but I haven't done
12:49 < Igor2> :)
12:49 < werner2101> Ales: I will try to add the last non-GtkDialog tomorrow.
12:49 < sdb> anything.
12:49 < sdb> I *do* plan to put DOxygen style comments
12:49 < Igor2> any chance to have HID for an import dialog similar to the export dialog and another for pcb-modificating plugins/scripts?
12:49 < werner2101> I expect some guests in a few minutes. I'll have to leave soon.
12:49 < sdb> into PCB's GTK stuff as a first step towards learning
12:49 < sdb> the cod.e
12:50 <@Ales> werner: sounds good
12:52 <@Ales> plus, a week delay will allow the code base to stablize after today :)
12:52 < dj> lares: not much I can do about the gtk thing, at least nothing easy.
12:53 < dj> and about wget... anyone smart enough to use -U is smart enough to not accidentally download my whole site.
12:53 < lares> dj. it would appear I'm just now becomming the smart one.
12:53 < lares> err s/the/a/
12:54 < cnieves> anyone knows the allowed automake minimum version requirement?
12:55 -!- Igor2 [~igor2@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx] has quit [Quit: Leaving]
12:56 < pcjc2> Ales: question becomes, is it ok to remove most of the (world_)get_..._bounds() functions, and leave the helpers for things like world_get_complex_bounds().. which is fact now a wrapper to world_get_object_list_bounds()
12:57 -!- rikster [~rik@xxxxxxxxxxx] has joined #geda
12:57 < pcjc2> Should we propogate all requests for "bounds" into the obejcts, and allow simple stub implementations like a function such as o_get_cached_bounds()
12:58 <@Ales> peter: I think so, question though, how do I update the world bounds for say a line or a circle?
12:58 < peterbrett> pcjc2: Fully-updated git tree now at http://repo.or.cz/w/geda-gaf.git
12:58 < peterbrett> pcjc2: I suggest you make a "fork" on there for your own work
12:58 -!- Cesar [~Cesar@xxxxxxxxxxxxxxxxxxxxxx] has joined #geda
12:59 < Cesar> Hello, everybody.
12:59 < pcjc2> the way it is cached (and used) currently, the cached bounds are just the smallest rectangle (oriented with horizontals and verticals) which contains the objects
12:59 <@Ales> Carlos: automake 1.6 is my guess, we can always change it later
12:59 <@Ales> Hi Ceasar
12:59 < pcjc2> Hi Cesar
12:59 -!- Cesar [~Cesar@xxxxxxxxxxxxxxxxxxxxxx] has quit [Client Quit]
12:59 < cnieves> hi Cesar
13:00 < cnieves> Ales: ok. I'm committing the changes now.
13:00 -!- Cesar [~Cesar@xxxxxxxxxxxxxxxxxxxxxx] has joined #geda
13:00 < pcjc2> Which means - perhaps incorrectly, it is already possible to select a diagonal line any where inside the rectangle it occupies
13:00 < cnieves> Hi cesar
13:00 < Cesar> Hi, Carlos.
13:01 <@Ales> peter: yes that is a limitation of sorts of how the bounding/selection stuff works
13:02 < pcjc2> it would work the same with the changes
13:04 <@Ales> okay
13:05 < lares> anyone else working on free rotation?
13:06 < dj> not that I know of.
13:06 < pcjc2> my sticking point is that in my code, taking an example of world_get_single_object_bounds() - which probably wants to get moved, and renamed - as proposed by Patrick I think, the code specifically knows to look at the cached coordinates for some objects, and to call helpers for others (complex objects)
13:07 < pcjc2> lares: not me, but I did have a few thoughts when I saw your post... I've been wanting rotated components in PCB, as it makes doing things like sensor boards for motor armatures quite nice.
13:07 < dj> The only tricky bit is non-90 pads.
13:08 < werner2101> My guests are here, I'm leaving, bye.
13:08 < dj> The rest is, I think, is just a lot of effort, but not so much tricky.
13:08 <@Ales> bye werner
13:08 < pat> bye werner
13:08 < pcjc2> Sure, there is more critical work to do first, in getting it going, but things like allowing the line-direction enforcing tools to work w.r.t the rotation of the starting component
13:09 < cnieves> bye werner
13:09 < pat> pcjc2: I donot understand your point: the code should use the cached coordinates all the time
13:09 < pat> pcjc2: its bounding box is updated (with o_recalc() or get_bounds()) only when it is modified
13:10 < pcjc2> Patrick: For now, I'm not sure that the complex objects will work reliably
13:11 < pat> pcjc2: why? you can not modify the internals of a complex
13:11 < pcjc2> I'm debating whether to scrap the (world_)get_..._bounds() functions entirely - understanding that there is an generic "object" function which reads the cached values and returns them
13:11 < lares> I'm working on the easy on right now.. the actual rotate code. the intergration is going to be the harder part.
13:12 < pcjc2> Or whether the (world_)get_..._bounds() functions should be a stub, which reads the cached value, and returns it.
13:12 < cnieves> dj: http://www.seul.org/pipermail/geda-dev/2006-December/001634.html
13:12 < pcjc2> Patrick, I guess you're mostly right there, but there are a few cases I ran into
13:12 < cnieves> dj: what are the steps to reproduce it?
13:12 < pcjc2> Component updating is one, I was not sure if there were others
13:13 -!- Cesar [~Cesar@xxxxxxxxxxxxxxxxxxxxxx] has left #geda []
13:13 < pcjc2> I recall having gschem appearing to work prefectly, even when caching complex object's bounds, however I wasn't 100% convinced
13:14 < pat> pcjc2: ideally we should have world_get_.._bounds() for every type as now (that is returning the bounding box) and a o_recalc() that select the previous world_get_..._bounds() for correct type and update the object's left, top... members
13:14 < pcjc2> what about invisible text.. does turning that on and off change the apparent bounds of a complex.. does it matter?
13:15 < pcjc2> Patrick: That was where I initially disagreed - and so my patches do it differently. But I've not been able to resolve the issue in my head entirely
13:15 < pat> pcjc2: but it is not really convenient to add a type check in o_recalc() (we do not have classes)
13:15 < pcjc2> o_recalc() is gone in my code
13:15 < pcjc2> (I make that statement from memory.... its been a while since I actually read it!)
13:15 < pcjc2> There is nowhere we need to perform a generic recalc for a generic object
13:16 < pat> pcjc2: would it be possible to have a full patch or tarball of your tree? I had a look at git but failed to understand it enough to get your branch
13:16 < pcjc2> since the code has moved to using world coordinates, no external event can cause the object's internal state to need updating
13:16 < pcjc2> I'd be happy to send you that. I'll need to get straight in my head what to send, and where the patch ought to base off
13:17 < pcjc2> http://www.srcf.ucam.org/~pcjc2/geda/gitweb.cgi?p=pcjc2.git;a=shortlog;h=precvs-noscreen_mergetest3
13:17 < pcjc2> If you take a look there, you may be able to see the commit log up until fairly recently, and it has the advantage of being separate patches still
13:18 < pcjc2> the branch I'm working on at the moment is precvs-noscreen_mergetest3
13:18 < pat> pcjc2: what I meant is: 1/ o_recalc() asks for the bounding box and update objects members (something that is common to all objects) 2/ world_get_.._bounds() computes and returns the rectangle
13:19 < pcjc2> ok, but world_get_.._bounds() would then only really need to be called from the o_recalc() code, and that code would need to type-check and call the right function
13:19 < dj> Are we having fun yet?
13:20 < peterbrett> What libgeda needs is a distinction between the functions that comprise the "public" interface, and the functions used internally that are subject to change.
13:20 < pat> pcjc2: thanks
13:20 < peterbrett> In fact, an actual design would be good.
13:20 < cnieves> dj: did you see my previous question?
13:20 < pcjc2> peterbrett: harsh
13:20 < pcjc2> harsh, but I'm also of the opinion that it needs some architectural re-factoring
13:21 < pat> pcjc2: o_recalc() or whatever you name it (maybe something with update would be better) is public
13:21 < dj> about reproducing the zoom thing?
13:21 < cnieves> dj: yes
13:21 < dj> ve
13:21 < dj> view extents
13:21 < pcjc2> Patrick: what might be useful for me to send you, is a tarball of the outstanding patches which make up the difference between the end of that git repo, and where I'm attempting to get to
13:21 < pcjc2> Patrick: What public use could there be for o_recalc()
13:21 < dj> I sent the patch to make it 100% to Ales
13:21 < pat> pcjc2: I am with you on the need for some architecture refactoring
13:22 < pcjc2> I believe I've stripped out all need for it
13:22 < cnieves> dj: ok.. then I won't worry about it.
13:22 < pat> pcjc2: depends on what you really call public
13:22 < pat> pcjc2: it may indeed not be necessary for gschem but within libgeda is ok
13:23 < pcjc2> depends on our design though
13:23 < pat> pcjc2: of course :)
13:23 < dj> It really should have a .gafrc entry to specify it, though.
13:23 < pcjc2> As I understood it, all operations which move an object, or whatever, are within the object's "class", eg. o_line_translate()
13:24 < pat> pcjc2: indeed I would be interested on a tarball of the patches
13:24 < peterbrett> pat: I think pcjc2 has a public git tree somewhere
13:25 < pat> peterbrett: yes but I do not "speek git" enough yet and gitweb is not really convenient for an overall view
13:25 < pcjc2> peterbrett: I sent the link.. I was referring to the patches which I've not applied onto that git branch. I had a working branch, from which I spat out a series of patches, and have fixed, and re-ordered them onto a new branch
13:25 < peterbrett> pcjc2: never mind
13:25 < pat> we should not even see this o_line_translate()
13:25 < peterbrett> pat: You'd probably get a better view if you downloaded his git repo and used gitk to view the changes graphically
13:26 < pcjc2> Patrick... what I can do, is spit out the git-history as a numbered series of patches
13:26 < pcjc2> there are a handful which are still causing me a headache to refactor, like this bounds caching stuff
13:26 < pat> when you translate an object you should call o_translate() and this function is in charge of the calling o_recalc()
13:26 < pcjc2> I disagree
13:27 < pcjc2> you should call o_translate_world(), which picks the right type of object, and calls e.g. o_line_translate_world()
13:27 < pcjc2> I would have thought o_line_translate_world() is incharge of updating its cached bounds
13:27 < pat> yes of course the _world() one
13:27 < pcjc2> _world() wasn't my main point..
13:28 < pat> this is the way it is done now but I think it would be better this way
13:28 < pat> I understood
13:28 < pcjc2> I'd expect to be able to use a more specific set of functions, like o_line_translate(), perhaps from within the line code, and not have to worry about the bounds being left out of date
13:29 < pat> we have an object OBJECT that is derived into a LINE, the bounding box is something from the OBJECT side (common to all objects)
13:29 < pcjc2> what would be nice is a better class system of course, where as you imply, the "base" class has the common code, and the higher classes just over-ride specifics
13:29 < pat> from within the line code you are in a private domain, you can call o_line_translate() if you want
13:30 < pat> but anything outside should see an OBJECT only
13:30 < pcjc2> but that call must update the OBJECT's cached bounds
13:30 < pcjc2> even if it does so by calling an OBJECT specific routine
13:30 < pat> then it is your responsability to update the bbox when using o_line_translate()
13:30 < pat> directly
13:30 < pcjc2> but I don't see the point in it calling o_recalc(), to call into the LINE code, to update the cache
13:31 * rikster is away: Ordering breakfast, back in 5 min
13:31 < pcjc2> in that case, any translation automatically keeps the bounds up to date
13:31 <@Ales> rikster: I applied your patch btw, thanks
13:31 < pat> the point is there is only one point in the code where you actually modify an object bounds
13:31 < pcjc2> where is that....
13:32 < pat> in o_recalc()
13:32 < pat> (it really needs a better name BTW)
13:32 < pcjc2> as I said above, if it is the responsibility of o_line_translate() to update the bbox, I'm not sure it should be necessary to call o_recalc
13:33 < pat> yes :) but my point is in moving the update of the bbox out of o_line_translate()
13:33 < pcjc2> I jump out of the LINE specific code, to OBJECT specific code which simply looks up what type of object I am, and re-enters the LINE specific code
13:33 < pat> right
13:34 < pcjc2> since LINE "derives" from OBJECT, it shouldn't be a problem for LINE code to alter OBJECT data
13:34 < pcjc2> I think I see what you're getting at though.....
13:34 < pat> yes but LINE alters OBJECT, NET alters OBJECT, COMPLEX alters OBJECT... all in the same way
13:35 < peterbrett> dj: did you apply my patch to make \_ work as expected in PCB net names?
13:35 < pat> bbox caching is something of OBJECT
13:35 < pcjc2> keep world_get_line_bounds() to actually work out the line bounds from the line specific geometry
13:35 < dj> maybe...
13:35 < pcjc2> then have o_get_bounds() or similar, use its cache
13:36 < pcjc2> that doesn't seem to fit with OBJECT being the base class
13:36 < dj> could you point me at it?
13:36 < pat> world_get_line_bounds() takes a LINE object and returns a bounding box
13:36 < pcjc2> it seems more like a superclass of OBJECT, which adds the caching to an implementation which isn't aware of it
13:37 < pat> o_recalc() calls world_get_line_bounds() when it has a LINE object
13:37 < pat> and stores it
13:37 < pcjc2> Patrick: world_get_line_bounds() takes a LINE object and returns a bounding box, .... not from the cache, you mena
13:37 < pat> yes
13:38 < pcjc2> so the LINE implementation is aware of the caching, in that it knows to call o_recalc() to keep the underlying cache correct
13:38 < pat> and you have a third function that returns the cached bbox, your o_get_bounds()
13:39 < pcjc2> I see the desire for the o_get_bounds(), it is what world_get_single_object_bounds() does at the moment (name could be a little simpler)
13:39 < pat> sorry if I am not clear, I am going to write a small example file
13:39 < pcjc2> Well... its what that function does in my code
13:40 < pcjc2> I think you're being clear, I'm just unsure as to how the "inheritance" works
13:40 < pcjc2> it would be useful to keep caching separate, so that we may do different things in the future anyway... we may want to kill the cache some time in the future
13:41 < pcjc2> so when I would have updated the cache'd bounds in my LINE code, I'm essentially calling a callback (o_recalc() as you say), to tell interested parties that the bounds of the LINE object have changed.
13:42 < pcjc2> The interested party, in this case, is simply the bounds caching code, which can now ask me my bounds (which I calculate and return), for storing in the object's cache
13:44 < pcjc2> The other possible implementation... as I was alluding to earlier wouldn't really regard it as a "cache" at all. This is where I've been leaning towards.....
13:44 < pcjc2> The bbox is a property of the OBJECT, pure and simple. There is an OBJECT level function to retrieve it.
13:44 < pcjc2> And each derrived type from OBJECT, e.g. LINE, will fill in this value as necessary.
13:45 < pcjc2> This doesn't break inheritance, it should be fast, and requires no callbacks.
13:46 < pcjc2> The derived objects do not have any get_..._bounds() functions, just a "o_..._recalc()" which knows how to update the OBJECT structure specific to this object. "o_..._recalc()" is only ever called internally to the derived object, and exists to avoid code duplication within that object.
13:47 < pcjc2> Ales... have you been following this debate? It sounds like a fairly religious architectural point... what are your thoughts?
13:48 < pcjc2> Patrick: I'm sorting out that patchset for you now
13:48 < pat> any one can help me share a file?
13:48 <@Ales> peter: no I haven't been following the discussion. I've been fixing bugs. :)
13:49 <@Ales> could I get a summary in two sentences from both sides?
13:49 <@Ales> choose your words wisely. :)
13:50 < pcjc2> There are two options, I'll present both as I see them, and I'm sure Patrick will do similar:
13:52 < pcjc2> 1) BBox is the responsibility of the OBJECT implementation, it is updated by an OBJECT level function which finds what type of derived object we're dealing with, calls its world_get_..._bounds() function, and caches the result. It is the responsibility of any function which changes the BBox to call an OBJECT level function, o_recalc() which will retrieve the bounds, and then store in the cache. o_get_bounds() returns the cached value, always.
13:54 < pcjc2> 2) BBox is part of the OBJECT's data-structure, but is updated from within the derived object implementation directly, no OBJECT level function exists to update the BBox for a given object, it is always up-to-date. no world_get_..._bounds() functions exist, the only entry point is o_get_bounds(), which returns the stored values from the OBJECT data structure.
13:54 -!- rikster [~rik@xxxxxxxxxxx] has quit [Ping timeout: 622 seconds]
13:55 < pcjc2> Options 2) retains o_..._recalc() as an INTERNAL function, to update the OBJECT data-structure's BBox when other internal functions modify positional data.
13:56 < cnieves> mike: did you see http://sourceforge.net/tracker/index.php?func=detail&aid=1568155&group_id=161080&atid=818426 ?
13:56 < pat> please see http://www.pastebin.ca/349358 for what I would like to have
13:56 <@Ales> okay, in choice #2 ah, so its o_..._recalc that figures out the BBox
13:57 <@Ales> I've read over the two choices, and I can't see a clear winner
13:57 <@Ales> I would want to avoid a "patchwars" though
13:57 < pat> what I propose is #1
13:57 < lares> rand()%2
13:58 <@Ales> isn't option 1 basically how we do things today?
13:58 < pat> the problem with this option is the two switch that are not nice
13:58 < pat> ok wait let me read it again :)
13:59 <@Ales> maybe I'm wrong, since I haven't looked at this particular code recently
13:59 <@Ales> yeah, I'm probably wrong
13:59 < pat> Ales: no I do not think so, the bbox is updated in every translate functions (in o_line_translate in the example above)
14:00 <@Ales> ah okay
14:00 <@Ales> ah, yes "object level function"
14:01 <@Ales> long story short here is a summary:
14:01 <@Ales> For option 1) a generic object level function updates the BBox (which means it needs to know about all the types right)?
14:01 <@Ales> For option 2) the derived types update the bounding boxes
14:02 <@Ales> For option 1) would it still call derived type functions to calculate the bounding box?
14:02 < pat> that is correct
14:02 <@Ales> okay, next question, why do we need a generic object level function to calculate the bounding box?
14:02 < pat> yes it still call get_line_bounds()
14:03 < pcjc2> sorry, haven't been watching... will catch up shortly
14:03 <@Ales> I understand.
14:03 < pat> to factor out the caching of the bbox
14:03 < pat> and be more object oriented
14:03 < pcjc2> Patrick: Patches at www2.eng.cam.ac.uk/~pcjc2/geda/patches_for_pb.tar.gz
14:03 <@Ales> but we would still be caching the bbox right?
14:03 < pcjc2> of course, everyone is more than welcome to download and look at those.
14:04 <@Ales> btw, could somebody update gschem and run autogen.sh and ./configure
14:04 < pat> pcjc2: thank you I have them now I will look at them and let you know
14:04 <@Ales> I added a call to a macro go get rid of a bunch of warnings
14:05 <@Ales> isn't updating the bounding box a derived object type operation in general?
14:05 <@Ales> who would call this generic object level function?
14:05 < pcjc2> Ales: I'm of the opinion it is - especially if we don't call it a "cache" anymore
14:06 < pcjc2> Ales: That was my only objection to Patrick's option #1, that the generic object level function isn't needed publicly, it is only _ever_ called from the derived objects - and it calls back into that same derived object to get the bounds
14:07 < pat> bbox is only one part of the problem. The real point is: do not use o_line_translate() anywhere in the code but in o_line_basic.c
14:07 < pat> only use o_translate()
14:08 < pat> and this is o_translate that is in charge of computing and caching the bbox
14:08 < pcjc2> we needn't necessarily move the bounds calculation into o_..._recalc(), if there is any desire to remove the "cache'd" bounding box, it could stay in o_..._get_bounds(), as an INTERNAL function, then o_..._recalc() could update the BBox with a stub call to that internal function
14:08 < peterbrett> dj: http://sourceforge.net/tracker/index.php?func=detail&aid=1617287&group_id=73743&atid=538813
14:08 < pcjc2> I agree with only using o_translate() from outside libgeda
14:09 < pcjc2> Patrick: are you now saying that OBJECT level, o_translate() should update the bounding box of the object, after calling the derived LINE function, o_line_translate(),
14:10 < pat> o_translate() should call o_recalc() after translate to compute and cache the new bounds
14:11 < pcjc2> Ok, sorry Patrick - just re-read your pastebin, makes it clear
14:11 < pat> anyway I will have to go (dinner time here). Is it planned to archive the discussion here? Not sure I will be able to re-join after
14:11 < pat> yes I think the best way to explain is pseudo code
14:12 < pcjc2> Patrick: Just to be clear, I'm not _opposed_ to your way... it was the very fact that I couldn't decide a clear winner that I wanted to have a discussion with all involved before re-jigging those remaining patches
14:13 < peterbrett> pat: How soon are you going to be able to merge your changes to the way libgeda selections work?
14:13 < pat> pcjc2: no problem you are free to be opposed :)
14:13 < pat> peterbrett: in fact I am likely to ditch my changes in favor of your proposition
14:14 < pat> peterbrett: I like the iterator thing and had previously thought of adding iter to attributes list
14:14 < peterbrett> pat: Have we decided whether or not selections should live in gschem or libgeda?
14:14 <@Ales> pat: yes I will post the log file
14:14 < peterbrett> pat: Only gschem using them at the moment
14:14 < peterbrett> Ales: I'm already logging, will make available
14:14 < pcjc2> Patrick: if you have a minute, I think I have one argument which may favour my proposition, that is thinking about how it would work if we had a _true_ object oriented system
14:14 < pat> peterbrett: what would be really nice would be to share the iter between the two lists
14:15 <@Ales> my irc session which is always active, always logs. :)
14:15 < pat> Ales: good
14:15 < pcjc2> If it were truly OO, there would not be a "o_line_translate", simply o_translate(), which the LINE class would over-ride
14:15 -!- rikster [~rik@xxxxxxxxxxx] has joined #geda
14:16 < pcjc2> similarly, there would just be o_get_bounds()
14:16 < pat> pcjc2: there would be a function that overrides o_translate for line object (basically o_line_translate)
14:16 < pcjc2> so.. there would be a clash between the cached version specific to the object, and any object specific function which actually computes the BBox
14:16 < pat> pcjc2: and there would be one overriding a world_get_bounds() (world_get_line_bounds)
14:17 < pcjc2> indeed, but if still keeping a cache / copy of the BBox in the OBJECT class, the overridden world_get_bounds function would have to return that
14:17 < pat> pcjc2: you may think of translate and get_bounds() more as interface functions
14:18 < pat> but o_translate() is the real entry point in the translation operation
14:18 < pcjc2> in this code, the interfacing function gets called first, taking specialism from the derived types (by explicitly knowning about them, which is also bad)
14:18 < pcjc2> Considering o_get_bounds(), your OBJECT level, interface function is just returning the cached value
14:19 < pcjc2> But the (say) LINE specific implementation is doing computation for the BBox. At the very least, they are not the same function - we don't override the caching implementation with a computing operation
14:19 < pcjc2> it would be o_line_compute_bounds(), for example, and o_get_bounds() would not be over-ridden
14:22 < pcjc2> to elaborate further, to do your way with real classes, there would be a (virtual?) function, o_compute_bounds() which the LINE implementation provided / over-rode, and o_get_bounds() would return its local cached value. o_update_bounds() would use o_calculate_bounds(), and by merit of the virtual function, it wouldn't need to do the switch() to determine which implementation to call
14:22 < dj> peterbrett: it's in. I had to patch parse_l.l too; do you have a temp patch from me that lets you read quoted names?
14:22 < peterbrett> No...
14:23 < dj> I edited a .pcb file to have abc\_def in it, and pcb choked.
14:23 < peterbrett> dj: Even with the patch? Weird. The patched version worked perfectly for me. Never mind.
14:23 < dj> The patch lets you quote pretty much anything on input, but if you're only giving it \\_ it wouldn't have noticed.
14:23 < dj> The bug was in *reading* pcb files, not *writing* them.
14:24 < pat> I will think about that, I really have to go now, see you later
14:24 < peterbrett> dj: The problem I was getting was that it loaded the netlist fine, but when it wrote it back out it was dropping the \'s.
14:24 < pcjc2> Bye,
14:24 < peterbrett> dj: So I had to hand edit them back in.
14:24 < pcjc2> it was good to chat about this with everyone... I've been waiting for the oportunity
14:24 < peterbrett> With my patch, it correctly output them again.
14:24 < pat> bye for now
14:24 < peterbrett> dj: But anyway, if it's fixed that's good :)
14:24 -!- pat [~pat@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx] has quit [Quit: [BX] Mr. Peanut uses BitchX. Shouldn't you?]
14:24 < pcjc2> I will have to go too within about 1/2 hour
14:25 < mike> Ales: I have the patch to scale the output postscript text ready to commit.
14:25 < dj> I think you just weren't tripping over the problem because of the input you were choosing to give it.
14:25 < peterbrett> I'll need to go soon too
14:26 < rikster> Proposal: move always-promote-attributes from gafrc to gschemrc
14:26 < rikster> Can we move always-promote-attributes from the gafrc to join the other attribute promotion keywords in gschemrc?
14:26 <@Ales> rikster: the only reason it's in there is because other programs might need it as well
14:27 <@Ales> mike: commit away :)
14:27 <@Ales> mike: do you know why the text size changed though?
14:27 -!- dj [~dj@xxxxxxxxxxx] has quit [Quit: Leaving]
14:27 < rikster> Is that definitely the case? If so, why aren't the other attribute promotion keywords in gafrc and not in gschemrc?
14:27 -!- dj [~dj@xxxxxxxxxxx] has joined #geda
14:28 < dj> wrong button
14:28 < mike> Ales: I probably did not apply the same scaling factor that you were using with the postscript fonts. But to my eye things looked fine.
14:28 <@Ales> rikster: that's a very good point.
14:29 <@Ales> could you file a bug on this
14:29 < mike> Ales: others must have wanted slightly larger text.
14:29 <@Ales> okay
14:30 < rikster> I'll file a bug and a patch to fix it.
14:31 < rikster> I know I had a hard time understanding attribute promotion at first because I read through the gschemrc and thought I understood all the controlling switches but couldn't figure out why some attributes were still being promoted.
14:32 <@Ales> yeah, I wrestled where to put it and I probably didn't pick the right spot
14:33 <@Ales> ideally I would want to get rid of gschemrc, gnetlistrc etc... and have only one file (gafrc).
14:33 <@Ales> that was sorta the plan all along
14:33 < peterbrett> Ales: http://repo.or.cz/w/geda-gaf.git
14:34 <@Ales> is that a git mirror of gEDA cvs?
14:34 < peterbrett> Yep, this one's on 12-hour updates
14:34 < pcjc2> what was the frequency of the old one?
14:36 < peterbrett> 6 hours
14:38 < pcjc2> how CPU / network intensive is the update... is there a reason to make it slower?
14:38 < pcjc2> I only ask, as my workflow is to prepare patches for CVS locally, based ontop of git's idea of CVS
14:39 < pcjc2> the commit to CVS, and merge the "precvs_..." branch in git up to date with CVS (basically that is a trivial merge, as both are the same by this point)
14:39 < peterbrett> I'll speed it up to 3 hours if you want
14:40 < pcjc2> if it doesn't eat too much network traffic on srcf / seul, that would be handy
14:40 <@Ales> how much pain does that cause to our server?
14:40 < peterbrett> That's the other issue
14:40 <@Ales> cvs isn't the most memory friendly program
14:41 <@Ales> how often does it really have to run?
14:41 < peterbrett> What it does is to log everything, starting from the date/time it was last run
14:41 < peterbrett> So it's pretty abusive
14:41 < peterbrett> That's why it would be nicer to have it run as a post-commit hook, so that it only runs when it needs to
14:42 < peterbrett> It takes approx. 1 min at the moment
14:42 < pcjc2> if it is a problem, then 12 hours is fine.. I keep an eye on the CVS mailing lists anyway, so I can see if there is more up-to-date stuff in CVS than in git
14:43 < peterbrett> I've set it for three hours at the moment. If it becomes a problem for either SRCF or SEUL, I'll tone it down
14:43 < peterbrett> How does that sound?
14:43 < pcjc2> how easy would it be for seul to run the post-commit hook, and just shove a copy of all changes to repo.or.cz
14:43 < pcjc2> its not quite hosting a git mirror, and would make everything a lot more responsive
14:43 <@Ales> if it can be limited to the geda repository then that should be okay
14:43 < peterbrett> I've never implemented a post-commit-hook, so I don't know
14:44 <@Ales> it'll be harder to do such things if we migrate to sf or others
14:44 < peterbrett> Ales: MUCH harder.
14:44 < mike> Ales: I finished the commit. I have to do an update and build again though.
14:45 < pcjc2> Peter: your git repo still doesn't show me a tag for noscreen-base
14:46 < peterbrett> pcjc2: I think that might be a cvsps bug
14:46 < peterbrett> If you know which commit it is, why not just add it to your local repo directly...?
14:46 < pcjc2> http://cvs.seul.org/viewcvs/viewcvs.cgi/eda/geda/gaf/?only_with_tag=noscreen-base
14:46 < pcjc2> It will change as any merges take place in CVS
14:47 < pcjc2> for example, if I merged up with later CVS changes, that tag should be moved (If I remember Dan's faq correctly)
14:47 < pcjc2> I have to go now anyway.. my girlfriend just arrived.
14:47 <@Ales> mike: thanks, I'll build too
14:47 < peterbrett> pcjc2: I'm afraid I don't have a solution for that
14:47 < peterbrett> pcjc2: Have a nice evening
14:47 <@Ales> see ya PeterC
14:48 < pcjc2> Ales: I hope you see now why / where I'm stalled with my patches. There is no clear correct solution
14:48 < cnieves> bye PeterC
14:48 <@Ales> peterC: yup I understand
14:48 < pcjc2> Perhaps we might get together, and discuss it further at some point. - If we can find a time Patrick's about too, and anyone else interested
14:49 <@Ales> agreed
14:49 < pcjc2> I'll stay online, so I can read-over the comments before the log is posted - but won't be about to repond
14:49 <@Ales> there.. fixed a bunch more warnings in the code
14:49 < pcjc2> bye all!
14:55 < rikster> Proposal: clear refdes option for grenum or refdes_renum
14:57 < rikster> I often run the netlister early in the design cycle to get a pin and net count for PCB layout estimation purposes. In order to do that I need to number the reference designators. These aren't the final designators I want so I clear them before I make my final output netlist. Would an option to clear existing refdes'es be useful?
14:58 < sdb> I belive refdes_renum just trashes the old refdeses.
14:58 < sdb> Therefore, you can use use it to overwrite your refdeses.
14:59 < sdb> I have thought about adding a --gentle flag to refdes_renum to
14:59 < sdb> prevent refdes overwriting.
14:59 < sdb> Anyway, this may not be exactly what you want, but perhaps provides a work-around?
15:00 < rikster> It does trash the old refdeses which is fine for my purposes. My ulterior question is which program should I be working on? grenum or refdes_renum? I'm very comfortable with perl and could update refdes_renum to add an option to behave like grenum and not blow-away existing refdes'es. Then refdes_renum would have the best of both worlds.
15:01 < mike> I have to be off now too, as it's time to shovel the driveway.
15:01 < dj> amusingly enough, it's dry and sunny here in New England.
15:02 < mike> It's sunny here too, but I have been lazy over the last few days... and the accumulation is getting to 10cm.
15:02 < mike> (4 in)
15:02 -!- al [~al@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx] has joined #geda
15:02 < rikster> (4000 mil) for board designers
15:02 < al> does this work?
15:03 <@Ales> no. :)
15:03 <@Ales> Hi Al
15:03 < dj> Hi Al
15:03 < al> ok ..that was easy.
15:05 < cnieves> hi al
15:09 < rikster> No responses? Is that a vote for updating refdes_renum to have a no-delete-existing-refdes option?
15:09 < dj> John's working on something in refdes_renum...
15:12 < rikster> I'll code up a patch and submit it tomorrow.
15:13 <@Ales> a patch to do what exactly with refdes_renum?
15:14 < rikster> To add an option which doesn't destroy existing refdes'es.
15:15 < rikster> Instead, it will number around the existing refdes'es as grenum does now. This is very useful for a component that has been added after the original netlist has gone to layout.
15:18 -!- rikster [~rik@xxxxxxxxxxx] has quit [Quit: Thanks everyone. Off for some ice skating.]
15:21 <@Ales> Please do not use // comments in C code. thank you. :)
15:44 < Bert> Goodnight :) signing off
15:44 < dj> Bye
15:44 -!- Bert [~e234574@xxxxxxxxxxxxxxxxxxxxxxxxxxxx] has quit [Remote host closed the connection]
16:41 -!- werner2101 [~Werner@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx] has quit [Quit: Konversation terminated!]
16:47 < cnieves> guys, I'm leaving. Thank you for joining this code sprint. I think it beated the record of the most crowded one!. I hope it was as funny for you as it was for me!
16:47 < cnieves> Hope to see you in the next one!
16:48 < mike> Thanks! I will be going now too.
16:48 < cnieves> bye!
16:49 < dj> bye!
16:50 <@Ales> see ya carlos!
16:50 <@Ales> thanks for all the checkins
16:50 <@Ales> see ya mike too and thanks for all the fish oh wait.. checkins
16:51 < mike> I hope they were mostly harmless.
16:51 < mike> :-)
16:54 <@Ales> we shall see. :)
16:54 <@Ales> new release is scheduled for 20070216
17:00 -!- cnieves [~cnieves@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx] has quit [Quit: Abandonando]
17:01 -!- mike [~mike@xxxxxxxxxxxxxxxxxxxxxxxxxxx] has left #geda []
17:02 <@Ales> okay, I'm going to start packing up too
17:07 < dj> I gotta go too...
17:09 <@Ales> later all!
17:11 < sdb> bye!
17:11 -!- sdb [~sdb@xxxxxxxxxx] has quit [Quit: Leaving]
17:15 -!- dj [~dj@xxxxxxxxxxx] has quit [Quit: Leaving]
17:20 -!- robfitz [~robfitz@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx] has joined #geda
17:25 -!- peterbrett [~peter@xxxxxxxxxxxxxxxxxxxxxx] has quit [Remote host closed the connection]
17:29 -!- robfitz [~robfitz@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx] has quit [Quit: leaving]
17:41 -!- robfitz [~robfitz@xxxxxxxxxxxxxxxxxxx] has joined #geda
18:01 -!- lares [~lares@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx] has quit [Quit: leaving]
18:36 -!- al [~al@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx] has quit [Quit: Leaving]
20:23 -!- jegc [~jegc@xxxxxxxxxxxxxxx] has joined #geda
20:35 -!- jegc [~jegc@xxxxxxxxxxxxxxx] has left #geda []
23:17 -!- igor2_off [~igor2@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx] has joined #geda
23:19 < igor2_off> hi
--- Day changed Sun Feb 11 2007
_______________________________________________
geda-cvs mailing list
geda-cvs@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-cvs