**** BEGIN LOGGING AT Fri Jan 08 02:59:57 2021 Jan 08 03:51:43 c++ is interesting but... Jan 08 03:52:17 Should I learn more about it or use c instead? Conundrum! Issue number one! Concern! Problematic! Jan 08 03:52:26 Aw! Jan 08 03:53:58 I am learning from an older book, as usual, and I wanted to think of reasoning here where I know little about everything. Does c++ have a specific use that is becomes overachieving compared to other languages? Jan 08 03:54:48 Forget it. I cannot make sense right now. Scratch out the "becomes" word. Jan 08 04:01:25 if your messing alot with linux and building stuff c is more pertinent then c++ Jan 08 04:03:33 kinda depends on what your messing with but with linux and building things c is used alot more... not that i am saying its a bad thing learning c++ tho Jan 08 04:03:54 Okay. Jan 08 04:04:26 I was wondering what exact ideal does c++ have over other languages. Like, what is c++ good at doing? Jan 08 04:04:58 c++ is newer and alot more popular on windows i think Jan 08 04:04:58 Networking over Python or just a lot of extra features? Jan 08 04:05:05 Oh. Okay. Jan 08 04:05:16 c++ is used a lot on any platform Jan 08 04:06:05 c++ is used on a lot of different platforms but what are c++ strong points? Jan 08 04:06:51 Like Networking or embedded solutions or etc... Jan 08 04:07:21 Networking w/ embedded solutions...? Jan 08 04:07:22 Ha. Jan 08 04:07:59 c++ is usually more of a higher language Jan 08 04:08:14 like ap development and stuff Jan 08 04:08:18 c++ is a bit hard to describe... it's still a fairly low-level systems programming language like C, but it has a ton of features piled on, both compile-time (metaprogramming support, much more advanced type system) and runtime (dynamic dispatch, exceptions, runtime type information), and it has a much larger standard library Jan 08 04:08:25 c being older tends to be more system level stuff Jan 08 04:08:46 Mac uses C++ in the kernel Jan 08 04:09:05 I was just wondering. I will keep learning in time. This is not a concern. I was thinking that there may be a strong suit for c++. Jan 08 04:09:18 Did mac ever get their ARM chips for the new 'puters? Jan 08 04:09:27 theres nothing wrong with learning both really Jan 08 04:09:33 I've also used C++ on baremetal/embedded targets (with some restrictions on what language features you use, similar to the Mac's kernel C++ I think) Jan 08 04:10:15 set_: C++ is a large, complicated language that is not easy to learn, might want to start with something simpler like python :P Jan 08 04:10:24 Okay. I see there are a lot of C language concepts in C++ but w/ C++ having the extra added language features. Jan 08 04:10:26 i just find if your playing with embedded stuff c or assembly is better for low level stuff and things now like python seem to handle alot more of the application layer stuff Jan 08 04:10:39 Aw. Jan 08 04:10:40 Okay. Jan 08 04:11:34 I have been trying to learn more C/C++ stuff in time but finding time is difficult. So, when I do find time, I like @zmatt telling me to stick w/ another something or other like usual. Ha! Jan 08 04:11:36 been awhile since i did any mac programming so i wasnt sure if they were still using objective c/c++ or gone to normal c++ Jan 08 04:12:05 @zmatt: Why do you always lead me away from what I am doing? Jan 08 04:12:10 I think C++ used to be fully backwards compatible with C, in the sense that you could just compile your C source code as C++ and it works... that's not quite true nowadays but it's generally easy enough to tweak C code so it's also valid C++ Jan 08 04:13:13 I always thought C++ was good w/ graphics and networking for some reason. Jan 08 04:13:25 i mostly spend all my time in the embedded environment doing alot of re and dev work so i dont do much c++ or the newer c# stuff but i would tend to think your right with the backwards comp thing Jan 08 04:13:28 set_: because I know some roads are going to be dead ends and a waste of time... I've so far not seen any evidence from you that you grasp programming at all, and if you're unable to do so in python you will most definitely be unable to do so in C++ Jan 08 04:13:46 Oh. Jan 08 04:14:17 I took an online class on C++ for C People. Jan 08 04:14:22 Ha. Jan 08 04:14:23 i would agree as python is a good one and probably a real asset to learn these days Jan 08 04:14:27 It was a bit interesting. Jan 08 04:14:48 The teacher was trying to make people understand what ++ means. Jan 08 04:15:48 Ha. It was good, though. I got to see some differences like in preprocessor calls, and in other parts of the language like w/ defines, and then w/ what I am reading now... Jan 08 04:15:49 buzzmarshall: the main userspace application frameworks on Mac use Objective C, or Swift (which interoperates with it) Jan 08 04:16:23 The book describes a calculator. Jan 08 04:16:30 set_: preprocessor works the same in C and C++ afaik Jan 08 04:16:41 The main() of the calc... Jan 08 04:16:44 Oh? Jan 08 04:16:53 c was 1st and is a subset of C++ and kinda carries the the object and procedural methodolgies further ahead Jan 08 04:16:58 I thought you had to take off the .h part of the file in C++. Jan 08 04:17:08 Right. Jan 08 04:17:18 it's not quite a subset anymore, C and C++ have gone their separate ways Jan 08 04:17:28 ANSI! Jan 08 04:17:55 I think they call it ANSI C++ now. Jan 08 04:18:05 set_: for some inexplicable reason the C++ standard library headers don't use .h ... it's a complete mystery to me why Jan 08 04:18:13 Or have done so for some time... Jan 08 04:18:13 Ha. Jan 08 04:18:31 ansi is a standard as there are variations to the languages Jan 08 04:18:31 I know I do not know. I cannot help you w/ that one. I am still just reading. Jan 08 04:18:36 Oh. Jan 08 04:18:38 I don't know if ANSI ever standardized C++ directly, I think it's always been ISO/IEC Jan 08 04:18:51 Oh. I may be wrong. It was C then. Jan 08 04:19:00 I would check but...not now. Jan 08 04:19:32 ISO Certified. Okay. Maybe that is what I was thinking. Jan 08 04:19:43 C was standardized by ANSI in de 80s, the standard is now maintained by ISO Jan 08 04:19:45 People love their rule usage. Jan 08 04:19:59 not "ISO Certified" what.. it's standardized by ISO Jan 08 04:20:03 Wozzers. I wonder how old my language .pdf is then? Jan 08 04:20:15 It said ANSI on it. I am pretty sure. Jan 08 04:20:19 Yikes. Jan 08 04:20:22 then it's old Jan 08 04:20:28 Ha. Dang it. Jan 08 04:20:34 C99? Jan 08 04:20:41 C99 is not ANSI C Jan 08 04:20:45 Oh. Jan 08 04:20:51 ANSI C is a relic from the 80s Jan 08 04:20:56 Hmm. Jan 08 04:21:02 I should look it up. Jan 08 04:21:08 You are getting to me. Jan 08 04:21:11 Ha. Jan 08 04:21:26 @zmatt: What are you doing these days? Jan 08 04:21:31 Anything supernatural? Jan 08 04:21:54 C99 is the first modern-ish C revision, after which came C11 and C17 (the current standard) Jan 08 04:22:08 (C17 is just a minor revision of C11 though) Jan 08 04:22:14 C17 is the current. Okay. I have a book on C11. Jan 08 04:22:21 C11 is fine Jan 08 04:22:32 Nice! Jan 08 04:23:05 I am tossing the .pdf when I find it again. Jan 08 04:23:12 trash Jan 08 04:23:25 C++ has seen much more massive changes and learning it (which you shouldn't) should be from a resource that's written for C++17 Jan 08 04:24:09 (C++11 is already ancient, anything before that was the stone age of C++) Jan 08 04:24:19 Oh. I know, I know. You know better. But! Why not complicate your life and mine? It is not all about me (mister unselfish here)! Jan 08 04:24:25 Oh. Jan 08 04:24:42 Too cheasy? Jan 08 04:25:03 I am sorry. I just do not like being redirected. Jan 08 04:25:44 I know you know better but I am going to keep reading when I see fit. I will try to not make your issues part of my life or vice versa. Jan 08 04:25:47 haha... talk of stone age... i started out hacking on old cmp based machines Jan 08 04:25:57 sorry cpm Jan 08 04:26:27 Nice. Jan 08 04:26:27 kaypro's and osbournes and come commodores Jan 08 04:26:31 haha Jan 08 04:27:28 being a hacker im a hardware guy but it was necessary to know how to do code back then Jan 08 04:27:50 I have been reading on how to overcome error prone code w/ exceptions and more errors. Ha. Jan 08 04:28:37 over the years i basically just stayed at assembly and most c but have watched things grow just not had much need to go to the newer languages as almost everything i touch outside of my dev machines is embedded Jan 08 04:29:22 For instance...the main() block of source should not be dedicated to anything but starting and stopping the source. Functions should handle the exceptions and errors. Does this sound right? Jan 08 04:29:43 no Jan 08 04:29:48 at least these days there are tons of great learning tuts and docs freely available for anyone wanting to learn Jan 08 04:29:56 ha. Fine. Jan 08 04:30:09 I will reread that again and again until it is embedded in my brain. Jan 08 04:31:41 like, I have no idea what you're even trying to say with that sentence, it definitely doesn't sound like it even resembles a relevant point to necessary or even recommended program structure Jan 08 04:31:56 Come on... Jan 08 04:32:06 It must sound sort of reasonable. Jan 08 04:32:09 it doesn't Jan 08 04:32:12 Fine. Jan 08 04:32:20 I will go back to my corner. Jan 08 04:32:57 Like, starting/stopping can be a try except clause or a while loop. Jan 08 04:33:05 main is the main entry point of a C/C++ program, where essentially everything your program does happens (apart from initialization/cleanup handlers which may get invoked before/after main) Jan 08 04:33:19 nothing about that has anything to do with exceptions or error handling though Jan 08 04:33:50 Oh. So, one should try exceptions in the main function or try error handling in it too? Jan 08 04:34:30 I have no idea what you mean by that. main() is not special in any way to exception handling, it's just a function like any other Jan 08 04:34:49 ANyway sir...I will leave you be for now. YOu are heated. Jan 08 04:35:01 I am sorry for bringing up source ideas in chat. Jan 08 18:51:43 is extcon being deprecated? at least for tcpm it seems that connector is meant to be used instead of extcon in 5.4 Jan 08 20:23:25 what do you mean? extcon is a driver class, the usb connector binding spec is just a generic format for connector nodes in devices that have them rather than corresponding to any specific device driver Jan 08 20:24:33 as in the tcpm seems to try to get away from using extcon to bind various devices together... at least in the case of fusb302 and the updates it recieved to 5.4 from linux 4 Jan 08 20:25:40 hmm, fusb302 seems to have vestiges of extcon, but there is mention that it is not handled. instead it seems most control comes from the tcpm driver. Jan 08 20:26:21 https://github.com/beagleboard/linux/blob/3af6eaf5aa96b12490b082e8ca9f0b5ac6731cf5/drivers/usb/typec/tcpm/fusb302.c#L1707 Jan 08 20:28:27 usage of extcon in the fusb302 driver (which is the only use of extcon in the entire tcpm directory) does not seem to have changed between 4.19 and 5.4 Jan 08 20:29:13 from the sound of that particular line it seemed like it was not supported. Jan 08 20:31:14 referencing the extcon device via phandle isn't supported, it's doing it by name instead Jan 08 20:32:11 regardless of the comment I see no reason why you wouldn't be able to just set that property in DT Jan 08 20:33:34 the fusb driver also uses the usb-connector binding btw, but that has nothing to do with its use of extcon Jan 08 20:34:44 yea, looking it over i think i was misunderstanding what the extcon does. seems it only informs fusb302 of current limits. Jan 08 20:35:03 extcon only appears to be used for receiving status signals from usb2 battery charger detection logic Jan 08 20:35:12 to set the sink current limit Jan 08 20:35:25 yeah, that Jan 08 20:36:06 I'm still a little stuck on the best way to integrate the charger driver to tcpm, but i did notice the exporting of vbus_on enable... unfortunately not the charge_on variable Jan 08 20:36:12 which seems like an odd use of the concept of extcon Jan 08 20:37:10 or not actually, it seems extcon was meant exactly for that Jan 08 20:37:20 For now i'm taking your advice of rewriting the bq charger. had a lot of stuff that was tied directly to a custom fusb302 driver rather than tcpm Jan 08 20:38:08 extcon has surprisingly very little defined in its header. It does seem some of it is redundant with the definitions for typec connections\ Jan 08 20:38:10 what did I advice rewriting? Jan 08 20:38:31 what definitions for typec connections? Jan 08 20:38:36 the means of detecting driver Jan 08 20:38:41 again, extcon is an actual driver class, with a kernel API Jan 08 20:38:56 it was scanning the whole device tree Jan 08 20:38:57 drivers can find each other via extcon Jan 08 20:39:00 oh ew Jan 08 20:39:03 that thing Jan 08 20:39:18 right, some weird driver you find somewhere floating around on the web iirc? Jan 08 20:39:24 not something in mainline Jan 08 20:39:33 yup, i got it to work by commenting out half the driver code. Jan 08 20:40:01 yeah I now vaguely remember, it looked like it was someone's inept attempt at writing a driver :P Jan 08 20:40:15 also, it apparently used an irq to detect vbus state, rather than something more reasonable.. like a prochot signal perhaps.. Jan 08 20:40:47 a what Jan 08 20:41:11 in the irq work it would detect ac_online from the chip and re-write the next rising or falling trigger level of the irq Jan 08 20:41:26 ~PROCHOT Jan 08 20:41:37 signal saying somethings wrong Jan 08 20:41:45 I have no context for what you're saying Jan 08 20:41:49 sorry Jan 08 20:42:11 not important, but that driver was very custom. Jan 08 20:42:27 but I'm perfectly willing to believe that scanning the entire DT for a node is representative for the overall quality of the driver :P Jan 08 20:43:20 now i'm rewriting it based on sbs-charger.c Jan 08 20:59:43 what's the means to know what the current compatible string is that is executing the probe method? Jan 08 21:00:13 why would you need to? Jan 08 21:01:02 i have diffenet regmap configs Jan 08 21:01:09 based on which chip it is Jan 08 21:02:23 from what i'm seeing, i do regmap config init, then iterate over each and field alloc Jan 08 21:02:25 so use match data Jan 08 21:02:37 (and of_device_get_match_data() ) Jan 08 21:03:33 you mean put the [0](config+map),[1](config+map) into the data? Jan 08 21:04:14 as in put a struct with both the config and map in each data slot for the appropriate chip? Jan 08 21:05:39 as in, put whatever constants (including pointers to other information structures) you have that depend on device variant (determined by compatible-string) into a struct, define one per device variant, put the pointer into the match data Jan 08 21:06:28 e.g. https://github.com/beagleboard/linux/blob/4.19/drivers/spi/spi-omap2-mcspi.c#L1392-L1420 Jan 08 21:06:38 got it. I think. at least it makes sense now. thank you. Jan 08 21:07:12 (except those three structs should probably have been declared const :P ) Jan 08 21:08:05 it's not the only way to use match data, but it's a generic and typical way Jan 08 21:09:45 ohh interesting, so the structs could be of different type? how can you know which it is? in calling out the match, i see it referred to as pdata Jan 08 21:09:52 no? Jan 08 21:09:56 they're all the same type Jan 08 21:10:09 haha, oops Jan 08 21:10:14 yup see it Jan 08 21:10:37 i suppose if it was a raw pointer it could be anything at all ;) Jan 08 21:11:11 it can be anything at all, I'm pretty sure some drivers just stick a number in there instead of a pointer... it's up to you to decide what the value means Jan 08 21:11:28 yea saw a lot of numbers crammed in there. Jan 08 21:12:03 which is fine if a number is all you need, but a pointer to a struct is at least extensible if needed in the future Jan 08 21:13:00 also, older pre-DT drivers often already had such a "platform data" struct (containing information it needs for the instance) that was passed to them from board files Jan 08 21:15:39 the mcspi driver still has the legacy of that: the struct is uses is in a public header and if of_match_data() (which is an older and less user-friendly variant of of_device_get_match_data()) fails it falls back to dev_get_platdata() Jan 08 21:16:03 *it uses Jan 08 21:17:10 (in a DT-only driver of_device_get_match_data() should never fail) Jan 08 21:18:01 does that hold true if you modprobe the driver? Jan 08 21:18:34 having to manually modprobe the driver just means something is broken Jan 08 21:19:29 but I do remember some legacy weirdness with i2c devices Jan 08 21:20:04 as in, would of device fail if you modprobe it rather than being called out from dt Jan 08 21:20:24 modprobe does not result in a driver being probed, it just inserts the module Jan 08 21:20:57 Hi Jan 08 21:21:33 a driver gets probes because the kernel recognized that it matches a device which doesn't have a driver yet Jan 08 21:21:37 *probed Jan 08 21:22:03 ahhh sooo don't go initializing things in the probe... Jan 08 21:22:05 (normally the module will also get automatically loaded based on the same match data) Jan 08 21:22:15 I don't know what you mean by that Jan 08 21:24:21 like setting intial values for components Jan 08 21:24:28 if you want it to work with modprobe Jan 08 21:24:33 the normal sequence is: bus "discovers" device (e.g. by reading data from DT in case of platform devices), based on identifying information (compatible-string in case of DT) a driver is located, if none is found in a the kernel a callout is done to userspace to find and load the appropriate kernel module (based on the same matching data), if a driver has thus been located then its probe() will get ... Jan 08 21:24:39 ...called for the device Jan 08 21:24:40 * components= registers Jan 08 21:27:00 now like I said, i2c devices have some legacy weirdness... iirc you should provide both an .of_match_table and an .id_table with the latter identifiers being the compatible-strings without vendor prefix Jan 08 21:27:10 unless that's been fixed Jan 08 21:27:43 dunno but this driver certainly has that ids list Jan 08 21:28:01 yeah having both should at least be safe Jan 08 21:29:22 ah, here's the background issue: https://patchwork.ozlabs.org/project/linux-i2c/patch/1368397583-22769-1-git-send-email-linus.walleij@linaro.org/ Jan 08 21:29:45 I think Jan 08 21:29:57 no, there was also another issue Jan 08 21:31:35 like, I think the issue is that they can't switch to passing a MODALIAS suitable for matching compatible-strings to userspace without breaking compatibility until all existing i2c drivers that are used with DT are fixed to have an .of_match_data Jan 08 21:32:04 sounds like a pain Jan 08 21:32:25 so right now if you're missing a legacy .id_table your module would fail to get automatically loaded Jan 08 21:33:08 (while it's iirc no longer needed to get probed, having .of_match_data suffices for that, iirc) Jan 08 21:36:48 ah, and to fix the problem in the link I gave before that they added .probe_new to struct i2c_driver as replacement of .probe, without the legacy struct i2c_device_id * argument Jan 08 21:38:06 it also looks like the other issue might be fixed Jan 08 21:38:12 so maybe .id_table isn't needed anymore Jan 08 21:39:34 it's not Jan 08 21:40:20 "i2c: core: report OF style module alias for devices registered via OF" ... merged in kernel 4.18 Jan 08 21:41:11 at least I have a driver here with only .of_match_table, and it works as expected Jan 08 21:41:27 so yeah, forget everything I said, it has been fixed :) Jan 08 21:42:19 at least now you know why you'll often still see .id_table but why you no longer need it Jan 08 21:42:24 haha, it was flying over my head anyway. Jan 08 21:43:06 you probably still need it if you want to allow instantiating devices via sysfs Jan 08 21:43:46 the takeaway is: prior to 4.18: i2c_driver needs .id_table in addition to .of_match_table or module will fail to autoload, since 4.18 that's been fixed Jan 08 21:44:11 mru: actually no Jan 08 21:44:16 oh? Jan 08 21:45:07 see i2c_of_match_device_sysfs() in drivers/i2c/i2c-core-of.c Jan 08 21:45:44 ah, nice Jan 08 21:46:49 as long as you don't have two entries differing only in vendor prefix Jan 08 21:46:51 though that means the driver also has to use that to get the match data Jan 08 21:47:17 or you specify the vendor prefix via sysfs Jan 08 21:47:33 that function you mentioned skips it unconditionally Jan 08 21:47:45 uhh, no? Jan 08 21:47:48 no, I'm stupid Jan 08 21:48:04 that's just the fallback Jan 08 21:48:40 it's weirdly written Jan 08 21:49:08 if there is no vendor prefix, it compares the same thing twice Jan 08 21:50:35 Konsgn: so it seems for i2c devices specifically using i2c_of_match_device() is technically more correct than using of_device_get_match_data(), though the difference doesn't matter if you're using DT to declare the device Jan 08 21:51:07 mru: no, if sysfs doesn't use a vendor prefix, the first comparison will just always fail since it compares against compatible-string that does have one Jan 08 21:51:34 if the dt doesn't have a vendor prefix Jan 08 21:52:19 then 1. ew 2. yeah then it does do the same comparison twice Jan 08 21:52:32 they should have done if (!name) continue; Jan 08 23:05:31 Hi everybody! Happy new year! Jan 08 23:07:38 Can somebody tell me if the BeagleBone Black implements the trusted execution environment? And if yes: Can it be disabled? Jan 08 23:08:14 it doesn't implement it, there's nothing useful in secure world on GP AM335x devices Jan 08 23:08:50 (though I'm not sure why you'd want to disable it if it did, instead of just not using it) Jan 08 23:09:31 Thanks a lot zmatt! Jan 08 23:10:17 annoyingly TI restricts use of trustzone only to "High Security" devices for high volume customers (which get to burn their public key into efuses) Jan 08 23:11:14 (even though having any sort of customer-specific key burned into the chip is completely unnecessary for setting up a secure root of trust) Jan 08 23:11:53 aah by the way: Is there a reason why the website beagleboard.org isn't redirecting from http to https? Jan 08 23:13:02 yeah, some examples you can test by communicating with a local beaglebone via a websocket, which browsers don't allow from https websites (which is extremely annoying since they also don't provide any other way for websites to integrate with local devices) Jan 08 23:13:40 (and https sites can only use tls-secured websockets, which you can't use for local devices since those can't have a valid tls certificate) Jan 08 23:15:18 ok, so a general redirect would break stuff Jan 08 23:15:33 yeah Jan 08 23:16:05 has anybody here used a micro sd to flash their eMMC? Jan 08 23:16:08 also, for example, https://beagleboard.org/getting-started#step2 attempts to determine whether your beaglebone is reachable, and if so via which hostname/IP .. that doesn't work if served via https (for same reason) Jan 08 23:16:47 Cam: reflashing eMMC is almost always done using a micro sd card Jan 08 23:17:00 there's no other officially supported way Jan 08 23:17:40 maybe this can be fixed somehow Jan 08 23:18:43 I don't necessarily need to reflash. I was reading Derek Molly's book, and he talks about using lsblk to expand partition on the sd card. I initially flashed my eMMC with the micro SD card using a flasher image, but I was wondering if it'd be possible to use the SD card to allocate more space for the file system if the sd card contains a flasher Jan 08 23:18:43 image Jan 08 23:19:16 I can't run sudo apt upgrade because my eMMC only has 4gb and the flasher image is 3.77 gb, so after running upgrade I barely have any space left Jan 08 23:19:41 3.77 ? what image did you flash? Jan 08 23:19:52 Debian Buster IoT Flasher Image Jan 08 23:20:12 10.3 Jan 08 23:20:29 that image only uses 1.9G of space or so Jan 08 23:21:22 after I had done the upgrade the first time, I ran the df command and added up the result and I had ~152 of mb left Jan 08 23:21:46 I have a beaglebone with the latest buster IoT image on which I've installed a bunch of stuff and it has 2.3G in use Jan 08 23:21:55 added up what? Jan 08 23:22:16 the results from the df command Jan 08 23:22:27 what's there to add? it reports the free space directly Jan 08 23:22:50 does df report ram space? Jan 08 23:22:54 no Jan 08 23:23:01 if it does, how would I check out much space I have left on my eMMC? Jan 08 23:23:25 df Jan 08 23:23:31 df -h for more readable output Jan 08 23:23:53 the Avail column shows the amount of free space (minus a small amount of reserved space for emergency use by root) Jan 08 23:25:37 ro__: it would need to be fixed in browsers and they don't seem to give a single second of thought to how people are supposed to deal with local devices, they just break shit and don't care Jan 08 23:26:04 ro__: I still have one idea on how to work around it (using WebRTC DataChannel) but I haven't had time to explore it Jan 08 23:27:10 for now they're basically just forcing sites that want to interact with local devices (e.g. management or web gui for them) to sacrifice security by using http instead of https Jan 09 00:02:03 Does anyone know how to change the password for the board's wifi on a beaglebone wireless? Jan 09 00:02:23 probably in some config file Jan 09 00:02:53 I looked in /etc earlier and went through several files and directories and could not seem to find the info Jan 09 00:03:19 /etc/default/bb-wl18xx USE_PERSONAL_PASSWORD looks like it might be it? Jan 09 00:05:13 Yep, that looks like it. Thank you **** ENDING LOGGING AT Sat Jan 09 02:59:57 2021