[MacRuby-devel] PPC build server for MacRuby trunk

2009-04-07 Thread Rich Morin
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 looong time here:

  5 raise942.18  13.45 955.63 (536.527173)


Examining code, output, etc.


The directory tree is available for public examination at:

  http://www.cfcl.com/rdm/macruby/

.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_cilog for "rake bench:ci"
  macruby-experimental/...   working directory tree

Notesassorted notes
doit*the script
llvm-trunk/...   LLVM build tree
-- 
http://www.cfcl.com/rdmRich Morin
http://www.cfcl.com/rdm/resume [email protected]
http://www.cfcl.com/rdm/weblog +1 650-873-7841

Technical editing and writing, programming, and web development
___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel


Re: [MacRuby-devel] Strings, Encodings and IO

2009-04-07 Thread Vincent Isambart
Hi again,

So plan B: We emulate Ruby 1.9 strings behavior on top of of NSString/NSData.

Internally we would use a NSData when the encoding is not valid or
it's binary, and NSString in the other cases (never both at the same
time). We would have a Ruby encoding that may be completely different
from the real encoding of the string (it's just a facade for Ruby).

force_encoding would transform back the string into NSData using the
Ruby encoding if the data is stored as a NSString, or use the NSData.
And then it would try to make a NSString from that data using the
encoding given to force_encoding. If it's successful, we use the
string, if not we use the NSData.

Of course, force_encoding would be slow, as would be accessing bytes
when it's a NSString. However accessing the nth character of a string
would probably be faster than in 1.9.

I am however a bit afraid it would not be very easy to implement. The
main problem is not implementing the string itself, but have something
that plays well with real NSStrings, and with Objective-C code that
waits for normal NSStrings of course. And well I do not know
CFString/NSString well.

As before it's just an idea. Comments are welcome. Implementation will
wait at least until a few people seems it could be useful (and anyone
wanting to do it would be welcome as personally I'm not sure I will
have the time necessary until May).
___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel


Re: [MacRuby-devel] Unit testing in Xcode

2009-04-07 Thread Brian Marick


On Apr 4, 2009, at 4:55 AM, John Shea wrote:

Brian Marick has a good chapter on testing in his "RubyCocoa,  
bringing some love. "  using standard ruby testing  
methodologies. You can get this as a pdf book (its not out in print  
yet)



Thanks. Note, though, that I don't test in Xcode. I don't even code in  
Xcode - I use Aquamacs emacs. So the testing I describe is plain old  
testing at the command line. It's the equivalent of Command-Tab and  
typing !! to the shell. (As an emacs user, of course, it's all done  
inside of emacs, so all I type is F4. I imagine a little AppleScript  
could make it one keystroke for non-emacs users.)


-
Brian Marick, independent consultant
Mostly on agile methods with a testing slant
www.exampler.com, www.exampler.com/blog, www.twitter.com/marick

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


Re: [MacRuby-devel] PPC build server for MacRuby trunk

2009-04-07 Thread Rich Morin
The 5 am run this morning failed, due to a PATH problem.
I made a fix and re-ran at 10:30 am; seems OK now.

-r
-- 
http://www.cfcl.com/rdmRich Morin
http://www.cfcl.com/rdm/resume [email protected]
http://www.cfcl.com/rdm/weblog +1 650-873-7841

Technical editing and writing, programming, and web development
___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel


Re: [MacRuby-devel] experimental branch: status update

2009-04-07 Thread Eloy Duran

Hi Chris,

I've finally had some time to write an explanation on how to work on  
the specs.

You can find it in spec/README.rdoc, or view it at: 
http://github.com/alloy/mr-experimental/blob/master/spec/README.rdoc

Let me know if there are any questions, I probably left out important  
parts ;-)


Cheers,
Eloy

On 6 apr 2009, at 17:39, Chris McGrath wrote:

On Mon, Apr 6, 2009 at 10:16 AM, Eloy Duran  
 wrote:
If there are people who would like to work on getting examples up- 
to-date,

please respond and I will try to give you an outline on a workflow.



I'd be interested in helping out, but atm I'm not up to speed enough
to have even built the experimental branch.

Cheers,

Chris
___
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] PPC build server for MacRuby trunk

2009-04-07 Thread Rich Morin
I added some code to remove "moldy oldies" (output trees before
the most recent half-dozen).  If anyone wants me to retain more
trees, let me know the reasons(s) and the suggested count.

-r
-- 
http://www.cfcl.com/rdmRich Morin
http://www.cfcl.com/rdm/resume [email protected]
http://www.cfcl.com/rdm/weblog +1 650-873-7841

Technical editing and writing, programming, and web development
___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel


Re: [MacRuby-devel] experimental branch: status update

2009-04-07 Thread Eloy Duran

Hi,

I just added a spec:ci32 task which will run the specs in 32 bit mode.
It uses a simple script (miniruby32) which runs miniruby through /usr/ 
bin/arch.


http://github.com/alloy/mr-experimental/commit/321cc9b0ae0acce82bdb59bdc11e4f688e6233c6

And indeed :)

% rake spec:ci32
(in /Users/eloy/Documents/DEVELOPMENT/MacRuby/git-svn-roxor)
./miniruby32 ./mspec/bin/mspec-ci -B ./spec/frozen/macruby.mspec spec/ 
frozen/language spec/frozen/core/io/binmode_spec.rb spec/frozen/core/ 
io/closed_spec.rb spec/frozen/core/io/constants_spec.rb spec/frozen/ 
core/io/each_byte_spec.rb spec/frozen/core/io/fileno_spec.rb spec/ 
frozen/core/io/fsync_spec.rb spec/frozen/core/io/flush_spec.rb spec/ 
frozen/core/io/getc_spec.rb spec/frozen/core/io/io_spec.rb spec/frozen/ 
core/io/inspect_spec.rb spec/frozen/core/io/initialize_copy_spec.rb  
spec/frozen/core/io/putc_spec.rb spec/frozen/core/io/readchar_spec.rb  
spec/frozen/core/io/sync_spec.rb spec/frozen/core/io/syswrite_spec.rb  
spec/frozen/core/io/tell_spec.rb spec/frozen/core/io/to_i_spec.rb spec/ 
frozen/core/io/to_io_spec.rb spec/frozen/core/io/initialize_spec.rb

.

Finished in 8.402635 seconds

69 files, 676 examples, 1600 expectations, 0 failures, 0 errors

Cheers,
Eloy

On 6 apr 2009, at 22:52, Jordan Breeding wrote:

Based on that I would say that it is a good idea going forward to  
try having 64-bit machines run tests in 64-bit and 32-bit mode. I  
look forward to seeing any solution to running the tests in 32-bit  
mode that you come up with.


Jordan

On Apr 06, 2009, at 13:07, Eloy Duran wrote:


Hmm, so it's indeed a 32/64 bit issue.

Thanks for trying Mike!

- Eloy

On 6 apr 2009, at 18:56, Mike Moore wrote:

On Mon, Apr 6, 2009 at 3:16 AM, Eloy Duran  
 wrote:


One last question I have for everyone on the list. If there's  
someone with a 32 bit intel machine, could you please please run  
the spec:ci task and see if you get any failures?
It seems that, at least, because of a 32/64 bit issue some IO  
specs are now failing on my machines and those of Laurent. Thanks  
in advance!


I have a first generation MacBook Pro.

$ svn up
...
$ rake
...
$ rake spec:ci
(in /Users/blowmage/Scratch/macruby-experimental)
./mspec/bin/mspec ci -B ./spec/frozen/macruby.mspec spec/frozen/ 
language spec/frozen/core/io/binmode_spec.rb spec/frozen/core/io/ 
closed_spec.rb spec/frozen/core/io/constants_spec.rb spec/frozen/ 
core/io/each_byte_spec.rb spec/frozen/core/io/fileno_spec.rb spec/ 
frozen/core/io/fsync_spec.rb spec/frozen/core/io/flush_spec.rb  
spec/frozen/core/io/getc_spec.rb spec/frozen/core/io/io_spec.rb  
spec/frozen/core/io/inspect_spec.rb spec/frozen/core/io/ 
initialize_copy_spec.rb spec/frozen/core/io/putc_spec.rb spec/ 
frozen/core/io/readchar_spec.rb spec/frozen/core/io/sync_spec.rb  
spec/frozen/core/io/syswrite_spec.rb spec/frozen/core/io/ 
tell_spec.rb spec/frozen/core/io/to_i_spec.rb spec/frozen/core/io/ 
to_io_spec.rb spec/frozen/core/io/initialize_spec.rb

MacRuby version 0.5 (ruby 1.9.0) [universal-darwin9.0, i386]
...F 
.


1)
The throw keyword does not convert strings to a symbol FAILED
Expected ArgumentError but no exception was raised


Finished in 9.338692 seconds

69 files, 672 examples, 1593 expectations, 1 failure, 0 errors
rake aborted!
Command failed with status (1): [./mspec/bin/mspec ci -B ./spec/ 
frozen/macr...]


(See full trace by running task with --trace)
___
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


[MacRuby-devel] HotCocoa Tutorial ?

2009-04-07 Thread Stéphane Wirtel

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


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


Re: [MacRuby-devel] Strings, Encodings and IO

2009-04-07 Thread Charles Oliver Nutter

Vincent Isambart wrote:

Hi again,

So plan B: We emulate Ruby 1.9 strings behavior on top of of NSString/NSData.


I'm really interested in this discussion too. A little background for JRuby:

We started out (or really, the original authors started out) with JRuby 
using all Java strings and stringbuffers for Ruby's String. This made 
interop easy and of course simplified implementation, but it ran into 
the same problems you enumerated in your original post:


* Java's strings are all UTF-16. In order to represent binary data, we 
ended up using a "raw" encoder/decoder and only using the bottom byte of 
each character. Wasteful, since every string was 2x as large, and slow, 
since IO had to up/downcast byte[] contents to char[] and back.
* So we made a move about two years ago to using all byte[]-based 
strings in JRuby. This allowed us maximum compatibility, maximum 
performance, and a future-proof path, but it damages interop. Currently 
whenever you pass a string across the Ruby/Java boundary, we have to do 
the decode/encode. That affects performance pretty severely. We also had 
to implement our own regular expression engine, since no Java regex 
works with byte[].
* We want to move to an intermediate version, where we sometimes have a 
byte[]-backed string and sometimes a char[]/String-backed string. 
IronRuby does this already. This is, however, predicated on the idea 
that byte[]-based strings rarely become char[]-based strings and vice 
versa. I don't have any evidence for or against that yet.


So it's a nearly identical problem for MacRuby, as I understand it. I'm 
interested in discussion around this topic, since we are still moving 
forward with JRuby and would like to improve interop with Java 
libraries. I will offer the following food for thought:


* Going with 100% objc strings at first is probably a good pragmatic 
start. You'll have the perf/memory impact of encoding/decoding and 
wasteful string contents, but you should be able to get it functioning 
well. And since interop is a primary goal for MacRuby (where it's been 
somewhat secondary in JRuby) this is probably a better place to start.
* We have considered having a modified 1.9 mode that normalizes all 
strings into UTF-16 internally. That might work for you as well. I 
presume there are byte-decoding APIs in objc that could produce your 
standard strings. You'd be able to at least pretend you support 1.9 
encoding, but be transcoding to the user's selected encoding. It 
wouldn't be fast, but it would work.
* Alternatively, you could only support a minimum set of encodings and 
make it explicit that internally everything would be UTF-16 or MacRoman. 
In MacRuby's case, I think most people would happily accept that, just 
as a lot of JRuby users would probably accept that everything's UTF-16 
since that's what they get from Java normally.


Ultimately this is the exact reason I argued over a year ago that Ruby 
1.9 should introduce a separate Bytes class used for IO. I was denied.


It's definitely a sticky issue, and Ruby has made it even stickier in 
1.9 with arbitrary encoding support. None of the proposed solutions 
across all implementations (including JRuby) have really seemed ideal to me.


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


Re: [MacRuby-devel] HotCocoa Tutorial ?

2009-04-07 Thread Matt Aimonetti
Salut Stéphane,

 I'd like to tackle documentation of HotCocoa when I come back from
vacation, I believe there was some talk about generating documentation
automatically but nothing concrete yet. We could def. at least add links to
the cocoa documentation in the hotcocoa mapping source.

However, having a 'getting started' guide for HotCocoa would be awesome. Now
that you have more experience, would you be interested in writing something?
Don't worry about typos or syntax, people can help out.

- Matt


2009/4/7 Stéphane Wirtel 

> 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
>
>
> ___
> 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] experimental branch: status update

2009-04-07 Thread Matt Aimonetti
slightly out topic: w00t!!  great job guys!

- Matt

2009/4/7 Eloy Duran 

> Hi,
> I just added a spec:ci32 task which will run the specs in 32 bit mode.
> It uses a simple script (miniruby32) which runs miniruby through
> /usr/bin/arch.
>
>
> http://github.com/alloy/mr-experimental/commit/321cc9b0ae0acce82bdb59bdc11e4f688e6233c6
>
> And indeed :)
>
> % rake spec:ci32
> (in /Users/eloy/Documents/DEVELOPMENT/MacRuby/git-svn-roxor)
> ./miniruby32 ./mspec/bin/mspec-ci -B ./spec/frozen/macruby.mspec
> spec/frozen/language spec/frozen/core/io/binmode_spec.rb
> spec/frozen/core/io/closed_spec.rb spec/frozen/core/io/constants_spec.rb
> spec/frozen/core/io/each_byte_spec.rb spec/frozen/core/io/fileno_spec.rb
> spec/frozen/core/io/fsync_spec.rb spec/frozen/core/io/flush_spec.rb
> spec/frozen/core/io/getc_spec.rb spec/frozen/core/io/io_spec.rb
> spec/frozen/core/io/inspect_spec.rb
> spec/frozen/core/io/initialize_copy_spec.rb spec/frozen/core/io/putc_spec.rb
> spec/frozen/core/io/readchar_spec.rb spec/frozen/core/io/sync_spec.rb
> spec/frozen/core/io/syswrite_spec.rb spec/frozen/core/io/tell_spec.rb
> spec/frozen/core/io/to_i_spec.rb spec/frozen/core/io/to_io_spec.rb
> spec/frozen/core/io/initialize_spec.rb
> .
>
> Finished in 8.402635 seconds
>
> 69 files, 676 examples, 1600 expectations, 0 failures, 0 errors
>
> Cheers,
> Eloy
>
> On 6 apr 2009, at 22:52, Jordan Breeding wrote:
>
> Based on that I would say that it is a good idea going forward to try
> having 64-bit machines run tests in 64-bit and 32-bit mode. I look forward
> to seeing any solution to running the tests in 32-bit mode that you come up
> with.
> Jordan
>
> On Apr 06, 2009, at 13:07, Eloy Duran wrote:
>
> Hmm, so it's indeed a 32/64 bit issue.
>
> Thanks for trying Mike!
> - Eloy
>
> On 6 apr 2009, at 18:56, Mike Moore wrote:
>
> On Mon, Apr 6, 2009 at 3:16 AM, Eloy Duran wrote:
>
>>
>> One last question I have for everyone on the list. If there's someone with
>> a 32 bit intel machine, could you please please run the spec:ci task and see
>> if you get any failures?
>> It seems that, at least, because of a 32/64 bit issue some IO specs are
>> now failing on my machines and those of Laurent. Thanks in advance!
>
>
> I have a first generation MacBook Pro.
>
> $ svn up
> ...
> $ rake
> ...
> $ rake spec:ci
> (in /Users/blowmage/Scratch/macruby-experimental)
> ./mspec/bin/mspec ci -B ./spec/frozen/macruby.mspec spec/frozen/language
> spec/frozen/core/io/binmode_spec.rb spec/frozen/core/io/closed_spec.rb
> spec/frozen/core/io/constants_spec.rb spec/frozen/core/io/each_byte_spec.rb
> spec/frozen/core/io/fileno_spec.rb spec/frozen/core/io/fsync_spec.rb
> spec/frozen/core/io/flush_spec.rb spec/frozen/core/io/getc_spec.rb
> spec/frozen/core/io/io_spec.rb spec/frozen/core/io/inspect_spec.rb
> spec/frozen/core/io/initialize_copy_spec.rb spec/frozen/core/io/putc_spec.rb
> spec/frozen/core/io/readchar_spec.rb spec/frozen/core/io/sync_spec.rb
> spec/frozen/core/io/syswrite_spec.rb spec/frozen/core/io/tell_spec.rb
> spec/frozen/core/io/to_i_spec.rb spec/frozen/core/io/to_io_spec.rb
> spec/frozen/core/io/initialize_spec.rb
> MacRuby version 0.5 (ruby 1.9.0) [universal-darwin9.0, i386]
> ...F.
>
> 1)
> The throw keyword does not convert strings to a symbol FAILED
> Expected ArgumentError but no exception was raised
>
>
> Finished in 9.338692 seconds
>
> 69 files, 672 examples, 1593 expectations, 1 failure, 0 errors
> rake aborted!
> Command failed with status (1): [./mspec/bin/mspec ci -B
> ./spec/frozen/macr...]
>
> (See full trace by running task with --trace)
> ___
> 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
>
>
___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel


Re: [MacRuby-devel] [MacRuby] #241: NSMutableSet#merge fails

2009-04-07 Thread MacRuby
#241: NSMutableSet#merge fails
--+-
 Reporter:  kou...@…  |   Owner:  b...@…  
 Type:  defect|  Status:  new
 Priority:  major |   Milestone:  MacRuby 0.4
Component:  MacRuby   |Keywords: 
--+-

Comment(by b...@…):

 While fixing this I found out that the tests hang in #==…I’ll write a new
 one about that.

-- 
Ticket URL: 
MacRuby 

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


Re: [MacRuby-devel] [MacRuby] #241: NSMutableSet#merge fails

2009-04-07 Thread MacRuby
#241: NSMutableSet#merge fails
--+-
 Reporter:  kou...@…  |Owner:  b...@…  
 Type:  defect|   Status:  closed 
 Priority:  major |Milestone:  MacRuby 0.4
Component:  MacRuby   |   Resolution:  fixed  
 Keywords:|  
--+-
Changes (by b...@…):

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


Comment:

 Fixed in [1401].

-- 
Ticket URL: 
MacRuby 

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


[MacRuby-devel] [MacRuby] #242: test/test_set.rb hangs because of #==

2009-04-07 Thread MacRuby
#242: test/test_set.rb hangs because of #==
-+--
 Reporter:  b...@…|   Owner:  b...@…  
 Type:  defect   |  Status:  new
 Priority:  blocker  |   Milestone:  MacRuby 0.4
Component:  MacRuby  |Keywords: 
-+--
 {{{
 Loaded suite test/test_set
 Started
 EF.
 }}}

 The stack is blown because Set#== is recursing.

-- 
Ticket URL: 
MacRuby 

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


Re: [MacRuby-devel] Strings, Encodings and IO

2009-04-07 Thread Benjamin Stiglitz
So plan B: We emulate Ruby 1.9 strings behavior on top of of  
NSString/NSData.


I'm really interested in this discussion too. A little background  
for JRuby:


Thanks for the background, Charlie. This sort of history is very  
instructive.


* Java's strings are all UTF-16. In order to represent binary data,  
we ended up using a "raw" encoder/decoder and only using the bottom  
byte of each character. Wasteful, since every string was 2x as  
large, and slow, since IO had to up/downcast byte[] contents to  
char[] and back.


Most CFStrings use a UTF-16 internal store as well.

* We want to move to an intermediate version, where we sometimes  
have a byte[]-backed string and sometimes a char[]/String-backed  
string. IronRuby does this already. This is, however, predicated on  
the idea that byte[]-based strings rarely become char[]-based  
strings and vice versa. I don't have any evidence for or against  
that yet.


So it's a nearly identical problem for MacRuby, as I understand it.  
I'm interested in discussion around this topic, since we are still  
moving forward with JRuby and would like to improve interop with  
Java libraries. I will offer the following food for thought:


* Going with 100% objc strings at first is probably a good pragmatic  
start. You'll have the perf/memory impact of encoding/decoding and  
wasteful string contents, but you should be able to get it  
functioning well. And since interop is a primary goal for MacRuby  
(where it's been somewhat secondary in JRuby) this is probably a  
better place to start.


That’s where things stand today, and with Laurent’s ByteString work  
this all mostly works as long as you don’t try to change encodings  
around on strings.


* Alternatively, you could only support a minimum set of encodings  
and make it explicit that internally everything would be UTF-16 or  
MacRoman. In MacRuby's case, I think most people would happily  
accept that, just as a lot of JRuby users would probably accept that  
everything's UTF-16 since that's what they get from Java normally.


This seems like a bad situation in the face of the varied encoding  
landscape on the Internet.


Ultimately this is the exact reason I argued over a year ago that  
Ruby 1.9 should introduce a separate Bytes class used for IO. I was  
denied.


I was disappointed to see this turned down as well. The encoding  
situation in 1.9 feels worse than it was in 1.8, and that’s pretty  
impressive.


It's definitely a sticky issue, and Ruby has made it even stickier  
in 1.9 with arbitrary encoding support. None of the proposed  
solutions across all implementations (including JRuby) have really  
seemed ideal to me.


Laurent and I discussed this a bit tonight, and here’s what I think we  
can get away with:


By default, store all strings as NSString (UTF-16 backed) with an ivar  
to store the encoding e.

When getting bytes, convert to a ByteString in the appropriate encoding.
When doing force_encoding, convert to a ByteString in the old  
encoding, then try to convert to an NSString in the new encoding. If  
we succeed, great. If not, leave as a tagged ByteString (and probably  
whine about it).

All ASCII-8BIT strings are backed by ByteString.

There’s some simplification here; some of the ByteStrings are really  
just NSDatas, &c., but the flow is there. Sorry the list above is a  
mess, I’m up much later than I’m accustomed to.


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