Back
[00:02:31] <jepler> hah
[00:05:28] <Dallur> hey, since I wanted to work on the tooltable I noticed that the documentation is lacking to the point where I had to create something (just so I could reveal my ignorance and get corrected)
[00:05:40] <Dallur> Is there someone who can take a look at
http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?ToolTable
[00:06:22] <Dallur> and perhaps delete/correct any mis-information
[00:07:01] <Jymmm> * Jymmm volunteers Dallur for the job, anyone second ?
[00:07:21] <Dallur> * Dallur volunteers Rugludallur for the job
[00:08:10] <Jymmm> Dallur, Hey now, just because you hear 20 voices in your head doens't mena you can take advantage of that
[00:09:14] <Dallur> I am my own party, I never have to drink alone
[00:17:02] <Jymmm> lol
[00:17:35] <Jymmm> les_w, Where for art thou?!
[00:25:11] <rayh> Hi guys. Sorry was away reading backlog.
[00:25:28] <SWPadnos> backlog - I'm familiar with that :)
[00:25:47] <rayh> Lots of it.
[00:26:13] <SWPadnos> in several forms
[00:55:21] <jmkasunich> hi guys
[00:56:14] <cradek> hi all
[00:56:15] <SWPadnos> hiya
[00:56:21] <cradek> * cradek just woke up
[00:56:41] <SWPadnos> * SWPadnos just ate some Coffeee Heath Bar Crunch ice cream
[00:56:49] <SWPadnos> mmmmmmmm
[00:57:16] <jmkasunich> * jmkasunich just had hot & sour soup and mu shu chicken
[00:57:29] <SWPadnos> sometimes I wonder why I even bother moving it from the carton to a bowl
[00:57:49] <SWPadnos> hmmm - hot&sour - the best soup available (at chinese restaurants)
[00:57:58] <SWPadnos> maybe I should get some take-out :)
[00:58:08] <jmkasunich> this batch was a little dissapointing - to salty
[00:58:44] <SWPadnos> bummer - I disklike salt
[00:58:48] <SWPadnos> dislike, too
[00:59:38] <SWPadnos> it's always annoying to go to e.g. a Cajun place, and the cajun blackened whatever is actually overcooked salty stuff that's otherwise almost flavorless
[01:00:03] <cradek> I suppose salt is the cheapest way to give something flavor
[01:00:08] <SWPadnos> yeah
[01:00:09] <cradek> garlic might be next
[01:00:15] <SWPadnos> too bad it's always a salty flavor ;)
[01:00:36] <jmkasunich> cayanne pepper is probably pretty cheap, given the required dosage
[01:01:00] <SWPadnos> heh
[01:01:11] <SWPadnos> some people are resistant though :)
[01:01:47] <jmkasunich> yesterday we had homemade red beans and rice... tasty
[01:03:02] <SWPadnos> damn - you're making me hungry
[01:03:50] <jmkasunich> chitlins!
[01:03:56] <jmkasunich> (did that solve the problem?)
[01:04:00] <SWPadnos> ok, not hungry any more - thanks
[01:04:02] <SWPadnos> yep
[01:04:14] <SWPadnos> I tasted them once, and that's enough for me
[01:04:28] <jmkasunich> more than enough for me
[01:04:35] <jmkasunich> never tasted, never intend to
[01:04:54] <SWPadnos> yeah - my wife doesn't need to taste them either - she smelled them :)
[01:06:08] <Dallur> I tasted them this spring for the first time, in slovenia, not half bad kinda like bacon soup
[01:06:18] <jmkasunich> from wikipedia: "Chitterlings must be soaked and rinsed thoroughly in several different cycles of cool water, and repeatedly picked clean by hand, removing extra fat and specks of faecal matter."
[01:07:08] <SWPadnos> it's nice when they get all the faecal matter out
[01:07:30] <cradek> happily I don't know what this "food" is, and I'm not going to google-image-search it up either
[01:07:46] <SWPadnos> lower intestine of pig - no photos needed
[01:07:56] <cradek> yum
[01:08:05] <cradek> wouldn't you like some nice bread instead?
[01:08:06] <SWPadnos> err - yeah
[01:08:17] <SWPadnos> I like bread a lot more than chitlins
[01:08:40] <SWPadnos> even 21-grain bird-food bread
[01:08:48] <Dallur> you guys are just picky, how about sour ram balls ? or cured shark ? and you think chitterlings taste bad
[01:09:30] <jmkasunich> Rocky Mountain Oysters!
[01:09:37] <cradek> Dallur: nothing where you kill an animal and chop off a part of it for me, thanks
[01:09:47] <cradek> that's just gross
[01:11:05] <Dallur> tasting can't hurt
[01:11:49] <cradek> some of the stuff in the wiki is baffling
[01:11:50] <rayh> One place in china had sausage named as breakfast bowels.
[01:12:21] <cradek> rayh: that reminds me of a story
[01:12:35] <cradek> rayh: we used to go to a place called "thai garden", thai food obviously
[01:12:48] <cradek> one day on the door was a homemade ad with a picture of two birds
[01:13:03] <cradek> under it, it said "two lovebirds, great for breading"
[01:13:20] <rayh> okay
[01:13:28] <SWPadnos> heh
[01:13:36] <cradek> well I thought it was funny
[01:13:43] <cradek> maybe you had to be there or something
[01:13:45] <rayh> That calls to mind some interesting images.
[01:13:52] <SWPadnos> http://www.engrish.com/
[01:14:48] <cradek> http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?ArcRevrse
[01:15:46] <jmkasunich> the pic?
[01:15:58] <jmkasunich> tomp is a character
[01:17:09] <cradek> hmm, I don't get a pic on that page
[01:17:19] <cradek> I just don't have any clue what he was trying to do
[01:17:27] <cradek> but he definitely worked hard on it
[01:17:45] <jmkasunich> he's thinking about edm, and the need to not just stop, but actually back up along the toolpath
[01:18:00] <cradek> oh, ok
[01:18:39] <Dallur> Who would be the person here who knows tool tables best ?
[01:19:00] <cradek> me, since I just messed them all around
[01:19:08] <jmkasunich> everybody bit cradek steps backwards
[01:19:28] <Dallur> ok, there are 2 things I have in mind regarding tool tables
[01:19:37] <Dallur> 1. I tried to find docs, found none and create
http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?ToolTable
[01:19:48] <cradek> cool, and I added something there already
[01:20:23] <Dallur> great, thats where all the missing lathe stuff is :D
[01:20:41] <cradek> yes there's good stuff on that page
[01:20:52] <cradek> the angles probably need to be documented better
[01:21:14] <cradek> but a patient guy can look at the picture of the orientations and figure out what the angles mean
[01:21:38] <Dallur> :D when I get around to converting my lathe I will need those :D
[01:21:45] <cradek> yep
[01:22:02] <cradek> right now the angles are only used to draw the tool on the screen
[01:22:12] <cradek> they may be used for some kind of gouge protection later
[01:22:26] <cradek> and I don't know what FMS means
[01:22:38] <cradek> ray do you know?
[01:23:46] <cradek> it would be nice if "two" tools could be in one pocket
[01:23:46] <Dallur> ohh well takes ages for him to get the message (latency on those modems) :Þ
[01:24:05] <cradek> like I have a tool with two points, one for turning and one for facing
[01:24:12] <cradek> that will have different offsets and orientation obviously
[01:24:26] <cradek> but if I had an auto toolchanger I would want to specify the same pocket for both
[01:24:44] <cradek> right now it doesn't matter because I stick it on the tool post myself
[01:25:39] <cradek> Dallur: did you have a question for me and I rambled so long you forgot?
[01:25:52] <Dallur> well I saw a couple of dorian 8 tool changes(posts) going for around $200 on ebay the other day
[01:26:15] <jmkasunich> cradek: you could do a hack if/when you do a toolchanger: divide the tool number from EMC by two, so both 0 and 1 are the same physical tool, but EMC sees them as different
[01:26:39] <Dallur> The other thing that I have in mind is actually something that has been .. well forming in my head since I started the plasma thing
[01:27:01] <Dallur> With plasma torches you have several different amp settings, and you have consumables for each amp setting
[01:27:17] <Dallur> So , your Amp setting is in fact the same as your tool
[01:27:47] <Dallur> Hence, I want to use a tool table to store configs for my different amp settings
[01:28:08] <jepler> by the way, there is documentation on the (old) tool table in
http://www.linuxcnc.org/EMC2_User_Manual.pdf
[01:28:12] <cradek> currently the format of the tool table is quite fixed
[01:28:17] <jepler> page 106
[01:28:25] <jepler> The "FMS" column contains an unsigned integer which represents a code number for the tool. The
[01:28:29] <jepler> user may use any code for any tool, as long as the codes are unsigned integers.
[01:28:32] <jepler> that's taken from the old nist documentation
[01:28:40] <Dallur> ok, I will look at it
[01:28:44] <Dallur> But with the amp settings come 2 values ,, Pierce Height and Voltage/Standoff
[01:29:10] <Dallur> So I have been wondering if I should create a new type of tool table specifically for plasma cutting
[01:30:16] <cradek> if these things are needed only in hal, we need a hal block that takes an unsigned int and gives a set of values on pins
[01:30:49] <cradek> since you only need them in hal, it shouldn't be necessary to pass these things that emc doesn't actually care about through all the layers of emc
[01:31:00] <Dallur> no but there is more
[01:31:07] <cradek> ok
[01:31:16] <Dallur> you see if you already have the amperage and the voltage/standoff
[01:31:37] <Dallur> you might as well create a table with the materials you intend to cut (steel/stainless/aluminium)
[01:31:54] <Dallur> and the thickness of each (which you can actually get from the float sensor if you want to)
[01:32:13] <Dallur> and automatically set everything correctly including the optimal velocity
[01:32:33] <Dallur> example:
[01:32:48] <Dallur> I want to cut 10mm stainless steel
[01:33:22] <rayh> Back in the old days the FMS column was a a way to allow for numbering other than pocket but I don't think it was ever used any place.
[01:34:09] <Dallur> make a selection from a vcp gui, that will look up from the tables that I need to mount a 40A tip at 121V, speed should be 0.36Meters per minute, Pierce delay is 1.5 sec and Pierce Height is 6.4mm
[01:34:56] <Dallur> Im at a point where I am thinking, why do I want to match the features of the other software when ,, it might be easier to 1up them
[01:35:14] <jmkasunich> you don't need to change the tool table to do that
[01:35:24] <cradek> that's still what I'm thinking too
[01:35:35] <jmkasunich> most of those parameters (delay, height, etc) are in hal, right?
[01:35:47] <Dallur> all of the params are already implemented in hal
[01:36:17] <jmkasunich> so write a user space app that exports some hal pins... it can run completely independently of emc itself, and just set the hal pins
[01:36:19] <Dallur> so your point is ,,, do it in hal ?
[01:36:24] <cradek> now assume you have access to the loaded tool number in hal (simple matter of programming)
[01:36:48] <jmkasunich> actually, I think the latest approach would skip the tool number part completely
[01:37:11] <Dallur> well it would be nice to get the "tool change prompt" feature from the tool table things
[01:37:12] <cradek> depends if you want to change these things with TxM6 or not
[01:37:28] <jmkasunich> you'd pick "stainless" from a menu, then pick 10mm, and click OK... 3 or 4 or 5 hal pins would get set to the appropriate values
[01:38:32] <cradek> but you'll also want to set the kerf ("cutter diameter") at the same time right?
[01:38:36] <SWPadnos> you still need a "toolchange" to accomodate varying beam widths
[01:38:41] <jmkasunich> oops, yeah
[01:38:43] <cradek> that's why I was thinking using M6
[01:38:44] <Dallur> cradek: yes true
[01:39:37] <Dallur> so, just make the tool ID available as a hal pin, than it can all be done from hal really
[01:40:04] <jmkasunich> I think the tool ID is already available (for automatic toolchangers)
[01:40:08] <cradek> you still need a "table lookup" component
[01:40:20] <Dallur> yes
[01:40:39] <SWPadnos> seemingly unrelated - the mesa driver can optionally load a config into the FPGA, right?
[01:40:44] <jmkasunich> we need a way to read a file into a HAL component
[01:40:54] <SWPadnos> see - not so unrelated at all :)
[01:40:55] <Dallur> And I need a way to set VCP pins to a value even though they are already connected to signals which in turn are connected to other hal pins
[01:41:18] <jmkasunich> SWPadnos: I think so... but the FPGA config is hard coded into the driver as a const array of unsigned char (I think)
[01:41:32] <SWPadnos> ok
[01:41:49] <SWPadnos> oh, so it's a "reset the FPGA" flag, not a file to load
[01:41:57] <SWPadnos> bummer
[01:42:27] <cradek> jmkasunich: are you back home now?
[01:42:32] <jmkasunich> yeah
[01:42:43] <jmkasunich> have been since late Friday
[01:43:20] <jmkasunich> SWPadnos: yeah, thats what it is...
[01:43:22] <jmkasunich> static hal_u8_t
[01:43:22] <jmkasunich> fpgaConfig[] = {
[01:43:22] <jmkasunich> 0xff, 0xff, 0xff, 0xff, 0x55, 0x99, 0xaa, 0x66,
[01:43:22] <jmkasunich> 0x0c, 0x00, 0x01, 0x80, 0x00, 0x00, 0x00, 0xe0,
[01:43:30] <SWPadnos> right
[01:43:40] <jmkasunich> 20,000 lines of it
[01:43:51] <cradek> beautiful
[01:43:52] <SWPadnos> in fact, no w I remember looking for the source that converts the bitfile to the C header
[01:44:09] <cradek> we've all written that once or twice I bet
[01:44:18] <SWPadnos> indeed
[01:44:23] <SWPadnos> so why do it again? ;)
[01:46:16] <rayh> gotta bail. see you guys later.
[01:48:01] <jmkasunich> Dallur: I'm looking at the vcp changes you sent
[01:48:13] <jmkasunich> I have a couple thoughts.
[01:48:17] <Dallur> yes
[01:48:43] <jmkasunich> the buttons: I'd rather have "button" and "toggle" as two distinct widgets, instead of two types of button
[01:49:41] <Dallur> ok, I figured you might but I implemented as the same, might as well use the chance and implemented a configurable "initial_state" for the toggle
[01:50:00] <Dallur> If you want I can change and send again tomorrow
[01:50:23] <jmkasunich> I'm going to go ahead and commit tonight
[01:50:26] <cradek> does the toggle look like a checkbutton?
[01:50:39] <jmkasunich> would you like to be a developer? then you can just change and commit yourself
[01:51:21] <Dallur> if you guys are ok with it I would
[01:51:23] <jmkasunich> cradek: I don't know yet... I suspect they both look like "buttons"
[01:51:34] <Dallur> cradek: they look the same
[01:51:47] <jmkasunich> but the toggle stays pressed when you click it
[01:51:53] <jmkasunich> (until you click it again)
[01:52:02] <Dallur> cradek: but the check button is 100% same functionality, I can implement it while I fix toggle if you want, takes 1 minute
[01:52:18] <cradek> in my opinion it's a "gui blooper" if a button and checkbutton (toggle) look the same
[01:52:28] <jmkasunich> I was wondering about that
[01:52:28] <Dallur> cradek: toggle looks like
http://wiki.linuxcnc.org/uploads/Dallur_vcp.png
[01:52:56] <cradek> I see, it's a button but it sticks in
[01:53:05] <jmkasunich> cool, spinboxes too
[01:53:05] <Dallur> yup
[01:53:19] <cradek> that's not really the standard usage of widgets
[01:53:28] <cradek> yay, we needed spinboxes
[01:53:35] <jmkasunich> checkbox would be the normal way to do that?
[01:53:52] <cradek> yes those are the widget typically used for toggles
[01:54:09] <cradek> we might also want to add radiobuttons (one of a set is in, the rest are out)
[01:55:00] <jmkasunich> I guess the one you prefer depends on your goal... if you are really making a "virtual control panel" that emulates physical hardware, checkboxes would be uncommon, you'd have either maintained pushbuttons or two position rotary or toggle switches or somethign like that
[01:55:00] <SWPadnos> how difficult is it to do "owner-drawn" controls?
[01:55:16] <jmkasunich> if you are making a GUI, then you'd use more traditional GUI things like checkboxes
[01:55:34] <jmkasunich> likewise for radio buttons - on a control panel, that might be a 4 position rotary switch
[01:55:35] <SWPadnos> how about both, with a "style" keyword?
[01:55:45] <cradek> true, in real life you'd have toggle switches, but the natural parallel in the gui is a checkbutton
[01:56:44] <jmkasunich> I kinda like SWP's "style" thing
[01:56:52] <jmkasunich> but I'm scared of trying to code it
[01:56:56] <jmkasunich> I suck at GUI stuff
[01:56:58] <cradek> I could (maybe) be convinced that we want a new widget that looks like a rotary switch to parallel the real world
[01:57:15] <cradek> but I think it's wrong to use existing widgets, that people are familiar with how to use, in an unusual way
[01:57:25] <cradek> it makes the app unfriendly
[01:57:30] <SWPadnos> "locked" buttons are pretty common, I think
[01:57:33] <jmkasunich> heh, I'm not going to try to convince you, because I have absolutely no desire to write the code to render that on screen
[01:57:51] <SWPadnos> consider things like the bold or underline buttons on GUI word processors
[01:57:54] <jmkasunich> (the rotary switch that is)
[01:57:58] <cradek> SWPadnos: I think not really except on PalmOS (really)
[01:58:11] <cradek> SWPadnos: true, in toolbars
[01:58:44] <CIA-19> 03jepler 07HEAD * 10axis/scripts/hal_manualtoolchange.py:
[01:58:44] <CIA-19> It's not clear exactly why, or whether it's a bug in Tk or the icewm window
[01:58:44] <CIA-19> manager, but the manual toolchange dialog wasn't getting completely focused.
[01:58:44] <CIA-19> This change seems to "fix" the problem, but it's a bit janky.
[01:58:44] <CIA-19> Also, move the import of Tk and the creation of the application below
[01:58:44] <CIA-19> hal_ready() so that it doesn't block the startup of emc. Otherwise,
[01:58:47] <SWPadnos> it's still confusing, because you don't know if the tesxt tells you what happens if you click, or what the current state is
[01:58:48] <CIA-19> with cold cache, this added several seconds to the startup time.
[01:58:49] <jmkasunich> cradek: what is the traditional GUI counterpart of the vcp LED
[01:59:06] <cradek> SWPadnos: hmm maybe I'm wrong, or maybe toolbars kind of suck in their own way
[01:59:12] <SWPadnos> heh
[01:59:26] <cradek> SWPadnos: it's an unnatural marriage of a button and an indicator, which does make it unclear what's going on
[01:59:26] <SWPadnos> for some things, it's a useful indicator and control
[01:59:26] <jmkasunich> I know the TkEmc button is terrible
[01:59:43] <jepler> butticator?
[01:59:45] <jmkasunich> when it says "estop", does that mean "I'm in estop", or "press to estop"
[01:59:53] <SWPadnos> something like a "Bold Text" button is great, but in many cases it's confusing
[02:00:08] <cradek> we should ask jepler
[02:00:14] <jmkasunich> cradek: lighted pushbuttons are very common on industrial control panels
[02:00:16] <cradek> ... who has just invented the erm "butticator"
[02:00:22] <cradek> term
[02:00:25] <SWPadnos> jmkasunich, that confusion (in tkemc) stems partly from the fact that the button looks the same unless yuo're "pressing' it
[02:00:37] <jepler> Your search - butticator - did not match any documents.
[02:00:39] <jepler> holy cow, I did
[02:00:45] <cradek> also, some of the "buttons" cause menus to pop down
[02:00:56] <SWPadnos> hah
[02:00:57] <cradek> tkemc has several nonstandard widget usages
[02:00:58] <SWPadnos> heh
[02:01:08] <jmkasunich> ;-)
[02:01:11] <cradek> but let's talk about vcp
[02:01:18] <SWPadnos> quick - copyright that
[02:01:24] <cradek> jepler: and you thought you wouldn't accomplish anything today
[02:01:26] <SWPadnos> some sex toy company will pay for it
[02:01:32] <jepler> butticator(SM)(R)(C)(patent pending)
[02:01:35] <cradek> No match for domain "BUTTICATOR.COM".
[02:01:49] <SWPadnos> or butticated :)
[02:01:56] <jmkasunich> ok, ok
[02:01:59] <SWPadnos> heh
[02:02:04] <jmkasunich> lets talk about vcp
[02:02:05] <jepler> anyway, the use of the "pressed-in button" as an indicator on toolbars is pretty well established. usually it shows an icon, of course.
[02:02:23] <jepler> when pressed in, the function shown by the icon is in effect
[02:02:28] <SWPadnos> that's also part of the reason for my "owner draw" question
[02:02:53] <jmkasunich> let's take a step back for a second...
[02:02:55] <jepler> if there are several mutually exclusive items represented by separate butticators, they are placed closer together (the left / center / right justify butticators)
[02:02:59] <SWPadnos> things like toggle switches are just an image that changes when toggled
[02:03:09] <jepler> all of vcp is toolbar-like, so this usage would not be amiss
[02:03:11] <SWPadnos> radio butticators
[02:03:12] <cradek> on toolbars the square-with-icon can be part of a radiobutton set, or a toggle, or a button
[02:03:34] <SWPadnos> usually sets are delimited by vertical lines
[02:03:43] <cradek> right
[02:03:46] <jmkasunich> do we want to keep going with vcp as it is, slowly re-inventing Glade ( or <insert your favorite gui builder here>), or should we consider some other approach
[02:03:57] <SWPadnos> like qtemc?
[02:04:04] <cradek> I withdraw my complaint since well-established toolbars have this problem too
[02:04:13] <SWPadnos> like openoffice?
[02:05:22] <jepler> so .. I don't think I helped clear anything up ..
[02:05:46] <jmkasunich> well, you pointed out that vcp is more like a toolbar than a normal window (maybe)
[02:06:31] <jmkasunich> I keep looking at the code behind the relatively limited set of widgets that vcp has so far...
[02:06:43] <jmkasunich> and I look at the number of ideas we have for widgets....
[02:06:43] <cradek> I agree it is toolbar-like
[02:06:54] <jmkasunich> and I wonder if we're taking the right approach
[02:07:30] <jmkasunich> Dallur's screenshot brought up another thing...
[02:07:46] <jmkasunich> notice how he has the VCP right next to TkEMC?
[02:08:02] <Dallur> jmkasunich: I wish I could dock them btw :D
[02:08:07] <jmkasunich> it would be nice if a vcp window could be part of another app, rather than an app itself
[02:08:54] <SWPadnos> I think you need the more advanced features of gnome/KDE for that
[02:09:09] <SWPadnos> but maybe there are "embedding" features at a lower level - I'm not sure
[02:09:29] <jmkasunich> perhaps "libvcp" instead of (or in addition to) vcp as a program?
[02:09:50] <cradek> maybe you're more likely to be able to embed tkemc in the vcp window
[02:09:53] <jmkasunich> I dunno, I'm way out of my depth when we start talking about GUIs
[02:10:03] <cradek> I'm always out of my depth
[02:10:16] <SWPadnos> I lose footing when we talk about X GUIs ;)
[02:11:28] <jepler> X has a standard for embedding, but it sucks
[02:11:47] <jmkasunich> btw, if you want a _real_ butticator, you just embed a vcp LED in a vcp button ;-)
[02:12:17] <SWPadnos> like Dallur has
[02:12:32] <jmkasunich> technically the togglebutton goes against the "NIST way", because you can't change it from anywhere else
[02:12:55] <jmkasunich> but its usefull enough in simple cases that I want to keep it anyway
[02:12:57] <SWPadnos> it's a HAL writer - it can't be connected to any others
[02:12:57] <Dallur> jmkasunich: and btw there is a need to do that now with the tool table thing
[02:13:20] <SWPadnos> the HAL mux violates the NIST principle, actually ;)
[02:13:37] <jmkasunich> SWPadnos: how?
[02:14:10] <SWPadnos> because it lets you change the controller of something, and has no way of making sure that no instantaneous change in state occurs as a result
[02:14:19] <jepler> frame .f -container 1 -width 600 -height 400
[02:14:19] <jepler> pack .f
[02:14:19] <jepler> exec xterm -into [expr [winfo id .f]] &
[02:14:27] <jepler> here's how you can use the ancient X embedding API with a Tk app
[02:15:06] <cradek> jepler: I can't believe I've never heard of that
[02:15:07] <jepler> but nobody ever got around to fixing the issue of how you "tab around" between the two apps, for instance
[02:15:15] <SWPadnos> heh
[02:15:39] <SWPadnos> that would be great for an embedded g-code editor in AXIS
[02:15:41] <jmkasunich> speaking of tabbing around, I have no idea how (or if) vcp works with the keyboard
[02:15:44] <SWPadnos> (sort of)
[02:16:03] <SWPadnos> there's often a "taborder" keyword for these kinds of things
[02:16:23] <SWPadnos> and also hotkeys
[02:16:34] <Dallur> jmkasunich: of course it works with tab :D
[02:16:49] <Dallur> jmkasunich: orders from top to bottom
[02:17:29] <SWPadnos> out of curiosity, what happens if those 4 bordered regions are placed next to each other?
[02:17:40] <jmkasunich> 4 bordered regions?
[02:17:50] <SWPadnos> oops - 6
[02:17:56] <SWPadnos> the named frames
[02:18:04] <SWPadnos> Sensor Inputs, Input Signals ...
[02:18:08] <Dallur> you mean side by side ?
[02:18:12] <SWPadnos> yes
[02:18:24] <SWPadnos> pack the top level horizontally instead of vertically
[02:18:26] <jmkasunich> you mean if the outermost box was changed from "layout = vertical" to "layout = horizontal" ?
[02:18:31] <SWPadnos> yes :)
[02:18:39] <jmkasunich> it would be wider ;-)
[02:18:47] <SWPadnos> and shorter
[02:18:47] <Dallur> and tab would go from left to right
[02:18:51] <SWPadnos> and uneven
[02:19:16] <SWPadnos> L->R, then T->B, or vertically through each frame, then to the next frame?
[02:19:19] <jmkasunich> yeah, probably look pretty crappy
[02:19:51] <Dallur> l->r first i think
[02:20:08] <Dallur> through each frame and on to next
[02:20:09] <jmkasunich> there are "expand" and "padding" attributes for each widget, which map to the corresponding GTK widget attribs
[02:20:19] <SWPadnos> the tab order is probably implicit in the order in which the VCP items appear in the input file, since the display widgets are created in order
[02:20:22] <jmkasunich> but getting a nice layout takes a fair amount of trial and error
[02:20:33] <jmkasunich> I bet thats true
[02:20:56] <SWPadnos> and you can't put some stuff in one box, then go on to another, then put more stuff in the first, right?
[02:21:09] <SWPadnos> (ie, you have to close one "group" before starting another at the same level)
[02:21:12] <jmkasunich> so it would basically be a depth first traversal of the tree
[02:21:21] <jmkasunich> right - its a tree
[02:21:38] <SWPadnos> ok - yep, that's the order then, I'm betting
[02:21:42] <jmkasunich> the nesting in the .vcp file maps exactly to the nesting of the widgets
[02:22:13] <SWPadnos> ok. I assume there's a tab order attribute for the GTK widgets (that the user can modify), right?
[02:22:20] <jmkasunich> no idea
[02:22:24] <SWPadnos> heh
[02:22:49] <SWPadnos> ok - focus chain
[02:22:56] <jmkasunich> when it comes to GTK, I stumble around until I find something that seems to work
[02:23:36] <jmkasunich> jepler: if you were going to tackle something like vcp, what would you use? python, tcl/tk, gtk, qt, ?
[02:24:02] <SWPadnos> qt actually is similar in some ways to HAL - it works with "signals" and "slots"
[02:24:14] <SWPadnos> you connect event signals to receiving slots
[02:24:36] <SWPadnos> something borrowed from NeXT
[02:25:03] <jmkasunich> that is done at the source code level tho, isn't it?
[02:25:17] <SWPadnos> yes, for the widget itself
[02:25:18] <jmkasunich> the goal with vcp is to build a panel without compiling
[02:25:26] <Jymmm> * Jymmm misses his NeXT box =(
[02:25:37] <jmkasunich> just like the goal for HAL is to build a system without compiling
[02:25:43] <Dallur> * Dallur misses his cube to ;O
[02:25:44] <SWPadnos> though there are GUI/RAD interface builders for it (similar to Glade, I think)
[02:25:54] <SWPadnos> I've still got NextStep 3.xx for the PC
[02:26:02] <cradek> I distinctly remember jepler asking why you were reinventing tk
[02:26:07] <SWPadnos> too bad there are no drivers for modern-ish hardware
[02:26:11] <SWPadnos> heh
[02:26:43] <jmkasunich> exactly - I shouldn't be reinventing tk
[02:27:10] <SWPadnos> actually, what's being reinvented here is the Windows resource file, for the most part (or the file that Borland C++ Builder uses to speficy window arrangements)
[02:28:04] <cradek> yes except that's for compiling
[02:28:12] <cradek> this is "interpreted"
[02:28:14] <jmkasunich> vcp is better than tk for 2 reasons: 1) tk is more general (and thus has far more options to confuse somebody who is trying to do something simple)
[02:28:24] <jmkasunich> 2) tk alone can't access HAL pins
[02:28:41] <jmkasunich> tk is better than vcp for several reasons:
[02:28:48] <jmkasunich> 1) not reinventing the wheel
[02:28:55] <cradek> 1) tk is more general so you can do whatever you like
[02:29:01] <jmkasunich> right
[02:29:36] <Dallur> Does anyone know that the commercial guys use to build those XML based UIs that have popped up in every computer game since 2003 ?
[02:30:21] <SWPadnos> I don't think they use XML, to be honest
[02:30:55] <Dallur> hmm I know EQ uses xml, I think WoW uses xml to but I am not sure
[02:31:05] <SWPadnos> many (most) game developers create their own UI tools
[02:32:11] <jmkasunich> would it be possible to extend tk (tcl actually, I think) to talk to hal pins (without the incredibly slow hack of invoking halcmd?)
[02:32:25] <SWPadnos> halsh, anyone?
[02:32:27] <cradek> jmkasunich: SMOP I'm sure
[02:32:36] <jmkasunich> only if you know what you are doing
[02:32:38] <SWPadnos> extend emcsh with HAL functions
[02:32:40] <cradek> yeah
[02:32:49] <cradek> isn't that always the problem
[02:35:03] <jmkasunich> the idea of polling by doing "testpin name" thru a halsh, instead of "if (mystruct->data) { do something } " just makes my skin crawl
[02:35:13] <jmkasunich> and for stuff like LEDs, you have to poll
[02:35:31] <cradek> the polling would be done in C with the tcl variables updated when necessary I think
[02:35:38] <cradek> * cradek waves his hands
[02:35:49] <jmkasunich> how would the C know which pins to poll?
[02:35:54] <cradek> you hook the indicator to the tcl variable, and it tracks automatically
[02:36:36] <cradek> I guess you have to register them somehow (with a tcl command that calls the C, which keeps track of a list maybe)
[02:36:46] <SWPadnos> plus or minus some string <-> real data conversions, I bet
[02:36:46] <cradek> I dunno jmk
[02:37:08] <cradek> look at me pretending I know how tk works
[02:37:17] <SWPadnos> though the tcl internals aren't strings these days, according to some book I almost read
[02:37:17] <jmkasunich> the polling rate doesn't have to be extremely fast, 10 times a sec is probably enough
[02:37:40] <jmkasunich> but the idea of creating and then parsing a string for every pin every time just reeks
[02:39:03] <cradek> * cradek shrugs
[02:39:49] <SWPadnos> there's one difference between halcmd (or halsh) and vcp though - vcp owns the pins it creates
[02:39:59] <SWPadnos> so it knows where the data is
[02:40:07] <jmkasunich> if we did a halsh, it should own pins too
[02:40:17] <SWPadnos> right, and for those, the data would be in a known location
[02:40:29] <jmkasunich> I'm not interested in a tcl/tk version of halcmd (or maybe I am, but not tonight)
[02:40:32] <SWPadnos> so it ends up being if (mydata->foo) ...
[02:40:49] <jmkasunich> the C in halsh looks like that
[02:41:02] <SWPadnos> yes
[02:41:16] <jmkasunich> but what does the tcl that calls it look like, and how much C is needed to translate between the two?
[02:41:52] <cradek> I know how to make new tcl commands that execute C and return a thing, but I'm not sure if you can link C and tcl variables the same way
[02:42:10] <cradek> or if you need setter/getter functions for all the vars
[02:42:35] <jmkasunich> to work, you'd need "get(name)", not "get_name()"
[02:42:46] <SWPadnos> here's a sample of what you're heading toward with halvcp ;)
http://pastebin.ca/92985
[02:43:13] <jmkasunich> long
[02:43:21] <jmkasunich> (vcp files get long too)
[02:43:29] <SWPadnos> that's most of the window definition for the G-Rex tester program (I removed the glyph image data - a lot of hex codes)
[02:44:00] <jmkasunich> currently vcp doesn't do left/top/height/width stuff, it leaves that up to GTK/the window manager
[02:44:39] <jmkasunich> but other than details, you are exactly right
[02:44:50] <jmkasunich> its a way to describe a window
[02:44:55] <SWPadnos> yep
[02:46:08] <jmkasunich> the question is: should we continue on the current path, defining the .vcp file to match exactly our needs, or should we use something that exists, is more general, but more complex with a steeper learning curve for non-programmers?
[02:46:29] <SWPadnos> I don't think the learning curve would be more steep for the users, just for us ;)
[02:46:29] <cradek> I think the "more complex" argument is red herring
[02:46:42] <cradek> you defeat that just by having simple examples
[02:47:14] <jmkasunich> SWPadnos: I don't follow... I want a user to be able to create a panel layout
[02:47:34] <SWPadnos> right - drag and drop is easy for the user, the underlying file format is immaterial
[02:47:58] <jmkasunich> well, I don't see us ever having drag-n-drop, unless we use a pre-existing toolset
[02:48:23] <cradek> maybe we should look ahead and try to pick something that could support dnd someday
[02:48:29] <SWPadnos> right, so a pre-existing toolset, modified for use with EMC2/HAL, is easy for the user, but hard for us
[02:48:34] <jmkasunich> cradek: the complexity is in connectin HAL stuff to the widgets
[02:48:48] <SWPadnos> here's what that long file creates:
http://www.cncgear.com/images/grextester.png
[02:49:03] <SWPadnos> less some of the text, plus some standard dialogs
[02:49:04] <jmkasunich> with vcp, connecting to a pin is easy: halpin = name
[02:49:32] <SWPadnos> the way those interface builders usually work is to present a list of "properties" for the selected control
[02:49:41] <SWPadnos> one extra property we'd define is the HAL pin name
[02:49:48] <cradek> yes the too-long list
[02:49:48] <SWPadnos> the user can then edit it
[02:49:49] <jmkasunich> with other languages, the widget specific stuff that the tools were designed to handle is clean, but the hal connections will require the user to write some code (even if its just copy/paste code)
[02:49:54] <cradek> I've seen that
[02:50:28] <SWPadnos> we did some of this for NML with QT widgets, but it's a PITA to get them to be usable by QT Designer
[02:50:45] <SWPadnos> or KDevelop
[02:51:04] <cradek> surely the tk program could make halpins matching the widget tree if that's what you want
[02:51:12] <jmkasunich> with vcp, "layout = horizintal" and "halpin = foo" are both attributes of the object
[02:51:31] <jmkasunich> if we could add attributes to some existing toolset to achieve that, I'd go for it in a second
[02:52:03] <SWPadnos> that's doable, we just never got to the point where the custom widgets could be dropped into a GUI designer
[02:52:13] <cradek> all you'd need to do is walk the widget tree in C and hal_pin_new_whatever with the appropriate type for the widget
[02:52:21] <SWPadnos> I need to find the code for qtNML
[02:52:41] <jmkasunich> cradek: what would you use for a pin name?
[02:52:43] <SWPadnos> we had DROs and stuff in KDE - they loko nice
[02:52:47] <SWPadnos> look
[02:52:59] <cradek> same as the widget name?
[02:53:13] <jmkasunich> button.0, button.1, etc?
[02:53:41] <cradek> tkvcp.estopframe.machine.on
[02:53:44] <jmkasunich> I like "halpin = run-button" "halpin = estop-led" better
[02:53:49] <cradek> you can name the widgets as you please
[02:53:57] <jmkasunich> oh, ok
[02:54:10] <jmkasunich> I was confusing widget type names (button, box) with widget instance names
[02:54:24] <cradek> ah
[02:54:48] <cradek> so if the widget is a checkbutton, make a "bit" pin
[02:54:50] <jmkasunich> does tk let you build new widget types (classes I guess) from existing ones?
[02:54:54] <Jymmm> "halpin = oh-shit"
[02:55:12] <SWPadnos> incr tk does, but I think tk doesn't
[02:55:13] <jmkasunich> existing class: checkbutton.... new class: hal_checkbutton
[02:55:13] <cradek> I don't know enough to say
[02:55:25] <Jymmm> (with a lil burning turd in place of the LED =)
[02:55:55] <jmkasunich> if we did this, the user might well _not_ want every single widget to have a hal pin
[02:56:50] <cradek> well for instance frames don't get a pin
[02:57:13] <jmkasunich> right
[02:57:46] <cradek> I don't really know enough to talk about these details
[02:57:46] <jmkasunich> the tree walking code would know that frames, file open dialogs, etc don't get pins
[02:57:51] <jmkasunich> neither do I
[02:58:06] <jmkasunich> but its fun to babble and speculate and wave hands ;-)
[02:59:03] <SWPadnos> does the VCP language allow for absolute positioning of objects?
[02:59:37] <jmkasunich> no, gtk builds the window (or maybe its the windowing system, I dunno...) and also handles rebuilding it when the window is resized, etc
[02:59:44] <SWPadnos> ok
[03:00:07] <SWPadnos> that would make a GUI interface builder easier to write, I think ;)
[03:00:52] <jmkasunich> you mean if the resulting window wasn't resizable?
[03:01:31] <cradek> I think dnd gui builders often give unresizable absolute-positioned windows
[03:01:35] <SWPadnos> hmmm - no, just so that the UI creator could avoid figuring out how to describe positions in relative terms (relative to frames, for example)
[03:01:47] <SWPadnos> that's the anchor thing in the code I posted
[03:01:53] <cradek> (that's why they're a bad idea)
[03:02:20] <jmkasunich> whether they're a bad idea depends on who you ask
[03:02:33] <cradek> yeah I shouldn't say stuff like that in public
[03:02:47] <jmkasunich> if somebody is literally building the interface for their very own machine, they might build it exactly the size they want it
[03:03:09] <cradek> but I've used so many crappy interfaces that don't work because my font is a little different size
[03:03:10] <SWPadnos> in modern UI builders, you can anchor an object to any combination of the top, bottom, left, or right sides of its container
[03:03:23] <jmkasunich> I agree that if you are building a GUI to distribute, the guy with the 800x600 screen and SWPadnos with the starship enterprise bridge are probably gonna want them differnet sizes
[03:03:27] <SWPadnos> if top and bottom are anchored, the object grows with the container, vertically only
[03:03:33] <SWPadnos> heh
[03:03:38] <SWPadnos> I need more monitors :)
[03:04:01] <cradek> the guy with the 8" monochrome monitor?
[03:04:05] <SWPadnos> I'd hate to have fixed size windows (and text) on a 3840x2400 display
[03:04:44] <SWPadnos> actually, I qualify for both the largest and smallest displays, I think (the kiosk touchscreen is 800x600)
[03:05:46] <jmkasunich> Rugludallur: are you still here?
[03:06:09] <Rugludallur> yup im here
[03:06:25] <jmkasunich> are you interested in getting developer access to CVS?
[03:06:45] <jmkasunich> (switching from blue sky future stuff to the here-and-now for a minute or two ;-)
[03:06:54] <Rugludallur> that would be great, be nice to check in directly
[03:07:15] <jmkasunich> all you need to do is send ssh keys to cradek
[03:07:21] <Rugludallur> ok, will do
[03:07:32] <cradek> the public key only of course
[03:07:33] <jmkasunich> once he enters them, you can get a developer checkout, do stuff, and commit it
[03:07:40] <cradek> .ssh/id_dsa.pub
[03:08:09] <Rugludallur> yup
[03:08:20] <jmkasunich> if you don't already have keys, I think its "ssh-keygen -t dsa" ?
[03:08:39] <cradek> [email protected]
[03:08:46] <cradek> or paste it on irc even
[03:09:11] <jmkasunich> now, getting back to vcp_widgets.c
[03:09:28] <Rugludallur> AAAAB3NzaC1kc3MAAACBAO4+00CmNrw2c9EfzX6ENbGzQASR7OQAwaDf8CXpJDToKTZuXxRIK4TkwLEBbhLBMvks0RBEJf5KrXE6E99P0MkBtrB+81KzNxUFk9l2lj6utpLrebJT/4zLpx+Pm6NSvpNnmXPLSCfhwFu8acQh3RXGoEak55/CkJ4MA72MbkYPAAAAFQDYOkkwttzpcjnGnFc9eg51PYLcxQAAAIEAnHzcgO2o2emuS+6r8nnnA4zFit1zLS6kv6KQCnjm8j8M1umeIFE3AckZSJApnZgdziWZ08sQC/Z5cfdRsd9LLZPU0P5/w3rCJQ38jB1XgqK/H5BCOGEGY3J9jSZ4xFU9I659mW5feKhNObCR2e3BbAmBcLjVVeiKbKnEIXeHzlQAAACBAJDa6Ca+wWXSuTBZAAu9EGLc4zbyyBLIZ05hn4ufN
[03:09:31] <jmkasunich> even if we go some other way in the future, Rugludallur has some good code today
[03:09:57] <Rugludallur> jmkasunich: I will listen carefully for changes :D
[03:10:25] <jmkasunich> I'm wondering if vcp_widgets.c should be broken up into smaller files
[03:10:39] <jmkasunich> with a couple of related widgets in each one
[03:10:55] <cradek> Rugludallur: do you have a sf devl account?
[03:11:30] <Rugludallur> cradek: yup jarl.stefansson
[03:12:36] <cradek> should I make the account name match on cvs.linuxcnc.org or do you want to use dallur
[03:13:17] <Rugludallur> jarl.stefansson is probably better
[03:13:55] <cradek> ok one minute
[03:13:59] <Rugludallur> Dallur is just short for Rugludallur, which is the name of my boat :P
[03:14:11] <cradek> ok
[03:15:48] <cradek> ok give it a try
[03:16:40] <cradek> make a new checkout the same way but with jarl.stefansson instead of anon
[03:17:22] <jmkasunich> I think I'm going to re-arrange the vcp source
[03:17:32] <Rugludallur> cradek: yup
[03:17:43] <jmkasunich> vcp_widgets.c will contain the top level, main window, and box widgets only
[03:18:05] <jmkasunich> three new files will contain the other three widget classes: display, control, and label
[03:18:17] <cradek> Jul 19 22:27:15 cvs sshd[55270]: Failed password for jarl.stefansson from 82.221.52.51 port 29849 ssh2
[03:18:21] <jmkasunich> or maybe label can go in with the top level stuff
[03:18:25] <cradek> you should not get a password prompt if the keys match
[03:18:57] <cradek> I bet your key was cut off in irc, it ended with "ufN" on my screen
[03:19:07] <Rugludallur> cradek: yup
[03:19:16] <jmkasunich> ended with 4uf on mine
[03:19:30] <Rugludallur> cradek: you are 3 sec ahead of me every step
[03:19:34] <Rugludallur> I will send mail
[03:19:35] <cradek> haha
[03:19:37] <cradek> ok
[03:20:07] <jmkasunich> Rugludallur: thats just because cradek (and jepler) are the two fastest typists I've ever seen
[03:20:57] <jmkasunich> damn, getting late again
[03:21:12] <Rugludallur> yup, 3:30 over here :P
[03:21:12] <jmkasunich> Rugludallur: where are you (what time is it there)?
[03:21:21] <Rugludallur> im GTM all time around (iceland)
[03:21:24] <jmkasunich> heh, only 11:30 here, but I was up late last night
[03:21:40] <cradek> Rugludallur: try again
[03:21:52] <jmkasunich> I've made little progress on the vcp code (too much talking)
[03:22:10] <Rugludallur> same , asks for pass
[03:22:14] <cradek> hmm
[03:22:32] <cradek> let me try pasting again, maybe I messed it up
[03:23:03] <cradek> once more
[03:23:38] <cradek> ok try again please
[03:23:42] <cradek> yay
[03:23:45] <Rugludallur> got it
[03:23:52] <cradek> welcome
[03:23:55] <jmkasunich> cool!
[03:23:55] <Rugludallur> thanks :D
[03:24:01] <jmkasunich> now....
[03:24:24] <jmkasunich> if you get a chance tomorrow, could you add the spin code, then commit
[03:24:47] <Rugludallur> will do (I'm on leave for this month and the next so nothing but time)
[03:24:51] <jmkasunich> if you don't mind, I'd rather call it "spinbox" instead of "spin" though
[03:24:58] <Rugludallur> no prob
[03:25:24] <jmkasunich> for the toggle button, I'd rather have "button" and "toggle" as two different widgets instead of one with a lot of conditional code (already mentioned that)
[03:25:47] <jmkasunich> and for now, forget my rambling about splitting up the file
[03:26:00] <jmkasunich> oh, one other thing:
[03:26:06] <jmkasunich> you added CL_SPIN
[03:26:20] <jmkasunich> the idea behind the CL things it that they are general classes of widgets
[03:26:30] <jmkasunich> the spinbox should be a CL_CONTROL
[03:26:51] <cradek> also I wanted to start asking new developers to avoid reformatting code using tools like indent, because it messes up cvs, sometimes folks don't know that
[03:27:11] <jmkasunich> sometimes its not indent
[03:27:17] <Rugludallur> what is your rule with indent , spaces or tabs and how many spaces if that is ?
[03:27:42] <Rugludallur> and I figure you always put { in the same line not the line below ?
[03:27:44] <jmkasunich> I've been doing 4 space indentation
[03:27:46] <cradek> Rugludallur: my "rule" is try to match the surrounding code and don't worry too much
[03:28:07] <jmkasunich> cradek has it right, just match the code thats there
[03:28:18] <jmkasunich> the "preferred" brace style is
[03:28:21] <jmkasunich> if (foo) {
[03:28:24] <Rugludallur> ok, well since I only use vi you don't have to worry about autoformat messing anything up :D
[03:28:24] <jmkasunich> bar
[03:28:26] <jmkasunich> } else {
[03:28:32] <cradek> great
[03:28:32] <jmkasunich> blat
[03:28:33] <jmkasunich> }
[03:28:42] <cradek> heh I messed that up
[03:28:47] <Rugludallur> :D
[03:28:51] <Rugludallur> else if ok in same line ?
[03:29:02] <cradek> sure whatever
[03:29:05] <jmkasunich> yeah
[03:29:13] <cradek> we don't all agree, but we all get along
[03:29:22] <jmkasunich> I do whatever reads better
[03:29:31] <jmkasunich> fi (foo ) {
[03:29:35] <jmkasunich> dofoo
[03:29:43] <jmkasunich> } else if ( bar ) {
[03:29:47] <jmkasunich> dobar
[03:29:57] <jmkasunich> } else if (blat) {
[03:30:00] <jmkasunich> doblat
[03:30:02] <cradek> fe fi fo fum
[03:30:06] <jmkasunich> etc
[03:30:10] <cradek> }
[03:30:29] <jmkasunich> one of my nitpicks is:
[03:30:35] <jmkasunich> if ( foo )
[03:30:38] <jmkasunich> do foo;
[03:30:41] <jmkasunich> morecode
[03:30:52] <jmkasunich> even if its a one line body, I like to use {}
[03:30:58] <cradek> bah
[03:31:07] <cradek> we don't all agree, but we all get along
[03:31:09] <Rugludallur> :D I get the guys don't all agree
[03:31:11] <jmkasunich> right
[03:31:48] <cradek> try to match the surrounding code, unless it's otherworldly, but even if so leave it alone
[03:32:03] <cradek> whatever, no hard rules
[03:32:26] <cradek> code contributions are more important than bickering over whitespace
[03:32:31] <jmkasunich> exactly
[03:33:05] <Rugludallur> ok, but make sure to bonk me if you see anything that should be done a or b ,, I have only been using C since Friday so .....
[03:33:30] <jmkasunich> just look at the 10 lines before and after your addition, and do whatever you think makes the whole thing most readable
[03:33:51] <cradek> ok we'll help however we can
[03:33:58] <jmkasunich> (which will usually be "match the style of those 20 lines)
[03:34:04] <jmkasunich> certainly
[03:34:17] <jmkasunich> its great to have another developer
[03:34:18] <Rugludallur> and I promise if I break the build I will burn in hell
[03:34:26] <jmkasunich> no, no, no
[03:34:38] <jmkasunich> its "I promise if I break the build I will try to fix it"
[03:35:06] <jmkasunich> speaking of that, you should subscribe to the commit list, so you can see changes (and compile farm failure reports ;-)
[03:35:28] <Rugludallur> yes and start joining the dev irc channel probably
[03:35:46] <cradek> sometimes we go there when it's too off-topic and busy here
[03:36:08] <jmkasunich> sure (but you know, I hope, that that channel is for anyone, not just developers)
[03:36:15] <jmkasunich> we just ask that it stay more on topic
[03:37:04] <jmkasunich> do you have the url for the commit list subscribe page?
[03:37:28] <jmkasunich> https://lists.sourceforge.net/lists/listinfo/emc-commit
[03:38:22] <Rugludallur> thx
[03:38:44] <cradek> goodnight guys, it's even getting late here in the "west"
[03:39:02] <Rugludallur> nite
[03:39:03] <jmkasunich> time for me to sleep too
[03:39:07] <jmkasunich> goodnight all
[03:39:49] <Rugludallur> nite
