from:"Laurent Sansonetti"

Hi Steve,

It would be nice to know what exactly in ruby-mysql causes the
problem. If you can reduce the problem to a simple code snippet or
point us to the ruby-mysql source code it would be great.

Thanks
Laurent

On Sun, Sep 18, 2011 at 8:38 AM, Steve Clarke st...@sclarkes.me.uk wrote:
 Yes, looks like the same issue as ticket 742.  I did  look at tickets but 
 failed to spot that.

 The comment on the ticket re only UTF-8 being required may be true - it 
 certainly is for me.  Sadly the ruby-mysql gem works in such a way that the 
 difference between MRI and macruby breaks it.

 Steve

 On 18 Sep 2011, at 06:07, Watson wrote:

 Hi,

 Maybe related to http://www.macruby.org/trac/ticket/742.
 MacRuby ignore magic-comment, and uses default encoding UTF8.

 Thanks.

 2011/9/18 Steve Clarke st...@sclarkes.me.uk:
 Code
 

 ABC='ABC'
 puts ABC[0] encoding is #{ABC[0].encoding}
 puts ?\\xff encoding is #{?\xff.encoding}


 Output
 


 MRI output

 ABC[0] encoding is US-ASCII
 ?\xff encoding is ASCII-8BIT



 macruby output

 ABC[0] encoding is UTF-8
 ?\xff encoding is UTF-8


 The encodings reported above did not seem to be effected by the encoding of 
 the source file.  I tried both ASCII and UTF-8.

 When the same code is executed in (mac)irb the results are the same for 
 macirb as they are for macruby.
 irb for MRI however produces UTF-8 strings in both cases! This seemed very 
 odd but I'm fairly sure it's because I have an environment variable:
 LANG=GB.UTF-8
 When I changed to LANG=GB.US_ASCII irb for MRI rendered 'abc'[0] with 
 US_ASCII encoding. macirb still used UTF-8.

 (I discovered this when trying to get ruby-mysql to work with macruby.  It 
 doesn't work as-is but seems to work with a few mods that use 
 force_encoding to make MRI and macruby produce the same outputs).
 I abandoned my earlier attempts to use postgres with macruby via the pg 
 gem.  It failed regularly but in unpredictable ways associated, as far as I 
 could tell, with memory management problems.


 ___
 MacRuby-devel mailing list
 MacRuby-devel@lists.macosforge.org
 http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

 ___
 MacRuby-devel mailing list
 MacRuby-devel@lists.macosforge.org
 http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

 ___
 MacRuby-devel mailing list
 MacRuby-devel@lists.macosforge.org
 http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

___
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] linking an NSTextView with my AppDelegate

Hi Brice,

AFAIK, IB support in Xcode4 was broken for a long time but has been
fixed in the beta builds. Unless you can't use the beta,
http://www.macruby.org/trac/ticket/1322 contains a workaround.

Laurent

On Mon, Sep 12, 2011 at 9:37 PM, Brice Ruth bdr...@gmail.com wrote:
 Good afternoon -

 I saw a thread from August indicating that there was an issue with Xcode 4
 on Lion w/r/t linking in IB (matched exactly what I'm seeing). I went and
 grabbed the latest Xcode 3.x and installed it on Lion - I now have the old
 IB, but I still can't seem to see the attrs defined in my AppDelegate when I
 try to link the TextView. Not sure what I'm doing wrong ... would anyone
 mind stepping me through in a little more detail or pointing me to a more
 detailed walk through? I was using Xcode 4 on Snow Leopard and everything
 seemed to be working peachy ... I'm now on Lion, working on a new NSTextView
 and I can't get it to link to anything anymore.

 I saw one response indicating that you need to tell IB to read the files - I
 see a Read class files ... option in the menu - when I point that at my
 AppDelegate, I get an error dialog in IB, when I point it at main_rb, I
 don't get an error, but it still doesn't appear to work.

 I can't make heads or tails of the XML in the .xib, either - so no hope
 there.

 Much obliged,

 Brice Ruth, FCD
 Software Engineer, Madison WI

 ___
 MacRuby-devel mailing list
 MacRuby-devel@lists.macosforge.org
 http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel


___
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] Serialport IO and OS X Lion

Hi Robert

I guess it can be either a problem in MacRuby or a problem in Lion.
Can you share more details on this? Some system frameworks shipped
with GC regressions in Lion, maybe that's the problem here.

Laurent

On Sat, Aug 20, 2011 at 9:42 PM, Robert Rice rice.au...@pobox.com wrote:
 Hi devotees,

 I was using an Obj-C wrapper for serial port IO written by Paolo Bosetti but 
 I found that it no longer works in Lion. Does anyone know what might have 
 changed? Does MacRuby have a better solution for serial IO yet than using an 
 Obj-C wrapper?

 Thanks,
 Bob Rice

 ___
 MacRuby-devel mailing list
 MacRuby-devel@lists.macosforge.org
 http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

___
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] -twolevel_namespace issue?

Hi Jeremy,

Could the problem be fixed by linking statically your own copy of
SQLite against the Amalgalite library, and perhaps passing all SQLite
symbols to -unexported_symbols_list during ld time? I am guessing
symbols wouldn't collide anymore this way.

From what I understand, it looks like it would be better to fix the
problem in Amalgalite itself, and not in each client requiring it.

Laurent

On Mon, Sep 12, 2011 at 8:39 PM, Jeremy Hinegardner
jer...@hinegardner.org wrote:
Hey all,

I develop the Amalgalite gem[1] and it ships with its own copy of SQLite.
It does this as it adds in additional compile-time features, and I try and
keep it as current as posssible.

The problem is that since MacRuby is linked to CoreServices etc, the sqlite
library that ships with OSX gets linked at runtime before the sqlite library
that is built into the amalgalite gem extension. I've encountered this
before[2] with amalgalite, when it was loaded with my 'hitimes' gem (which on
osx links
against -framework CoreServes).

I am wondering what the appropriate approach is here. I was able to fix this
in
MRI by compiling MRI with -twolevel_namespace and I think there is an open
ticket
with ruby-core to see if MRI on osx should be compiled with that flag.

I attempted to compile MacRuby with -twolevel_namespace to resolve this, and I
was unsuccessful. There appeared to be other flags that conflicted with it.

I would expect something like this may also affect the nokogiri gem as limxml2
is also a system library on osx, and may conflict with the version that
nokogiri
expects.

Thoughts? Opinions? I'm sure this is a rare case, Amalgalite may be the only
project that could experience an issue like this. What is the best way to
handle
this in the MacRuby ecosystem?

enjoy,

-jeremy

[1] - https://github.com/copiousfreetime/amalgalite
[2] -
https://github.com/copiousfreetime/amalgalite/blob/master/lib/amalgalite/sqlite3/version.rb#L42-L56-54
--

Jeremy Hinegardner jer...@hinegardner.org

___
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] Invoking an obj-c method requiring a block

Hi Andy,

Blocks should work. Perhaps there is a problem with this very specific
API. Could you file a ticket? We will investigate.

Thanks
Laurent

On Sat, Aug 20, 2011 at 11:52 PM, Andy Park sohoc...@gmail.com wrote:
 I tried using blocks today, to no avail.

 This didn't work:
                NSNotificationCenter.defaultCenter.addObserverForName 
 kDocSetSelection
 Changed, object:nil, queue:nil, usingBlock:Proc.new{ |notification|
                        NSLog(notified)
                }

 But this did:
                NSNotificationCenter.defaultCenter.addObserver(self, selector: 
 handleM
 e:, name: kDocSetSelectionChanged, object: nil)

 I found http://www.macruby.org/trac/ticket/760 that hinted MacRuby does 
 impleme
 nt blocks, but also had references to BridgeSupport. I installed the preview-3
 version; what would be the reason the above didn't work?

 Thanks.

 ___
 MacRuby-devel mailing list
 MacRuby-devel@lists.macosforge.org
 http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

___
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] [ANN] Launch: MemoryCloud - Where memories live

A bit late to the party... but congratulations, it looks great, and
thanks for using MacRuby :-)

Laurent

On Thu, Sep 1, 2011 at 6:16 PM, Steven Buxton wantmyel...@me.com wrote:

 http://memorycloudapp.com - We built this 100% in MacRuby 0.10 and it was a
 blast to build.  Started building it in 0.6 and worked on it all the way to
 Lion and 0.10.  Never had 1 issue in app approval with it being macruby!
 About MemoryCloud --
 MemoryCloud stores your favorite photos and videos for you, allowing you to
 reclaim precious hard drive space.

 Not backup, not synchronization. MemoryCloud is simple and safe storage for
 the files that typically take up a lot of room.

 Here’s how it works: photos and videos occupy a lot of space on your Mac.
 With MemoryCloud, you just drag and drop these files to store them on
 the cloud; drag and drop again to retrieve. Smaller versions of the
 originals are kept on your hard drive so you can still view a favorite photo
 any time you want.

 Want to know what is being stored for you? MemoryCloud places a small
 watermark on your compressed files, so you instantly know what has
 been archived to the cloud.

 MemoryCloud provides a simple alternative to multiple CDs, memory cards and
 external storage devices, allowing you to carry smaller versions of your
 media with you. Finally, you don’t have to choose between cherished memories
 and hard drive space.

 MemoryCloud offers:

 * Safe storage utilizing Amazon’s state-of-the-art cloud technology.
 * A simple way to organize and access your favorite photos and videos.
 * Full compatibility with both iPhoto and iTunes.
 * The only cloud storage solution that also allows you to reclaim precious
 hard drive space.

 Thanks!
 Steven





 ___
 MacRuby-devel mailing list
 MacRuby-devel@lists.macosforge.org
 http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel


___
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] 0.11 schedule

2011-06-20 Thread Laurent Sansonetti

Agreed! I attached the 0.11-blocker keyword.

Thanks,
Laurent

On Mon, Jun 20, 2011 at 1:57 PM, Martin Schürrer mar...@schuerrer.org wrote:
 HI,

 shouldn't stuff like http://www.macruby.org/trac/ticket/505 be a blocker?

 (I'm new to macruby, so I'm curious)

 Cheers,
 Martin

 On Mon, Jun 20, 2011 at 22:20, Laurent Sansonetti
 laurent.sansone...@gmail.com wrote:
 Hi guys,

 A lot of good work has been integrated into master recently, so it's
 now time to think about making a new release (hopefully it will be the
 last 0.x release!).

 Here is a list of bugs I think are blockers to this release:

 http://www.macruby.org/trac/ticket/1286
 http://www.macruby.org/trac/ticket/1294
 http://www.macruby.org/trac/ticket/1308
 http://www.macruby.org/trac/ticket/1313
 http://www.macruby.org/trac/ticket/1329

 As always it is highly possible that I missed other blockers, so if
 you know about one please commit it, so that we can promote it with
 the 0.11-blocker keyword accordingly.

 Thanks!
 Laurent
 ___
 MacRuby-devel mailing list
 MacRuby-devel@lists.macosforge.org
 http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

 ___
 MacRuby-devel mailing list
 MacRuby-devel@lists.macosforge.org
 http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

___
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] 0.11 schedule

2011-06-20 Thread Laurent Sansonetti

Thanks Morgan.

Have you filed a ticket about this? If it's something that used to
work in past releases and doesn't anymore, then it's likely going to
be a blocker, as we want to avoid regressions.

Laurent

On Mon, Jun 20, 2011 at 3:43 PM, Morgan Schweers cyber...@gmail.com wrote:
 Greetings,
 I just yesterday ran into a problem with the head of MacRuby on GitHub that
 makes it not possible to use Mechanize/Nokogiri, specifically the
 redefinition of Node?
 I see this if I just go
 $ macirb
 irb require 'rubygems'
 irb require 'mechanize'
 It looks like a bundle gets loaded that tries to redefine Node, but...that
 doesn't work for some reason?  I'm not totally clear on what's going wrong,
 just that it was a show-stopper for me for moving to HEAD.  I'm not at home,
 where I was having this problem in spades until I downgraded to 0.10, but if
 you install the mechanize gem on a 0.11 version it pretty consistently fails
 to load.
 Since nokogiri and mechanize are pretty important to what I'm building, it's
 a bad place to be... :/
 --  Morgan
 On Mon, Jun 20, 2011 at 3:18 PM, Laurent Sansonetti
 laurent.sansone...@gmail.com wrote:

 Agreed! I attached the 0.11-blocker keyword.

 Thanks,
 Laurent

 On Mon, Jun 20, 2011 at 1:57 PM, Martin Schürrer mar...@schuerrer.org
 wrote:
  HI,
 
  shouldn't stuff like http://www.macruby.org/trac/ticket/505 be a
  blocker?
 
  (I'm new to macruby, so I'm curious)
 
  Cheers,
  Martin
 
  On Mon, Jun 20, 2011 at 22:20, Laurent Sansonetti
  laurent.sansone...@gmail.com wrote:
  Hi guys,
 
  A lot of good work has been integrated into master recently, so it's
  now time to think about making a new release (hopefully it will be the
  last 0.x release!).
 
  Here is a list of bugs I think are blockers to this release:
 
  http://www.macruby.org/trac/ticket/1286
  http://www.macruby.org/trac/ticket/1294
  http://www.macruby.org/trac/ticket/1308
  http://www.macruby.org/trac/ticket/1313
  http://www.macruby.org/trac/ticket/1329
 
  As always it is highly possible that I missed other blockers, so if
  you know about one please commit it, so that we can promote it with
  the 0.11-blocker keyword accordingly.
 
  Thanks!
  Laurent
  ___
  MacRuby-devel mailing list
  MacRuby-devel@lists.macosforge.org
  http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
 
  ___
  MacRuby-devel mailing list
  MacRuby-devel@lists.macosforge.org
  http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
 
 ___
 MacRuby-devel mailing list
 MacRuby-devel@lists.macosforge.org
 http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel


 ___
 MacRuby-devel mailing list
 MacRuby-devel@lists.macosforge.org
 http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel


___
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] 0.11 schedule

2011-06-20 Thread Laurent Sansonetti

It seems that the problem has already been reported:
http://www.macruby.org/trac/ticket/1335. It has also been tagged as a
blocker :)

Laurent

On Mon, Jun 20, 2011 at 5:51 PM, Morgan Schweers cyber...@gmail.com wrote:
 Greetings,
 I haven't filed a ticket yet; ran into it yesterday, and let myself get
 distracted by my kids, once I got to a stable state again. :)
 I'll reproduce it this evening and file a ticket with the output and what I
 can figure out.
 --  Morgan

 On Mon, Jun 20, 2011 at 3:54 PM, Laurent Sansonetti
 laurent.sansone...@gmail.com wrote:

 Thanks Morgan.

 Have you filed a ticket about this? If it's something that used to
 work in past releases and doesn't anymore, then it's likely going to
 be a blocker, as we want to avoid regressions.

 Laurent

 On Mon, Jun 20, 2011 at 3:43 PM, Morgan Schweers cyber...@gmail.com
 wrote:
  Greetings,
  I just yesterday ran into a problem with the head of MacRuby on GitHub
  that
  makes it not possible to use Mechanize/Nokogiri, specifically the
  redefinition of Node?
  I see this if I just go
  $ macirb
  irb require 'rubygems'
  irb require 'mechanize'
  It looks like a bundle gets loaded that tries to redefine Node,
  but...that
  doesn't work for some reason?  I'm not totally clear on what's going
  wrong,
  just that it was a show-stopper for me for moving to HEAD.  I'm not at
  home,
  where I was having this problem in spades until I downgraded to 0.10,
  but if
  you install the mechanize gem on a 0.11 version it pretty consistently
  fails
  to load.
  Since nokogiri and mechanize are pretty important to what I'm building,
  it's
  a bad place to be... :/
  --  Morgan
  On Mon, Jun 20, 2011 at 3:18 PM, Laurent Sansonetti
  laurent.sansone...@gmail.com wrote:
 
  Agreed! I attached the 0.11-blocker keyword.
 
  Thanks,
  Laurent
 
  On Mon, Jun 20, 2011 at 1:57 PM, Martin Schürrer mar...@schuerrer.org
  wrote:
   HI,
  
   shouldn't stuff like http://www.macruby.org/trac/ticket/505 be a
   blocker?
  
   (I'm new to macruby, so I'm curious)
  
   Cheers,
   Martin
  
   On Mon, Jun 20, 2011 at 22:20, Laurent Sansonetti
   laurent.sansone...@gmail.com wrote:
   Hi guys,
  
   A lot of good work has been integrated into master recently, so it's
   now time to think about making a new release (hopefully it will be
   the
   last 0.x release!).
  
   Here is a list of bugs I think are blockers to this release:
  
   http://www.macruby.org/trac/ticket/1286
   http://www.macruby.org/trac/ticket/1294
   http://www.macruby.org/trac/ticket/1308
   http://www.macruby.org/trac/ticket/1313
   http://www.macruby.org/trac/ticket/1329
  
   As always it is highly possible that I missed other blockers, so if
   you know about one please commit it, so that we can promote it with
   the 0.11-blocker keyword accordingly.
  
   Thanks!
   Laurent
   ___
   MacRuby-devel mailing list
   MacRuby-devel@lists.macosforge.org
   http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
  
   ___
   MacRuby-devel mailing list
   MacRuby-devel@lists.macosforge.org
   http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
  
  ___
  MacRuby-devel mailing list
  MacRuby-devel@lists.macosforge.org
  http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
 
 
  ___
  MacRuby-devel mailing list
  MacRuby-devel@lists.macosforge.org
  http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
 
 
 ___
 MacRuby-devel mailing list
 MacRuby-devel@lists.macosforge.org
 http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel


 ___
 MacRuby-devel mailing list
 MacRuby-devel@lists.macosforge.org
 http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel


___
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] Does everyone do this with their MacRuby apps?

2011-06-17 Thread Laurent Sansonetti

I think we need an official tutorial on the website on how to prepare an app 
for submission to the app store.

Is someone here interested in contributing to it?

Laurent

On Jun 17, 2011, at 12:34 AM, Andre Lewis wrote:

 I wrote the post at 
 http://redwoodapp.posterous.com/macruby-and-xcode-4-build-a-self-contained-ma,
  but I haven't submitted to the app store yet. The post was very much in the 
 just get it working spirit. If anyone has better steps, would love to see 
 them!
 
 Andre
 
 
 ___
 MacRuby-devel mailing list
 MacRuby-devel@lists.macosforge.org
 http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

___
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] Break in Block Fails only in Macruby

2011-05-25 Thread Laurent Sansonetti

Indeed.

$ ./miniruby -e require 'find'; p Find.find('.') { break 42 }
nil
$ ruby1.9 -e require 'find'; p Find.find('.') { break 42 }
42

Can you file a ticket?

Thanks,
Laurent

On May 25, 2011, at 1:23 PM, Shannon Love wrote:

 Greetings,
 
 If I run the following under the system ruby 1.8.7:
 
 require 'find'
 starting_directory=/Users/developer/Desktop/Top
 file_name_I_want_to_find=target_file.txt
 path=Find.find(starting_directory) {|p| break p if 
 p.include?(file_name_I_want_to_find) } 
 puts path = #{path}
 
 ... I get the expected output:
 
 path = /Users/developer/Desktop/Top/Lev_1-2/Lev_2.1/target_file.txt
 
 However, if I run it under Macruby I get nothing, just:
 
 path =
 
 I'm running MacRuby 0.10 (ruby 1.9.2) [universal-darwin10.0, x86_64] on 10.6.7
 
 Not sure what is going on. 
 
 Thanks,
 Shannon
 
 
 ___
 MacRuby-devel mailing list
 MacRuby-devel@lists.macosforge.org
 http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

___
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] Dynamic refresh in a view - xcode 4 / MacRuby

2011-05-25 Thread Laurent Sansonetti

Just one minor detail, the NSTimer callback method accepts an argument (which 
is a reference to the NSTimer object). So it should be:

  def drawWord(sender)
…
  end

If it works otherwise, then it's pure luck :)

Laurent
 
On May 24, 2011, at 10:50 PM, Thomas R. Koll wrote:

 Laurent is right and and I think best would be for you to use a NSTimer.
 
 def drawWord
  if !next_word
self.timer.invalidate
return
  end
  self.label.stringValue = next_word
  self.setNeedsDisplay true
 end
 
 def next_word
  ...
 end
 
 self.timer = NSTimer.scheduledTimerWithTimeInterval( 1/20.0,
  target:self, selector:drawWord:, userInfo:nil, repeats:true)
 
 
 
 Am 25.05.2011 um 02:06 schrieb az...@gmx.net:
 
 I have a label that I have set to blank, and after a user clicks 'go' I 
 generate a random word or number and use:
 
 self.label.stringValue = some_word
 
 to update the view.
 
 However, I would like to show 200 or so random words in quick succession 
 before the final one is shown - just because it's too plain at the moment. 
 Alternatively, I'd be happy with showing an animated graphic in its place - 
 which is replaced by the final random word after a few seconds.
 
 I've tried things like:
 
 100.times do
 num = rand(40)
 self.label.stringValue = num
 sleep 1
 end
 
 But it doesn't work. I've also (after googling) tried .reloadData but to no 
 avail as well.
 
 Any ideas on how to achieve this? Or pointers on how to add animations to my 
 window/views?
 
 
 --
 Thomas R. TomK32 Koll, Ruby/Rails freelancer
 http://ananasblau.com | http://github.com/TomK32
 
 
 
 
 ___
 MacRuby-devel mailing list
 MacRuby-devel@lists.macosforge.org
 http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

___
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] Constant definitions

2011-05-24 Thread Laurent Sansonetti

Hi Bob,

https://github.com/MacRuby/MacRuby/commit/68ac3fcaf1041ef9b25fb3bc940a47f41505b7e5
 happened. This fixes bugs but also introduces others. We have tickets covering 
the new bugs and Kouji-san is working on them. 

https://www.macruby.org/trac/ticket/1292
https://www.macruby.org/trac/ticket/1288
https://www.macruby.org/trac/ticket/1285

Laurent

On May 24, 2011, at 8:46 AM, Robert Rice wrote:

 Hi Fans:
 
 What changed on 5/19/2011?
 
 I haven't been able to use the nightly builds since 5/18/2011. Constant 
 definitions stopped working and I get an uninitialized constant xxx 
 (NameError) message wherever my code tries to reference a constant defined in 
 the same class.
 
 Thanks,
 Bob Rice
 
 ___
 MacRuby-devel mailing list
 MacRuby-devel@lists.macosforge.org
 http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

___
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] Dynamic refresh in a view - xcode 4 / MacRuby

2011-05-24 Thread Laurent Sansonetti

Hi,

It doesn't work because you're (probably) blocking the main thread,
which is responsible for drawing. What you want to do instead is
scheduling a timer inside the main run loop. Look at the NSTimer
class. Also, don't forget to force the view to be redrawn, by using
the setNeedsDisplay: method.

HTH
Laurent

On Tue, May 24, 2011 at 5:06 PM, az...@gmx.net az...@gmx.net wrote:
 I have a label that I have set to blank, and after a user clicks 'go' I 
 generate a random word or number and use:

 self.label.stringValue = some_word

 to update the view.

 However, I would like to show 200 or so random words in quick succession 
 before the final one is shown - just because it's too plain at the moment. 
 Alternatively, I'd be happy with showing an animated graphic in its place - 
 which is replaced by the final random word after a few seconds.

 I've tried things like:

 100.times do
  num = rand(40)
  self.label.stringValue = num
  sleep 1
 end

 But it doesn't work. I've also (after googling) tried .reloadData but to no 
 avail as well.

 Any ideas on how to achieve this? Or pointers on how to add animations to my 
 window/views?
 ___
 MacRuby-devel mailing list
 MacRuby-devel@lists.macosforge.org
 http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

___
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] MacRuby WWDC Meetup

2011-05-20 Thread Laurent Sansonetti

Hi Christian,

Awesome! Thanks for setting this up! 

I think we should wait one more day before advertising the link on twitter, to 
make sure subscribers of the mailing-list can RSVP before. I will post a link 
to the event tomorrow via @MacRuby.

Laurent

On May 20, 2011, at 10:08 AM, Christian Niles wrote:

 Hey Everyone!
 
 WWDC is getting close and I wanted to make sure the MacRuby community has a 
 chance to get together while everyone's in town. If you're going to be in 
 town and want to join us, please RSVP here:
 
   http://macrubymeetup.eventbrite.com/
 
 Right now I have Erik Michaels-Ober and Laurent Sansonetti on board to give 
 some brief presentations. If anyone else feels like presenting a topic or a 
 project, let me know.
 
 Also, please help out and publicize this event. Attendance is limited to 50 
 people, and it'd be nice to have a full house.
 
 christian.
 ___
 MacRuby-devel mailing list
 MacRuby-devel@lists.macosforge.org
 http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

___
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] MacRuby WWDC Meetup

2011-05-20 Thread Laurent Sansonetti

On May 20, 2011, at 1:03 PM, Christian Niles wrote:

 On May 20, 2011, at 12:21 PM, Laurent Sansonetti wrote:
 
 Hi Christian,
 
 Awesome! Thanks for setting this up! 
 
 I think we should wait one more day before advertising the link on twitter, 
 to make sure subscribers of the mailing-list can RSVP before. I will post a 
 link to the event tomorrow via @MacRuby.
 
 That sounds reasonable.
 
 BTW, Pivotal has a videographer reserved for the event, and asked if we would 
 like the presentations recorded and placed on their tech talks page:
 
   http://pivotallabs.com/talks
 
 Will you and/or Erik's presentations be formal-ish enough to make this 
 worthwhile, or should we pass on recording them?

I can't speak for Erik, but I'm not allowed to do any presentation. I can 
attend the meeting, discuss the project and answer questions though (like a 
BoF, which I thought was the plan here).

Laurent
___
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] macruby_deploy and nokogiri - LoadError on some mac

2011-05-18 Thread Laurent Sansonetti

Good catch!

It looks like we could improve macruby_deploy to warn (or die?) if of the 
embedded binaries link against something in /opt (or better, in anything but 
the default link paths). That would make sure this problem would not happen 
again.

Laurent

On May 18, 2011, at 9:06 AM, Eloy Duran wrote:

 Hi,
 
 It seems that the nokogiri gem that you are bundling has been compiled 
 against a iconv installation in /opt/local (macports|homebrew). Some users 
 probably have it as well which is why they wouldn't complain, but people with 
 a default osx installation don't. Here's what it does on my system, which 
 uses only default system libs:
 
 % otool -L 
 /Library/Frameworks/MacRuby.framework/Versions/0.11/usr/lib/ruby/Gems/1.9.2/gems/nokogiri-1.4.4/ext/nokogiri/nokogiri.bundle
 /Library/Frameworks/MacRuby.framework/Versions/0.11/usr/lib/ruby/Gems/1.9.2/gems/nokogiri-1.4.4/ext/nokogiri/nokogiri.bundle:
   
 /Library/Frameworks/MacRuby.framework/Versions/0.11/usr/lib/libmacruby.dylib 
 (compatibility version 0.11.0, current version 0.11.0)
   /usr/lib/libexslt.0.dylib (compatibility version 9.0.0, current version 
 9.13.0)
   /usr/lib/libxslt.1.dylib (compatibility version 3.0.0, current version 
 3.24.0)
   /usr/lib/libxml2.2.dylib (compatibility version 10.0.0, current version 
 10.3.0)
   /usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 
 7.0.0)
   /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current 
 version 125.2.10)
 
 As you can see, it references /usr/lib/libiconv.2.dylib, not 
 /opt/local/lib/libiconv.2.dylib. So it's probably best to only compile 
 against system versions.
 
 To make sure this doesn't happen in the future, you should always test your 
 app on clean installs of the system. It's pretty easy to keep a spare HD 
 around with multiple version installs from which you boot and test the whole 
 process.
 
 HTH
 
 On 18 mei 2011, at 17:24, Francis Chong wrote:
 
 Hi
 
 I tried to use macruby_deploy to embed my macruby based mac app with gems 
 (/usr/local/bin/macruby_deploy --compile --embed --gem nokogiri)
 
 The resulting app run fine on my machine. However, on many of our testers, 
 the app failed with LoadError. It seems nokogiri depends on a libiconv 
 with different version. (nokogiri.bundle requires version 8.0.0 or later, 
 but libiconv.2.dylib provides version 7.0.0)
 
 We cant ask our user to install each of those library. Are there any way I 
 can build the app embed the correct version of libiconv?
 
 Logs:
 
 dlopen(/Applications/ChineseIdiom.app/Contents/Frameworks/MacRuby.framework/Versions/0.10/usr/lib/ruby/site_ruby/1.9.2/nokogiri/nokogiri.bundle,
  9): Library not loaded: /opt/local/lib/libiconv.2.dylib
 18/05/2011 10:44:53 PM   
 [0x0-0x157b57a].hk.ignition.mac.ChineseIdiom[1576]Referenced from: 
 /Applications/ChineseIdiom.app/Contents/Frameworks/MacRuby.framework/Versions/0.10/usr/lib/ruby/site_ruby/1.9.2/nokogiri/nokogiri.bundle
 18/05/2011 10:44:53 PM   
 [0x0-0x157b57a].hk.ignition.mac.ChineseIdiom[1576]Reason: 
 Incompatible library version: nokogiri.bundle requires version 8.0.0 or 
 later, but libiconv.2.dylib provides version 7.0.0 - 
 /Applications/ChineseIdiom.app/Contents/Frameworks/MacRuby.framework/Versions/0.10/usr/lib/ruby/site_ruby/1.9.2/nokogiri/nokogiri.bundle
  (LoadError)
 18/05/2011 10:44:53 PM   
 [0x0-0x157b57a].hk.ignition.mac.ChineseIdiom[1576]  from 
 /Applications/ChineseIdiom.app/Contents/Resources/rb_main.rb:20:in `main'
 18/05/2011 10:44:53 PM   com.apple.launchd.peruser.501[191]  
 ([0x0-0x157b57a].hk.ignition.mac.ChineseIdiom[1576]) Exited with exit code: 1
 
 Thanks
 
 Francis Chong
 Ignition Soft
 http://ignition.hk
 ___
 MacRuby-devel mailing list
 MacRuby-devel@lists.macosforge.org
 http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
 
 ___
 MacRuby-devel mailing list
 MacRuby-devel@lists.macosforge.org
 http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

___
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] Syntax Coloring in XCode 4

2011-05-17 Thread Laurent Sansonetti

Hi Alec / Chris,

You may want to tell the Xcode team: http://bugreporter.apple.com

Laurent

On Mon, May 16, 2011 at 8:13 PM, Chris Rhoden carho...@gmail.com wrote:
 Hey Alec,
 This is something that's come up on the list previously; unfortunately, it's
 out of our hands. Apple needs to support it with the way that things are
 currently structured.
 Sorry, mate.

 On Mon, May 16, 2011 at 9:54 PM, Alec Sloman alec.slo...@gmail.com wrote:

 Hello,
 Had a rough introduction to the community a few weeks back, so I'd like to
 start with an apology: sorry for being a jerk. Twitter isn't the place to
 complain. Again, my bad, humble apologies.
 I have been working with MacRuby since then and am *VERY* enthusiastic.
 But there's one small thing that is driving me crazy - the syntax coloring
 in XCode 4. Currently it only picks out strings and numbers. Have I done
 something incorrectly when installing MacRuby, or is this to be expected? Is
 there anything I can do to improve this?
 Keep up the fantastic work!
 Regards,
 Alec
 ___
 MacRuby-devel mailing list
 MacRuby-devel@lists.macosforge.org
 http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel




 --
 chrisrhoden

 ___
 MacRuby-devel mailing list
 MacRuby-devel@lists.macosforge.org
 http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel


___
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] String#sub/gsub and text encodings

2011-05-16 Thread Laurent Sansonetti

Hi Caio,

On May 16, 2011, at 2:21 PM, Caio Chassot wrote:

 On 2011-05-16, at 00:37 , Laurent Sansonetti wrote:
 
 Filling dups is always a good idea as it helps up prioritizing work.
 
 Oh Laurent, please let's not encourage this terrible dupes-as-voting-system 
 practice; just add a +1 button to tickets.
 
 Filling proper tickets is hard work. Time shouldn't be spent on filing known 
 dupes. (Filing accidental dupes still preferred than not filing anything at 
 all for laziness of searching to check it's not a dupe)

Well I think it's quicker to file a dup than search through the entire database 
(using the awful Trac interface, but that's another topic), to then comment 
hey, me too!. And let's also consider false positives (people thinking this 
ticket describes their bug, when it doesn't).

I think it's a better idea to let the team triage the bugs, since they know 
about the big picture.

Laurent
___
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] Invoking a block in MacRuby, instantiated in Objective-C

2011-05-15 Thread Laurent Sansonetti

Hi Christian,

I think I only implemented Ruby - ObjC blocks support, not the other way 
around :) I didn't know Cocoa was exposing APIs returning ObjC blocks yet. 
Could you file a ticket? I will try to get that fixed in the upcoming release.

Thanks,
Laurent

On May 15, 2011, at 1:42 PM, Christian Niles wrote:

 Hey All,
 
 There's plenty of documentation showing how one can use Proc objects to 
 invoke Objective-C methods that accept block parameters, but I can't find any 
 way to invoke an Objective-C block from within a Ruby method.
 
 Without thinking I had assumed they'd be mapped to a Proc-like object, which 
 I could invoke with #call:
 
   def performOperation(operation, success:success_callback, 
 error:error_callback)
   # ...
   result = ...
   success_callback.call(result)
   end
 
 But I get an error: undefined method `call' for #__NSAutoBlock__:0x2006b6560
 
 christian.
 ___
 MacRuby-devel mailing list
 MacRuby-devel@lists.macosforge.org
 http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

___
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] String#sub/gsub and text encodings

2011-05-15 Thread Laurent Sansonetti

If the script works different in CRuby 1.9, then a ticket will be helpful too, 
as it is likely something we need to fix. I don't know by heart if it's a 
well-known issue, but we will figure it out later. Filling dups is always a 
good idea as it helps up prioritizing work.

Thanks,
Laurent

On May 15, 2011, at 8:10 AM, Caio Chassot wrote:

 Hi,
 
 Can you post some sample code?
 
 Thanks
 
 On Sun, May 15, 2011 at 11:50, Yasu Imao yimao...@gmail.com wrote:
 Hi,
 
 I just wrote a simple script for text processing and encountered a problem 
 with String#sub/gsub.
 
 Original text: UTF-8 encoded ASCII character only text
 Replacing text: UTF-8 encoded text with ASCII and non-ASCII characters 
 (including Japanese characters)
 
 The resulting text: all the non-ASCII characters were garbage.
 
 When I split the original text at the strings to be replaced and inserted 
 the replacing text at these places, the resulting string object was fine; 
 all the characters were kept as they should be in UTF-8 encoding.
 
 I checked the tickets, but couldn't find something like this.  Is this a 
 known issue?
 
 Best,
 Yasu
 ___
 MacRuby-devel mailing list
 MacRuby-devel@lists.macosforge.org
 http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
 
 ___
 MacRuby-devel mailing list
 MacRuby-devel@lists.macosforge.org
 http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

___
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] Unable to Upload Application to the App store

2011-05-06 Thread Laurent Sansonetti

Hi Daniel,

What version of MacRuby are you using? You may want to try a nightly build as 
it contains up to date fixes in the deployment tool.

Laurent

On May 6, 2011, at 12:06 PM, Daniel Westendorf wrote:

 Hi all,
 
 I'm running into some trouble uploading my application to the App store. I 
 have my main application target which validates fine when Archived. I have a 
 second target, which depends on the main target. This target uses 
 macruby_deploy with the arguments --compile --embed --gem sqlite3 --gem 
 sequel. When I go to validate this archive, I get the following:
 
 The binary is invalid. A symbolic link resolves to a file that doesn't exist. 
 Relative location: Thumper.app/Contents/Frameworks/MacRuby.framework/Headers
 The binary is invalid. A symbolic link resolves to a file that doesn't exist. 
 Relative location: Thumper.app/Contents/Frameworks/MacRuby.framework/MacRuby
 The binary is invalid. A symbolic link resolves to a file that doesn't exist. 
 Relative location: Thumper.app/Contents/Frameworks/MacRuby.framework/Resources
 The binary is invalid. A symbolic link resolves to a file that doesn't exist. 
 Relative location: 
 Thumper.app/Contents/Frameworks/MacRuby.framework/Versions/0.10/Headers
 
 When I take the .app to a fresh install of 10.6 w/o Macruby installed, it 
 runs fine. I'm confused as to where to go from here. Does anyone have any 
 advice?
 
 Thanks!
 
 Daniel
 ___
 MacRuby-devel mailing list
 MacRuby-devel@lists.macosforge.org
 http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

___
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] handlers and carets

2011-05-06 Thread Laurent Sansonetti

Hi Pavlos,

You simply pass a Proc object. 

handler = Proc.new do |result|
if result == …
...
end
oPanel.beginSheetModalForWindow self.window, completionHandler: handler 

Make sure you installed the latest BridgeSupport preview before, available from 
http://www.macruby.org/files.

Laurent

On May 6, 2011, at 5:38 PM, Pavlos Vinieratos wrote:

 hello. how can I write this in macruby?
 [oPanel beginSheetModalForWindow:[self window]
 
 completionHandler:^(NSInteger result) {
 
 if (result == NSFileHandlingPanelOKButton) {
 
 for (NSURL *fileURL in [oPanel URLs]) {
 
 // do something with fileURL
 
 }
 
 }
 
 }];
 
 the second arg is a handler..
 
 thank you
 
 -- 
 Pavlos Vinieratos
 ___
 MacRuby-devel mailing list
 MacRuby-devel@lists.macosforge.org
 http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

___
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] hpricot and macruby?

2011-05-04 Thread Laurent Sansonetti

Hi Daniel,

I think the master branch is able to run hpricot, although I recommend using 
NSXMLDocument.

Laurent

On May 4, 2011, at 12:56 PM, macr...@djc.net wrote:

 With:
 MacRuby 0.10 (ruby 1.9.2) [universal-darwin10.0, x86_64]
 and having done successfully:
 macgem install hpricot ...
 
 I get this when trying to use the actual gem:
 
 dyld: lazy symbol binding failed: Symbol not found: _rb_enc_to_index
  Referenced from: 
 /Library/Frameworks/MacRuby.framework/Versions/0.10/usr/lib/ruby/Gems/1.9.2/gems/hpricot-0.8.4/lib/fast_xs.bundle
  Expected in: flat namespace
 
 is this a hpricot or macruby issue?
 Any tips appreciated ... or do I give up, and attempt to convert this old 
 script  to use: NSXMLDocument ?
 (ruby 1.8.7 is core dumping, having its own problems, so I am hoping MacRuby 
 is up to the task...)
 
 -Daniel
 
 ___
 MacRuby-devel mailing list
 MacRuby-devel@lists.macosforge.org
 http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

___
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] Failure with outlineView data source

2011-04-30 Thread Laurent Sansonetti

Hi Malcolm,

Have you tried removing the #to_s call in the
outlineView:objectValueForTableColumn:byItem: method? An important
thing to keep in mind when writing an outline view data source is to
always return the same object reference for an item, not copies. The
references must also be unique.

Laurent

On Sat, Apr 30, 2011 at 4:07 PM, Malcolm F malc...@gmail.com wrote:
 I'm getting crashes using an outlineView data source fed by an array of 
 numbers. The crash happens after fiddling around in the view, usually after 
 some variable small delay. Upon crash, the debugger is always stopped in 
 'class_getSuperclass'.

 The crash only happens using Integers or Floats over 12.

 I've simplified it down to this sparse MyDocument class that can be put into 
 a document-based app. Put an outline view into MyDocument.xib and connect the 
 datasource delegate to MyDocument.

 I'm new at this, so if an experienced MacRubyist can show me what I'm doing 
 wrong, I will be very grateful.
 thanks, m

 code snippet start
 class MyDocument  NSDocument
  attr_accessor :dataSourceArray

  def init
    super
    if (self != nil)
      # Add your subclass-specific initialization here.
      # If an error occurs here, return nil.
    end
    self
  end

  def awakeFromNib
    #@dataSourceArray = [1,2,3,4,5,6,7,8,9,10,11,12] #survives
    @dataSourceArray = [1,2,3,4,5,6,7,8,9,10,11,12,13] #crashes, anything over 
 12

    #@dataSourceArray = [0.to_i,8.to_i,116.to_i,224.to_i,400.to_i,1000.to_i] 
 #crashes
    #@dataSourceArray = 13.0 #float also crashes
    #@dataSourceArray = [10]  #survives
    #@dataSourceArray = [99] #crashes
    #@dataSourceArray = 99 #crashes
    #@dataSourceArray = 9 #survives
    #@dataSourceArray = [NSNumber.numberWithInt(99)] #crashes
    #@dataSourceArray = Array.new [117] #crashes
    #@dataSourceArray = [1,2,3,4,[5,6],7,8,9,0] #survives
    #@dataSourceArray = [0,8,116,224,400,1000] #crashes
    #@dataSourceArray = [0.to_s,8.to_s,116.to_s,224.to_s,400.to_s,1000.to_s] 
 #survives
    #@dataSourceArray = 
 [:zero,:eight,:onesixteen,:twotwentyfour,:fourhundred,:hundredyoh] #survives
  end

  def windowNibName
   MyDocument
  end

  ## DataSource for OV ###
  def outlineView(outlineView, numberOfChildrenOfItem:item)
    if item.is_a? Array
      return item.count
    end
    1
  end
  def outlineView(outlineView, isItemExpandable:item)
    (item == nil) || ((item.is_a? Array)  (item.count  0))
  end
  def outlineView(outlineView, child:index, ofItem:item)
    #returns child item objects
    if item == nil
      return @dataSourceArray #root item
    end
    if item.is_a? Array
      return item[index]
    end
    return nil
  end
  def outlineView(outlineView, objectValueForTableColumn:tableColumn, 
 byItem:item)
    # returns the object represented by the column at this item
    item.to_s
  end

 end

 code snippet end
 ___
 MacRuby-devel mailing list
 MacRuby-devel@lists.macosforge.org
 http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

___
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] Sqlite3 without core data

2011-04-28 Thread Laurent Sansonetti

Hi Petr,

Have you tried using `macruby_deploy --embed --gem ...' instead of
vendoring the gems by yourself? It should work out of the box, and you
do not need to change LOAD_PATH.

Laurent

On Thu, Apr 28, 2011 at 1:16 AM, Petr Kaleta petr.kal...@me.com wrote:
 Thanks for this hint, this lib looks great. Problem is, that I can't make it 
 work. I am loading all gems from vendor folder inside my app. So:

 $LOAD_PATH.unshift(File.join(File.dirname(__FILE__), 
 'vendor/sqlite3-ruby/lib'))
 $LOAD_PATH.unshift(File.join(File.dirname(__FILE__), 'vendor/sequel/lib'))

 require 'sqlite3'
 require 'sequel'

 But the problem is, that when loading sqlite3 it raises this error:

 `loadExternalLibraries': no such file to load -- sqlite3/sqlite3_native 
 (LoadError)

 Which looks really strange... Hints?

 - Petr

 On Apr 18, 2011, at 8:00 PM, Joe West wrote:

 On Mon, Apr 18, 2011 at 7:47 AM, Rolando Abarca
 rola...@gamesforfood.com wrote:
 try sequel: http://sequel.rubyforge.org/


 +1 for Sequel
 ___
 MacRuby-devel mailing list
 MacRuby-devel@lists.macosforge.org
 http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

 ___
 MacRuby-devel mailing list
 MacRuby-devel@lists.macosforge.org
 http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

___
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] BridgeSupport crash

2011-04-17 Thread Laurent Sansonetti

On Apr 16, 2011, at 2:30 PM, Nathaniel Talbott wrote:

 On Sat, Apr 16, 2011 at 2:34 PM, Nathaniel Talbott
 nathan...@spreedly.com wrote:
 
 Excellent! Can't wait to see your commit, since I've been playing with
 a fix and am curious if I'm even looking in the right place :-)
 
 Attached is my hacky patch; my sample app works if I build with it
 (going to move on to getting my app out next!). Can't wait to see
 Laurent's solution - mine feels sub-optimal.


Your patch is a good workaround for you but cannot be included, as it's not 
going to work as expected if the user uses macruby_deploy --bs on a system 
where BridgeSupport preview has not been installed.

I committed a fix that should work in all cases: we now parse the BridgeSupport 
file version number and propagate it to MacRuby core, which will accordingly 
load the hacks.

https://github.com/MacRuby/MacRuby/commit/eedc8a3b28adc6933087e3b2694e2a1d902bd1ec

Let me know if it works for you. I just wrote that patch and haven't got the 
time to fully test it yet.

Once BridgeSupport preview ships with a version of Mac OS X, it will be time to 
finally get rid of the hacks :)

Laurent
___
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] BridgeSupport crash

2011-04-17 Thread Laurent Sansonetti

On Apr 16, 2011, at 11:34 AM, Nathaniel Talbott wrote:
 In the meantime, is there any simple workaround for 0.10? Would love
 to get this app shipped in working form to my alpha testers
 post-haste.

Sadly no, but either your patch or embedding the master branch of MacRuby 
should work. At this point we only commit bug fixes to the master branch, it's 
very stable and always better than the last released version, so you may want 
to consider embedding it. 

Laurent
___
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] macruby_deploy --embed bug

2011-04-17 Thread Laurent Sansonetti

On Apr 17, 2011, at 2:18 PM, Nathaniel Talbott wrote:

 On Sun, Apr 17, 2011 at 12:07 PM, Nathaniel Talbott
 nathan...@talbott.ws wrote:
 
 Tonight I'll be able to submit a reproduction of the issue (have to
 run out now) but in the meantime, any ideas as to what the cause might
 be?
 
 After doing a bit of poking around and failing to find the root of the
 problem, I decided to just fix up $LOAD_PATH by adding the following
 at the top of rb_main.rb:

[…]

Thanks for finding this also! It looks like the recent change to macruby_deploy 
in order to conform to new AppStore submissions broke the load path relocation. 
I corrected the problem in 
https://github.com/MacRuby/MacRuby/commit/f024e510389140e090aa3404ed18744fc6986ef6

MacRuby core has a very intensive test suite, but sadly we don't have any test 
for macruby_deploy yet. Maybe we should consider writing some at some point to 
avoid this kind of regressions.

Laurent
___
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] BridgeSupport crash

2011-04-16 Thread Laurent Sansonetti

On Apr 16, 2011, at 6:52 AM, Nathaniel Talbott wrote:

 On Sat, Apr 16, 2011 at 9:29 AM, Nathaniel Talbott nathan...@talbott.ws 
 wrote:
 
 I have not tried to get it to crash on my development box (though I'll
 probably attempt that next); perhaps the difference is running it on a
 box that truly has never had the new BridgeSupport installed?
 
 OK, running on this hunch, I got it to crash on my local dev box.
 Reproduction is trivial: simply remove or rename
 /System/Library/BridgeSupport/ruby-1.8/bridgesupportparser.bundle.
 This file, which is added by the preview3 BridgeSupport installer,
 seems to be at the root of the issue. Apparently it's required for
 some reason if the BridgeSupport files are embedded within an app.

Thanks a lot for finding this, I now know exactly what the problem is :) I will 
commit a fix shortly.

Laurent
___
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] BridgeSupport crash

2011-04-15 Thread Laurent Sansonetti

Hi Nathaniel,

This is likely the same problem as http://www.macruby.org/trac/ticket/1217. 
I'll have a look, hopefully I should be able to get a fix this week-end.

Laurent

On Apr 15, 2011, at 8:58 AM, Nathaniel Talbott wrote:

 I have a MacRuby app that's working great on my local box, but when I
 put it on another box it crashes hard. Here's the relevant thread
 crash info:
 
 Exception Type:  EXC_BAD_ACCESS (SIGSEGV)
 Exception Codes: KERN_INVALID_ADDRESS at 0x
 Crashed Thread:  0  Dispatch queue: com.apple.main-thread
 
 Thread 0 Crashed:  Dispatch queue: com.apple.main-thread
 0   libmacruby.1.9.2.dylib0x00010010c4b1
 rb_vm_resolve_const_value + 1537
 1   libmacruby.1.9.2.dylib0x0001000f52f6
 rb_objc_load_loaded_frameworks_bridgesupport + 374
 2   libmacruby.1.9.2.dylib0x000100157f0a macruby_main + 362
 3   com.terralien.Elephant0x0001142f 0x1 + 5167
 4   com.terralien.Elephant0x000113f4 0x1 + 5108
 
 The app runs fine on my own box, and the only difference I can figure
 between them is that I've installed BridgeSupport preview3, but the
 box it's crashing on hasn't. I'm doing a macruby_deploy --bs and have
 verified that the BridgeSupport files are being copied into the right
 spot in the .app file.
 
 Any ideas what might be wrong and/or how I can debug further?
 
 
 -- 
 Nathaniel Talbott
 :((
 ___
 MacRuby-devel mailing list
 MacRuby-devel@lists.macosforge.org
 http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

___
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] BridgeSupport crash

2011-04-15 Thread Laurent Sansonetti

I can't seem to be able to reproduce the crash. I built a sample MacRuby 
project (DotView), ran macruby_deploy --bs --embed on it, verified that both 
MacRuby.framework and the BridgeSupport files were included, then I renamed all 
BridgeSupport directories on my system (to make sure MacRuby won't load them), 
ran the app through gdb, and verified that the BridgeSupport files were loaded 
from inside the app bundle (and also, that the app ran fine without crashing).

Looking at your backtrace, it seems that MacRuby is crashing when loading the 
BridgeSupport of a framework that you embedded in your app. Do you have any 
framework (other than MacRuby) inside your app? If yes, did you generate a 
BridgeSupport file for it?

Also, it would be interesting if you could reduce the problem to a sample .app 
that you can give me.

Laurent

On Apr 15, 2011, at 8:16 PM, Laurent Sansonetti wrote:

 Hi Nathaniel,
 
 This is likely the same problem as http://www.macruby.org/trac/ticket/1217. 
 I'll have a look, hopefully I should be able to get a fix this week-end.
 
 Laurent
 
 On Apr 15, 2011, at 8:58 AM, Nathaniel Talbott wrote:
 
 I have a MacRuby app that's working great on my local box, but when I
 put it on another box it crashes hard. Here's the relevant thread
 crash info:
 
 Exception Type:  EXC_BAD_ACCESS (SIGSEGV)
 Exception Codes: KERN_INVALID_ADDRESS at 0x
 Crashed Thread:  0  Dispatch queue: com.apple.main-thread
 
 Thread 0 Crashed:  Dispatch queue: com.apple.main-thread
 0   libmacruby.1.9.2.dylib   0x00010010c4b1
 rb_vm_resolve_const_value + 1537
 1   libmacruby.1.9.2.dylib   0x0001000f52f6
 rb_objc_load_loaded_frameworks_bridgesupport + 374
 2   libmacruby.1.9.2.dylib   0x000100157f0a macruby_main + 362
 3   com.terralien.Elephant   0x0001142f 0x1 + 5167
 4   com.terralien.Elephant   0x000113f4 0x1 + 5108
 
 The app runs fine on my own box, and the only difference I can figure
 between them is that I've installed BridgeSupport preview3, but the
 box it's crashing on hasn't. I'm doing a macruby_deploy --bs and have
 verified that the BridgeSupport files are being copied into the right
 spot in the .app file.
 
 Any ideas what might be wrong and/or how I can debug further?
 
 
 -- 
 Nathaniel Talbott
 :((
 ___
 MacRuby-devel mailing list
 MacRuby-devel@lists.macosforge.org
 http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
 
 ___
 MacRuby-devel mailing list
 MacRuby-devel@lists.macosforge.org
 http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

___
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] WWDC ?

2011-04-07 Thread Laurent Sansonetti

On Apr 6, 2011, at 10:10 PM, Rich Morin wrote:

 At 6:34 PM -0700 4/6/11, Laurent Sansonetti wrote:
 (Sorry for the late reply!)
 
 I would be glad to attend any MacRuby meetup during WWDC,
 and reply to any question and discuss MacRuby's current
 state and future.
 
 Rich, if you still desire to organize something, please
 go ahead.  Last year I tried to organize something but
 it was a failure, too many people came and I wasn't able
 to find a good place.  Let's hope it will work out better
 this year :)
 
 Unfortunately, I can't find any schedule information for
 the evenings of June 6-9.  So, I'm not in a good position
 to suggest a date.  Would some folks that are attending
 please let me know which evenings/times to avoid?

Maybe we should make a quick poll (here + twitter)? I think the biggest 
challenge here would be to find the venue.

Laurent
___
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] WWDC ?

2011-04-07 Thread Laurent Sansonetti

Hi Christian,

According to https://www.macruby.org/trac/wiki/MacRubyWWDC09, about 20, but I 
remember there were many more people coming that night (maybe 2x more). And 
MacRuby is way more popular this year. I think that if the meetup is properly 
advertised, at least 50 people will come.

Laurent

On Apr 7, 2011, at 12:01 PM, Christian Niles wrote:

 Hey Laurent,
 
 How many people came last year? I can start asking around and see if any 
 local companies have the space to host a meetup.
 
 christian.
 
 On Apr 6, 2011, at 6:34 PM, Laurent Sansonetti wrote:
 
 (Sorry for the late reply!)
 
 I would be glad to attend any MacRuby meetup during WWDC, and reply to any 
 question and discuss MacRuby's current state and future. 
 
 Rich, if you still desire to organize something, please go ahead. Last year 
 I tried to organize something but it was a failure, too many people came and 
 I wasn't able to find a good place. Let's hope it will work out better this 
 year :)
 
 Cheers,
 Laurent
 
 On Mar 30, 2011, at 7:31 PM, Rich Morin wrote:
 
 Looking at http://www.sfruby.info/#upcoming, I don't
 see anything scheduled during WWDC (June 6-10).  If
 the WWDC attendees in the crowd can settle on a date
 (ideally, one that works for Jordan and Laurent :-),
 I'll be happy to put in the schedule.
 
 I can probably also find a venue for the event; let
 me know if this is an issue...
 
 -r
 -- 
 http://www.cfcl.com/rdmRich Morin
 http://www.cfcl.com/rdm/resume r...@cfcl.com
 http://www.cfcl.com/rdm/weblog +1 650-873-7841
 
 Software system design, development, and documentation
 ___
 MacRuby-devel mailing list
 MacRuby-devel@lists.macosforge.org
 http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
 
 ___
 MacRuby-devel mailing list
 MacRuby-devel@lists.macosforge.org
 http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
 
 ___
 MacRuby-devel mailing list
 MacRuby-devel@lists.macosforge.org
 http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

___
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] I want to talk about MacRuby support of Lion.

2011-04-07 Thread Laurent Sansonetti

Hi Kouji,

We can continue this conversation privately (off-list). I dropped you an e-mail.

Laurent

On Apr 7, 2011, at 7:49 PM, Takao Kouji wrote:

 Hi,
 
 I have joined the Mac Developer Program.
 I am compiling and testing MacRuby on Mac OS X Lion Preview 2.
 I am using CruiseControl.rb to compile and test MacRuby.
 
 I want to talk about MacRuby support of Lion
 (especially icu-1060 directory and auto_zone_1060.h file) with somebody.
 I think that I can talk if there is it between people joined Mac Developer 
 Program.
 
 Thanks Kouji.
 
 ---
 TAKAO Kouji ko...@takao7.net
 blog: http://d.hatena.ne.jp/kouji0625/
 twitter: takaokouji / projects: ruby, s7-seven
 
 ___
 MacRuby-devel mailing list
 MacRuby-devel@lists.macosforge.org
 http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

___
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] WWDC ?

2011-04-06 Thread Laurent Sansonetti

(Sorry for the late reply!)

I would be glad to attend any MacRuby meetup during WWDC, and reply to any 
question and discuss MacRuby's current state and future. 

Rich, if you still desire to organize something, please go ahead. Last year I 
tried to organize something but it was a failure, too many people came and I 
wasn't able to find a good place. Let's hope it will work out better this year 
:)

Cheers,
Laurent

On Mar 30, 2011, at 7:31 PM, Rich Morin wrote:

 Looking at http://www.sfruby.info/#upcoming, I don't
 see anything scheduled during WWDC (June 6-10).  If
 the WWDC attendees in the crowd can settle on a date
 (ideally, one that works for Jordan and Laurent :-),
 I'll be happy to put in the schedule.
 
 I can probably also find a venue for the event; let
 me know if this is an issue...
 
 -r
 -- 
 http://www.cfcl.com/rdmRich Morin
 http://www.cfcl.com/rdm/resume r...@cfcl.com
 http://www.cfcl.com/rdm/weblog +1 650-873-7841
 
 Software system design, development, and documentation
 ___
 MacRuby-devel mailing list
 MacRuby-devel@lists.macosforge.org
 http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

___
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] Tyro Needs Ruby vs. O-C Advice

2011-04-06 Thread Laurent Sansonetti

Hi Bryan,

I see that many people responded to that thread, but I would like to still add 
the following points:

1) MacRuby can't be used for iOS programming at this time.

2) In order to fully program in Objective-C, you must know C first. If you're a 
seasoned C programmer, picking Objective-C should just take a couple days 
(maximum). Otherwise, you will have to learn C before, which can be 
challenging, especially if you come from PHP. Ruby, the language MacRuby 
implements, is _much_ easier to learn. Using Cocoa from MacRuby does not 
require you to master Objective-C, you basically just need to learn about 
Objective-C classes and methods and how to use them in Ruby, then you can spend 
the rest of your time learning the Cocoa APIs. There is plenty of documentation 
available, including 2 books (currently being written) on this very specific 
topic :)

HTH,
Laurent

On Mar 30, 2011, at 8:43 PM, Bryan Harrison wrote:

 I've decided to use an upcoming sabbatical to teach myself OS X and iOS 
 programming.  My background includes OS X systems administration and web 
 development, mostly using the Apache/MySQL/PHP model.  I'm familiar with OOP 
 concepts and have trifled with any number of languages from C to AppleScript, 
 but am not fluent in any object oriented language.  I've been exploring Xcode 
 4 for a week and feel conversant with the IDE if not yet able to accomplish 
 anything with it.
 
 So…  I understand that Cocoa is a given, but today's million dollar question 
 is Objective-C or MacRuby?  I'm a blank slate with regard to both and so 
 could use some good advice.  For example…
 
 What are the advantages of MacRuby over Objective-C?
 
 What are the advantage of O-C over Ruby?
 
 Is Xcode's support for O-C significantly better than it's handling of Ruby?  
 Do I care?
 
 At this point I'm primarily interested in OS X development, but iOS clearly 
 needs to run a close second.  What's the current status of Ruby development 
 for iOS and is it likely to go anywhere in the nearish future?
 
 Any thoughts on the longer-term prospects of either language?
 
 Any thoughts from anybody will be much appreciated.
 
 Thanks,
 Bryan
 ___
 MacRuby-devel mailing list
 MacRuby-devel@lists.macosforge.org
 http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

___
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] Moving to GitHub!

2011-03-28 Thread Laurent Sansonetti

The move is now complete! I wrote a small message on the blog: 
http://www.macruby.org/blog/2011/03/26/github.html

Now let's continue fixing 1.0 bugs :)

Laurent

On Mar 25, 2011, at 9:30 PM, Laurent Sansonetti wrote:

 Hi guys,
 
 We finally decided to move MacRuby's source code repository from subversion 
 to Git, and GitHub seems to be the best place to do it. 
 
 The move will happen somewhere this week-end, or Monday. The repository 
 address will be: https://github.com/MacRuby/MacRuby. Currently, this 
 repository is a mirror of the subversion one.
 
 Here is how we will proceed:
 
 1) Add frequent contributors to the GitHub repository. [Done]
 2) Update the nightly build process to use the GitHub repository. [Done]
 3) Stop the GitHub repository mirroring.
 4) Empty the trunk branch of the subversion repository, and just keep a text 
 file saying that we moved to GitHub.
 5) Refresh the website.
 
 Once this is done, frequent contributors can commit to the central repository 
 on GitHub, and MacRuby's development can continue. We will keep the rest of 
 the infrastructure (such as Trac for managing the tickets), only the source 
 code repository moves.
 
 If you have any suggestion or concern let us know. Also, it's possible that I 
 forgot a step or two, as I'm writing this under the influence of a few 
 guinness :) Hopefully Eloy or Matt will correct me.
 
 Thanks!
 Laurent
 ___
 MacRuby-devel mailing list
 MacRuby-devel@lists.macosforge.org
 http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

___
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

[MacRuby-devel] Moving to GitHub!

2011-03-25 Thread Laurent Sansonetti

Hi guys,

We finally decided to move MacRuby's source code repository from subversion to 
Git, and GitHub seems to be the best place to do it. 

The move will happen somewhere this week-end, or Monday. The repository address 
will be: https://github.com/MacRuby/MacRuby. Currently, this repository is a 
mirror of the subversion one.

Here is how we will proceed:

1) Add frequent contributors to the GitHub repository. [Done]
2) Update the nightly build process to use the GitHub repository. [Done]
3) Stop the GitHub repository mirroring.
4) Empty the trunk branch of the subversion repository, and just keep a text 
file saying that we moved to GitHub.
5) Refresh the website.

Once this is done, frequent contributors can commit to the central repository 
on GitHub, and MacRuby's development can continue. We will keep the rest of the 
infrastructure (such as Trac for managing the tickets), only the source code 
repository moves.

If you have any suggestion or concern let us know. Also, it's possible that I 
forgot a step or two, as I'm writing this under the influence of a few guinness 
:) Hopefully Eloy or Matt will correct me.

Thanks!
Laurent
___
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] Proposal: splitting macrubyc UI from logic

Hi Mark,

Sorry for the late reply.

Could you file at ticket and add a link to the changes on github? I will look 
into this once we release 0.10.

Thanks!
Laurent

On Mar 14, 2011, at 6:58 PM, Mark Rada wrote:

 On 2011-03-14, at 16:05, Laurent Sansonetti lsansone...@apple.com wrote:
 
 Hi Mark,
 
 As macrubyc's compilation logic is essentially spawning several command-line 
 tools, I wonder if calling the logic directly from macruby_deploy is going 
 to bring significant advantages, vs the complexity of splitting macrubyc.
 
 
 The splitting macrubyc was a low hanging fruit; macrubyc was almost split 
 already, so few changes were introduced. I don't think I introduced much 
 complexity, and in turn some clutter was separated from the initialization 
 process:
 
 - calls to #die were replaced with calls to #raise
 - the option parser was moved out of the compiler class, now 
 Compiler#initialize takes a hash of options and just unpacks it
 - most of the extra tool lookups (#locate) were moved to constants so they 
 only have to be looked up once
 
 I think a better strategy would be to optimize what's slow in macrubyc (such 
 as command-line options parsing),
 
 I don't think it's the command line parsing, I thinks it's the spawning of 
 new MacRuby processes which will have to JIT the compiler logic over and over 
 again for each file. 
 
 But I guess a lot of that can be mitigated by compiling the compiler when it 
 becomes possible. 
 
 and better include the compilation strategy into Xcode (if possible).
 
 
 That does sound like a much better idea for macruby_deploy. 
 
 However, I am rarely using Xcode to work with MacRuby, and there are other 
 places where calling the compiler directly will have benefit, such as a rake 
 task or during gem installation. Perhaps I am speaking for a minority in 
 these two cases
 
 Sent from my iDevice
 
 Laurent
 
 On Mar 12, 2011, at 5:40 PM, Mark Rada wrote:
 
 Hi,
 
 I have completed a proof of concept patch for MacRuby where I have split 
 the UI of macrubyc from the underlying logic so that tools like 
 macruby_deploy can make use of the compiler without having to spawn a new 
 macruby process for each file that needs to be compiled. This should also 
 be beneficial for compiling gems and the standard library.
 
 After having made this patch, I realized that there are still several 
 places in the compiler where a new process is spawned to perform part of 
 the compilation. I'm not really sure how much else can be lib-ified from 
 the other required components. Overall there are still a few places that I 
 know I can optimize without much work needed.
 
 Right now, compile time for ruby files with about 100-200 lines of code is 
 about 1(+/-0.1) seconds on my MBP. Spawning a new macruby process and 
 processing the macrubyc options takes about 0.25 seconds; so I think the 
 patch is still useful in the general case.
 
 The code for the changes is located in my MacRuby fork on github: 
 https://github.com/ferrous26/MacRuby/tree/libify-rubyc
 
 Mark Rada
 mr...@marketcircle.com
 
 ___
 MacRuby-devel mailing list
 MacRuby-devel@lists.macosforge.org
 http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
 
 ___
 MacRuby-devel mailing list
 MacRuby-devel@lists.macosforge.org
 http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
 
 ___
 MacRuby-devel mailing list
 MacRuby-devel@lists.macosforge.org
 http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

___
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] Why the MacRuby does not implement cref?

Hi Kouji,

I think that you're looking for the current_class variable of RoxorVM and the 
rb_vm_outer_t structure. That's how const lookup is implemented in MacRuby, 
basically.

It is possible that the current implementation is not good enough in order to 
fix these issues and that a solution like CRuby should be implemented. But so 
far, every const lookup bug was able to be fixed.

Laurent

On Mar 22, 2011, at 1:37 AM, Takao Kouji wrote:

 Hi,
 
 I'm trying to fix issues below.
 
 - #619: Constant scope in a block is determined at run-time?
 - #828: A NameError, raised from evalling, gets the wrong constant name.
 - #1095: Segfault on uninitialized constant in Rspec2 test
 - #1167: NameError: uninitialized constant Hpricot::Container::Trav::Traverse
 - #1192: Did not find nested constants.
 
 But, I could not find like cRuby's cref variable in compiler.cpp.
 
 I am wondering why the MacRuby does not implement cref?
 Also, I am thinking about implementing cref myself.
 I wonder if anyone would be opposed to this?
 
 Thanks Kouji.
 
 ---
 TAKAO Kouji ko...@takao7.net
 blog: http://d.hatena.ne.jp/kouji0625/
 twitter: takaokouji / projects: ruby, s7-seven
 
 ___
 MacRuby-devel mailing list
 MacRuby-devel@lists.macosforge.org
 http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

___
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

[MacRuby-devel] 0.10 - update

Hi guys,

As the Xcode4 templates seem to be functional, I just branched trunk for the 
0.10 release. I will do more testing and hopefully, 0.10 should be released 
either tonight or tomorrow!

Development continues in trunk, which is now using the 0.11 version number.

Laurent
___
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] 0.10 - update

Here are the release notes.

Highlights:

- Support for the new MacBook Pro hardware (SandyBridge processors).
- Fixes in macruby_deploy for App Store submissions.
- Xcode4 support.
- Minor stability fixes.

Changes:

- Fixed a bug where we would crash when protecting an internal call during an 
exception raise.
- Fixed a bug in the BridgeSupport parser when loading IOKit, which contains 
very large structures. 
- Fixed a bug in IO#try_convert to properly raise a TypeError exception when 
passed a wrong object.
- Fixed a regexp bug in the URI library to avoid a backtrace explosion.
- Fixed a bug in String#+ where non-string objects could be concatenated.
- Fixed a bug when break expressions inside hash iterations wouldn't be taken 
into account.
- Fixed a bug in Array#fill(start, length) where passing a huge length would 
cause a crash.
- Fixed various minor CRuby conformance bugs in Array.
- Implemented the Hash#{keep_if, select!} methods.
- Implemented the Set#{keep_if, select!} methods.
- Fixed a bug in the ostruct library where regexp global variables would be 
overriden.
- Fixed a bug in macruby_deploy when passing --embed, to change the libmacruby 
dyld identification name, to conform to App Store submission rules.
- Fixed a bug in macruby_deploy when using --gem on gems containing a space 
character in their paths would break the deployment.
- Fixed a race condition crash in Thread#kill.
- Fixed a bug when compiling recursive method calls when methods actually 
re-define themselves on the fly (this fixes the mustache library).
- Moved to LLVM 2.9.
- Fixed a bug where converting a NULL pointer as an opaque type value to Ruby 
would not give nil (as in RubyCocoa).
- Fixed a bug in Hash#[]= to not duplicate a String key that is already frozen.

Tickets:

#1184   Bus Error occurs since r5265.
#1186   macirb segfaults when trying to tab complete an NSURL object
#1166   Segfaults occurs when was passed NULL pointer into rb_protect's 3rd 
argument.
#794`pthread_mutex_unlock(t-sleep_mutex)' failed: Invalid argument (22)
#734Mustache fails on call to render.
#1177   Hash.each doesn't exit on embedded return
#1171   `macruby_deploy --gem` problem with directories that have a space
#1179   OpenStruct overwrites regex globals - seriously breaks Rack/Sinatra
#1178   Mac App Store reviewers rejecting MacRuby app's due to library name
#1185   LLVM error running 1.9 distribution on Sandy Bridge
#1191   Assertion failed with define_method.
#1194   launch_msg(LAUNCH_KEY_CHECKIN) doesn't return nil when run outside of a 
daemon/agent

Laurent
___
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

[MacRuby-devel] [ANN] MacRuby 0.10

Hi,

After just a couple weeks of development since the last release,
MacRuby 0.10 is now available. Get it here while it's still hot!

MacRuby is an implementation of Ruby 1.9 directly on top of Mac OS X
core technologies such as the Objective-C runtime and garbage
collector, the LLVM compiler infrastructure and the Foundation and ICU
frameworks. It is the goal of MacRuby to enable the creation of
full-fledged Mac OS X applications which do not sacrifice performance
in order to enjoy the benefits of using Ruby.

You can learn more about MacRuby, and download a binary installer,
from the website:

http://macruby.org

Or about this release more specifically, on our blog:

http://www.macruby.org/blog/2011/03/23/macruby010.html

Enjoy,

Laurent
___
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] Xcode 4 LLVM = r127367

Hi Dave,

Xcode4 does not expose the LLVM header files and libraries needed for MacRuby, 
so you will have to build and install LLVM by yourself (as outlined in the 
README.rdoc file).

Xcode4, on the other side, installs clang, which can be used to compile MacRuby 
instead of gcc, but you will still need the LLVM libraries around.

Laurent

On Mar 23, 2011, at 6:37 PM, Dave Lee wrote:

 Can the LLVM that comes with Xcode 4 be used to compile MacRuby 0.10? Is 
 there a way to determine which svn revision Xcode's LLVM was compiled from?
 
 thanks,
 Dave
 ___
 MacRuby-devel mailing list
 MacRuby-devel@lists.macosforge.org
 http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

___
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

[MacRuby-devel] xcode4 templates - update

2011-03-22 Thread Laurent Sansonetti

Hi guys,

I know some of you are waiting for the Xcode4 templates. Some work has been 
committed to trunk. You should be able to create new MacRuby projects from 
Xcode4 (basic, document-based, core-data based or preference pane). Each 
template has a Deployment target builtin that will call macruby_deploy with 
--compile --embed (you can customize the arguments if needed). Also, a basic 
.rb File template is provided.

According to Matt there is still a problem with the CoreData template, but 
besides that, I think it's good enough for 0.10. Please give trunk or tonight's 
nightly build a try and let us know what you think!

Thanks,
Laurent
___
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] MacRuby build issues with LLVM

2011-03-18 Thread Laurent Sansonetti

Hi Geoffrey,

Yes, you can use trunk or the latest nightly builds. We are still working on 
the Xcode4 templates to release 0.10, and it's taking some time (the new 
template system is very different, and quite complex to understand). But 
besides the templates, trunk is ready, so you can bundle it.

Laurent

On Mar 18, 2011, at 11:56 AM, Geoffrey Grosenbach wrote:

 On Thu, Mar 10, 2011 at 1:34 PM, Laurent Sansonetti
 lsansone...@apple.com wrote:
 Thanks for verifying the fixes. I will release trunk as 0.10 tomorrow 
 evening.
 
 Is this still the plan? Many customers are on the new MacBook and I've
 had them roll back to a previous version of my app so it launches.
 
 Or, should I build my own MacRuby from trunk (if it will be a while
 before the official 0.10 release)?
 
 -- 
 Geoffrey Grosenbach
 b...@topfunky.com
 
 PeepCode Screencasts
 http://peepcode.com
 ___
 MacRuby-devel mailing list
 MacRuby-devel@lists.macosforge.org
 http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

___
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] Proposal: splitting macrubyc UI from logic

2011-03-14 Thread Laurent Sansonetti

Hi Mark,

As macrubyc's compilation logic is essentially spawning several command-line 
tools, I wonder if calling the logic directly from macruby_deploy is going to 
bring significant advantages, vs the complexity of splitting macrubyc.

I think a better strategy would be to optimize what's slow in macrubyc (such as 
command-line options parsing), and better include the compilation strategy into 
Xcode (if possible).

Laurent

On Mar 12, 2011, at 5:40 PM, Mark Rada wrote:

 Hi,
 
 I have completed a proof of concept patch for MacRuby where I have split the 
 UI of macrubyc from the underlying logic so that tools like macruby_deploy 
 can make use of the compiler without having to spawn a new macruby process 
 for each file that needs to be compiled. This should also be beneficial for 
 compiling gems and the standard library.
 
 After having made this patch, I realized that there are still several places 
 in the compiler where a new process is spawned to perform part of the 
 compilation. I'm not really sure how much else can be lib-ified from the 
 other required components. Overall there are still a few places that I know I 
 can optimize without much work needed.
 
 Right now, compile time for ruby files with about 100-200 lines of code is 
 about 1(+/-0.1) seconds on my MBP. Spawning a new macruby process and 
 processing the macrubyc options takes about 0.25 seconds; so I think the 
 patch is still useful in the general case.
 
 The code for the changes is located in my MacRuby fork on github: 
 https://github.com/ferrous26/MacRuby/tree/libify-rubyc
 
 Mark Rada
 mr...@marketcircle.com
 
 ___
 MacRuby-devel mailing list
 MacRuby-devel@lists.macosforge.org
 http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

___
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] framework method gotcha

2011-03-14 Thread Laurent Sansonetti

Hi Christian,

These tests should probably be removed, they are not used anymore (these were 
used before we switched to RubySpec).

The correct thing to do is probably make a macruby spec (under the spec/macruby 
directory).

How do you intend to change #framework exactly? Maybe you should work on a 
patch first, and we can iterate on it, then write the spec/test later.

Thanks for helping :)

Laurent

On Mar 12, 2011, at 10:54 PM, Christian Niles wrote:

 Cool. I've compiled MacRuby from source and discovered a test for the 
 'framework' method in test-macruby/cases/framework_test.rb. 
 
 What's the best way to run the tests in this directory? It doesn't seem to be 
 run by `rake spec` and I couldn't find another task that seemed to run these.
 
 On Mar 12, 2011, at 8:35 PM, Matt Aimonetti wrote:
 
 Hi Christian,
 
 As long as performance isn't affected, I think that making #framework 
 smarter shouldn't be a problem. 
 
 - Matt
 
 Sent from my iPhone
 
 On Mar 12, 2011, at 17:19, Christian Niles christ...@nerdyc.com wrote:
 
 Hey All,
 
 I just spent a few hours banging my head against a gotcha with the 
 `framework` method -- if there happens to be a file or directory in the 
 current directory with the name of the framework, the method fails:
 
 $ touch Cocoa
 $ macruby -e 'framework Cocoa'
 -e:1:in `main': framework at path `Cocoa' cannot be located (RuntimeError)
 
 $ rm Cocoa; mkdir Cocoa
 $ macruby -e 'framework Cocoa'
 -e:1:in `main': framework at path `Cocoa' cannot be loaded: Error 
 Domain=NSCocoaErrorDomain Code=4 UserInfo=0x200241e20 The bundle “Cocoa” 
 couldn’t be loaded because its executable couldn’t be located.
 
 I ran into this while trying to setup unit testing for a Cocoa framework 
 I'm writing. XCode 4 automatically creates a directory for each target you 
 create. Thus, when I tried to load my framework, it saw my project target 
 directory and thought it had found the framework.
 
 I think the `framework` method should be updated to avoid this gotcha. 
 Currently, it just tests for existence of a file or directory. I'm happy to 
 start working on a patch, but wanted to ask if there's any possible reason 
 the `framework` method is this naïve?
 
 christian.
 ___
 MacRuby-devel mailing list
 MacRuby-devel@lists.macosforge.org
 http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
 ___
 MacRuby-devel mailing list
 MacRuby-devel@lists.macosforge.org
 http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
 
 ___
 MacRuby-devel mailing list
 MacRuby-devel@lists.macosforge.org
 http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

___
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] TIL - Uncaught exceptions in threads cause SIGABRT in the main thread!

2011-03-14 Thread Laurent Sansonetti

Hi Morgan,

Well in theory, you should NOT get a segfault when doing that.

When an exception isn't rescued inside a Thread, the correct behavior is that 
the thread will quit, and that the exception will be silently ignored. Then, 
once the Thread object is garbage collected, if the exception has not been 
retrieved from the Thread object (for instance, if #join has never been called 
on it), then a warning message is printed on stderr with the exception 
backtrace, for debugging purposes.

It would be nice if you could reproduce the segfault in a small test case, 
because it looks bad (we should never segfault) :)

Laurent

On Mar 13, 2011, at 6:31 PM, Morgan Schweers wrote:

 Greetings,
 Today I Learned :) if a thread throws an exception that isn't rescued by the 
 top of the thread, it'll crash the app's main thread with 'Program received 
 signal:  “SIGABRT”.'
 
 That's been plaguing me since I started doing MacRuby development; every time 
 I tried to start up multiple threads, the app became incredibly fragile and, 
 unlike the main thread, it wouldn't show ruby traces.
 
 Now I just wrap threads in begin/rescue blocks, and I'm all good.  Good 
 programming practice anyway, but the failure mode is unobvious if you don't.
 
 Hopefully this helps someone else!
 
 --  Morgan
 
 ___
 MacRuby-devel mailing list
 MacRuby-devel@lists.macosforge.org
 http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

___
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

[MacRuby-devel] trunk depends on a new LLVM

2011-03-11 Thread Laurent Sansonetti

For those compiling from the repository: MacRuby now requires LLVM 2.9. I 
tested revision 127367 to be okay, so I recommend this one.

The README.rdoc file has been updated with newer instructions. Also, as trunk 
no longer builds for i386 by default, LLVM doesn't need to be built for it 
anymore, which results in a much faster build.

For those using the nightly builds, we will make sure it gets updated.

Laurent
___
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] Xcode 4 is out... any plan to integrate soon?

2011-03-11 Thread Laurent Sansonetti

I just tested Xcode4 on a Snow Leopard machine, after having re-installed 
MacRuby, and it seems that outlets and actions are recognized again!

Thanks for letting me know, I will prepare and integrate some templates into 
the upcoming 0.10 release.

Laurent

On Mar 11, 2011, at 12:53 PM, Shaun August wrote:

 Sorry, I was looking in the wrong place. I can confirm the outlets ARE 
 working for me. To reiterate, I installed Xcode 4 and then the nightly build 
 from the installer package and not from the command line. 
 
 
 Thank you,
 
 
 SHAUN AUGUST  DIRECTOR OF DESIGN
 
 EOS LIGHTMEDIA CORPORATION
 
 320 - 825 POWELL STREET, VANCOUVER, BC V6A 1H7  
 
 T 604 639 5488 / F 604 639 5489 / M 604 760-5475 / W eoslightmedia.com
 
 On 2011-03-11, at 12:50 PM, Shaun August saug...@me.com wrote:
 
 Hi All,
 
 I installed Xcode 4 and then the latest nightly build and the outlets are 
 not working for me.
 
 
 Thanks
 
 Shaun
 
 
 
 
 
 On 2011-03-11, at 10:22 AM, Matt Aimonetti mattaimone...@gmail.com wrote:
 
 Can you verify that the outlets are working?
 Laurent said he would commit the templates shortly so they should be 
 available in a future nightly build.
 
 - Matt
 
 On Fri, Mar 11, 2011 at 8:59 AM, Manu seatm...@gmail.com wrote:
 Interestingly, I made the mistake to remove Xcode 3.. so I have only Xcode 
 4 but I see it working with an older project. 
 
 So where can I find the template for MacRuby? And where should they be 
 installed?  So far beside few path issues in the build it seems to mostly 
 work
 
 I created a new file SomeClass.rb and a class, and I see it working on the 
 Custom Class field of the interface
 
 Emmanuel
 
 On Mar 11, 2011, at 8:50 AM, Matt Aimonetti wrote:
 
 Indeed and others couldn't get Xcode to work.
 
 - Matt
 
 On Fri, Mar 11, 2011 at 8:34 AM, Manu seatm...@gmail.com wrote:
 Ok . Seems like someone got it to work but did not explain how he did...
 
 
 On Mar 10, 2011, at 10:54 PM, Matt Aimonetti wrote:
 
 Please refer to the other posts about the same topic sent today.
 
 - Matt
 
 On Thu, Mar 10, 2011 at 9:25 PM, Manu seatm...@gmail.com wrote:
 Hi
 
 Now that Xcode 4 is out , and that MacRuby 0.9 is out,  any plans to 
 integrate with Xcode 4? Just curious. I saw a post last month but was 
 wondering if there were any update
 
 Emmanuel
 ___
 MacRuby-devel mailing list
 MacRuby-devel@lists.macosforge.org
 http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
 
 
 
 
 
 ___
 MacRuby-devel mailing list
 MacRuby-devel@lists.macosforge.org
 http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
 ___
 MacRuby-devel mailing list
 MacRuby-devel@lists.macosforge.org
 http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
 ___
 MacRuby-devel mailing list
 MacRuby-devel@lists.macosforge.org
 http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

___
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] macruby_deploy not embedding all of MacRuby

2011-03-11 Thread Laurent Sansonetti

Hi Kevin,

It sounds like a data corruption problem, but it could also maybe due to 
running the application on an Intel 32-bit machine (because, as of 0.10, i386 
support is not built in anymore by default).

I would run md5 hashes on both the embedded dylib and the one in 
/Library/Frameworks to ensure that no data corruption happened.

Laurent

On Mar 11, 2011, at 3:33 PM, Kevin Colyar wrote:

 I'm running the following command to prepare my app to share with testers.
 
 PATH=$PATH:/usr/local/bin macruby_deploy --embed --compile 
 $TARGET_BUILD_DIR/$PROJECT_NAME.app
 
 On my machine, its says the app directory is ~25MB but testers get the 
 following error when they try to run it:
 
 dyld: Library not loaded: 
 @executable_path/../Frameworks/MacRuby.framework/Versions/0.10/usr/lib/libmacruby.dylib
   Referenced from: /Applications/ViKing.app/Contents/MacOS/ViKing
   Reason: no suitable image found.  Did find:
 
 /Applications/ViKing.app/Contents/MacOS/../Frameworks/MacRuby.framework/Versions/0.10/usr/lib/libmacruby.dylib:
  unknown file type, first eight bytes: 0x6C 0x69 0x62 0x6D 0x61 0x63 0x72 0x75
 
 /Applications/ViKing.app/Contents/MacOS/../Frameworks/MacRuby.framework/Versions/0.10/usr/lib/libmacruby.dylib:
  unknown file type, first eight bytes: 0x6C 0x69 0x62 0x6D 0x61 0x63 0x72 0x75
 Trace/BPT trap
 
 When I upload the app directory to a remote server it's ~55MB and works only 
 other's machines.
 
 I assume this is due to symbolic links.  Has anyone else seen this or have a 
 fix for it?  Perhaps I'm missing a flag that I need to pass to macruby_deploy.
 
 Thanks,
 Kevin
 
 -- 
 Kevin Colyar
 http://kevin.colyar.net
 
 ___
 MacRuby-devel mailing list
 MacRuby-devel@lists.macosforge.org
 http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

___
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] Note of warning about Xcode 4

2011-03-10 Thread Laurent Sansonetti

Hi Sven,

On Mar 10, 2011, at 2:09 AM, Sven Schwyn wrote:

 Hi
 
 Referring to Vincent's recent post:
 
 - But the biggest problem is that currently there is no MacRuby support in 
 the interface editor: the actions and properties added in the Ruby code 
 won't appear in the interface editor.
 
 I've never had this kind of trouble not with the later betas nor the GM. 

What Vincent is referring to is the Xcode 3 feature where IB would 
automatically reveal the outlets and actions written in Ruby. This is not 
working in Xcode 4, and may be the reason why you want to stick to Xcode 3.

Laurent
___
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] MacRuby build issues with LLVM

2011-03-10 Thread Laurent Sansonetti

Yes, it was a problem in LLVM, which wasn't generating code for the proper 
architecture. I hope this was an exception and that we won't need to target new 
LLVM versions each time new architectures are introduced :)

Thanks for verifying the fixes. I will release trunk as 0.10 tomorrow evening.

Laurent

On Mar 10, 2011, at 3:00 AM, Nick Ludlam wrote:

 I can also confirm this now builds correctly. Thanks very much for the speedy 
 turnaround, Laurent.
 
 Out of interest, do you know why the Core i7 chip in this laptop behaves 
 differently to the Core 2 Duo in my previous laptop? Is it perhaps just that 
 LLVM is failing to detect the CPU correctly, and is creating code based on 
 incorrect assumptions?
 
 On 10 Mar 2011, at 02:27, Laurent Sansonetti wrote:
 
 I got confirmation that trunk as of r5271 should work.  Because of the 
 severity of this problem, and the recent changes in macruby_deploy regarding 
 App Store submissions, I think we should release 0.10 as soon as possible 
 now. I will work on it.
 
 Laurent
 
 On Mar 9, 2011, at 4:09 PM, Laurent Sansonetti wrote:
 
 Okay, I committed support for LLVM 2.9 as of r5269 and verified that no 
 regression is introduced (the spec suite runs fine).
 
 Please update your repository, do a rake clean, then build with the 
 CFLAGS=-D__SUPPORT_LLVM_29__ option. Example: $ rake 
 CFLAGS=-D__SUPPORT_LLVM_29__ jobs=8
 
 If this fixes the problem, we might need to roll out a MacRuby release with 
 this new LLVM soon, as I suspect the problem will hit many people.
 
 Laurent
 
 On Mar 9, 2011, at 2:10 PM, Laurent Sansonetti wrote:
 
 Okay, API breakage, but I can reproduce that on my machine :) I will hack 
 on it later today and post a message here once it's supposed to compile, 
 this way you can continue testing.
 
 Laurent
 
 On Mar 9, 2011, at 2:03 PM, Nick Ludlam wrote:
 
 Ok, well it's not failing in the same way, but it's still failing:
 
 /usr/bin/gcc-4.2 -std=c99 -I. -I./include -pipe -fno-common -fexceptions 
 -fblocks -g -O3 -Wall -Wno-deprecated-declarations -Werror -arch x86_64 
 -I./icu-1060 -c ucnv.c -o .objs/ucnv.o
 /usr/bin/gcc-4.2 -std=c99 -I. -I./include -pipe -fno-common -fexceptions 
 -fblocks -g -O3 -Wall -Wno-deprecated-declarations -Werror -arch x86_64 
 -I./icu-1060 -c encoding.c -o .objs/encoding.o
 /usr/bin/g++-4.2 -I. -I./include -fblocks -g -Wall 
 -Wno-deprecated-declarations -Werror -arch x86_64 
 -I/opt/llvm-macruby/include  -D_DEBUG -D_GNU_SOURCE -D__STDC_LIMIT_MACROS 
 -D__STDC_CONSTANT_MACROS -O3   -fno-rtti -fno-common -Woverloaded-virtual 
 -I./icu-1060 -c main.cpp -o .objs/main.o
 In file included from vm.h:593,
 from main.cpp:17:
 compiler.h:82: error: ISO C++ forbids declaration of ‘DIFactory’ with no 
 type
 compiler.h:82: error: expected ‘;’ before ‘*’ token
 rake aborted!
 Command failed with status (1): [/usr/bin/g++-4.2 -I. -I./include 
 -fblocks ...]
 
 (See full trace by running task with --trace)
 
 
 
 
 On 9 Mar 2011, at 21:34, Laurent Sansonetti wrote:
 
 It looks like it might take a while until I get my hands on a new MBP, 
 so could one try the following?
 
 1) Grab a copy of 
 https://llvm.org/svn/llvm-project/llvm/branches/release_29 using svn, 
 then build it using the same instructions in README.rdoc. I am just 
 hoping that this new version of LLVM supports the new hardware and that 
 it doesn't introduce API breakage.
 2) Re-build and install MacRuby trunk after doing a rake clean.
 
 Laurent
 
 On Mar 9, 2011, at 1:08 PM, Laurent Sansonetti wrote:
 
 Sorry the late reply. It's probably because this version of LLVM that 
 we use cannot target the new CPU yet. I will investigate :)
 
 Laurent
 
 On Mar 9, 2011, at 12:10 PM, Nick Ludlam wrote:
 
 Yes, this looks like it's exactly the problem I'm having, from the 
 look of the log, so perhaps it's a Sandy Bridge / Core i5/7 issue. 
 Curious!
 
 On 9 Mar 2011, at 19:56, Richard Sepulveda wrote:
 
 I have a customer that is also having this same problem with my 
 MacRuby Mac App Store application running on his new MacBook Pro. I 
 don't have
 access to this type of Mac so I haven't been able to reproduce this 
 problem.
 
 He has tried MacRuby 0.8 and 0.9 versions of my app with the same 
 results.
 
 I can provide copies of my app to developers that would like to try 
 to reproduce the problem.
 
 Thanks,
 
 Richard
 
 Here is a portion of the log that he sent me.
 
 3/9/11 11:35:31 AM
 [0x0-0xe20e2].com.rsepulveda.quickalarmtrial[2927]  LLVM ERROR: 
 Cannot yet select: 0x101899010: f64 = bit_convert 0x10191ae10 
 [ORD=315] [ID=7]
 3/9/11 11:35:31 AM
 [0x0-0xe20e2].com.rsepulveda.quickalarmtrial[2927]
 0x10191ae10: i64 = and 0x10191b510, 0x10189a110 [ORD=314] [ID=6]
 3/9/11 11:35:31 AM
 [0x0-0xe20e2].com.rsepulveda.quickalarmtrial[2927]  
 0x10191b510: i64,ch = CopyFromReg 0x103911388, 0x10191c510 [ORD=314] 
 [ID=5]
 3/9/11 11:35:31 AM
 [0x0-0xe20e2].com.rsepulveda.quickalarmtrial[2927

Re: [MacRuby-devel] Note of warning about Xcode 4

2011-03-10 Thread Laurent Sansonetti

Hi Sven,

On Mar 10, 2011, at 2:56 PM, Sven Schwyn wrote:

 Hi Laurent
 
 What Vincent is referring to is the Xcode 3 feature where IB would 
 automatically reveal the outlets and actions written in Ruby. This is not 
 working in Xcode 4, and may be the reason why you want to stick to Xcode 3.
 
 Well, it works for me. At least if by reveal the outlets and actions you 
 mean the following:
 
 Create application_controller.rb:
 
 class AppliationController
  attr_accessor foobar
  def do_this(sender)
puts @foobar
  end
 end
 
 Edit MainMenu.XIB:
 
 - Add an NSObject and set it to class ApplicationController
 - Select the connection inspector for it
 - The outlet foobar and the action do_this show up an can be linked to 
 elements

Strange! It wasn't working before, maybe they fixed that. I don't use Xcode, so 
I didn't see. Can someone else verify this? If it all works, we can include 
some Xcode4 templates in tomorrow's release.

Laurent
___
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] MacRuby build issues with LLVM

Sorry the late reply. It's probably because this version of LLVM that we use 
cannot target the new CPU yet. I will investigate :)

Laurent

On Mar 9, 2011, at 12:10 PM, Nick Ludlam wrote:

 Yes, this looks like it's exactly the problem I'm having, from the look of 
 the log, so perhaps it's a Sandy Bridge / Core i5/7 issue. Curious!
 
 On 9 Mar 2011, at 19:56, Richard Sepulveda wrote:
 
 I have a customer that is also having this same problem with my MacRuby Mac 
 App Store application running on his new MacBook Pro. I don't have
 access to this type of Mac so I haven't been able to reproduce this problem.
 
 He has tried MacRuby 0.8 and 0.9 versions of my app with the same results.
 
 I can provide copies of my app to developers that would like to try to 
 reproduce the problem.
 
 Thanks,
 
 Richard
 
 Here is a portion of the log that he sent me.
 
 3/9/11 11:35:31 AM   [0x0-0xe20e2].com.rsepulveda.quickalarmtrial[2927]  
 LLVM ERROR: Cannot yet select: 0x101899010: f64 = bit_convert 0x10191ae10 
 [ORD=315] [ID=7]
 3/9/11 11:35:31 AM   [0x0-0xe20e2].com.rsepulveda.quickalarmtrial[2927]  
   0x10191ae10: i64 = and 0x10191b510, 0x10189a110 [ORD=314] [ID=6]
 3/9/11 11:35:31 AM   [0x0-0xe20e2].com.rsepulveda.quickalarmtrial[2927]  
 0x10191b510: i64,ch = CopyFromReg 0x103911388, 0x10191c510 [ORD=314] 
 [ID=5]
 3/9/11 11:35:31 AM   [0x0-0xe20e2].com.rsepulveda.quickalarmtrial[2927]  
   0x103911388: ch = EntryToken [ORD=314] [ID=0]
 3/9/11 11:35:31 AM   [0x0-0xe20e2].com.rsepulveda.quickalarmtrial[2927]  
   0x10191c510: i64 = Register %reg16384 [ORD=314] [ID=1]
 3/9/11 11:35:31 AM   [0x0-0xe20e2].com.rsepulveda.quickalarmtrial[2927]  
 0x10189a110: i64 = Constant-4 [ORD=314] [ID=2]
 3/9/11 11:35:31 AM   com.apple.launchd.peruser.501[112]  
 ([0x0-0xe20e2].com.rsepulveda.quickalarmtrial[2927]) Exited with exit code: 1
 
 
 Nick and group,
 
 I'm seeing similar errors with the newest MacBook Pro -- after simply 
 downloading the 1.9 binary and running macgem, macirb, or macrake. In other 
 words, I'm not compiling from source, just trying to use the latest binary 
 distribution on a core i7 laptop.
 
 $ sudo macgem install rack
 LLVM ERROR: Cannot yet select: 0x10509ba10: f64 = bit_convert 0x10508ef10 
 [ORD=2615] [ID=7]
 0x10508ef10: i64 = and 0x105062a10, 0x10509b010 [ORD=2614] [ID=6]
 0x105062a10: i64,ch = CopyFromReg 0x1039108a8, 0x105099510 [ORD=2614] [ID=5]
 0x1039108a8: ch = EntryToken [ORD=2614] [ID=0]
 0x105099510: i64 = Register %reg16384 [ORD=2614] [ID=1]
 0x10509b010: i64 = Constant-4 [ORD=2614] [ID=2]
 
 
 $ macirb
 LLVM ERROR: Cannot yet select: 0x104852410: f64 = bit_convert 0x104858c10 
 [ORD=186] [ID=7]
 0x104858c10: i64 = and 0x104853c10, 0x104851910 [ORD=185] [ID=6]
 0x104853c10: i64,ch = CopyFromReg 0x103b0d028, 0x104856010 [ORD=185] [ID=5]
 0x103b0d028: ch = EntryToken [ORD=185] [ID=0]
 0x104856010: i64 = Register %reg16384 [ORD=185] [ID=1]
 0x104851910: i64 = Constant-4 [ORD=185] [ID=2]
 
 
 $ macrake
 LLVM ERROR: Cannot yet select: 0x10506d810: f64 = bit_convert 0x105047310 
 [ORD=800] [ID=7]
 0x105047310: i64 = and 0x105067d10, 0x105063010 [ORD=799] [ID=6]
 0x105067d10: i64,ch = CopyFromReg 0x103b0cf68, 0x105043110 [ORD=799] [ID=5]
 0x103b0cf68: ch = EntryToken [ORD=799] [ID=0]
 0x105043110: i64 = Register %reg16384 [ORD=799] [ID=1]
 0x105063010: i64 = Constant-4 [ORD=799] [ID=2]
 
 
 
 Interestingly, the macruby interpreter runs without error. macgem --help 
 and macgem --version also run fine (but these options produce errors with 
 macirb or macrake).
 
 FWIW, I only have Xcode 4 DP2 installed on this machine... although I 
 assume the MacRuby framework doesn't have any runtime dev tool 
 dependencies? (My understanding was it could be bundled with apps and 
 distributed to end users who don't have dev tools installed.)
 
 Scott
 
 On Wednesday, March 9, 2011 at 10:40 AM, Joshua Ballanco wrote: 
 Nick,
 
 I'm currently using Homebrew's llvm with MacRuby. Try passing the 
 --universal switch when you install llvm (i.e. brew install llvm 
 --universal). You also might try building and installing clang at the 
 same time (i.e. brew install llvm --universal --clang) and see if clang 
 can compile a simple C hello world to rule out llvm bugs. 
 
 Cheers,
 
 Josh
 
 On Wed, Mar 9, 2011 at 5:41 AM, Nick Ludlam n...@recoil.org wrote:
 Yes, I've double checked that I'm running 2.8 RELEASE, and it's still 
 bailing out with that cryptic message. The only other thing I can think 
 of is to remove XCode 4 and reinstall the current XCode3 release.
 
 On 9 Mar 2011, at 03:37, Matt Aimonetti wrote:
 
 ___
 MacRuby-devel mailing list
 MacRuby-devel@lists.macosforge.org
 http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
 
 ___
 MacRuby-devel mailing list
 MacRuby-devel@lists.macosforge.org
 http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] MacRuby build issues with LLVM

It looks like it might take a while until I get my hands on a new MBP, so could 
one try the following?

1) Grab a copy of https://llvm.org/svn/llvm-project/llvm/branches/release_29 
using svn, then build it using the same instructions in README.rdoc. I am just 
hoping that this new version of LLVM supports the new hardware and that it 
doesn't introduce API breakage.
2) Re-build and install MacRuby trunk after doing a rake clean.

Laurent

On Mar 9, 2011, at 1:08 PM, Laurent Sansonetti wrote:

 Sorry the late reply. It's probably because this version of LLVM that we use 
 cannot target the new CPU yet. I will investigate :)
 
 Laurent
 
 On Mar 9, 2011, at 12:10 PM, Nick Ludlam wrote:
 
 Yes, this looks like it's exactly the problem I'm having, from the look of 
 the log, so perhaps it's a Sandy Bridge / Core i5/7 issue. Curious!
 
 On 9 Mar 2011, at 19:56, Richard Sepulveda wrote:
 
 I have a customer that is also having this same problem with my MacRuby Mac 
 App Store application running on his new MacBook Pro. I don't have
 access to this type of Mac so I haven't been able to reproduce this problem.
 
 He has tried MacRuby 0.8 and 0.9 versions of my app with the same results.
 
 I can provide copies of my app to developers that would like to try to 
 reproduce the problem.
 
 Thanks,
 
 Richard
 
 Here is a portion of the log that he sent me.
 
 3/9/11 11:35:31 AM  [0x0-0xe20e2].com.rsepulveda.quickalarmtrial[2927]  
 LLVM ERROR: Cannot yet select: 0x101899010: f64 = bit_convert 0x10191ae10 
 [ORD=315] [ID=7]
 3/9/11 11:35:31 AM  [0x0-0xe20e2].com.rsepulveda.quickalarmtrial[2927]  
   0x10191ae10: i64 = and 0x10191b510, 0x10189a110 [ORD=314] [ID=6]
 3/9/11 11:35:31 AM  [0x0-0xe20e2].com.rsepulveda.quickalarmtrial[2927]  
 0x10191b510: i64,ch = CopyFromReg 0x103911388, 0x10191c510 [ORD=314] 
 [ID=5]
 3/9/11 11:35:31 AM  [0x0-0xe20e2].com.rsepulveda.quickalarmtrial[2927]  
   0x103911388: ch = EntryToken [ORD=314] [ID=0]
 3/9/11 11:35:31 AM  [0x0-0xe20e2].com.rsepulveda.quickalarmtrial[2927]  
   0x10191c510: i64 = Register %reg16384 [ORD=314] [ID=1]
 3/9/11 11:35:31 AM  [0x0-0xe20e2].com.rsepulveda.quickalarmtrial[2927]  
 0x10189a110: i64 = Constant-4 [ORD=314] [ID=2]
 3/9/11 11:35:31 AM  com.apple.launchd.peruser.501[112]  
 ([0x0-0xe20e2].com.rsepulveda.quickalarmtrial[2927]) Exited with exit code: 
 1
 
 
 Nick and group,
 
 I'm seeing similar errors with the newest MacBook Pro -- after simply 
 downloading the 1.9 binary and running macgem, macirb, or macrake. In 
 other words, I'm not compiling from source, just trying to use the latest 
 binary distribution on a core i7 laptop.
 
 $ sudo macgem install rack
 LLVM ERROR: Cannot yet select: 0x10509ba10: f64 = bit_convert 0x10508ef10 
 [ORD=2615] [ID=7]
 0x10508ef10: i64 = and 0x105062a10, 0x10509b010 [ORD=2614] [ID=6]
 0x105062a10: i64,ch = CopyFromReg 0x1039108a8, 0x105099510 [ORD=2614] 
 [ID=5]
 0x1039108a8: ch = EntryToken [ORD=2614] [ID=0]
 0x105099510: i64 = Register %reg16384 [ORD=2614] [ID=1]
 0x10509b010: i64 = Constant-4 [ORD=2614] [ID=2]
 
 
 $ macirb
 LLVM ERROR: Cannot yet select: 0x104852410: f64 = bit_convert 0x104858c10 
 [ORD=186] [ID=7]
 0x104858c10: i64 = and 0x104853c10, 0x104851910 [ORD=185] [ID=6]
 0x104853c10: i64,ch = CopyFromReg 0x103b0d028, 0x104856010 [ORD=185] [ID=5]
 0x103b0d028: ch = EntryToken [ORD=185] [ID=0]
 0x104856010: i64 = Register %reg16384 [ORD=185] [ID=1]
 0x104851910: i64 = Constant-4 [ORD=185] [ID=2]
 
 
 $ macrake
 LLVM ERROR: Cannot yet select: 0x10506d810: f64 = bit_convert 0x105047310 
 [ORD=800] [ID=7]
 0x105047310: i64 = and 0x105067d10, 0x105063010 [ORD=799] [ID=6]
 0x105067d10: i64,ch = CopyFromReg 0x103b0cf68, 0x105043110 [ORD=799] [ID=5]
 0x103b0cf68: ch = EntryToken [ORD=799] [ID=0]
 0x105043110: i64 = Register %reg16384 [ORD=799] [ID=1]
 0x105063010: i64 = Constant-4 [ORD=799] [ID=2]
 
 
 
 Interestingly, the macruby interpreter runs without error. macgem --help 
 and macgem --version also run fine (but these options produce errors 
 with macirb or macrake).
 
 FWIW, I only have Xcode 4 DP2 installed on this machine... although I 
 assume the MacRuby framework doesn't have any runtime dev tool 
 dependencies? (My understanding was it could be bundled with apps and 
 distributed to end users who don't have dev tools installed.)
 
 Scott
 
 On Wednesday, March 9, 2011 at 10:40 AM, Joshua Ballanco wrote: 
 Nick,
 
 I'm currently using Homebrew's llvm with MacRuby. Try passing the 
 --universal switch when you install llvm (i.e. brew install llvm 
 --universal). You also might try building and installing clang at the 
 same time (i.e. brew install llvm --universal --clang) and see if clang 
 can compile a simple C hello world to rule out llvm bugs. 
 
 Cheers,
 
 Josh
 
 On Wed, Mar 9, 2011 at 5:41 AM, Nick Ludlam n...@recoil.org wrote:
 Yes, I've double checked that I'm running 2.8 RELEASE, and it's still 
 bailing out with that cryptic message

Re: [MacRuby-devel] MacRuby build issues with LLVM

Okay, API breakage, but I can reproduce that on my machine :) I will hack on it 
later today and post a message here once it's supposed to compile, this way you 
can continue testing.

Laurent

On Mar 9, 2011, at 2:03 PM, Nick Ludlam wrote:

 Ok, well it's not failing in the same way, but it's still failing:
 
 /usr/bin/gcc-4.2 -std=c99 -I. -I./include -pipe -fno-common -fexceptions 
 -fblocks -g -O3 -Wall -Wno-deprecated-declarations -Werror -arch x86_64 
 -I./icu-1060 -c ucnv.c -o .objs/ucnv.o
 /usr/bin/gcc-4.2 -std=c99 -I. -I./include -pipe -fno-common -fexceptions 
 -fblocks -g -O3 -Wall -Wno-deprecated-declarations -Werror -arch x86_64 
 -I./icu-1060 -c encoding.c -o .objs/encoding.o
 /usr/bin/g++-4.2 -I. -I./include -fblocks -g -Wall 
 -Wno-deprecated-declarations -Werror -arch x86_64 -I/opt/llvm-macruby/include 
  -D_DEBUG -D_GNU_SOURCE -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -O3   
 -fno-rtti -fno-common -Woverloaded-virtual -I./icu-1060 -c main.cpp -o 
 .objs/main.o
 In file included from vm.h:593,
 from main.cpp:17:
 compiler.h:82: error: ISO C++ forbids declaration of ‘DIFactory’ with no type
 compiler.h:82: error: expected ‘;’ before ‘*’ token
 rake aborted!
 Command failed with status (1): [/usr/bin/g++-4.2 -I. -I./include -fblocks 
 ...]
 
 (See full trace by running task with --trace)
 
 
 
 
 On 9 Mar 2011, at 21:34, Laurent Sansonetti wrote:
 
 It looks like it might take a while until I get my hands on a new MBP, so 
 could one try the following?
 
 1) Grab a copy of https://llvm.org/svn/llvm-project/llvm/branches/release_29 
 using svn, then build it using the same instructions in README.rdoc. I am 
 just hoping that this new version of LLVM supports the new hardware and that 
 it doesn't introduce API breakage.
 2) Re-build and install MacRuby trunk after doing a rake clean.
 
 Laurent
 
 On Mar 9, 2011, at 1:08 PM, Laurent Sansonetti wrote:
 
 Sorry the late reply. It's probably because this version of LLVM that we 
 use cannot target the new CPU yet. I will investigate :)
 
 Laurent
 
 On Mar 9, 2011, at 12:10 PM, Nick Ludlam wrote:
 
 Yes, this looks like it's exactly the problem I'm having, from the look of 
 the log, so perhaps it's a Sandy Bridge / Core i5/7 issue. Curious!
 
 On 9 Mar 2011, at 19:56, Richard Sepulveda wrote:
 
 I have a customer that is also having this same problem with my MacRuby 
 Mac App Store application running on his new MacBook Pro. I don't have
 access to this type of Mac so I haven't been able to reproduce this 
 problem.
 
 He has tried MacRuby 0.8 and 0.9 versions of my app with the same results.
 
 I can provide copies of my app to developers that would like to try to 
 reproduce the problem.
 
 Thanks,
 
 Richard
 
 Here is a portion of the log that he sent me.
 
 3/9/11 11:35:31 AM
 [0x0-0xe20e2].com.rsepulveda.quickalarmtrial[2927]  LLVM ERROR: 
 Cannot yet select: 0x101899010: f64 = bit_convert 0x10191ae10 [ORD=315] 
 [ID=7]
 3/9/11 11:35:31 AM
 [0x0-0xe20e2].com.rsepulveda.quickalarmtrial[2927]0x10191ae10: 
 i64 = and 0x10191b510, 0x10189a110 [ORD=314] [ID=6]
 3/9/11 11:35:31 AM
 [0x0-0xe20e2].com.rsepulveda.quickalarmtrial[2927]  0x10191b510: 
 i64,ch = CopyFromReg 0x103911388, 0x10191c510 [ORD=314] [ID=5]
 3/9/11 11:35:31 AM
 [0x0-0xe20e2].com.rsepulveda.quickalarmtrial[2927]
 0x103911388: ch = EntryToken [ORD=314] [ID=0]
 3/9/11 11:35:31 AM
 [0x0-0xe20e2].com.rsepulveda.quickalarmtrial[2927]
 0x10191c510: i64 = Register %reg16384 [ORD=314] [ID=1]
 3/9/11 11:35:31 AM
 [0x0-0xe20e2].com.rsepulveda.quickalarmtrial[2927]  0x10189a110: 
 i64 = Constant-4 [ORD=314] [ID=2]
 3/9/11 11:35:31 AMcom.apple.launchd.peruser.501[112]  
 ([0x0-0xe20e2].com.rsepulveda.quickalarmtrial[2927]) Exited with exit 
 code: 1
 
 
 Nick and group,
 
 I'm seeing similar errors with the newest MacBook Pro -- after simply 
 downloading the 1.9 binary and running macgem, macirb, or macrake. In 
 other words, I'm not compiling from source, just trying to use the 
 latest binary distribution on a core i7 laptop.
 
 $ sudo macgem install rack
 LLVM ERROR: Cannot yet select: 0x10509ba10: f64 = bit_convert 
 0x10508ef10 [ORD=2615] [ID=7]
 0x10508ef10: i64 = and 0x105062a10, 0x10509b010 [ORD=2614] [ID=6]
 0x105062a10: i64,ch = CopyFromReg 0x1039108a8, 0x105099510 [ORD=2614] 
 [ID=5]
 0x1039108a8: ch = EntryToken [ORD=2614] [ID=0]
 0x105099510: i64 = Register %reg16384 [ORD=2614] [ID=1]
 0x10509b010: i64 = Constant-4 [ORD=2614] [ID=2]
 
 
 $ macirb
 LLVM ERROR: Cannot yet select: 0x104852410: f64 = bit_convert 
 0x104858c10 [ORD=186] [ID=7]
 0x104858c10: i64 = and 0x104853c10, 0x104851910 [ORD=185] [ID=6]
 0x104853c10: i64,ch = CopyFromReg 0x103b0d028, 0x104856010 [ORD=185] 
 [ID=5]
 0x103b0d028: ch = EntryToken [ORD=185] [ID=0]
 0x104856010: i64 = Register %reg16384 [ORD=185] [ID=1]
 0x104851910: i64 = Constant-4 [ORD=185] [ID=2]
 
 
 $ macrake

Re: [MacRuby-devel] MacRuby build issues with LLVM

I got confirmation that trunk as of r5271 should work.  Because of the severity 
of this problem, and the recent changes in macruby_deploy regarding App Store 
submissions, I think we should release 0.10 as soon as possible now. I will 
work on it.

Laurent

On Mar 9, 2011, at 4:09 PM, Laurent Sansonetti wrote:

 Okay, I committed support for LLVM 2.9 as of r5269 and verified that no 
 regression is introduced (the spec suite runs fine).
 
 Please update your repository, do a rake clean, then build with the 
 CFLAGS=-D__SUPPORT_LLVM_29__ option. Example: $ rake 
 CFLAGS=-D__SUPPORT_LLVM_29__ jobs=8
 
 If this fixes the problem, we might need to roll out a MacRuby release with 
 this new LLVM soon, as I suspect the problem will hit many people.
 
 Laurent
 
 On Mar 9, 2011, at 2:10 PM, Laurent Sansonetti wrote:
 
 Okay, API breakage, but I can reproduce that on my machine :) I will hack on 
 it later today and post a message here once it's supposed to compile, this 
 way you can continue testing.
 
 Laurent
 
 On Mar 9, 2011, at 2:03 PM, Nick Ludlam wrote:
 
 Ok, well it's not failing in the same way, but it's still failing:
 
 /usr/bin/gcc-4.2 -std=c99 -I. -I./include -pipe -fno-common -fexceptions 
 -fblocks -g -O3 -Wall -Wno-deprecated-declarations -Werror -arch x86_64 
 -I./icu-1060 -c ucnv.c -o .objs/ucnv.o
 /usr/bin/gcc-4.2 -std=c99 -I. -I./include -pipe -fno-common -fexceptions 
 -fblocks -g -O3 -Wall -Wno-deprecated-declarations -Werror -arch x86_64 
 -I./icu-1060 -c encoding.c -o .objs/encoding.o
 /usr/bin/g++-4.2 -I. -I./include -fblocks -g -Wall 
 -Wno-deprecated-declarations -Werror -arch x86_64 
 -I/opt/llvm-macruby/include  -D_DEBUG -D_GNU_SOURCE -D__STDC_LIMIT_MACROS 
 -D__STDC_CONSTANT_MACROS -O3   -fno-rtti -fno-common -Woverloaded-virtual 
 -I./icu-1060 -c main.cpp -o .objs/main.o
 In file included from vm.h:593,
   from main.cpp:17:
 compiler.h:82: error: ISO C++ forbids declaration of ‘DIFactory’ with no 
 type
 compiler.h:82: error: expected ‘;’ before ‘*’ token
 rake aborted!
 Command failed with status (1): [/usr/bin/g++-4.2 -I. -I./include -fblocks 
 ...]
 
 (See full trace by running task with --trace)
 
 
 
 
 On 9 Mar 2011, at 21:34, Laurent Sansonetti wrote:
 
 It looks like it might take a while until I get my hands on a new MBP, so 
 could one try the following?
 
 1) Grab a copy of 
 https://llvm.org/svn/llvm-project/llvm/branches/release_29 using svn, then 
 build it using the same instructions in README.rdoc. I am just hoping that 
 this new version of LLVM supports the new hardware and that it doesn't 
 introduce API breakage.
 2) Re-build and install MacRuby trunk after doing a rake clean.
 
 Laurent
 
 On Mar 9, 2011, at 1:08 PM, Laurent Sansonetti wrote:
 
 Sorry the late reply. It's probably because this version of LLVM that we 
 use cannot target the new CPU yet. I will investigate :)
 
 Laurent
 
 On Mar 9, 2011, at 12:10 PM, Nick Ludlam wrote:
 
 Yes, this looks like it's exactly the problem I'm having, from the look 
 of the log, so perhaps it's a Sandy Bridge / Core i5/7 issue. Curious!
 
 On 9 Mar 2011, at 19:56, Richard Sepulveda wrote:
 
 I have a customer that is also having this same problem with my MacRuby 
 Mac App Store application running on his new MacBook Pro. I don't have
 access to this type of Mac so I haven't been able to reproduce this 
 problem.
 
 He has tried MacRuby 0.8 and 0.9 versions of my app with the same 
 results.
 
 I can provide copies of my app to developers that would like to try to 
 reproduce the problem.
 
 Thanks,
 
 Richard
 
 Here is a portion of the log that he sent me.
 
 3/9/11 11:35:31 AM  
 [0x0-0xe20e2].com.rsepulveda.quickalarmtrial[2927]  LLVM ERROR: 
 Cannot yet select: 0x101899010: f64 = bit_convert 0x10191ae10 [ORD=315] 
 [ID=7]
 3/9/11 11:35:31 AM  
 [0x0-0xe20e2].com.rsepulveda.quickalarmtrial[2927]0x10191ae10: 
 i64 = and 0x10191b510, 0x10189a110 [ORD=314] [ID=6]
 3/9/11 11:35:31 AM  
 [0x0-0xe20e2].com.rsepulveda.quickalarmtrial[2927]  
 0x10191b510: i64,ch = CopyFromReg 0x103911388, 0x10191c510 [ORD=314] 
 [ID=5]
 3/9/11 11:35:31 AM  
 [0x0-0xe20e2].com.rsepulveda.quickalarmtrial[2927]
 0x103911388: ch = EntryToken [ORD=314] [ID=0]
 3/9/11 11:35:31 AM  
 [0x0-0xe20e2].com.rsepulveda.quickalarmtrial[2927]
 0x10191c510: i64 = Register %reg16384 [ORD=314] [ID=1]
 3/9/11 11:35:31 AM  
 [0x0-0xe20e2].com.rsepulveda.quickalarmtrial[2927]  
 0x10189a110: i64 = Constant-4 [ORD=314] [ID=2]
 3/9/11 11:35:31 AM  com.apple.launchd.peruser.501[112]  
 ([0x0-0xe20e2].com.rsepulveda.quickalarmtrial[2927]) Exited with exit 
 code: 1
 
 
 Nick and group,
 
 I'm seeing similar errors with the newest MacBook Pro -- after simply 
 downloading the 1.9 binary and running macgem, macirb, or macrake. In 
 other words, I'm not compiling from source, just trying to use the 
 latest binary distribution on a core i7 laptop.
 
 $ sudo macgem

Re: [MacRuby-devel] macgem and macirb broken after trunk r5248 (0.10) install

2011-02-26 Thread Laurent Sansonetti

Hi Franco,

As the version number got changed, I recommend starting with a fresh copy of 
MacRuby, by doing a `rake clean'. Then, you can build the project as usual, 
then you may want to delete the /Library/Frameworks/MacRuby.framework directory 
before doing a `rake install' (though this should not be necessary).

Laurent

On Feb 26, 2011, at 1:09 AM, Franco Rondini wrote:

 Hello guys,
 After checking out r5248 trunk (0.10) ( my  previous svn co was of r5235 
 (0.9)) the:
 rake jobs=2 it's OK 
 sudo rake install aborts this way:
 
 /usr/bin/install -c -m 0755 ext/bigdecimal/lib/bigdecimal/jacobian.rbo 
 /Library/Frameworks/MacRuby.framework/Versions/0.10/usr/lib/ruby/site_ruby/1.9.2/bigdecimal
 install: 
 /Library/Frameworks/MacRuby.framework/Versions/0.10/usr/lib/ruby/site_ruby/1.9.2/bigdecimal:
  No such file or directory
 rake aborted!
 
 so i fix it making the missing path by hand to finally get the 0.10 installed:
 
 cd /Library/Frameworks/MacRuby.framework/Versions/
 mkdir 0.10
 cd 0.10
 mkdir usr
 cd usr
 mkdir lib
 cd lib
 mkdir ruby
 cd ruby
 mkdir site_ruby
 cd site_ruby
 mkdir 1.9.2
 cd 1.9.2
 mkdir bigdecimal
 cd bigdecimal
 
 cd ~Projects/macruby/MacRuby-trunk
 sudo rake install 
 [snip]
 ** Execute install
 MacBook-di-Franco-Rondini:MacRuby-trunk ronda$ macruby --version
 MacRuby 0.10 (ruby 1.9.2) [universal-darwin10.0, x86_64]
 
 Unfortunately the following problems have arisen:
 macirb 
 /usr/local/bin/macirb:3:in `main': no such file to load -- ripper/core 
 (LoadError)
 macgem 
 /usr/local/bin/macgem:9:in `main': uninitialized constant 
 Gem::ConfigFile::YAML (NameError)
 MacBook-di-Franco-Rondini:MacRuby-trunk ronda$ 
 
 could it be something wrong in my environment settings? 
 ..btw with the previous revisions, build and install without problems
 Thanks, Bye 
 Franco 
 
 ___
 MacRuby-devel mailing list
 MacRuby-devel@lists.macosforge.org
 http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

___
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

[MacRuby-devel] MacRuby 0.9 release notes

Here are the release notes for MacRuby 0.9! An e-mail announcing the release 
will be following.

Highlights:

- Lots of stability fixes (crashers, memory leaks and race conditions), and a 
few performance improvements.
- The internal representation of Strings changed from a dual binary / UTF-16 
model to a pure binary one, principally to avoid problems in multithreaded 
applications. Performance should remain the same in most cases.
- The macruby_deploy program has been enhanced to embed RubyGems (with 
dependencies) and BridgeSupport files. See the new respective --gem and --bs 
options.
- The libmacruby-static.a library is not built by default anymore, because 
static compilation is still a work in progress.
- Upgraded to RubyGems 1.4.2.

Changes:

- Fix a bug in IO.open() where numeric file descriptors could not be passed as 
the first argument.
- Fix an assertion that could happen when calling #methods  friends on a class 
that contains a method name larger than 100 characters.
- Fix a bug in IO.open() where the given path would not be handled as a path 
(calling #to_path if necessary).
- Fix a bug in the YAML extension where yajl_free() would be called on a NULL 
pointer.
- Fix a bug in the OpenSSL extension, when calling ossl_pkey_sign().
- Fix a bug where calling a method defined with #define_method with a block 
accepting a splat argument (arity -2) would crash.
- Fix Ruby warnings in the YAML extension.
- Fix a bug when some splat methods defined with #define_method() would 
segfault at dispatch time.
- Improve the internal rb_eql() routine for performance, makes faster hash 
lookup / keys comparison operations.
- Improve the hashing function for Arrays.
- Move the conformsToProtocol: and performSelector: default logic on direct 
pure-Ruby subclasses.
- Fix a bug in IO#close_write where IOError would not be thrown if the stream 
was readable and non-duplex.
- Fix a bug in IO#write where an exception would be raised if the stream was 
read-only when writing 0 bytes of data.
- Fix a bug in Kernel.require where a file path starting with '~' would not be 
loaded.
- Fix a bug in String#gsub! where we would segfault during string concatenation.
- Fix a bug in the compilation of scopes where the current_block_arg state 
variable wouldn't be re-entrant (this fixes the compilation of the mechanize 
library).
- Fix bugs in String#inspect when called on a string that contains invalid and 
non-BMP characters.
- Fix a potential memory crasher in String#sub and String#gsub where free'd 
memory would be reused.
- Fix a bug where $FILENAME, $* and $-W could be changed.
- Fix a bunch of bugs in Array methods where SecurityError would not be raised 
when $SAFE is 4.
- Fix a bug in Kernel#untrust where an exception would not be raised on a 
frozen object.
- Fix a bug in Kernel#trust where an exception would not be raised on a frozen 
object.
- Fix a bug in Kernel#trust where an exception would not be raised if $SAFE is 
equal or greater than 3.
- Fix a crash in Rational#rationalize due to registering the method with a 
wrong arity.
- Fix a bug when we would free outer memory but still keep outers pointing to 
that memory location, causing crashes later during const lookup (this fixes 
rspec).
- Fix a bug in Struct#hash when called on recursive structs.
- Fix a bug in Array#== when called with recursive arrays.
- Fix a bug in StringIO#puts when called with recursive arrays.
- Fix a bug in Exception#== when an infinite loop would be entered when 
comparing exceptions from different classes.
- Fix a bug when #initialize_copy would not raise an exception when called on 
Object or BasicObject.
- Add support for encodings ISO8859_{2..16}.
- Fix a bug in String#search_codepoint where breaks were ignored.
- Fix a bug in OpenSSL::BN#to_s.
- Fix a bug in OpenSSL::PKey::DH#compute_key.
- Fix a bug in OpenSSL::X509::Attribute#to_der.
- Fix a bug in OpenSSL::PKCS5.pbkdf2_hmac(_sha1).
- Fix a bug in OpenSSL::PKey::DSA#syssign.
- Fix a bug in OpenSSL's ossl_x509store_initialize() function where an internal 
value would not properly be initialized.
- Fix a bunch of bugs in Array methods where an exception would not be raised 
when passing very large indexes or ranges.
- Fix a bug in Array#inspect where an untrusted string would not be returned.
- Fix a bug in String#unpack when called with a block.
- Add support for variadic objc method dispatch in the parser.
- Fix a bug in Socket.pair where the sockets would not be yielded when passing 
a block.
- Fix a bug in Socket.pair(domain, type, protocol) and Socket.new(domain, type, 
protocol) where protocol would not be an optional argument.
- Fix a bug in Socket.getservbyport(port) where a port outside the uint16 range 
would be accepted.
- Fix a bug in Socket.getservbyport where the network byte order value would 
not be passed to the underlying API.
- Fix a memory leak and potential crasher in Regexp's internal 
rb_reg_matcher_new() function.
- Fix various memory leaks and potential

[MacRuby-devel] [ANN] MacRuby 0.9

Hi,

After about 2 months of development since the last release, MacRuby 0.9 is
now available. Get it here while it's still hot!

MacRuby is an implementation of Ruby 1.9 directly on top of Mac OS X
core technologies such as the Objective-C runtime and garbage
collector, the LLVM compiler infrastructure and the Foundation and ICU
frameworks. It is the goal of MacRuby to enable the creation of
full-fledged Mac OS X applications which do not sacrifice performance
in order to enjoy the benefits of using Ruby.

You can learn more about MacRuby, and download a binary installer,
from the website:

http://macruby.org

Or about this release more specifically, on our blog:

http://www.macruby.org/blog/2011/02/24/macruby09.html

Enjoy,

Laurent
___
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] iokit again

Hi Joel,

Support is almost complete, be patient a bit more. Also, please follow up on 
the ticket (that's what they are meant to be used for).

Laurent

On Feb 23, 2011, at 12:20 PM, Joel Reymont wrote:

 I'm chomping at the bit to have IOKit support in MacRuby. 
 
 Can you tell me what needs to be done for IOKit support [1]?
 
 I may be able to do the work and submit a patch.
 
   Thanks in advance, Joel
 
 [1] http://www.macruby.org/trac/ticket/1126
 
 --
 - mac osx device driver ninja, kernel extensions and user-land usb drivers
 -++---
 http://wagerlabs.com | @wagerlabs | http://www.linkedin.com/in/joelreymont
 -++---
 
 ___
 MacRuby-devel mailing list
 MacRuby-devel@lists.macosforge.org
 http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

___
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] stopping to build for i386

Hi Eric,

On Feb 24, 2011, at 2:19 PM, Eric Christopherson wrote:

 On Tue, Feb 22, 2011 at 8:31 PM, Laurent Sansonetti
 lsansone...@apple.com wrote:
 Hi,
 As of r5239 in trunk, the default build process will no longer build for
 both i386 and x86_64, but just x86_64. This is an attempt at accelerating
 the build process and reducing the framework objects size.
 We are however not removing any i386-related code from the project, and one
 will still be able to build a 32-bit version of MacRuby by passing
 archs=i386 to rake. We will also consider fixing i386 bugs. But we want to
 start discouraging people to target i386 hardware for MacRuby apps, for
 several reasons (codebase not well tested, runtime / exception handling
 differences, floating point precision loss, etc.). The i386-related code
 could eventually be removed from MacRuby after 0.10.
 This is not an irrevocable decision, though. If people complain we will
 revert the change. But I want to give it a try.
 Laurent
 
 How hard do you imagine it would be for other developers to keep the
 386 code going after 0.10?

It wouldn't be very easy, I'm afraid. But we can keep the code is there is a 
demand.

Laurent___
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] NoMethodError (ib_outlets)

2011-02-23 Thread Laurent Sansonetti

Hi Rob,

ib_outlets is an old RubyCocoa craft that is not supported in MacRuby since a 
long time. You can define IB outlets using the attr_writer or attr_accessor 
methods. You can define IB actions by defining methods accepting a single 
argument, named 'sender'. 

There are lots of documentation about this on the net. Here is a pointer to a 
nice tutorial that you might be interested to follow.

http://blog.phusion.nl/2010/03/12/creating-our-very-first-mac-application-with-ruby-how-exciting/#more-509

Laurent

On Feb 23, 2011, at 1:57 PM, Rob Gleeson wrote:

 Hi
 
 I'm giving my first MacRuby application a shot, and I'm sort of blind to be 
 honest :)
 I've added a NSWindowController, attached it to my window, saved the classes 
 in Interface Builder, but when I build and run my application, I get a 
 NoMethodError for 'ib_outlets'. 
 
 My controller inherits from NSResponder.
 
 The stranger thing is, I guess, when I remove any code referencing 
 ib_outlets, the same error is raised again. NoMethodError.
 
 Any advice? What class defines ib_outlets? Am I doing it completely wrong?
 Thanks.
 
 --
 Rob
 
 
 
 
 
 ___
 MacRuby-devel mailing list
 MacRuby-devel@lists.macosforge.org
 http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

___
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] 0.9 update

2011-02-23 Thread Laurent Sansonetti

Hi Andre,

Thanks for reporting this. Are you using the new macruby_deploy --gem option to 
embed the gems?

Laurent

On Feb 23, 2011, at 5:33 PM, Andre Lewis wrote:

 It would be nice if you could try the latest nightly build with your app and 
 favorite Ruby lib
 
 My app is working with 0.9. My build process embeds MacRuby in the app 
 bundle, and packages the Nokogiri and Gdata gems. Everything is working so 
 far with 0.9.
 
 Thanks! Cheers,
 
 Andre
 
 ___
 MacRuby-devel mailing list
 MacRuby-devel@lists.macosforge.org
 http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

___
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

[MacRuby-devel] 0.9 update

Hi guys,

0.9 is now ready to be released! (really!). The trunk branch has been copied as 
branches/0.9 and we will continue the development on trunk, which now uses the 
0.10 version number.

It would be nice if you could try the latest nightly build with your app and 
favorite Ruby lib, and let me know if you find anything wrong, as I had to 
change (again) the const lookup rules to fix a regression. yesterday. I did a 
bit of testing and I'm confident the fix is good, but I would prefer to see 
more testing. 

http://www.macruby.org/files/nightlies/macruby_nightly-2011-02-22.pkg

If I don't hear anything bad, 0.9 will be released Friday :)

Thanks,
Laurent___
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

[MacRuby-devel] 0.9 update

Hi guys,

0.9 is now ready to be released! (really!). The trunk branch has been copied as 
branches/0.9 and we will continue the development on trunk, which now uses the 
0.10 version number.

It would be nice if you could try the latest nightly build with your app and 
favorite Ruby lib, and let me know if you find anything wrong, as I had to 
change (again) the const lookup rules to fix a regression. yesterday. I did a 
bit of testing and I'm confident the fix is good, but I would prefer to see 
more testing. 

http://www.macruby.org/files/nightlies/macruby_nightly-2011-02-22.pkg

If I don't hear anything bad, 0.9 will be released Friday :)

Thanks,
Laurent___
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] NSLocalizedString

We could add such a method in MacRuby core, but I wonder if it will be really 
that much of a use. NSLocalizedString macros are used in Objective-C programs 
because they are parsed by the genstrings command-line tool, to generate the 
translation file. I am not sure if genstrings can be used on Ruby files.

At some point we will need a l10n solution for MacRuby apps, though. I am 
wondering if there isn't already a Ruby library for this? (something like 
gettext?).

Laurent

On Feb 22, 2011, at 9:50 AM, Eloy Duran wrote:

 Something like this:
 
 module Kernel
  private
 
  def NSLocalizedString(key, value)
NSBundle.mainBundle.localizedStringForKey(key, value:value, table:nil)
  end
 end
 
 On 21 feb 2011, at 23:56, Charles Steinman wrote:
 
 On Mon, Feb 21, 2011 at 8:23 AM, Martin Hawkins
 martin.hawk...@gmail.com wrote:
 Changing the line to
 return NSBundle.mainBundle.localizedStringForKey(Today, value:Today
 title string, table:nil)
 works but NSLocalizedString is supposed to be a Foundation Function,
 so should be 'freely' available in MacRuby, shouldn't it?
 
 The trouble is that NSLocalizedString is not actually a function —
 it's a macro, so MacRuby can't call it. It really just needs to be
 reimplemented, but until then the NSBundle methods are precisely
 equivalent.
 
 — Chuck
 ___
 MacRuby-devel mailing list
 MacRuby-devel@lists.macosforge.org
 http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
 
 ___
 MacRuby-devel mailing list
 MacRuby-devel@lists.macosforge.org
 http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

___
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] Towards a compile option for macgem

I think that macgem should just compile the gem source files during 
installation, by default. We could eventually add a --no-compile argument to 
skip the compilation.

There is just one problem: AOT compilation does not remember the DWARF metadata 
yet, so backtraces won't be complete. This is the reason why we are not doing 
this, yet.

I believe we have a ticket track the AOT compilation problem, once it's fixed, 
we can turn this on. Maybe we can do this for 0.10.

Laurent

On Feb 22, 2011, at 9:18 AM, Joshua Ballanco wrote:

 Hey Mark,
 
 I agree with Matt that macruby_deploy needs work in this area, and any effort 
 you can contribute (or experience that you have gained from working on your 
 gem plugin) would be greatly appreciated. That said, I think a gem plugin is 
 a separate (and, IMHO at least, as valuable) issue.
 
 So then, my personal view on the options you outlined:
 
 - A gemspec property (e.g. spec.compile_for_macruby = true)
 
 This seems more apt of an addition for MacRuby specifically. Unfortunately, 
 it seems that extraneous gemspec properties are not ignored, but if they 
 were, this would be a prime candidate for an option that is only used by 
 macgem. Now that I'm thinking about it, though, I wonder why we wouldn't just 
 have MacGem compile all gems?
  
 - A gem command:
   gem compile nokogiri
   gem compile —remove-original-files nokogiri
   • I can’t remove the original *.rb files and leave *.rbo files by 
 default because of how rubygems identifies gems (unless I modify gemspec 
 files)
 
 This seems most in keeping with how other gem extensions work. I don't think 
 removing original files is all that important though, since keeping them 
 around is also useful for debugging gems.
  
  - A gem install option
gem install —compile nokogiri
 
 Maybe this is better handled with an option in .gemrc? or an environment 
 variable?
 
 I'm afraid I'm a bit too swamped at the moment to lend a hand directly, but I 
 like the direction you're going, and I'll definitely keep an eye on where 
 this is going.
 
 Cheers,
 
 Josh 
 ___
 MacRuby-devel mailing list
 MacRuby-devel@lists.macosforge.org
 http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

___
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

[MacRuby-devel] stopping to build for i386

Hi,

As of r5239 in trunk, the default build process will no longer build for both 
i386 and x86_64, but just x86_64. This is an attempt at accelerating the build 
process and reducing the framework objects size.

We are however not removing any i386-related code from the project, and one 
will still be able to build a 32-bit version of MacRuby by passing archs=i386 
to rake. We will also consider fixing i386 bugs. But we want to start 
discouraging people to target i386 hardware for MacRuby apps, for several 
reasons (codebase not well tested, runtime / exception handling differences, 
floating point precision loss, etc.). The i386-related code could eventually be 
removed from MacRuby after 0.10.

This is not an irrevocable decision, though. If people complain we will revert 
the change. But I want to give it a try. 

Laurent___
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] WeakRef advice

2011-02-15 Thread Laurent Sansonetti

Hi Alan,

Do you control the data structure that holds a reference to 'B'? If yes, you 
may want to use NSHashTable which supports weak references.

To me, this sounds like a design problem. Maybe your project can be 
re-architectured to avoid this pattern.

Laurent

On Feb 15, 2011, at 12:22 AM, Alan Skipp wrote:

 Hi Laurent,
 Thanks for the response. In essence the problem I have is something like this:
 
 Object 'A' is created, then to handle Key Value Observing, Object 'B' is 
 created which holds an instance variable to Object 'A'. 'B' is held in a hash 
 or array somewhere. Object 'B' only has a purpose while 'A', is in use, when 
 this is no longer the case I want 'B' to self destruct. However, 'B' is held 
 in a hash and holds a reference to 'A', so neither object goes out of scope 
 and neither can be garbage collected.
 
 If I changed the implementation perhaps I could avoid this problem, though 
 I'm not sure what the solution would be as yet.
 
 al
 
 On 14 Feb 2011, at 22:09, Laurent Sansonetti wrote:
 
 Hi Alan,
 
 MacRuby should have the same problem. ObjectSpace._id2ref in MacRuby 
 basically maps an object pointer value to a numerical description, and the 
 GC recycles objects. 
 
 I am curious why you need weak references, though. MacRuby is able to detect 
 and deal with reference cycles, so you shouldn't need to worry about leaks. 
 Is there another use case that I'm forgetting? 
 
 Laurent
 
 ___
 MacRuby-devel mailing list
 MacRuby-devel@lists.macosforge.org
 http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

___
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] WeakRef advice

2011-02-14 Thread Laurent Sansonetti

Hi Alan,

MacRuby should have the same problem. ObjectSpace._id2ref in MacRuby basically 
maps an object pointer value to a numerical description, and the GC recycles 
objects. 

I am curious why you need weak references, though. MacRuby is able to detect 
and deal with reference cycles, so you shouldn't need to worry about leaks. Is 
there another use case that I'm forgetting? 

Laurent

On Feb 14, 2011, at 5:48 AM, Alan Skipp wrote:

 Hello everyone,
 I've been doing some research into weak references in ruby and from what I've 
 read it seems that Ruby's WeakRef implementation is both inefficient and 
 unsafe. Here is the thread discussing the matter:
 http://redmine.ruby-lang.org/issues/show/4168
 
 As Macruby has a different garbage collector I don't know if these problems 
 are also present?
 
 I am working on a blocks based API for Key Value Coding and need to keep a 
 weak reference to objects. 
 Here is a very basic example of how this would look in garbage collected 
 Objective-C:
 
 @interface Observer : NSObject
 {
__weak id obj;
 }
 
 @implementation
 - (Observer *)initObservedObject:(id)object
 {
   obj = object;
 }
 
 
 Essentially I just need a Macruby equivalent of the above. Is there a simple 
 way to have a weak referenced instance variable in Macruby?
 
 al
 ___
 MacRuby-devel mailing list
 MacRuby-devel@lists.macosforge.org
 http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

___
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] MacRuby 0.9 - crash using Proc.new with NSArray.enumerateObjectsUsingBlock

2011-02-13 Thread Laurent Sansonetti

Hi Jonathan,

Your snippet does not require the Foundation framework. Add the following line 
to your script

framework 'Foundation'

You will also need MacRuby 0.8 and the latest BridgeSupport Preview 3 release. 
Then let us know if you still reproduce the crash. 

The snippet works fine in my environment :(

Laurent

On Feb 13, 2011, at 8:55 AM, Jonathan Waddilove wrote:

 Hi, another MacRuby 0.9 question...
 
 I've been trying to use lambda and/or Proc.new to provide callback blocks (as 
 suggested in Matt's excellent draft book). Again I have seen discussions 
 about problems in this area and for me all the suggested variants of code 
 fail.
 
 Here's a snip of failing code:
 
 #!/usr/local/bin/macruby
 puts Ruby Version: #{RUBY_VERSION}, MacRuby Version: #{MACRUBY_VERSION}
 
 a = [1, 2, 3, 4, 5,]
 
 a.enumerateObjectsUsingBlock(Proc.new {|obj, index, stop|
 puts I'll bet this never displays
 })
   
 and here's the resulting crash...
 
 Any suggestions?  many thanks,  Jonathan
 
 
 Process: macruby [23078]
 Path:
 /Library/Frameworks/MacRuby.framework/Versions/0.8/usr/bin/macruby
 Identifier:  macruby
 Version: ??? (???)
 Code Type:   X86-64 (Native)
 Parent Process:  ruby [23074]
 
 Date/Time:   2011-02-13 16:50:33.806 +
 OS Version:  Mac OS X 10.6.6 (10J567)
 Report Version:  6
 
 Exception Type:  EXC_BAD_ACCESS (SIGSEGV)
 Exception Codes: KERN_INVALID_ADDRESS at 0x
 Crashed Thread:  0  Dispatch queue: com.apple.main-thread
 
 Application Specific Information:
 objc[23078]: garbage collection is ON
 
 Thread 0 Crashed:  Dispatch queue: com.apple.main-thread
 0   ???   00 0 + 0
 1   ???   0x000102d63ac6 0 + 4342561478
 2   libmacruby.dylib  0x00010014a0b3 rb_vm_dispatch + 1331
 3   ???   0x000102d5a536 0 + 4342523190
 4   ???   0x000102d63806 0 + 4342560774
 5   libmacruby.dylib  0x000100162d53 rb_vm_run + 531
 6   libmacruby.dylib  0x0001000408f0 ruby_run_node + 80
 7   macruby   0x00010d28 main + 152
 8   macruby   0x00010c88 start + 52
 
 Thread 1:
 0   libSystem.B.dylib 0x7fff88fe5f8a __workq_kernreturn + 
 10
 1   libSystem.B.dylib 0x7fff88fe639c _pthread_wqthread + 
 917
 2   libSystem.B.dylib 0x7fff88fe6005 start_wqthread + 13
 
 Thread 0 crashed with X86 Thread State (64-bit):
  rax: 0x7fff5fbfddc0  rbx: 0x  rcx: 0x7fff5fbfdf0f  
 rdx: 0x
  rdi: 0x0002000bed00  rsi: 0x0002000bec00  rbp: 0x7fff5fbfdf40  
 rsp: 0x7fff5fbfdcf8
   r8: 0x0002   r9: 0x0005  r10: 0x0001  
 r11: 0x000100af9000
  r12: 0x0002000bec00  r13: 0x  r14: 0x0005  
 r15: 0x
  rip: 0x  rfl: 0x00010246  cr2: 0x
 
 Binary Images:
   0x1 -0x10ff7 +macruby ??? (???) 
 4408616F-9F77-025F-C278-91F945728AB0 /usr/local/bin/macruby
   0x13000 -0x100a29fd7 +libmacruby.dylib 0.8.0 (compatibility 
 0.8.0) 8910242D-90F3-32AC-A4CA-99D5C316AEB8 
 /Library/Frameworks/MacRuby.framework/Versions/0.8/usr/lib/libmacruby.dylib
0x7fff5fc0 - 0x7fff5fc3bdef  dyld 132.1 (???) 
 486E6C61-1197-CC7C-2197-82CE505102D7 /usr/lib/dyld
0x7fff801f1000 - 0x7fff802aafff  libsqlite3.dylib 9.6.0 (compatibility 
 9.0.0) 2C5ED312-E646-9ADE-73A9-6199A2A43150 /usr/lib/libsqlite3.dylib
0x7fff802ba000 - 0x7fff80478fff  libicucore.A.dylib 40.0.0 
 (compatibility 1.0.0) 781E7B63-2AD0-E9BA-927C-4521DB616D02 
 /usr/lib/libicucore.A.dylib
0x7fff809d - 0x7fff80a8dff7  com.apple.CoreServices.OSServices 357 
 (357) 7B22626F-D544-1955-CC53-240F4CACEB4A 
 /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/OSServices.framework/Versions/A/OSServices
0x7fff815d5000 - 0x7fff815ebfef  libbsm.0.dylib ??? (???) 
 42D3023A-A1F7-4121-6417-FCC6B51B3E90 /usr/lib/libbsm.0.dylib
0x7fff817b9000 - 0x7fff817bdff7  libmathCommon.A.dylib 315.0.0 
 (compatibility 1.0.0) 95718673-FEEE-B6ED-B127-BCDBDB60D4E5 
 /usr/lib/system/libmathCommon.A.dylib
0x7fff81cbb000 - 0x7fff81d05ff7  com.apple.Metadata 10.6.3 (507.15) 
 5170FCE0-ED6C-2E3E-AB28-1DDE3F628FC5 
 /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/Metadata.framework/Versions/A/Metadata
0x7fff8208d000 - 0x7fff82310ff7  com.apple.Foundation 6.6.4 (751.42) 
 AF1E3050-3503-8714-8274-EA6BD6BE8A22 
 /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation
0x7fff82318000 - 0x7fff82340fff  com.apple.DictionaryServices 1.1.2 
 (1.1.2) E9269069-93FA-2B71-F9BA-FDDD23C4A65E

Re: [MacRuby-devel] BridgeSupport Requirement

Hi Martin,

Are you sure you embedded the BridgeSupport file defining the
kInternetEventClass constant?

Looking on my system, it's in the HIServices.bridgesupport file.

You need to embed all BridgeSupport file dependencies, not only Cocoa or
Foundation. Here is a command snippet that will embed *all* of them:

$ find /System/Library/Frameworks -name *.bridgesupport -exec cp {}
/path/to/MyApp.app/Contents/Resources/BridgeSupport \;

That is going to increase your app bundle of about 7MB. You can remove the
frameworks files you don't use after,. The solution we will implement in
macruby_deploy might be a bit smarter by only embedding the files you need.

Laurent

On Feb 9, 2011, at 12:24 AM, Martin Hawkins wrote:

Laurent,
Your suggestion didn't work. We've taken to defining the constants
locally (it's KInternetEventClass KAEGetURL for NSAppleEventManager
that are causing all this).
I'm having difficulty testing this because I'm relying on a third
party to do so - I had to upgrade both my iMac and Powerbook to
BridgeSupport Preview 3, so unless I can roll back on one of them
(which you said was difficult) it's going to be hard to fix this.

regards
Martin

On Feb 8, 10:54 pm, Laurent Sansonetti lsansone...@apple.com wrote:

Seems good! Let us know if it does not work.

I think we should add an option to macruby_deploy to automate this.
Could you file a ticket?

Will file a ticket now.

Thanks. I added the 0.9-blocker keyword, as I think it should go with the
--gem option too.

Laurent

___
MacRuby-devel mailing list
MacRuby-de...@lists.macosforge.orghttp://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
___
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

___
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] macfuse example broken again?

Please open a new ticket and we will look :)

Laurent

On Feb 9, 2011, at 7:49 AM, Joel Reymont wrote:

 Is it just me or has the hellofs example [1] stopped working again?
 
 [1] http://www.macruby.org/trac/ticket/922
 
 --
 - mac osx device driver ninja, kernel extensions and user-land usb drivers
 -++---
 http://wagerlabs.com | @wagerlabs | http://www.linkedin.com/in/joelreymont
 -++---
 
 ___
 MacRuby-devel mailing list
 MacRuby-devel@lists.macosforge.org
 http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

___
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] error: gc operation on unregistered thread

It is not a MacRuby problem. This message is triggered by the GC when an 
operation (allocation, collection, whatever) happens on a thread that has not 
been registered. I suspect macfuse spawns new pthreads without calling the 
objc_registerThreadWithCollector() function.

Laurent

On Feb 9, 2011, at 4:43 PM, Joel Reymont wrote:

 I get a bunch of errors like this when running the hellofs MacFUSE example 
 [1]:
 
 macruby(25346,0x107082000) malloc: *** auto malloc[25346]: error: GC 
 operation on unregistered thread. Thread registered implicitly. Break on 
 auto_zone_thread_registration_error() to debug.
 
 Is this a MacRuby problem? How do I fix it?
 
   Thanks, Joel
 
 [1] http://www.macruby.org/trac/ticket/922
 
 --
 - mac osx device driver ninja, kernel extensions and user-land usb drivers
 -++---
 http://wagerlabs.com | @wagerlabs | http://www.linkedin.com/in/joelreymont
 -++---
 
 ___
 MacRuby-devel mailing list
 MacRuby-devel@lists.macosforge.org
 http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

___
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

[MacRuby-devel] macruby_deploy changes

Hi guys,

For those who are not following trunk, macruby_deploy got some changes recently:

- The --gem option is added. This option will embed the given RubyGem and its 
dependencies inside the application's bundle.

  ex. $ macruby_deploy --embed --gem nokogiri Foo.app

- The --bs option is added. This option will embed the system BridgeSupport 
files inside the application's bundle. This can be useful if you rely on 
BridgeSupport preview.

  ex. $ macruby_deploy --embed --bs Foo.app

- A bug has been fixed, when macruby_deploy was called with --embed but not 
--compile. The main application executable would not have its load path 
updated. This was a serious problem.

- When using --embed, the 'Current' symlink of the framework is now deleted. 
Apparently this fixes the Mac AppStore validation process which was following 
both '0.9' and 'Current' symlinks and ending with a Payload not declared in 
Package info error.

Please give tonight's nightly build a try and let us know if you find something 
wrong :)

Laurent___
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] BridgeSupport Requirement

2011-02-08 Thread Laurent Sansonetti

Hi Martin,

There is a way: if you copy the .bridgesupport files of your system inside your 
application's bundle, under the Resources/BridgeSupport directory, MacRuby 
should look at them in priority.

Examples:

Foo.app/Contents/Resources/BridgeSupport/Foundation.bridgesupport
Foo.app/Contents/Resources/BridgeSupport/AppKit.bridgesupport
etc.

I think we should add an option to macruby_deploy to automate this. Could you 
file a ticket?

Laurent

On Feb 8, 2011, at 1:07 AM, Martin Hawkins wrote:

 I installed BridgeSupport Preview 3 in order to resolve some issues
 related to errors looking up constant values. The new BridgeSupport
 worked fine and the application I have been working runs fine. I have
 'embedded' MacRuby so that it can be distributed but here I come
 unstuck.
 
 When run on a computer that does not have the BridgeSupport upgrade,
 it crashes; it seems that, while the app makes no reference to the
 MacRuby framework, it does need the new version of BridgeSupport in
 order to run.
 
 This makes the notion of an embedding fragile - is there a way to
 embed the required BridgeSupport, or must I require that users upgrade
 their BrigeSupport before they install my app.?
 ___
 MacRuby-devel mailing list
 MacRuby-devel@lists.macosforge.org
 http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

___
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] BridgeSupport Requirement

2011-02-08 Thread Laurent Sansonetti

Yep it does.

But if you copy the BridgeSupport file under the special 
Resources/BridgeSupport directory of your .app bundle, you do not need to pass 
the full path nor use #load_bridge_support_file. You can just use #framework as 
before.

Laurent

On Feb 8, 2011, at 1:56 AM, Robert Payne wrote:

 If you specify a full path does Bridge Support behave this way? Such as
 
 load_bridge_support_file NSBundle.mainBundle.pathForResource(MyFramework, 
 ofType:bridgesupport)
 
 Robert
 
 On 8/02/2011, at 10:50 PM, Laurent Sansonetti wrote:
 
 Hi Martin,
 
 There is a way: if you copy the .bridgesupport files of your system inside 
 your application's bundle, under the Resources/BridgeSupport directory, 
 MacRuby should look at them in priority.
 
 Examples:
 
  Foo.app/Contents/Resources/BridgeSupport/Foundation.bridgesupport
  Foo.app/Contents/Resources/BridgeSupport/AppKit.bridgesupport
  etc.
 
 I think we should add an option to macruby_deploy to automate this. Could 
 you file a ticket?
 
 Laurent
 
 On Feb 8, 2011, at 1:07 AM, Martin Hawkins wrote:
 
 I installed BridgeSupport Preview 3 in order to resolve some issues
 related to errors looking up constant values. The new BridgeSupport
 worked fine and the application I have been working runs fine. I have
 'embedded' MacRuby so that it can be distributed but here I come
 unstuck.
 
 When run on a computer that does not have the BridgeSupport upgrade,
 it crashes; it seems that, while the app makes no reference to the
 MacRuby framework, it does need the new version of BridgeSupport in
 order to run.
 
 This makes the notion of an embedding fragile - is there a way to
 embed the required BridgeSupport, or must I require that users upgrade
 their BrigeSupport before they install my app.?
 ___
 MacRuby-devel mailing list
 MacRuby-devel@lists.macosforge.org
 http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
 
 ___
 MacRuby-devel mailing list
 MacRuby-devel@lists.macosforge.org
 http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
 
 ___
 MacRuby-devel mailing list
 MacRuby-devel@lists.macosforge.org
 http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

___
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] BridgeSupport Requirement

2011-02-08 Thread Laurent Sansonetti

On Feb 8, 2011, at 5:30 AM, Martin Hawkins wrote:

 Thank you for the replies.
 
 On 8/02/2011, at 10:50 PM, Laurent Sansonetti wrote:
 
 Hi Martin,
 
 There is a way: if you copy the .bridgesupport files of your system inside 
 your application's bundle, under the Resources/BridgeSupport directory, 
 MacRuby should look at them in priority.
 
 Examples:
 
Foo.app/Contents/Resources/BridgeSupport/Foundation.bridgesupport
Foo.app/Contents/Resources/BridgeSupport/AppKit.bridgesupport
etc.
 
 Just to confirm -
 I have added a folder under Resources in Xcode called BridgeSupport
 into which I have copied
  AppKit.bridgesupport
  CoreServices.bridgesupport
  Cocoa.bridgesupport and
  Foundation.bridgesupport
 
 When I build now, I see the Contents/Resources/BridgeSupport directory
 containing the .bridgesupport files, so it seems to have had the
 desired effect.
 I'll be able to get it tested soon and I'll let you know if there are
 any further problems.

Seems good! Let us know if it does not work.

 I think we should add an option to macruby_deploy to automate this. Could 
 you file a ticket?
 
 Will file a ticket now.


Thanks. I added the 0.9-blocker keyword, as I think it should go with the --gem 
option too.

Laurent___
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] Subject: Re: Strange NSDate behavior building 32 bit v 64 bit

2011-01-31 Thread Laurent Sansonetti

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 then we can see if people complain.

Laurent

On Jan 31, 2011, at 12:07 PM, Jordan K. Hubbard wrote:

 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 demonstrate the 
 problem) yet?  That will allow us to track and prioritize the work for 
 possible inclusion in 0.9 (or later, depending on how things go).
 
 Thanks,
 
 - Jordan
 
 On Jan 31, 2011, at 2:41 AM, Richard Sepulveda wrote:
 
 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 next release.
 
 But i can't see anything obvious other than rewriting all of my NSDate based 
 code in Objective-C or
 waiting for a fix. i include the MacRuby framework in my Pkg so that is 
 possible.
 
 Richard
 
 Message: 2
 Date: Sun, 30 Jan 2011 22:08:38 -0800
 From: Jordan K. Hubbard j...@apple.com
 To: MacRuby development discussions.
 macruby-devel@lists.macosforge.org
 Subject: Re: [MacRuby-devel] Strange NSDate behavior building 32 bit v
 64 bit
 Message-ID: d31ef44c-06f8-45b1-83b4-7977a32bd...@apple.com
 Content-Type: text/plain; charset=us-ascii
 
 I suppose this begs the question:  Does anyone really *require* 32 bit 
 support for MacRuby at this point?  SnowLeopard is already the minimum 
 supported config, and the only Intel 32 bit-only platforms (very early 
 MacBook and Mac Mini configurations) are several years old now.  I don't 
 want to sound like an unfeeling ogre to anyone who actually has such a 
 configuration, mind you, but how big of an installed base does this really 
 represent?
 
 - Jordan
 
 On Jan 30, 2011, at 8:49 PM, Vincent Isambart wrote:
 
 1. Modified the Valid Archetectures to i386 x86_64
 
 There's a simple way to run macruby (or any other program) on the
 command line in 32 bits: just add arch -i386 before the name of the
 program to execute:
 $ macruby -v
 MacRuby 0.9 (ruby 1.9.2) [universal-darwin10.0, x86_64]
 $ arch -i386 macruby -v
 MacRuby 0.9 (ruby 1.9.2) [universal-darwin10.0, i386]
 ___
 MacRuby-devel mailing list
 MacRuby-devel@lists.macosforge.org
 http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
 
 ___
 MacRuby-devel mailing list
 MacRuby-devel@lists.macosforge.org
 http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

___
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] Can't build the MacRuby latest.

2011-01-28 Thread Laurent Sansonetti

Fixed in r5207. Sorry for the inconvenience, I did not try a full build before 
committing.

Laurent

On Jan 28, 2011, at 3:28 AM, Vincent Isambart wrote:

 Hi,
 
 I suspect the cause of the bug is the change Laurent did today for 
 next/ensure. Last time I played with the exception handling code I remember 
 it took me quite a while to get something working in all cases.
 
 I did a reduction of the code that does not work:
 def foo(dummy)
 1.times do
   next
 end
 ensure
 puts
 end
 foo(nil)
 
 I'll create a ticket for that.
 
 On Jan 28, 2011, at 6:43 PM, Watson wrote:
 
 Hi,
 
 Now, I'm rebuilding all of MacRuby latest.
 But, it seems that does not finish  forever with following build log.
 
 snip
 ./miniruby -I. -I./lib bin/rubyc --internal --arch x86_64 -C
 ext/ripper/lib/ripper/filter.rb -o
 ext/ripper/lib/ripper/filter.rbo
 ./miniruby -I. -I./lib bin/rubyc --internal --arch x86_64 -C
 ext/ripper/lib/ripper/lexer.rb -o ext/ripper/lib/ripper/lexer.rbo
 ./miniruby -I. -I./lib bin/rubyc --internal --arch x86_64 -C
 ext/ripper/lib/ripper/sexp.rb -o ext/ripper/lib/ripper/sexp.rbo
 ./miniruby -I. -I./lib bin/rubyc --internal --arch x86_64 -C
 ext/ripper/lib/ripper.rb -o ext/ripper/lib/ripper.rbo
 cd ext/bigdecimal  ../../miniruby -I../.. -I../../lib -r rbconfig -e
 RbConfig::CONFIG['libdir'] = '../..'; require './extconf.rb'
 checking for labs() in stdlib.h... yes
 checking for llabs() in stdlib.h... yes
 creating Makefile
 
 -
 
 Does it occur only in my environment?
 
 Thank you.
 ___
 MacRuby-devel mailing list
 MacRuby-devel@lists.macosforge.org
 http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
 
 ___
 MacRuby-devel mailing list
 MacRuby-devel@lists.macosforge.org
 http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

___
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] Gems again; signing records

2011-01-28 Thread Laurent Sansonetti

Hi Martin,

I think we now get the how to embed gems in a MacRuby Xcode project? question 
every week. I think it's time that we provide a way to automate that and 
properly document it on the website.

As I suggested on IRC yesterday, I think we should add a --gem argument to 
macruby_deploy, which would make sure the given gems and their dependencies are 
unpacked inside the application bundle.

I created the following ticket to track this change, and I believe it should be 
done for 0.9.

https://www.macruby.org/trac/ticket/1137

Laurent

On Jan 28, 2011, at 9:41 AM, Martin Hawkins wrote:

 I know this has been asked before but his is driving me nuts.It' s
 been a frustrating day; I've been trying to use the UUID gem and have
 still not been able to 'require' it successfully.
 
 I have installed uuid using macgem and have unpacked it to a vendor
 directory, so I now have :
 vendor -- macaddr-1.0.0 -- lib -- macaddr.rb
   --  uuid-2.3.1 -- lib -- uuid.rb
 
 Obviously, there's more, but those are important bits.
 
 I have tried the following, after googling, with no success, on the
 basis that the files are 'require'd and once loaded, can be 'require'd
 again by simple reference:
 In rb_main.rb
 
 $:.unshift  File.join(File.dirname(__FILE__), 'Vendor/uuid-2.3.1/lib')
 $:.unshift  File.join(File.dirname(__FILE__), 'Vendor/macaddr-1.0.0/
 lib')
 
 require 'macaddr'
 require 'uuid'
 
 However, when I try to require 'macaddr' or 'uuid' from another class
 definition file, I get 'no such file to load'.
 
 I've tried setting ENV['GEM_HOME']='/Users/martin/work/macruby/onWeb/
 PeepOpen/Vendor' in rb_main.rb; that seemed to make no difference.
 
 I've tried using the full path:
 require '/Users/martin/work/macruby/onWeb/xx/Vendor/macaddr-1.0.0/
 lib/macaddr'
 require '/Users/martin/work/macruby/onWeb/xx/Vendor/uuid-2.3.1/lib/
 uuid'
 and this produces a 'no such file to load -- fileutils' - neither gem
 depends on fileutils !
 
 But hey, I tried it and it refused to build - 'checking for Magick-
 config... no'
 
 So I have two questions:
 
 1. What is the *proper* way of incorporating gems into a MacRuby
 project using XCode to build and run; and
 2. All I want to do is sign records for later comparison. Can anybody
 suggest an alternative method, other than using UUID?
 
 thanks
 ___
 MacRuby-devel mailing list
 MacRuby-devel@lists.macosforge.org
 http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

___
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] Gems again; signing records

2011-01-28 Thread Laurent Sansonetti

Hi Caio,

On Jan 28, 2011, at 2:39 PM, Caio Chassot wrote:
 On 2011-01-28, at 20:30 , Laurent Sansonetti wrote:
 
 As I suggested on IRC yesterday, I think we should add a --gem argument to 
 macruby_deploy, which would make sure the given gems and their dependencies 
 are unpacked inside the application bundle.
 
 It could be great if this involved a bit of magic, so you only specify the 
 gems you need in a single place.
 
 Maybe it's overkill, but we could rely on Bundler. I'm a Bundler hater turned 
 devotee. It really helps keep a tight grip on a project's gem dependencies, 
 locking versions and all. With the added benefit to pull gems from custom 
 paths and git repos.
 
 I suppose such support could be built on top of a simpler --gem argument in a 
 rake task, though.

I would rather avoid any dependency. I agree that keeping track of the gems you 
need in a single place is a good idea, though.

Maybe we should refactor the Xcode templates to do so, eventually. Another 
possibility would be to scan the application's source code and auto-detect the 
list of gems, but I prefer to avoid that.

Laurent___
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

[MacRuby-devel] 0.9 release

2011-01-27 Thread Laurent Sansonetti

Hi guys,

I think it's time to release trunk as 0.9. I expect to do it next week, if 
possible.

I tagged the following tickets as blockers:

http://www.macruby.org/trac/ticket/1121
http://www.macruby.org/trac/ticket/1128

If you think another ticket should also be a 0.9 blocker let me know, as I may 
have overlooked the list :) We are looking for functional or performance 
regressions.

If you're doing a Cocoa app, please try a recent nightly build and let me know 
if anything is broken, as we must not ship any regression at this point.

Thanks :)
Laurent___
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] 0.9 release

2011-01-27 Thread Laurent Sansonetti

On Jan 27, 2011, at 3:36 PM, Caio Chassot wrote:
 On 2011-01-27, at 21:27 , Laurent Sansonetti wrote:
 Hi guys,
 
 I think it's time to release trunk as 0.9. I expect to do it next week, if 
 possible.
 
 Are we gonna have 0.10, 0.11, etc, or is 1.0 the next target?

There will very likely be a 0.10 release after 0.9.

Laurent___
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] 0.9 release

2011-01-27 Thread Laurent Sansonetti

Thanks Justin, we will fix that one in 0.9 :)

Laurent

On Jan 27, 2011, at 6:33 PM, Justin Schumacher wrote:

 Just posted a new regression:
 
 https://www.macruby.org/trac/ticket/1132
 
 On Thu, Jan 27, 2011 at 5:54 PM, Laurent Sansonetti lsansone...@apple.com 
 wrote:
 On Jan 27, 2011, at 3:36 PM, Caio Chassot wrote:
 On 2011-01-27, at 21:27 , Laurent Sansonetti wrote:
 Hi guys,
 
 I think it's time to release trunk as 0.9. I expect to do it next week, if 
 possible.
 
 Are we gonna have 0.10, 0.11, etc, or is 1.0 the next target?
 
 There will very likely be a 0.10 release after 0.9.
 
 Laurent
 
 ___
 MacRuby-devel mailing list
 MacRuby-devel@lists.macosforge.org
 http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
 
 
 ___
 MacRuby-devel mailing list
 MacRuby-devel@lists.macosforge.org
 http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

___
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] [macruby-changes] [5186] MacRuby/trunk/hash.h

Hi Watson,

Sorry for late response. I think your benchmark code contains too much side 
effects (such as the allocation of 'a' string and hash internals during 
rehash). If you just benchmark h[42]=42 you should see a difference.

Anyways, I corrected the change to use the mask flag in r5187.

Laurent

On Jan 21, 2011, at 3:09 PM, Watson wrote:

 Hi Laurent,
 
 There is only the extremely slight difference.
 I think that I can ignore this.
 How do you think?
 
 I attached a patch and benchmark script.
 
 
 ** Result of r5185
 $ macruby bm_hash.rb
 Rehearsal 
  13.64   0.21  13.85 (  9.114591)
 -- total: 13.85sec
 
   user system  totalreal
  13.72   0.24  13.96 (  9.172110)
 
 
 ** Result of r5186
 $ macruby bm_hash.rb
 Rehearsal 
  13.66   0.21  13.87 (  9.239979)
 -- total: 13.87sec
 
   user system  totalreal
  13.85   0.22  14.07 (  9.412910)
 
 
 ** Result of appling attached patch
 $ macruby bm_hash.rb
 Rehearsal 
  13.66   0.20  13.86 (  9.171733)
 -- total: 13.86sec
 
   user system  totalreal
  13.79   0.22  14.01 (  9.271439)
 
 
 
 2011/1/22 Laurent Sansonetti lsansone...@apple.com:
 Hi Watson,
 This isn't good, rhash_modify() must be very fast, so calling OBJ_FROZEN and
 OBJ_UNTRUSTED is not good there.
 Can we look up the mask flag as before?
 Laurent
 On Jan 21, 2011, at 7:51 AM, source_chan...@macosforge.org wrote:
 
 Revision 5186 Author watson1...@gmail.com Date 2011-01-21 07:51:01 -0800
 (Fri, 21 Jan 2011)
 
 Log Message
 
 More method of Hash will throw a SecurityError when $SAFE is 4.
 
 Test Script:
 {{{
 h = {}
 $SAFE = 4
 h['a'] = 1.0
 }}}
 
 Modified Paths
 
 MacRuby/trunk/hash.h
 
 Diff
 
 Modified: MacRuby/trunk/hash.h (5185 = 5186)
 
 --- MacRuby/trunk/hash.h 2011-01-21 02:20:08 UTC (rev 5185)
 +++ MacRuby/trunk/hash.h 2011-01-21 15:51:01 UTC (rev 5186)
 @@ -41,14 +41,11 @@
 static inline void
 rhash_modify(VALUE hash)
 {
 -const long mask = RBASIC(hash)-flags;
 -if ((mask  FL_FREEZE) == FL_FREEZE) {
 -rb_raise(rb_eRuntimeError, can't modify frozen/immutable hash);
 +if (OBJ_FROZEN(hash)) {
 +rb_error_frozen(hash);
 }
 -if ((mask  FL_TAINT) == FL_TAINT) {
 -if (rb_safe_level() = 4) {
 -rb_raise(rb_eSecurityError, Insecure: can't modify hash);
 -}
 +if (!OBJ_UNTRUSTED(hash)  rb_safe_level() =  4) {
 +rb_raise(rb_eSecurityError, Insecure: can't modify hash);
 }
 }
 
 
 ___
 macruby-changes mailing list
 macruby-chan...@lists.macosforge.org
 http://lists.macosforge.org/mailman/listinfo.cgi/macruby-changes
 
 
 ___
 MacRuby-devel mailing list
 MacRuby-devel@lists.macosforge.org
 http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
 
 
 modify_check_patch.txtbm_hash.rb___
 MacRuby-devel mailing list
 MacRuby-devel@lists.macosforge.org
 http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

___
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] Setting properties on a dereferenced NSRangePointer has no effect

Hi Caio,

Sorry for the late response. This is a limitation of our implementation of 
pointers. Sadly, I don't recall the problem anymore (as I wrote that stuff 2 
years ago), but I think it's related to the way we cache the Pointer internal 
data.

For 1.0, we should either document this or try to make 
proposedSelRangePtr[0].location=42 work, as I suspect people will hit the same 
problem. Could you file a ticket? We will continue the investigation there.

Thanks!
Laurent

On Jan 21, 2011, at 1:37 PM, Caio Chassot wrote:

 Hi all,
 
 NSFormatter defines a method with the following selector:
 

 isPartialStringValid:proposedSelectedRange:originalString:originalSelectedRange:errorDescription:
 
 This is its signature:
 
- (BOOL)isPartialStringValid:(NSString **)partialStringPtr
   proposedSelectedRange:(NSRangePointer)proposedSelRangePtr
  originalString:(NSString *)origString
   originalSelectedRange:(NSRange)origSelRange
errorDescription:(NSString **)error
 
 
 The relevant bit here is the proposedSelRangePtr argument, which is a 
 NSRangePointer.
 
 When subclassing NSFormatter in ruby, I define the method as:
 
def isPartialStringValid(partialStringPtr,
   proposedSelectedRange:proposedSelRangePtr,
  originalString:origString,
   originalSelectedRange:origSelRange,
errorDescription:error)
 
 
 When implementing the Cocoa Programming exercises in MacRuby, I ran across 
 the following situation:
 
 At some point in that method definition, in the original code, Aaron sets the 
 range properties directly:
 
proposedSelRangePtr-location = [*partialStringPtr length];
proposedSelRangePtr-length   = [match length] - 
 proposedSelRangePtr-location;
 
 
 Initially, I did similar in MacRuby
 
proposedSelRangePtr[0].location = partialStringPtr[0].length
proposedSelRangePtr[0].length   = match.length - 
 proposedSelRangePtr[0].location
 
 
 This has no effect. It does not raise, but the values go unchanged. I can 
 NSLog the range values before and after and they're the same.
 
 My final solution was to assign a new range to that location:
 
proposedSelRangePtr[0] = NSRange.new(partialStringPtr[0].length, 
 match.length - partialStringPtr[0].length)
 
 
 But I wonder why setting the range properties had no effect. MacRuby bug?
 
 ___
 MacRuby-devel mailing list
 MacRuby-devel@lists.macosforge.org
 http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

___
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] Thread safety in apply example?

Hi Charles!

Sorry for the late response.

As others have noted, in this snippet, #apply is called on a sequential queue 
(queues created by Queue.new are always sequential), therefore there shouldn't 
be any problem here. If the queue was concurrent, however, there would be a 
thread safety issue.

I think this rdoc snippet should be rewritten to avoid confusion.

I see that you're wrapping a GCD-like interface in JRuby, it's very cool! I 
assume you want your interface to be cross platform, but in the case of JRuby 
running on Mac OS X, maybe we can extract our code as a C extension, this way 
JRuby would use the system GCD. Maybe we can also work together on creating a 
good test/spec suite for the GCD interface, because it's currently lacking.

Laurent

On Jan 21, 2011, at 9:57 PM, Charles Oliver Nutter wrote:

 I'm curious about this example in Queue#apply's rdoc:
 
 * gcdq = Dispatch::Queue.new('doc')
 * @result = []
 * gcdq.apply(5) {|i| @result[i] = i*i }
 * p @result  #= [0, 1, 4, 9, 16, 25]
 
 apply is said to issue the jobs in parallel, so this would be making
 concurrent updates to the @result array. Are simple arrays in MacRuby
 thread-safe?
 
 - Charlie
 ___
 MacRuby-devel mailing list
 MacRuby-devel@lists.macosforge.org
 http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

___
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] Concurrency bug in ControlTower