> Is trunk ready for primetime? I noticed some problem reports with 0.9 in the
> mailing list lately and wasn't sure if that was a good idea.
For that I can't really answer, as I'm don't have any real application
using MacRuby. Other people on the mailing list can probably answer
that though.
How
Is trunk ready for primetime? I noticed some problem reports with 0.9 in the
mailing list lately
and wasn't sure if that was a good idea. And i haven't tested at all with 0.8
or 0.9. But I guess
you guys are primarily fixing things for the 1.0 release and only changing
things that are necessary
> Another question, my project is currently using the default 0.7 MacRuby
> framework included in XCode. I assume
> that I should include this fix in the latest 0.7 or 0.8 build and run all of
> the test suites to verify that I didn't
> break anything in the build process?
It looks like this part
Hi Morgan:
Thanks for all your help with the sort algorithm. It occurred to me that in my
app I could sort my elements as I create them in my NSXMLParser delegate
methods such that I wouldn't need to use a sort algorithm. I now have:
def add_child( child )
change
Thanks for the rapid response to this problem. I will verify that it works with
my project as
soon as I can get MacRuby built. I also ran into some other strangeness in
32-bit mode but this may fix
those issues as well. I will give an update soon.
Another question, my project is currently using
Wow, now that's service! :-) Thanks, Vincent!
- Jordan
On Jan 31, 2011, at 3:22 PM, Vincent Isambart wrote:
> Sorry, I'm not patient so I filed the ticket:
> http://www.macruby.org/trac/ticket/1143
> And fixed it in r5215 :D
> http://www.macruby.org/trac/changeset/5215/
>
> On Feb 1, 2011, at
Sorry, I'm not patient so I filed the ticket:
http://www.macruby.org/trac/ticket/1143
And fixed it in r5215 :D
http://www.macruby.org/trac/changeset/5215/
On Feb 1, 2011, at 8:07 AM, Laurent Sansonetti wrote:
> Like Jordan said :)
>
> Please file a ticket and we will get this fixed in 0.9. Bugs
Like Jordan said :)
Please file a ticket and we will get this fixed in 0.9. Bugs breaking
applications are considered as a priority.
I think 0.9 should remain 32/64 bits, but the release after may drop 32-bit
support (unless people really need it). I can add a note in the 0.9 release
notes and
Greetings,
Sorry; I neglected that aspect of your code.
If, instead of '@children = ...' you were to go:
def sort_children2
new_children = @children.sort_by.with_index { |*args| args}
set_modified if @children != new_children
@children = new_children
end
It adds an extra 'n' in doing the c
Greetings,
On Mon, Jan 31, 2011 at 11:00 AM, Charles Oliver Nutter wrote:
> FWIW, JRuby originally had a stable Array#sort, but because it was
> slower than MRI's unstable sort (and we got bug reports to that
> effect) we replaced it with an unstable hybrid sort based on
> quicksort. Shortly aft
Fair enough, I did not realize that you'd already deployed an app based on
MacRuby and had already received bug reports (which suggests that the number of
32 bit users is clearly non-zero, at least!). Have you filed a ticket in trac
with a reduction (e.g. the minimum code necessary to demonstra
On Sun, Jan 30, 2011 at 6:19 PM, Morgan Schweers wrote:
> Greetings,
> Ruby's sort algorithm is quicksort, last I checked, and quicksort is not
> stable (which is the property you're looking for in a sort). There are a
> bunch of ways around this, including writing your own, but one cute, quick,
Hi Morgan:
Thanks again.
I understand the concept now of adding a secondary sort key but I was
unfamiliar with the .with_index enumerator method.
My app is usually sorting a small array of XML elements that will already be
sorted but I need to know if the sequence has changed to update the fil
Forget my previous mail, I found a better workaround: in objc.m replace:
VALUE arg = DBL2NUM(time + CF_REFERENCE_DATE);
by
VALUE arg = LONG2NUM(time + CF_REFERENCE_DATE);
With this, you will lose sub-second precision but it will still be
better than what you have currently.
I can add microseconds p
Hi,
> That makes perfectly good sense but i unfortunately started selling a MacRuby
> app on the App Store
> for i386 and 64 bit machines. And a few people are experiencing this issue. I
> was just hoping
> for a quick workaround to make them happy. And I would discontinue selling
> the 32 bit
That makes perfectly good sense but i unfortunately started selling a MacRuby
app on the App Store
for i386 and 64 bit machines. And a few people are experiencing this issue. I
was just hoping
for a quick workaround to make them happy. And I would discontinue selling the
32 bit version
on the n
Greetings,
The long example didn't work quite right. You can see it here:
https://gist.github.com/803842
-- Morgan
On Mon, Jan 31, 2011 at 1:55 AM, Morgan Schweers wrote:
> Greetings,
> Ouch. That's...probably painfully expensive for large @children arrays.
> Trying to understand, it looks
Greetings,
Ouch. That's...probably painfully expensive for large @children arrays.
Trying to understand, it looks like you're sorting on child.sequence, and
keeping each child with the same sequence in the same order as they are
initially in the @children array?
You could try something like this
18 matches
Mail list logo
