Search results

Digging further into the lex man page, you can do something like this (and use non-blocking I/O!): %{ /* Current socket to process */ extern int currentSocket; /* Stop scanning on YY_NULL */ %option noyywrap #define YY_INPUT(buf,result,max_size) \ { \ ssize_t recvSize =...

Do you really need a powerful lex parser then? Are there libraries that can do this parsing in a more canonical way? I think lex can be made to solve this problem ... although it's not straightforward to me how. At this stage, I would Invesigtate the C++ interface - it may cope better with...

I just noticed a section titled "Multiple Input Buffers" in the man page of lex. Yeah, use fdopen with yy_create_buffer for every new socket, and then yy_switch_to_buffer on recv. By the way, libevent (or even libev) makes this pretty trivial. You could pass the YY_BUFFER_STATE as the extra...

You could use fdopen to make a socket into a FILE * and then assign that to yyin. Lex seems limited to one input stream at a time, but maybe you could swap yyin out based on the socket you're processing. Something tells me that making a socket into a FILE * could have all sorts of bad side...

I couldn't say. Such a system doesn't exist ... the closest thing to it is Siri which runs on a remote server farm. If your Internet connection is severed, then I'd agree, you'd definitely need something else (like a keyboard) in such a case. Complexity doesn't necessarily mean it's horribly...

You also read too much into it. CPU and RAM is a more expendable resource than it used to be. You're the newbie here. You still haven't told me what you base your claim on

I think you read too much into it.

Why stop at the keyboard or even TTY? Anything can fail in the kernel and leave you equally stuck ... even unprovoked. But while we're at it, if such a service is a user space process then that is definitely more stable than anything in kernel space. *yawn* Besides, what do you base that on...

Meanwhile, software continues to be dumber than a bag of hammers. I personally believe smart software can overcome stupid input interfaces while being practical and convenient. Dictation is about as stupid as it gets. But when NLP and AI advance enough so that you can hold a meaningful...

Everything else provided by the operating system is also software and prone to crash. Some of it can bring down the entire machine (or leave the machine hanging). What's the difference?

You can probably force the attach by changing the atheros vendor ID to 0x0000 ... though I'm not sure if this has consequences. I would comment out the lines for ath* in your kernel config and build them as modules instead to experiment. You probably should file a PR. I know Adrian is very...

Here's a similar post: http://unix.derkeiler.com/Mailing-Lists/FreeBSD/current/2009-05/msg00518.html The only difference is chip=0x0013168c I'm not sure how the various fields in pciconf are used to extract vendor and chip id in the driver (I know nothing about the ath driver), however I...

Far larger? I can't even tell if it's even slightly larger ... See for yourself: http://en.wikipedia.org/wiki/Comparison_of_open-source_wireless_drivers#Linux http://en.wikipedia.org/wiki/Comparison_of_open-source_wireless_drivers#OpenBSD I mean ... it's not FreeBSD, but you do pay...

Almost certainly. It is a burden (for example) to prepare presentations, write papers and program on tablets. Even Swype does not compare to a real keyboard for these tasks. Perhaps if you plug a keyboard into a tablet ... That said, I do know of someone with no hands who programs in C++ with...

I don't know. I would hope that PCs and mobile devices continue to become more powerful. With more powerful devices and improved algorithms, perhaps this sort of toolkit can run on the devices itself. The cloud may stifle that (all in the name of marketing/protecting IP). Machine learning has...

Agreed, tablets are quite the toy presently. But I don't think they have to be and I do think they can be productivity systems with a lot of UI work. Whether their plethora of input devices can be made to be more efficient than keyboards and mice remains to be seen ... I think they can be with...

*yawn* vim on iPad. More of the same old ... Why not? Machine learning and computer vision can create realistic photographs from simple labeled sketches (here). Why can't an AI assist you in development through otherwise inefficient interfaces like touch screen and dictation? More of the same...

I don't think touch screens will ever be efficient by themselves. I really think future software will need AI interfaces to predict user intentions for touch screen to ever be efficient. This goes without saying for dictation too. That said, I never suggested anything like a desktop interface...

But what if there was a general and practical interface to do everything as easily (if not easier) than with a keyboard/mouse?

Admittedly, I'm not well versed in the details of Unix history. But I'm guessing that Unix didn't always have a tty subsystem. That it originally started with paper tape. Then it evolved to have ttys. Then it later evolved to have ptys and mouse support. What's next? Keyboards/mice may go...