[MacRuby-devel] [MacRuby] #767: Some minor issues with framework constants

2010-06-30 Thread MacRuby 
#767: Some minor issues with framework constants
+---
 Reporter:  jazz...@…   |   Owner:  lsansone...@…
 Type:  defect  |  Status:  new  
 Priority:  minor   |   Milestone:  MacRuby 0.7  
Component:  MacRuby |Keywords:   
+---
 Issue 1:

 {{{
 $ macruby -e "framework 'AddressBook'; p KABEmailMobileMeLabel"
 unknown: [BUG] cannot locate symbol for BridgeSupport constant
 `kABEmailMobileMeLabel'
 MacRuby 0.7 (ruby 1.9.2) [universal-darwin10.0, x86_64]

 Abort trap
 }}}

 I think that's because this constant is defined in the Mac OS X v10.6 SDK
 only.

 Issue 2:

 {{{
 $ macruby -e "framework 'Foundation'; p KCFAllocatorUseContext"
 Segmentation fault
 }}}

 I ran into this when iterating over the constants in a framework:

 {{{
 oc = Object.constants
 framework 'Foundation'
 (Object.constants - oc).each do |c|
   puts "#{c} = #{eval(c).inspect}"
 end
 }}}

 In MacRuby 0.5 KCFAllocatorUseContext isn't accessible!

-- 
Ticket URL: 
MacRuby 

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

Re: [MacRuby-devel] [MacRuby] #765: framework is not supported in MacRuby static

2010-06-30 Thread MacRuby 
#765: framework is not supported in MacRuby static
+---
 Reporter:  jazz...@…   |   Owner:  lsansone...@…
 Type:  defect  |  Status:  new  
 Priority:  major   |   Milestone:  MacRuby 0.7  
Component:  MacRuby |Keywords:   
+---

Comment(by jazz...@…):

 Replying to [comment:1 lsansone...@…]:
 > #framework is not supported via static compilation. You should specify
 the frameworks you need using --framework to macrubyc instead.

 NSGregorianCalendar is a constant which is defined in the foundation
 framework, which is already included by default in macrubyc.

 > FYI, static compilation is still a work in progress, so a lot of things
 will not work yet.

 ...so I have to wait until constants of Cocoa frameworks are supported!

-- 
Ticket URL: 
MacRuby 

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

[MacRuby-devel] [MacRuby] #768: Timeout is broken. It seems MacRuby does not dispatch the Thread.

2010-06-30 Thread MacRuby 
#768: Timeout is broken. It seems MacRuby does not dispatch the Thread.
--+-
 Reporter:  watson1...@…  |   Owner:  lsansone...@…
 Type:  defect|  Status:  new  
 Priority:  blocker   |   Milestone:   
Component:  MacRuby   |Keywords:   
--+-
 Timeout is broken.
 Even if Timeout which I appointed passed, MacRuby's execution is not
 finished.

 {{{
 require 'timeout'

 Timeout::timeout(1) do
   i = 0
   loop do
 i += 1
   end
 end
 }}}

 I think it seems MacRuby does not dispatch the Thread.

-- 
Ticket URL: 
MacRuby 

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

[MacRuby-devel] Compile fix for 10.5

2010-06-30 Thread Justin McPherson 
Hi,

Attached is a compile fix for 10.5.

There are other problems building on 10.5 that are not addressed by the
patch, thought I'd offer it up anyway :)


- Justin


-- 
Decay is inherent in all component things, work out your salvation with
diligence.


objc.m.patch
Description: Binary data
___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] Compile fix for 10.5

2010-06-30 Thread Laurent Sansonetti 
Thanks Justin, merged in r4311!

Laurent

On Jun 30, 2010, at 7:46 AM, Justin McPherson wrote:

> Hi,
> 
> Attached is a compile fix for 10.5. 
> 
> There are other problems building on 10.5 that are not addressed by the 
> patch, thought I'd offer it up anyway :)
> 
> 
> - Justin
> 
> 
> -- 
> Decay is inherent in all component things, work out your salvation with 
> diligence.
> ___
> 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] #745: README.rdoc has mistake in "Enumerable#p_findall" on "lib/dispach". And p_find_all causes an error.

2010-06-30 Thread MacRuby 
#745: README.rdoc has mistake in "Enumerable#p_findall" on "lib/dispach". And
p_find_all causes an error.
--+-
 Reporter:  watson1...@…  |Owner:  lsansone...@…
 Type:  defect|   Status:  closed   
 Priority:  blocker   |Milestone:   
Component:  MacRuby   |   Resolution:  fixed
 Keywords:|  
--+-
Changes (by ernest.prabha...@…):

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


Comment:

 Thanks so much. Committed r4312.

-- 
Ticket URL: 
MacRuby 

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

[MacRuby-devel] memory leaks

2010-06-30 Thread Jakub Suder 
Hi,

The users of my app are reporting to me that it takes way more memory
than such app is supposed to. I've just released a new version that
was supposed to improve this at least a bit, and someone commented
that "I haven't even entered login and password and it already leaked
almost a megabyte" (posting this screenshot from Instruments:
http://static0.blip.pl/user_generated/update_pictures/1129697.jpg). I
did a test - I've removed almost everything from the app except the
login screen; and indeed, when started, the Leaks tool in Instruments
shows about 800 KB of leaked memory (I suppose it goes up over time).
All of that is shown as coming from libmacruby (though this really
just means that the app is running MacRuby, as I understand).

Now, I'm wondering:
- is this memory leaking because I'm doing something wrong (though
there's not much things I could have done wrong in a login dialog...)
- or is it leaking because MacRuby is doing something wrong
- or is it not leaking at all really, and it's just that Instruments
can't understand the memory managed by MacRuby and assumes it's leaked
even if it's not?

Here's a minimal version of the app:
http://dl.dropbox.com/u/41808/macblip_mem_test.zip

Could you take a look and give me some clues? (I'm running MacRuby 0.6 stable)

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

Re: [MacRuby-devel] [MacRuby] #745: README.rdoc has mistake in "Enumerable#p_findall" on "lib/dispach". And p_find_all causes an error.

2010-06-30 Thread MacRuby 
#745: README.rdoc has mistake in "Enumerable#p_findall" on "lib/dispach". And
p_find_all causes an error.
--+-
 Reporter:  watson1...@…  |Owner:  lsansone...@…
 Type:  defect|   Status:  reopened 
 Priority:  blocker   |Milestone:   
Component:  MacRuby   |   Resolution:   
 Keywords:|  
--+-
Changes (by watson1...@…):

  * status:  closed => reopened
  * resolution:  fixed =>


Comment:

 In Enumerable#p_find section, p_find_all is described.

 please modify.

-- 
Ticket URL: 
MacRuby 

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

[MacRuby-devel] [MacRuby] #769: String::ord with packed array in MacRuby

2010-06-30 Thread MacRuby 
#769: String::ord with packed array in MacRuby
-+--
 Reporter:  babs.d...@…  |   Owner:  lsansone...@…  

 Type:  defect   |  Status:  new

 Priority:  blocker  |   Milestone:  MacRuby 0.7

Component:  MacRuby  |Keywords:  binary, pack, ord, ordinal, 
String, String::ord
-+--
 When attempting to get the ordinal from a character of an array packed to
 a binary string, MacRuby returns inconsistent values, and sometimes seg.
 faults.

 {{{
 sha1 = ["94f389bf5d9af4511597d035e69d1be9510b50c7"].pack("H*")
 sha1[0].ord
 #Macirb has returned:
 #  63, 96, 65428(most often), 65535, and seg. faults
 #Irb returns: 148

 foo = ['bar'].pack('H*')
 foo[1].ord
 #Macirb:65456 Irb:176

 "cat"[0].ord
 #Works as expected
 }}}

 Tested with Ruby 1.9.1 and Macruby 6/23/10 nightly.

-- 
Ticket URL: 
MacRuby 

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

Re: [MacRuby-devel] [MacRuby] #768: Timeout is broken. It seems MacRuby does not dispatch the Thread.

2010-06-30 Thread MacRuby 
#768: Timeout is broken. It seems MacRuby does not dispatch the Thread.
--+-
 Reporter:  watson1...@…  |Owner:  lsansone...@…
 Type:  defect|   Status:  closed   
 Priority:  blocker   |Milestone:   
Component:  MacRuby   |   Resolution:  duplicate
 Keywords:|  
--+-
Changes (by martinlagarde...@…):

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


Comment:

 This is a duplicate of a know bug: #176

 The problem is not that the thread is not dispatched. It is actually
 dispatched. But the dispatched thread is not the one that does the
 operation, it's a thread that sleep for whatever was passed to timeout,
 and then sends "cancel" to the main thread. However, with the way MacRuby
 implements threads (with pthread), it's not possible to cancel the main
 thread without breaking everything :D.

 We're working on it, and waiting to find a solution.

-- 
Ticket URL: 
MacRuby 

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

Re: [MacRuby-devel] [MacRuby] #176: timeout fails to raise a Timeout::Error

2010-06-30 Thread MacRuby 
#176: timeout fails to raise a Timeout::Error
-+--
 Reporter:  acangi...@…  |   Owner:  lsansone...@…
 Type:  defect   |  Status:  new  
 Priority:  major|   Milestone:   
Component:  MacRuby  |Keywords:   
-+--
Description changed by martinlagarde...@…:

Old description:

> timeout should raise a Timeout::Error with message "execution expired"
> when the time is up. Right now
> it doesn't.
>
> For example, you can try the following:
>
> require 'timeout'
>
> timeout(2) do
>   1+1 while true
> end

New description:

 timeout should raise a Timeout::Error with message "execution expired"
 when the time is up. Right now
 it doesn't.

 For example, you can try the following:

 {{{
 require 'timeout'

 timeout(2) do
   1+1 while true
 end
 }}}

--

-- 
Ticket URL: 
MacRuby 

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

Re: [MacRuby-devel] [MacRuby] #768: Timeout is broken. It seems MacRuby does not dispatch the Thread.

2010-06-30 Thread Chuck Remes 

On Jun 30, 2010, at 8:07 PM, MacRuby wrote:

> #768: Timeout is broken. It seems MacRuby does not dispatch the Thread.
> --+-
> Reporter:  watson1...@…  |Owner:  lsansone...@…
> Type:  defect|   Status:  closed   
> Priority:  blocker   |Milestone:   
> Component:  MacRuby   |   Resolution:  duplicate
> Keywords:|  
> --+-
> Changes (by martinlagarde...@…):
> 
>  * status:  new => closed
>  * resolution:  => duplicate
> 
> 
> Comment:
> 
> This is a duplicate of a know bug: #176
> 
> The problem is not that the thread is not dispatched. It is actually
> dispatched. But the dispatched thread is not the one that does the
> operation, it's a thread that sleep for whatever was passed to timeout,
> and then sends "cancel" to the main thread. However, with the way MacRuby
> implements threads (with pthread), it's not possible to cancel the main
> thread without breaking everything :D.
> 
> We're working on it, and waiting to find a solution.

I believe the rubinius guys solved this using the following trick. I may also 
be completely wrong about it. :)

When you create a timeout thread, also create a named socket (or pipe) and add 
its file descriptor to the set of descriptors that the main loop selects/polls 
on. Have your timeout thread wake and signal that file descriptor. The main 
loop will detect the signal on that descriptor and do the appropriate thing.

That's also a technique for having signal handlers cleanly terminate the 
process. They can signal another FD which causes the main loop to clean up 
after itself and shutdown nicely.

cr

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