July 2009 - MacRuby-devel - lists.macosforge.org

Re: [MacRuby-devel] web site nits (resend)
by Mike Sassak 15 Jul '09

15 Jul '09

On Wed, Jul 15, 2009 at 11:31 AM, Rich Morin <rdm(a)cfcl.com> wrote: > No big deal, but it has been a week since I posted this and there > has been no visible response. Is there a better way to get this > on the RADAR? > > At 00:33 -0700 7/7/09, Rich Morin wrote: > > On http://www.macruby.org/documentation.html, all of the entries > > (under Screencasts, Tutorials, Talks, and Recipes) are listed as > > being in 2009. At least some of these (eg, the ones in November) > > should say 2008. Could someone with the appropriate permissions > > fix these? > > Hi Rich, The source for the website is available in Subversion [0], and is written with a Ruby website generation tool called Webby [1]. I can't speak for the core team, but I bet they'd appreciate it if you grabbed a copy of the source and submitted patches via Trac. Mike [0] http://www.macruby.org/trac/browser/MacRubyWebsite [1] http://webby.rubyforge.org/

3 2

web site nits
by Rich Morin 15 Jul '09

15 Jul '09

On http://www.macruby.org/documentation.html, all of the entries (under Screencasts, Tutorials, Talks, and Recipes) are listed as being in 2009. At least some of these (eg, the ones in November) should say 2008. Could someone with the appropriate permissions fix these? -r -- http://www.cfcl.com/rdm Rich Morin http://www.cfcl.com/rdm/resume rdm(a)cfcl.com http://www.cfcl.com/rdm/weblog +1 650-873-7841 Technical editing and writing, programming, and web development

1 1

experimental branch: status update
by Laurent Sansonetti 12 Jul '09

12 Jul '09

Another update on the experimental branch! Highlights are: - A much better AOT (ahead-of-time) compiler, now available as a separate command line executable, macrubyc. It can compile some MacRuby sample code. Details at the very end of this message. - IB support is back! Once you install experimental IB can show the classes and their outlets/actions that you defined in your Ruby code, inside Xcode, as previously. It still uses the same command line tool based on Ripper. - More Ruby and Cocoa compatibility. Detailed changes: - AOT compiler: added support for compilation of NSObject, IDs, blocks, dynamic variables, instance variables, cleanup exception handler, global variables, literal symbols & immediates, - RubySpec was updated from upstream. - Fixed a bug in the way we compile literal strings, before the same instance was reused which was bad since strings are mutable. - Implemented END{} blocks. - Fixed a bug in IO.copy_stream, IO#print, implemented IO#initialize_copy. - Fixed lexical constant lookup inside classes defined within a builtin class. - The Ripper C extension is now supported again. It is built and installed as part of the normal build process. First C extension on experimental! - Fixed a bug in the instance variable slot logic where it was only called for T_OBJECT types. - Added a workaround for missing 64-bit informal protocol annotations in BridgeSupport. - Installed a cleanup exception handler in macruby_main(). - Optimized dummy calls to <=>: inside the code base. - Mark thread block locals as used. This fixes a bug where a thread's block was using a local variable right after the method exited. - Implemented the internal rb_rescue() and rb_ensure() APIs. - Implemented ThreadGroup. - Re-implemented return-from-block to use a specialized C++ exception instead of SjLj. This is to make sure ensure blocks are honored, to conform to the Ruby specs. - Force the installation of the static .a library within MacRuby.framework (for AOT compiler). - Fixed the setting of $? post a popen-based expression. - Removed the --compile command line argument from the macruby executable, added the --emit-llvm argument which dumps the LLVM bitcode. This is only for internal use, users should use the new macrubyc executable instead. - Introducing macrubyc, a command line tool interface to the AOT compiler. macrubyc allows you to compile a given Ruby file into a Mach-O object file and/or produce a final executable. Produced Mach-O objects are true object files. They can be used to form a MacRuby executable or you can also use them into your Objective- C project that uses the MacRuby Objective-C API. Produced executables embed all the compiled Ruby code as well as MacRuby, statically. It can be distributed as is and does not depend on anything MacRuby or LLVM at runtime. The Ruby source code is compiled into native machine code (same process as we do at runtime with the JIT compiler), so it's also a good way to obfuscate the source code. The final binary looks like an Objective-C binary (except that it's larger). macrubyc behaves like gcc. An example: $ echo 'p 123' > t1.rb $ echo 'p 456' > t2.rb $ macrubyc -c t1.rb -o t1.o $ macrubyc -c t2.rb -o t2.o $ macrubyc t1.o t2.o -o t $ ./t 123 456 Which can be rewritten in a shorter form: $ macrubyc t1.rb t2.rb -o t $ ./t 123 456 Ruby files are loaded using the link order. You can also provide any .o file during link time. Example: $ cat t.m #import <Foundation/Foundation.h> @interface Foo : NSObject @end @implementation Foo + (void)foo { NSLog(@"foo"); } @end $ gcc -c t.m -o t.o -fobjc-gc $ cat t2.rb Foo.foo $ macrubyc t.o t2.rb -o t $ ./t 2009-07-11 22:04:37.229 t[12964:903] foo Here, we link a Ruby source file with a pure Objective-C source file and it works. macrubyc is still very preliminary but it can compile a few samples that we ship, like DotView or PathDemo (I did not try all of them yet). We will provide an Xcode target to automatize the compilation of a MacRuby Xcode project, but in the meantime you can try the command line. An example for PathDemo: $ cd build/Release/PathDemo.app/Contents/Resources/ $ cat prelude.rb framework 'Cocoa' $ cat main.rb NSApplicationMain(0, nil) $ macrubyc prelude.rb DemoView.rb PathDemoController.rb main.rb -o ../ MacOS/PathDemo $ rm *.o *.rb As you can see, here we created 2 additional files, prelude.rb and main.rb. prelude.rb loads the Cocoa framework and is passed as the 1st object, which means it will be executed at the very first time. This is needed since you want the framework to be loaded before executing code that would use it. main.rb just calls the Cocoa run loop, we pass it at the very end since this is a blocking call. Current issues: - It is very preliminary. Lots of bugs and only a portion of the Ruby AST is supported. The goal is to provide 2 modes: normal and full. Only the normal mode is being implemented right now. The normal mode will support the entire Ruby specification, compile input source files into machine code, and still use LLVM at runtime to generate stubs. This will be the preferred way to compile desktop applications. Startup time will be very good (almost like Objective-C) and the entire source code will be compiled. The full mode will compile everything statically and will not generate any code at runtime. Only a subset of the Ruby specification will be supported, and the final binary will not contain LLVM. This can be used when you want a very light application and/or if the environment does not support runtime code generation. - It can only produce 64-bit binaries for now. Universal binary support will come in the future. - It heavily depends on the linker ordering in order to initialize things. macrubyc might expose a way to call a "main" method that you would define in Ruby, after doing all the initializations. If you have any comment, criticism or suggestion please do not hesitate. This is all shiny and we have the time to iterate on it :-) Laurent

2 1

Return from thread context
by Perry Smith 11 Jul '09

11 Jul '09

The spec says that a 'return' from a thread should raise a LocalJumpError. Looking at the code for RETURN_NODE in compiler.cpp, the question of "Is this a thread" is never asked. And, I guess this exception is only for the top level block of the thread since a function called from the block could do a return. I looked briefly at the Thread create process and I didn't see anything that flagged the block passed as the top level block for the thread. The testcase causes a segmentation fault. I looked at the signal handler too and it appears as if it is "lets do this for now and address it later" code. The SEGV fault handler simply sets a flag and returns. The return will put us back where we were just at so we immediately seg fault again and then we do an exit -- with no core file. I don't see the value of catching SEGV in the first place unless the underlying Ruby code has asked us to do that. I think that would generally apply to all signals. Perry

5 10

Build problems
by Perry Smith 10 Jul '09

10 Jul '09

I just did "svn update", rake clean, rake and got: ../../miniruby -I../.. -I../../lib ./tools/preproc.rb ../../parse.y -- output=ripper.y ambiguous option: --output=ripper.y Usage: preproc.rb [--output=PATH] <parse.y> --output=PATH An output file. --help Prints this message and quit. make: *** [ripper.y] Error 1 rake aborted! Command failed with status (2): [/usr/bin/make top_srcdir=../.. ruby="../.....] I haven't dug into it yet to see whats up. Perry

2 1

Changing tags on some tests?
by Perry Smith 10 Jul '09

10 Jul '09

How do others feel about changing the tags on the tests that get segv faults to something like "faults". At least with my system, the whole testing chain stops at the segv faults. Thanks, Perry

4 4

Checkbox state
by Marinus van der Lugt 09 Jul '09

09 Jul '09

Hi All, First post, so a little bit about me: I am a SW engineer and have been one for over 20 years, increadible as that may sound. I have programmed on the Mac before in Ada95, Obj-C and Java (but I have had a pause of about 5 years from the Mac). Now that MacRuby seems to gain some foothold I'd like to get back to the mac and make the jump from Obj-C to MacRuby. I work in Xcode, and have just started a new MacRuby Core-Data Application. The first goings look good, but in implementing my first window controller I ran into a (little?) problem: I cannot get the state of a checkbox: status = @myCheckbox.state always returns a Fixnum with value 0. regardless of the visual representation of the checkbox (i.e. selected or not) The checkbox should be mapped correctly because: myTitle = @myCheckbox.title does indeed give me the title I set in the IB. I checked the archives but did not find any discussions about this. There was something about checkboxes and hotcocoa, but I do not use hotcocoa. The best solution would be a simple stupid mistake on my part :-) Any takers? Regards, Rien.

3 5

I want to help too
by Perry Smith 08 Jul '09

08 Jul '09

I'm an old crusty C programmer. I have a masters in CS and my focus was languages and compilers. MacRuby and LLVM are really exciting to me. I use a Mac. Working with Ruby since 2006. Love Rails. etc etc. I saw a previous thread in the archive where a newbie wanted to help and the reply was to help with testing. Thats fine. I'm worried about duplicate effort . Maybe split off some bugs / test cases I can work on? Most of my work will be during the weekends but I think I'd like to start setting things up during this week. Take care, Perry Ease Software, Inc. ( http://www.easesoftware.com ) Low cost SATA Disk Systems for IBMs p5, pSeries, and RS/6000 AIX systems

3 7

date broken in experimental r2001?
by Timothy Wood 08 Jul '09

08 Jul '09

% macirb irb: warn: can't alias exit from irb_exit. irb(main):001:0> require 'date' NoMethodError: undefined method `Rational:' for Date:Class This is with a freshly installed LLVM (r72741, the stable point noted in README.rdoc) and MacRuby r2001. Are other folks seeing this, or is it maybe something about my config? Thanks! -tim

3 4

[MacRuby] [0.5] rake extensions task fails when building ripper unless 0.5 has already been installed
by Mike Sassak 07 Jul '09

07 Jul '09

Hello, I'm trying to build the experimental branch out of SVN, but the rake extensions task fails at line 320 of rakelib/builder.rake when it tries to build the ripper extension with "no such file to load -- mkmf (LoadError)". That can be fixed by changing lines 320 (and then 321) of builder.rake to have miniruby include "../../" and "../../lib" before running extconf.rb and when executing Ripper's Makefile, but at that point the ripper build fails with the following error: gcc -dynamic -bundle -undefined suppress -flat_namespace -arch i386 -arch x86_64 -o ripper.bundle ripper.o -L. -L/Library/Frameworks/MacRuby.framework/Versions/0.5/usr/lib -arch i386 -arch x86_64 -lmacruby ld: library not found for -lmacruby collect2: ld returned 1 exit status ld: library not found for -lmacruby collect2: ld returned 1 exit status lipo: can't open input file: /var/folders/27/271LwlCYGQmE75LcbyeFIU+++TI/-Tmp-//cccgTd4l.out (No such file or directory) make: *** [ripper.bundle] Error 1 >From the look of it, the problem is that gcc isn't passed a -L flag for the root of the build, and I didn't have a previous version of MacRuby 0.5 installed underneath /Library/Frameworks, so it can't find libmacruby, but my knowledge of the GCC toolchain and extconf.rb fail me at this point. rake macruby works just fine, as do rake spec:ci and rake bench:ci, and building revision 1988 works like a charm; it's only after enabling the ripper build that I start having problems. I can get experimental HEAD compiled and installed by first building and installing rev 1988 and then installing HEAD, but I figured that's probably not the way things are supposed to work. :-) Any help would be appreciated, Mike

2 2