Does anyone know how to use Win32's BitBlt() using Ruby? It seems like you need to use a destination DC (device context) and how can Ruby handle that? I use GetPixel() and it is really slow even to get 100 pixels (takes about 10 seconds). thanks.
Second Carl's other post: use win32 screenshot http://github.com/jarmo/win32screenshot
How about writing all of your image processing code in C++ as a Win32 executable and launching it as a separate process or calling into it from Ruby using the Win32API class? It makes sense to do it this way instead of writing a cludge in Ruby which will never perform as well.
I'd just like to note that I'm seeing a similar thing. GetPixel is exceedingly slow on Vista. I've determined that this is the case when you're using that Aero thing. If you set desktop theme to one of the "Classic" settings, it's fast again. And the OP's estimate of ~10 seconds is not wrong, believe it or not. It's really exceedingly slow.
I, too, am looking for a BitBlt in Ruby. I expect I'll need to figure it out/write it, but was hoping someone else has already posted an example.
I wouldn't go quite as far as Ed; chances are you only want to do some relatively simple and commonplace things that a normal GUI would do. For this, such libraries already exist and don't need to be written.
One example would be wxRuby.
I'm afraid I'm not familiar with it, but maybe it already offers some screen-grabbing utility methods.
Related
What I'm Doing
I am currently working on creating a SWI-Prolog module that adds tab-completion capability to the swipl-win window. So far I've actually gotten it to where it reads a single character at a time without stopping/returning anything until a tab character is typed. I have also already written a predicate that returns all possible completions of an incompletely typed term by using substring-matching on a list of current terms (obtained via current_functor/2, current_arithmetic_function/1, current_predicate/2, etc [the predicate used will eventually be based off of context]).
If you want to see my code, it is here...just keep in mind that I'm not exactly a Prolog master yet (friendly tips are more than welcome).
What I'm Thinking
I've long abandoned any efforts at using XPCE to do popup-dropdown-completion in the swipl-win window (I'll eventually try to get that into Pce-Emacs [it won't be as polished as Visual Studio --picture something more like Python's IDLE], but I don't know if that's really even practical since I'm starting to use actual Emacs a lot more nowadays anyway), but is there any way to modify the output color in the swipl-win window? I know syntax highlighting has already been implemented in other Prolog systems' command-prompt windows, but I really just want to have it so that when tabber.pl suggests a completion, it also shows the arity (and perhaps the rest of the partially-typed term) of the suggested term in light gray. I know there is already color output from the system (like when it starts up), but I don't know how to hook into output stuff to control it myself. (Obviously, I'd probably define print/1 but...)
I know I could write my own SWI-Prolog console like one guy has done with C#, but I really wanted it so people (including me) could just load the tabber module somewhere in their config file and continue to use the swipl-win window, rather than having it be a completely different executable... Would I have to use some kind of C API?
Note:
The actual implementation will likely be influenced by the answers that I get to this question, because I'm going to base my decision on the use of strings and/or atoms in this project off of them.
What I'm Asking
Is there a way or something (even if it's really low-level) I can implement to colorize output in the swipl-win window?
AFAIU the question you have to deal with is to avoid calling the fontify-function every seconds as common buffers do. I.e. call it only once when output arrived and restrict fontification to previous prompt in buffer.
I try to figure out a way of controlling a browser (preferably Firefox) via R scripts in order to retrieve information controlled by AJAX/Javascripts in Websites. For example, how could I retrieve the values in field "Modell" at http://www.mobile.de/home/index.html?
AFAIU, Gabe Becker's package "RFirefox" does provide some sort of link between R an Firefox. But being a Windows-Kid (not by conviction, but longstanding network effects ;-)), I couldn't try it myself yet so I'm not sure if it can do what I'm after.
So: is there anyone out there who does have some experience with either RFirefox or handling AJAX via R yet? Don't want you to do my homework, but before I plunge into the Linux world I'd just like to assess if it's worth it.
Nevertheless, any code examples would be greatly appreciated. ;-)
I'm not clear on why you need a browser to do this. It's just web scraping; it will require some kind of parser, certainly, but not necessarily a browser. I think that RFirefox may be barking up the wrong tree. If you want to play with Javascript+R connections, take a look at Duncan Temple Lang's SpiderMonkey.
Even so, I think it may be better to collect data with a more serious crawling/scraping facility suited for working with Javascript. This question on SO seems particularly aligned with that. My recommendation would be to get a tool that does what you need, and then interface that with R at the simplest level possible. There are bindings for Webkit to several languages, albeit this doesn't seem to be the case for R.
This question addresses your situation even more closely: it is also on Windows. It doesn't use Webkit. The three suggestions in the accepted answer refer to accessing the tools, written in C/C++, from Python. R has interfaces for both, so you may find it easier to write some stuff to work with these and pass objects and instructions back and forth between R and Python or C/C++.
What are the advantages of using Bonjour in a program (vb.net), is it even possible? Couldn't I get the same end result using just what I program?
You could probably write it yourself. But:
It would take a lot of time and effort
You would need to test it
You would need to maintain it
Using a standard tested library generally results in a cheaper and more robust solution.
http://deusty.blogspot.com/2008/03/bonjour-for-net.html
What would be the absolute fastest possible way to write a string to the standard/console output on Windows? I'm interested in the solution for both null- and non-null-terminated strings.
WriteConsole is pretty much the fastest you can get. It's still inter-process call to win32csr (on Windows 7 it's different, but it is still IPC) using LPC, so don't expect performance to be something surprising.
2nd on the WriteConsole answer, you can write the entire screen in one call;
but also 2nd on what Austin says: having ultrafast console output as a requirement for an application sounds a bit strange to me.
Anyway if it's really a bottleneck, maybe use some kind of logging system and provide actual logging to the console a seperate thread?
I am writing a simple memory game using ruby + qt (trying to get away from c++ for while...)
In order to allow a X second timeout to view two open pieces, I need either timers or do the work in a background thread.
What is the simplest way of implementing this without reinventing the wheel?
Ruby threads? Qt threads? Qt timers?
I dont know if it is the best solution but:
block=Proc.new{ Thread.pass }
timer=Qt::Timer.new(window)
invoke=Qt::BlockInvocation.new(timer, block, "invoke()")
Qt::Object.connect(timer, SIGNAL("timeout()"), invoke, SLOT("invoke()"))
timer.start(1)
Makes ruby threads work! Adjust start(x) for your needs.
The decision to choose QT threads/timers or Ruby ones is probably a personal one, but you should remember that Ruby threads are green. This means that they are implemented by the Ruby interpreter and cannot scale across multiple processor cores. Though, for a simple memory game with a timer I'm guessing you probably don't need to worry about that.
Although somewhat unrelated, Midiator, a Ruby interface to MIDI devices uses Ruby threads to implement a timer.
Also, have a look at Leslie Viljoen's article, he says that Ruby's threads lock up when QT form widgets are waiting for input. He also provides some sample code to implement QT timers (which look quite easy and appropiate for what you are doing).
Thanks.
Solved it using QTimer::singleShot.
Sufficient - in my case, fires a one time timer every time two tiles are displayed.