Have a small example pasted down which launches a system tray icon using gtk2 gem.
#!/usr/bin/env ruby
# encoding: UTF-8
require 'gtk2'
si=Gtk::StatusIcon.new
si.stock=Gtk::Stock::DIALOG_INFO
si.tooltip='StatusIcon'
si.signal_connect('activate'){|icon| icon.blinking=!(icon.blinking?)}
info=Gtk::ImageMenuItem.new(Gtk::Stock::INFO)
info.signal_connect('activate'){p "Embedded: #{si.embedded?}"; p "Visible: #{si.visible?}"; p "Blinking: #{si.blinking?}"}
quit=Gtk::ImageMenuItem.new(Gtk::Stock::QUIT)
quit.signal_connect('activate'){Gtk.main_quit}
menu=Gtk::Menu.new
menu.append(info)
menu.append(Gtk::SeparatorMenuItem.new)
menu.append(quit)
menu.show_all
si.signal_connect('popup-menu'){|tray, button, time| menu.popup(nil, nil, button, time)}
si.signal_connect('scroll-event'){|icon, event|
modifier=event.state#A GdkModifierType indicating the state of modifier keys and mouse buttons
##Handle only control and shift key
ctrl_shift=(Gdk::Window::CONTROL_MASK|Gdk::Window::SHIFT_MASK)
mod=modifier&ctrl_shift
case mod
when 0
print "(None)"
when Gdk::Window::CONTROL_MASK
print "Control+"
when Gdk::Window::SHIFT_MASK
print "Shift+"
when (Gdk::Window::CONTROL_MASK|Gdk::Window::SHIFT_MASK)
print "Control+Shift+"
end
##Check for direction
case event.direction
when Gdk::EventScroll::UP
print "up\n"
when Gdk::EventScroll::DOWN
print "down\n"
end
}
exit if defined?(Ocra)
Gtk.main
This works in a second if I run it as a ruby script i.e., ruby my_program.rb
But I would like to distribute it so I chose OCRA which builds me a exe file so that the user can run it without ruby or its packages installed.
So I run ocra my_program.rb --windows and it gives me a nice exe file called my_program.exe.
Problem : When I launch my_program.exe it takes 25 to 30 seconds to load the program.
The system tray icon takes 1 second and takes 30 times more to launch when packaged as a exe file.
Is there any possible way to decrease this load time. Thank you very much in advance.
EDIT: After a heads up I changed the ocra exe creation to ocra my_program.rb --windows --no-lzma. This solution saved me 10 seconds and now it is taking around 18-20 seconds for the program to load.
Can I optimize it more for a shorter load time? Please help.
Please see discussion on related topic here:
http://programming.nullanswer.com/question/28323543
It might be helpful.
Related
Here is the case;
There is this app called "termux" on android which allows me to use a terminal on android, and one of the addons are androids API's like sensors, tts engines, etc.
I wanted to make a script in ruby using this app, specifically this api, but there is a catch:
The script:
require('json')
JSON.parse(%x'termux-sensor -s "BMI160 Gyro" -n 1')
-s = Name or partially the name of the sensor
-n = Count of times the command will run
returns me:
{
"BMI160 Gyroscope" => {
"values" => [
-0.03...,
0.00...,
1.54...
]
}
}
I didn't copied and pasted the values, but that's not the point, the point is that this command takes almost a full second the load, but there is a way to "make it faster"
If I use the argument "-d" and not use "-n", I can specify the time in milliseconds to delay between data being sent in STDOUT, it also takes a full second to load, but when it loads, the delay works like charm
And since I didn't specify a 'n' number of times, it never stops, and there is the problem
How can I retrieve the data continuously in ruby??
I thought about using another thread so it won't stop my program, but how can I tell ruby to return the last X lines of the STDOUT from a command that hasn't and will not ever stop since "%x'command'" in ruby waits for a return?
If I understood you need to connect to stdout from a long running process.
see if this works for your scenario using IO.popen:
# by running this program
# and open another terminal
# and start writing some data into data.txt
# you will see it appearing in this program output
# $ date >> data.txt
io_obj = IO.popen('tail -f ./data.txt')
while !io_obj.eof?
puts io_obj.readline
end
I found out a built in module that saved me called PTY and the spawn#method plus thread management helped me to keep a variable updated with the command values each time the command outputted new bytes
I'm pretty new to cucumber automated testing. When I first started, a co-worker had set up everything for me on my computer, and (now that he's gone) I've run into a problem that I can't seem to figure out.
I'm using cucumber to test a web application. In the past when I run the script, an internet explorer pops up, and I can see each line of the script being executed.
I recently had to reinstall cucumber, ruby, watir, etc., and that internet explorer screen no longer pops up.
I installed Ruby 1.9.3, cucumber (gem install cucumber), watir (gem install watir). Am I missing something? Is it an extra plug in? The script still runs. However, instead of taking say 1 min + to run a 320 step script, it now takes 1.5 seconds. There are no error messages. When run from the command window, it literally looked like it just scrolled through the script instead of going through each step.
What is the pop up screen called anyways? A scenario screen? Output screen?
It was really difficult for me to look it up on google because I had no idea how to refer to that screen.
Any help is appreciated. and I realize I might not have described the problem well enough. Just leave a comment, and I can try to clarify it more.
Feature:
'To go to a webpage'
Scenario:
# ----------
# GO TO PAGE
# ----------
Given that I have gone to the Login page at "url"
#
# ----------
# LOG IN
# ----------
When I add "username" to the Username
When I add "password" to the Password
And click the Login button
Then "Welcome" should be mentioned on the page
script definitions:
require "rubygems"
require "watir"
puts "Browser is running..."
END {
puts "Closing browser..."
}
BEGIN {
puts "Starting browser..."
}
Given /^that I have gone to the Login page at "(.*)"$/ do |item|
#browser = Watir::IE.start(item)
lnk_found = 0
#browser.links.each do |lnk|
if lnk.id.to_s.matches("overridelink")
lnk_found += 1
end
end
if lnk_found > 0
#browser.link(:id, "overridelink").click
end
# puts "Watir Version: #{Watir::IE::VERSION}"
#browser.maximize
end
#
#
#
When /^I add "(.*)" to the Username$/ do |item|
#browser.text_field(:name, "loginName").set(item)
end
#
#
When /^I add "(.*)" to the Password$/ do |item|
#browser.text_field(:name, "passwd").set(item)
end
#
#
#
Then /^"(.*)" should be mentioned on the page$/ do |item|
if #browser.text.include?(item)
# puts "TEST PASSED. FOUND >#{item}<"
else
puts "*** TEST FAILED ***. >#{item}< was not found."
end
end
Directory Structure
Cucumber
Testing
lib
login.rb
login.feature
I don't know what exactly fixed it but after taking suggestions and advices from different people I basically uninstalled and reinstalled watir several times.
I also updated the code, took out "require 'rubygems'" and replaced Watir::IE.start with Watir::Browser.start.
It seems like the problem was the existing scripts I worked with was based off of older versions of watir/cucumber/ruby, so when I had to reinstall everything, the scripts were no longer compatible with newer versions of everything.
The ruby debugger does not halt on breakpoints I set in files different from the on the execution starts in. For example, consider these two files, foo.rb:
# foo.rb
class Foo
def bar
puts "baz"
end
end
and main.rb:
# main.rb
require './foo'
Foo.new.bar
I start debugging using ruby -r debug .\main.rb. Now, when I try to set a breakpoint on a specific line in another file using b ./foo.rb:4, I get the message Set breakpoint 1 at foo.rb:4, but when I cont, the program executes to the end, and the debugger never halts. However, if I break on a line in main.rb, e.g. b ./main.rb:3, or a method, e.g. b Foo.bar, the debugger halts as expected.
Why doesn't the debugger halt at breakpoints in files other than the main file?
Update: I have tried this with Ruby 1.9.3 on Windows 7 as well as OS X 10.8; it doesn't work in either environment.
I have also just realized that the debugger quits after the script has run till the end: I start debugging main.rb, use cont, then baz is printed on the console and I'm right back in the shell. Is this the expected behaviour, or might the debugger have crashed?
Wow, that is weird. Not sure if this helps, but maybe you could do this. Step over the require with next so that Foo is loaded then
b Foo:bar
that should at least break on bar
I was playing with some ruby the other day and I wrote the following code
File.open(my_file, "w+") do | fh |
begin
fh.readonly = true <--------Exception thrown here
ensure
fh.close
end
end
this does not work as it throws EACCES because the file is readonly, if I change the open flag to "r" this works just fine. To me this is counter intuitive because I thought opening it with "r" meant i'd only be able to read the file, not change attributes.
I am using win32-file (0.6.6) with ruby 1.8.7 (not upgradable for current project), is this normal behaviour a quirk of the win-32 file gem or just a bug that I am able to code around.
In order to set the readonly bit to true I must open with w+ which seems much more sensible
A bit more info is that this test was performed on Windows Server 2003 64-bit, just in case that makes a diff.
Try opening the file with read and write permissions.
File.open(my_file, "rw+") do | fh |
begin
fh.readonly = true
ensure
fh.close
end
end
I eventually found out what this was, there was another process locking the directory with an exclusive lock on the filesystem, It didn't show up with processexplorer but i noticed in my log something logging that directory, I stopped the service and bam it worked.
Can I replace an executable (accessed via a system call from ruby) with an executable that expects certain input and supplies the expected output in a consistent amount of time? I'm mainly operating on Mac OSX 10.6 (Snow Leopard), but I also have access to Linux and Windows. I'm using MRI ruby 1.8.7.
Background: I'm looking at doing several DNA sequence alignments, one in each thread. When I try using BioRuby for this, either BioRuby or ruby's standard library's tempfile sometimes raise exceptions (which is better than failing silently!).
I set up a test that reproduces the problem, but only some of the time. I assume the main sources of variability between tests are the threading, the tempfile system, and the executable used for alignment (ClustalW). Since ClustalW probably isn't malfunctioning, but can be a source of variability, I'm thinking that eliminating it may aid reproducibility.
For those thinking select isn't broken - that's what I'm wondering too. However, according to the changelog, there was concern about tempfile's thread safety in August 2009. Also, I've checked on the BioRuby mailing list whether I'm calling the BioRuby code correctly, and that seems to be the case.
I really don't understand what the problem is or what exactly are you after, can't you just write something like
#!/bin/sh
#Test for input (syntax might be wrong, but you get the idea)
if [ $* ne "expected input" ]; then
echo "expected output for failure"
exit -1
fi
#have it work in a consistent amount of time
$CONSISTENT_AMOUNT_OF_TIME = 20
sleep $CONSISTENT_AMOUNT_OF_TIME
echo "expected output"
You can. In cases where I'm writing a functional test for program A, I may need to "mock" a program, B, that A runs via system. What I do then is to make program B's pathname configurable, with a default:
class ProgramA
def initialize(argv)
#args = ParseArgs(argv)
#config = Config.new(#args.config_path || default_config_path)
end
def run
command = [
program_b_path,
'--verbose',
'--do_something_wonderful',
].join(' ')
system(command)
...
end
def program_a_path
#config.fetch('program_b_path', default_program_b_path)
end
end
Program A takes a switch, "--config PATH", which can override the default config file path. The test sets up a configuration file in /tmp:
program_b_path: /home/wayne/project/tests/mock_program_b.rb
And passes to program A that configuration file:
program_a.rb --config /tmp/config.yaml
Now program A will run not the real program B, but the mock one.
Have you tried the Mocha gem? It's used a lot for testing, and you describe it perfectly. It "fakes" the method call of an object (which includes just about anything in ruby), and returns the result you want without actually running the method. Take this example file:
# test.rb
require 'rubygems'
require 'mocha'
self.stubs(:system).with('ls').returns('monkey')
puts system('ls')
Running this script outputs "monkey" because I stubbed out the system call. You can use this to bypass parts of an application you don't want test, to factor out irrelevant parts.