#emc-devel | Logs for 2007-03-05

[00:34:53] <steves_logging> steves_logging is now known as steve_stallings
[00:36:35] <steve_stallings> Have not fully caught up reading, but want to comment on spindle at speed feedback. My opinion - M3, and M4 should delay until at speed, otherwise spindle not running at commanded speed is an eStop event.
[01:35:51] <roltek> hi guys was reading what went on today and see you have a feed rate override on rapid is this true! very dangerous to dynamics on machine tool
[01:38:16] <SWPadnos> roltek, it can't increase the rapid speed, since G0 is already at the MAX_VEL specified in the ini file (and FO will never cause a move exceed that)
[01:39:03] <roltek> that's not what they were saying earler
[01:39:12] <SWPadnos> I think it is
[01:39:34] <roltek> feed rate override affects go and go1 in same way
[01:39:57] <petev> roltek, have you used any controls where the rapids were effected by the same FO as for feed?
[01:39:59] <SWPadnos> yes, but in all cases, the requested rate is clamped to the max set in the ini file
[01:40:32] <petev> SWPadnos, where is the check done?
[01:40:39] <SWPadnos> in the TP
[01:40:49] <petev> so motion knows nothing about it?
[01:41:06] <SWPadnos> it never exceeds the max accel and vel set for each axis in the ini, and the check is done after the scale factor is applied
[01:41:22] <SWPadnos> doesn't motion contain the TP?
[01:41:25] <roltek> on machine controls rapid nobs have 100% 50% 25% and f0 which is stopped
[01:41:35] <petev> so motion is looking at the INI settings for the AXIS section
[01:43:16] <SWPadnos> err - wherever the TP is, that's where it happens
[01:43:35] <SWPadnos> and since the TP is the last thing before the HAL position output pins (I think), it all works out
[01:43:40] <petev> I thought the TP was doing higer level
[01:43:52] <jmkasunich> task is higher level
[01:43:53] <petev> and motion was interpreting between the points generated by the TP
[01:44:07] <SWPadnos> well, it's likely I'm labeling something incorrectly. I do that a lot where the TP and motion are concerned
[01:44:15] <jmkasunich> task sends things like "line" and "arc" to motion
[01:44:33] <petev> what is the servo rate interpolation called?
[01:44:46] <jmkasunich> motion handles lots of commands, but "line" and "arc" and a couple others are passed by motion to TP (part of the motion module)
[01:45:18] <jmkasunich> interpolation is just another part of motion
[01:45:53] <petev> ok, I guess I always viewed the low level servo rate stuff as motion, and the higer level as TP
[01:46:39] <petev> so do the arc and line commands that are sent to motion contain any info about what generated them?
[01:46:40] <SWPadnos> there isn't a lot of high level "planning" in EMC - there's no many-segment lookahead, multi-segment blending, etc (AFAIK)
[01:46:49] <jmkasunich> basically, "motion" is motion.c (setup and init, no runtime stuff), command.c (handles commands coming from task), control.c (does the actual realtime control) and things in the kinematics directory, including tp.c and friends (the actual trajectory planner), called by control.c
[02:02:49] <roltek> jmk you still here
[02:03:07] <jmkasunich> no?
[02:03:13] <roltek> ok
[02:03:23] <jmkasunich> whats up?
[02:04:11] <roltek> i have an extra book on fanuc lathe control should i send it to you or chris
[02:04:19] <jmkasunich> not me
[02:04:25] <roltek> ok
[02:04:43] <jmkasunich> my main area is the guts of the motion control, and device drivers
[02:05:36] <roltek> just trying to help with good g code
[02:06:56] <jmkasunich> its appreciated
[02:07:06] <jmkasunich> I'm just not the guy to talk to about g-code
[02:07:16] <jmkasunich> I think cradek is around
[02:07:25] <jmkasunich> maybe he'll pop his head up
[02:07:26] <cradek> roltek: I think I'd be the best person to get it, nobody else has done any of the lathe work
[02:08:12] <cradek> roltek: thanks for the offer - that stuff is hard to find without contacts
[02:09:04] <roltek> i just sent you an e-mail for an address
[02:09:19] <roltek> i'll get it out tomorrow
[02:10:01] <cradek> response on the way, thanks again
[02:11:10] <roltek> see you later guys
[02:21:31] <petev> any body care to give me their opinions on the source dir structure for the higher layers under the emc dir?
[02:21:50] <SWPadnos> as in "are they any good?
[02:21:56] <SWPadnos> or "where is stuff"
[02:22:03] <SWPadnos> or "how can I cahnge them"
[02:22:25] <petev> I don't really follow the structure and it seems as if many files are C++ just to use RCSLIB
[02:22:33] <petev> the code inside is C code
[02:22:47] <petev> and the naming conventions don't seem to be anything standard
[02:22:58] <SWPadnos> I think a lot of the high end stuff is C++ (RCS/NML, etc, also parts of the interp and the ini file handling)
[02:23:14] <petev> headers don't match implementation name and function and var naming is totally inconsistent
[02:23:17] <SWPadnos> no - I think this is a very good example of very bad CPP code
[02:24:00] <petev> the shared headers for interfaces should either be in the emc dir (like for hal) or an include dir
[02:24:13] <petev> I find the code a bit hard to follow
[02:24:45] <SWPadnos> I suspect there are still some vestiges of the old system, which would create an include dir and copy .h files from all the various subdirs into it
[02:24:57] <SWPadnos> I think it's very hard to follow
[02:25:14] <petev> is the main resistance to changing things because it's such a pain with CVS?
[02:25:15] <SWPadnos> just a map of what is where (as I think you're looking for) isn't trivial
[02:25:24] <SWPadnos> I don't think so
[02:25:41] <petev> is cradek running the CVS server now?
[02:26:02] <SWPadnos> I suspect it's (a) lack of absolute necessity and (b) concern for unseen changes (bugs)
[02:26:16] <SWPadnos> sort of. it's at jeplers place, I think
[02:26:35] <petev> hmm, but this code realy needs to be understood and fixed in order to fix other things we discussed
[02:26:55] <petev> I have been using svn for quite some time and moves/renames are easy
[02:27:09] <SWPadnos> agreed. unfortunately, it's not very fun figuring it out, so without massive need, it doesn't get done
[02:27:11] <petev> but I hate to see all the old revs be lost if a switch were made
[02:27:28] <SWPadnos> I don't think we'll be moving to svn any time soon - just from conversations about it
[02:27:45] <petev> I would be willing to take a shot a re-organizing it and making things into proper C++ classes
[02:27:46] <SWPadnos> I can do svn on the same host that does linuxcnc.org
[02:27:54] <petev> but I think it will be hard with CVS
[02:28:15] <petev> I'll be bugging someone to make changes on the server all the time
[02:28:52] <SWPadnos> there is the possibility of making a new module, (like emc3 or something) but that would definitely need discussion first
[02:29:05] <SWPadnos> what's your schedulr around June 11-17?
[02:29:10] <SWPadnos> schedule
[02:29:26] <petev> nothing planned right now, but I rarely know that far in advance
[02:29:30] <SWPadnos> heh
[02:29:41] <SWPadnos> that happens to be CNC workshop and EMC fest time
[02:29:47] <SWPadnos> (in Galesburg, IL)
[02:29:53] <petev> hmm
[02:30:32] <SWPadnos> there are cheap hotels, and I can likely give you a ride from an airport (like O'Hare or Peoria)
[02:31:12] <petev> That might be interesting, my dad and brother are still in IL
[02:31:20] <SWPadnos> cool
[02:31:21] <petev> but it's a bit far off for getting this stuff fixed
[02:31:28] <SWPadnos> yeah, I guess so
[02:32:05] <SWPadnos> I don't think you'll find many objections to an at-speed pin, which is in effect feedhold (though there may have been implementation problems with that(
[02:32:26] <SWPadnos> everything else being done in ladder/HAL for now
[02:32:27] <petev> yes, I think there are
[02:33:02] <petev> for one, I don't think the lower levels of motion know the diff between G0 and G1, 2, 3 moves
[02:33:26] <petev> then there is the whole pre-conditions and where they should be specified
[02:33:45] <petev> would be nicer for them to come from above like they do for other stuff
[02:33:48] <SWPadnos> for a first shot, is it unacceptable to have g0 be held as well?
[02:33:50] <SWPadnos> sure
[02:34:13] <petev> I guess it depends when it's held
[02:34:29] <petev> for sure you can't have it held at all times when the spindle is off
[02:34:49] <petev> so the new input would have to be ignored when the spindle is not on
[02:35:19] <SWPadnos> well, I'd say that the first thing to do is write up some problem description and possible solutions and post that to the dev list. I wouldn't go too far with this without input from the experts
[02:36:09] <petev> I posted something like that yesterday
[02:36:17] <SWPadnos> after some consensus is reached on what to do, there will be less resistance to mucking about with CVS or whatever
[02:36:47] <SWPadnos> ok - I saw something on the subject. I should reread it
[02:37:25] <petev> I could try and make C++ classes out of things now, leaving the file names and dir structure as is, but things will be seriously broken for a while
[02:37:52] <SWPadnos> I don't think you'd get much support for that. broken and C++ are two things that most people around here don't really like
[02:38:32] <petev> well right now there seems to be this pile of code nobody wants to touch
[02:38:40] <petev> myself included
[02:38:46] <SWPadnos> yep
[02:38:58] <petev> but I don't see how we get past this without dealing with it
[02:39:14] <petev> last time I looked at task, the e-stop handling scared me
[02:39:15] <SWPadnos> I agree
[02:39:18] <SWPadnos> heh
[02:39:27] <SWPadnos> well, remember it's not really "E" stop
[02:39:34] <petev> I was very happy to see that get pushed lower
[02:39:42] <petev> it used to be all handled in task
[02:39:51] <petev> and there were plenty of bugs
[02:40:19] <SWPadnos> the assumption was that an estop input was just a courtesy from the hardware, and that the machine would have already been shut down
[02:40:30] <SWPadnos> so timing isn't an issue (though bugs still are, of course)
[02:40:43] <petev> not how it worked in EMC1 and I never saw anybody using hte HW estops
[02:41:11] <petev> I don't think anybody uses the HW support on motenc or m5i20
[02:41:28] <SWPadnos> hmmm. I'm pretty sure that it was always meant to be hardware with a software notification, but that may not have been clear from whatever integrators documentation there was
[02:41:43] <SWPadnos> I'm talking HW as in relays and power removal
[02:41:51] <SWPadnos> not PC based driver cards
[02:41:54] <petev> the standard motenc and m5i20 setups don't use the HW estop
[02:41:56] <skunkworks> couldn't it be done in another branch - like rigid tapping?
[02:42:21] <SWPadnos> moving files around in CVS is a little trickier than making changes to existing files
[02:42:29] <SWPadnos> s/little/lot/ :)
[02:42:42] <petev> another branch would help with the broken part
[02:42:52] <SWPadnos> yes
[02:42:54] <petev> but CVS sux for this kind of stuff
[02:48:19] <petev> what's with the untyped/tagged enums in emc.hh?
[02:54:07] <SWPadnos> are you talking about the "digital IO point indices" (and analog)?
[02:54:25] <SWPadnos> and all the miscellaneous other ones
[02:54:56] <SWPadnos> actually, those are the only ones I see that are untagged
[02:55:52] <SWPadnos> ugh. the code makes my head hurt. I think this cold is getting to me
[02:56:06] <SWPadnos> I'll see you tomorrow - I think it's bedtime for me
[02:58:12] <petev> yes, those
[02:58:15] <petev> gn
[04:42:51] <steve_stallings> steve_stallings is now known as steves_logging
[10:52:42] <alex_jon1> alex_jon1 is now known as alex_joni
[13:05:21] <SWPadnos_> SWPadnos_ is now known as SWPadnos
[14:48:28] <SWPadnos_> SWPadnos_ is now known as SWPadnos
[15:28:32] <steves_logging> steves_logging is now known as steve_stallings
[20:34:04] <petev> I have been looking at the higher level code
[20:34:15] <SWPadnos> uh-oh
[20:34:16] <alex_joni> heh..
[20:34:19] <petev> and I think there may be some steps we can take to make it more manageable
[20:34:28] <SWPadnos> I'd bet on that
[20:34:33] <alex_joni> ask if you have problems in understanding the flow
[20:34:36] <SWPadnos> did you see Matt's email?
[20:34:37] <petev> first I think we can isolate 2 things
[20:34:42] <petev> no, what email?
[20:34:42] <alex_joni> SWPadnos: not yet
[20:34:52] <SWPadnos> on the dev list
[20:34:54] <alex_joni> * alex_joni watches bits dribbling in
[20:34:55] <petev> I'm having problems with my developer email
[20:34:58] <SWPadnos> regarding call trees and stuff
[20:35:08] <petev> no, can you forward it?
[20:35:09] <SWPadnos> http://www.mattshaver.com/include_graphs/+index-by-size.html
[20:35:15] <SWPadnos> http://www.mattshaver.com/include_graphs/index-by-size.html
[20:35:21] <SWPadnos> sorry about the plus sign there
[20:35:26] <SWPadnos> one sec
[20:35:55] <SWPadnos> ok - frowarded it to you (pete)
[20:35:57] <petev> I started some notes of my own I'll share when they are more complete
[20:36:10] <petev> I tried to capture the major important stuff in the flow
[20:36:19] <petev> anyhow, back to the 2 things
[20:36:29] <petev> I think the first is pretty easy
[20:36:44] <petev> I would like to isolate all of the init file reading stuff
[20:36:58] <petev> code is seriously duplicated and there are plenty of memory leaks
[20:37:20] <petev> I think the IniFile class can be extended and then a new EmcConfig class derived from it
[20:37:39] <petev> it should parse the whole INI file and then the config object passed to the other modules
[20:37:43] <alex_joni> petev: while you're at that..
[20:37:50] <alex_joni> http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?IniChanges
[20:37:53] <petev> this will eliminate code duplication and isolate the file format
[20:38:36] <petev> you don't want my thoughts on all that because I would redo it all in xml
[20:38:48] <SWPadnos> that's not out of the question
[20:38:49] <petev> but for now I think some layering and information hiding would help
[20:39:08] <SWPadnos> but it's not very palatable for some folks due to the near-unreadability of XML for humans
[20:39:12] <petev> I didn't get such warm reception to the idea before, so unless things have changed...
[20:39:21] <SWPadnos> things have probably changed a bit
[20:39:27] <petev> there are a bunch of editors that solve that
[20:39:27] <alex_joni> petev: the idea itself is not that bad
[20:39:34] <petev> and do DTD checking as well
[20:39:42] <alex_joni> it would be even better if it's accompanied by a GUI to do configs
[20:39:47] <petev> I already wrote a sample and DTD
[20:40:04] <petev> yes, we could start with off the shelf editor and make custom GUI later
[20:40:13] <petev> ok, the second item is NML
[20:40:19] <SWPadnos> there's a "nearly-XML" format also, which eliminates a lot of unreadable crap by removing end tags and such
[20:40:35] <petev> I know this is touchy, but is there any reason it has to polute the whole code base?
[20:41:03] <SWPadnos> it shouldn't have to, but the ability to do a networked system is pretty central to EMC
[20:41:10] <petev> why can't we isolate it to the communications links between the objects and not get it in the objects themselves?
[20:41:17] <SWPadnos> networked as in I/O, motion, GUI can be on separate machines
[20:41:29] <petev> I'm not saying ditch it, although I would replace it with RPC myself
[20:41:29] <SWPadnos> no particular reason, probably
[20:41:53] <petev> but lets make some clean object boundaris and put all the comm stuff in client/server modules
[20:41:58] <SWPadnos> NML can be used on small (8-bit) microcontrollers. if you have an RPC implementation that can do that, then it may be possible
[20:42:01] <petev> the UIs would like against the client side
[20:42:05] <SWPadnos> sure, that likely makes sense
[20:42:14] <petev> the server side would make calls to EMC objects
[20:42:28] <petev> no NML or RPC or any other comm protocol anyhwere else
[20:42:43] <petev> then it would be easy to use a comm channel or not
[20:43:11] <petev> this second change is a bit larger, but I think it would really improve code readbility
[20:43:36] <petev> after that, I think some real C++ classes are in order to better define the interfaces and get rid of globals and the like
[20:43:44] <petev> what do you guys think?
[20:43:50] <SWPadnos> number two is really two different topics: one is layering / "protocol hiding", the other is removal/replacement of NML
[20:44:10] <petev> I think the NML is still layering/hiding
[20:44:29] <SWPadnos> better layering is a no-brainer for me, removing NML is less so (only due to the fact that it's so interwoven in the code)
[20:44:29] <petev> why is NML needed anywhere but for comm?
[20:44:56] <petev> I only see it being used to talk to task and io, but maybe I missed something
[20:44:57] <SWPadnos> it isn't (I think), but it's so intertwined with everything that changing it is a pain
[20:45:10] <petev> it looks like motion goes straight to the SHMEM already
[20:45:10] <alex_joni> right
[20:45:14] <SWPadnos> it's also usable to talk to remote machines, with different word sizes and endian-ness
[20:45:19] <petev> I think io can be eliminated
[20:45:30] <petev> that only leaves comm between UI and task
[20:45:32] <cradek> alex_joni: that guy is probably not subscribed?
[20:46:01] <alex_joni> cradek: too slow connection to look
[20:46:06] <SWPadnos> if there's a "remote HAL" protocol of some sort, then it could, but having I/O separate from motion/task is pretty central to original EMC thinking (and may still be needed, though I'm not sure)
[20:46:27] <petev> hmm, all IO is HAL based now
[20:46:32] <alex_joni> petev: I somehow favour a major change of ditching io altogether, and moving it into RT
[20:46:49] <petev> I would like to see the NML queue removed and the SHMEM interface made into a queue
[20:46:55] <SWPadnos> what I mean is having some I/O hardware on one computer (or device), and being able to get that data to another computer that's running task/motion ...
[20:46:58] <petev> I think that would eliminate the bottle neck too
[20:47:12] <alex_joni> SWPadnos: use RTnet :P
[20:47:13] <petev> why is that an issue?
[20:47:26] <petev> just run HALUI and it sends NML or RPC to task
[20:47:30] <SWPadnos> RTAI also has FIFOs, but they're not being used (for some reason I don't know at the moment)
[20:47:48] <petev> I also want to fix the plan/execute stuff
[20:47:52] <alex_joni> SWPadnos: but seriously.. how many cases like that have you seen lately (in the last 5 years)?
[20:47:53] <SWPadnos> RTNet schmaRTNet :)
[20:48:03] <petev> plan executes some stuff directly which is just broken
[20:48:11] <duerz> does anyone have any stuff to incororate isagraph? plc??
[20:48:23] <SWPadnos> there's been a raeasonable amount of discussion about the G-Rex or a serial (AVR-based) I/O card for a while
[20:48:54] <SWPadnos> those are both hard with the current scheme, but I'd like to make sure they're no harder in a new scheme
[20:49:11] <petev> both what, I lost you?
[20:49:24] <SWPadnos> ethernet and/or serially connected I/O devices
[20:49:31] <petev> oh
[20:50:04] <SWPadnos> there's been some work on HAL drivers for both types of device, but it's not too easy to work that into the RT system
[20:50:15] <SWPadnos> NML is a partial solution, though it's not RT
[20:52:00] <duerz> isagraf?
[20:52:32] <SWPadnos> never hrard of it
[20:52:33] <alex_joni> duerz: no isagraf
[20:52:34] <SWPadnos> neard
[20:52:39] <SWPadnos> heard
[20:52:44] <SWPadnos> man - I need more caffeine
[20:52:45] <duerz> http://www.isagraf.com/
[20:52:58] <duerz> it will run in linux
[20:53:10] <alex_joni> SWPadnos: the RTnet HAL driver just links together some HAL pins (e.g. replicates tehm on the remote PC)
[20:53:35] <SWPadnos> ok - I haven't looked at it - Eric checked it in though?
[20:53:43] <SWPadnos> (looked lately, at least)
[20:53:59] <alex_joni> not in..
[20:54:04] <SWPadnos> ok
[20:54:03] <alex_joni> sent it as an email to the dev list
[20:54:18] <SWPadnos> ok - I go that one
[20:54:23] <SWPadnos> got
[20:54:24] <alex_joni> the only 9one
[20:54:26] <SWPadnos> right
[20:55:12] <SWPadnos> I'd like for there to be some reasonable replacement for the capabilities that NML gives us in I/O and UI connectivity before throwing NML away
[20:55:30] <petev> I'm not saying throw it away
[20:55:41] <petev> just isolate it like any comm should be
[20:55:46] <petev> I would do RPC the same way
[20:56:04] <SWPadnos> sure - that makes perfect sense
[20:56:06] <petev> at least if it's isolated, it will be easier to understand and maintain
[20:56:55] <alex_joni> petev: one single aspect I'm worried about
[20:56:59] <petev> yes?
[20:57:07] <SWPadnos> one comment on point 1 (config info) - I don't know if you've seen the KDE config system, but they have some very nice provisions for systemwide settings, private settings, immutable settings, etc.
[20:57:23] <alex_joni> that during this cleanup you encounter some technical dificulties (because of libnml architecture) to complete the task
[20:58:00] <petev> alex, if we don't bite the bullet and try, how do we ever get out of the state we are in?
[20:58:15] <petev> nobody understands the code that well or wants to touch it
[20:58:29] <petev> and we can't fix simple stuff like the spindle problem
[20:58:45] <petev> we can do it in a branch or something if that helps
[20:59:02] <petev> I don't see any problems with the config stuff
[20:59:06] <alex_joni> * alex_joni neither
[20:59:17] <alex_joni> petev: I think it's an interesting task.
[20:59:27] <petev> I can't say for sure on the NML, because I still have to understand the internal queue better
[20:59:29] <alex_joni> the problem is that I've been too busy lately to even try..
[20:59:44] <petev> I don't think the config would take long
[21:00:07] <petev> the NML is a bigger job, but right now I can hardly follow the heirarchy of things
[21:00:12] <alex_joni> you must be a better c++ coder than me ;)
[21:00:17] <petev> it seems like everything includes everything
[21:00:19] <SWPadnos> (he is :) )
[21:00:27] <alex_joni> you talking about NML or the way emc uses it?
[21:00:34] <alex_joni> SWPadnos: that's trivial :P
[21:00:39] <SWPadnos> :P
[21:00:52] <petev> the config stuff would probably take a good day if we stick with INI format
[21:00:57] <petev> it would take longer to go to XML
[21:01:29] <petev> I'm not totally clear on the structure of the queue between plan and execute in task
[21:01:30] <SWPadnos> there have been discussions on config issues and additional features. if it's going to be done, let's try to get those concerns addressed
[21:01:50] <alex_joni> petev: interp_list ?
[21:01:54] <petev> I need to understand the messages better and how the pre/post conditions are dealt with
[21:01:55] <SWPadnos> (I don't remember all of them, but I can search the archives/IRC logs for that kind of thing)
[21:01:58] <petev> alex, yes
[21:02:28] <alex_joni> petev: I suggested a thing a while ago.. but seems no-one liked it at the time
[21:02:37] <petev> what was that?
[21:02:44] <alex_joni> I said the NML messages should have a flag field for the pre/port conditions
[21:02:53] <alex_joni> post
[21:03:02] <alex_joni> instead of hardcoding them in task
[21:03:10] <petev> I'm leaning towards removing them and making them separate queue entries
[21:03:40] <duerz> anyone in here ever integrate OpenCNC?
[21:03:53] <petev> so you could queue commands and conditions
[21:04:02] <petev> conditions would just wait until met when executed
[21:04:14] <alex_joni> petev: interesting
[21:05:20] <petev> I also think the task code is a mess due to it really needing to be 2 threads, one for plan and one for execute
[21:05:27] <alex_joni> petev: http://www.robcon.ro/emc/nml/NML%20messages%20usage%20desc.csv
[21:05:31] <petev> they are done as one with a state machine mess
[21:05:39] <alex_joni> petev: that's an older list I made on NML messages
[21:05:54] <petev> is that current?
[21:06:06] <SWPadnos> 2 years old or so, I think
[21:06:10] <alex_joni> the current stuff is in there (except 1-2 messages)
[21:06:17] <alex_joni> there might be 3-4 others removed
[21:06:25] <SWPadnos> ah - newer than the copy I have then :)
[21:06:35] <alex_joni> 1 year old?
[21:06:44] <alex_joni> is it really 2 years since I did that?
[21:07:02] <SWPadnos> I think so - you, Paul and I were working on that stuff
[21:07:06] <alex_joni> SWPadnos: 19.06.2005
[21:07:18] <alex_joni> time flies
[21:07:21] <SWPadnos> yep :)
[21:07:30] <alex_joni> petev: use with a pinch of mistrust then ;)
[21:07:34] <petev> ok
[21:07:36] <alex_joni> but I know that not much has changed since
[21:07:46] <petev> does this sound like something we want to start now?
[21:07:57] <alex_joni> now..now?
[21:08:10] <petev> why not?
[21:08:25] <alex_joni> * alex_joni is on a business trip away from his devel box :)
[21:08:30] <alex_joni> and it's 11ppm
[21:08:36] <petev> just to really stir stuff up, what are the chances of moving the repository to svn to make refactor stuff easier?
[21:08:42] <petev> oh, I didn't mean this instant
[21:08:50] <SWPadnos> hahahahahaha
[21:08:57] <SWPadnos> I mean - well, there may be some resistance
[21:09:07] <alex_joni> petev: ask cradek first
[21:09:14] <alex_joni> then ray
[21:09:16] <petev> I hate to loose the old revs too, but cvs is painful
[21:09:18] <SWPadnos> svn is available on DreamHost, though we wouldn't have full admin rights
[21:09:34] <petev> why not run it on the same server we are using?
[21:09:46] <alex_joni> that would probably be the idea
[21:09:50] <petev> I even run it on my doze box without trouble
[21:09:51] <skunkworks> :) I am not a contributer but from my perspective - things have slowed down and emc2 seems to be at a good spot to clean up.. (but that is just my opinion) :)
[21:09:52] <SWPadnos> a laptop in Jeff's basement is the current CVS server
[21:10:07] <SWPadnos> DH may be a little higher performance :)
[21:10:12] <alex_joni> SWPadnos: not from here
[21:10:16] <SWPadnos> heh
[21:10:26] <SWPadnos> not for Ray either, I imagine
[21:10:36] <petev> yeah, I think he's on dialup
[21:10:41] <SWPadnos> yep
[21:10:40] <alex_joni> actually I get better speeds from jeff's box sometimes
[21:10:46] <alex_joni> not my limitation
[21:10:47] <SWPadnos> really?
[21:10:49] <alex_joni> yes
[21:10:50] <SWPadnos> that's odd
[21:10:54] <alex_joni> I know
[21:10:59] <SWPadnos> though it is 1000 miles closer to you
[21:11:05] <SWPadnos> (Jeff, that is)
[21:11:10] <alex_joni> I planned to move all my hostings to DH
[21:11:17] <alex_joni> but I'm having second thoughts
[21:11:34] <SWPadnos> hmm - that's too bad. is it slow for you often?
[21:11:47] <alex_joni> no.. only loong latencies at the beginning
[21:11:53] <SWPadnos> ok
[21:12:13] <SWPadnos> I know they had some issues recently - a somewhat prolonged power outage was one of them
[21:12:42] <alex_joni> we drifted..
[21:12:51] <SWPadnos> yep - sorry
[21:13:25] <SWPadnos> anyway, svn is available, but with the CVS server tweaked as it is (security-wise), and other objections, I don't think a move to SVN is in the cards at the moment
[21:13:36] <SWPadnos> but that is more of a cradek / board question
[21:13:49] <petev> what would the problems be?
[21:13:54] <SWPadnos> (remember that all the devs and users who compile for themselves need to be able to use svn)
[21:14:09] <petev> the same clients are available
[21:14:26] <SWPadnos> you mean "cvs up -dP" ... ?
[21:14:33] <petev> you can use toroise for cvs or svn and linux has packages for both
[21:14:40] <SWPadnos> most devs don't use a "client" other than the command line
[21:14:49] <SWPadnos> is tortoise available for Linux?
[21:14:51] <petev> yeah, there is svn command line
[21:15:02] <petev> I use tortoise on doze
[21:15:14] <petev> I use the command line on linux
[21:15:18] <SWPadnos> I do as well, and I like it.
[21:15:20] <SWPadnos> same here
[21:15:29] <alex_joni> * alex_joni three
[21:16:11] <SWPadnos> (minor segue) I'd love to see the same features that tortoise has integrated into nautilius or some other Linux shell
[21:16:27] <petev> that would be cool
[21:16:54] <SWPadnos> I think there are some gnome scripts that do that, but I haven't tried them yet
[21:21:52] <SWPadnos> anyway - on configs, there has been a fair amount of discussion about combining HAL and ini (and possibly NML) config info into one file (or at least one format)
[21:24:33] <alex_joni> * alex_joni heads to bed
[21:24:37] <alex_joni> g'night all
[21:24:42] <SWPadnos> see you later
[21:24:47] <petev> gn
[21:24:59] <alex_joni> maybe I'll sneek in in a while..
[23:51:46] <cradek> wonder how I screwed that up - I thought I tested it