Back
[00:00:31] <jepler> would "reentrant" allow adding multiple times to one thread? I thought about this once as a way to do multiple I/O on a dumb device per cycle. For instance, clocked-serial might want to write the parport 16 times and read it 8 times in the servo thread, with a call to a function of the clocked-serial component in between..
[00:00:57] <jepler> though that seems different than "reentrant"
[00:06:24] <SWPadnos> yes, it should
[00:06:41] <SWPadnos> there are no functions marked as reentrant at the moment
[00:07:30] <SWPadnos> another application of reentrant (or something like it) would be if we ever add "function arrays" - most of the functions are re-used, just with different data
[00:08:05] <SWPadnos> of course they have to be reentrant (by the standard definition) in that case, since you could e.g. add pid.0 to one thread and pid.1 to another
[00:09:03] <SWPadnos> I guess that doesn't need an explicit flag - if we had a "hal_make_func_array" function, it would just create a bunch of functs with different names anyway
[00:21:19] <SWPadnos> jmkasunich, if you do remove the reentrant flag, then delf can probably lose the thread name, since a function could only be in at most one thread
[00:57:07] <SWPadnos> jepler, if you set the reentrant flag, you would be able to add to the same thread multiple times, regardless of whether that does one thing several times or a sequence of things
[00:57:42] <SWPadnos> the trouble is that HAL wouldn't prevent you from also adding the same function to another thread, which could cause intermittent surprises
[00:57:58] <SWPadnos> (at least I think you could add to the same thread multiple times, I'm not sure)
[01:26:46] <jepler> to call a function from fast and slow thread would require that it be reentrant
[01:26:54] <jepler> to call it multiple times from a single thread wouldn't
[01:27:04] <jepler> (in the normal cs meaning of "reentrant")
[01:27:32] <SWPadnos> right
[01:27:43] <SWPadnos> HAL doesn't care about anything other than the flag though
[01:28:01] <SWPadnos> so you could use multiple invocations in a single thread to do something like you suggested
[01:28:11] <SWPadnos> even though it doesn't need to be CS reenreant
[01:43:56] <jmkasunich> if we remove the reentrant flag, we can choose to enforce "one function, ever", or "only in one thread, but maybe called more than once"
[01:44:16] <jmkasunich> SWPadnos: I don't understand "function arrays"
[01:44:54] <SWPadnos> I guess I was thinking of a shorthand way of creatig multiple functions
[01:45:28] <jmkasunich> right now, you can call "hal_funct_new" with the same function, but pointers to different data (and we normally do that)
[01:45:30] <SWPadnos> in many cases, multiple instances of a component (like PID) will have a single function that gets called with different data as the argument
[01:45:34] <SWPadnos> right
[01:45:36] <jmkasunich> that gives us pid.1, pid,2, etc
[01:46:05] <jmkasunich> from the user's point of view, they are distinct functions
[01:46:14] <jmkasunich> from the programmer's pov, they use the same code
[01:46:25] <jmkasunich> I don't see why we would want to do anything that changes the user's view
[01:46:26] <jepler> if there were a magic way to write .all (aside from comp doing it) that wouldn't hurt (but it wouldn't help that much either)
[01:46:37] <jmkasunich> I really don't like all
[01:46:42] <SWPadnos> so a helper function where you give it hal_multi_funct_new(base_pointer, offset_in_bytes, count, "format_str", ...) would be a nice shorthand
[01:46:59] <jepler> if you feel strongly about it, it can be removed -- it's in TRUNK only
[01:47:01] <jmkasunich> the odds of the function ordering being right are slim to none, unless the data paths thru each instance are parallel
[01:47:29] <jepler> * jepler has an aha moment
[01:47:42] <jepler> I thought about that before, but I didn't get to the end
[01:47:57] <jepler> "the user can simply make sure that and.0 *should be* evaluted before and.1, and so on"
[01:48:01] <jepler> ^^^ too simple thinking
[01:48:15] <SWPadnos> heh
[01:48:16] <jepler> if it's for and.0, then xor.0, then and.1, ...
[01:48:27] <jepler> OK, you convinced me
[01:48:29] <SWPadnos> that'll never work. it requires more thought on the part of the user :)
[01:51:00] <jepler> Running test: /home/jepler/emc2.tool/tests/hm2-idrom
[01:51:00] <jepler> hm2/hm2_test\.0: invalid cookie |test pattern 0 didnt produce error 'hm2/hm2_test\.0: invalid
[01:51:20] <jepler> hm hm2 test failures
[01:51:36] <jepler> Running test: /home/jepler/emc2.tool/tests/threads.1
[01:51:36] <jepler> test: 4: Illegal number:
[01:51:36] <jepler> *** /home/jepler/emc2.tool/tests/threads.1: FAIL: checkresult exited with 2
[01:51:41] <jepler> and whatever this means
[01:54:57] <jepler> oh that was because of .all
[01:55:03] <CIA-42> EMC: 03jepler 07TRUNK * 10emc2/src/hal/utils/comp.g: The "all" function only encourages users not to carefully consider the order of functions in threads. get rid of it.
[01:55:04] <CIA-42> EMC: 03jepler 07TRUNK * 10emc2/tests/loadrt.1/expected: The "all" function only encourages users not to carefully consider the order of functions in threads. get rid of it.
[01:55:05] <CIA-42> EMC: 03jepler 07TRUNK * 10emc2/tests/threads.1/test.hal: The "all" function only encourages users not to carefully consider the order of functions in threads. get rid of it.
[01:55:19] <cradek> bonk there goes my config
[01:55:25] <jepler> cradek: haha oops
[01:55:30] <cradek> 'sokay I'm used to it
[01:57:21] <jepler> the hm2 test is broken on sim because you can't read messages from rtapi in the same way (by checking in dmesg)
[02:05:41] <CIA-42> EMC: 03jepler 07TRUNK * 10emc2/tests/hm2-idrom/skip: this test doesn't run on sim
[02:22:28] <jmkasunich> SWPadnos: do you have the xilinx tools on windows, linux, or both?
[02:23:14] <jepler> I know you didn't ask me, but I have xilinx on linux only
[02:24:27] <jmkasunich> I knew you wouldn't have windows
[02:24:40] <jmkasunich> I'm thinking about the makefile I've been writing
[02:25:20] <jmkasunich> I know how to make it work, but if I want to get peter to use it, doze would be usefull
[02:25:27] <jepler> oh my
[02:25:33] <jmkasunich> he is very interested in being able to do builds from the command line
[02:25:42] <jmkasunich> and maybe able to set up a linux box
[02:26:00] <jmkasunich> emphasis on maybe
[02:26:28] <jmkasunich> I have a python program that does most of the work, make isn't really doing much
[02:26:51] <jepler> that's an interesting point; python is pretty easy to install on windows
[02:26:58] <jmkasunich> it wouldn't be a big step to have the .py spit out a bash build script and a doze batch file
[02:27:10] <jepler> since usually you "just rebuild everything", right?
[02:27:21] <jmkasunich> yeah, make doesn't really save much
[02:27:34] <jepler> you could also have python directly execute the commands using os.system or os.spawnv
[02:27:39] <jmkasunich> with C, you spend 2 minutes compiling and 5 seconds linking, and make lets you skip much of the compile
[02:27:54] <fenn> or use scons
[02:27:56] <jmkasunich> with FPGAs, you spend 20 seconds compiling and 10 minutes "linking"
[02:28:05] <fenn> (not that i have any idea what you're talking about)
[02:28:17] <jmkasunich> jepler: I didn't think about that approach
[02:28:45] <jmkasunich> what happens to stdout when you spawn/system something? (xilinix tools output much messages to stdout)
[02:29:46] <jepler> just like in a shell: stdout goes to the shell's stdout unless you redirect it; same for stderr
[02:30:03] <jmkasunich> so basically, it does what I want it to do ;-)
[02:30:53] <jmkasunich> I bet python has os.foo for renaming/deleting/copying files too (another OS difference)
[02:30:55] <jepler> if you want better control over that (e.g., to redirect to a file) then subprocess.Popen will serve your needs. if you just want it passed through, then simply using os.system / os.spawnv will do
[02:31:32] <jepler> yes. os.rename, os.unlink for working one file at a time, shutil module for slightly higher level stuff like copying files or trees of files
[02:31:44] <jmkasunich> just thinking one or two
[02:31:58] <jmkasunich> I was originally thinking about "make for windows" (exists)
[02:32:08] <jmkasunich> but the makefile tends to invoke things like rm, etc
[02:32:54] <jepler> I think you get basics like 'rm', 'mv', 'echo' when you install the mingw environment on windows
[02:32:55] <jmkasunich> so he'd need rm for windows, mv for windows, etc - ick
[02:33:48] <jmkasunich> yeah, there are ways to get a linuxy environment on doze, but that's just more hoops for him to jump thru
[02:33:55] <jmkasunich> I have an incentive to make it easy for him
[02:34:05] <jepler> if you need python already, then trying to do it all from python seems like a good avenue to go down
[02:34:30] <jmkasunich> my approach needs minor changes to the vhdl - if I make it easy for Peter, he won't mind those changes
[02:34:57] <jmkasunich> he's already stated that he doesn't like the way he is doing config now, from a phone call I had with him I think he'll like what I'm planning
[02:35:45] <jepler> let me check how much space I have on my virtualbox windows .. should be able to install xilinx on there and work with you to develop this stuff
[02:35:50] <jepler> then we'll get him using cvs :-P
[02:35:56] <jmkasunich> heh
[02:36:49] <jmkasunich> right now the biggest thing I think I'll lose when I switch from make to py is "make clean"
[02:37:02] <jmkasunich> (of course that can be done in py too, but it smells like reinventing stuff)
[02:37:29] <jmkasunich> the dependency management is already py, since make doesn't know about vhdl
[02:37:40] <jmkasunich> config manipulation is also .py
[02:39:38] <jepler> ffs
[02:40:08] <jmkasunich> ?
[02:40:23] <jepler> virtualbox modules aren't out yet for the current ubuntu 8.04 kernel
[02:40:52] <jmkasunich> bummrt
[02:42:22] <SWPadnos> jmkasunich, I have some older ones on Windows, and I can probably install a more recent version
[02:42:33] <jmkasunich> cool
[02:42:54] <jmkasunich> I'm hoping that the command line tools are the same in both environments
[02:44:18] <SWPadnos> you could try doing it in tcl, since the tools use that already
[02:45:11] <jepler> yay, built
[02:45:26] <jmkasunich> tcl bites
[02:45:35] <jepler> free space: 1.75GB
[02:45:38] <jepler> I wonder if that's enough space for xilinx
[02:45:47] <jmkasunich> hmm
[02:46:14] <jmkasunich> no
[02:46:22] <SWPadnos> heh
[02:46:30] <SWPadnos> not even for the downloaded file
[02:46:34] <jmkasunich> the version I have here is 2.4G unpacked, and it is over a year old
[02:46:44] <SWPadnos> oh wait, you can just fit the download in that
[02:47:01] <jepler> ugh
[02:47:07] <jepler> guess I'll have to make another 4GB drive
[02:47:14] <SWPadnos> but then there are 1.5G of updates (unless you start with 10.x.03)
[02:47:15] <jmkasunich> bloat, thy name is xilinx
[02:47:24] <jepler> or maybe 8GB
[02:47:44] <jepler> * jepler wonders why his virtualbox shared drive doesn't work anymore
[02:47:53] <SWPadnos> yes, espeically if you want the OS there as well
[03:07:29] <SWPadnos> can anyone think of an easy way to see what thread a function is in (other than looking through the thread function lists to find the function name)?
[03:07:53] <jmkasunich> not really
[03:07:58] <SWPadnos> bummer
[03:08:13] <jmkasunich> are you referring to something you can do from the halcmd prompt? or something you could code as an addition to halcmd?
[03:08:24] <SWPadnos> well, either way I guess
[03:08:27] <SWPadnos> but it's for completion
[03:08:54] <SWPadnos> if you do delf pid.0<tab>, it may as well fill in pid.0.calculate <threadname>
[03:09:13] <jmkasunich> I know when you remove a comp, hal_lib can figure out what threads (if any) it's functions are in
[03:09:14] <SWPadnos> or at least let you teb once more to get the thread name
[03:09:21] <SWPadnos> yep. I can look at that
[03:09:22] <jmkasunich> you could examine that code
[03:09:49] <jmkasunich> as jepler pointed out, if we get rid of reentrancy, we can make delf not require the threadname
[03:09:50] <SWPadnos> I bet it scans through the threads and looks for the owner ID of each funct
[03:09:53] <SWPadnos> yep
[03:11:59] <fenn_> fenn_ is now known as fenn
[03:15:56] <jmkasunich> jepler: SWPadnos:
http://www.pastebin.ca/1280389
[03:18:50] <jepler> jmkasunich: I'd want it to be OK to specify the ".spec" extension, so that I can tab-complete it. maybe that's silly nitpicking on my part
[03:19:19] <jmkasunich> no prob, the program needs to know the base name, but that is easy to parse
[03:19:23] <jepler> I think mcs and svf are the programming files I needed for jtag programming of my "s3board"
[03:19:44] <SWPadnos> are the steps from 7 on doable by makefile?
[03:19:45] <jepler> one for volatile jtag programming, one for programming the flash
[03:20:12] <SWPadnos> if so, the "stop and later continue where you left off" is done by make, not the script
[03:20:30] <jmkasunich> SWPadnos: yes, but the cross-platform goal makes depending on make less desirable
[03:20:34] <SWPadnos> hmm
[03:21:07] <jmkasunich> right now I have one python program that does most of steps 1, 2, 3
[03:21:18] <jmkasunich> another that does dependency stuff, but only one level, so that is part of 4
[03:21:19] <SWPadnos> I suppose a Windows dependency on CygWin isn't desirable :)
[03:21:48] <jmkasunich> the rest of 4 is currently done by make itself, thru an "include makefile.dep" line, and some weird stuff
[03:22:27] <jmkasunich> 5 and 6 are currently part makefile, part unimplemented, but trivial in .py
[03:22:52] <jmkasunich> as you say, 7 onward is a bit of "reinventing make in python", although obviously much simpler
[03:23:18] <SWPadnos> yeah. I guess you could add a --resume option or something
[03:23:25] <SWPadnos> make_bitfile --resume myfile
[03:23:41] <SWPadnos> and it can look for appropriately named intermediate files
[03:23:58] <jmkasunich> yeah, all intermediates have the same base name, only the extension changes
[03:24:03] <SWPadnos> in python it may be almost as simple as:
[03:24:28] <SWPadnos> if (remake and file_exists(thefile)) or create(thefile)
[03:24:33] <jmkasunich> it will need to check timestamps I think, unless the first thing a "non-resume" build does is clean out all the intermediates
[03:24:49] <SWPadnos> non-resume should recreate everything
[03:25:02] <SWPadnos> IMO anyway
[03:25:28] <jmkasunich> recreate doesn't imply "delete first"
[03:25:37] <jmkasunich> but I think either that or datestamp checking is needed
[03:25:46] <SWPadnos> actually, it's not quite that simple, unless there's a guarantee that any partially finisned steps won't leave an a correctly named file with incorrect contents
[03:26:04] <SWPadnos> ... partly finished steps ...
[03:26:49] <jmkasunich> if ( not step_successfull ) : delete output
[03:27:11] <SWPadnos> well, there's also ctrl-C to deal with
[03:27:15] <jmkasunich> yeah
[03:27:36] <jmkasunich> if you send ctrl-C to a python program that is running a child process, who gets it?
[03:27:47] <jmkasunich> that is the kind of thing I was hoping jepler could comment on
[03:28:18] <SWPadnos> me too!
[03:28:19] <jmkasunich> typically if you ctrl-C this thing, you'll want the current step to die, and the python program to clean up and then exit
[03:31:07] <jepler> >>> import os
[03:31:07] <jepler> >>> os.system("sleep 30")
[03:31:07] <jepler> 2
[03:31:22] <jepler> hit ctrl-c, signal is sent to sleep which exits with a nonzero code
[03:31:39] <jmkasunich> just what we want
[03:31:45] <jmkasunich> how'd that happen?
[03:31:50] <jepler> you'll also want to handle the uncommon case of hitting ctrl-c in between invocations of os.system()
[03:32:11] <jepler> you can do that by having a 'try / except KeyboardInterrupt' block around the whole process, which is treated just like an error
[03:32:56] <jepler> something like:
[03:32:57] <jepler> try:
[03:32:57] <jepler> result = actual_build_process()
[03:32:57] <jepler> except KeyboardInterrupt:
[03:32:57] <jepler> result = False
[03:33:00] <jepler> if not result:
[03:33:02] <jepler> some sort of failure, clean up, exit with nonzero status
[03:34:56] <jmkasunich> where "actual_build_process" is several steps?
[03:34:58] <jepler> you could also write a wrapper for os.system/os.spawnv to turn a nonzero status into an exception, so you don't have to put checks everywhere
[03:35:05] <jepler> jmkasunich: presuambly
[03:35:23] <jmkasunich> hmm, the cleanup probably depends on where in the process you were
[03:35:42] <jepler> it can't be of the form: "If file x exists, delete it"
[03:35:51] <SWPadnos> you can have multiple Except blocks, I assume
[03:36:06] <jepler> SWPadnos: yes
[03:36:20] <SWPadnos> so the code looks more like
[03:36:22] <SWPadnos> try:
[03:36:28] <SWPadnos> do_something()
[03:36:33] <SWPadnos> do_soemthing_else()
[03:36:40] <SWPadnos> except Keyboardinterrupt:
[03:36:51] <jepler> SWPadnos: sure
[03:36:53] <SWPadnos> do_ctrl-C_handling()
[03:37:01] <SWPadnos> except myownexception:
[03:37:13] <SWPadnos> handle_screwup_number1()
[03:37:16] <SWPadnos> ...
[03:37:46] <SWPadnos> (just pointing out exception handling for the c++ - phobic :) )
[03:38:07] <jmkasunich> time to start coding
[03:38:36] <jmkasunich> stupid question - anybody have a better name than "make-bitfile.py" ?
[03:38:55] <SWPadnos> create-most-excellent-config.py
[03:39:01] <SWPadnos> (no :) )
[03:39:02] <jepler> bitmaster.py
[03:39:12] <jepler> git.py
[03:39:19] <SWPadnos> gitabit.py
[03:39:37] <jmkasunich> fpga.py
[03:39:49] <SWPadnos> actually - make-xilinx-bitfile.py
[03:39:49] <jepler> shaveandacircuittwobits.py
[03:40:07] <SWPadnos> heh
[03:40:21] <SWPadnos> I just watched "Who Framed Roger Rabbit" last week :)
[03:40:38] <SWPadnos> those toons just can't resist 'shave and a haircut'
[03:40:42] <jmkasunich> SWPadnos: given the assumption of some hostmot2 specific hooks, I'd be more inclined to call it "make-mesa-bitfile.py"
[03:41:13] <SWPadnos> yeah, I was just realizing that there aren't any non-Xilinx bitfiles to make for these cards
[03:41:26] <SWPadnos> make-custom-config
[03:41:31] <jmkasunich> mkbit.py
[03:41:42] <SWPadnos> mmb.py
[03:41:50] <SWPadnos> heh
[03:42:03] <jmkasunich> spec2bit?
[03:42:08] <SWPadnos> 3 hours later, they decided on a name, but by then it was past everyone's bedtime
[03:42:15] <SWPadnos> so the project was shelved
[03:42:20] <SWPadnos> :)
[03:42:38] <SWPadnos> make-special-bitfile-from-spec-file-for-mesa-card
[03:42:44] <SWPadnos> .py
[03:42:51] <jmkasunich> I think I like spec2bit - not very original, but fairly short and descriptive
[03:43:01] <SWPadnos> or just use ls to screw everyone up
[03:44:34] <jepler> bitfondler
[03:44:49] <SWPadnos> and its sister app bitbanger
[03:47:48] <jmkasunich> jepler: I'm planning to make the spec file look like this:
http://www.pastebin.ca/1280407
[03:48:03] <jmkasunich> and just execfile() it to get the info into python
[03:48:11] <jmkasunich> is that a horribly fragile thing to do?
[03:49:00] <jmkasunich> my gut says it is, but it is just so freaking easy....
[03:49:21] <SWPadnos> if you expect users to edit the file, then it's fragile
[03:49:44] <jmkasunich> well, they are expected to edit the VHDL in module_id and pin_desc
[03:49:54] <SWPadnos> I don't know what the error messages look like when there's an error though - they may be good enough
[03:50:01] <jmkasunich> that is more fragile than the python """ wrapped around it
[03:50:06] <SWPadnos> I guess that's true
[03:50:39] <jmkasunich> all the spec really is is 5 name/string pairs
[03:50:49] <jmkasunich> two of the strings will contain newlines
[03:51:28] <SWPadnos> ok, I see that now. it's probably fine, though I don't know how well errors in that file will map back from the Xilinx tools
[03:51:55] <jmkasunich> errors in the vhdl will probably be rather icky
[03:52:04] <SWPadnos> ie, make a typo in there, spec2bit runs and spits out a new file, where the error really comes from as far as xilink is concerned
[03:52:15] <jmkasunich> but that would be true regardless of the mechanism used to get the vhdl to the xilinx tools
[03:52:18] <jepler> """ is pretty easy to understand
[03:52:20] <SWPadnos> user can't figure out where the problem is in his input
[03:52:39] <SWPadnos> yes, the format of the file is fine - I didn't notice that it was all multiline string constants
[03:53:08] <jmkasunich> the header of the generated file (which is what Xilinx will complain about) looks like:
[03:53:12] <jmkasunich> -- AUTOGENERATED FILE - DO NOT EDIT!
[03:53:12] <jmkasunich> -- this file is: myconfig.vhd
[03:53:12] <jmkasunich> -- generated from: myconfig.spec
[03:53:12] <jmkasunich> -- using template: I20HostMot2-in.vhd
[03:53:12] <jmkasunich> -- generated on: 2008-12-03 00:43:41
[03:53:54] <SWPadnos> those strings get included verbatim in the output, right?
[03:53:59] <jmkasunich> yes
[03:54:11] <jmkasunich> ThePinDesc: PinDescType :=
[03:54:11] <jmkasunich> (
[03:54:11] <jmkasunich> IOPortTag & x"00" & QCountTag & QCountQAPin, -- I/O 00
[03:54:11] <jmkasunich> IOPortTag & x"00" & QCountTag & QCountQBPin, -- I/O 01
[03:54:13] <SWPadnos> so theoretically you could add to that header:
[03:54:30] <jmkasunich> the substitution starts at the :=
[03:54:40] <SWPadnos> -- pindesc starts at line 1009, module_id starts at line 1123
[03:54:53] <jmkasunich> theoretically
[03:55:02] <SWPadnos> so people can subtract that number (more or less) to get the offset into their "source" file
[03:55:06] <jmkasunich> python has a lib that handles the substitution very nicely, in one or two lines
[03:55:14] <SWPadnos> yeah, regexp :)
[03:55:21] <jmkasunich> finding out where the substitution took place is much more work
[03:55:29] <jepler> 'night guys
[03:55:33] <jmkasunich> night jeff
[03:55:34] <SWPadnos> see you jepler
[03:55:41] <jmkasunich> actually, string.Template()
[03:55:59] <SWPadnos> ok
[03:56:04] <jmkasunich> dest.write(string.Template(source.read()).substitute(substitutions))
[03:56:09] <SWPadnos> cool
[03:56:32] <jmkasunich> source is the source file, substitutions is a dict, dest is the result (header already written with dest.write("stuff")
[03:57:19] <SWPadnos> I bet there's a way of finding out what was substituted and where
[03:57:28] <jmkasunich> probably
[03:57:39] <jmkasunich> but I'm not gonna sweat it right now
[03:58:07] <jmkasunich> the goal of this tool isn't to make it super easy
[03:58:13] <SWPadnos> I wonder if you could give me a quick hal pointer. I can't find anything other than rtapi "cleanup_module" that even comes close to removing HAL objects when a module is removed
[03:58:34] <jmkasunich> you still have to know peter's conventions for module_id and pin_desc - Joe User won't be able to generate a custom config
[03:58:35] <SWPadnos> hal_exit does a little, then calls an RTAPI function, which eventually calls module_cleanup
[03:58:38] <jmkasunich> and I'm fine with that
[03:58:43] <SWPadnos> yeah, it's not simple by any means
[03:59:04] <jmkasunich> ok, changing to hal ;-)
[03:59:11] <jmkasunich> (I was about to call it a night on the other anyway)
[03:59:15] <SWPadnos> just a little, I promise :)
[03:59:17] <SWPadnos> ok
[03:59:20] <jmkasunich> lemme take a look in hal_lib
[03:59:34] <SWPadnos> OK - that's where I started, but I couldn't see it
[04:00:06] <SWPadnos> I figured I'd look for hal_unlink, and there are 4 refernces to that - 2 of them are the function itself and the EXPORT_SYMBOL() for it
[04:00:23] <jmkasunich> hal_lib.c, grep for "free_comp_struct"
[04:00:50] <jmkasunich> line 2980
[04:01:03] <jmkasunich> it searches the function list for functs belonging to this comp
[04:01:12] <jmkasunich> then calls free_funct_struct()
[04:01:40] <jmkasunich> which checks all threads looking for funct_entries that call that function
[04:01:48] <SWPadnos> ah, okj
[04:01:50] <SWPadnos> -j
[04:01:55] <SWPadnos> I didn't trace that far I guess
[04:02:05] <jmkasunich> and that calls "free_funct_entry_struct()"
[04:02:08] <jmkasunich> bit of a pattern there
[04:02:18] <SWPadnos> heh
[04:02:44] <jmkasunich> funct_entry is not the clearest thing around
[04:02:55] <jmkasunich> a funct_struct defines the function
[04:03:16] <jmkasunich> a funct_entry struct is assocated with a thread, and invokes the function
[04:03:26] <jmkasunich> this needs a pencil
[04:03:41] <SWPadnos> ok, so the bottom line is that it does exactly what I want to avoid, and it does it inline
[04:04:06] <jmkasunich> what are you trying to avoid?
[04:04:14] <jmkasunich> oh, the brute force search?
[04:04:18] <SWPadnos> yeah
[04:04:37] <jmkasunich> "for small N, brute force wins"
[04:04:38] <SWPadnos> actually, it would be different anyway, because I need to look at the name, not the comp_id
[04:04:40] <SWPadnos> heh
[04:04:56] <SWPadnos> these functions don't care what the objects are called, only who owns them
[04:05:02] <jmkasunich> N in this case is small - fewer than 5 threads in even an insane system, fewer than 100 functions
[04:05:03] <SWPadnos> I care the other way around
[04:05:06] <SWPadnos> sure
[04:11:21] <cradek> how do I spell printf("%p",p) in C++?
[04:11:49] <SWPadnos> p is a pointer?
[04:11:59] <cradek> say p is a char *
[04:12:03] <SWPadnos> cout << p
[04:12:09] <SWPadnos> if you have streams
[04:12:24] <SWPadnos> otherwise, it's printf("%p", p)
[04:12:26] <cradek> char *p="hello"; cout<<p says hello
[04:12:35] <SWPadnos> oh, right :)
[04:12:41] <cradek> I want it to say 0x12345678, like %p
[04:13:34] <SWPadnos> too funny. cast it to (void *)
[04:13:40] <SWPadnos> cout << (void *)p
[04:20:50] <jmkasunich> message sent to peter w describing what we've been discussing - I'd like his input
[04:20:53] <jmkasunich> goodnight
[04:20:59] <SWPadnos> cool. night
[11:58:47] <CIA-42> EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/hal/basic_hal.lyx: remove all function from docs
[12:10:54] <CIA-42> EMC: 03bigjohnt 07v2_2_branch * 10emc2/docs/src/hal/basic_hal.lyx: note that the all function is depreciated
[12:49:25] <jepler> stupid xilinx install ran out of space overnight even though it said there was enough on this fresh 6GB disk when it started
[12:49:28] <jepler> grgrngrg
[13:49:53] <CIA-42> EMC: 03bigjohnt 07v2_2_branch * 10emc2/docs/src/hal/basic_hal.lyx: remove all
[13:50:02] <cradek_> cradek_ is now known as cradek
[14:16:59] <CIA-42> EMC: 03cmorley 07TRUNK * 10emc2/src/hal/classicladder/drawing.c: switch back to normal colour display because of x windows crash after a long wait
[14:29:32] <cradek> ?
[14:35:01] <jepler> - DynaGcDrawWinColor = gdk_gc_new(pixmap);
[14:35:22] <jepler> looks like the buggy code repeatedly allocated a gc but never freed it
[14:35:38] <jepler> that's my guess, anyhow
[15:58:41] <CIA-42> EMC: 03jepler 07TRUNK * 10emc2/src/hal/classicladder/ (13 files): fix dos-style line endings; no substantive change intended
[18:42:31] <alex_joni> hi all
[18:44:17] <seb_kuzminsky> hi alex :-)
[18:46:21] <alex_joni> hey seb, how is everything?
[18:46:46] <seb_kuzminsky> pretty good
[18:47:55] <alex_joni> * alex_joni is a bit tired ..
[18:48:05] <alex_joni> finished doing 40 pounds of sausages :D
[18:48:17] <seb_kuzminsky> mmm sausage
[18:48:28] <fenn> eating or making them? :)
[18:48:55] <alex_joni> I doubt I can ever eat 40 pounds of anything
[18:49:04] <alex_joni> fenn: making them
[21:22:22] <tomaw> [Global Notice] Hi all. One of our client servers is having some connectivity problems. Please keep with us while we investigate. Thanks!