|
Member 14968771 wrote: I am trying to stay away from "low energy" technology for now.
My tip: If you have a choice, not dictated by external requirements (and that's what it sounds like), get into Bluetooth Low Energy as soon as possible. That is where things are happening nowadays. A whole lot of talk about 'Bluetooth' is in fact a short form of 'Bluetooth Low Energy'. Some of the new BLE application areas, such as the fairly new LC3 codec for BLE headphones, is really good, but will probably never be adapted to non-LE Bluetooth (according to a friend who has been actively working with the adaptation to BLE).
Expect any Bluetooth device running on batteries that you cannot reasonably charge every day to use BLE. Non-LE is primarily for stationary and semi-stationary equipment, plus your smartphone. The smartphone talks BLE to most other stuff.
|
|
|
|
|
|
Member 14968771 wrote: I am not sure want to get into "client / server / host " discussion.
Member 14968771 wrote: keep your comments to yourself - no need to rub it in
Granted. You now have 2 wishes left.
Bastard Programmer from Hell 
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
Greetings Kind Regards May I please inquire will an appreciable/significant/useful/meaningful overall speed performance difference result comparing two PCs each w/ same version intel i7 same memory size i.e. 16GB same SSD for purpose of software development i.e. compile/link/build durations one w/ DDR3 memory other w/ DDR4 memory Thank You Kindly
|
|
|
|
|
There is only one way to find out.
|
|
|
|
|
Programming tool temporarily running on RAMDISK would benefit from higher bandwidth for file i/o during multi-threaded compiling and have much better random-access latency than SSD. But instead of upgrading RAM, you could buy a better CPU cooler and give it a bit overclock for cores & caches and have better performance in everything, not just compiling.
Because, CPU cache is used well in compiling codes because codes are converted to graphs of commands. Traversing graphs cause a lot of re-used data from memory that is mainly the CPU cache.
|
|
|
|
|
I have one instance set up and working on another computer I did all the same steps (at least I think) to set it up on another computer, it works with CPU detection, but since it's an i3 I am trying to get the GPU detection working I am using an EVGA 1070 and I get this error on the log screen.
Object Detection (YOLO): (General Exception) : CUDA error: an illegal memory access was encountered
I am not sure how to troubleshoot the issue, I cloned the hard-drive from the working machine downloaded the 1070 driver and still received the same error.
I appreciate any help you have to give.
|
|
|
|
|
Hi all,
Soon we will move to a different building with 2 +/- 100 square meters floors.
I want to have a mesh wifi network covering all the house / 2 floors.
That is the topology I am planning:
Second floor ==> Optical fiber ---> ISP ROUTER (working as ONT, configured in bridge mode/single point) ---> Unmanaged SWITCH [2 computers C1 and C2, a printer P1, a MESH ROUTER (alien amplifi, orbi...), a CAT 6 cable to another unmanaged switch at the first floor].
First Floor ==> unmanaged switch [2 computers C3 and C4, a printer P2, a MESH ACCESS POINT].
Questions:
Can we do this?
I mean can we connect the ISP router set in bridge mode to a switch and then connect a few devices AND the MESH ROUTER to that switch?
If one of the devices is a long cable to another switch on the first floor and there, we plug the MESH ACCESS POINT and several other devices...
Would C1 (computer on the second floor) be able to see C4 (computer on the first floor)?
Would the Mesh access point be connected to the MESH router using the physical cable?
Hope all this makes any sense.
Thank you all for your time and help.
![Beer | [beer]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/beer.gif)
|
|
|
|
|
You'll probably hate me for answering to your post without giving you the answer you want.
But it doesn't exist.
When your application sends out some text on a serial line, going to a teletype or CRT or whatever, it sends that text away. The text on your screen is not the string in your application. It is a copy of a string in your application - a copy that has been sent away.
Imagine yourself sending a letter (in the paper sense) to a friend. This friend picks up his yellow marker to highlight a couple words that you wrote; he might refer to those words when replying to you. You are asking for a way to change the letter you sent him a day or two ago, in the words that your friend highlighted. You can't. The words are no longer under your control.
The xterm highlighting you see is completely independent of your application. xterm is like a remote friend of the application: The text(copy) belongs to xterm, and it is xterm doing the highlighting, completely out of the control of the application. Whatever your xterm wants to do with the highlighted word(s), it can do. Essentially, it can copy the word(s) into a copy/paste buffer and paste it in as part of the input so that you don't have to type it on the keyboard. The application knows nothing about this copy/paste business and sees the paste as if it was typed.
If you want your application to be aware of highlighting done by the user, xterm is not the right tool You will have to write your own X11 client. It may look quite similar to that xterm client at the UI, but it will have a very different interface to your application, not trying to emulate an RS232 connected dumb terminal, the way xterm does.
|
|
|
|
|
Member 14968771 wrote: Your analogy is plausible, however, it does not explain how clicking on the text highlights it – if it is "gone" / does not exist per your explanation.
It does not exist in your application (well, your application may still have the original, from which a copy was sent to xterm, but that is a different object). But xterm saves in its own buffer the output it receives from the application. It uses the contents of the buffer to redraw the window, say, if you resize it, or scroll the text up and down.
This text buffer belongs to xterm. It is not accessible to your application. The highlighting is done in this buffer, by xterm.
All you input and output goes through xterm (as long as your focus is in the xterm window). xterm knows where you click your mouse, and knows the size of character cells in its window (they are all the same, at least in classic xterm). Calculating from the mouse coordinates which character cell was clicked is trivial. (If you use variable-width font, it is just semi-trivial.) xterm starts at from this character and looks at the preceding and following characters in its text buffer. As long as they are 'word characters', it adds highlight to it and searches forward, but stops on whitespace, punctuation etc.
If you could monitor the connection between xterm and your application when you mark the word, you would see none. The marking is something xterm does for itself, alone.
I haven't been working with xterm for a number of years, and don't remember all the details, but like most *nix-born applications, it has a ton of options. I guess that you can tell xterm to give you all the raw input - certainly from the keyboard, so that your application can interpret copy (mark) and paste keystrokes, but maybe even mouse input. Your problem is that xterm manages its own scrolling, word wrapping etc. and your application cannot know where it has placed the output text you gave it. So even if you get the mouse click position, you don't have the information to know which word the cursor was pointing at.
If I understand your need correctly (and you do not want to give your application its own tailor made X-based user interface), the simple but somewhat pedal driven way to do it is to open a text editor with a new empty file (or one where you want to add another log record), mark the text in your xterm window, and then past them into the file in the text editor. There are multiple ways to mark text in xterm - single, double, triple click, mouse drag etc.
By *nix conventions marked text is put into the copy&paste buffer. I believe (not 100% sure) that even the Windows version of xterm is *nix like; it doesn't require any ctrl-C to copy the text. Pasting into the text editor file (or any other *nix style application) is usually done with the middle mouse button (or left, if you have no middle). If you run in Windows environment, and the text editor is a Windows application, be prepared to use ctrl-V or some menu selection to paste the text.
And again: If you monitor the communication between your application and xterm, there is no trace of the copy&paste into the text editor file. The copying is a private matter between xterm and the editor.
If you have as a requirement that your application must be aware of the copy&paste, you have to abandon xterm and straight command line output, and give your application its own X-based GUI. That will complicate it significantly. If you go for that solution, do not attempt to program at the X.11 level - that is like 'GUI assembly coding'. Find some X.11 based library / GUI platform. I haven't made a *nix GUI since Motif was the standard library, but most likely, today it has competition from about 42 alternative libraries, all open source, free for you to study the source code 
|
|
|
|
|
"Selecting" is an illusion; screen coordinates interpreted by the OS, then the framework (which gives it context), and lastly the application.
There's nothing to "grab" except pixels unless you have a hook into the framework or app. The "device" knows nothing of the software that drives it; and that's why you're in the wrong forum, again.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
|
|
|
|
|
That is just a feature of the Window that displays the text, and most Window types have that feature. So unless the window allows you to copy/cut the highlighted text you are out of luck.
|
|
|
|
|
Insisting your Linux / Bluetooth issues are "hardware and device" issues ... because that's "your choice". You think that will help your case?
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
|
|
|
|
|
|
You've chosen the wrong site for your linux support questions, so YOU deal with it!
|
|
|
|
|
Hello, I am creating a program that will find and identify all equipment on a network. I need to find all computers, printers, thumdrives, cams, external harddrives, bar coder/scanners, ... It might be easier to state what I do not need. I do not need keyboards, mice, hubs, usb hubs, etc.
I prefer VB.net since that is what we use in the office.
modified 25-Aug-22 1:49am.
|
|
|
|
|
...and the actual problem you're having with this is...?
|
|
|
|
|
Harry, As desirable as a solution to your issue may be, you have listed devices that are typically on different "networks", some (e.g. USB) that require access through a likely opaque bridge (PC). Not an easy task.
|
|
|
|
|
Watch who you're replying to.
I don't need the notification that you posted anything to me, but the OP does.
Also, I already know what you're talking about.
|
|
|
|
|
Impossible. Cut your losses and go home.
|
|
|
|
|
OK ... go for it. This is not where we go: "I couldn't help overhearing ..."
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
|
|
|
|
|
|
How were the electronical hardware settings on a plane stored before the invention of solid state hard drives? To my mind a plane`s auto pilot is a rather complex piece of software with a lot of data to be kept somewhere when the plane computer is off. Also there are plenty of other electronics that need the default settings saved somewhere when the power is off.
A conventional hard drive must have been rather unpractical on a moving vehicle.
Also the lack of storage makes you understand how rudimentary the aero plane electronical devices were in WW2 days and even a few decades after that.
[edit]
I think my question is broader that the scope of aero plane electronics. How are the default settings in (general purpose) electronics being saved? One of my guesses is that the logic is hard coded into the circuitry. For instance the shape of a number on an old numerical display is not saved digitally (as dots making the shape) but rather each of the 7 segments making the digit has a corresponding electronical component that kicks in when required. It`s really difficult to figure out how electronics work when you`re born with a notebook in your lap, somehow understand how the software works but preserve a very vague understanding of what`s under the notebook casing.
modified 20-Aug-22 10:16am.
|
|
|
|
|
I would think it's mostly analog; which in my mind is simpler than dealing with digital feedback information. Altitude, velocity, direction, orientation, ...; action - reaction.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
|
|
|
|
|
thanks.
your second statement is slightly disorienting. You`re talking about digital "feedback" which is similar, on a superficial level, with force feedback. If my understanding is correct planes do have force feedback on the control column.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
