Laurent Sansonetti
lsans****@apple*****
Thu Aug 17 05:55:00 JST 2006
On Aug 15, 2006, at 3:08 PM, kimura wataru wrote: > On Mon, 14 Aug 2006 23:40:00 +0200, Laurent Sansonetti wrote: >> >> On Aug 14, 2006, at 4:03 PM, kimura wataru wrote: > >>> I tested to merge apple-unstable into trunk with "svn merge --dry- >>> run". >>> > >>> I think these conflicts are not so complex, and I believe that we >>> can >>> solve them. I attached all of log on "svn merge". >>> >> >> Thank you Kimura-san. I solved the conflicts on my working copy. >> Shall >> I commit everything? >> > Nice! Please commit to trunk. > I was about to commit, but I got the following message: svn: Commit failed (details follow): svn: MKACTIVITY of '/svnroot/rubycocoa/!svn/act/ 7da01d50-5ef1-488c-9ca0-12b48a39da40': authorization failed (https://svn.sourceforge.net ) A quick google reveals that SVN support should be switched on per user by the project admin. If that's true, could you do it Hisa-san? On another note, about the branch, the BridgeSupport stuff is going to be changed very soonly (we could decide with the PyObjC guys what was necessary in common). I'm going to work on this next week in priority. Also there is a bug with the new OSX::ns_import lazy mechanism, if you want to extend an ObjC class from Ruby you must explicitly call OSX::ns_import on it before extending, as otherwise the class may not be loaded before and you're going to create a new class. OSX::ns_import :NSImage # unless NSImage was acceded/loaded before class OSX::NSImage def myAdditionalMethod end end Before that, all classes were loaded at startup, so we did not have this problem. We need to load the NSImage ObjC class when it's going to be extended, but... I can't find a way to do that. Any idea? A kind- of Module#autoload but more generic would help, but I can't see anything at a glance... Thanks! Laurent
