Also, that's just a side note, but since you're using MacRuby, I think you
should try to take advantage of the ruby syntax.
For example:
options = NSMutableDictionary.dictionaryWithObject
NSNumber.numberWithFloat(0.85), forKey:NSImageCompressionFactor
would become:
options = {NSImageCompressionFa
On Aug 11, 2010, at 3:23 PM, easco wrote:
> My concern for the feature is focused not so much on the performance impact
> of using it, as it focuses on the fact that Fibers have been added to the
> 1.9.x language. They appear to be an important part of the External
> Enumerators feature and th
Hi Kenny,
Could you try to extract the image scaling code (which seems to cause the crash
if I read well) into a smaller program and see if you still have the problem?
A backtrace would be nice, otherwise. If your app crashes you might have a
crash log in ~/Library/Logs/CrashReporter for it.
L
On Aug 11, 2010, at 3:23 PM, easco wrote:
>> Because of the way MacRuby is implemented, fibers would need to unwind the
>> stack most of the time you switch continuations, which has poor runtime
>> performance. We will eventually implement continuations which can serve to
>> implement fibers at
Also, when debugging MacRuby it is better to use the version of libmacruby in
the build directory, because the installer strips symbols during installation.
From the build directory:
DYLD_LIBRARY_PATH=. gdb --args ./macruby ...
Also, the whole project is compiled with heavy optimizations which
Hi,
Good to know you're motivated to get into hacking MacRuby :D
`rb_marshal_load` is an "API", supposed to be used by extensions for example.
If you look in `marshal.c`, you'll see that the "load" method is defined by
`marshal_load` (without the rb_ prefix):
rb_objc_define_method(*(
Because of the way MacRuby is implemented, fibers would need to unwind the stack most of the time you switch continuations, which has poor runtime performance. We will eventually implement continuations which can serve to implement fibers at some point (which is what MRI does I believe), but I woul
Hi Logan,
On Aug 11, 2010, at 2:03 PM, Logan Bowers wrote:
> That's a bummer; it sounds like Fibers will never really be useful on the
> MacRuby platform then? :(
They could definitely be useful once they are implemented. But I'm not sure
there would be a case where using them would be prefer
That's a bummer; it sounds like Fibers will never really be useful on the
MacRuby platform then? :(
Out of curiosity, is there a limiting factor in the runtime that prevents the
use of, e.g., makecontext/setcontext or related call?
Logan Bowers
On Aug 11, 2010, at 1:56 PM, Laurent Sansonett
Hi Scott,
Because of the way MacRuby is implemented, fibers would need to unwind the
stack most of the time you switch continuations, which has poor runtime
performance. We will eventually implement continuations which can serve to
implement fibers at some point (which is what MRI does I believ
Sure,
I recommend you look at http://www.stackless.com/ (a fiber-supporting
implementation of Python), and NeverBlock
(http://www.espace.com.eg/neverblock/).
Stackless Python I believe is used extensively on the EVE Online MMO runtime as
fibers/coroutines make for very natural use of the ac
Sure, here's the parts that I think is of value:
Heres how my queue is defined:
class MetadataDownloader
@@queue = Dispatch::Queue.new("se.kennylovrin.test")
class << self
def fetch(id)
downloader = new(id)
@@queue.async do
downloader.start
end
end
end
end
I use this by looping an array of
Hello,
First I want to thank everyone involved in the project for their efforts in
bringing MacRuby to us. I love being able to use GCD with ruby! I have been
on vacation for a week and finally feel like touching a computer again so I
thought I would look into doing some MacRuby development.
If it's small enough, and if you can, could you probably share the code with
us? It might help us debug de problem.
If you can't, we may need a little more than just that:
- What version of MacRuby are you running?
- Can you attach a crashlog?
The more info, the better :-)
--
Thibault Martin-La
Hey guys
I have a piece of code that runs in a background thread, and it crashes
randomly. I can't see any structure to the crashing, other than it always
seem to crash at the following line:
jpeg_data = rep.representationUsingType NSJPEGFileType, properties:options
Are there any known issues wi
The em-synchrony project wraps a bunch of EventMachine code in fibers:
http://github.com/igrigorik/em-synchrony
I know the author was looking at MacRuby and trying to figure out if fibers
worked just the other day.
dan
On 2010-08-11, at 1:19 PM, Matt Massicotte wrote:
> Could you share some
Could you share some, or maybe provide a link? I'm interested in the topic,
but unfamiliar with any specific use-cases.
Matt
On Aug 11, 2010, at 10:15 AM, Logan Bowers wrote:
> +1 for fibers. There is a class of problems made much simpler and/or possible
> with fibers that are not viable w/th
+1 for fibers. There is a class of problems made much simpler and/or possible
with fibers that are not viable w/threads.
Would love to see this make its way into MacRuby.
Sent from my iPhone
On Aug 11, 2010, at 6:06 AM, Scott Thompson wrote:
>
> On Aug 11, 2010, at 7:23 AM, Louis-Philippe
On Aug 11, 2010, at 7:23 AM, Louis-Philippe wrote:
> Hi Scott,
>
> If you haven't done so already, you might want to have a look at:
> http://www.macruby.org/documentation/gcd.html
>
> it speaks of MacRuby integrating Apple's latest multi-threading strategy:
> Grand Central Dispatch.
Grand Ce
Hi Scott,
On Aug 11, 2010, at 5:23 AM, Louis-Philippe wrote:
> Hi Scott,
>
> If you haven't done so already, you might want to have a look at:
> http://www.macruby.org/documentation/gcd.html
>
> it speaks of MacRuby integrating Apple's latest multi-threading strategy:
> Grand Central Dispatch.
Hi Scott,
If you haven't done so already, you might want to have a look at:
http://www.macruby.org/documentation/gcd.html
it speaks of MacRuby integrating Apple's latest multi-threading strategy:
Grand Central Dispatch.
2010/8/10 Scott Thompson
> I recently had a discussion on a separate list
21 matches
Mail list logo
