Always grateful. When I drag the mouse over most any web page with left button pressed it uses a different (X) select mechanism than the copy to buffer and paste mechanism. Then press the middle button over a text editor (NEdit) page and there is no HTML markers. This is very handy for many things. When compiling, I open a terminal from the directory using Krusader file manager, type fpc (+ space) then use Xselect on the editor bar to grab the filename and drop it on the terminal with the mouse middle button, press enter and compile. I don't use all the freepascal Lazarus or text IDE. If you try NEdit there is a great web page instruction manual. The search menu button is great. The "replace" tool is extremely useful and can search regular expressions and replace them in multiple files reliably. I used that tool a lot to redo an AVR assembler program (GAVR) written in freepascal (because of the fantastic string handling) and was amazed it still worked. I just install the binary NEDIT because it won't compile easily. But you are right, I'm not entirely coherent here. My reason for the "independent real time" timer is well stated in the old Posix.4 (now Posix.1b) book mentioned; "jiffies" are not real time. The timed data point generation using other timers is an approximation, and can be seen clearly on a slow computer display. In fact, if you get that posix timer program running you will see some variation in overrun count that is not due to the clock itself. I don't care if X displays the data at unpredictable times, but I want the data acquired at predictable times. But perhaps "gettimeofday" would be better to assign acquired data to time as you say, I don't know. Here is where it might matter; http://www.theenergycollective.com/ There are some serious people on this board; retired nuclear submarine navy officers, oil refinery engineers, railroad managers, and a wasteland farmer (me). And here is my comment at the bottom where I'm pushing; http://www.theenergycollective.com/jemiller_ep/2397667/energy-technologies-markets-and-government-policies-major-impacts-on-u-s-carbon-emissions-2005-2016 I realize you don't have the time to chase this around. But you made a great effort to become aware of it, and I'm grateful. As you see, nobody really knows what to do!! Iznogoud wrote: > Rick, > I think you are better off posting your code without any HTML formatting. I > had to copy/paste from the browser to a text file; that is where the struggle > with formatting comes in. I recommend using Github for this sort of thing, or > just post the plain text source with a link to it. > > >> C unions have counterparts in Pascal variant records. All the "feature >> test macros" used (see getconf) in the C library work for a C compiler >> and not Pascal. So C++ really seems best. Freepascal has a utility >> "h2pas" that helps convert headers to pascal. But I'm actually satisfied >> with the posix timer results. The "siginfo" signal handlers are >> non-essential. >> > Unions as a C standard are very specific. But I think the compiler will > align those objects with the memory given the underlying handling by the > hardware. I suspect, but do not know, that whether it is a Pascal or a C > compiler, etc, the outcome should be the same. > > Sounds like that utility to convert headers will be enlighting to any > non-Pascal coders like me. I will have a look; I have not had the time. > > Let's take a step back. You wanted high-resolution timers so that you can > run events in a GUI for the purpose of graphing things in a window, etc. > I had said that you do not need that kind of resolution for timing screen > events, and that it is self-defeating (in my opinion) given that the X has > to inerpret, handle and draw, which will take an arbitrary about of time. > You can achieve the same by checking the clock (gettimeofday() for example) > and re-checking post event to trigger a redraw. This is standard practice > in gaming, etc. What happened since and what did you end up using? This > discussion sort of derailed a bit. > > >> I'm now playing with old Unix domain sockets software, and as usual, >> Linux has some new treats. Linux recently added SOCK_SEQPACKET types. >> What relates to this discussion is how some programmers are advocating >> pre-pending a message with a size byte to define message blocks. But >> that is exactly what freepascal does for old strings types. The null >> "terminated" C strings are a hazard. >> > The null-terminated strings is yet another convention, if you like. They > are just arrays of characters, and they are "strings" if *by convention) > are terminated by a null character. When you assign a pointer to a constant > "string" the quote at the end (which is considered a pointer in programming, > I think) is where the null character is automatically placed by the compiler. > If you turn on all GCC warnings you can do: > > char *s = "some text\n'); > > and get a warning that you have a redundant \n (null char) at the end. > > The standard of the language or the construction of the compiler can differ > a bit for languages like Pascal, Fortran, etc. In fortran, for example, all > functions that accepted strings actually accepted pointers to strings, and > additional arguments were placed at the end of the function's nominal arguments > that indicated the size of the string that was passed. I cannot say I like > this, but it was completely covered under the hood for anyone who did not mix > fortran with anything else. > > > Your mention of domain sockets reminded me of a joke, with which I wish to > end yet another pedantic post: > > "The good thing about UDP jokes is that I do not care whether you get them or > not." > > _______________________________________________ > TCLUG Mailing List - Minneapolis/St. Paul, Minnesota > tclug-list at mn-linux.org > http://mailman.mn-linux.org/mailman/listinfo/tclug-list >