Back
[00:01:41] -!-
Nick001-Shop has quit [Remote host closed the connection]
[00:14:24] -!-
SolarNRG has quit []
[00:49:56] -!-
servos4ever has quit [Quit: ChatZilla 0.9.85 [SeaMonkey 2.0.11/20101206162726]]
[00:50:35] -!-
rob_h has quit [Ping timeout: 260 seconds]
[01:23:20] -!-
bnl has quit [Ping timeout: 265 seconds]
[01:28:29] -!-
ries has quit [Quit: ries]
[01:33:09] -!-
ries has quit [Client Quit]
[01:33:28] -!-
flyback has quit [Quit: Leaving]
[01:57:05] -!-
ewidance has quit [Read error: Connection reset by peer]
[01:57:46] -!-
ewidance [ewidance!~ewidance@LPuteaux-156-15-52-242.w82-127.abo.wanadoo.fr] has joined #linuxcnc-devel
[01:58:36] -!-
Jim_ has quit [Quit: Leaving]
[02:15:42] -!-
kbarry has quit [Read error: Connection reset by peer]
[02:49:13] -!-
factor has quit [Ping timeout: 244 seconds]
[02:58:16] -!-
sumpfralle has quit [Ping timeout: 246 seconds]
[02:58:37] -!-
seb_ [seb_!~seb@75-166-181-154.hlrn.qwest.net] has joined #linuxcnc-devel
[03:09:01] -!-
JustinXJS has quit [Quit: Leaving]
[03:15:35] -!-
flyback has quit [Read error: Connection reset by peer]
[03:28:29] -!-
demacus has quit [Ping timeout: 245 seconds]
[03:30:50] -!-
steves_logging [steves_logging!~Steve@wsip-70-168-134-18.dc.dc.cox.net] has joined #linuxcnc-devel
[03:35:35] -!-
Tom_L has quit []
[03:49:06] -!-
koax [koax!~kelb@p508D5D77.dip.t-dialin.net] has joined #linuxcnc-devel
[03:51:09] -!-
phantoxe has quit []
[03:52:41] -!-
koax_ has quit [Ping timeout: 265 seconds]
[04:54:03] -!-
kbarry has quit [Quit: ChatZilla 0.9.88.1 [Firefox 10.0.2/20120215223356]]
[04:55:54] -!-
ve7it has quit [Remote host closed the connection]
[04:59:58] -!-
psha[work] [psha[work]!~psha@195.135.238.205] has joined #linuxcnc-devel
[05:01:35] -!-
Thetawaves has quit [Quit: This computer has gone to sleep]
[05:05:00] -!-
pcw_ has quit [Ping timeout: 252 seconds]
[05:05:19] -!-
pcw has quit [Ping timeout: 246 seconds]
[05:31:00] -!-
jbunch has quit [Read error: Connection reset by peer]
[06:09:05] -!-
mhaberler [mhaberler!~mhaberler@089144206069.atnat0015.highway.a1.net] has joined #linuxcnc-devel
[06:12:32] -!-
vladimirek has quit [Remote host closed the connection]
[06:56:44] -!-
capricorn_one has quit [Remote host closed the connection]
[07:17:45] -!-
rob_h [rob_h!~rob_h@5ace7011.bb.sky.com] has joined #linuxcnc-devel
[07:20:23] -!-
Valen has quit [Quit: Leaving.]
[07:42:18] -!-
mhaberler has quit [Quit: mhaberler]
[07:55:04] -!-
The_Ball_ has quit [Ping timeout: 260 seconds]
[08:07:00] bnl is now known as
bootnecklad
[08:07:19] bootnecklad is now known as
bnl
[08:15:43] -!-
mhaberler [mhaberler!~mhaberler@089144206249.atnat0015.highway.a1.net] has joined #linuxcnc-devel
[08:23:17] -!-
factor has quit [Read error: Operation timed out]
[08:27:38] -!-
mhaberler has quit [Read error: Connection reset by peer]
[08:32:40] -!-
pingufan has quit [Quit: Konversation terminated!]
[08:36:22] -!-
emc has quit [Read error: Connection reset by peer]
[08:45:39] -!-
mhaberler [mhaberler!~mhaberler@chello213047166130.1.15.univie.teleweb.at] has joined #linuxcnc-devel
[09:06:23] -!-
mhaberler has quit [Quit: mhaberler]
[09:45:47] -!-
Thetawaves has quit [Quit: This computer has gone to sleep]
[10:22:23] -!-
phantoxe has quit [Remote host closed the connection]
[10:47:14] -!-
sumpfralle has quit [Ping timeout: 245 seconds]
[10:52:13] -!-
sumpfralle1 has quit [Ping timeout: 265 seconds]
[10:53:41] -!-
automata has quit [Ping timeout: 248 seconds]
[10:58:36] -!-
ewidance has quit [Read error: Connection reset by peer]
[11:11:24] -!-
sumpfralle has quit [Quit: Leaving.]
[11:40:57] -!-
maximilian_h [maximilian_h!~bonsai@p549FD163.dip.t-dialin.net] has joined #linuxcnc-devel
[11:41:47] -!-
psha[work] has quit [Quit: Lost terminal]
[11:49:21] -!-
sumpfralle has quit [Quit: Leaving.]
[11:55:29] -!-
sumpfralle has quit [Client Quit]
[11:56:51] -!-
maximilian_h has quit [Quit: Leaving.]
[12:10:28] -!-
pjm__ has quit [Read error: Connection reset by peer]
[12:19:19] -!-
skunkworks__ has quit [Ping timeout: 264 seconds]
[12:46:37] -!-
bedah has quit [Quit: Ex-Chat]
[12:52:40] -!-
psha [psha!~psha@213.208.162.69] has joined #linuxcnc-devel
[12:56:23] -!-
maximilian_h [maximilian_h!~bonsai@p549FD163.dip.t-dialin.net] has joined #linuxcnc-devel
[13:14:47] -!-
ries has quit [Ping timeout: 246 seconds]
[13:51:38] -!-
GoSebGo [GoSebGo!~GoSebGo@184-229-111-236.pools.spcsdns.net] has joined #linuxcnc-devel
[13:57:07] <seb_> crashed my mill last night :-/
[13:57:34] <seb_> a program traversed into a clamp
[13:57:56] <seb_> i didn't notice beforehand because axis doesn't show initial traverse moves
[13:58:33] <seb_> wrecked a junky old .750 endmill, and took a nice big bite out of one of the nuts from my clamping kit
[13:58:45] <seb_> no other damage, as far as i could tell
[13:59:09] <seb_> except my ego got bruised
[14:00:46] <seb_> oh look, there's another seb in that window over there
[14:00:50] <seb_kuzminsky> hi seb!
[14:00:52] -!-
seb_ [seb_!~seb@75-166-181-154.hlrn.qwest.net] has parted #linuxcnc-devel
[14:00:57] -!-
seb_ has quit [Quit: Leaving]
[14:03:50] <jepler> seb_kuzminsky: :(
[14:03:57] <jepler> seb_kuzminsky: I'm glad the damage seems to be minor
[14:04:45] -!-
Nick001 has quit [Ping timeout: 252 seconds]
[14:04:53] <jepler> seb_kuzminsky: "show rapids" is an option in axis, have a look in the view menu
[14:07:55] -!-
Loetmichel has quit [Ping timeout: 264 seconds]
[14:08:46] <cradek> seb_kuzminsky: ouch, but yay that's the good kind of crash.
[14:09:37] <cradek> seb_kuzminsky: is that your first crash? I've rapided a drill chuck down "into" the work (just once)
[14:10:25] <cradek> the drill drilled for a little bit I think, and then the drill chuck jaws drilled for a little bit, and then it ferrored and stopped
[14:11:42] -!-
skunkworks [skunkworks!~skunkwork@68-115-41-210.static.eucl.wi.charter.com] has joined #linuxcnc-devel
[14:13:41] -!-
psha has quit [Read error: Connection reset by peer]
[14:17:40] -!-
psha [psha!~psha@213.208.162.69] has joined #linuxcnc-devel
[14:18:25] <awallin> seb_kuzminsky: that would have been avoided if there was a cutting-simulation mode for LinuxCNC !?
[14:20:32] Jymmm is now known as
Red70sShow
[14:20:38] Red70sShow is now known as
Jymmm
[14:22:18] <cradek> if I understand right, it was the move from the initial tool position to the program's first programmed position, so I don't think any simulation mode would have helped, he just needed more care starting the program
[14:22:39] <cradek> (of course I wasn't there so I'm guessing)
[14:23:18] <seb_kuzminsky> yeah, the initial rapids from the tool change position to set up for the first cut
[14:23:23] <seb_kuzminsky> cradek: i'll look in to that
[14:23:31] <seb_kuzminsky> i mean, jepler: i'll look in to that
[14:23:57] -!-
phantoxe has quit [Ping timeout: 252 seconds]
[14:24:13] <cradek> did your entry move do XY first then Z down? I think that can really help if not
[14:24:49] -!-
Valen has quit [Quit: Leaving.]
[14:25:42] <seb_kuzminsky> my program needed a bunch of traverses, so i defined a traverse z level
[14:26:00] <seb_kuzminsky> then i changed my work holding around, and forgot to change that variable...
[14:26:52] <seb_kuzminsky> so the intended motions were: tool change, rapid z to traverse level, rapid over to the x, y of the first cut, rapid down to work, start cutting
[14:27:12] <seb_kuzminsky> but that first xy move was too low and crashed
[14:27:24] <cradek> doesn't the tool change always happen all the way up?
[14:27:30] <seb_kuzminsky> yes...
[14:27:46] <seb_kuzminsky> i'm in the habit of defining a traverse plane and doing all my rapids there
[14:27:59] <seb_kuzminsky> maybe i should use g53 g0 z0 as my traverse plane
[14:28:00] <cradek> then always first XY then Z would be as safe as possible after a tool change
[14:28:33] <seb_kuzminsky> yes that's true
[14:28:47] <cradek> youtube shows me that starting and ending programs is the crashiest part :-)
[14:28:52] <seb_kuzminsky> heh
[14:29:07] <seb_kuzminsky> my program consists of a bunch of named subroutine calls
[14:29:37] <seb_kuzminsky> the subs all take a "retract plane" or "safe z" plane, and they all start and finish by traversing Z to that plane
[14:29:55] <seb_kuzminsky> the caller just specified too low a traverse plane
[14:30:58] <seb_kuzminsky> this was my second crash
[14:31:08] <seb_kuzminsky> my first crash was much less intense
[14:31:26] <seb_kuzminsky> i traversed a 1/8 endmill into the side of the work
[14:31:28] <cradek> http://www.youtube.com/watch?v=RZB8W81ae_g
[14:31:46] <seb_kuzminsky> snapped off about a 1/2 inch of the cutter, heard it hit the wall of the garage behind me
[14:31:56] <cradek> eek
[14:32:13] <cradek> 1/8 doesn't put up much of a fight! (3/4 either)
[14:33:30] <seb_kuzminsky> cradek: oh snap!
[14:36:20] <seb_kuzminsky> oh man, this made me cringehttps://www.youtube.com/watch?NR=1&feature=fvwp&v=0PzPfzLeDa0
[14:36:32] <seb_kuzminsky> kid gets wrapped up in a lathe :-(
[14:37:32] <cradek> not looking...
[14:39:32] -!-
phantoxe has quit [Remote host closed the connection]
[14:44:03] <seb_kuzminsky> bbl, work
[14:45:05] <skunkworks> I did a g53g0x38y36z24 (which is 'home') and watched it just miss clamping hardware.. It was a few inches past by the time my hand had gotten even close to the estop
[14:46:28] <cradek> retract z first! it's easy!
[14:48:07] <skunkworks> but the shortest distance between 2 points.....
[14:48:09] <skunkworks> ;)
[14:48:37] <cradek> I have a "retract Z" hard button (a touchy feature)
[14:49:00] <cradek> I never program moves after the end of the program at all, just stop
[14:50:02] <cradek> the machine is small enough I can reach it wherever it is, so I just poke retract when I need access
[14:51:40] Cylly is now known as
Loetmichel
[15:03:36] <GoSebGo> I've been meaning to detect double-click on the z+ button on my control panel and hook that to halui mdi g53g0z0
[15:07:05] -!-
nick25 has quit [Client Quit]
[15:16:23] -!-
mhaberler [mhaberler!~mhaberler@195.191.253.94] has joined #linuxcnc-devel
[15:27:36] -!-
n2diy has quit [Quit: Ex-Chat]
[15:28:29] -!-
mhaberler has quit [Quit: mhaberler]
[15:35:53] -!-
mhaberler [mhaberler!~mhaberler@195.191.253.94] has joined #linuxcnc-devel
[15:38:11] -!-
micges has quit [Client Quit]
[16:04:02] -!-
maximilian_h [maximilian_h!~bonsai@p549FD163.dip.t-dialin.net] has parted #linuxcnc-devel
[16:15:36] -!-
m42 has quit [Quit: m42]
[16:21:55] -!-
phantoxe has quit [Remote host closed the connection]
[16:33:38] -!-
ve7it [ve7it!~LawrenceG@S0106001c10b7770f.pk.shawcable.net] has joined #linuxcnc-devel
[16:34:08] -!-
jbunch has quit [Ping timeout: 260 seconds]
[16:45:37] -!-
GoSebGo has quit [Quit: Bye]
[16:45:55] -!-
GoSebGo [GoSebGo!~GoSebGo@184-229-111-236.pools.spcsdns.net] has joined #linuxcnc-devel
[16:56:31] -!-
syyl has quit [Ping timeout: 246 seconds]
[17:11:32] -!-
mozmck has quit [Ping timeout: 244 seconds]
[17:13:42] -!-
mozmck [mozmck!~moses@client-74.117.92.175.dfwtx.partnershipbroadband.com] has joined #linuxcnc-devel
[17:19:32] -!-
mhaberler has quit [Read error: Connection reset by peer]
[17:33:23] -!-
emc has quit [Ping timeout: 245 seconds]
[18:27:11] -!-
phantoxe has quit []
[18:33:53] -!-
mhaberler [mhaberler!~mhaberler@195.191.253.94] has joined #linuxcnc-devel
[18:39:00] <mhaberler> epler: here's a redis example to convey the idea:
http://git.mah.priv.at/gitweb/emc2-dev.git/shortlog/refs/heads/redis-iocontrol - this just publishes tool & pocket info in a redis DB, and uses publish/subscribe to notify clients of changes
[18:39:17] <mhaberler> epler/jepler
[18:44:54] <mhaberler> this is just a demo for you guys to judge the redis fattening factor;) it isnt how its going to work eventually
[18:48:26] -!-
IchGuckLive has quit [Quit: ChatZilla 0.9.87 [Firefox 10.0.2/20120216080748]]
[19:06:56] <jepler> If there's a simple statement of the goal here, it's to remove any hard-coded limitation on the number of tools or pockets?
[19:07:51] -!-
mhaberler has quit [Read error: Operation timed out]
[19:14:16] <jepler> by having working code you're about 10x out in front of anybody else who's ever tried to point us down a path that turns away from NML as the only userspace communication layer
[19:14:41] <jepler> though as far as I can tell, redis is not able to replace, say, the command channel
[19:16:22] -!-
psha has quit [Quit: leaving]
[19:18:40] <jepler> I have way too little knowledge about potential choices of ipc / database / ??? whatever holes that NML currently pokes into that might be replaced with different technologies
[19:19:11] <jepler> so if I look at redis and say I don't like this or that aspect of it, my opinion's not particularly well-informed
[19:21:49] <jepler> but your code shows that it looks not too bad in terms of number of LOCs to write before you have something working and addressing a specific problem
[19:21:55] <jepler> so .. there are my thoughts, for what they're worth
[19:43:38] -!-
pcw has quit [Ping timeout: 240 seconds]
[19:44:13] -!-
pcw_ has quit [Ping timeout: 245 seconds]
[20:04:40] -!-
mhaberler [mhaberler!~mhaberler@195.191.253.94] has joined #linuxcnc-devel
[20:15:33] <mhaberler> jepler: it's about removing the limits on size of tt, and the type and kind of information stored in the tt; for instance, tool image thumbnails, wear information etc by using a late binding vehicle which does work over tcp (separation of gui/task still possible). I dont intend to replace NML in any way as a signalling/comms mechanism esp wrt emcStatus (minus tooltable, offsets etc) - no point here. In theory it's possible but I dont see the up
[20:15:33] <mhaberler> Also, some care must be taken not to introduce race conditions between two comms mechanisms. But I think it is potentially a good supplement to HAL for inter-component comms/state sharing. And yes, the point was to show it's not all that complex to obtain some tangible result
[20:17:53] <mhaberler> one way around the potential race issue is to use redis to share state, but retain nml fields as notification mechanism
[20:28:41] <SWPadnos_> this kind of tool table management may be more apt for a separate application, one which in intended for organizations which might have many tools, and use a subset of them on any given job
[20:29:32] <SWPadnos_> the tool crib might have thousands of tools, and a database of wear and other things (images, so a worker bee can put the right one on the machine, for instance) would be useful there
[20:30:12] <SWPadnos_> Whether that's part of iocontrol is another story. The actual machine will have far fewer tools available to it in a given (G-code) program
[20:30:40] <SWPadnos_> more than 56 or whatever, but probably not so many that a full-on database needs to be handled in iocontrol
[20:36:21] -!-
ewidance [ewidance!~ewidance@montpellier.civade.com] has joined #linuxcnc-devel
[20:37:27] <mhaberler> SWPadnos: as I said: this is a demo - iocontrol has no future anyway
[20:37:56] <jepler> we (you) did ioctlv2 and already it has no future?
[20:39:45] <mhaberler> it has no point as a place to manage the toolstore if the limitations of NML define a funnel through which everything needs to be crammed
[20:40:10] <mhaberler> see configs/sim/remap/iocontrol-removed for an alternative approach
[20:42:45] <SWPadnos_> it's true - a lot of what iocontrol used to do is now done by HAL and the motion controller
[20:42:54] <mhaberler> amen
[20:43:19] <mhaberler> if you want to break the early binding barrier, tool info cant go through NML
[20:43:29] <SWPadnos_> I stick by the idea that tool crib management and toolchanger operation are not the same thing though
[20:44:11] <mhaberler> how does that conradict anything I said?
[20:44:18] <SWPadnos_> there needs to be a way to get tools from the tool store to the machine, but once there, a lot of the information about them is no longer needed (such as images)
[20:44:31] -!-
ewidance [ewidance!~ewidance@montpellier.civade.com] has parted #linuxcnc-devel
[20:44:45] <SWPadnos_> well, it suggests that the approach of making iocontrol database-aware might not be the best approach :)
[20:45:18] <SWPadnos_> make a fantastic tool management database, and an export/import utility that can create tool tables for linuxcnc
[20:45:24] <SWPadnos_> (as one alternative approach)
[20:46:05] <mhaberler> I said: this was a demo for redis binding. It was NOT a suggestion where to place a database.
[20:46:19] <SWPadnos_> note: you did the work, and that's really cool. I guess I'm just brainstorming here, wondering what impact this has on the user, and what they (the users) might want to do with it
[20:46:22] <SWPadnos_> ok, fair enough
[20:46:49] <SWPadnos_> I haven't been keeping up lately, so I'm sure I've missed something
[20:46:59] <SWPadnos_> most things, actually
[20:47:24] <jepler> well, I pretty much feel the same way
[20:50:48] -!-
skunkworks has quit []
[20:51:19] <mhaberler> well, if any of you guys have master lying around, I really suggest you give configs/sim/remap/iocontrol-removed a spin and have a look at customtask.py - this is one of the steps needed to excise the toolstore from iocontrol (and it was a micges idea;)
[20:51:49] -!-
theorbtwo has quit [Ping timeout: 245 seconds]
[20:53:37] <mhaberler> that redis-iocontrol branch was to show jepler redis can be integrated by mortals because we had a recent discussion about it
[20:54:19] <mhaberler> it is never going to wind up in git.linuxcnc.org
[20:54:34] <SWPadnos_> you're mortal?
[20:54:36] <SWPadnos_> huh
[20:54:38] <SWPadnos_> :)
[20:55:28] <mhaberler> well, mortals cant understand the control flow in Axis, I dont either, so I reserve that right;)
[20:55:52] <jepler> that's because it's a big ball of mud
[20:56:07] <SWPadnos_> mud flows are dangerous
[20:56:15] <jepler> it has more to do with having years of experience as a dung beetle than being superhuman
[20:56:57] <SWPadnos_> at least you're not looking at 18000-line files that are full of #define SOME_TOOLKIT_FUNCTION_WITH_A_NAME_M() some_toolkit_funtion_with_a_name()
[20:57:02] <mhaberler> I'm not blaming you - it was that unfortunate suggestion using tcl as primary I/f layer which lead to the language breaks which make it incomprehensible
[20:57:47] <jepler> #define WhoWritesThiShit WhoWritesThisShitW
[20:58:19] <SWPadnos_> yeah, more or less
[20:58:26] <SWPadnos_> and multiple levels deep
[20:59:02] <jepler> oh that reminds me, I need to blog the AVR I/O pin access macros that I'm certain are not an original inspiration, but I can't find the original anymore
[20:59:29] <SWPadnos_> (so we have driver level functions with corresponding FUNCTION_M macros, which are often defined as the same thing at a driver level, like #define TOOLKIT_INIT_M() DRIVER_INIT_M(), and DRIVER_INIT_M is driver_init()
[20:59:32] <SWPadnos_> argh
[21:00:11] <SWPadnos_> or worse #define TK_INIT_M() tk_init(), tk_init is a one-liner that called DRIVER_INIT_M(), which is a define to driver_init()
[21:00:14] <SWPadnos_> argh ++
[21:01:06] <SWPadnos_> and then put 10 sets of those in the same file, with #ifdefs for different CPUs or products
[21:01:06] <jepler> the neat part is where you can write #define LED B, 3
[21:01:17] <jepler> and then AS_OUTPUT(LED); /* f: sbi DDRB, 3 */
[21:01:30] <jepler> the terrible part is when you try to read the macros to understand how they do that
[21:01:35] <SWPadnos_> heh
[21:01:49] <jepler> hint: magic + gnomes
[21:01:49] <SWPadnos_> can you tell them the polarity? (ie, on=1 vs on=0)
[21:02:02] <SWPadnos_> gnome for AVR. now there's a bad idea :)
[21:02:26] <jepler> that's not a feature that was relevant to me, but it would fit in the design if you went back in and made a pin definition into a triple instead of a pair
[21:03:15] <jepler> but there are 5 levels of macros to understand first
[21:03:25] <SWPadnos_> trivial
[21:03:30] <jepler> sounds like you are probably a 6th level macro user at this point
[21:03:42] <SWPadnos_> 8th level, but only in defensive macro
[21:03:57] <SWPadnos_> I try to stay away from offensive macros
[21:05:18] <jepler> http://chainsawsuit.com/2011/08/15/humans-and-habitats/
[21:05:22] <SWPadnos_> I'd love to figure out an easy way to use sparse arrays on an AVR
[21:06:09] <SWPadnos_> like, I have a bunch of non-contiguous 8-bit codes, and I want to store some stuff about those codes, but I don't want to use 256 elements in the array, since I only have 50 or 100 codes
[21:07:06] <jepler> what are your access requirements? do you know the number of used codes statically? their locations?
[21:07:30] <SWPadnos_> the code numbers are known at compile time, and therefore the total number of them as well
[21:07:31] <jepler> (I mean, their indexes)
[21:07:40] <jepler> then what you need is a perfect hash
[21:07:41] <SWPadnos_> access time is pretty important
[21:07:59] <jepler> so that instead of accessing arr[i] you access arr[H(i)]
[21:08:03] <SWPadnos_> sure
[21:08:07] <SWPadnos_> hmm
[21:08:23] <jepler> but you have to design the hash function H(i) based on the domain of i
[21:08:33] <SWPadnos_> sure
[21:10:39] <jepler> "perfect hash" seems to be turning up hits about string -> integer mapping, not integer->integer mapping
[21:10:52] <SWPadnos_> yes
[21:11:36] <SWPadnos_> though I suppose that with the overhead of a single 256-byte array (only 128 words in an AVR), you can map any set of keys to specific indices in a shorter array of larger structures
[21:11:38] <jepler> though if arr stores significantly more than 1 byte for each index, then maybe arr[h[i]] is feasible
[21:11:54] <jepler> and yes as you point out this could be in flash rather than ram
[21:11:56] <SWPadnos_> that gives O(1) lookup, and also O(1) program complexity
[21:11:59] <jepler> arr[pgm_read_byte(h+i)]
[21:12:43] <SWPadnos_> yeah, index=index_table[key], then access any other (short) tables as table[index]
[21:12:51] <jepler> if you can spare the flash, then in terms of instruction count it's probably faster than any H(i) you could make out of arithmetic
[21:12:56] <SWPadnos_> sure
[21:13:29] -!-
SolarNRG has quit [Ping timeout: 245 seconds]
[21:13:31] <SWPadnos_> and given all the case statements in this code I'm looking at, I'll bet a 256-byte remapping table and the extra lookup to use it would save a bit of code
[21:14:14] <SWPadnos_> it's amazing how bad some compilers are (commercial ones costing $1500-$4000)
[21:15:29] -!-
theorbtwo has quit [Ping timeout: 255 seconds]
[21:17:05] <jepler> and if flash is really at a premium, maybe you can get away with two smaller tables: index = index_table2[index_table1[key >> 4] + (key & 0xf)]
[21:17:35] <jepler> index_table1 has at most 16 entries, and depending on your luck about the distribution of the keys index_table2 could have many or only a few indices
[21:18:28] <SWPadnos_> actually, these are command codes which are separated into groups by the top nibble (or 3 bits, depending), and which are generally sequences from those base numbers
[21:18:37] <SWPadnos_> so that would work quite well
[21:18:44] <jepler> key >> 4 fits the 'swap' instruction nicely
[21:18:48] <SWPadnos_> indeed
[21:18:59] <jepler> constructing the index_tables is going to be the next thing you spend too much time getting right
[21:19:20] <SWPadnos_> that's one place where assembler shines :)
[21:20:09] <jepler> how many levels do you have in macro assembler?
[21:20:10] <SWPadnos_> actually, a table of 16 RAM values can be generated as part of the init code
[21:20:55] <SWPadnos_> put the actual codes in the info table (good for sanity anyway), and search through the master table for places where (code>>4) != (last_code >>4)
[21:20:59] <SWPadnos_> save the indices
[21:21:04] <SWPadnos_> oh, I don't know
[21:21:20] <SWPadnos_> I did things where I kept a running counter of screen definitions, for example
[21:21:31] <SWPadnos_> .def CurrentScreen = CurrentScreen +1
[21:21:51] <SWPadnos_> and inside my data statements, I could chain to the next screen with CurrentScreen + 1
[21:21:58] -!-
vladimirek has quit [Remote host closed the connection]
[21:22:11] <SWPadnos_> also, I can make tags like MainScreen = CurrentScreen
[21:22:30] <CIA-51> 03seb 07v2.5_branch * r6671a7bc10b3 10/docs/src/hal/comp.txt: docs: branding fixes
[21:22:30] <SWPadnos_> and use those in screen defs that are "far away"
[21:23:15] <SWPadnos_> this was for an AVR based menuing system
[21:23:58] <jepler> this sounds vaguely like something you talked about once
[21:24:15] <SWPadnos_> could well be
[21:24:44] -!-
cpresser_ has quit [Ping timeout: 260 seconds]
[21:26:33] <SWPadnos_> That project was 800k of AVR source, which was just about the limit for an assembler project. I think we had decided that the next version would be in C, but we never got there :)
[21:26:43] <SWPadnos_> err, AVR assembler source, that is
[21:37:41] -!-
FinboySlick has quit [Quit: Leaving.]
[21:46:32] bnl is now known as
Quad
[21:46:37] Quad is now known as
bnl
[21:52:09] <jepler> well, I couldn't resist writing the two-level table generator in crappy Python
[21:55:09] -!-
GoSebGo has quit [Quit: Bye]
[21:55:19] <jepler> http://emergent.unpythonic.net/files/sandbox/tabtab.py
[21:55:21] -!-
GoSebGo [GoSebGo!~GoSebGo@184-229-111-236.pools.spcsdns.net] has joined #linuxcnc-devel
[22:07:41] -!-
DJ9DJ has quit [Quit: bye]
[22:17:30] -!-
micges [micges!~x@user-46-112-93-219.play-internet.pl] has joined #linuxcnc-devel
[22:20:31] -!-
ewidance [ewidance!~ewidance@montpellier.civade.com] has joined #linuxcnc-devel
[22:26:02] -!-
isssy has quit [Quit: Bye Bye]
[22:35:35] -!-
GoSebGo has quit [Quit: Bye]
[22:35:48] -!-
GoSebGo [GoSebGo!~GoSebGo@184-229-111-236.pools.spcsdns.net] has joined #linuxcnc-devel
[22:40:29] -!-
mhaberler has quit [Quit: mhaberler]
[23:03:30] -!-
syyl_ws has quit [Remote host closed the connection]
[23:03:55] <CIA-51> 03seb 07v2.5_branch * rb371ff0ebfdb 10/docs/src/hal/comp.txt: docs: whitespace cleanup in a comp example
[23:18:13] -!-
bedah has quit [Quit: gn8]
[23:22:58] -!-
servos4ever has quit [Quit: ChatZilla 0.9.85 [SeaMonkey 2.0.11/20101206162726]]
[23:42:01] -!-
micges has quit [Quit: Ex-Chat]
[23:51:02] <cradek> what's the smart way to merge a po file where pretty much every comment conflicts?
[23:51:08] <cradek> (fr.po, 2.5->master)
[23:58:14] -!-
mhaberler [mhaberler!~mhaberler@195.191.253.94] has joined #linuxcnc-devel