date:20091204

[MacRuby-devel] Xcode and Interface Builder: action and outlets not showing up

2009-12-04 Thread Robinson, John MD PhD


Hi all,

I am new to the list.

While working through Geoffrey Grosenbach's tutorial on peepcode, I  
began to experience the following problems in IB. I lost autocomplete  
in the class identity textbox and the outlets/actions of the class  
were not avaiable. Conclusion: IB isn't recognizing my classes. This  
seems to have started after loading the iphone sdk, which upgraded  
Xcode from 3.1 -> 3.2.


Thanks,

~JR





___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] Xcode and Interface Builder: action and outlets not showing up

2009-12-04 Thread John Shea

Yes, as you have probably realised you need to reinstall MacRuby.
In my case it did not affect my iphone SDK after reinstalling MacRuby.

J

On Dec 4, 2009, at 13:00 , Robinson, John MD PhD wrote:

> Hi all,
> 
> I am new to the list.
> 
> While working through Geoffrey Grosenbach's tutorial on peepcode, I began to 
> experience the following problems in IB. I lost autocomplete in the class 
> identity textbox and the outlets/actions of the class were not avaiable. 
> Conclusion: IB isn't recognizing my classes. This seems to have started after 
> loading the iphone sdk, which upgraded Xcode from 3.1 -> 3.2.
> 
> Thanks,
> 
> ~JR
> 
> 
> 
> 
> 
> ___
> MacRuby-devel mailing list
> [email protected]
> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] Xcode and Interface Builder: action and outlets not showing up

2009-12-04 Thread Robinson, John MD PhD


Works!

 Thanks,
~JR








On Dec 4, 2009, at 6:28 AM, John Shea wrote:


Yes, as you have probably realised you need to reinstall MacRuby.
In my case it did not affect my iphone SDK after reinstalling MacRuby.

J

On Dec 4, 2009, at 13:00 , Robinson, John MD PhD wrote:


Hi all,

I am new to the list.

While working through Geoffrey Grosenbach's tutorial on peepcode, I  
began to experience the following problems in IB. I lost  
autocomplete in the class identity textbox and the outlets/actions  
of the class were not avaiable. Conclusion: IB isn't recognizing my  
classes. This seems to have started after loading the iphone sdk,  
which upgraded Xcode from 3.1 -> 3.2.


Thanks,

~JR





___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel


___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel



___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] [MacRuby] #477: Need GCD wrapper for dispatch_once

2009-12-04 Thread MacRuby

#477: Need GCD wrapper for dispatch_once
+---
 Reporter:  ernest.prabha...@…  |   Owner:  lsansone...@…
 Type:  defect  |  Status:  new  
 Priority:  minor   |   Milestone:  MacRuby 0.5  
Component:  MacRuby |Keywords:   
+---

Comment(by joshua.balla...@…):

 What about using dispatch once as a method decorator like "private".
 Something like:

 {{{
 class Foo
   def initialize(db_file)
 @db_file = db_file
   end

   def connect
 DB.connect(@db_file)
   end
   dispatch_once :connect

   ...

 end
 }}}

-- 
Ticket URL: 
MacRuby 

___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] [MacRuby] #477: Need GCD wrapper for dispatch_once

2009-12-04 Thread MacRuby

#477: Need GCD wrapper for dispatch_once
+---
 Reporter:  ernest.prabha...@…  |   Owner:  lsansone...@…
 Type:  enhancement |  Status:  new  
 Priority:  minor   |   Milestone:  MacRuby 0.5  
Component:  MacRuby |Keywords:   
+---
Changes (by joshua.balla...@…):

  * type:  defect => enhancement


-- 
Ticket URL: 
MacRuby 

___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] [MacRuby] #477: Need GCD wrapper for dispatch_once

2009-12-04 Thread MacRuby

#477: Need GCD wrapper for dispatch_once
+---
 Reporter:  ernest.prabha...@…  |   Owner:  lsansone...@…
 Type:  enhancement |  Status:  new  
 Priority:  minor   |   Milestone:  MacRuby 0.5  
Component:  MacRuby |Keywords:   
+---

Comment(by ernest.prabha...@…):

 Ooh, I like it.  I wonder if that would allows us to also create an
 instance variable to use as the predicate.

-- 
Ticket URL: 
MacRuby 

___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] [MacRuby] #476: GCD Groups should be a wrapper around dispatch, not its own invocation style

2009-12-04 Thread MacRuby

#476: GCD Groups should be a wrapper around dispatch, not its own invocation
style
+---
 Reporter:  ernest.prabha...@…  |   Owner:  lsansone...@…
 Type:  enhancement |  Status:  new  
 Priority:  blocker |   Milestone:  MacRuby 0.5  
Component:  MacRuby |Keywords:  gcd  
+---

Comment(by joshua.balla...@…):

 Ideally, I'd prefer a change such that the programmer doesn't need to
 worry about the difference between a dispatch group and a dispatch queue.
 There would be only one "Dispatch" class with methods "sync", "async",
 "apply", etc. Dispatch.sync would take a name parameter (a symbol?), and
 subsequent calls to Dispatch.sync with the same parameter would dispatch
 to the same queue. Dispatch.async would just take an optional priority
 parameter. Dispatch.apply would iterate over a collection. All would
 return a group which could be optionally captured for later calls to wait,
 and would accept an optional group argument to add a block to a pre-
 existing group. So, for example:

 {{{

 notifications = Dispatch.async do
   send_start_notification
 end

 url_fetching = Dispatch.apply(LIST_OF_URLS) do |url|
   connection = open(url)
   Dispatch.sync(:disk_dispatch) do
 File.open(URL_FILE) { |f| f << connection.read }
   end
 end

 url_fetching.wait
 Dispatch.async(:group => notifications) do
   send_finish_notification
 end

 do_other_work

 notifications.wait
 exit
 }}}

-- 
Ticket URL: 
MacRuby 

___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] [MacRuby] #476: GCD Groups should be a wrapper around dispatch, not its own invocation style

2009-12-04 Thread MacRuby

#476: GCD Groups should be a wrapper around dispatch, not its own invocation
style
+---
 Reporter:  ernest.prabha...@…  |   Owner:  lsansone...@…
 Type:  enhancement |  Status:  new  
 Priority:  blocker |   Milestone:  MacRuby 0.5  
Component:  MacRuby |Keywords:  gcd  
+---

Comment(by ernest.prabha...@…):

 I'm not sure I'd want to go that far, but I like the idea of passing
 groups -- and even sync -- as named parameters to dispatch (i.e., a hash)

 g = Dispatch::Group.new

 q1.dispatch(group: g) { block }
 q2.dispatch(group: g, sync:true) { block }

 g.wait

 That would seem both the simplest to implement, and the clearest
 semantically.  I'll file a bug about the 'sync' keyword...

-- 
Ticket URL: 
MacRuby 

___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

[MacRuby-devel] [MacRuby] #482: Dispatch::Queue#dispatch should take a hash instead of a bool

2009-12-04 Thread MacRuby

#482: Dispatch::Queue#dispatch should take a hash instead of a bool
+---
 Reporter:  ernest.prabha...@…  |   Owner:  lsansone...@…
 Type:  enhancement |  Status:  new  
 Priority:  blocker |   Milestone:  MacRuby 0.5  
Component:  MacRuby |Keywords:   
+---
 I like the way MacRuby unifies GCD's 'sync' and 'async' call into a single
 "dispatch" method.  However, I always need to remind myself which way is
 'true' and which is 'false'.  In addition, it may create ordering issues
 when we add other parameters.

 I think it would be better if dispatch just took an explicit hash; then we
 could say:

 q.dispatch(sync:true)

 which is much easier to figure out.  This would also simplify groups:

 q.dispatch(sync:true, group: g)

-- 
Ticket URL: 
MacRuby 

___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] [MacRuby] #479: Need GCD wrapper for Process Sources

2009-12-04 Thread MacRuby

#479: Need GCD wrapper for Process Sources
+---
 Reporter:  ernest.prabha...@…  |   Owner:  lsansone...@…
 Type:  defect  |  Status:  new  
 Priority:  blocker |   Milestone:  MacRuby 0.5  
Component:  MacRuby |Keywords:   
+---

Comment(by ernest.prabha...@…):

 Replying to [comment:1 ernest.prabha...@…]:
 > I was being overly elaborate.  The API should just take a PID not a
 Process::Status.  Gotta get away from thinking in terms of static types...

 So, the revised proposal is for something like:

 process_mask = Dispatch::Source::ProcessEvent.new(:exit,  :exec, :reap,
 :signal)
 process_mask.exit = false

 proc_src = Dispatch::Source.for_process(queue, pid, process_mask) do
 |event|
   if event.exec then "Do something"
 end

-- 
Ticket URL: 
MacRuby 

___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

[MacRuby-devel] [MacRuby] #483: Need GCD wrapper for File (Vnode) Sources

2009-12-04 Thread MacRuby

#483: Need GCD wrapper for File (Vnode) Sources
+---
 Reporter:  ernest.prabha...@…  |   Owner:  lsansone...@…
 Type:  enhancement |  Status:  new  
 Priority:  blocker |   Milestone:  MacRuby 0.5  
Component:  MacRuby |Keywords:   
+---
 We should wrap DISPATCH_SOURCE_TYPE_VNODE

 
http://developer.apple.com/mac/library/documentation/Darwin/Reference/ManPages/man3/dispatch_source_create.3.html

 file_source = Dispatch::Source.for_file(queue, io, mask, &block)

 As with PROC, the key is coming up with the right "bitfield" class to
 represent the event types:

o DISPATCH_VNODE_DELETE  The referenced node was removed from
 the filesystem namespace via unlink(2).

o DISPATCH_VNODE_WRITE   A write to the referenced file
 occurred

o DISPATCH_VNODE_EXTEND  The referenced file was extended

o DISPATCH_VNODE_ATTRIB  The metadata attributes of the
 referenced node have changed

o DISPATCH_VNODE_LINKThe link count on the referenced node
 has changed

o DISPATCH_VNODE_RENAME  The referenced node was renamed

o DISPATCH_VNODE_REVOKE  Access to the referenced node was
 revoked via revoke(2) or the underlying fileystem was unmounted.

 e.g.,: Dispatch::Source::FileEvent.new(:delete, :write, :extend, :attrib,
 :link, :rename, :revoke)

-- 
Ticket URL: 
MacRuby 

___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

[MacRuby-devel] Accessing memory address in MacRuby

2009-12-04 Thread Yehuda Katz

I'm currently working with an API that sends me a memory address for an int
and expects me to populate it with a value:

It essentially looks like this:

int retValue = 1;
[historyController.repository outputForArguments:[NSArray
arrayWithObjects:@"update-ref",
@"-mUpdate from GitX", [ref ref], [dropCommit realSha], NULL]
retValue:&retValue];
if (retValue) return NO;

I am writing code that implements outputForArguments:retValue:, but it seems
that MacRuby hands me an opaque primitive that I can't use. When I try to do
anything with it, I get EXC_BAD_ACCESS.

Any ideas?

Yehuda Katz
Developer | Engine Yard
(ph) 718.877.1325
___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

[MacRuby-devel] [MacRuby] #484: scoping issues with notification center

2009-12-04 Thread MacRuby

#484: scoping issues with notification center
-+--
 Reporter:  mattaimone...@…  |   Owner:  lsansone...@…
 Type:  defect   |  Status:  new  
 Priority:  blocker  |   Milestone:  MacRuby 0.5  
Component:  MacRuby  |Keywords:   
-+--
 Here is a reduction of a bug I encountered today:

 {{{
 framework 'Cocoa'

 class Foo

   def dataReady(notification)
 puts "called ok"
 NSApplication.sharedApplication.terminate(nil)
   end
 end

 nc = NSNotificationCenter.defaultCenter

 # foo = nil

 Proc.new do

   foo = Foo.new
   task = NSTask.alloc.init
   pi = NSPipe.alloc.init
   po = NSPipe.alloc.init

   task.arguments = []
   task.currentDirectoryPath = "/bin/"
   task.launchPath = "/bin/ls"
   task.standardInput  = pi
   task.standardOutput = po
   task.launch

   file_handle = po.fileHandleForReading
   file_handle.readInBackgroundAndNotify

   nc.addObserver(foo, selector: "dataReady:", name:
 NSFileHandleReadCompletionNotification, object: file_handle)

 end.call

 app = NSApplication.sharedApplication
 app.delegate = self
 app.run
 }}}

 If you run the code as is, the observer never gets called, however if you
 uncomment the line defining foo before the block everything works fine.

 It looks like foo isn't available when the notification center tries to
 call it to send it the notification.

-- 
Ticket URL: 
MacRuby 

___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] [MacRuby] #484: scoping issues with notification center

2009-12-04 Thread MacRuby

#484: scoping issues with notification center
-+--
 Reporter:  mattaimone...@…  |Owner:  lsansone...@…
 Type:  defect   |   Status:  closed   
 Priority:  blocker  |Milestone:   
Component:  MacRuby  |   Resolution:  invalid  
 Keywords:   |  
-+--
Changes (by lsansone...@…):

  * status:  new => closed
  * resolution:  => invalid
  * milestone:  MacRuby 0.5 =>


Old description:

> Here is a reduction of a bug I encountered today:
>
> {{{
> framework 'Cocoa'
>
> class Foo
>
>   def dataReady(notification)
> puts "called ok"
> NSApplication.sharedApplication.terminate(nil)
>   end
> end
>
> nc = NSNotificationCenter.defaultCenter
>
> # foo = nil
>
> Proc.new do
>
>   foo = Foo.new
>   task = NSTask.alloc.init
>   pi = NSPipe.alloc.init
>   po = NSPipe.alloc.init
>
>   task.arguments = []
>   task.currentDirectoryPath = "/bin/"
>   task.launchPath = "/bin/ls"
>   task.standardInput  = pi
>   task.standardOutput = po
>   task.launch
>
>   file_handle = po.fileHandleForReading
>   file_handle.readInBackgroundAndNotify
>
>   nc.addObserver(foo, selector: "dataReady:", name:
> NSFileHandleReadCompletionNotification, object: file_handle)
>
> end.call
>
> app = NSApplication.sharedApplication
> app.delegate = self
> app.run
> }}}
>
> If you run the code as is, the observer never gets called, however if you
> uncomment the line defining foo before the block everything works fine.
>
> It looks like foo isn't available when the notification center tries to
> call it to send it the notification.

New description:

 Here is a reduction of a bug I encountered today:

 {{{
 framework 'Cocoa'

 class Foo

   def dataReady(notification)
 puts "called ok"
 NSApplication.sharedApplication.terminate(nil)
   end
 end

 nc = NSNotificationCenter.defaultCenter

 # foo = nil

 Proc.new do

   foo = Foo.new
   task = NSTask.alloc.init
   pi = NSPipe.alloc.init
   po = NSPipe.alloc.init

   task.arguments = []
   task.currentDirectoryPath = "/bin/"
   task.launchPath = "/bin/ls"
   task.standardInput  = pi
   task.standardOutput = po
   task.launch

   file_handle = po.fileHandleForReading
   file_handle.readInBackgroundAndNotify

   nc.addObserver(foo, selector: "dataReady:", name:
 NSFileHandleReadCompletionNotification, object: file_handle)

 end.call

 app = NSApplication.sharedApplication
 app.delegate = self
 app.run
 }}}

 If you run the code as is, the observer never gets called, however if you
 uncomment the line defining foo before the block everything works fine.

 It looks like foo isn't available when the notification center tries to
 call it to send it the notification.

--

Comment:

 NSNotificationCenter doesn't retain the observer. In your example, foo is
 garbage collected before the notification. You must keep a live reference
 to foo.

 This is a common Cocoa pattern. Observers, delegates & friends are always
 weakly referenced.

-- 
Ticket URL: 
MacRuby 

___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] hotcocoa/graphics

2009-12-04 Thread Laurent Sansonetti


Hi Juergen,

Currently MacRuby trunk doesn't run HotCocoa at 100%. We intend to  
fully support it in the next (and hopefully last) beta release.


Laurent

On Dec 3, 2009, at 8:10 AM, Juergen Dabel wrote:


Today I tried with the newest nightly build and I got:

dab:~ jdabel$ cd /Developer/Examples/Ruby/MacRuby/HotCocoa/graphics
dab:graphics jdabel$ macruby particle.rb
Segmentation fault
dab:graphics jdabel$ macruby demo.rb
2009-12-03 17:03:51.063 macruby[153:903] *** -[NSLock unlock]: lock  
( '(null)') unlocked when not locked
2009-12-03 17:03:51.065 macruby[153:903] *** Break on _NSLockError()  
to debug.
/Library/Frameworks/MacRuby.framework/Versions/0.5/usr/lib/ruby/ 
1.9.0/hotcocoa/mappings/application.rb:9:in `handle_block:':  
undefined method `on_action' for 0:NSSlider (NoMethodError)

from core:in `application:'
from demo.rb:1:in `'
dab:graphics jdabel$

My Mac:
Modellname: MacBook
  Modell-Identifizierung:   MacBook5,1
  Prozessortyp: Intel Core 2 Duo
  Prozessorgeschwindigkeit: 2,4 GHz
  Anzahl der Prozessoren:   1
  Gesamtzahl der Kerne: 2
  L2-Cache: 3 MB
  Speicher: 4 GB

I would choose MacRuby for Hotcocoa!!!

Juergen Dabel
Schrobenhausen
Germany
___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel


___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] Accessing memory address in MacRuby

2009-12-04 Thread Laurent Sansonetti


Hi Yehuda,

C pointers are mapped to the Pointer class. You can create Pointer  
objects by yourself, and if you override an Objective-C method with a  
C pointer argument, MacRuby will hand you an instance of Pointer.


You code could be rewritten in MacRuby as:

  retValuePtr = Pointer.new(:int) # this creates a C pointer of sizeof 
(int) of 1 element
  retValuePtr[0] = 1 # assigns 1 as the first (and only) element of  
the pointer
  historyController.repository outputForArguments:['update-ref', '- 
mUpdate from GitX', ref.ref, dropCommit.realSha], retValue: retValuePtr

  if retValuePtr[0] == 1 # dereference the first element of the pointer
return false
  end
  # ...

If you are overriding the outputForArguments:retValue: method in  
MacRuby, the last argument should be of Pointer type.


  def outputForArguments(args, retValue: retValuePtr)
# ...
if some_error
  retValuePtr[0] = 1
end
  end

It is very easily to crash the program while using a Pointer object  
that was created by MacRuby, because MacRuby has no way to know the  
boundaries of the original C pointer.


Laurent

On Dec 4, 2009, at 4:16 PM, Yehuda Katz wrote:

I'm currently working with an API that sends me a memory address for  
an int and expects me to populate it with a value:


It essentially looks like this:

int retValue = 1;
[historyController.repository outputForArguments:[NSArray  
arrayWithObjects:@"update-ref", @"-mUpdate from GitX", [ref ref],  
[dropCommit realSha], NULL] retValue:&retValue];

if (retValue) return NO;

I am writing code that implements outputForArguments:retValue:, but  
it seems that MacRuby hands me an opaque primitive that I can't use.  
When I try to do anything with it, I get EXC_BAD_ACCESS.


Any ideas?

Yehuda Katz
Developer | Engine Yard
(ph) 718.877.1325
___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel


___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] [MacRuby] #481: macrubyc doesn't let you use ruby's stdlibs

2009-12-04 Thread MacRuby

#481: macrubyc  doesn't let you use ruby's stdlibs
-+--
 Reporter:  mattaimone...@…  |   Owner:  lsansone...@…
 Type:  defect   |  Status:  new  
 Priority:  blocker  |   Milestone:  MacRuby 0.5  
Component:  MacRuby  |Keywords:   
-+--

Comment(by lsansone...@…):

 $LOAD_PATH is missing. 

-- 
Ticket URL: 
MacRuby 

___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] [MacRuby] #474: Sinatra's get method not being registered

2009-12-04 Thread MacRuby

#474: Sinatra's get method not being registered
+---
 Reporter:  c...@…   |Owner:  lsansone...@…
 Type:  defect  |   Status:  closed   
 Priority:  trivial |Milestone:   
Component:  MacRuby |   Resolution:  invalid  
 Keywords:  |  
+---
Changes (by lsansone...@…):

  * status:  new => closed
  * resolution:  => invalid


Comment:

 I believe you need to tell the program about the webserver. Sinatra
 probably has a default one that MacRuby can't run, for a reason.

 # We recently created a simple webserver in MacRuby that runs Sinatra
 apps, and it will be released soon.

 I am closing the bug since 1.9 behaves the same. If you believe there is
 something wrong in MacRuby please let us know.

-- 
Ticket URL: 
MacRuby 

___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

[MacRuby-devel] Xcode and Interface Builder: action and outlets not showing up

Re: [MacRuby-devel] Xcode and Interface Builder: action and outlets not showing up

Re: [MacRuby-devel] Xcode and Interface Builder: action and outlets not showing up

Re: [MacRuby-devel] [MacRuby] #477: Need GCD wrapper for dispatch_once

Re: [MacRuby-devel] [MacRuby] #477: Need GCD wrapper for dispatch_once

Re: [MacRuby-devel] [MacRuby] #477: Need GCD wrapper for dispatch_once

Re: [MacRuby-devel] [MacRuby] #476: GCD Groups should be a wrapper around dispatch, not its own invocation style

Re: [MacRuby-devel] [MacRuby] #476: GCD Groups should be a wrapper around dispatch, not its own invocation style

[MacRuby-devel] [MacRuby] #482: Dispatch::Queue#dispatch should take a hash instead of a bool

Re: [MacRuby-devel] [MacRuby] #479: Need GCD wrapper for Process Sources

[MacRuby-devel] [MacRuby] #483: Need GCD wrapper for File (Vnode) Sources

[MacRuby-devel] Accessing memory address in MacRuby

[MacRuby-devel] [MacRuby] #484: scoping issues with notification center

Re: [MacRuby-devel] [MacRuby] #484: scoping issues with notification center

Re: [MacRuby-devel] hotcocoa/graphics

Re: [MacRuby-devel] Accessing memory address in MacRuby

Re: [MacRuby-devel] [MacRuby] #481: macrubyc doesn't let you use ruby's stdlibs

Re: [MacRuby-devel] [MacRuby] #474: Sinatra's get method not being registered

18 matches

Site Navigation

Mail list logo

Footer information