Re: [MacRuby-devel] Default Test Framework

2009-10-09 Thread Eloy Duran 

Hi,

As we're targeting 1.9 compatibility, the library that will be shipped  
with MacRuby is minitest. Atm however, we still have an older version  
of the stdlib, which means we still ship test-unit.


I myself have put my trust in Bacon, and as far as a "blessing" goes,  
all critical bugs encountered with Bacon have been fixed.


Eloy

On 9 okt 2009, at 07:58, Josh Ballanco wrote:


Hey all!

So, as I've been working on a recipe for testing with MacRuby, I  
realized that it would probably be good to discuss the topic of  
"blessing" a particular test suite. Obviously, with macgem all of  
the Ruby test suites are available to use, but for the purposes of  
tutorials and whatnot, having one default that ships with MacRuby  
would help reduce confusion and at least get people started on the  
road to testing. Personally, I think whatever ships with MacRuby  
should ideally be light-weight, extensible, and integrated. In other  
words, the heavy hitters like Test::Unit, RSpec, and Shoulda are  
out. That leaves:


-- minitest: The "blessed" test library of Matz Ruby. It's very  
minimal, but documentation is somewhat lacking. I also couldn't find  
an easy spot to hook into the API to customize output format. Still,  
if it's good enough for Matz Ruby...


-- bacon: Small, and output is easily customized. I'm currently  
looking at what would be required to get bacon's output to play  
nicer with Xcode. The one unknown (for me, at least) is popularity/ 
familiarity in the larger Ruby community.


-- OCUnit: This is the Objective C test library that ships with  
Xcode. We could put a thin wrapper around it, and then not worry  
about having to ship a separate test library. The major downside to  
OCUnit is that it's not very "Ruby-ish".


I'm quite enamored with bacon, but I'm worried about the possibility  
that developers coming from Matz Ruby might start to expect minitest  
to be included. That might be a remote possibility, though, as it  
seems like minitest isn't currently that popular. If there are  
others I missed, or if you disagree with any points, speak up!


Cheers,

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


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

Re: [MacRuby-devel] install from command line Re: MacRuby 0.5 beta 1

2009-10-09 Thread Claudio Poli 
don't know what you mean with merge it, however there are apis to ease  
the download:

http://macruby.icoretech.org/api

a curl -O http://macruby.icoretech.org/latest/macruby_nightly- 
latest.pkg should suffice :)


claudio

Il giorno 09/ott/2009, alle ore 01.19, Laurent Sansonetti ha scritto:


Hi Ernie,

On Oct 8, 2009, at 2:25 PM, Ernest N. Prabhakar, Ph.D. wrote:


Hi Wayne,

On Oct 8, 2009, at 1:59 PM, Wayne Seguin wrote:

Is it possible to a) install from command line




$ unzip ~/Downloads/MacRuby\ 0.5\ beta\ 1.zip
$ cd ~/Downloads/MacRuby\ 0.5\ beta\ 1
$ sudo installer -pkg MacRuby\ 0.5\ beta\ 1.pkg  -target /


I totally didn't know about that.

Anyone to create a macruby_update_nightly script that would fetch  
the latest nightly build and merge it ? :)


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


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

[MacRuby-devel] Empty Ruby Template

2009-10-09 Thread Jesse Read 
I saw in the trunk status update, this line:
"- Added an empty Ruby template file"

Which I believes corresponds to
this changeset
on Trac, where Matt added an Xcode Ruby file template.

I manually installed the template, but are there any plans to add these into
the installers, either for 0.5b2 or the nightlies? I doubt much will change
with them, but other would probably enjoy them if they see them installed.

Thanks, and keep up the great work!

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

Re: [MacRuby-devel] MacRuby 0.5 beta

2009-10-09 Thread Jordan K. Hubbard 
Just judging by the initial round of twitter / blog postings, the #1  
problem people are having trouble with 0.5B1 is obtaining LLVM.
Antonio has already put together a nice blog posting about it (http://antoniocangiano.com/2009/10/08/getting-macrubys-compiler-to-work/ 
), but shouldn't his instructions be on the MacRuby blog, seeing as  
how Laurent's announcement is the first thing many people are going to  
see?  Even better, maybe an LLVM package to go along with MacRuby,  
also linked to on the site?  Given that you need a very specific (e.g.  
recent, from trunk) version of LLVM for MacRuby to work at all, this  
seems pretty reasonable.  If the instructions were "just go grab llvm  
2.6" then I might feel differently.


- Jordan

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

Re: [MacRuby-devel] MacRuby 0.5 beta

2009-10-09 Thread Vincent Isambart 
> Even better, maybe an LLVM package to go along with MacRuby, also linked to
> on the site?  Given that you need a very specific (e.g. recent, from trunk)
> version of LLVM for MacRuby to work at all, this seems pretty reasonable.

I think Laurent wants to include it directly in the next MacRuby installer.
Though I was just thinking we should be careful not to overwrite the
version of LLVM the user might have, putting our version in MacRuby's
directory, not at the place we MacRuby developers have it installed
currently (/usr/local).

>  If the instructions were "just go grab llvm 2.6" then I might feel
> differently.

At first I was thinking we might be able to use the final 2.6, but
it's in a pretty bad shape. We could not use LLVM 2.5 because of
problems regarding exception handling. And it looks like we won't be
able to use LLVM 2.6 because of... problems regarding exception
handling...
___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

[MacRuby-devel] [MacRuby] #370: Inconsistency between macruby and ruby in a simple class

2009-10-09 Thread MacRuby 
#370: Inconsistency between macruby and ruby in a simple class
---+
 Reporter:  kfow...@…  |   Owner:  lsansone...@…
 Type:  defect |  Status:  new  
 Priority:  major  |   Milestone:  MacRuby 0.5  
Component:  MacRuby|Keywords:   
---+
 running this script:
 {{{
 class W
   def initialize(w)
 @w = w
   end
 end

 class M
   def initialize(m)
 @m = m
   end
 end


 printf("%s\n" , W.new(W.new(1)).inspect)
 printf("%s\n" , M.new(M.new(1)).inspect)
 printf("%s\n" , W.new(M.new(1)).inspect)
 printf("%s\n" , M.new(W.new(1)).inspect)
 }}}

 on ruby1.9 from mac ports (ruby 1.9.1p243 (2009-07-16 revision 24175)
 [i386-darwin10]) yields this:
 {{{
 #>
 #>
 #>
 #>
 }}}

 on macruby 0.5 (MacRuby version 0.5 (ruby 1.9.0) [universal-darwin10.0,
 x86_64]) built from source
 (http://svn.macosforge.org/repository/ruby/MacRuby/tr...@2771) against
 llvm (https://llvm.org/svn/llvm-project/llvm/tr...@82747) yields this:
 {{{
 ##-
 ##-
 ##->
 ##->
 }}}

 Ruby 1.8.7 from 10.6:
 {{{
 #>
 #>
 #>
 #>
 }}}

 jruby 1.3.1:
 {{{
 #>
 #>
 #>
 #>
 }}}

-- 
Ticket URL: 
MacRuby 

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

Re: [MacRuby-devel] Empty Ruby Template

2009-10-09 Thread Matt Aimonetti 
The file should be part of the nightly package. I have to admit I failed to
check tho.
Can you please check that it's not a right access instead of the file
missing from the package?

Thanks,

- Matt


On Fri, Oct 9, 2009 at 1:01 AM, Jesse Read  wrote:

> I saw in the trunk status update, this line:
> "- Added an empty Ruby template file"
>
> Which I believes corresponds to 
> this changeset
> on Trac, where Matt added an Xcode Ruby file template.
>
> I manually installed the template, but are there any plans to add these
> into the installers, either for 0.5b2 or the nightlies? I doubt much will
> change with them, but other would probably enjoy them if they see them
> installed.
>
> Thanks, and keep up the great work!
>
> — Jesse
>
> ___
> MacRuby-devel mailing list
> [email protected]
> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
>
>
___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] [MacRuby] #370: Inconsistency between macruby and ruby in a simple class

2009-10-09 Thread MacRuby 
#370: Inconsistency between macruby and ruby in a simple class
---+
 Reporter:  kfow...@…  |   Owner:  lsansone...@…
 Type:  defect |  Status:  new  
 Priority:  major  |   Milestone:  MacRuby 0.5  
Component:  MacRuby|Keywords:   
---+

Comment(by kfow...@…):

 if I change M to extend W:
 {{{class M < W}}}...
 then I get:
 {{{
 ##-
 ##-
 ##-
 ##->
 }}}

-- 
Ticket URL: 
MacRuby 

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

Re: [MacRuby-devel] MacRuby 0.5 beta

2009-10-09 Thread Laurent Sansonetti 

Jordan,

Users should not need to obtain and install LLVM. MacRuby uses it  
statically. There was a mistake in the installer, we forgot to bundle  
llc (LLVM compiler tool) used by macrubyc, this will be fixed in the  
upcoming nightly builds then in the next beta.


Laurent

On Oct 9, 2009, at 1:02 AM, Jordan K. Hubbard wrote:

Just judging by the initial round of twitter / blog postings, the #1  
problem people are having trouble with 0.5B1 is obtaining LLVM.
Antonio has already put together a nice blog posting about it (http://antoniocangiano.com/2009/10/08/getting-macrubys-compiler-to-work/ 
), but shouldn't his instructions be on the MacRuby blog, seeing as  
how Laurent's announcement is the first thing many people are going  
to see?  Even better, maybe an LLVM package to go along with  
MacRuby, also linked to on the site?  Given that you need a very  
specific (e.g. recent, from trunk) version of LLVM for MacRuby to  
work at all, this seems pretty reasonable.  If the instructions were  
"just go grab llvm 2.6" then I might feel differently.


- Jordan

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


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

Re: [MacRuby-devel] [MacRuby] #370: Inconsistency between macruby and ruby in a simple class

2009-10-09 Thread MacRuby 
#370: Inconsistency between macruby and ruby in a simple class
---+
 Reporter:  kfow...@…  |   Owner:  lsansone...@…
 Type:  defect |  Status:  new  
 Priority:  major  |   Milestone:  MacRuby 0.5  
Component:  MacRuby|Keywords:   
---+

Comment(by kfow...@…):

 "return self" appears to be a work around:
 {{{
   def initialize(m)
 @m = m
 return self
   end
 }}}

-- 
Ticket URL: 
MacRuby 

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

Re: [MacRuby-devel] [MacRuby] #370: Inconsistency between macruby and ruby in a simple class

2009-10-09 Thread MacRuby 
#370: Inconsistency between macruby and ruby in a simple class
---+
 Reporter:  kfow...@…  |   Owner:  lsansone...@…
 Type:  defect |  Status:  new  
 Priority:  major  |   Milestone:  MacRuby 0.5  
Component:  MacRuby|Keywords:   
---+

Comment(by conra...@…):

 Yes, there's seems to be an issue with the initialize method returning the
 instance to the caller.  However, you can rewrite the classes as follows
 and the initialize method seems to work as expected:

 {{{

 W = Class.new do
define_method :initialize do |w|
   @w = w
end
 end

 M = Class.new do
define_method :initialize do |m|
   @m = m
end
 end

 printf("%s\n" , W.new(W.new(1)).inspect)
 printf("%s\n" , M.new(M.new(1)).inspect)
 printf("%s\n" , W.new(M.new(1)).inspect)
 printf("%s\n" , M.new(W.new(1)).inspect)

 }}}

 Next, adding 'self' as the last executable statement within the
 'initialize' method provides a temporary workaround.  Finally, if I'm
 reading the code correctly, the function 'rb_class_new_instance0' within
 the 'object.c' file may be a starting point for resolving the issue.

-- 
Ticket URL: 
MacRuby 

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

[MacRuby-devel] [MacRuby] #371: Module methods included in the class Module are not visible to other classes.

2009-10-09 Thread MacRuby 
#371: Module methods included in the class Module are not visible to other
classes.
-+--
 Reporter:  m...@…   |   Owner:  lsansone...@…
 Type:  defect   |  Status:  new  
 Priority:  blocker  |   Milestone:   
Component:  MacRuby  |Keywords:   
-+--
 {{{
 module A
   def b
 puts 'b'
   end
 end

 class Module
   include A
 end

 class C
   b()
 end
 }}}

 Running the above on Ruby 1.9 prints out 'b'.  Running it on MacRuby 0.5
 generates an "undefined method `b' for C:Class (NoMethodError)"

-- 
Ticket URL: 
MacRuby 

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

[MacRuby-devel] Building MacRuby r2765 with llvm r82747 failed on core duo macbook, Leopard

2009-10-09 Thread hiroshi saito 
Hi all,

I failed to build llvm r82747 and MacRuby r2765 following the
instruction of README.
I use core duo macbook and Leopard.

$ svn co -r 2765
http://svn.macosforge.org/repository/ruby/MacRuby/trunk MacRuby-trunk
$ svn co -r 82747 https://llvm.org/svn/llvm-project/llvm/trunk llvm-trunk
$ cd llvm-trunk
$ UNIVERSAL=1 UNIVERSAL_ARCH="i386 x86_64" ENABLE_OPTIMIZED=1 make
...
llvm[2]: Compiling BasicBlockTracing.c for Release build (bytecode)
...
llvm-gcc-4.2: -E, -S, -save-temps and -M options are not allowed with
multiple -arch flags

To avoid the error, omited univsersal environment variables.

$ ENABLE_OPTIMIZED=1 make

It worked.

Next, build MacRuby itself. My llvm isn't universal binary anymore, so
I explicitly specified archs options;

$ PATH=$PATH:~/Desktop/wc/MacRuby/llvm-trunk/Release/bin rake archs=i386
...
/usr/bin/g++ -I/Users/hiroshi/Desktop/wc/MacRuby/llvm-trunk/include
-I/Users/hiroshi/Desktop/wc/MacRuby/llvm-trunk/include  -D_DEBUG
-D_GNU_SOURCE -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -O3
-fno-common -Woverloaded-virtual -I. -I./include -g -Wall -arch i386
-Wno-parentheses -Wno-deprecated-declarations -Werror -Winline --param
inline-unit-growth=1 --param large-function-growth=1 -x
objective-c++ -c dispatcher.cpp -o dispatcher.o
cc1objplus: warnings being treated as errors
/Users/hiroshi/Desktop/wc/MacRuby/llvm-trunk/include/llvm/Type.h:417:
warning: ‘void llvm::PATypeHandle::addUser()’ was used before it was
declared inline
...

I got warnings which stopped build. So added "allow_build_warnings=true";

$ PATH=$PATH:~/Desktop/wc/MacRuby/llvm-trunk/Release/bin rake
archs=i386 allow_build_warnings=true
...
./miniruby -I. -I./lib bin/rubyc --internal -C "rbconfig.rb" -o "./rbconfig.rbo"
terminate called after throwing an instance of 'RoxorReturnFromBlockException*'
rake aborted!

I stucked. I don't have any idea to avoid the exception yet.

Also, I tried some of ideas;
* use gcc-4.2 instead of default version of gcc 4.0 on Leopard, but
this doesn't seem to have any effect.
* append --disable-dependency-tracking to ./configure of llvm

Before continue to struggle, I want some help.
If someone succeeded to build MacRuby after releasing 0.5 beta1, please help me.
Or have any idea, I'll try it.

Thanks in advance.



== Lines below are more details of the build fialures:

$ uname -a
Darwin hiroshi-macbook.local 9.8.0 Darwin Kernel Version 9.8.0: Wed
Jul 15 16:55:01 PDT 2009; root:xnu-1228.15.4~1/RELEASE_I386 i386
$ gcc -v
..
gcc version 4.0.1 (Apple Inc. build 5493)

$ svn co -r 2765
http://svn.macosforge.org/repository/ruby/MacRuby/trunk MacRuby-trunk
$ svn co -r 82747 https://llvm.org/svn/llvm-project/llvm/trunk llvm-trunk
$ cd llvm-trunk
$ ./configure
$ UNIVERSAL=1 UNIVERSAL_ARCH="i386 x86_64" ENABLE_OPTIMIZED=1 make
...
llvm[2]: Compiling BasicBlockTracing.c for Release build (bytecode)
/Developer/usr/bin/llvm-gcc
-I/Users/hiroshi/Desktop/wc/MacRuby/llvm-trunk/include
-I/Users/hiroshi/Desktop/wc/MacRuby/llvm-trunk/runtime/libprofile
-D_DEBUG -D_GNU_SOURCE -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS
-O3  -fno-common   -mmacosx-version-min=10.5 -pedantic -Wno-long-long
-Wall -W -Wno-unused-parameter -Wwrite-strings  -arch i386 -arch
x86_64 BasicBlockTracing.c -o
/Users/hiroshi/Desktop/wc/MacRuby/llvm-trunk/runtime/libprofile/Release/BasicBlockTracing.ll
-S -emit-llvm
llvm-gcc-4.2: -E, -S, -save-temps and -M options are not allowed with
multiple -arch flags
make[2]: *** 
[/Users/hiroshi/Desktop/wc/MacRuby/llvm-trunk/runtime/libprofile/Release/BasicBlockTracing.ll]
Error 1
make[1]: *** [libprofile/.makeall] Error 2
make: *** [all] Error 1

Instead of building llvm with multiple archs, I tried to build it
without universal flags:

$ ENABLE_OPTIMIZED=1 make

It works, but next, building macruby itself failed.

$ cd ..; cd MacRuby-trunk
$ PATH=$PATH:~/Desktop/wc/MacRuby/llvm-trunk/Release/bin rake archs=i386
...
/usr/bin/g++ -I/Users/hiroshi/Desktop/wc/MacRuby/llvm-trunk/include
-I/Users/hiroshi/Desktop/wc/MacRuby/llvm-trunk/include  -D_DEBUG
-D_GNU_SOURCE -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -O3
-fno-common -Woverloaded-virtual -I. -I./include -g -Wall -arch i386
-Wno-parentheses -Wno-deprecated-declarations -Werror -Winline --param
inline-unit-growth=1 --param large-function-growth=1 -x
objective-c++ -c dispatcher.cpp -o dispatcher.o
cc1objplus: warnings being treated as errors
/Users/hiroshi/Desktop/wc/MacRuby/llvm-trunk/include/llvm/Type.h:417:
warning: ‘void llvm::PATypeHandle::addUser()’ was used before it was
declared inline
/Users/hiroshi/Desktop/wc/MacRuby/llvm-trunk/include/llvm/AbstractTypeUser.h:95:
warning: previous non-inline declaration here
/Users/hiroshi/Desktop/wc/MacRuby/llvm-trunk/include/llvm/Type.h:422:
warning: ‘void llvm::PATypeHandle::removeUser()’ was used before it
was declared inline
/Users/hiroshi/Desktop/wc/MacRuby/llvm-trunk/include/llvm/AbstractTypeUser.h:96:
warning: previous non-inline declaration here
/Users/hiroshi/Desktop/w

[MacRuby-devel] [MacRuby] #372: Error while requiring rss module

2009-10-09 Thread MacRuby 
#372: Error while requiring rss module
--+-
 Reporter:  dml...@…  |   Owner:  lsansone...@…  
 Type:  defect|  Status:  new
 Priority:  minor |   Milestone:  MacRuby 0.5
Component:  MacRuby   |Keywords:  rss, macruby 0.5 beta 1
--+-
 Using macruby 0.5 beta 1,


 {{{
 ~> macruby --version
 MacRuby version 0.5 (ruby 1.9.0) [universal-darwin10.0, x86_64]
 ~> cat rss.rb
 require 'rss'
 ~> macruby rss.rb
 rss.rb:1:in `': undefined method `split' for nil:NilClass
 (NoMethodError)
 }}}

-- 
Ticket URL: 
MacRuby 

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

Re: [MacRuby-devel] Empty Ruby Template

2009-10-09 Thread Jesse Read 
I just checked the last nightly, and it only installs the following Xcode
templates:
/Library/Application Support/Developer/Xcode/3.0/Target Templates
/Library/Application Support/Developer/Xcode/3.0/Project Templates
/Library/Application Support/Developer/Xcode/Shared/Target Templates
/Library/Application Support/Developer/Xcode/Shared/Project Templates

No File Templates, I just manually copied the File Templates folder from
/misc/xcode-templates in trunk to the 3.0 and Shared folders, mimicking the
nightly installer.

— Jesse


On Fri, Oct 9, 2009 at 4:42 AM, Matt Aimonetti wrote:

> The file should be part of the nightly package. I have to admit I failed to
> check tho.
> Can you please check that it's not a right access instead of the file
> missing from the package?
>
> Thanks,
>
> - Matt
>
>
> On Fri, Oct 9, 2009 at 1:01 AM, Jesse Read  wrote:
>
>> I saw in the trunk status update, this line:
>> "- Added an empty Ruby template file"
>>
>> Which I believes corresponds to 
>> this changeset
>> on Trac, where Matt added an Xcode Ruby file template.
>>
>> I manually installed the template, but are there any plans to add these
>> into the installers, either for 0.5b2 or the nightlies? I doubt much will
>> change with them, but other would probably enjoy them if they see them
>> installed.
>>
>> Thanks, and keep up the great work!
>>
>> — Jesse
>>
>> ___
>> MacRuby-devel mailing list
>> [email protected]
>> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
>>
>>
>
> ___
> MacRuby-devel mailing list
> [email protected]
> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
>
>
___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] [MacRuby] #371: Module methods included in the class Module are not visible to other classes.

2009-10-09 Thread MacRuby 
#371: Module methods included in the class Module are not visible to other
classes.
-+--
 Reporter:  m...@…   |   Owner:  lsansone...@…
 Type:  defect   |  Status:  new  
 Priority:  blocker  |   Milestone:   
Component:  MacRuby  |Keywords:   
-+--

Comment(by keith.gautre...@…):

 It seems that MacRuby treats modules differently than Ruby 1.9.  You
 shouldn't be able to instantiate a named module using the new method, i.e.

 A = Module.new do
   def meth1
 "hello"
   end
 end

 a = A.new (shouldn't work)
 => NoMethodError: undefined method `new' for A:Module

 but it does in MacRuby returning an instance of A:Module which responds to
 the meth1 call
 => #

 a.meth1
 =>"hello"

-- 
Ticket URL: 
MacRuby 

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

Re: [MacRuby-devel] MacRuby 0.5 beta

2009-10-09 Thread Jordan K. Hubbard 

Ah, OK.  Never mind then!

On Oct 9, 2009, at 1:56 AM, Laurent Sansonetti wrote:


Jordan,

Users should not need to obtain and install LLVM. MacRuby uses it  
statically. There was a mistake in the installer, we forgot to  
bundle llc (LLVM compiler tool) used by macrubyc, this will be fixed  
in the upcoming nightly builds then in the next beta.


Laurent

On Oct 9, 2009, at 1:02 AM, Jordan K. Hubbard wrote:

Just judging by the initial round of twitter / blog postings, the  
#1 problem people are having trouble with 0.5B1 is obtaining  
LLVM.   Antonio has already put together a nice blog posting about  
it (http://antoniocangiano.com/2009/10/08/getting-macrubys-compiler-to-work/ 
), but shouldn't his instructions be on the MacRuby blog, seeing as  
how Laurent's announcement is the first thing many people are going  
to see?  Even better, maybe an LLVM package to go along with  
MacRuby, also linked to on the site?  Given that you need a very  
specific (e.g. recent, from trunk) version of LLVM for MacRuby to  
work at all, this seems pretty reasonable.  If the instructions  
were "just go grab llvm 2.6" then I might feel differently.


- Jordan

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


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


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

Re: [MacRuby-devel] Empty Ruby Template

2009-10-09 Thread Matt Aimonetti 
thx, I'll look at  that tonight after work.

- Matt

On Fri, Oct 9, 2009 at 9:00 AM, Jesse Read  wrote:

> I just checked the last nightly, and it only installs the following Xcode
> templates:
> /Library/Application Support/Developer/Xcode/3.0/Target Templates
> /Library/Application Support/Developer/Xcode/3.0/Project Templates
> /Library/Application Support/Developer/Xcode/Shared/Target Templates
> /Library/Application Support/Developer/Xcode/Shared/Project Templates
>
> No File Templates, I just manually copied the File Templates folder from
> /misc/xcode-templates in trunk to the 3.0 and Shared folders, mimicking the
> nightly installer.
>
> — Jesse
>
>
>
> On Fri, Oct 9, 2009 at 4:42 AM, Matt Aimonetti wrote:
>
>> The file should be part of the nightly package. I have to admit I failed
>> to check tho.
>> Can you please check that it's not a right access instead of the file
>> missing from the package?
>>
>> Thanks,
>>
>> - Matt
>>
>>
>> On Fri, Oct 9, 2009 at 1:01 AM, Jesse Read  wrote:
>>
>>> I saw in the trunk status update, this line:
>>> "- Added an empty Ruby template file"
>>>
>>> Which I believes corresponds to 
>>> this changeset
>>> on Trac, where Matt added an Xcode Ruby file template.
>>>
>>> I manually installed the template, but are there any plans to add these
>>> into the installers, either for 0.5b2 or the nightlies? I doubt much will
>>> change with them, but other would probably enjoy them if they see them
>>> installed.
>>>
>>> Thanks, and keep up the great work!
>>>
>>> — Jesse
>>>
>>> ___
>>> MacRuby-devel mailing list
>>> [email protected]
>>> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
>>>
>>>
>>
>> ___
>> MacRuby-devel mailing list
>> [email protected]
>> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
>>
>>
>
> ___
> MacRuby-devel mailing list
> [email protected]
> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
>
>
___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] [MacRuby] #370: Inconsistency between macruby and ruby in a simple class

2009-10-09 Thread MacRuby 
#370: Inconsistency between macruby and ruby in a simple class
---+
 Reporter:  kfow...@…  |   Owner:  lsansone...@…
 Type:  defect |  Status:  new  
 Priority:  major  |   Milestone:  MacRuby 0.5  
Component:  MacRuby|Keywords:   
---+

Comment(by lsansone...@…):

 Good catch, the problem is definitely in object.c:1896

 {{{
 if (init_obj != Qnil) {
 p = CLASS_OF(init_obj);
 while (p != 0) {
 if (p == klass) {
 return init_obj;
 }
 p = RCLASS_SUPER(p);
 }
 }
 }}}

 If I remember correctly, this was added because some classes (Array for
 example) return different objects during #initialize that should be taken
 into account. The code should probably be altered to only handle these
 objects.

-- 
Ticket URL: 
MacRuby 

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

[MacRuby-devel] MacRuby gem only

2009-10-09 Thread Matt Aimonetti 
Any idea how we should flag gems that are MacRuby only like textorize-mr? I
don't think the platform flag is legit so I'm not sure what to use.
Any ideas?

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

[MacRuby-devel] [MacRuby] #373: protected methods aren't

2009-10-09 Thread MacRuby 
#373: protected methods aren't
-+--
 Reporter:  chr...@… |   Owner:  lsansone...@…
 Type:  defect   |  Status:  new  
 Priority:  blocker  |   Milestone:   
Component:  MacRuby  |Keywords:  protected access 
-+--
 Working through a trivial variation on the example class presented in
 Chapter 3 of PragProg's Programming Ruby 1.9, I noticed that MacRuby 0.5
 beta 1 doesn't enforce protected protection status of a method.  It does
 however enforce private protection status.  I do not have this problem
 with the same code run by Ruby 1.8.7 as shipped with Mac OS X 10.6.  I
 presume that the example in the PragProg book is valid for Ruby 1.9.

-- 
Ticket URL: 
MacRuby 

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

Re: [MacRuby-devel] [MacRuby] #373: protected methods aren't

2009-10-09 Thread MacRuby 
#373: protected methods aren't
-+--
 Reporter:  chr...@… |   Owner:  lsansone...@…
 Type:  defect   |  Status:  new  
 Priority:  blocker  |   Milestone:   
Component:  MacRuby  |Keywords:  protected access 
-+--

Comment(by lsansone...@…):

 Oops, looks like we forgot to implement the "protected" visibility :) I
 added this to the TODO list, thanks for the report.

-- 
Ticket URL: 
MacRuby 

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

[MacRuby-devel] [MacRuby] #374: Adding a binding (in IB) prevents instance variables

2009-10-09 Thread MacRuby 
#374: Adding a binding (in IB) prevents instance variables
-+--
 Reporter:  parzi...@…   |   Owner:  lsansone...@…
 Type:  defect   |  Status:  new  
 Priority:  major|   Milestone:   
Component:  MacRuby  |Keywords:   
-+--
 I've got a (MacRuby) subclass of NSWindowController.  If a binding is
 added using Interface Builder, it becomes impossible to have any instance
 variables in my subclass.  What's kind of strange, too, is that removing
 the binding doesn't fix it; so far it seems necessary to delete the object
 in IB and then re-create it.

 I'm using r2771, on a MBP(2007) running 10.6.1.  This was working at some
 point in 0.4, but I think it's been broken for at least a couple weeks or
 more.

 Here's some code in my class to demonstrate.  This gets called in
 awakeFromNib, though I tried adding an instance variable in initWithWindow
 and it came back nil as well :

 {{{
 testSPC = SourcePaneController.new
 puts "testSPC:"
 p testSPC
 @testSPC_iv = SourcePaneController.new
 puts "@testSPC_iv:"
 p @testSPC_iv

 testInt = 3
 puts "testInt:"
 p testInt
 @testInt_iv = 5
 puts "@testInt_iv:"
 p @testInt

 puts "Instance variables are :"
 p self.instance_variables
 }}}




 And the output:
 {{{
 in MainWinController.initWithWindow
 in SourcePaneController.init
 testSPC:
 #
 in SourcePaneController.init
 @testSPC_iv:
 nil
 testInt:
 3
 @testInt_iv:
 nil
 Instance variables are :
 []
 }}}

 As can be seen, the calls to my other class's initializer are working, but
 it's not getting assigned to the instance variable.
 A potentially revealing error occurred when I mistyped one of my test
 variable names.  This is what happens after ' @testSPC_iv = nothing'
 (where 'nothing' is an unassigned variable) :

 {{{
 2009-10-09 12:22:01.975 resynch[1015:a0f] +[MainWinController
 _getValue:forKey:]: unrecognized selector sent to class 0x200238940
 2009-10-09 12:22:01.978 resynch[1015:a0f] +[MainWinController
 _getValue:forKey:]: unrecognized selector sent to class 0x200238940
 2009-10-09 12:22:01.979 resynch[1015:a0f] An uncaught exception was raised
 2009-10-09 12:22:01.979 resynch[1015:a0f] +[MainWinController
 _getValue:forKey:]: unrecognized selector sent to class 0x200238940
 2009-10-09 12:22:01.981 resynch[1015:a0f] *** Terminating app due to
 uncaught exception 'NSInvalidArgumentException', reason:
 '+[MainWinController _getValue:forKey:]: unrecognized selector sent to
 class 0x200238940'
 *** Call stack at first throw:
 (
 0   CoreFoundation  0x7fff83dbf5a4
 __exceptionPreprocess + 180
 1   libobjc.A.dylib 0x7fff87c7c313
 objc_exception_throw + 45
 2   CoreFoundation  0x7fff83e18330
 __CFFullMethodName + 0
 3   CoreFoundation  0x7fff83d9230f
 ___forwarding___ + 751
 4   CoreFoundation  0x7fff83d8e458
 _CF_forwarding_prep_0 + 232
 5   CoreFoundation  0x7fff83d53ffd
 CFDictionaryGetValueIfPresent + 93
 6   libmacruby.dylib0x00010010b4ee
 classname + 126
 7   libmacruby.dylib0x00010010b728
 rb_class_path + 24
 8   libmacruby.dylib0x00010010ba3e
 rb_obj_classname + 46
 9   libmacruby.dylib0x00010006f89f
 rb_any_to_string + 15
 10  libmacruby.dylib0x00010015f697
 rb_vm_call_with_cache2 + 4663
 11  libmacruby.dylib0x000100121199
 rb_funcall + 425
 12  libmacruby.dylib0x00010015f697
 rb_vm_call_with_cache2 + 4663
 13  libmacruby.dylib0x000100121199
 rb_funcall + 425
 14  libmacruby.dylib0x00010006a8f6
 rb_inspect + 22
 15  libmacruby.dylib0x00010003e2a1
 name_err_mesg_to_str + 161
 16  libmacruby.dylib0x000100162d6f
 rb_vm_call + 4783
 17  libmacruby.dylib0x000100070df9
 rb_convert_type + 121
 18  libmacruby.dylib0x0001000f010b
 rb_string_value + 107
 19  libmacruby.dylib0x00010003c62e
 name_err_to_s + 78
 20  libmacruby.dylib0x00010015f697
 rb_vm_call_with_cache2 + 4663
 21  libmacruby.dylib0x000100121199
 rb_funcall + 425
 22  libmacruby.dylib0x000100162d6f
 rb_vm_call + 4783
 23  libmacruby.dylib0x000100175e23
 rb_vm_print_current_exception + 99
 24  libmacruby.dylib

Re: [MacRuby-devel] install from command line Re: MacRuby 0.5 beta 1

2009-10-09 Thread Ernest N. Prabhakar, Ph.D. 
>> Anyone to create a macruby_update_nightly script that would fetch the latest 
>> nightly build and merge it ? :)

Okay, here's a script that should do what Laurent asks:



macruby_get_nightly.sh
Description: Binary data


Note you need to be present to enter the sudo password; not sure if there's an 
easy way around that, or if we should be installing somewhere else.

Try it and let me know if/how it works!

-- Ernie P.

On Oct 9, 2009, at 1:00 AM, Claudio Poli wrote:

> don't know what you mean with merge it, however there are apis to ease the 
> download:
> http://macruby.icoretech.org/api
> 
> a curl -O http://macruby.icoretech.org/latest/macruby_nightly-latest.pkg 
> should suffice :)
> 
> claudio
> 
> Il giorno 09/ott/2009, alle ore 01.19, Laurent Sansonetti ha scritto:
> 
>> Hi Ernie,
>> 
>> On Oct 8, 2009, at 2:25 PM, Ernest N. Prabhakar, Ph.D. wrote:
>> 
>>> Hi Wayne,
>>> 
>>> On Oct 8, 2009, at 1:59 PM, Wayne Seguin wrote:
>> Is it possible to a) install from command line
> 
>>> 
>>> $ unzip ~/Downloads/MacRuby\ 0.5\ beta\ 1.zip
>>> $ cd ~/Downloads/MacRuby\ 0.5\ beta\ 1
>>> $ sudo installer -pkg MacRuby\ 0.5\ beta\ 1.pkg  -target /
>> 
>> I totally didn't know about that.
>> 
>> Anyone to create a macruby_update_nightly script that would fetch the latest 
>> nightly build and merge it ? :)
>> 
>> Laurent
>> ___
>> MacRuby-devel mailing list
>> [email protected]
>> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
> 
> ___
> MacRuby-devel mailing list
> [email protected]
> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

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

[MacRuby-devel] [MacRuby] #375: MacRuby 0.5 beta 1 HotCocoa examples seg fault

2009-10-09 Thread MacRuby 
#375: MacRuby 0.5 beta 1 HotCocoa examples seg fault
-+--
 Reporter:  macr...@…|   Owner:  lsansone...@…
 Type:  defect   |  Status:  new  
 Priority:  blocker  |   Milestone:   
Component:  MacRuby  |Keywords:   
-+--
 MacRuby 0.5 beta 1 HotCocoa examples seg fault.
 Example:


 Process: Calculator [1696]
 Path:
 
/Users/dculbert/dev/MacRuby/HotCocoa/calculator/Calculator.app/Contents/MacOS/Calculator
 Identifier:  com.yourcompany.Calculator
 Version: ??? (???)
 Code Type:   X86-64 (Native)
 Parent Process:  launchd [86]

 Date/Time:   2009-10-09 13:42:45.548 -0700
 OS Version:  Mac OS X 10.6.1 (10B504)
 Report Version:  6
 Sleep/Wake UUID: 84FF5771-DEEE-4B2D-B040-6722A1DD51CA

 Interval Since Last Report:  2227 sec
 Crashes Since Last Report:   1
 Per-App Crashes Since Last Report:   1
 Anonymous UUID:  3D195BF2-A865-4AF8-9EB6-0D3EFC48B294

 Exception Type:  EXC_BAD_ACCESS (SIGSEGV)
 Exception Codes: 0x000d, 0x
 Crashed Thread:  0  Dispatch queue: com.apple.main-thread

 Application Specific Information:
 objc_msgSend() selector name: length
 objc[1696]: garbage collection is ON

 Thread 0 Crashed:  Dispatch queue: com.apple.main-thread
 0   libobjc.A.dylib 0x7fff81db033c objc_msgSend +
 40
 1   libmacruby.dylib0x0001000ba3f0 rb_reg_search2
 + 144
 2   libmacruby.dylib0x0001000f4add str_gsub + 157
 3   libmacruby.dylib0x00010016d80f rb_vm_dispatch
 + 5679
 4   ??? 0x00010110363c 0 + 4312806972
 5   ??? 0x0001011028bd 0 + 4312803517
 6   ??? 0x0001011013b9 0 + 4312798137
 7   ??? 0x000101100869 0 + 4312795241

 Thread 1:
 0   libSystem.B.dylib   0x7fff8814594a
 __workq_kernreturn + 10
 1   libSystem.B.dylib   0x7fff88145d5c
 _pthread_wqthread + 917
 2   libSystem.B.dylib   0x7fff881459c5 start_wqthread
 + 13

 Thread 0 crashed with X86 Thread State (64-bit):
   rax: 0x7fff87a99a88  rbx: 0x000200021d40  rcx:
 0x  rdx: 0x0006
   rdi: 0x00020011a800  rsi: 0x7fff87a99a88  rbp:
 0x7fff5fbfdb40  rsp: 0x7fff5fbfda38
r8: 0x850cd77ff45c0bf4   r9: 0x0006  r10:
 0x0006  r11: 0x726f5020230a2300
   r12: 0x7fff5fbfdd20  r13: 0x00010161d000  r14:
 0x  r15: 0x00020009c9c0
   rip: 0x7fff81db033c  rfl: 0x00010206  cr2:
 0x0001000bab30

 Binary Images:
0x1 -0x10fff +com.yourcompany.Calculator ???
 (1.0) <88630F38-909F-129F-826E-AAD31BFB4579>
 
/Users/dculbert/dev/MacRuby/HotCocoa/calculator/Calculator.app/Contents/MacOS/Calculator
0x13000 -0x100aeef3f +libmacruby.dylib ??? (???)
 
 /Library/Frameworks/MacRuby.framework/Versions/0.5/usr/lib/libmacruby.dylib
 0x7fff5fc0 - 0x7fff5fc3bdef  dyld 132.1 (???)  /usr/lib/dyld
 0x7fff805f9000 - 0x7fff806c5fff  com.apple.CFNetwork 454.4 (454.4)
 
 
/System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/CFNetwork.framework/Versions/A/CFNetwork
 0x7fff806c6000 - 0x7fff806d5fff  com.apple.NetFS 3.2 (3.2)
 <61E3D8BE-A529-20BF-1A11-026EC774820D>
 /System/Library/Frameworks/NetFS.framework/Versions/A/NetFS
 0x7fff80cc4000 - 0x7fff80d05ff7  com.apple.SystemConfiguration
 1.10 (1.10) 
 
/System/Library/Frameworks/SystemConfiguration.framework/Versions/A/SystemConfiguration
 0x7fff80e3f000 - 0x7fff810c0fe7  com.apple.Foundation 6.6 (751)
 
 /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation
 0x7fff8120e000 - 0x7fff81540fef  com.apple.CoreServices.CarbonCore
 859.1 (859.1) <5712C4C1-B18B-88EE-221F-DA04A8EDA029>
 
/System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/CarbonCore.framework/Versions/A/CarbonCore
 0x7fff81b4a000 - 0x7fff81b58ff7  libkxld.dylib ??? (???)
 <823B6BE6-E952-3B3C-3633-8F4D6C4606A8> /usr/lib/system/libkxld.dylib
 0x7fff81dac000 - 0x7fff81e62fe7  libobjc.A.dylib ??? (???)
 <261D97A3-225B-8A00-56AA-F9F27973063F> /usr/lib/libobjc.A.dylib
 0x7fff81eb5000 - 0x7fff81ecbfef  libbsm.0.dylib ??? (???)
 <42D3023A-A1F7-4121-6417-FCC6B51B3E90> /usr/lib/libbsm.0.dylib
 0x7fff82df3000 - 0x7fff82f66fef  com.apple.CoreFoundation 6.6
 (550) <04EC0CC2-6CE4-4EE0-03B9-6C5109398CB1>
 /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation
 0x7fff83936000 - 0x7fff83961ff7  libxslt.1.dylib ??? (???)
 <87A0B228-B24A-C426-C3

Re: [MacRuby-devel] MacRuby gem only

2009-10-09 Thread Keith Gautreaux 
Presumably Macruby gems will be installed with macgem?  Certainly, we
would not want to fork RubyGems, but since the Gem::Platform spec
exists shouldn't macgem only install gems whose Gem::Platform::RUBY is
MacRuby?

For projects like JRuby and Rubinius it makes sense to always have
Gem::Platform::RUBY == 'ruby', but isn't MacRuby a superset of Ruby
the way Objective-C is a superset of C?

As long as RubyGems prevents installation of gems whose
Gem::Platform::RUBY == 'MacRuby' on stock YARV installations I think
this approach is reasonable, but IANEH (I Am Not Eric Hodel).

On Fri, Oct 9, 2009 at 1:55 PM, Matt Aimonetti  wrote:
> Any idea how we should flag gems that are MacRuby only like textorize-mr? I
> don't think the platform flag is legit so I'm not sure what to use.
> Any ideas?
>
> - Matt
>
> ___
> MacRuby-devel mailing list
> [email protected]
> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
>
>



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

Re: [MacRuby-devel] MacRuby gem only

2009-10-09 Thread Conrad Taylor 
Hi, I was thinking that it may time to update the GemSpec to support another
variable called required_ruby_implementation.  Thus, I filled an enhancement
request
https://rubyforge.org/tracker/?func=detail&aid=27269&group_id=126&atid=578

At this time, the GemSpec supports required_ruby_version but says nothing
about the implementation.  Also, it may be a good time to start upgrading
RubyGems as new Ruby implementation are currently in development or has been
released like JRuby.

On Fri, Oct 9, 2009 at 3:03 PM, Keith Gautreaux
wrote:

> Presumably Macruby gems will be installed with macgem?  Certainly, we
> would not want to fork RubyGems, but since the Gem::Platform spec
> exists shouldn't macgem only install gems whose Gem::Platform::RUBY is
> MacRuby?
>
>
The platform here seems to refer more to the type of OS.  Thus,
Gem::Platform::Ruby means
any OS which is a bit misleading.  Are we talking about the OS or the Ruby
implementation?


> For projects like JRuby and Rubinius it makes sense to always have
> Gem::Platform::RUBY == 'ruby', but isn't MacRuby a superset of Ruby
> the way Objective-C is a superset of C?
>
>
Yes, MacRuby would be considered a superset because Ruby has been
implemented on top
of the Objective-C runtime.  This is similar to JRuby, IronRuby, and so on.
 Furthermore, it
might be wise to consider that both Rubinius and JRuby may create gems that
are specific
to their respective implementations.


> As long as RubyGems prevents installation of gems whose
> Gem::Platform::RUBY == 'MacRuby' on stock YARV installations I think
> this approach is reasonable, but IANEH (I Am Not Eric Hodel).


'macgem list -r' to retrieve all the gems that are compatible with MacRuby.
 I have dealt with
this issue with Ruby 1.8.6 and 1.9.1 and it was a nightmare because
required_ruby_version
wasn't added to the GemSpec for the gem in question.  Now, the complexity
grows with new
implementations of Ruby.

Just my 2 cents,

-Conrad


> On Fri, Oct 9, 2009 at 1:55 PM, Matt Aimonetti 
> wrote:
> > Any idea how we should flag gems that are MacRuby only like textorize-mr?
> I
> > don't think the platform flag is legit so I'm not sure what to use.
> > Any ideas?
> >
> > - Matt
> >
> > ___
> > MacRuby-devel mailing list
> > [email protected]
> > http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
> >
> >
>
>
>
> --
> Keith
> ___
> MacRuby-devel mailing list
> [email protected]
> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
>
___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] [MacRuby] #370: Inconsistency between macruby and ruby in a simple class

2009-10-09 Thread MacRuby 
#370: Inconsistency between macruby and ruby in a simple class
---+
 Reporter:  kfow...@…  |Owner:  lsansone...@…
 Type:  defect |   Status:  closed   
 Priority:  major  |Milestone:  MacRuby 0.5  
Component:  MacRuby|   Resolution:  fixed
 Keywords: |  
---+
Changes (by lsansone...@…):

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


Comment:

 After a quick investigation it looks like this code was not necessary
 anymore, I deleted it in r2775.

-- 
Ticket URL: 
MacRuby 

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

Re: [MacRuby-devel] Building MacRuby r2765 with llvm r82747 failed on core duo macbook, Leopard

2009-10-09 Thread Laurent Sansonetti 

Hi,

On Oct 9, 2009, at 4:22 AM, hiroshi saito wrote:


Hi all,

I failed to build llvm r82747 and MacRuby r2765 following the
instruction of README.
I use core duo macbook and Leopard.

$ svn co -r 2765
http://svn.macosforge.org/repository/ruby/MacRuby/trunk MacRuby-trunk
$ svn co -r 82747 https://llvm.org/svn/llvm-project/llvm/trunk llvm- 
trunk

$ cd llvm-trunk
$ UNIVERSAL=1 UNIVERSAL_ARCH="i386 x86_64" ENABLE_OPTIMIZED=1 make
...
llvm[2]: Compiling BasicBlockTracing.c for Release build (bytecode)
...
llvm-gcc-4.2: -E, -S, -save-temps and -M options are not allowed with
multiple -arch flags


Looks like the LLVM build system it picking llvm-gcc instead of gcc.  
This is probably why it's failing.


You probably want to remote llvm-gcc out of your $PATH and try again.


To avoid the error, omited univsersal environment variables.

$ ENABLE_OPTIMIZED=1 make

It worked.

Next, build MacRuby itself. My llvm isn't universal binary anymore, so
I explicitly specified archs options;

$ PATH=$PATH:~/Desktop/wc/MacRuby/llvm-trunk/Release/bin rake  
archs=i386

...
/usr/bin/g++ -I/Users/hiroshi/Desktop/wc/MacRuby/llvm-trunk/include
-I/Users/hiroshi/Desktop/wc/MacRuby/llvm-trunk/include  -D_DEBUG
-D_GNU_SOURCE -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -O3
-fno-common -Woverloaded-virtual -I. -I./include -g -Wall -arch i386
-Wno-parentheses -Wno-deprecated-declarations -Werror -Winline --param
inline-unit-growth=1 --param large-function-growth=1 -x
objective-c++ -c dispatcher.cpp -o dispatcher.o
cc1objplus: warnings being treated as errors
/Users/hiroshi/Desktop/wc/MacRuby/llvm-trunk/include/llvm/Type.h:417:
warning: ‘void llvm::PATypeHandle::addUser()’ was used before it was
declared inline


Mmh, this never happened to me. But I never tried to build MacRuby for  
a single architecture like this yet.


I recommend to rebuild LLVM without llvm-gcc and try again.

Good luck,

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

Re: [MacRuby-devel] [MacRuby] #371: Module methods included in the class Module are not visible to other classes.

2009-10-09 Thread MacRuby 
#371: Module methods included in the class Module are not visible to other
classes.
-+--
 Reporter:  m...@…   |   Owner:  lsansone...@…
 Type:  defect   |  Status:  new  
 Priority:  blocker  |   Milestone:   
Component:  MacRuby  |Keywords:   
-+--

Comment(by lsansone...@…):

 These are 2 different bugs.

-- 
Ticket URL: 
MacRuby 

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

[MacRuby-devel] [MacRuby] #376: The second 'pointer' of a double pointer type is ignored

2009-10-09 Thread MacRuby 
#376: The second 'pointer' of a double pointer type is ignored
-+--
 Reporter:  m...@…   |   Owner:  lsansone...@…
 Type:  defect   |  Status:  new  
 Priority:  blocker  |   Milestone:   
Component:  MacRuby  |Keywords:   
-+--
 The following code worked in 0.4
 {{{
 framework 'Foundation'
 framework 'AudioToolbox'

 load_bridge_support_file '../BridgeSupport/MusicPlayer.bridgesupport'

 class MusicPlayer
   def initialize
 musicPlayer = Pointer.new_with_type '^{OpaqueMusicPlayer}'  # This
 should create a double pointer
 puts musicPlayer.type   # But
 it doesn't
 (result = NewMusicPlayer musicPlayer) == 0 or raise result.to_s
 @musicPlayer = musicPlayer[0]   #
 Causing problems here
   end
 end

 musicPlayer = MusicPlayer.new
 }}}

 But it now generates the following error

 {{{
 $ macruby x.rb
 ^{OpaqueMusicPlayer}
 x.rb:8:in `initialize': unrecognized runtime type `{OpaqueMusicPlayer}'
 (TypeError)
 from core:in `__new__:'
 from x.rb:1:in `'
 }}}

 The error is occuring during the attempt to dereference the double pointer
 at line 10 (despite the error message reporting line 8)

-- 
Ticket URL: 
MacRuby 

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

Re: [MacRuby-devel] [MacRuby] #374: Adding a binding (in IB) prevents instance variables

2009-10-09 Thread MacRuby 
#374: Adding a binding (in IB) prevents instance variables
-+--
 Reporter:  parzi...@…   |Owner:  lsansone...@…
 Type:  defect   |   Status:  closed   
 Priority:  major|Milestone:  MacRuby 0.5  
Component:  MacRuby  |   Resolution:  fixed
 Keywords:   |  
-+--
Changes (by lsansone...@…):

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


Comment:

 Matthias Neeracher was kind enough to contribute some KVO specs that were
 reproducing your crash, and I fixed the bugs in r2778. Please give it a
 try again and let us know if you still have problems.

-- 
Ticket URL: 
MacRuby 

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

[MacRuby-devel] Do the nightly builds continue from the latest beta

2009-10-09 Thread Paul Howson 
This might be an obvious question, but are the nightly builds (and the  
nightly build installers) an evolution from whatever is the latest  
beta? In other words, are the official betas just particular snapshots  
of the ongoing nightly build process?



Paul Howson
Warwick Qld Australia

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

Re: [MacRuby-devel] Do the nightly builds continue from the latest beta

2009-10-09 Thread Matt Aimonetti 
The answer is yes :) With a different packager tho.

- Matt

On Fri, Oct 9, 2009 at 9:39 PM, Paul Howson  wrote:

> This might be an obvious question, but are the nightly builds (and the
> nightly build installers) an evolution from whatever is the latest beta? In
> other words, are the official betas just particular snapshots of the ongoing
> nightly build process?
>
> 
> Paul Howson
> Warwick Qld Australia
>
> ___
> MacRuby-devel mailing list
> [email protected]
> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
>
___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] [MacRuby] #374: Adding a binding (in IB) prevents instance variables

2009-10-09 Thread Michael Winterstein 

r2778 works fine. Great to have some specs in there.

On Oct 9, 2009, at 7:40 PM, MacRuby wrote:


#374: Adding a binding (in IB) prevents instance variables
- 
+--

Reporter:  parzi...@…   |Owner:  lsansone...@…
Type:  defect   |   Status:  closed
Priority:  major|Milestone:  MacRuby 0.5
Component:  MacRuby  |   Resolution:  fixed
Keywords:   |
- 
+--

Changes (by lsansone...@…):

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


Comment:

Matthias Neeracher was kind enough to contribute some KVO specs that  
were
reproducing your crash, and I fixed the bugs in r2778. Please give  
it a

try again and let us know if you still have problems.

--
Ticket URL: 
MacRuby 

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


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