Hi,
Now that I have the initial port of obs api to rails 3 finished, I
consider staying forever on rails2 :)
I have this little benchmark that I initially wrote to check if it's
worth talking to the API in json instead of the usual XML:
prjs = DbProject.find :all
x = Benchmark.realtime { prjs.each { |p| p.expand_flags.to_json } }
y = Benchmark.realtime { prjs.each { |p| p.to_axml('flagdetails') }
puts "#{x} #{y}"
And indeed with rails 2.3.14, it shows json is good:
0.108472093 0.379935258
But now with rails 3.2.1 both are slower ;(
0.515888469 1.334631859
Both are with ruby 1.9.3
Greetings, Stephan
--
To unsubscribe, e-mail: opensuse-ruby+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-ruby+owner(a)opensuse.org
Hi,
I'm evaluating porting OBS to rails 3 and while there are
tons of annoying problems, that are ugly to fix but are "just work", I
have a real problem with the now deprecated find functions.
Let's take an example:
attribs.find(:first, :joins => "LEFT OUTER JOIN attrib_types at ON
attribs.attrib_type_id = at.id LEFT OUTER JOIN attrib_namespaces an ON
at.attrib_namespace_id = an.id", :conditions => ["at.name = BINARY ? and
an.name = BINARY ? and attribs.binary = BINARY ?", name, namespace, binary])
That's find_attribute and worked ok in rails 2.3 - it's a pretty huge
join and a rather useless big result, but ok.
Now with rails 3, find(:first) is not only deprecated but also joins
set the result to readonly, so I can't do an update to Attrib.
What I did (after a lot of trial and error and googling around was):
a = attribs.joins(:attrib_type =>
:attrib_namespace).where("attrib_types.name = BINARY ? and
attrib_namespaces.name = BINARY ? and ISNULL(attribs.binary)", name,
namespace).first
a = attribs.where(:id => a.id).first if a && a.readonly?
I found the existing documentating I could find rather unpleasant, they
always only cover simple cases or examples I don't understand ;(
Does anyone have a recommendation for such "at the limits" cases?
Greetings, Stephan
--
To unsubscribe, e-mail: opensuse-ruby+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-ruby+owner(a)opensuse.org
Hi all,
Anyone planning to attend http://reddotrubyconf.com/ ?
Cheers,
James T.
--
To unsubscribe, e-mail: opensuse-ruby+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-ruby+owner(a)opensuse.org
Hi all,
just a short remider that the next rug-n meeting (Ruby User Group Nuremberg)
will be next Wednesday on March 21st at 18:30 in the all-hands-area here at
SUSE.
The meeting will be open to external people, too. So if you know some ruby
developers, bring them along.
Planned topics:
- testsuite optimization
- code review using git-review
If you're planning to attend our meeting, there is a doodle survey waiting
for your vote, whether you'd like to get some pizza or not.
Hope to see you there,
Dominik
http://rug-n.de
PS: It's still not quite sure in which language the talks will be held.
Depending on the attendants we will decide that ad hoc.
--
To unsubscribe, e-mail: opensuse-ruby+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-ruby+owner(a)opensuse.org
Hi,
As I have a high interest in getting ruby 1.9 (as default ruby) into
factory to replace the soon out of maintenance 1.8, darix invited me
to work out a plan how to have gems build for 1.8 and 1.9.
So I renamed ruby to ruby18 and added a ruby package that defines
the default ruby. With this I rebuilt all gems that I have installed
on my workstation as 1.9 version.
But that doesn't solve the 1.8 backward problem - and while it doesn't
sound _soo_ important, I already found the lack of a way to test the 1.8
stack in comparision when porting quite bothering :)
So I changed the gem2rpm template to output always two ruby versions.
ruby18-gem-gettext and ruby19-gem-gettext. This _kind_ of works, but
both these gems install stuff in %_bindir and they conflict (other files
are in ruby version specific dirs).
I see several options:
1. Most of the executables are just wrappers for the real stuff
happening in ruby modules, so just package the executables for the
default ruby version.
2. add a suffix to the non-default ruby versions
3. add a suffix to all executables and provide update-alternative hooks
all around
4. even more complex stuff :)
The mid term goal is to have it clear from the binary rpm name which
ruby version it is for - ruby 1.8 will be around for a while.
If you want to see my state, check http://s.kulow.org/4
Greetings, Stephan
--
To unsubscribe, e-mail: opensuse-ruby+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-ruby+owner(a)opensuse.org
