From eng at pinenet.com Thu Feb 2 22:21:56 2017 From: eng at pinenet.com (Rick Engebretson) Date: Thu, 2 Feb 2017 22:21:56 -0600 Subject: [tclug-list] Linux timers In-Reply-To: <5886BE7F.7020202@pinenet.com> References: <58849BCF.8070900@pinenet.com> <20170123025841.GA8597@nobelware.com> <58858CA1.2030707@pinenet.com> <20170124014604.GB27479@nobelware.com> <5886BE7F.7020202@pinenet.com> Message-ID: <58940564.5090303@pinenet.com> I got a slimmed down freepascal version of the posix timer example to work; http://www.sytekcom.com/eng/fp_Linux_PosixTimer.html Digging into the types involved, I don't think many appreciate the complexity of C "unions" and the havoc created with 32 bit, 64 bit, and hybrid data and memory types. The system calls might follow posix (portable OS...) but nothing else is portable. So 32 RT signals, and all the other variables and tricks will have to do; "siginfo" handlers only work with C. Even various freepascal types are wrong. Anyway, this freepascal code works on 32 bit opensuse 12.2. And the code doesn't look like chicken footprints in the snow. The comment text is mostly from the timer_create C example as well. As can be seen, with reasonable types defined, plucking C functions for pascal use is quite easy. Reliable microsecond timer accuracy. Rick Engebretson wrote: > Absolutely outstanding. Again, sincere thanks. > > Right now I'm reading "Programming for the Real World; POSIX.4," by > Bill O. Gallmeister; Copyright 1995 by O'Reilly & Associates Inc. The > book is much clearer than the Linux manpages, and explains why these > Posix.4 timers are an important new aspect of Linux (Unix) software. I > got the book many years ago when I thought the Linux 2.4 kernel was > great. Now seeing industrial linux hardware the size of this book with > real-time capabilities, it is a topic worth being aware of I believe. > > Many years ago I did a lot of "libc" adaptation of signals, > semaphores, the UART, etc. in freepascal. It's quite easy really, but > I have not yet found what's in librt; I know it comes with libc. Not > your (C, C++ programmer) problem at all, just a Pascal problem since I > need to know where functions are accessed. > > As for the stripchart XForms program, you are right, I have a lot to > figure out. It still draws reasonably accurate trigometric functions. > It will be a great goal to have a useful set to offer. Since you have > worked Monte Carlo (random) collision chemical reaction kinetics > theory simulations you might like to see how 3 or more sine waves add > up graphically. My outdoor long range television antenna is a good > oversize model of a molecule, with molecule dipoles instead in the > optical wavelength range. Chemistry does not need to be "random." > > Innovation matters. > > Iznogoud wrote: >>> Please look next at manual page "timer_create.2" . This is all new >>> Posix >>> compliance tools. There is an example provided. Apparently, the call >>> even allows you to define several types of clocks and event >>> reporting. I >>> don't understand "threads" and "virtual" stuff, but I do understand a >>> "process." >>> >> I looked at the manual page. Yes, it is all POSIX and in general if your >> application is sticking with unix, you want to stick to POSIX pieces of >> the glibc and the kernel. This particular piece of work, as the manual >> page states, is a mix of kernel work and some glibc pieces. This is very >> good in my opinion (to have most of it in glibc), as the user gets a lot >> of say in what happens during execution. >> >> There is an example given, but I do not think it would be instructive >> for >> you given that you do not touch C or system programming. But, in a >> nutshell, >> the example shows how a signal handler is established (in a special way) >> to trap timer expiration events for this particular process alone. It >> sets >> the signal handler and first blocks trapping of that signal by the >> handler. >> It gives the process time to establish the timer; which is the meanigful >> thing to do. Then, it unblocks the signal handling and sends the main >> process work to sleep. The timer will have expired when the process >> wakes >> up. The pending signal will "fall" into the handler when that happens. >> >> It works as expected. It is not the most instructive example, but it >> does >> do what it promises. I tried it as is and I tried it without blocking >> the >> signal trapping at all. In the former case (original code), it waited >> for >> 1 second before it trapped the signal due to the timer having >> expired. In >> that latter, the handler invoked immediately (after the 100 >> nanoseconds I >> had specified) while the process was starting to go to sleep for a >> second. >> >> One more (possibly instructive to you) point. If you follow this >> model of >> using HRTs and want to work with signals that are picked from specific >> timers, you will have to provide handler functions. Those become >> detached >> POSIX threads (is my understanding) to execute the handler code. >> There is >> no other way, if you think about it. You can certainly achieve >> realtimeness >> that way. Or you can engineer your UI so that it traps signals and then >> re-freshes the screen at constant framerate. A thread in the backend can >> do all intensive work and set a flag for what it is done. The main >> loop of >> the UI keeps checking the flag and draws new things when the flag is set >> and it unsets it. Really easy to program... >> >> >>> Using freepascal 3.0.0 to access C library calls isn't hard. But the >>> timer_create manpage also indicates a needed link to "-lrt" . The >>> freepascal team has added a lot of Unix and Linux calls over the years, >>> but not this one yet. I've done this before, and that's why I got old. >>> >> I had to link with -lrt (of course). It does not matter what the >> Pascal >> compiler and linker invokation do. I would make sure the Pascal compiler >> can produce compiled object code (.o files) and then link with the >> linker >> externally or just link with gcc (the C compiler/linker stript). >> >> >>> Understanding the XForms-toolkit somewhat, I do think this approach is >>> much better precision than the legacy timeout functions used in the >>> toolkit. And the XForms maintainer rightly criticized my using a system >>> Sleep call to get better accuracy, since it blocked XWindow events too. >>> So I think this is a very versatile feature to play with drawing >>> complex >>> functions on a screen stripchart. >>> >> Yes, do not sleep the main process that handles X window events... >> You will >> get a freeze and then possibly a pile of events to be handled at >> once. You >> typically want your UI to run in semi real-time and have all processing >> done in the background; this can include UI event-handling. Most >> people do >> not concern themselves with realtimeness issues and make the main >> code the >> UI event handler. I think this is bad practice, but it has a low >> barrier to >> entry for programmers and for non-intesive work. >> >>> When I get a decent set of software I'll try put it on a little web >>> site. Even try put up a few binary programs so you don't have to >>> work so >>> hard to figure what I'm talking about. Thanks for trying. >>> >> Use Github. I do use it for such things. >> >> I hope I had shed some light in this for you and I have not wasted >> anybody >> else's time with yet another pedantic post. >> >> _______________________________________________ >> TCLUG Mailing List - Minneapolis/St. Paul, Minnesota >> tclug-list at mn-linux.org >> http://mailman.mn-linux.org/mailman/listinfo/tclug-list >> > > _______________________________________________ > TCLUG Mailing List - Minneapolis/St. Paul, Minnesota > tclug-list at mn-linux.org > http://mailman.mn-linux.org/mailman/listinfo/tclug-list > From iznogoud at nobelware.com Fri Feb 3 15:41:15 2017 From: iznogoud at nobelware.com (Iznogoud) Date: Fri, 3 Feb 2017 21:41:15 +0000 Subject: [tclug-list] New toy with a lot of memory Message-ID: <20170203214115.GA28778@nobelware.com> thor% cat /proc/meminfo MemTotal: 1043304284 kB MemFree: 1040470704 kB MemAvailable: 1039881024 kB Buffers: 54660 kB Cached: 466924 kB SwapCached: 0 kB It cost a lot. But it is purchasable, which is why I am posting this here. From PJ.world at hotmail.com Fri Feb 3 16:07:13 2017 From: PJ.world at hotmail.com (paul g) Date: Fri, 3 Feb 2017 22:07:13 +0000 Subject: [tclug-list] Distros with up-to-date C++ support In-Reply-To: References: <9a4fef78-ec78-7122-5cc4-4008637ce0a5@gmail.com>, Message-ID: I have an issue while running 'Mint 17 Qiana' on an older Dell Laptop 'I don't recall the model number off hand right now'. I have not found a fix for that as of yet. GUM GUM GUM! ________________________________ From: tclug-list-bounces at mn-linux.org on behalf of Jeff Chapin Sent: Friday, January 27, 2017 3:28 PM To: TCLUG Mailing List Subject: Re: [tclug-list] Distros with up-to-date C++ support Compile your own and they all do. On Fri, Jan 27, 2017 at 3:17 PM, B-o-B De Mars > wrote: Slackware On 1/27/2017 2:52 PM, Brian Wood wrote: Recently I had some trouble with getting TrueOS to hibernate on my laptop. So I decided to try Linux Mint. Unfortunately, it has support for older C++ compilers than TrueOS. I read that Fedora 26 will have support for compilers that are already available on TrueOS, but the alpha for that is still 6 weeks away. Are there any other distros to look at for this? Thanks in advance. Brian Ebenezer Enterprises - Learn from the Psalms. http://webEbenezer.net _______________________________________________ TCLUG Mailing List - Minneapolis/St. Paul, Minnesota tclug-list at mn-linux.org http://mailman.mn-linux.org/mailman/listinfo/tclug-list _______________________________________________ TCLUG Mailing List - Minneapolis/St. Paul, Minnesota tclug-list at mn-linux.org http://mailman.mn-linux.org/mailman/listinfo/tclug-list -- Jeff Chapin President, CedarLug, retired President, UNIPC, "I'll get around to it" President, UNI Scuba Club Senator, NISG, retired -------------- next part -------------- An HTML attachment was scrubbed... URL: From carl.soderstrom at real-time.com Fri Feb 3 16:25:04 2017 From: carl.soderstrom at real-time.com (Carl Wilhelm Soderstrom) Date: Fri, 3 Feb 2017 17:25:04 -0500 Subject: [tclug-list] New toy with a lot of memory In-Reply-To: <20170203214115.GA28778@nobelware.com> References: <20170203214115.GA28778@nobelware.com> Message-ID: <20170203222504.GL20814@real-time.com> On 02/03 09:41 , Iznogoud wrote: > thor% cat /proc/meminfo > MemTotal: 1043304284 kB > MemFree: 1040470704 kB > MemAvailable: 1039881024 kB > Buffers: 54660 kB > Cached: 466924 kB > SwapCached: 0 kB > > > It cost a lot. But it is purchasable, which is why I am posting this here. Thanks for sharing. My first 'real' desktop computer had 32MB RAM when I bought it, in the mid 1990s. One of the guys at school asked "Are you going to run Linux on that?" since Linux (according to the rumor) was supposed to use large amounts of memory more efficiently than Windows. (It probably did, but that's not a high bar to overcome, and might not have been noticeable anyway). I did in fact eventually run Linux on that machine, but not until many years later, after I'd tried it out on some junk computers bought at auction, and learned how to set up dual-boot. -- Carl Soderstrom Systems Administrator Real-Time Enterprises www.real-time.com From chapinjeff at gmail.com Fri Feb 3 16:29:58 2017 From: chapinjeff at gmail.com (Jeff Chapin) Date: Fri, 3 Feb 2017 16:29:58 -0600 Subject: [tclug-list] Distros with up-to-date C++ support In-Reply-To: References: <9a4fef78-ec78-7122-5cc4-4008637ce0a5@gmail.com> Message-ID: k. On Fri, Feb 3, 2017 at 4:07 PM, paul g wrote: > I have an issue while running 'Mint 17 Qiana' on an older Dell Laptop 'I > don't recall the model number off hand right now'. I have not found a fix > for that as of yet. > > > GUM GUM GUM! > > > ------------------------------ > *From:* tclug-list-bounces at mn-linux.org > on behalf of Jeff Chapin > *Sent:* Friday, January 27, 2017 3:28 PM > *To:* TCLUG Mailing List > *Subject:* Re: [tclug-list] Distros with up-to-date C++ support > > Compile your own and they all do. > > On Fri, Jan 27, 2017 at 3:17 PM, B-o-B De Mars > wrote: > >> Slackware >> >> On 1/27/2017 2:52 PM, Brian Wood wrote: >> >> >> Recently I had some trouble with getting TrueOS to hibernate >> on my laptop. So I decided to try Linux Mint. Unfortunately, >> it has support for older C++ compilers than TrueOS. I read that >> Fedora 26 will have support for compilers that are already >> available on TrueOS, but the alpha for that is still 6 weeks away. >> Are there any other distros to look at for this? Thanks in advance. >> >> >> Brian >> Ebenezer Enterprises - Learn from the Psalms. >> http://webEbenezer.net >> >> >> _______________________________________________ >> TCLUG Mailing List - Minneapolis/St. Paul, Minnesotatclug-list at mn-linux.orghttp://mailman.mn-linux.org/mailman/listinfo/tclug-list >> >> >> >> _______________________________________________ >> TCLUG Mailing List - Minneapolis/St. Paul, Minnesota >> tclug-list at mn-linux.org >> http://mailman.mn-linux.org/mailman/listinfo/tclug-list >> >> > > > -- > Jeff Chapin > President, CedarLug, retired > President, UNIPC, "I'll get around to it" > President, UNI Scuba Club > Senator, NISG, retired > > _______________________________________________ > TCLUG Mailing List - Minneapolis/St. Paul, Minnesota > tclug-list at mn-linux.org > http://mailman.mn-linux.org/mailman/listinfo/tclug-list > > -- Jeff Chapin President, CedarLug, retired President, UNIPC, "I'll get around to it" President, UNI Scuba Club Senator, NISG, retired -------------- next part -------------- An HTML attachment was scrubbed... URL: From iznogoud at nobelware.com Fri Feb 3 16:53:23 2017 From: iznogoud at nobelware.com (Iznogoud) Date: Fri, 3 Feb 2017 22:53:23 +0000 Subject: [tclug-list] New toy with a lot of memory In-Reply-To: <20170203222504.GL20814@real-time.com> References: <20170203214115.GA28778@nobelware.com> <20170203222504.GL20814@real-time.com> Message-ID: <20170203225323.GA31226@nobelware.com> > > > At age 9 I had an Amstrad CPC 6128 with 128kB of RAM. 12kB to 1TB in 31 years! My Amiga 500 had 500 of those. My first Linux run on 8MBs of RAM on a 25MHz board that was put in a Franken-box by yours truly, where every components was from a different junked machine, and all components were in an IBM PS/2 286 box that I had modified with a saw... They were held together with sillicone. Those were the days! From carl.soderstrom at real-time.com Mon Feb 6 09:23:19 2017 From: carl.soderstrom at real-time.com (Carl Wilhelm Soderstrom) Date: Mon, 6 Feb 2017 10:23:19 -0500 Subject: [tclug-list] New toy with a lot of memory In-Reply-To: <20170203225323.GA31226@nobelware.com> References: <20170203214115.GA28778@nobelware.com> <20170203222504.GL20814@real-time.com> <20170203225323.GA31226@nobelware.com> Message-ID: <20170206152318.GN20814@real-time.com> On 02/03 10:53 , Iznogoud wrote: > At age 9 I had an Amstrad CPC 6128 with 128kB of RAM. I remember my Apple IIc being a big deal because it had 128KB RAM. I'm sure there's someone on this list who remembers the days of 'ed' on a teletype tho, so I'm not going to try to out-nostalgia anyone here. (I have used a teletype once or twice, they aren't worthy of nostalgia. Good riddance to the things.) -- Carl Soderstrom Systems Administrator Real-Time Enterprises www.real-time.com From sfertch at gmail.com Mon Feb 6 09:41:03 2017 From: sfertch at gmail.com (Shawn Fertch) Date: Mon, 6 Feb 2017 09:41:03 -0600 Subject: [tclug-list] New toy with a lot of memory In-Reply-To: <20170206152318.GN20814@real-time.com> References: <20170203214115.GA28778@nobelware.com> <20170203222504.GL20814@real-time.com> <20170203225323.GA31226@nobelware.com> <20170206152318.GN20814@real-time.com> Message-ID: On Feb 6, 2017 09:23, "Carl Wilhelm Soderstrom" < carl.soderstrom at real-time.com> wrote: I remember my Apple IIc being a big deal because it had 128KB RAM. Reminds me of the Tandy 1000EX I had. TandyDOS 2.11, dropped a lot of money for the external 3.5" FDD, and to upgrade to 640K memory with a 300 baud modem. Hercules graphics, and 9-pin track paper. Ahh, the memories.... I'm sure there's someone on this list who remembers the days of 'ed' on a teletype tho, so I'm not going to try to out-nostalgia anyone here. Agreed. Always someone out there... -------------- next part -------------- An HTML attachment was scrubbed... URL: From mr.chew.baka at gmail.com Mon Feb 6 10:20:17 2017 From: mr.chew.baka at gmail.com (B-o-B De Mars) Date: Mon, 6 Feb 2017 10:20:17 -0600 Subject: [tclug-list] New toy with a lot of memory In-Reply-To: References: <20170203214115.GA28778@nobelware.com> <20170203222504.GL20814@real-time.com> <20170203225323.GA31226@nobelware.com> <20170206152318.GN20814@real-time.com> Message-ID: On 2/6/2017 9:41 AM, Shawn Fertch wrote: > I remember my Apple IIc being a big deal because it had 128KB RAM. > > > Reminds me of the Tandy 1000EX I had. TandyDOS 2.11, dropped a lot of > money for the external 3.5" FDD, and to upgrade to 640K memory with a > 300 baud modem. Hercules graphics, and 9-pin track paper. > > Ahh, the memories.... I love these memories. I had a Commodore 64, 300 baud modem, and a 9-pin printer too. I still remember when they first released a multi-color terminal program. That was huge. Watching the cursor slowing zip across the screen to create the screen you selected in color. Good stuff. From gsker at skerbitz.org Mon Feb 6 10:43:45 2017 From: gsker at skerbitz.org (gerry) Date: Mon, 6 Feb 2017 10:43:45 -0600 (CST) Subject: [tclug-list] New toy with a lot of memory In-Reply-To: <20170206152318.GN20814@real-time.com> References: <20170203214115.GA28778@nobelware.com> <20170203222504.GL20814@real-time.com> <20170203225323.GA31226@nobelware.com> <20170206152318.GN20814@real-time.com> Message-ID: On Mon, 6 Feb 2017, Carl Wilhelm Soderstrom wrote: > On 02/03 10:53 , Iznogoud wrote: >> At age 9 I had an Amstrad CPC 6128 with 128kB of RAM. > > I remember my Apple IIc being a big deal because it had 128KB RAM. > > I'm sure there's someone on this list who remembers the days of 'ed' on a > teletype tho, so I'm not going to try to out-nostalgia anyone here. > > (I have used a teletype once or twice, they aren't worthy of nostalgia. Good > riddance to the things.) > Playing yahtzee and football on a teletype while my dad fixed the line printers at Bemidji State ... those were the days. About 1975 or so I think. -- gsker From o1bigtenor at gmail.com Mon Feb 6 14:35:48 2017 From: o1bigtenor at gmail.com (o1bigtenor) Date: Mon, 6 Feb 2017 14:35:48 -0600 Subject: [tclug-list] New toy with a lot of memory In-Reply-To: <20170206152318.GN20814@real-time.com> References: <20170203214115.GA28778@nobelware.com> <20170203222504.GL20814@real-time.com> <20170203225323.GA31226@nobelware.com> <20170206152318.GN20814@real-time.com> Message-ID: On Mon, Feb 6, 2017 at 9:23 AM, Carl Wilhelm Soderstrom wrote: > On 02/03 10:53 , Iznogoud wrote: >> At age 9 I had an Amstrad CPC 6128 with 128kB of RAM. > > I remember my Apple IIc being a big deal because it had 128KB RAM. > > I'm sure there's someone on this list who remembers the days of 'ed' on a > teletype tho, so I'm not going to try to out-nostalgia anyone here. > > (I have used a teletype once or twice, they aren't worthy of nostalgia. Good > riddance to the things.) > There are application forms from government departments that still ask for teletype numbers as of late 2016. This is indicative of something (rather not mention what I think) not very positive. Regards Dee From carl.soderstrom at real-time.com Mon Feb 6 14:48:48 2017 From: carl.soderstrom at real-time.com (Carl Wilhelm Soderstrom) Date: Mon, 6 Feb 2017 15:48:48 -0500 Subject: [tclug-list] New toy with a lot of memory In-Reply-To: References: <20170203214115.GA28778@nobelware.com> <20170203222504.GL20814@real-time.com> <20170203225323.GA31226@nobelware.com> <20170206152318.GN20814@real-time.com> Message-ID: <20170206204848.GU20814@real-time.com> On 02/06 02:35 , o1bigtenor wrote: > There are application forms from government departments that still ask for > teletype numbers as of late 2016. This is indicative of something (rather not > mention what I think) not very positive. I'm told our nuclear ballistic missile systems still use 8" floppies. No idea if it's true or not. -- Carl Soderstrom Systems Administrator Real-Time Enterprises www.real-time.com From iznogoud at nobelware.com Mon Feb 6 14:57:59 2017 From: iznogoud at nobelware.com (Iznogoud) Date: Mon, 6 Feb 2017 20:57:59 +0000 Subject: [tclug-list] New toy with a lot of memory In-Reply-To: <20170206204848.GU20814@real-time.com> References: <20170203214115.GA28778@nobelware.com> <20170203222504.GL20814@real-time.com> <20170203225323.GA31226@nobelware.com> <20170206152318.GN20814@real-time.com> <20170206204848.GU20814@real-time.com> Message-ID: <20170206205759.GA12134@nobelware.com> > > I'm told our nuclear ballistic missile systems still use 8" floppies. No > idea if it's true or not. > This. It was on MPR a few weeks/months ago. And the interesting fact is that those floppies may survive longer than some of the commodity hardware hard drives sold today. I remember the teletype from when I was a kid. OK, progress has been totally forward in this matter. Please do not take away my vinyl! (Record Store Day is only weeks away.) From carl.soderstrom at real-time.com Mon Feb 6 15:14:24 2017 From: carl.soderstrom at real-time.com (Carl Wilhelm Soderstrom) Date: Mon, 6 Feb 2017 16:14:24 -0500 Subject: [tclug-list] New toy with a lot of memory In-Reply-To: <20170206205759.GA12134@nobelware.com> References: <20170203214115.GA28778@nobelware.com> <20170203222504.GL20814@real-time.com> <20170203225323.GA31226@nobelware.com> <20170206152318.GN20814@real-time.com> <20170206204848.GU20814@real-time.com> <20170206205759.GA12134@nobelware.com> Message-ID: <20170206211424.GV20814@real-time.com> On 02/06 08:57 , Iznogoud wrote: > > > > I'm told our nuclear ballistic missile systems still use 8" floppies. No > > idea if it's true or not. > > > > This. It was on MPR a few weeks/months ago. And the interesting fact is that > those floppies may survive longer than some of the commodity hardware hard > drives sold today. Given that the magnetic spots on them are so huge, it would make sense. -- Carl Soderstrom Systems Administrator Real-Time Enterprises www.real-time.com From iznogoud at nobelware.com Tue Feb 7 08:15:08 2017 From: iznogoud at nobelware.com (Iznogoud) Date: Tue, 7 Feb 2017 14:15:08 +0000 Subject: [tclug-list] Daemontools or runit or something else? In-Reply-To: <20170126044534.GA11052@nobelware.com> References: <20170124220132.GA7933@nobelware.com> <20170124202011.GA4156@nobelware.com> <2822a78e6c6f310ccc05ca147fe45751@rainloop.oustrencats.com> <20170124205748.GD923@real-time.com> <20e6b0df66e2a49bc2d40fb593ae10e5@rainloop.oustrencats.com> <20170125190256.GA21659@nobelware.com> <20e1145b-ee85-cc2a-7d53-c4607012d876@jfoo.org> <20170126044534.GA11052@nobelware.com> Message-ID: <20170207141508.GA18308@nobelware.com> John, I found something that you may find useful for process monitoring, etc. It is loosely related to what you wanted but probably useful to know. Look here: http://oss.digirati.com.br/watchcatd/ I found this by looking here: http://libevent.org/ From eng at pinenet.com Tue Feb 7 12:16:38 2017 From: eng at pinenet.com (Rick Engebretson) Date: Tue, 7 Feb 2017 12:16:38 -0600 Subject: [tclug-list] New toy with a lot of memory In-Reply-To: References: <20170203214115.GA28778@nobelware.com> <20170203222504.GL20814@real-time.com> <20170203225323.GA31226@nobelware.com> <20170206152318.GN20814@real-time.com> Message-ID: <589A0F06.6070409@pinenet.com> While the "information" technology of old is ridiculous today, the "mechanical" technology would be worth a fortune today. I tore a junked large teletype apart, and a junked large card punch and reader apart. I still have the small desksize teletype/printer frame and added steel plate. The huge power transformer was very sophisticated, with capacitors the size of large beer cans. The separate circuit area was very accessable, and the printer/keyboard/interface desktop was comfortable for a seated worker. The stepper motor feeding the dot printer head has a screw over 2feet long, and I still have that. I have pondered building a fuel cell, or other power generator onto that beast. I also still have the frame on wheels for the IBM card punch/reader. But the incredible automation hulk had to go, sanity and my wife prevailed. It was a pleasure and honor to dis-assemble such electro-mechanical genius, especially when I see the machining junk now selling on eBay. I won't get in to what old hard drives looked like inside. Those were the prototypes for today's marvels. Innovation can win big or lose big. A good friend got a ton of money to automate plastic vacuum forming in the 1980s. Starving Rick pushed computers, but he chose pneumatics. Next I heard he ran off to Bolivia. gerry wrote: > On Mon, 6 Feb 2017, Carl Wilhelm Soderstrom wrote: >> On 02/03 10:53 , Iznogoud wrote: >>> At age 9 I had an Amstrad CPC 6128 with 128kB of RAM. >> >> I remember my Apple IIc being a big deal because it had 128KB RAM. >> >> I'm sure there's someone on this list who remembers the days of 'ed' >> on a >> teletype tho, so I'm not going to try to out-nostalgia anyone here. >> >> (I have used a teletype once or twice, they aren't worthy of >> nostalgia. Good >> riddance to the things.) >> > > Playing yahtzee and football on a teletype while my dad fixed the line > printers at Bemidji State ... those were the days. About 1975 or > so I think. > > > > -- > gsker > _______________________________________________ > TCLUG Mailing List - Minneapolis/St. Paul, Minnesota > tclug-list at mn-linux.org > http://mailman.mn-linux.org/mailman/listinfo/tclug-list > From iznogoud at nobelware.com Tue Feb 7 14:36:13 2017 From: iznogoud at nobelware.com (Iznogoud) Date: Tue, 7 Feb 2017 20:36:13 +0000 Subject: [tclug-list] New toy with a lot of memory In-Reply-To: <589A0F06.6070409@pinenet.com> References: <20170203214115.GA28778@nobelware.com> <20170203222504.GL20814@real-time.com> <20170203225323.GA31226@nobelware.com> <20170206152318.GN20814@real-time.com> <589A0F06.6070409@pinenet.com> Message-ID: <20170207203613.GA31879@nobelware.com> The new generation will have high-school projects where they replicate those old machines (teletypes, type-writers, and the like) with 3D printers. Hey, that's fun. From iznogoud at nobelware.com Tue Feb 7 22:39:33 2017 From: iznogoud at nobelware.com (Iznogoud) Date: Wed, 8 Feb 2017 04:39:33 +0000 Subject: [tclug-list] Linux timers In-Reply-To: <58940564.5090303@pinenet.com> References: <58849BCF.8070900@pinenet.com> <20170123025841.GA8597@nobelware.com> <58858CA1.2030707@pinenet.com> <20170124014604.GB27479@nobelware.com> <5886BE7F.7020202@pinenet.com> <58940564.5090303@pinenet.com> Message-ID: <20170208043933.GA16577@nobelware.com> > > I got a slimmed down freepascal version of the posix timer example to work; > > http://www.sytekcom.com/eng/fp_Linux_PosixTimer.html > I had a good look at what you have created. I was surprised to see that Pascal tries to control from within the source the library from which specific _external_ functions are picked, for example the timer-related calls from "rt" and signal-related calls from the "c" library (librt.so and libc.so). That is "strange" enough, controlling from the source what objects are linked are the linking step. But I do not really know Pascal and its idiosyncrasies. I will get the freepascal software and try to run it and see what the issue is with the unions. From eng at pinenet.com Wed Feb 8 06:28:05 2017 From: eng at pinenet.com (Rick Engebretson) Date: Wed, 8 Feb 2017 06:28:05 -0600 Subject: [tclug-list] Linux timers In-Reply-To: <20170208043933.GA16577@nobelware.com> References: <58849BCF.8070900@pinenet.com> <20170123025841.GA8597@nobelware.com> <58858CA1.2030707@pinenet.com> <20170124014604.GB27479@nobelware.com> <5886BE7F.7020202@pinenet.com> <58940564.5090303@pinenet.com> <20170208043933.GA16577@nobelware.com> Message-ID: <589B0ED5.9010909@pinenet.com> Big thanks for your interest. Where do I begin here? I code Pascal from the text editor "NEdit." With Pascal syntax highlight settings and tab space setting of 4 spaces it all reads like a book or poem to me. Code blocks are clearly marked by words like Program, uses, const, type, var, procedure, function, begin, end, interface, implementation, etc. Symbols, labels and names are (mostly) case insensitive so can be chosen for readability, instead of looking like a password to an online bank account separated by squiggles and stars. 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. 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. Standard interprocess communication, with precision intra-process events. Far too big a problem for me, but I'm delighted to learn the Linux community is equipped for industrial (not just informational) applications. Iznogoud wrote: >> I got a slimmed down freepascal version of the posix timer example to work; >> >> http://www.sytekcom.com/eng/fp_Linux_PosixTimer.html >> > I had a good look at what you have created. I was surprised to see that > Pascal tries to control from within the source the library from which > specific _external_ functions are picked, for example the timer-related > calls from "rt" and signal-related calls from the "c" library (librt.so > and libc.so). That is "strange" enough, controlling from the source what > objects are linked are the linking step. But I do not really know Pascal > and its idiosyncrasies. > > I will get the freepascal software and try to run it and see what the issue > is with the unions. > _______________________________________________ > TCLUG Mailing List - Minneapolis/St. Paul, Minnesota > tclug-list at mn-linux.org > http://mailman.mn-linux.org/mailman/listinfo/tclug-list > From iznogoud at nobelware.com Wed Feb 8 13:16:56 2017 From: iznogoud at nobelware.com (Iznogoud) Date: Wed, 8 Feb 2017 19:16:56 +0000 Subject: [tclug-list] Linux timers In-Reply-To: <589B0ED5.9010909@pinenet.com> References: <58849BCF.8070900@pinenet.com> <20170123025841.GA8597@nobelware.com> <58858CA1.2030707@pinenet.com> <20170124014604.GB27479@nobelware.com> <5886BE7F.7020202@pinenet.com> <58940564.5090303@pinenet.com> <20170208043933.GA16577@nobelware.com> <589B0ED5.9010909@pinenet.com> Message-ID: <20170208191656.GA17288@nobelware.com> 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." From eng at pinenet.com Wed Feb 8 15:12:42 2017 From: eng at pinenet.com (Rick Engebretson) Date: Wed, 8 Feb 2017 15:12:42 -0600 Subject: [tclug-list] Linux timers In-Reply-To: <20170208191656.GA17288@nobelware.com> References: <58849BCF.8070900@pinenet.com> <20170123025841.GA8597@nobelware.com> <58858CA1.2030707@pinenet.com> <20170124014604.GB27479@nobelware.com> <5886BE7F.7020202@pinenet.com> <58940564.5090303@pinenet.com> <20170208043933.GA16577@nobelware.com> <589B0ED5.9010909@pinenet.com> <20170208191656.GA17288@nobelware.com> Message-ID: <589B89CA.4040809@pinenet.com> 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 > From iznogoud at nobelware.com Wed Feb 8 17:01:54 2017 From: iznogoud at nobelware.com (Iznogoud) Date: Wed, 8 Feb 2017 23:01:54 +0000 Subject: [tclug-list] Linux timers In-Reply-To: <589B89CA.4040809@pinenet.com> References: <58849BCF.8070900@pinenet.com> <20170123025841.GA8597@nobelware.com> <58858CA1.2030707@pinenet.com> <20170124014604.GB27479@nobelware.com> <5886BE7F.7020202@pinenet.com> <58940564.5090303@pinenet.com> <20170208043933.GA16577@nobelware.com> <589B0ED5.9010909@pinenet.com> <20170208191656.GA17288@nobelware.com> <589B89CA.4040809@pinenet.com> Message-ID: <20170208230154.GB25691@nobelware.com> Got it Rick. Yes, we discussed this before; for high-fidelity acquisition measurements you will need precise time. You do not want a soft timer for that, but something that queries the hard clock. If you can afford having a process devoted to full-time data acquisition (and you should if you need it), have it making continuous queries to the clock and decide to trigger the acquisition event. With some offline tests and experimentation you can associate a time-scale with the response from the data-acquisition interface such that data is perfectly matched to an objective time. Peg the process to a core and keep it there. There has got to be a lot of work done on this. People do super high frequency measurements with proper hardware, and I am sure somebody out there has pushed the limit of it under some Linux setup. From eng at pinenet.com Thu Feb 9 01:13:45 2017 From: eng at pinenet.com (Rick Engebretson) Date: Thu, 9 Feb 2017 01:13:45 -0600 Subject: [tclug-list] Linux timers In-Reply-To: <20170208230154.GB25691@nobelware.com> References: <58849BCF.8070900@pinenet.com> <20170123025841.GA8597@nobelware.com> <58858CA1.2030707@pinenet.com> <20170124014604.GB27479@nobelware.com> <5886BE7F.7020202@pinenet.com> <58940564.5090303@pinenet.com> <20170208043933.GA16577@nobelware.com> <589B0ED5.9010909@pinenet.com> <20170208191656.GA17288@nobelware.com> <589B89CA.4040809@pinenet.com> <20170208230154.GB25691@nobelware.com> Message-ID: <589C16A9.7080304@pinenet.com> Just to conclude this thread, I wanted to share that I found an example program in the 7-17-2016 Unix(7) manual page that uses the newer SOCK_SEQPACKET socket types. My older 2012 manual page does not. I don't mind feeling old, but I like to think I still know something, so I'll sleep well tonight and brag to my wife tomorrow. The example even calls the exchanged messages "commands" so the Linux experts are thinking like us, or maybe more like you. And remember, I use freepascal because I can't program in C. Younger programmers should be younger. Speaking anatomically, how the server "brain" controls and gets feedback from several client "limbs" in an industrial automaton is academic. For me it's nice to know linux is available. And that energy link provided earlier is a hot topic. Cybersecurity, various climate and technology and efficiency issues, etc. invite existing Linux capabilities. Lots of blanks to fill in by lots of young people inventing their future. Ooops, sorry to lecture. Thanks. Iznogoud wrote: > Got it Rick. Yes, we discussed this before; for high-fidelity acquisition > measurements you will need precise time. You do not want a soft timer for > that, but something that queries the hard clock. > > If you can afford having a process devoted to full-time data acquisition > (and you should if you need it), have it making continuous queries to the > clock and decide to trigger the acquisition event. With some offline tests > and experimentation you can associate a time-scale with the response from > the data-acquisition interface such that data is perfectly matched to an > objective time. Peg the process to a core and keep it there. > > There has got to be a lot of work done on this. People do super high > frequency measurements with proper hardware, and I am sure somebody out > there has pushed the limit of it under some Linux setup. > > _______________________________________________ > TCLUG Mailing List - Minneapolis/St. Paul, Minnesota > tclug-list at mn-linux.org > http://mailman.mn-linux.org/mailman/listinfo/tclug-list > From iznogoud at nobelware.com Thu Feb 9 09:56:12 2017 From: iznogoud at nobelware.com (Iznogoud) Date: Thu, 9 Feb 2017 15:56:12 +0000 Subject: [tclug-list] Linux timers In-Reply-To: <589C16A9.7080304@pinenet.com> References: <58858CA1.2030707@pinenet.com> <20170124014604.GB27479@nobelware.com> <5886BE7F.7020202@pinenet.com> <58940564.5090303@pinenet.com> <20170208043933.GA16577@nobelware.com> <589B0ED5.9010909@pinenet.com> <20170208191656.GA17288@nobelware.com> <589B89CA.4040809@pinenet.com> <20170208230154.GB25691@nobelware.com> <589C16A9.7080304@pinenet.com> Message-ID: <20170209155612.GA27975@nobelware.com> > > Just to conclude this thread, I wanted to share that I found an example > program in the 7-17-2016 Unix(7) manual page that uses the newer > SOCK_SEQPACKET socket types. My older 2012 manual page does not. I don't > mind feeling old, but I like to think I still know something, so I'll > sleep well tonight and brag to my wife tomorrow. > > The example even calls the exchanged messages "commands" so the Linux > experts are thinking like us, or maybe more like you. > You are talking about this one: http://man7.org/linux/man-pages/man7/unix.7.html This is a great example. There are conventions used there, in the spirit of what I was talking about. The server expects keywords, like DOWN and END, and will pass if anything is garbled. This is typical of an example with no error-checking beyond the null-terminated string, etc. (Essentially, there is no protocol when you are writing your own software for your use or tests.) Inter-process communication, as was mentioned in that man page, is also done with pipes through the file-system. There are pros and cons to this. There is also shared-memory type communication with the "RAM drive" that is typically in a mount-point like /dev/shm. In the case of pipes, you write to a pipe and you read from the other side. The process is FIFO and you will need some system call like "select()" to monitor a file pointer. There are also pipes that stay within a memory space so that threads can talk to eachother in the same way. I use this for my audio sequencer software to get real-timeness on POSIX thread communication where one thread manages the hardware via ALSA and another thread generates sounds to fill a buffer. Here is a snippet from my software: read(seq->pipep[0], cmd, (size_t) 4); if(strncmp(cmd,"QUIT",4) == 0) icmd = -1; if(strncmp(cmd,"WAIT",4) == 0) icmd = 0; if(strncmp(cmd,"PLAY",4) == 0) icmd = 1; switch(icmd) { The above code reads from the pipe, identifies one of three expected commands, and reacts (with the "switch" block of statements). It is triggered from the outcome monitoring of the pipe determines in the following statements: /* keep monitoring the pipe for a command from the master */ FD_ZERO(&rfds); FD_SET(seq->pipep[0], &rfds); nfds = seq->pipep[0] + 1; iret = select(nfds, &rfds, (fd_set *) NULL, (fd_set *) NULL, &stv); This method would work really well for real-timeness and your data acquisition needs. The timeout for the select() can be set given a gettimeofday() call that is used to try and maintain a constant rate. You need to do the thinking there on how this can work for you. I hope this helps, hence the long reply. One last thought regarding your automation discussion and for your information. You can do a lot with fully programmable OS type controlers based on the Raspberry Pi and the I2C functionality/protocol. (I love the Pi for a lot of reasons, mostly its price for a fully functioning computer.) Most components you need for sensors and automation can be had with I2C support built-in. It is a client-server protocol that is an industrial standard and it is well supported under Linux. Pythoners can use it via Python bindings to I2C, which is great, and that is how your Pascal code can probably interface well via a Python interface and a file- or pipe-based setup. Look it up. From eng at pinenet.com Thu Feb 9 11:59:17 2017 From: eng at pinenet.com (Rick Engebretson) Date: Thu, 9 Feb 2017 11:59:17 -0600 Subject: [tclug-list] Linux timers In-Reply-To: <20170209155612.GA27975@nobelware.com> References: <58858CA1.2030707@pinenet.com> <20170124014604.GB27479@nobelware.com> <5886BE7F.7020202@pinenet.com> <58940564.5090303@pinenet.com> <20170208043933.GA16577@nobelware.com> <589B0ED5.9010909@pinenet.com> <20170208191656.GA17288@nobelware.com> <589B89CA.4040809@pinenet.com> <20170208230154.GB25691@nobelware.com> <589C16A9.7080304@pinenet.com> <20170209155612.GA27975@nobelware.com> Message-ID: <589CADF5.60804@pinenet.com> Delighted in your youth. You have tons of good ideas, so don't let my grouches deter you. My (now) son-in-law bought me a Pi kit. The first problem was I had no USB keyboard. I had probably a dozen IBM PS2 clickety click keyboards (and some other cheapies) around, and I still use at least 2 of them to keep the wife awake. So he bought me a USB keyboard. Then "What is HDMI?" I asked. But once we hooked it up it was great "Raspian" linux, and even had XForms-toolkit and freepascal in the repository. It doesn't have a real-time clock however. I really got hissed at on AVRfreaks for suggesting a Linux terminal interface. Then came Arduino Uno, and I love that "Abstract Communication Module" (fake modem) interface. Now Intel has bought into Arduino and "Edisons" are happening. Apparently "Lady Gaga" and her drone army was a hit show at the Superbowl. So I don't know the future. But out here in the wilderness they buried a big fiberoptic cable under my driveway last fall. Century Link says I can get 10 megs(?). But Verizon has been great, too. When we first moved out here it would cost at least a dollar to call the next town, and a dollar was a lot 35 years ago. The mailwoman is very respectful of ebay packages. It's a different world, and mostly I like it. Your turn, dude. I'm going to grow asparagus. Iznogoud wrote: >> Just to conclude this thread, I wanted to share that I found an example >> program in the 7-17-2016 Unix(7) manual page that uses the newer >> SOCK_SEQPACKET socket types. My older 2012 manual page does not. I don't >> mind feeling old, but I like to think I still know something, so I'll >> sleep well tonight and brag to my wife tomorrow. >> >> The example even calls the exchanged messages "commands" so the Linux >> experts are thinking like us, or maybe more like you. >> > You are talking about this one: > http://man7.org/linux/man-pages/man7/unix.7.html > This is a great example. There are conventions used there, in the spirit of > what I was talking about. The server expects keywords, like DOWN and END, and > will pass if anything is garbled. This is typical of an example with no > error-checking beyond the null-terminated string, etc. (Essentially, there is > no protocol when you are writing your own software for your use or tests.) > > Inter-process communication, as was mentioned in that man page, is also done > with pipes through the file-system. There are pros and cons to this. There is > also shared-memory type communication with the "RAM drive" that is typically > in a mount-point like /dev/shm. In the case of pipes, you write to a pipe > and you read from the other side. The process is FIFO and you will need some > system call like "select()" to monitor a file pointer. There are also pipes > that stay within a memory space so that threads can talk to eachother in the > same way. I use this for my audio sequencer software to get real-timeness on > POSIX thread communication where one thread manages the hardware via ALSA and > another thread generates sounds to fill a buffer. Here is a snippet from my > software: > > read(seq->pipep[0], cmd, (size_t) 4); > > if(strncmp(cmd,"QUIT",4) == 0) icmd = -1; > if(strncmp(cmd,"WAIT",4) == 0) icmd = 0; > if(strncmp(cmd,"PLAY",4) == 0) icmd = 1; > > switch(icmd) { > > The above code reads from the pipe, identifies one of three expected commands, > and reacts (with the "switch" block of statements). It is triggered from the > outcome monitoring of the pipe determines in the following statements: > > /* keep monitoring the pipe for a command from the master */ > FD_ZERO(&rfds); > FD_SET(seq->pipep[0], &rfds); > nfds = seq->pipep[0] + 1; > iret = select(nfds, &rfds, (fd_set *) NULL, (fd_set *) NULL, &stv); > > This method would work really well for real-timeness and your data acquisition > needs. The timeout for the select() can be set given a gettimeofday() call > that is used to try and maintain a constant rate. You need to do the thinking > there on how this can work for you. I hope this helps, hence the long reply. > > > One last thought regarding your automation discussion and for your information. > You can do a lot with fully programmable OS type controlers based on the > Raspberry Pi and the I2C functionality/protocol. (I love the Pi for a lot > of reasons, mostly its price for a fully functioning computer.) Most components > you need for sensors and automation can be had with I2C support built-in. It > is a client-server protocol that is an industrial standard and it is well > supported under Linux. Pythoners can use it via Python bindings to I2C, which > is great, and that is how your Pascal code can probably interface well via > a Python interface and a file- or pipe-based setup. Look it up. > > _______________________________________________ > TCLUG Mailing List - Minneapolis/St. Paul, Minnesota > tclug-list at mn-linux.org > http://mailman.mn-linux.org/mailman/listinfo/tclug-list > From tclug at freakzilla.com Sat Feb 18 13:53:20 2017 From: tclug at freakzilla.com (Clug) Date: Sat, 18 Feb 2017 13:53:20 -0600 (CST) Subject: [tclug-list] Anyone want a GTX 970? Message-ID: I upgraded my system and have this GPU left over (ASUS Strix GTX 970). Previous gen but pretty much the best of it's class. Figured I'd ask on here before I go CL/eBay... From trnja001 at umn.edu Sat Feb 18 14:30:35 2017 From: trnja001 at umn.edu (Elvedin Trnjanin) Date: Sat, 18 Feb 2017 14:30:35 -0600 Subject: [tclug-list] Anyone want a GTX 970? In-Reply-To: References: Message-ID: <9CBB56C6-30D1-462E-BC04-C909F58651FA@umn.edu> I'm interested in adding it to my desktop. What's your location and how much for the card? Thanks, Elvedin > On Feb 18, 2017, at 1:53 PM, Clug wrote: > > I upgraded my system and have this GPU left over (ASUS Strix GTX 970). Previous gen but pretty much the best of it's class. Figured I'd ask on here before I go CL/eBay... > _______________________________________________ > TCLUG Mailing List - Minneapolis/St. Paul, Minnesota > tclug-list at mn-linux.org > http://mailman.mn-linux.org/mailman/listinfo/tclug-list From tclug at freakzilla.com Sat Feb 18 15:45:18 2017 From: tclug at freakzilla.com (Clug) Date: Sat, 18 Feb 2017 15:45:18 -0600 (CST) Subject: [tclug-list] Anyone want a GTX 970? In-Reply-To: <9CBB56C6-30D1-462E-BC04-C909F58651FA@umn.edu> References: <9CBB56C6-30D1-462E-BC04-C909F58651FA@umn.edu> Message-ID: Hi there, I'm in Shoreview, and I'm asking $150. On Sat, 18 Feb 2017, Elvedin Trnjanin wrote: > I'm interested in adding it to my desktop. What's your location and how much for the card? > > Thanks, > Elvedin > >> On Feb 18, 2017, at 1:53 PM, Clug wrote: >> >> I upgraded my system and have this GPU left over (ASUS Strix GTX 970). Previous gen but pretty much the best of it's class. Figured I'd ask on here before I go CL/eBay... >> _______________________________________________ >> TCLUG Mailing List - Minneapolis/St. Paul, Minnesota >> tclug-list at mn-linux.org >> http://mailman.mn-linux.org/mailman/listinfo/tclug-list > _______________________________________________ > TCLUG Mailing List - Minneapolis/St. Paul, Minnesota > tclug-list at mn-linux.org > http://mailman.mn-linux.org/mailman/listinfo/tclug-list > From tclug at freakzilla.com Sat Feb 18 15:46:57 2017 From: tclug at freakzilla.com (Clug) Date: Sat, 18 Feb 2017 15:46:57 -0600 (CST) Subject: [tclug-list] Anyone want a GTX 970? In-Reply-To: References: <9CBB56C6-30D1-462E-BC04-C909F58651FA@umn.edu> Message-ID: That was NOT supposed to go to the list - I apologise. Elvdin, please reply directly to my address rather than the list. On Sat, 18 Feb 2017, Clug wrote: > Hi there, > > I'm in Shoreview, and I'm asking $150. > > On Sat, 18 Feb 2017, Elvedin Trnjanin wrote: > >> I'm interested in adding it to my desktop. What's your location and how >> much for the card? >> >> Thanks, >> Elvedin >> >>> On Feb 18, 2017, at 1:53 PM, Clug wrote: >>> >>> I upgraded my system and have this GPU left over (ASUS Strix GTX 970). >>> Previous gen but pretty much the best of it's class. Figured I'd ask on >>> here before I go CL/eBay... >>> _______________________________________________ >>> TCLUG Mailing List - Minneapolis/St. Paul, Minnesota >>> tclug-list at mn-linux.org >>> http://mailman.mn-linux.org/mailman/listinfo/tclug-list >> _______________________________________________ >> TCLUG Mailing List - Minneapolis/St. Paul, Minnesota >> tclug-list at mn-linux.org >> http://mailman.mn-linux.org/mailman/listinfo/tclug-list >> > _______________________________________________ > TCLUG Mailing List - Minneapolis/St. Paul, Minnesota > tclug-list at mn-linux.org > http://mailman.mn-linux.org/mailman/listinfo/tclug-list > From tclug at thelinuxshack.com Wed Feb 22 11:03:48 2017 From: tclug at thelinuxshack.com (Nicholas Schuetz) Date: Wed, 22 Feb 2017 11:03:48 -0600 Subject: [tclug-list] Meetup Kickoff Meeting: Docker, Kubernetes and OpenShift with Grant Shipley Message-ID: Howdy TCLUG, I'd like to welcome you all to join us for our first OpenShift and Kubernetes Minnesota Meetup at Day Block Brewing Event Center tomorrow: https://www.meetup.com/Minneapolis-OpenShift-Meetup/events/237164323/ There will be refreshments, snacks, SWAG and great conversation. It should be a cool event for anyone interested in Linux Containers, Kubernetes and OpenShift. Hope to see you there, Nick