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

Strings, Encodings and IO
by Vincent Isambart 08 Apr '09

08 Apr '09

Hi, MacRuby is getting better and better at great speed, but there is one point where MacRuby still has much to do: strings, encodings and IO. If you have some interest in that, but do not know Ruby 1.9's strings well, I recommend you check at least the 2 last posts of James Gray II's series about encodings (http://blog.grayproductions.net/articles/ruby_19s_string and http://blog.grayproductions.net/articles/ruby_19s_three_default_encodings) A few of the new features have been added quite late in the 1.9 development cycle so if you played with 1.9 a few months before 1.9.1, you should at least check the last post. In MacRuby, we can't have the same strings as 1.9 because, for easy interoperability with Cocoa, we have to use Cocoa's strings (CFString/NSMutableString). And those strings work quite differently from Ruby's strings, including: - Cocoa strings are not made to store non-text data. For that you are supposed to use NSData. But Ruby strings are used to store anything (using in 1.9 the ASCII-8BIT encoding). - Cocoa stores all strings in generally either UTF-16 or MacRoman (the string is converted to one of these encodings if you give it data in an other encoding). Ruby 1.9 does not do any conversion except if you ask it explicitely. The reason Ruby does not convert strings is that in a few rare cases you can lose some data between conversions. But most people would never see it, and implementation-wise it's hard to handle strings in lots of different encodings. And in fact most programming languages and frameworks use internally strings in one of the Unicode encodings (a lot use UTF-16 and a few UTF-8 - I have never seen one using UTF-32 internally). Using only one encoding also makes string comparison easier (in Ruby 1.9 comparing strings of different encodings is not a good idea). We won't have an implementation of strings 100% compatible with 1.9, but I think we should still have something very similar, in the sense that if your code doesn't do something too weird with strings it should work on both 1.9 and MacRuby. Patrick and Laurent, in the work on IO in 0.5, have created a new ByteString type that inherits from NSMutableString but internally uses NSData. But all the IO methods always return a ByteString which is, I think, not a good idea. My main idea is the following: at the places where 1.9 returns a ASCII-8BIT string we should return a ByteString. And for strings with a real encoding we should return a NSMutableString (the encoding being the one chosen by Cocoa). A few functions of 1.9 may also be disabled (like force_encoding). Of course it would be possible to add the full functionality of Ruby 1.9 strings on ByteString but it wouldn't be worth it. Ruby 1.9 also has default code and default external encodings different depending on the environment, but I think always both of them set to UTF-8 would be the best. (we may even completely ignore the encoding pragmas in the code not to complicate the parser). If you have any comments or critics do not hesitate, it's the reason I posted it on the ML ;) Cheers, Vincent

4 11

Tutorials and Xcode
by Martin Kay 08 Apr '09

08 Apr '09

I see occasional references of tutorials on the list, and I look forward to their appearance with eagerness. But I fear that their usefulness may be be greatly reduced, as have so many in the past, by their attachment to XCode. I do not know whether XCode is a good or a bad thing for developers because it is totally beyond my comprehension. I do know that it gives rise to a "lead by the hand" style of tutorial from which it is difficult to learn anything. You know the kind of thing: "Click on this; type in that; drag this from here to there; click on that, and voilà!". But no attempt is made to provide a model form which one could understand this moves, or to produce a sequence of events that would achieve the result *I* have in mind. Examples are, or course, indispensible, so long as one can see what it is that they exemplify. Maybe someone could explain, as well as exemplify XCode or, alternatively, do MacRuby without it. --Martin

2 1

HotCocoa Tutorial ?
by Stéphane Wirtel 08 Apr '09

08 Apr '09

Hi, With HotCocoa, I have created my first small application ;-) but I would like to know if the HotCocoa tutorial will come soon, because the first problem to learn HotCocoa is the missing documentation. So I have read the examples of MacRuby, but without explainations about the lib and config directories, it's not easy to understand the structure of a HotCocoa application. Thank you so much for MacRuby and HotCocoa Regards, Stephane

2 3

[MacRuby] #241: NSMutableSet#merge fails
by MacRuby 08 Apr '09

08 Apr '09

#241: NSMutableSet#merge fails ------------------------------+--------------------------------------------- Reporter: kourge@… | Owner: lsansonetti@… Type: defect | Status: new Priority: major | Milestone: MacRuby 0.4 Component: MacRuby | Keywords: ------------------------------+--------------------------------------------- NSMutableSet#merge succeeds if called with another NSMutableSet, but it fails when passed an Enumerable, such as NSMutableArray. {{{ ~ kourge$ irb >> s = Set[1, 2] NameError: uninitialized constant Set from (irb):1 >> require 'set' => true >> s = Set[1, 2] => #<Set: {1, 2}> >> s.merge [3, 4] => #<Set: {1, 2, 3, 4}> >> quit ~ kourge$ macirb >> s = Set[1, 2] => #<NSMutableSet:0x800754380> >> s.merge [3, 4] 2009-03-30 23:54:03.319 macruby[233:10b] *** -[NSCFArray _applyValues:context:]: unrecognized selector sent to instance 0x80047cd80 2009-03-30 23:54:03.365 macruby[233:10b] *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '*** -[NSCFArray _applyValues:context:]: unrecognized selector sent to instance 0x80047cd80' 2009-03-30 23:54:03.366 macruby[233:10b] Stack: ( 140735351352508, 140735358957775, 140735351379451, 140735351372932, 140735351373272, 4295759037, 4296060391, 4296017807, 4296038178, 4296040810, 4296042845, 4296060391, 4296017807, 4296038178, 4296074114, 4295152255, 4295972133, 4296060391, 4296017807, 4296038178, 4296066197, 4296060391, 4296017807, 4296038178, 4296066197, 4296060391, 4296017807, 4296038178, 4296038828, 4295151426, 4295164679, 4294971167, 4294971044 ) terminate called after throwing an instance of 'NSException' Abort trap ~ kourge$ }}} -- Ticket URL: <http://www.macruby.org/trac/ticket/241> MacRuby <http://macruby.org/>

1 3

experimental branch: status update
by Laurent Sansonetti 08 Apr '09

08 Apr '09

Hi guys, I figured out that it would be a good idea to give periodical status updates on what's happening in the experimental branch, so here is the first one :) - The compiler is now able (AFAIK) to compile all the language specs, so I guess it's now roughly complete. - Lots of progresses on the RubySpecs - Eloy might want to comment here maybe :) - A third of the core/io specs are now passing too. Good progress on the IO front. - The `for' expression has been fixed (it was too unstable). - Lots of fixes in eval & dynamic variables. A preliminary version of Binding was implemented. The new dvar implementation is more or less twice faster than the previous one. - Better exception handling of top level exceptions. - Calling 'return' from a block has been implemented (but not optimized, yet). - Fixed the 'require of the death' bug (basically, requiring a file that requires another file that require the first file again). - Implemented implicit enumeratorization (Example: [1,2,3].each). - Ported old code to the new rb_objc_block_call() syntax (which is faster). - Implemented catch/throw. - Thanks to everything above, IRB is now running! $ ./miniruby -I./lib bin/irb irb: warn: can't alias exit from irb_exit. irb(main):001:0> 1+2 => 3 irb(main):002:0> x=40 => 40 irb(main):003:0> x+2 => 42 irb(main):004:0> def foo; 42; end => nil irb(main):005:0> foo => 42 irb(main):006:0> (With a few caveats: there are _lots_ of bugs around.) Starting IRB takes about 1.5 seconds on my machine, this is way to slow and we need to optimize this. So I will work on this. The compiler & JIT strategy have not been optimized yet. Next step will be to implement the BridgeSupport plumbing then we can bootstrap Cocoa again! Laurent

6 16

PPC build server for MacRuby trunk
by Rich Morin 07 Apr '09

07 Apr '09

I have set up a PPC-based server (dual-core 2.0 GHz Power Mac G5) to do nightly downloads and builds of the MacRuby trunk. The current snapshot was made at 2350 PDT; the next and following runs will occur at 0500. I plan to install a script RSN to remove ancient output. Clues and suggestions welcome... -r Building LLVM ------------- The README file suggests using: UNIVERSAL_ARCH="i386 x86_64" for building LLVM. This doesn't seem reasonable for a PPC machine. So, based Dömötör Gulyás's hint on how to build MacRuby, I tried: UNIVERSAL_ARCH="ppc i386" After an interminable series of compilations, the build finished: llvm[4]: Linking Release executable Sample (without symbols) llvm[4]: ======= Finished Linking Release Executable Sample (without symbols) make[1]: Nothing to be done for `all'. llvm[0]: ***** Completed Release Build Installing LLVM --------------- I then tried to install llvm, but got LOTS of errors of the form: /opt/local/bin/ginstall: cannot create regular file `/usr/local/include/./.svn/all-wcprops': No such file or directory I then alternated between mkdir and "make install" commands for a while, making the following directories: /usr/local/include/.svn /usr/local/include/llvm/.svn /usr/local/include/llvm/.svn/{prop-base,text-base} /usr/local/include/llvm/ADT/.svn/ /usr/local/include/llvm/ADT/.svn/{prop-base,text-base} /usr/local/include/./llvm/Analysis/.svn /usr/local/include/./llvm/Analysis/.svn/{prop-base,text-base} /usr/local/include/./llvm/Assembly/.svn /usr/local/include/./llvm/Assembly/.svn/{prop-base,text-base} /usr/local/include/./llvm/Bitcode/.svn /usr/local/include/./llvm/Bitcode/.svn/{prop-base,text-base} /usr/local/include/./llvm/CodeGen/.svn /usr/local/include/./llvm/CodeGen/.svn/{prop-base,text-base} /usr/local/include/./llvm/CompilerDriver/.svn /usr/local/include/./llvm/CompilerDriver/.svn/{prop-base,text-base} /usr/local/include/./llvm/Config/.svn /usr/local/include/./llvm/Config/.svn/{prop-base,text-base} /usr/local/include/./llvm/Debugger/.svn /usr/local/include/./llvm/Debugger/.svn/{prop-base,text-base} /usr/local/include/./llvm/ExecutionEngine/.svn /usr/local/include/./llvm/ExecutionEngine/.svn/{prop-base,text-base} /usr/local/include/./llvm/Support/.svn /usr/local/include/./llvm/Support/.svn/{prop-base,text-base} /usr/local/include/./llvm/Support/.svn /usr/local/include/./llvm/Support/.svn/{prop-base,text-base} /usr/local/include/./llvm/System/.svn /usr/local/include/./llvm/System/.svn/{prop-base,text-base} /usr/local/include/./llvm/Target/.svn /usr/local/include/./llvm/Target/.svn/{prop-base,text-base} /usr/local/include/./llvm/Transforms/.svn /usr/local/include/./llvm/Transforms/.svn/{prop-base,text-base} /usr/local/include/./llvm/Transforms/IPO/.svn /usr/local/include/./llvm/Transforms/IPO/.svn/{prop-base,text-base} /usr/local/include/./llvm/Transforms/Utils/.svn /usr/local/include/./llvm/Transforms/Utils/.svn/{prop-base,text-base} /usr/local/include/./llvm-c/.svn /usr/local/include/./llvm-c/.svn/{prop-base,text-base} /usr/local/include/./llvm-c/Transforms/.svn /usr/local/include/./llvm-c/Transforms/.svn/text-base This was really tedious. I assume that there is something I (or the build script) should have done to obviate this hassle. Suggestions? Build, Specs, Benchmarks ------------------------ The build proceeded without any apparent problems. The specs proceeded without any apparent problems. The benchmarks stalled for a looooooong time here: 50000 raise 942.180000 13.450000 955.630000 (536.527173) Examining code, output, etc. ---------------------------- The directory tree is available for public examination at: http://www.cfcl.com/rdm/macruby/ YYYY.MMDD.HHMM/ tree for a given run 1_svn_co log for "svn co ..." 2_rake log for "rake" 3_rake_spec_ci log for "rake bench:ci" 4_rake_bench_ci log for "rake bench:ci" macruby-experimental/... working directory tree Notes assorted notes doit* the script llvm-trunk/... LLVM build tree -- 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 2

Unit testing in Xcode
by Frisco Del Rosario 07 Apr '09

07 Apr '09

Is unit testing in Xcode necessarily as cumbersome as it seems to be described in http://developer.apple.com/documentation/developertools/Conceptual/UnitTest… ? Xcode is making me miss the days I could just append a TestCase instance with TextMate and hit command-r.

4 3

How to install MacRuby-experimental and keep the stable version 0.4
by Stephane Wirtel 06 Apr '09

06 Apr '09

Hi all, I would like to try MRE[1] on my laptop with coexisting the last stable version 0.4 To do that, I have installed LLVM into a directory named ~/local and I have specified during the installation of MRE[1] that rake must install it into the directory ~/Library/Frameworks with the following commands: rake all framework_instdir=~/Library/Frameworks rake install Excepted that doesn't work and my directory ~/Library/Frameworks doesn't exist after the installation of MRE[1]. I don't want to install MRE in my system, but only a local directory to my user account 1. MacRuby-experimental (http://svn.macosforge.org/repository/ruby/MacRuby/branches/experimental) Stephane Thank you so much

3 4

CIImage / CICrop broken?
by Benjamin Mollenhauer 06 Apr '09

06 Apr '09

Hi, i have the problem, that under MacRuby cropping of an CIImage fails. Whether i use CIFilter or CIImage#imageByCroppingToRect. Whereas a Cocoa-Application the same code works just fine, my Ruby version repeats the same cropped Image over and over again. Have a look at the Screenshot: http://i43.tinypic.com/a3f2vt.jpg See the source: Objective-C: http://pastie.org/438181 Ruby-Version: http://pastie.org/438183 I noticed, that the Ruby version runs fine, if I load the image fresh from a file before each crop. Next thing i tried, was to write a Objective-C-Class to do my cropping and display it in my ruby view. Didn't work either. Some comments on this? Did I miss something or should I fill a bug report? Ben

2 3

a modest request
by Rich Morin 05 Apr '09

05 Apr '09

I realize that Laurent and company have their hands full with simply trying to make JIT (etc) work on Intel hardware. So, I don't expect anyone to make this work on PPC hardware, as well (at least in the short run :-). However, it occurs to me that it might be possible to "guard" the Intel-specific code such that it doesn't even TRY to run unless an Intel processor is being used. This could allow PPC users to play with new MacPerl releases, albeit in a less optimized manner. Is this is a possibility? -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

4 4