June 2010 - MacRuby-devel - lists.macosforge.org

[MacRuby] #573: Creating a void pointer causes abort()
by MacRuby 05 Jun '10

05 Jun '10

#573: Creating a void pointer causes abort() --------------------------------+------------------------------------------- Reporter: carlo@… | Owner: lsansonetti@… Type: defect | Status: new Priority: major | Milestone: MacRuby 0.5 Component: MacRuby | Keywords: --------------------------------+------------------------------------------- When creating a void pointer (`Pointer.new_with_type("v")`), the app exits: Assertion failed: (Ty->isSized() && "Cannot getTypeInfo() on a type that is unsized!"), function getTypeSizeInBits, file TargetData.cpp, line 397. Abort trap Tested in MR 0.5b2 on Snow Leopard. -- Ticket URL: <http://www.macruby.org/trac/ticket/573> MacRuby <http://macruby.org/>

1 2

[MacRuby] #733: Proc as callback function for CoreAudio(AudioDeviceCreateIOProcID) isn't called
by MacRuby 05 Jun '10

05 Jun '10

#733: Proc as callback function for CoreAudio(AudioDeviceCreateIOProcID) isn't called -----------------------------------+---------------------------------------- Reporter: nagachika00@… | Owner: lsansonetti@… Type: defect | Status: new Priority: blocker | Milestone: Component: MacRuby | Keywords: -----------------------------------+---------------------------------------- I'm trying to output arbitrary waveform data to audio device with CoreAudio Framework, and confront a callback function problem. I attach sample scripts. At first, I have to apply a small dirty patch to MacRuby to avoid {{{"unrecognized runtime type `?'"}}} exception. The function AudioDeviceStart/Stop take an argument has type `"^?"`, but MacRuby doesn't allow that type. I attach the patch too. In my sample, register Proc as callback function with AudioDeviceCreateIOProcID() seems success. Then call AudioDeviceStart() to start playback, but the Proc object seems never called. The sample script intends play silent waveform, so make no sound is OK, but log message to stdout with Kernel#p method isn't available. The callback function in CoreAudio is called from CoreAudio internal thread. Is that the cause of the problem? {{{ $ macruby -I. coreaudio_sample.rb Default Output Device ID = 268 #<Pointer:0x2002565a0> start sleep macruby(19434,0x103cc7000) malloc: *** auto malloc[19434]: error: GC operation on unregistered thread. Thread registered implicitly. Break on auto_zone_thread_registration_error() to debug. stop }}} -- Ticket URL: <http://www.macruby.org/trac/ticket/733> MacRuby <http://macruby.org/>

1 5

[MacRuby] #731: uninitialized constant IO::WaitReadable / IO::WaitWritable
by MacRuby 05 Jun '10

05 Jun '10

#731: uninitialized constant IO::WaitReadable / IO::WaitWritable ----------------------------------+----------------------------------------- Reporter: watson1978@… | Owner: lsansonetti@… Type: defect | Status: new Priority: blocker | Milestone: Component: MacRuby | Keywords: ----------------------------------+----------------------------------------- {{{ $ macirb irb(main):001:0> require 'net/http' => true irb(main):002:0> Net::HTTP.get('www.apple.com', '/') NameError: uninitialized constant IO::WaitReadable }}} I think that IO::WaitReadable and IO::WaitWritable are not defined. {{{ $ grep "WaitReadable" -r * ext/openssl/lib/openssl/buffering.rb: # IO::WaitReadable or IO::WaitWritable. ext/openssl/lib/openssl/buffering.rb: # IO::WaitReadable means SSL needs to read internally. ext/openssl/lib/openssl/buffering.rb: # rescue IO::WaitReadable ext/openssl/lib/openssl/buffering.rb: # IO::WaitReadable or IO::WaitWritable. ext/openssl/lib/openssl/buffering.rb: # IO::WaitReadable means SSL needs to read internally. ext/openssl/lib/openssl/buffering.rb: # rescue IO::WaitReadable ext/openssl/ossl_ssl.c: //rb_extend_object(exc, rb_mWaitReadable); ext/openssl/ossl_ssl.c: * rescue IO::WaitReadable ext/openssl/ossl_ssl.c: * rescue IO::WaitReadable lib/net/protocol.rb: rescue IO::WaitReadable $ grep "WaitWritable" -r * ext/openssl/lib/openssl/buffering.rb: # IO::WaitReadable or IO::WaitWritable. ext/openssl/lib/openssl/buffering.rb: # IO::WaitWritable means SSL needs to write internally. ext/openssl/lib/openssl/buffering.rb: # rescue IO::WaitWritable ext/openssl/lib/openssl/buffering.rb: # IO::WaitReadable or IO::WaitWritable. ext/openssl/lib/openssl/buffering.rb: # IO::WaitWritable means SSL needs to write internally. ext/openssl/lib/openssl/buffering.rb: # rescue IO::WaitWritable ext/openssl/ossl_ssl.c: //rb_extend_object(exc, rb_mWaitWritable); ext/openssl/ossl_ssl.c: * rescue IO::WaitWritable ext/openssl/ossl_ssl.c: * rescue IO::WaitWritable lib/net/protocol.rb: rescue IO::WaitWritable lib/net/protocol.rb: # OpenSSL::Buffering#read_nonblock may fail with IO::WaitWritable. }}} -- Ticket URL: <http://www.macruby.org/trac/ticket/731> MacRuby <http://macruby.org/>

1 2

Re: [MacRuby-devel] Changeset 3398: mark Process.fork as not supported-implemented ... motivation?
by Thibault Martin-Lagardette 04 Jun '10

04 Jun '10

(I'm CCing the MacRuby list just in case someone would be looking for the same answer. You can definitely do threads, but the easiest way would be to use IO.popen: $> macruby -e 'io = IO.popen("sleep 5"); p Process.waitpid(io.pid, 0)' 56484 You can of course use Process.WNOHANG instead of 0. Please note that if you have an array of arguments (like in your example), you can pass an array to popen and splat your arguments in it: $> macruby -e 'args = ["blah", "bleh", "meh", "hohoho"]; io = IO.popen(["echo", "moof", *args]); p Process.waitpid(io.pid, 0); p io.gets' 56505 "moof blah bleh meh hohoho\n" I hope this helps :-) -- Thibault Martin-Lagardette On Jun 4, 2010, at 15:29, macruby(a)djc.net wrote: > > Very good, thanks. > If you don't mind: what is the recommended way of migrating code that does use fork, but in fact, is just doing fork/exec, e.g. > > the code used to do > p1 = fork { > exec(*ARGV) <---- some foreign binary/cmd > } > > to get the process id, NOT block, and later, at the appropriate time, do something like > > > Process.waitpid(p1) > or Process.waitpid(p1,Process::WNOHANG) > > is an alternative recommended: > > Open4#popen4 ? > will that work in MacRuby? > > else > threads + `` ? > > or another alternative? > > > > > > On Fri, 4 Jun 2010 14:57:51 -0700 > Thibault Martin-Lagardette <thibault.ml(a)gmail.com> wrote: >> Hi! >> MacRuby makes intensive use of many system Frameworks and libraries, which makes us limited by the CAVEATS of fork(). What it means for us, is that we can use fork() for the typical pipe+dup2+fork+exec (any exec from the exec family) to run a binary and read its output. That's what we use for #` (well we actually use posix_spawn, but it is equivalent). But callin the exec() family is pretty much all we can safely do within a forked program. Because of the said caveats, we cannot do any kind of ruby execution, not even "just" calling #exec, since it would use the MacRuby dispatcher, the Obj-C runtime etc. >> This makes it impossible for us to implement the "|-" argument to #read / #open, or the #fork method. >> The main problem is that CoreFoundation would be involved within the two processes and share, for example, the same garbage collector. >> What is not safe is using anything related to CoreFoundation within the new forked process (we could say it's not "fork-safe"), and the dispatcher as well as the MacRuby runtime make extensive use of Foundation / CF. >> Even if the only operation within the child would be simply calling #exec (which we cannot make sure of anyway), calling this method would go through the runtime and the dispatcher, unfortunately unsafe. >> I hope this explains it :-) >> -- >> Thibault Martin-Lagardette >> On Jun 4, 2010, at 14:50, macruby(a)djc.net wrote: >>> Just curious: why was MacRuby added to the not-support list for fork() : >>> Changeset 3398: mark Process.fork as not supported-implemented. >>> Is there some subtle issue that will keep this from being implemented? >>> -Daniel >>> _______________________________________________ >>> MacRuby-devel mailing list >>> MacRuby-devel(a)lists.macosforge.org >>> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel >

1 0

Changeset 3398: mark Process.fork as not supported-implemented ... motivation?
by macruby＠djc.net 04 Jun '10

04 Jun '10

Just curious: why was MacRuby added to the not-support list for fork() : Changeset 3398: mark Process.fork as not supported-implemented. Is there some subtle issue that will keep this from being implemented? -Daniel

2 1

[MacRuby] #736: Unpack inconsistencies (possibly related to issue #605?)
by MacRuby 04 Jun '10

04 Jun '10

#736: Unpack inconsistencies (possibly related to issue #605?) ---------------------------------+------------------------------------------ Reporter: babs.devs@… | Owner: lsansonetti@… Type: defect | Status: new Priority: major | Milestone: Component: MacRuby | Keywords: Grit, unpack ---------------------------------+------------------------------------------ I am attempting to use the Grit(http://github.com/mojombo/grit) gem (after various patches to work w/ macruby), but there seems to be some inconsistency between unpacking strings w ruby 1.9 and MacRuby (nightly as of 6/3/10). Specifically with this method: {{{ def init_pack with_idx do |idx| @offsets = [0] FanOutCount.times do |i| //MacRuby vs Ruby assign VERY different values to pos pos = idx[i * IdxOffsetSize,IdxOffsetSize].unpack('N')[0] if pos < @offsets[i] raise PackFormatError, "pack #@name has discontinuous index #{i}" end @offsets << pos end @size = @offsets[-1] end end }}} In MacRuby the var 'pos' evaluates to [0, 4285812579] in every other block. In Ruby 1.9 'pos' evaluates correctly (ex. after 7 blocks: [0, 11, 24, 39, 48, 56, 63]) This bug may be invalid, and/or related to the Grit gem, but at first glance appears to be MacRuby related. @see also: http://www.macruby.org/trac/ticket/605 -- Ticket URL: <http://www.macruby.org/trac/ticket/736> MacRuby <http://macruby.org/>

1 2

[MacRuby] #592: No such file to load -- ubygems (LoadError)
by MacRuby 04 Jun '10

04 Jun '10

#592: No such file to load -- ubygems (LoadError) -------------------------------------+-------------------------------------- Reporter: lasse.koskela@… | Owner: lsansonetti@… Type: defect | Status: new Priority: minor | Milestone: MacRuby 0.5 Component: MacRuby | Keywords: LoadError -------------------------------------+-------------------------------------- After a fresh install of MacRuby 0.5 (the zipped-up installer .pkg), the macruby binary fails to load 'ubygems' when printing out the version, as shown below: $ /usr/local/bin/macruby -v[[BR]] MacRuby version 0.5 (ruby 1.9.0) [universal-darwin10.0, x86_64][[BR]] no such file to load -- ubygems (LoadError)[[BR]] $ On the other hand, the following does not emit the same error: $ /usr/local/bin/macruby -e 'puts "hello"'[[BR]] hello[[BR]] $ -- Ticket URL: <http://www.macruby.org/trac/ticket/592> MacRuby <http://macruby.org/>

1 2

[MacRuby] #549: Class variables are not initialised properly.
by MacRuby 03 Jun '10

03 Jun '10

#549: Class variables are not initialised properly. -------------------------------------+-------------------------------------- Reporter: sorin.ionescu@… | Owner: lsansonetti@… Type: defect | Status: new Priority: blocker | Milestone: MacRuby 0.5 Component: MacRuby | Keywords: class, instance -------------------------------------+-------------------------------------- The mime-types gem has a class and an instance interface. The class interface uses an instance of itself. However, it doesn’t work in MacRuby. It does not seem to be initialised properly. I have included in a sample code with the expected behaviour. Changing @__types__ to @@__types__ will not fix it. #!/usr/bin/env macruby class Test def initialize() @foo = true end def add(something) puts "Is foo nil: #{(a)foo.nil?}" end @__types__ = self.new() def self.add(something) @__types__.add(something) end end t = Test.new t.add(3) Test.add(4) Output (MacRuby 0.5) Is foo nil: false Is foo nil: true Expected (Ruby 1.9.1/1.8.7) Is foo nil: false Is foo nil: false -- Ticket URL: <http://www.macruby.org/trac/ticket/549> MacRuby <http://macruby.org/>

1 7

[MacRuby] #499: Order declaring class hierarchy gets MacRuby confused about instance variables
by MacRuby 03 Jun '10

03 Jun '10

#499: Order declaring class hierarchy gets MacRuby confused about instance variables ------------------------------+--------------------------------------------- Reporter: paul@… | Owner: lsansonetti@… Type: defect | Status: new Priority: major | Milestone: MacRuby 0.5 Component: MacRuby | Keywords: ------------------------------+--------------------------------------------- The following code appears to misbehave in MacRuby. It defines a class hierarchy Alpha > Beta > Gamma, with methods to set and get instance variables. {{{ class Alpha end class Beta < Alpha def setAnotherVar @another_var = "Assigned to another_var in Beta" end end class Alpha def setVar=(var) @var = var end def var @var end end class Gamma < Beta def setAnotherVar @another_var = "Assigned to another_var in Gamma" end end a = Gamma.new a.setVar = "Assigned to var" puts a.var a.setAnotherVar puts a.var }}} Ruby 1.8.7 prints: Assigned to var[[BR]] Assigned to var Whereas MacRuby prints: Assigned to var[[BR]] Assigned to another_var in Gamma Ruby 1.8.7 would appear to be the correct behaviour. MacRuby is getting confused about instance variables. Setting the "another_var" instance variable wrongly changes the "var" instance variable. Declaring the classes strictly in the order of the hierarchy (i.e Alpha then Beta then Gamma) fixes the problem, but in a large project where classes are autoloaded, that may not happen. This is a simplified extraction from a larger project. It was a very elusive bug. Well, is it a bug? -- Ticket URL: <http://www.macruby.org/trac/ticket/499> MacRuby <http://macruby.org/>

2 5

[MacRuby] #627: Obj-C exception raised within a rescue block are not catched
by MacRuby 02 Jun '10

02 Jun '10

#627: Obj-C exception raised within a rescue block are not catched ----------------------------------------+----------------------------------- Reporter: martinlagardette@… | Owner: lsansonetti@… Type: defect | Status: new Priority: major | Milestone: Component: MacRuby | Keywords: rescue exception ----------------------------------------+----------------------------------- This file: {{{ #!ruby # test.rb begin begin raise rescue NSString.stringWithCString(nil) end rescue puts "rescued" end }}} Will produce the following: {{{ #!sh $> macruby /tmp/test.rb uncaught Objective-C/C++ exception... 2010-03-01 22:45:58.926 macruby[30392:903] *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '*** +[NSString stringWithCString:]: NULL cString' *** Call stack at first throw: ( 0 CoreFoundation 0x00007fff84f80444 __exceptionPreprocess + 180 1 libobjc.A.dylib 0x00007fff84db80f3 objc_exception_throw + 45 2 CoreFoundation 0x00007fff84f80267 +[NSException raise:format:arguments:] + 103 3 CoreFoundation 0x00007fff84f801f4 +[NSException raise:format:] + 148 4 Foundation 0x00007fff87f704ed +[NSString stringWithCString:] + 80 5 ??? 0x0000000101040385 0x0 + 4312007557 6 libmacruby.dylib 0x0000000100174130 rb_vm_dispatch + 2688 7 ??? 0x000000010104015d 0x0 + 4312007005 8 libmacruby.dylib 0x0000000100184ebf rb_vm_run + 351 9 libmacruby.dylib 0x0000000100046459 ruby_run_node + 73 10 macruby 0x0000000100000d28 main + 152 11 macruby 0x0000000100000c88 start + 52 12 ??? 0x0000000000000002 0x0 + 2 ) terminate called after throwing an instance of 'NSException' Abort trap }}} However, using pure Ruby exceptions works without issue: {{{ #!ruby # test2.rb begin begin raise rescue raise end rescue puts "rescued" end }}} {{{ #!sh $> macruby /tmp/test2.rb rescued }}} -- Ticket URL: <http://www.macruby.org/trac/ticket/627> MacRuby <http://macruby.org/>

1 1