#emc-devel | Logs for 2010-08-02

[01:18:43] <skunkworks> 2 days of playing around with lucid - no issues.
[01:19:02] <skunkworks> none at all. And it shuts down the computer! ;)
[03:23:58] <ries> skunkworks: unplug it??
[12:47:19] <alex_joni> http://picasaweb.google.com/TalentTrainingCenter/2010#5497909274170368258
[12:49:47] <alex_joni> summer camp in saudi arabia, learning Axis/emc2 and cooltool mills/lathes
[13:27:26] <skunkworks> alex_joni: that is cool :)
[13:28:21] <cradek> yep that is slick.
[13:28:21] <JT-Work> skunkworks: I had the same problem of 10.04 shutting down my computer on one of the installs I had tried
[13:29:47] <skunkworks> ?
[13:30:24] <JT-Work> was that you saying your computer shut down last night or do I need a #5?
[13:30:43] <skunkworks> I meant that the lucid actually powers off the computer when it is shutting down.
[13:30:46] <skunkworks> which is cool
[13:30:57] <JT-Work> oh ok
[13:31:02] <skunkworks> So far - I have not had any performance problems with lucid.
[13:31:33] <JT-Work> me neither other than getting a good install which I seem to have now :)
[13:31:34] <skunkworks> (other than my laptop - but who cares about that ;))
[13:34:13] <Dave911> alex_joni: I had a friend go to Saudi Arabia last year to do a machine startup in a concrete plant... He said they are building and installing city infrastructure like crazy .. putting in sewers, constructing factories, etc Lots of money going into
[13:34:38] <Dave911> basic industrial infrastructure ...
[13:34:46] <skunkworks> JT-Work: did you see http://www.electronicsam.com/images/KandT/conversion/servo/x-zservo_mount
[13:34:53] <skunkworks> Dave911: ^
[13:35:46] <JT-Work> skunkworks: is that link missing something?
[13:35:49] <Dave911> skunksworks ... that link is incomplete? it is asking if I want to save it ..??
[13:35:55] <JT-Work> me too
[13:36:04] <cradek> save it and add a .jpg extension
[13:36:23] <cradek> skunkworks just got lazy and didn't type a good filename
[13:37:14] <JT-Work> skunkworks: getting closer!
[13:38:16] <Dave911> Good thing you don't need to change those belts very often! ;-) Did you find a source for belts?
[13:39:05] <skunkworks> oops sorry
[13:39:39] <Dave911> I have a source for reasonably priced polyurethane belts in Georgia I believe...
[13:39:46] <skunkworks> that is so wierd. I didn't even notice that. IE brings it right up.
[13:39:56] <Dave911> NP
[13:40:15] <skunkworks> do you know if they sell H in 1/2 inch increments?
[13:42:03] <Dave911> http://beltcorp.com/ Don't know ... good folks to talk to though.. If they can't do it ... probably can't be done from what I have seen.
[13:42:14] <skunkworks> cool - thanks
[13:43:19] <Dave911> Have you talked to Gates about what they have? They tend to be expensive though .... for special stuff.
[13:44:25] <skunkworks> we don't really need it in 1/2inch increments.. but if we can get them cheap - it would put the servos right in the middle of the slots.
[13:45:29] <Dave911> Makes sense.. those belts don't stretch much though .. until they are about to break..
[13:46:28] <skunkworks> heh
[13:49:09] <Dave911> skunkworks: Another good source of belts, pulleys, etc... is Motion Inc. They are nationwide and the local guy will track down just about anything for me.. They try really hard to stay competitive cost wise also..
[13:49:40] <jepler> btw I've gotten a few pieces of positive feedback about 10.04 in private e-mail
[13:49:50] <jepler> imo things are looking very positive at this point
[13:50:17] <skunkworks> yes - I have a few local people I need to call.
[13:50:36] <Jymmm> skunkworks: Who you gonna call????
[13:50:50] <skunkworks> jepler: neat!
[13:51:29] <JT-Work> my last install on the zotac was stock 10.04 + your script... all working fine and playing nice with everything else including virtualbox ose
[13:52:22] <skunkworks> so - put 512 into the same motherboard here - booted the livecd and it still has good latency. Must be the installed version uses a different video driver or something.
[13:53:59] <jepler> skunkworks: that's weird
[13:54:34] <skunkworks> I could try installing it on this motherboard - just to make sure the latency jumps. for s&g's
[13:57:39] <jepler> skunkworks: to check the "video driver" theory, you could pastebin the /var/log/Xorg.0.conf from the live system and from the installed system
[13:58:12] <alex_joni> maybe the exact hardware isn't exactly the same
[13:59:27] <skunkworks> jepler: will do
[13:59:39] <skunkworks> identical motherboards.
[14:00:00] <alex_joni> that is hard to check ;)
[14:00:02] <skunkworks> but I see what you are saying...
[14:00:04] <skunkworks> ;)
[14:05:55] <SWPadnos> skunkworks, did you have internet connectivity during installation?
[14:06:27] <skunkworks> I think so. - yes I am sure I did.
[14:06:43] <SWPadnos> ok, in that case you probably got some updates
[14:07:01] <SWPadnos> the new installer downloads and installs updates during install (probably to save a reboot)
[14:07:38] <Jymmm> SWPadnos: good to know.
[14:07:59] <SWPadnos> yeah, it's nice, but it can also take some extra time
[14:08:26] <Jymmm> SWPadnos: Hey, if it's "hands off", works for me =)
[14:08:29] <skunkworks> I can try that also - this one isn't on the net
[14:08:49] <SWPadnos> it is hands off, but I don't recall if it tells you why it's taking so long :)
[14:09:10] <Jymmm> SWPadnos: > 40 minutes?
[14:09:13] <SWPadnos> gotta run, just thought I'd mention the "instant updates" thing
[14:09:29] <SWPadnos> no, 10-20 usually, but I've never tried on dial-up ;)
[14:09:39] <Jymmm> dial what?
[14:13:06] <Jymmm> SWPadnos: One of these? http://www.sciencemuseum.org.uk/images/object_images/535x535/10304636.jpg
[15:13:07] <micges> hi guys
[15:13:27] <alex_joni> hi
[15:15:02] <micges> we have in Poland useless hostings services, can you recommend me some good europe wide ?
[15:16:08] <micges> hmm wrong channel
[15:16:27] <skunkworks> heh
[15:21:15] <skunkworks> so - with it installed - still has good latency. (no internet access.) and I am saving the Xorg.0.conf files from each. Next - update.
[19:15:25] <CIA-2> EMC: 03micges 07iotask_remove * rc09df8d16711 10/src/emc/ (16 files in 6 dirs): Move lube functionality to motion
[19:19:45] <robh__> cradek, i did find one bug in cycles, G28 does not cancel a cycle, EMC will do the G28 move but any new coordinate it will reenter the last cycle. G00 cancels a cycle as exspected. (did not test G02/G03)
[19:20:47] <cradek> do you mean three lines like G81 X0 Y0 Z-1 R1 F10 / G28 / X1
[19:21:09] <cradek> (if so I'm not sure what I even expect that to do)
[19:22:00] <cradek> micges: the lube output is silly anyway - I think it comes on with machine on, and never does anything special
[19:22:15] <micges> yes
[19:23:01] <micges> lubel level isn't also nowhere displayed
[19:23:36] <robh__> yes cradek, G28 Z0 / X Y EMC does the G28 as exspected, like Z0 but it does not exit the caned cycle, should tell you in that fanuc manual not sure what page dont have one in front of me, should do as G00 does or apeared todo right
[19:23:40] <cradek> micges: I wonder what it was supposed to do
[19:23:49] <cradek> micges: (I handled lube and lube level in ladder on my mill)
[19:24:25] <micges> I think it is to signal low lube level ?
[19:24:41] <cradek> I mean what's supposed to happen when lube is low?
[19:25:20] <micges> now it's nothing, maybe it was meaning in the pas
[19:25:22] <micges> t
[19:25:42] <robh__> cradek, one of our machines with lube low on, goes into single block mode, which is most annoying maybe they ment todo something like that
[19:26:06] <cradek> robh__: if anything might be a bug in G28 (should switch to G0) but I'm not sure
[19:26:08] <robh__> then that is simens for you, does it on coolant low also
[19:26:18] <cradek> robh__: bizarre
[19:26:42] <cradek> I set it up so I can't come out of estop but otherwise it continues when lube is low
[19:27:15] <cradek> another good alternative I think is that the spindle won't start when lube is low (but will continue running if already running)
[19:27:30] <cradek> that's how the BOSS8 worked
[19:27:57] <robh__> i just put a indicated on a panel like old machine, that will flash on lube low i guess its all personal tastes
[19:28:18] <cradek> that plus won't come out of estop sounds perfect
[19:28:37] <cradek> if it starts blinking you can go fill it, but if you forget, it won't run tomorrow
[19:29:44] <robh__> nuthing worse than wondering why a machine will not run when there is no clear message
[19:30:12] <cradek> I had that the other day - took me a few minutes to figure out the vfd was faulted
[19:30:18] <alex_joni> robh__: heh, yeah.. we had that on some older robots
[19:30:25] <cradek> (but better than a crash because the spindle didn't start)
[19:30:36] <alex_joni> if you hit a hardware limit it will complain, but if you reboot the control it would just sit there silently
[19:31:06] <alex_joni> and since most "operators" always reboot the control to see if it fixes things (which it doesn't)...
[19:31:21] <robh__> yea the old turn it on and off trick
[19:31:49] <micges> often it works even now :)
[19:31:56] <cradek> heh jr won't tell you it's on a limit either - just won't come out of estop
[19:32:30] <alex_joni> see..
[19:32:36] <robh__> something i need to add on my mill a override button as its all hard wired in the estop chain the switch's
[19:32:51] <cradek> that's how mine is (momentary override button on the side of the control box)
[19:33:06] <cradek> hold button, estop reset, carefully jog off limit, release button
[19:33:12] <micges> I think it can be added message of low lube
[19:33:32] <micges> (but op will ignore it)
[19:42:52] <micges> cradek: I think we can add something useable to lube in emc
[19:43:47] <micges> soemthing most common on mill centers
[19:55:58] <cradek> how about when you try to turn machine on, if lube is low, you get a message instead of machine coming on
[19:57:14] <micges> I like it
[19:57:46] <cradek> or, if you want it in motion instead of task, you could give the error when you try to go into coordinated mode
[19:58:10] <cradek> or, let people do it in ladder however they want
[19:58:13] <cradek> I have mixed feelings
[20:00:21] <micges> I think I'll post question to emc-devel
[20:01:02] <skunkworks_> cradek: don't you need a nice M35 spindle lock/orient? ;) I started to think about how compicated that would be. Like - it gets turned off by spindle on, spindle off, tool change complete.. maybe... I think a user defined mcode will work just fine.
[20:01:28] <cradek> skunkworks_: I have a toggle switch on the panel that does orient
[20:01:43] <skunkworks_> and your tool change automagically does it?
[20:01:53] <cradek> yes
[20:02:09] <cradek> orient switch locks out spindle on (of course)
[20:02:54] <skunkworks_> heh - how does it orient? mine is going to need the vfd to do it.
[20:03:52] <cradek> there is a pin with two switches "fully out" and "fully in"
[20:04:05] <skunkworks_> mine needs it to be in a certain gear, a lock solinoid turned on and the vfd nees to be in super slow creap.
[20:04:16] <cradek> it waits for spindle to be stopped - turns on air that pushes pin - command vfd to "jog" - wait for pin to go in - turn off vfd
[20:04:27] <skunkworks_> ah - ok
[20:04:46] <cradek> spindle will not run unless pin is fully out
[20:05:13] <skunkworks_> similar - but mine the needs the vft to keep it against the lock
[20:05:22] <cradek> eww
[20:05:52] <skunkworks_> worked ok with the GE control. (we had added the vfd while still using the old control)
[20:06:24] <cradek> I guess as long as you don't need it oriented for any longer than a tool chagne takes
[20:06:29] <robh__> skunkworks_, it should be a M19 for spindle orientation realy i feel, which then would be used in the boring cycles where you need to orientate the spindle before coming out.
[20:07:09] <skunkworks_> our vfd didn't seem to have any issue with it stalled at that low of speed.
[20:08:02] <skunkworks_> robh__: I don't care what it is. (our 60's vintage control used M35)
[20:08:05] <robh__> did you see a quick little video i put up, shows vfd doing orientation better now, http://www.youtube.com/watch?v=D6dGYsXAPIU
[20:08:22] <skunkworks_> robh__: of course I did. :)
[20:08:28] <skunkworks_> nice!
[20:09:24] <skunkworks_> I don't know how well we could orient strictly with the spindle motor. there is a ton of gear lash between the motor and the spindle.
[20:09:28] <robh__> yaskawa seem todo better VFDs aimed at what we wanted todo there but it gets the job done and it makes parts perfectly fine :)
[20:09:47] <skunkworks_> and the cog is much more consistant. :)
[20:11:47] <robh__> i think its where you need a VFD than can change modes like someo f yaskawas and others, so you can get the fine position in low speed ranges with alot of torque when in high speed you can switch faster
[20:12:27] <robh__> but our VMC with a gearbox does orientation fine and there is quite abit of backlast in its gears also, pickup is on the spindle
[20:15:41] <robh__> we just picked up a 2nd hand control techniques DC mentor2 drive for a lathe so will soon be playing with C axes on a lathe if it can do what we want it todo, which control techniques said it can
[20:18:10] <skunkworks_> sounds like fun :)
[20:18:36] <skunkworks_> The spindle shift/lock logic is going to be a comp
[20:21:00] <robh__> what VFD are you running
[20:21:30] <skunkworks_> it is an older toshiba tosvert
[20:23:16] <skunkworks_> tosvert? That doesn't sound right
[20:24:13] <skunkworks_> yep that is righ. like this http://cgi.ebay.com/Toshiba-Tosvert-VFSX-2001P-VF-SX-Transistor-Inverter-/370073815113?cmd=ViewItem&pt=LH_DefaultDomain_0&hash=item562a1e4849
[20:24:16] <skunkworks_> except 5hp
[20:24:56] <skunkworks_> pretty basic vfd by todays standards.
[20:25:06] <skunkworks_> probably mid to late 90's
[20:28:02] <robh__> i never looked at there stuff, i know some Brother CNC have some Toshiba servos as i was wundering whos stuff they used to make there machiens so quick.
[20:47:51] <andypugh> You can almost orient with just a VFD and an encoder
[20:48:26] <andypugh> You saw the video where I tried to orient with my 1990s VFD?
[20:49:01] <andypugh> I reckon that a vector drive would work a lot better, the one I have doesn't even try below 10Hz demand.
[20:50:46] <skunkworks_> I remember that.
[20:51:29] <skunkworks_> rolands mazak did a orient using the vfd. It was slow. (but I don't think it was optimized much)
[20:52:01] <andypugh> I needed to set up an inverse dead-band for mine, but couldn't be bothered.
[20:56:09] <robh__> i found it worked better if i spun the motor todo it check out my video andypugh
[20:56:24] <jepler> andypugh: should I go ahead and put bldc_sine on master?
[20:56:29] <robh__> i tryed in vector mode, yes it worked grate, but can not do more than 4000rpm in vector
[20:57:15] <andypugh> Is that VMC video posted to the forums today?
[20:58:02] <andypugh> jepler: I see no harm in doing so, people have to choose to use it, so it can't do any harm to the unsuspecting.
[20:58:03] <robh__> last night on my leadwell topic
[20:58:37] <jepler> andypugh: OK, I'll push it in a few
[20:59:45] <andypugh> If I ever do a toolchanger I suspect it will rely on a sprung rack and letting the holders drop in as the spindle slowly turns.
[21:04:48] <jepler> CIA-2: you here?
[21:05:48] <robh__> i think a servo like VFD would work alot better but then we are talking 3x the price we did look at them.
[21:07:50] <CIA-2> EMC: 03jepler 07master * r78c32f269708 10/src/hal/components/bldc_sine.comp: bldc_sine: Commutation for BLDC with encoder feedback
[21:08:09] <jepler> andypugh: thanks for your latest contribution, and for having patience while I dragged my feet about it.
[21:08:39] <andypugh> No worries, even I am not ready to use them yet.
[21:15:48] <CIA-2> EMC: 03micges 07master * r59d86dca6450 10/src/emc/motion/usrmotintf.cc: Remove unused variable
[21:26:02] <cradek> that's awfully cool that you can run an ac servo with a dumb driver
[21:27:30] <andypugh> There is no reason that the same setup with a different comp couldn't take the place of a spindle VFD.
[21:28:07] <andypugh> No need for encoder feedback, just spin at the requested frequency.
[21:52:19] <CIA-2> EMC: 03jthornton 07v2.4_branch * r66893f0e9cf9 10/docs/src/hal/ (3 files in 2 dirs): add second reader to graphic
[22:34:41] <seb> i'm confused by what just happened on the buildbot
[22:36:12] <seb> andypugh committed a change to bldc_sine.comp, which made the build fail with this error: http://emc2-buildbot.colorado.edu/buildbot-admin/builders/lucid-i386-sim/builds/51/steps/compile/logs/stdio
[22:36:41] <seb> then micges committed something else, and it didnt fix the problem
[22:36:46] <andypugh> It asks for a login.
[22:37:06] <alex_joni> http://emc2-buildbot.colorado.edu/buildbot/builders/lucid-i386-sim/builds/51/steps/compile/logs/stdio
[22:37:38] <seb> sorry
[22:37:47] <seb> the non-admin webpage is more useful...
[22:38:06] <seb> but anyway, the problem went away when JT committed something to the docs...
[22:38:17] <alex_joni> hmm
[22:38:32] <andypugh> Does the buildbot build with comp?
[22:38:41] <alex_joni> on that note.. the email from buildbot only had this page linked: http://emc2-buildbot.colorado.edu/buildbot/builders/master-checkin/builds/422
[22:38:54] <alex_joni> seb: how do you get from there to the stdio log ?
[22:39:17] <andypugh> It almost looks like it is compiling the postprocessed .c file, then moving on to the .comp file?
[22:39:57] <seb> the buildbot just runs make
[22:40:04] <seb> it uses the same build system we all use
[22:40:20] <seb> it looks like comp doesn't understand the "bool" data type in the new bldc_sine.comp component?
[22:40:27] <seb> if i switch it to "int" it works fine on my machine
[22:40:44] <andypugh> OK. I admit it is all amystery to me. I have only ever built the .comps with "comp"
[22:40:52] <seb> oh, JT committed to 2.4, which doesnt have the new broken comp
[22:41:06] <seb> andypugh: the buildbot also uses comp
[22:41:28] <seb> does comp on your machine work with the bldc_sine.comp file? it doesnt complain about the bool?
[22:42:27] <andypugh> Not that I have ever noticed
[22:42:29] <seb> alex_joni: it's a known problem with our version of buildbot that it mails out failure emails that dont actually link to the failure messages :-(
[22:43:41] <andypugh> I would check, but I don't have any working emc machines at the moment, having lost 2 power supplies (and the cable box) over the course of 4 days, at different times.
[22:44:51] <andypugh> Let me try it in a VM.
[22:45:44] <alex_joni> seb: ah ok.. maybe they'll fix it eventually
[22:46:06] <jthornton_> what did I do?
[22:46:36] <seb> andypugh: according to http://linuxcnc.org/docs/2.4/html/hal_comp.html, the "type" of a "variable" can be any valid C type, and it looks to me like it doesnt like "bool" (even though section 1.5 says bool is ok) but it does like "int"
[22:46:46] <seb> jthornton_: nothing, false alarm, i'm an idiot :-)
[22:49:43] <seb> this is strange: comp chokes on bldc_sine.comp on sim, but not on realtime
[22:49:59] <seb> the sim comp doesnt like the variable type "bool", but the rt comp likes it
[22:50:11] <seb> i gotta run, i'll check back later tonight
[22:50:21] <alex_joni> maybe bool i sdefined in rtapi_math or such for RT
[22:50:23] <andypugh> the .comp compiles perfectly happily on a freshly-installed lived-cd install
[22:50:30] <jthornton_> seems I ran into bool with the thc comp
[22:50:32] <jthornton_> and had to change it to int or bit or something like that
[22:51:21] <andypugh> bldc_sine in a sim config is meaningless anyway, I think?
[22:51:44] <alex_joni> it can drive a simulated motor :)
[22:52:30] <andypugh> Though I guess it doesn't explicitly require the Mesa hardware, it could drive software pwmgens
[22:53:25] <andypugh> Looks like I made the mistake of assuming that because the docs said it was OK, and that it compiled on my machine, that it was OK.
[22:56:38] <jthornton_> do I need to change the manual to remove the bool reference?
[22:57:28] <andypugh> Perhaps the cahnge should be in the sim headers so that what works in RT also works in sim?
[22:58:23] <andypugh> Using an int (and the docs only admit to the existence of 32 bit ints) to store the value of a HAL "bit" pin seems non-intuitive
[23:05:22] <jepler> argh, should have tested more :-/
[23:05:27] <jepler> will commit a fix
[23:06:54] <CIA-2> EMC: 03jepler 07master * r23de0249fa1a 10/src/hal/components/bldc_sine.comp: fix build errors on RT systems
[23:08:51] <andypugh> Technically it is sim systems that need that fix, it compiles OK on RT systems.
[23:11:07] <andypugh> (Or so Seb said, I don't have a sim system)
[23:11:19] <jepler> oops
[23:11:28] <jepler> oh well
[23:12:04] <andypugh> Yeah, it's not a problem, just me exercising my inner pedant
[23:12:56] <alex_joni> jthornton_: judging by jepler's fix it's best if you remove the bool reference
[23:13:02] <jthornton_> ok
[23:13:33] <andypugh> Though I would still always prefer a bit to be stored in a bool, even if a bool is really an int. I am not comfortable that only one bit pattern is false, and 255 are true, it seems "wrong"
[23:15:43] <alex_joni> thtat's for 8bit
[23:16:41] <andypugh> Is it safe to assume that ints set to "true" always contain the same value? So that X == Y will always work? I can see that they could both be non-zero and "true" but not actually equal if they are typed to int not bool?
[23:19:14] <andypugh> Do you need to typecast to boolean before comparison to guarantee the right result? Is that even possible without a boolean data type?
[23:19:31] <andypugh> Do I worry too much?
[23:22:47] <alex_joni> yup
[23:23:04] <alex_joni> ==0 and !=0 that's all you need
[23:24:39] <andypugh> I am not sure that really addresses my question.
[23:25:00] <alex_joni> what's true?
[23:25:16] <alex_joni> usually there's a #define true 1
[23:25:18] <CIA-2> EMC: 03jthornton 07v2.4_branch * rc3c8d9a74249 10/docs/src/hal/comp.lyx: replace the reference to bool with int
[23:25:18] <alex_joni> or such
[23:25:19] <CIA-2> EMC: 03jthornton 07v2.4_branch * r1bd62994ff1f 10/docs/src/hal/comp.lyx: markup fixes
[23:25:32] <alex_joni> so a=true; b=true; will always have the same value
[23:25:35] <alex_joni> so a==b
[23:26:05] <andypugh> I am storing the value of a HAL "bit" pin
[23:34:09] <andypugh> the line "if (init && !old_init)" is completely unambiguous with a boolean data type. I am not sure what it means with an integer data type.
[23:35:20] <alex_joni> same thing
[23:36:28] <andypugh> So even if old_init is 00000001 there is no danger of !old_init being 11111110 and also "true"?
[23:37:05] <alex_joni> ! and ~ are 2 different operations
[23:37:20] <alex_joni> !00000001 -> 0
[23:37:33] <alex_joni> ~00000001 -> 11111110
[23:38:37] <andypugh> Part of my unease is that I am used to "true" being -1, and I think SQL uses 0, -1 and "oops"
[23:39:50] <andypugh> Anyway, this is just an intellectual discussion, I am sure you all know better than I do how to fix my code.
[23:40:48] <andypugh> But it does seem to me that the natural data type to store HAL "bit" pins is the "bool" not the "int"
[23:41:21] <jthornton_> its too late andypugh I've changed the manuals so it has to be true now :)
[23:42:04] <jthornton_> * jthornton_ thinks it is time to heat up the pizza stone
[23:42:07] <andypugh> I'll shit up and go to bed then.
[23:42:13] <jthornton_> hehe
[23:42:18] <andypugh> (oops, "shut" up)
[23:42:31] <jthornton_> aw, just come over for a pint and some pizza
[23:42:47] <alex_joni> typedef volatile unsigned char hal_bit_t;
[23:43:04] <andypugh> It's a long swim.
[23:43:05] <alex_joni> so even hal_bit is 8 bit ;)
[23:43:24] <jthornton_> but worth it I bet :)
[23:43:46] <Jymmm> jthornton_: s/pint/full sized keg/ & s/Pizza/12 hour pit cooked bbq/
[23:44:01] <jepler> sizeof(bool) >= sizeof(char), so a bool has to be at least 8 bits as well.
[23:44:07] <jthornton_> not tonight Jymmm
[23:44:18] <Jymmm> jthornton_: headache?
[23:46:10] <andypugh> Oh, I am well aware that bool datatypes are 8 bits, but they are only interpreted to have two values. Whereas ints have lots of values, which may take 2 values in some expressions, and lots of values in others which use the exact same variable. It just seems, well, messy.
[23:46:49] <andypugh> Maybe I just need to look at it as "overloading" and pretend it is clever and modern?
[23:47:38] <alex_joni> futuristic
[23:49:04] <andypugh> Though, more seriously, if hal_bit_t is a char, shouldn't the comp use a char to store the old value?
[23:49:33] <andypugh> If nothing else it saves a type conversion, I think?
[23:53:19] <andypugh> (In case it is not obvious, I am not trying to be argumentative or critical, I am asking questions from a position of ignorance in an attempt to learn more about C)
[23:55:04] <andypugh> But now I do need to log off. Goodnight all.
[23:55:17] <alex_joni> night