Re: [MacRuby-devel] Feedback: Dispatch high-level wrappers

2010-02-10 Thread Jordan K. Hubbard

On Feb 8, 2010, at 5:46 PM, Ernest N. Prabhakar, Ph.D. wrote:

> For MacRuby 0.6, I'd like to provide higher-level convenience APIs to reduce 
> the "cognitive overhead" and "semantic noise" of using Grand Central 
> Dispatch.  In other words, let people do what they want without having to 
> learn or type as much as they do now.

My first impression is "wow, cool!" followed by a second impression of "Hmmm!  
That's a lot of semi-parallel parallelization mechanisms to digest at one time!"

Which is not to say that I think you've overdone it here - this may be exactly 
the right number of permutations - but I'm having a hard time getting my head 
around the totality of what you're proposing clients of this code can actually 
do with it.  Having links to the implementations themselves is cool, and 
provides a fine API reference of a sort, but I think these sorts of concepts 
are far better conveyed through usage cases than implementation details.  Maybe 
if each of your bullets came with a small code fragment which demonstrated how 
to use the wrapper to solve Real World Problem Foo, even managers like myself 
could make the individual cognitive leaps much more readily.  :-)

- Jordan



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


Re: [MacRuby-devel] Feedback: Dispatch high-level wrappers

2010-02-10 Thread Jordan K. Hubbard

On Feb 8, 2010, at 5:46 PM, Ernest N. Prabhakar, Ph.D. wrote:

> I've also written up specs to both test and demonstrate these constructs:

P.S. Is it just me, or do other people have a really hard time turning specs 
into usage-case examples when they read them?

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


Re: [MacRuby-devel] [MacRuby] #609: Constants and methods are not copied when cloning modules

2010-02-10 Thread MacRuby
#609: Constants and methods are not copied when cloning modules
-+--
 Reporter:  m...@…   |Owner:  lsansone...@…
 Type:  defect   |   Status:  closed   
 Priority:  major|Milestone:  MacRuby 0.6  
Component:  MacRuby  |   Resolution:  fixed
 Keywords:   |  
-+--
Changes (by martinlagarde...@…):

  * status:  new => closed
  * resolution:  => fixed
  * milestone:  => MacRuby 0.6


Comment:

 r3475 should fix this bug :-)

-- 
Ticket URL: 
MacRuby 

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


Re: [MacRuby-devel] [MacRuby] #549: Class variables are not initialised properly.

2010-02-10 Thread MacRuby
#549: Class variables are not initialised properly.
-+--
 Reporter:  sorin.ione...@…  |   Owner:  lsansone...@…
 Type:  defect   |  Status:  new  
 Priority:  blocker  |   Milestone:  MacRuby 0.5  
Component:  MacRuby  |Keywords:  class, instance  
-+--
Description changed by martinlagarde...@…:

Old description:

> The mime-types gem has a class and an instance interface. The class
> interface uses an instance of itself. However, it doesn’t work in
> MacRuby. It does not seem to be initialised properly. I have included in
> a sample code with the expected behaviour. Changing @__types__ to
> @@__types__ will not fix it.
>
> #!/usr/bin/env macruby
>
> class Test
>   def initialize()
> @foo = true
>   end
>
>   def add(something)
> puts "Is foo nil: #[email protected]?}"
>   end
>
>   @__types__ = self.new()
>
>   def self.add(something)
> @__types__.add(something)
>   end
> end
>
> t = Test.new
> t.add(3)
> Test.add(4)
>
> Output (MacRuby 0.5)
> Is foo nil: false
> Is foo nil: true
>
> Expected (Ruby 1.9.1/1.8.7)
> Is foo nil: false
> Is foo nil: false

New description:

 The mime-types gem has a class and an instance interface. The class
 interface uses an instance of itself. However, it doesn’t work in MacRuby.
 It does not seem to be initialised properly. I have included in a sample
 code with the expected behaviour. Changing @__types__ to @@__types__ will
 not fix it.

 {{{
 #!/usr/bin/env macruby

 class Test
   def initialize()
 @foo = true
   end

   def add(something)
 puts "Is foo nil: #[email protected]?}"
   end

   @__types__ = self.new()

   def self.add(something)
 @__types__.add(something)
   end
 end

 t = Test.new
 t.add(3)
 Test.add(4)
 }}}

 Output (MacRuby 0.5)
 {{{
 Is foo nil: false
 Is foo nil: true
 }}}
 Expected (Ruby 1.9.1/1.8.7)
 {{{
 Is foo nil: false
 Is foo nil: false
 }}}

--

-- 
Ticket URL: 
MacRuby 

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


Re: [MacRuby-devel] [MacRuby] #549: Class variables are not initialised properly.

2010-02-10 Thread MacRuby
#549: Class variables are not initialised properly.
-+--
 Reporter:  sorin.ione...@…  |   Owner:  lsansone...@…
 Type:  defect   |  Status:  new  
 Priority:  blocker  |   Milestone:  MacRuby 0.5  
Component:  MacRuby  |Keywords:  class, instance  
-+--
Description changed by martinlagarde...@…:

Old description:

> The mime-types gem has a class and an instance interface. The class
> interface uses an instance of itself. However, it doesn’t work in
> MacRuby. It does not seem to be initialised properly. I have included in
> a sample code with the expected behaviour. Changing @__types__ to
> @@__types__ will not fix it.
>
> {{{
> #!/usr/bin/env macruby
>
> class Test
>   def initialize()
> @foo = true
>   end
>
>   def add(something)
> puts "Is foo nil: #[email protected]?}"
>   end
>
>   @__types__ = self.new()
>
>   def self.add(something)
> @__types__.add(something)
>   end
> end
>
> t = Test.new
> t.add(3)
> Test.add(4)
> }}}
>
> Output (MacRuby 0.5)
> {{{
> Is foo nil: false
> Is foo nil: true
> }}}
> Expected (Ruby 1.9.1/1.8.7)
> {{{
> Is foo nil: false
> Is foo nil: false
> }}}

New description:

 The mime-types gem has a class and an instance interface. The class
 interface uses an instance of itself. However, it doesn’t work in MacRuby.
 It does not seem to be initialised properly. I have included in a sample
 code with the expected behaviour. Changing `...@__types__` to `@@__types__`
 will not fix it.

 {{{
 #!/usr/bin/env macruby

 class Test
   def initialize()
 @foo = true
   end

   def add(something)
 puts "Is foo nil: #[email protected]?}"
   end

   @__types__ = self.new()

   def self.add(something)
 @__types__.add(something)
   end
 end

 t = Test.new
 t.add(3)
 Test.add(4)
 }}}

 Output (MacRuby 0.5)
 {{{
 Is foo nil: false
 Is foo nil: true
 }}}
 Expected (Ruby 1.9.1/1.8.7)
 {{{
 Is foo nil: false
 Is foo nil: false
 }}}

--

-- 
Ticket URL: 
MacRuby 

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


Re: [MacRuby-devel] [MacRuby] #549: Class variables are not initialised properly.

2010-02-10 Thread MacRuby
#549: Class variables are not initialised properly.
-+--
 Reporter:  sorin.ione...@…  |   Owner:  lsansone...@…
 Type:  defect   |  Status:  new  
 Priority:  blocker  |   Milestone:  MacRuby 0.5  
Component:  MacRuby  |Keywords:  class, instance  
-+--
Description changed by martinlagarde...@…:

Old description:

> The mime-types gem has a class and an instance interface. The class
> interface uses an instance of itself. However, it doesn’t work in
> MacRuby. It does not seem to be initialised properly. I have included in
> a sample code with the expected behaviour. Changing `...@__types__` to
> `@@__types__` will not fix it.
>
> {{{
> #!/usr/bin/env macruby
>
> class Test
>   def initialize()
> @foo = true
>   end
>
>   def add(something)
> puts "Is foo nil: #[email protected]?}"
>   end
>
>   @__types__ = self.new()
>
>   def self.add(something)
> @__types__.add(something)
>   end
> end
>
> t = Test.new
> t.add(3)
> Test.add(4)
> }}}
>
> Output (MacRuby 0.5)
> {{{
> Is foo nil: false
> Is foo nil: true
> }}}
> Expected (Ruby 1.9.1/1.8.7)
> {{{
> Is foo nil: false
> Is foo nil: false
> }}}

New description:

 The mime-types gem has a class and an instance interface. The class
 interface uses an instance of itself. However, it doesn’t work in MacRuby.
 It does not seem to be initialised properly. I have included in a sample
 code with the expected behaviour. Changing `...@__types__` to `@@__types__`
 will not fix it.

 {{{
 class MacRubyInitTest
   def initialize
 @foo = true
   end

   def add
 p self
 puts "@foo = " + @foo.inspect
   end

   @__types__ = self.new()

   def self.add
 @__types__.add
   end
 end

 t = MacRubyInitTest.new
 t.add
 MacRubyInitTest.add
 }}}

 Output (MacRuby 0.5)
 {{{
 
 @foo = true
 
 @foo = nil
 }}}
 Expected (Ruby 1.9.1/1.8.7)
 {{{
 #
 @foo = true
 #
 @foo = true
 }}}

--

-- 
Ticket URL: 
MacRuby 

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


Re: [MacRuby-devel] [MacRuby] #549: Class variables are not initialised properly.

2010-02-10 Thread MacRuby
#549: Class variables are not initialised properly.
-+--
 Reporter:  sorin.ione...@…  |   Owner:  lsansone...@…
 Type:  defect   |  Status:  new  
 Priority:  blocker  |   Milestone:  MacRuby 0.5  
Component:  MacRuby  |Keywords:  class, instance  
-+--

Comment(by martinlagarde...@…):

 Hi Sorin! Thanks for the report. Are you sure, though, that this bug is a
 "blocker"?

 To everyone: the attached file can be ignored, I edited the bug
 description to format the code, and modified it a little to show some
 interesting facts: `p self` shows that the `...@foo` variable is set to true,
 however, `...@foo` is `nil`.

-- 
Ticket URL: 
MacRuby 

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


Re: [MacRuby-devel] [MacRuby] #545: MacRuby.framework fails to work with Xcode

2010-02-10 Thread MacRuby
#545: MacRuby.framework fails to work with Xcode
-+--
 Reporter:  dognot...@…  |   Owner:  lsansone...@…
 Type:  defect   |  Status:  new  
 Priority:  major|   Milestone:   
Component:  MacRuby  |Keywords:  framework
-+--
Changes (by martinlagarde...@…):

 * cc: dognot...@… (added)


Comment:

 Hi!

 Can you verify this is still the case? And if it is, provide a sample
 Xcode project?

 Other people, like [http://blog.zottmann.org/ Carlo] have managed to use
 it properly, so maybe there is some misconfiguration on your side, or
 maybe the issue was fixed?

-- 
Ticket URL: 
MacRuby 

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


Re: [MacRuby-devel] [MacRuby] #547: macirb doesn't work, but macruby does

2010-02-10 Thread MacRuby
#547: macirb doesn't work, but macruby does
--+-
 Reporter:  rensela...@…  |   Owner:  lsansone...@…
 Type:  defect|  Status:  new  
 Priority:  blocker   |   Milestone:   
Component:  MacRuby   |Keywords:   
--+-
Changes (by martinlagarde...@…):

 * cc: rensela...@… (added)


Comment:

 Do we have some updates about this bug? Or can we close it for lack of
 activity & details?

-- 
Ticket URL: 
MacRuby 

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


Re: [MacRuby-devel] [MacRuby] #546: REXML text.rb fails: premature end of char-class

2010-02-10 Thread MacRuby
#546: REXML text.rb fails: premature end of char-class
-+--
 Reporter:  mac...@… |Owner:  lsansone...@…
 Type:  defect   |   Status:  closed   
 Priority:  blocker  |Milestone:  MacRuby 0.5  
Component:  MacRuby  |   Resolution:  duplicate
 Keywords:  0.5 rexml text.rb premature  |  
-+--
Changes (by martinlagarde...@…):

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


Comment:

 Let's mark it as a duplicate of #612

 Basically, we are implementing a new String / Regex class, that will
 hopefully get rid of this completely random bug.

-- 
Ticket URL: 
MacRuby 

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


Re: [MacRuby-devel] [MacRuby] #612: RegexpError: too short escaped multibyte character

2010-02-10 Thread MacRuby
#612: RegexpError: too short escaped multibyte character
-+--
 Reporter:  cehoff...@…  |   Owner:  lsansone...@…
 Type:  defect   |  Status:  new  
 Priority:  blocker  |   Milestone:   
Component:  MacRuby  |Keywords:   
-+--

Comment(by martinlagarde...@…):

 Should we close this bug? We have plenty of bug report about errors from
 re.c with `too short escaped` etc. or `premature end of char-class`, and
 they should be fixed when we have the new string/regexp

-- 
Ticket URL: 
MacRuby 

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


Re: [MacRuby-devel] [MacRuby] #544: NSBigMutableString#tr crashes

2010-02-10 Thread MacRuby
#544: NSBigMutableString#tr crashes
+---
 Reporter:  vincent.isamb...@…  |   Owner:  lsansone...@…
 Type:  defect  |  Status:  new  
 Priority:  blocker |   Milestone:  MacRuby 0.5  
Component:  MacRuby |Keywords:   
+---

Comment(by martinlagarde...@…):

 In `string.c:str_charset_find:2901`, the following debug:
 {{{
 printf("CFStringRef len: %ld\n", CFStringGetLength(str));
 CFShowStr(str);
 }}}
 Shows this for an `NSMutableString`:
 {{{
 $ ./miniruby -e "NSMutableString.stringWithString('abcd').tr('a','b')"
 CFStringRef len: 4

 Length 4
 IsEightBit 1
 HasLengthByte 1
 HasNullByte 1
 InlineContents 0
 Allocator SystemDefault
 Mutable 1
 CurrentCapacity 32
 DesiredCapacity 32
 Contents 0x20004d9e0
 }}}
 But it shows this for an `NSBigMutableString`:
 {{{
 $ ./miniruby -e "NSBigMutableString.stringWithString('abcd').tr('a','b')"
 CFStringRef len: 8590253120
 This is an NSString, not CFString
 unknown: [BUG] Segmentation fault
 }}}

-- 
Ticket URL: 
MacRuby 

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


Re: [MacRuby-devel] [MacRuby] #517: Installer crashes (if not admin?)

2010-02-10 Thread MacRuby
#517: Installer crashes (if not admin?)
--+-
 Reporter:  paulhenryda...@…  |   Owner:  lsansone...@…
 Type:  defect|  Status:  new  
 Priority:  minor |   Milestone:  MacRuby 0.5  
Component:  MacRuby   |Keywords:   
--+-
Changes (by martinlagarde...@…):

 * cc: paulhenryda...@… (added)


Comment:

 Hi!

 Do you have any more information about that? Is it still a problem with
 the current final 0.5 release?

-- 
Ticket URL: 
MacRuby 

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


Re: [MacRuby-devel] [MacRuby] #520: Confusion in data type names for Core OpenGL

2010-02-10 Thread MacRuby
#520: Confusion in data type names for Core OpenGL
--+-
 Reporter:  sojasta...@…  |   Owner:  lsansone...@… 
  
 Type:  defect|  Status:  new   
  
 Priority:  blocker   |   Milestone:
  
Component:  MacRuby   |Keywords:  pointer Core OpenGL data 
types confusion
--+-

Comment(by martinlagarde...@…):

 I reduced the code, but haven't been able to find what exactly is causing
 the problem. The issue arise at the last line, when trying to dereference
 `*CGLRendererInfoObject` to `CGLRendererInfoObject` (aka
 `^{_CGLRendererInfoObject}` to `{_CGLRendererInfoObject}`)
 {{{
 $ cat test.rb
 framework 'Cocoa'

 renderer_info = Pointer.new_with_type("^{_CGLRendererInfoObject}")
 renderer_count = Pointer.new_with_type("i")
 CGLQueryRendererInfo(1, renderer_info, renderer_count)
 renderer_info[0]

 $ ./miniruby test.rb
 /tmp/test.rb:1:in `': unrecognized runtime type
 `{_CGLRendererInfoObject}' (TypeError)
 }}}

-- 
Ticket URL: 
MacRuby 

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


Re: [MacRuby-devel] [MacRuby] #537: Missing Time#strftime formatter: "%P"

2010-02-10 Thread MacRuby
#537: Missing Time#strftime formatter: "%P"
---+
 Reporter:  bbu...@…   |   Owner:  lsansone...@…
 Type:  defect |  Status:  new  
 Priority:  minor  |   Milestone:   
Component:  MacRuby|Keywords:   
---+

Comment(by martinlagarde...@…):

 Laurent, what's our take on this? Right now we're using the system's
 `strftime` that does not implement %P. If we really want to support %P, we
 may have to use the one in Ruby 1.9

-- 
Ticket URL: 
MacRuby 

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


Re: [MacRuby-devel] [MacRuby] #612: RegexpError: too short escaped multibyte character

2010-02-10 Thread Jordan K. Hubbard
Probably a good idea to close it *after* the new string/regexp is done and 
we've proven that it actually solves the problem, or at least have a reasonably 
good idea that it does. :)

- Jordan

On Feb 10, 2010, at 3:45 AM, MacRuby wrote:

> Should we close this bug? We have plenty of bug report about errors from
> re.c with `too short escaped` etc. or `premature end of char-class`, and
> they should be fixed when we have the new string/regexp

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


Re: [MacRuby-devel] Feedback: Dispatch high-level wrappers

2010-02-10 Thread Ernest N. Prabhakar, Ph.D.
Hi Jordan,

On Feb 10, 2010, at 12:30 AM, Jordan K. Hubbard wrote:
> On Feb 8, 2010, at 5:46 PM, Ernest N. Prabhakar, Ph.D. wrote:
> 
>> I've also written up specs to both test and demonstrate these constructs:
> 
> P.S. Is it just me, or do other people have a really hard time turning specs 
> into usage-case examples when they read them?

I don't disagree.  Specs are arguably a half-step towards documentation.  
That's the next step, to actually create some real documentation.

Ironically, that is what I initially set out to do, but the API wasn't clean 
and complete enough to document, so I got sidetracked...

-- Ernie P.

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


Re: [MacRuby-devel] [MacRuby] #537: Missing Time#strftime formatter: "%P"

2010-02-10 Thread MacRuby
#537: Missing Time#strftime formatter: "%P"
---+
 Reporter:  bbu...@…   |   Owner:  lsansone...@…
 Type:  defect |  Status:  new  
 Priority:  minor  |   Milestone:   
Component:  MacRuby|Keywords:   
---+

Comment(by lsansone...@…):

 Maybe this will be done as part of #608.

-- 
Ticket URL: 
MacRuby 

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


[MacRuby-devel] Apple System Logger

2010-02-10 Thread Chris Hoffman
I've been trying to use the asl from macruby.  Accordingly I've created the 
necessary bridgesupport file from asl.h.  I can call asl_log just fine, but the 
issue comes when trying to customize the message.

For example, I'd like to have the output show up in Console.app.  To do this I 
need to

>> m = asl_new(ASL_TYPE_MSG)
>> asl_set(m, ASL_KEY_FACILITY, "com.apple.console")
>> asl_log(nil, m, ASL_LEVEL_INFO, "Shows up in console")

Unfortunately there is an error on the asl_new

TypeError: unrecognized runtime type `{__aslmsg=}'
from /Users/cehoffman/Repos/Ruby/mp4tag/(irb):9:in `'

Similarly trying to use client connections fails

>> asl_open($0, "com.apple.console", ASL_OPT_NO_DELAY)
TypeError: unrecognized runtime type `{__aslclient=}'
from /Users/cehoffman/Repos/Ruby/mp4tag/(irb):4:in `'

I was wondering what the next steps would be correct this since I have not 
encountered this error with BridgeSupport before.

P.S. I found an error in gen_bridge_metadata when creating 64-bit bridgesupport 
files. Setting headers directly bypassed the creation of the @import_directive 
which prevented the script from continuing.

Line 505:

g.headers = @headers

should be the following or similar to set @import_directive

@headers.each { |header| g.add_header(header) }
___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel


[MacRuby-devel] [MacRuby] #613: Dispatch classes should be wrapped in an Data struct to allow subclassing

2010-02-10 Thread MacRuby
#613: Dispatch classes should be wrapped in an Data struct to allow subclassing
+---
 Reporter:  ernest.prabha...@…  |   Owner:  lsansone...@…
 Type:  defect  |  Status:  new  
 Priority:  blocker |   Milestone:   
Component:  MacRuby |Keywords:   
+---
 The gcd.c implementation has this cryptic comment:

 // TODO: These structures need to be wrapped in a Data struct,
 // otherwise there are crashes when one tries to add an instance
 // variable to a queue. (Not that that is a good idea.)

 At first I ignored this, but later it occurred to me that this may be why
 I am unable to subclass Dispatch::Group (to use for a Future, which
 contains an instance variable).  Is that correct?  If so, is there a
 particular reason why subclassing these would be  bad idea?

-- 
Ticket URL: 
MacRuby 

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


Re: [MacRuby-devel] [MacRuby] #613: Dispatch classes should be wrapped in an Data struct to allow subclassing

2010-02-10 Thread MacRuby
#613: Dispatch classes should be wrapped in an Data struct to allow subclassing
+---
 Reporter:  ernest.prabha...@…  |   Owner:  lsansone...@…
 Type:  defect  |  Status:  new  
 Priority:  minor   |   Milestone:   
Component:  MacRuby |Keywords:   
+---
Changes (by ernest.prabha...@…):

  * priority:  blocker => minor


Comment:

 FYI, here's the source:

 http://svn.macosforge.org/repository/ruby/MacRuby/trunk/gcd.c

-- 
Ticket URL: 
MacRuby 

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


Re: [MacRuby-devel] [MacRuby] #549: Class variables are not initialised properly.

2010-02-10 Thread MacRuby
#549: Class variables are not initialised properly.
-+--
 Reporter:  sorin.ione...@…  |   Owner:  lsansone...@…
 Type:  defect   |  Status:  new  
 Priority:  blocker  |   Milestone:  MacRuby 0.5  
Component:  MacRuby  |Keywords:  class, instance  
-+--

Comment(by sorin.ione...@…):

 It is a blocker. The mime-types gem that uses it is quite popular if not
 the only one. Thanks for fixing the report.

-- 
Ticket URL: 
MacRuby 

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


Re: [MacRuby-devel] [MacRuby] #537: Missing Time#strftime formatter: "%P"

2010-02-10 Thread MacRuby
#537: Missing Time#strftime formatter: "%P"
---+
 Reporter:  bbu...@…   |   Owner:  lsansone...@…
 Type:  defect |  Status:  new  
 Priority:  minor  |   Milestone:   
Component:  MacRuby|Keywords:   
---+

Comment(by danielcavan...@…):

 haha. consider me signed up

-- 
Ticket URL: 
MacRuby 

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


Re: [MacRuby-devel] [MacRuby] #608: rb_str_format() does not handle the "field width" flag for strings

2010-02-10 Thread MacRuby
#608: rb_str_format() does not handle the "field width" flag for strings
+---
 Reporter:  martinlagarde...@…  |   Owner:  lsansone...@…
 Type:  defect  |  Status:  new  
 Priority:  minor   |   Milestone:   
Component:  MacRuby |Keywords:   
+---

Comment(by danielcavan...@…):

 sorry about that! i didn't realise HACKING.rdoc was there. i originally
 had braces around everything but at the end i removed them from single-
 line conditionals because they were ugly ;)

 the diff has been updated to 3474, it should follow HACKING.rdoc now, and
 spec:ci passes except for some random Dispatch errors, but since that's
 being worked on i'm going to assume it isn't sprintf's fault. let me know
 if that's not the case and i'll dig into it a bit more

-- 
Ticket URL: 
MacRuby 

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


Re: [MacRuby-devel] [MacRuby] #608: rb_str_format() does not handle the "field width" flag for strings

2010-02-10 Thread Jordan K. Hubbard

On Feb 10, 2010, at 4:20 PM, MacRuby wrote:

> i originally had braces around everything but at the end i removed them from 
> single-
> line conditionals because they were ugly ;)

They *are* ugly, but nowhere near as ugly as what happens when someone goes to 
add another line to an existing conditional body, or what happens when they get 
an else accidentally paired up with the wrong conditional.  There are good 
defensive coding reasons for the ugliness, in other words. :)

- Jordan

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


Re: [MacRuby-devel] [MacRuby] #608: rb_str_format() does not handle the "field width" flag for strings

2010-02-10 Thread MacRuby
#608: rb_str_format() does not handle the "field width" flag for strings
+---
 Reporter:  martinlagarde...@…  |Owner:  lsansone...@…
 Type:  defect  |   Status:  closed   
 Priority:  minor   |Milestone:  MacRuby 0.6  
Component:  MacRuby |   Resolution:  fixed
 Keywords:  |  
+---
Changes (by lsansone...@…):

  * status:  new => closed
  * resolution:  => fixed
  * milestone:  => MacRuby 0.6


Comment:

 Thanks a lot for this nice work. Committed as r3487 :-)

-- 
Ticket URL: 
MacRuby 

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


Re: [MacRuby-devel] [MacRuby] #607: macruby_main() argv transformation prevents passing arguments to the Ruby app

2010-02-10 Thread MacRuby
#607: macruby_main() argv transformation prevents passing arguments to the Ruby
app
-+--
 Reporter:  hongli...@…  |Owner:  lsansone...@…
 Type:  defect   |   Status:  closed   
 Priority:  blocker  |Milestone:  MacRuby 0.6  
Component:  MacRuby  |   Resolution:  fixed
 Keywords:   |  
-+--
Changes (by lsansone...@…):

  * status:  new => closed
  * resolution:  => fixed
  * milestone:  => MacRuby 0.6


Comment:

 Thanks for the patch, applied in r3489.

-- 
Ticket URL: 
MacRuby 

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


Re: [MacRuby-devel] [MacRuby] #159: "%d" with large integer argument gives conversion error

2010-02-10 Thread MacRuby
#159: "%d" with large integer argument gives conversion error
-+--
 Reporter:  ja...@…  |Owner:  lsansone...@…
 Type:  defect   |   Status:  closed   
 Priority:  major|Milestone:  MacRuby 0.6  
Component:  MacRuby  |   Resolution:  fixed
 Keywords:   |  
-+--
Changes (by lsansone...@…):

  * status:  new => closed
  * resolution:  => fixed
  * milestone:  => MacRuby 0.6


Comment:

 In the meantime, this bug seems to be fixed as of r3487 (which does more
 or less what Ed did, a new sprintf implementation).

 {{{
 $ ./miniruby -e "p '%d' % 100"
 "100"
 }}}

-- 
Ticket URL: 
MacRuby 

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


Re: [MacRuby-devel] [MacRuby] #438: rb_define_method for MacRuby

2010-02-10 Thread MacRuby
#438: rb_define_method for MacRuby
--+-
 Reporter:  ko...@…   |Owner:  lsansone...@…
 Type:  enhancement   |   Status:  closed   
 Priority:  trivial   |Milestone:  MacRuby 0.6  
Component:  MacRuby   |   Resolution:  fixed
 Keywords:  rb_define_method  |  
--+-
Changes (by lsansone...@…):

  * status:  new => closed
  * resolution:  => fixed
  * milestone:  MacRuby 0.5 => MacRuby 0.6


Comment:

 rb_define_method() is now supported as of r3474. Functions defined using
 the MRI ABI will be handled by MacRuby.

-- 
Ticket URL: 
MacRuby 

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


Re: [MacRuby-devel] [MacRuby] #250: subclassing Array

2010-02-10 Thread MacRuby
#250: subclassing Array
-+--
 Reporter:  mattaimone...@…  |Owner:  lsansone...@…
 Type:  defect   |   Status:  closed   
 Priority:  major|Milestone:  MacRuby 0.6  
Component:  MacRuby  |   Resolution:  fixed
 Keywords:  subclassing, Array   |  
-+--
Changes (by lsansone...@…):

  * status:  new => closed
  * resolution:  => fixed
  * milestone:  => MacRuby 0.6


Comment:

 This problem seems to be fixed as of r3489. Closing.

-- 
Ticket URL: 
MacRuby 

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


Re: [MacRuby-devel] [MacRuby] #216: fork subprocess exiting (normally) segfaults

2010-02-10 Thread MacRuby
#216: fork subprocess exiting (normally) segfaults
---+
 Reporter:  cel...@…   |Owner:  lsansone...@…
 Type:  defect |   Status:  closed   
 Priority:  major  |Milestone:   
Component:  MacRuby|   Resolution:  wontfix  
 Keywords:  fork process   |  
---+
Changes (by lsansone...@…):

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


Comment:

 #fork will not be supported any time soon (very likely never).

-- 
Ticket URL: 
MacRuby 

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


Re: [MacRuby-devel] [MacRuby] #281: Bundles pointing to local MacRuby installation instead of embedded

2010-02-10 Thread MacRuby
#281: Bundles pointing to local MacRuby installation instead of embedded
---+
 Reporter:  reb...@…   |Owner:  
lsansone...@…
 Type:  defect |   Status:  closed  
 
 Priority:  major  |Milestone:  MacRuby 
0.6  
Component:  MacRuby|   Resolution:  fixed   
 
 Keywords:  embedded,deploy,installation,distribution  |  
---+
Changes (by lsansone...@…):

  * status:  new => closed
  * resolution:  => fixed
  * milestone:  => MacRuby 0.6


Comment:

 I believe this problem has been fixed as of 0.5. Recently in trunk, we
 also fixed the install name of .rbo files in r3434. So, I'm closing this
 ticket, please let me know if it's still a problem for you and I will re-
 investigate.

-- 
Ticket URL: 
MacRuby 

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


Re: [MacRuby-devel] [MacRuby] #425: RSpec not working

2010-02-10 Thread MacRuby
#425: RSpec not working
+---
 Reporter:  jens.nock...@…  |   Owner:  martinlagarde...@…
 Type:  defect  |  Status:  new   
 Priority:  major   |   Milestone:
Component:  MacRuby |Keywords:
+---
Changes (by lsansone...@…):

  * owner:  lsansone...@… => martinlagarde...@…


Comment:

 Thibault, can you have a look at this bug?

-- 
Ticket URL: 
MacRuby 

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


Re: [MacRuby-devel] [MacRuby] #598: EXC_BAD_ACCESS when *splatting arguments in method call

2010-02-10 Thread MacRuby
#598: EXC_BAD_ACCESS when *splatting arguments in method call
+---
 Reporter:  m...@…|Owner:  lsansone...@…
 Type:  defect  |   Status:  closed   
 Priority:  major   |Milestone:   
Component:  MacRuby |   Resolution:  invalid  
 Keywords:  |  
+---
Changes (by lsansone...@…):

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


Comment:

 This seems to work in trunk.

 {{{
 $ cat t.rb
 class FileList < Array
 def addFiles(files)
 clear
 push(*files)
 files
 end
 end

 o=FileList.new
 p o.addFiles(['a','b','c','d','e'])
 $ ./miniruby  t.rb
 ["a", "b", "c", "d", "e"]
 }}}

 I have no idea what could have been wrong for the reporter. The GDB output
 does not contain anything meaningful too (no backtrace). Closing.

-- 
Ticket URL: 
MacRuby 

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


Re: [MacRuby-devel] [MacRuby] #309: String, Hash, Array: singleton attr_accessor cannot be defined

2010-02-10 Thread MacRuby
#309: String, Hash, Array: singleton attr_accessor cannot be defined
+---
 Reporter:  d...@…   |Owner:  lsansone...@…
 Type:  defect  |   Status:  closed   
 Priority:  minor   |Milestone:  MacRuby 0.6  
Component:  MacRuby |   Resolution:  fixed
 Keywords:  singleton   |  
+---
Changes (by lsansone...@…):

  * status:  new => closed
  * resolution:  => fixed
  * milestone:  MacRuby 0.5 => MacRuby 0.6


Comment:

 The snippet above does not print anything anymore in trunk (as of r3489).

 {{{
 $ cat t.rb
 [
   false,
   true,
   nil,
   1..100,
   /test/,
   Exception,
   Time,
   Hash,
   Array,
   String,
   Module,
   Object
 ].each do |k|
   s = k.is_a?(Class) ? k.new : k
   class << s
 attr_accessor :target1
 def target2
   :hit
 end
   end
   s.target1 = :hit
   def s.target3
 :hit
   end
   puts "#{k} err: singleton attr_accessor" unless s.target1 == :hit
   puts "#{k} err: singleton def (#2)" unless s.target2 == :hit
   puts "#{k} err: singleton def (#3)" unless s.target3 == :hit
 end

 $ ./miniruby  t.rb
 $
 }}}

 I guess we can close the bug.

-- 
Ticket URL: 
MacRuby 

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


Re: [MacRuby-devel] [MacRuby] #508: Method Syntax

2010-02-10 Thread MacRuby
#508: Method Syntax
--+-
 Reporter:  cjenk...@…|Owner:  lsansone...@…
 Type:  enhancement   |   Status:  closed   
 Priority:  minor |Milestone:   
Component:  MacRuby   |   Resolution:  wontfix  
 Keywords:|  
--+-
Changes (by lsansone...@…):

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


Comment:

 How would you decide which part is the left side of the method and which
 part becomes the name of the first argument? For setters it's obvious, but
 Cocoa has lots of APIs.

 Your proposal sounds also too magical in my taste. It can be confusing for
 the new learner specifically (when he browses API reference). Finally,
 there is the problem of creating such selectors (not calling them).

 We do not intend to change the syntax any time soon, sorry.

-- 
Ticket URL: 
MacRuby 

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


Re: [MacRuby-devel] [MacRuby] #205: Incorrect list of instance methods

2010-02-10 Thread MacRuby
#205: Incorrect list of instance methods
+---
 Reporter:  vincent.isamb...@…  |Owner:  lsansone...@…
 Type:  defect  |   Status:  closed   
 Priority:  major   |Milestone:  MacRuby 0.6  
Component:  MacRuby |   Resolution:  fixed
 Keywords:  |  
+---
Changes (by lsansone...@…):

  * status:  new => closed
  * resolution:  => fixed
  * milestone:  => MacRuby 0.6


Comment:

 Seems to be fixed in trunk (as of r3489).

 {{{
 $ ./miniruby  t.rb
 []
 [:x]
 $ ruby  t.rb
 []
 ["x"]
 $ /Volumes/SL/usr/local/bin/ruby19  t.rb
 []
 [:x]
 }}}

-- 
Ticket URL: 
MacRuby 

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


Re: [MacRuby-devel] [MacRuby] #495: Minor error in instructions for building LLVM

2010-02-10 Thread MacRuby
#495: Minor error in instructions for building LLVM
+---
 Reporter:  ernest.prabha...@…  |Owner:  lsansone...@…
 Type:  defect  |   Status:  closed   
 Priority:  minor   |Milestone:   
Component:  MacRuby |   Resolution:  wontfix  
 Keywords:  |  
+---
Changes (by lsansone...@…):

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


Comment:

 Closing.

-- 
Ticket URL: 
MacRuby 

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


Re: [MacRuby-devel] [MacRuby] #246: NSMutableDictionary methods cannot retrieve values for Fixnum keys

2010-02-10 Thread MacRuby
#246: NSMutableDictionary methods cannot retrieve values for Fixnum keys
---+
 Reporter:  krishna.kote...@…  |Owner:  eloy.de.en...@…
 Type:  defect |   Status:  closed 
 Priority:  critical   |Milestone:  MacRuby 0.6
Component:  MacRuby|   Resolution:  fixed  
 Keywords:  NSMutableDictionary Hash   |  
---+
Changes (by lsansone...@…):

  * status:  new => closed
  * resolution:  => fixed
  * milestone:  => MacRuby 0.6


Comment:

 This has been fixed in trunk (I don't remember the exact revision).

 {{{
 $ ./miniruby  -e "h={}; h.setObject('foo',forKey:42); p
 h.objectForKey(42)"
 "foo"
 $ ./miniruby  -e "h=NSMutableDictionary.dictionary;
 h.setObject('foo',forKey:42); p h.objectForKey(42)"
 "foo"
 }}}

 Closing.

-- 
Ticket URL: 
MacRuby 

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