rubycocoa-talk — talking about RubyCocoa

[Rubycocoa-talk] stanaloneify.rb in Leopard

[Alistair H. <ali...@gm...>]

Hello all!
I've just been playing with standaloneify.rb in Leopard and thought I'd
document my findings for reference.

I'm not sure how one goes about using the standaloneify.rb which is included
in Leopard
(/System/Library/Frameworks/RubyCocoa.framework/Versions/A/Tools/standaloneify.rb
) so I instead downloaded the .rb from
http://www.jpaisley.com/software/ruby/ . If anyone knows how to do it
properly please let me know!


I then encountered a problem with the .rb I had downloaded in that it was
looking for frameworks in '/Library/Frameworks'.. now I'm not sure about
other Leopard installations but in mine this folder was empty so I had to
drop into the Terminal, delete 'Library/Frameworks' and create a symbolic
link between '/Developer/SDKs/MacOSX10.5.sdk/System/Library/Frameworks/' and
'/Library/Frameworks'.

After that it worked great!

-- 
Alistair Holt
ali...@gm...

Re: [Rubycocoa-talk] Web server inside a RubyCocoa App

[Alistair H. <ali...@gm...>]

Thanks Eloy. That looks pretty cool. I will definitely have a play around
with that.
Cheers!

On 17/11/2007, elo...@gm... <elo...@gm...> wrote:
>
> Hey Alistair,
>
>
> Standaloneify will already do this for you. Only one catch is that if
> you are going to fork the process standalonify will never know  of the
> dependencies. So you have to require the depencies in your app as well
> when running standaloneify. Other than that it works great in an app
> I'm working on.
>
> Cheers,
> Eloy
>
> On 11/17/07, Alistair Holt <ali...@gm...> wrote:
> > Hello,
> > I'm writing a little app which I want to contain a small web server - I
> was
> > thinking of using the lovely Camping (
> > http://code.whytheluckystiff.net/camping/) . Problem is that I'm not
> sure
> > how I should go about achieving this. Camping is distributed as a Gem so
> I
> > was thinking I could package the gem source (and its dependencies) into
> my
> > app. Anyone have any other ideas? I'd be interested to hear peoples
> thoughts
> > on this.
> >
> > Cheers
> >
> > --
> > Alistair Holt
> > ali...@gm...
> >
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Rubycocoa-talk mailing list
> Rub...@li...
> https://lists.sourceforge.net/lists/listinfo/rubycocoa-talk
>



-- 
Alistair Holt
ali...@gm...

Re: [Rubycocoa-talk] Web server inside a RubyCocoa App

[<elo...@gm...>]

Hey Alistair,


Standaloneify will already do this for you. Only one catch is that if
you are going to fork the process standalonify will never know  of the
dependencies. So you have to require the depencies in your app as well
when running standaloneify. Other than that it works great in an app
I'm working on.

Cheers,
Eloy

On 11/17/07, Alistair Holt <ali...@gm...> wrote:
> Hello,
> I'm writing a little app which I want to contain a small web server - I was
> thinking of using the lovely Camping (
> http://code.whytheluckystiff.net/camping/) . Problem is that I'm not sure
> how I should go about achieving this. Camping is distributed as a Gem so I
> was thinking I could package the gem source (and its dependencies) into my
> app. Anyone have any other ideas? I'd be interested to hear peoples thoughts
> on this.
>
> Cheers
>
> --
> Alistair Holt
> ali...@gm...
>

[Rubycocoa-talk] Web server inside a RubyCocoa App

[Alistair H. <ali...@gm...>]

Hello,
I'm writing a little app which I want to contain a small web server - I was
thinking of using the lovely Camping (
http://code.whytheluckystiff.net/camping/) . Problem is that I'm not sure
how I should go about achieving this. Camping is distributed as a Gem so I
was thinking I could package the gem source (and its dependencies) into my
app. Anyone have any other ideas? I'd be interested to hear peoples thoughts
on this.

Cheers

-- 
Alistair Holt
ali...@gm...

Re: [Rubycocoa-talk] Totally stuck with Core Data on Leopard

[Pierce T. W. I. <pi...@tw...>]

On Nov 11, 2007, at 8:28 AM, Jacob Wallstr=F6m wrote:

> Summary of post: I can't get ruby subclasses of NSMangedObject to work
> if they have their own attribute implementations with RubyCocoa on
> Leopard. I desperately need this to work, have anybody solved this
> problem?
> ---
>
> I'm having major problems with porting my application to Leopard. The
> problem is that my application relies on ruby subclasses of
> NSManagedObject which contains methods implementing the core data
> attributes. The default attribute implementation provided by Core Data
> is not enough since changes in an attribute can trigger changes in
> other attributes etc. Since I have a UI that uses bindings, a lot of
> the access to my entities is happening from Obj-C and I need these
> calls to go through the ruby methods of my entities.
>
> I got this working quite well with RC 0.12.0 on Tiger. By overriding
> setValue:forKey: and having it check for a ruby set-method before
> passing the call on to the setValue:forKey: method in NSManagedObject
> I could get all access from Obj-C to the attributes to pass trough the
> ruby methods which was what I wanted. I also used KVO-observing to get
> notified of changes in certain attributes.

I had problems with this as well on Tiger, but my solution was to use =20=

MOGenerator to make Obj-C base classes for all of my data objects with =20=

the accessors on that side, then override them from ruby if I needed =20
too.

That also had the advantage of being faster because:

def value
	willReadValueForKey("value")
	result=3D @value
	didReadValueForKey("value")
end

Had several bridge crossings to deal with, especially when used with =20
bindings, so that sped up anything that just needed a simple accessor.

You could make your own subclass of NSManagedObject and override the =20
method that handles "unhandled keys" because on Tiger at least, that's =20=

actually how NSManagedObject works. setValue: forKey: falls through to =20=

being "unhandled" and then NSManagedObject uses its default =20
implementation.

For Leopard, I'm not sure how much help I can be because my app broke =20=

with weird Core Data errors. So I upgraded to trunk thinking it might =20=

be issues with the last version I was using vs. release, but now it =20
crashes inside rubycocoa instead. So now every morning I do:

   svn update
   ruby install.rb setup
   sudo install.rb install

With my fingers crossed but I'm getting:

2007-11-14 10:24:19.723 Frictionless[10512:10b] LIBFFI : arg[5] -> =20
ffi_type 0xa04b4034
2007-11-14 10:24:19.723 Frictionless[10512:10b] OVMIX : Registered =20
Ruby method by selector =20
'outlineView:willDisplayCell:forTableColumn:item:' types =20
'v24@0:4@8@12@16@20'
/Library/Frameworks/RubyCocoa.framework/Resources/ruby/osx/objc/=20
oc_import.rb:266: [BUG] Bus Error
ruby 1.8.6 (2007-06-07) [universal-darwin9.0]

Abort trap

  My apps is open source from http://www.twinforces.com/frictionless/ =20=

though if you want to check it out.

Pierce

Re: [Rubycocoa-talk] [ANN] Rucola first release.

[Eloy D. <elo...@gm...>]

Oh and just to clarify, by the rubycocoa command
I mean newcocoa after it was added to RubyCocoa trunk.

Eloy

On 13 nov 2007, at 23:00, Dave Baldwin wrote:

> This looks interesting, but how does it differ from newcocoa?
>
> Thanks,
>
> Dave.
>
> On 4 Nov 2007, at 13:59, Eloy Duran wrote:
>
>> Hello,
>>
>> Yesterday we released the first alpha version of rucola:
>> =
http://www.superalloy.nl/blog/2007/11/04/rucola-a-rubycocoa-application-bu=
ilder/
>>
>> Eloy
>>
>> =3D
>> =3D
>> =3D
>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>> A Framework for building Cocoa applications in Ruby
>>
>> Rucola is a light weight framework that helps you write RubyCocoa
>> apps.
>> It allows you to build, test, and deploy applications using rake
>> commands,
>> eliminating the need to use XCode, however you can use XCode if you
>> wish.
>>
>> Rucola provides a set of generators to help you generate controllers,
>> window controllers,
>> and document-based applications. It also provides APIs for =20
>> simplifying
>> some of Objective-C=92s
>> ways of doing things.
>> =
-------------------------------------------------------------------------
>> This SF.net email is sponsored by: Splunk Inc.
>> Still grepping through log files to find problems?  Stop.
>> Now Search log events and configuration files using AJAX and a
>> browser.
>> Download your FREE copy of Splunk now >> http://get.splunk.com/
>> _______________________________________________
>> Rubycocoa-talk mailing list
>> Rub...@li...
>> https://lists.sourceforge.net/lists/listinfo/rubycocoa-talk
>
>
> =
-------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a =20
> browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Rubycocoa-talk mailing list
> Rub...@li...
> https://lists.sourceforge.net/lists/listinfo/rubycocoa-talk

Re: [Rubycocoa-talk] [ANN] Rucola first release.

[Eloy D. <elo...@gm...>]

Hi Dave,

Good question! :)

One important point for me is that it doesn't try to replace xcode.
Xcode "the application building framework" is a very powerful tool,
I just prefer using ruby tools (rake etc) over Xcode "the gui app".
In short it let's xcode handle the stuff it does well,
but adds some ruby flavor on top of it for common tasks.

One example of this is that it takes me longer
to setup all the base files that I want specifically
for a RubyCocoa application and also for how I like to work.
So now with one command I can have a controller
and possibly a window (nib) all setup to go.

Also very important to me is testing, or rather BDD.
(Behaviour or Beer, up to you.)
So it also creates a test file which is already setup
to work with the layout of the files on disk.
And it's configured to work with autotest, which makes
the "painful" process of fully testing your app a lot easier.

Also not unimportant is that it comes with a "support" lib.
Meaning that it comes with code which we find good to have,
like making registering for notifications easier and testing
osx related code easier etc etc.
This is where a lot of the development will happen in the future I =20
think.

It occurred to me, that most of the think work about this stuff was =20
already done
in another ruby project you might have heard of... yeah Rails.
It all boils down to convention over configuration.
So unsurprisingly if you are known with Rails,
the way stuff works will be familiar. If not, no problem.
I think it should be easy to enough to get started quickly.

Bear in mind though, that Rucola is just at 0.0.1.
And although 0.0.2 is not far away, it's still a very
young project. So I would not know if it would be
possible to replace the rubycocoa command with it yet.

Also Rucola's aim at the "problem" is a bit more radical,
thus not suitable for inclusion with RubyCocoa.
The rubycocoa command might still be useful
for people who already use it and value it.

Cheers,
Eloy

PS: Are there many people using the rubycocoa command?
If so, what functionality do you like most?

On 13 nov 2007, at 23:00, Dave Baldwin wrote:

> This looks interesting, but how does it differ from newcocoa?
>
> Thanks,
>
> Dave.
>
> On 4 Nov 2007, at 13:59, Eloy Duran wrote:
>
>> Hello,
>>
>> Yesterday we released the first alpha version of rucola:
>> =
http://www.superalloy.nl/blog/2007/11/04/rucola-a-rubycocoa-application-bu=
ilder/
>>
>> Eloy
>>
>> =3D
>> =3D
>> =3D=20
>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>> A Framework for building Cocoa applications in Ruby
>>
>> Rucola is a light weight framework that helps you write RubyCocoa
>> apps.
>> It allows you to build, test, and deploy applications using rake
>> commands,
>> eliminating the need to use XCode, however you can use XCode if you
>> wish.
>>
>> Rucola provides a set of generators to help you generate controllers,
>> window controllers,
>> and document-based applications. It also provides APIs for =20
>> simplifying
>> some of Objective-C=92s
>> ways of doing things.
>> =
-------------------------------------------------------------------------
>> This SF.net email is sponsored by: Splunk Inc.
>> Still grepping through log files to find problems?  Stop.
>> Now Search log events and configuration files using AJAX and a
>> browser.
>> Download your FREE copy of Splunk now >> http://get.splunk.com/
>> _______________________________________________
>> Rubycocoa-talk mailing list
>> Rub...@li...
>> https://lists.sourceforge.net/lists/listinfo/rubycocoa-talk
>
>
> =
-------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a =20
> browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Rubycocoa-talk mailing list
> Rub...@li...
> https://lists.sourceforge.net/lists/listinfo/rubycocoa-talk

Re: [Rubycocoa-talk] [ANN] Rucola first release.

[Dave B. <dav...@3d...>]

This looks interesting, but how does it differ from newcocoa?

Thanks,

Dave.

On 4 Nov 2007, at 13:59, Eloy Duran wrote:

> Hello,
>
> Yesterday we released the first alpha version of rucola:
> =
http://www.superalloy.nl/blog/2007/11/04/rucola-a-rubycocoa-application-bu=
ilder/
>
> Eloy
>
> =3D
> =3D
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> A Framework for building Cocoa applications in Ruby
>
> Rucola is a light weight framework that helps you write RubyCocoa =20
> apps.
> It allows you to build, test, and deploy applications using rake
> commands,
> eliminating the need to use XCode, however you can use XCode if you
> wish.
>
> Rucola provides a set of generators to help you generate controllers,
> window controllers,
> and document-based applications. It also provides APIs for simplifying
> some of Objective-C=92s
> ways of doing things.
> =
-------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a =20
> browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Rubycocoa-talk mailing list
> Rub...@li...
> https://lists.sourceforge.net/lists/listinfo/rubycocoa-talk

[Rubycocoa-talk] Totally stuck with Core Data on Leopard

[<jac...@gm...>]

Summary of post: I can't get ruby subclasses of NSMangedObject to work =20=

if they have their own attribute implementations with RubyCocoa on =20
Leopard. I desperately need this to work, have anybody solved this =20
problem?
---

I'm having major problems with porting my application to Leopard. The =20=

problem is that my application relies on ruby subclasses of =20
NSManagedObject which contains methods implementing the core data =20
attributes. The default attribute implementation provided by Core Data =20=

is not enough since changes in an attribute can trigger changes in =20
other attributes etc. Since I have a UI that uses bindings, a lot of =20
the access to my entities is happening from Obj-C and I need these =20
calls to go through the ruby methods of my entities.

I got this working quite well with RC 0.12.0 on Tiger. By overriding =20
setValue:forKey: and having it check for a ruby set-method before =20
passing the call on to the setValue:forKey: method in NSManagedObject =20=

I could get all access from Obj-C to the attributes to pass trough the =20=

ruby methods which was what I wanted. I also used KVO-observing to get =20=

notified of changes in certain attributes.

My problem is that this no longer works on Leopard. It seems that a =20
lot of changes have been made to Core Data in Leopard. The change that =20=

is causing the most trouble for me is (from the release notes):

"On Mac OS X v10.5, Core Data will dynamically generate public and =20
primitive get and set attribute accessor methods and relationship =20
accessor methods for managed object classes."

That means that Core Data no longer uses setValue:forKey: to set an =20
attribute but instead directly checks if there exists an Obj-C =20
implementation. If not, the default Core Data attribute implementation =20=

is used. This means that all changes through the GUI which uses =20
bindings will not go through my ruby classes.

I have tried a lot of ways to solve this problems:

* Providing primitiveXx/xx methods in the ruby class. They are not =20
seen by core data (as the corresponding methods in Obj-C would).
* Using KVO-observing to observe changes in the relevant attributes. =20
This works with the exception that the application becomes unstable. I =20=

have spent a lot of time trying to track down the source of the =20
instability but failed. Both 0.12.0 and the trunk have this problem on =20=

Leopard (but the same code works on Tiger). While googling for help, I =20=

have found advice from Cocoa gurus that 1) it's really difficult to =20
get KVO to work correctly with Core Data and 2) KVO should only be =20
used to keep your UI up to date, not to handle dependencies within =20
your application.
* Providing setXx/xx methods in a Obj-C superclass to my entity that =20
forwards the call to ruby methods (rbXx=3D/rbXx) in a ruby subclass. =20
This doesn't work, simply adding an empty ruby subclass to an Obj-C =20
subclass of NSMangedObject causes the enitty to fail creation of new =20
objects.
* ... I've also tried a lot of other weird hacks that I barely can =20
remember know....

I would really appreciate any advice on how to move forward on this =20
issue. Unless I find a solution really soon, I will have to rewrite =20
all my NSManagedObject subclasses in Objective-C.

Best regards,
Jacob Wallstr=F6m

Re: [Rubycocoa-talk] Leopard RubyCocoa & WebKit Failure

[Laurent S. <lsa...@ap...>]

Should be fixed in r2107.

trunk has now a smarter slave creation mechanism (on demand), but this  
caused an infinite-loop because an object was passed to ObjC within  
its #initialize method (and the slave was being re-created infinitely).

Laurent

On Nov 6, 2007, at 8:53 AM, kimura wataru wrote:

> Hi,
>
> This problem was reproduced with r2102 and Leopard's ruby,
> and was not reproduced with r2102 and Tiger + ruby-1.8.6- 
> p110(macports).
>
> On Sat, 3 Nov 2007 11:32:04 -0400, Laurent Sansonetti wrote:
>> In my environment (Leopard + Leopard's ruby + RubyCocoa trunk),
>> darkroom.rb still hangs. Ruby is taking 100% of CPU time.
>>
>> It's maybe a RubyCocoa trunk regression.
>>
> -- 
> kimura wataru
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a  
> browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Rubycocoa-talk mailing list
> Rub...@li...
> https://lists.sourceforge.net/lists/listinfo/rubycocoa-talk

Re: [Rubycocoa-talk] Leopard RubyCocoa & WebKit Failure

[kimura w. <ki...@us...>]

Hi,

This problem was reproduced with r2102 and Leopard's ruby,
and was not reproduced with r2102 and Tiger + ruby-1.8.6-p110(macports).

On Sat, 3 Nov 2007 11:32:04 -0400, Laurent Sansonetti wrote:
> In my environment (Leopard + Leopard's ruby + RubyCocoa trunk),  
> darkroom.rb still hangs. Ruby is taking 100% of CPU time.
> 
> It's maybe a RubyCocoa trunk regression.
> 
-- 
kimura wataru

Re: [Rubycocoa-talk] Installation Issues on Tiger

[Satoshi N. <sna...@in...>]

Hi Chris,

> When doing the binary installer I got a very generic
> "Error: Please try again message".

This is not harmful error.  Please ignore it.  It's fixed in the trunk.

For details, the installer would fail in the post flight script of the  
installer.  It replaces libruby.1.dylib to a symbolic link. If you  
install the binary distribution twice, it will fail and display the  
error.  But it's no harmful. Because libruby.1.dylib should be already  
updated.

--
Satoshi Nakagawa

Re: [Rubycocoa-talk] Installation Issues on Tiger

[Chris C. <cdc...@gm...>]

On Nov 5, 2007 10:25 AM, Eloy Duran <elo...@gm...> wrote:
> Hi Chris,
>
> Please see this mail for the problem: http://lists.sourceforge.jp/mailman/archives/rubycocoa-devel/2007-November/001194.html
> And a patch from Kimura-san: http://trac.macports.org/projects/macports/ticket/13135
>
> Eloy

Thanks,
That worked great for the first step of the build process, but when I
go to do ruby install.rb setup, after a lot of compiling, I get this
error:

Ld /Users/cdcarter/Desktop/RubyCocoa-0.12.0/framework/build/Default/RubyCocoa.framework/Versions/A/RubyCocoa
normal i386
    cd /Users/cdcarter/Desktop/RubyCocoa-0.12.0/framework
    /usr/bin/gcc-4.0 -o
/Users/cdcarter/Desktop/RubyCocoa-0.12.0/framework/build/Default/RubyCocoa.framework/Versions/A/RubyCocoa
-L/Users/cdcarter/Desktop/RubyCocoa-0.12.0/framework/build/Default
-L/usr/local/lib
-F/Users/cdcarter/Desktop/RubyCocoa-0.12.0/framework/build/Default
-filelist /Users/cdcarter/Desktop/RubyCocoa-0.12.0/framework/build/RubyCocoa.build/Default/RubyCocoa.build/Objects-normal/i386/RubyCocoa.LinkFileList
-framework Foundation -arch i386 -Wl,-single_module
-compatibility_version 1 -current_version 1 -install_name
@executable_path/../Frameworks/RubyCocoa.framework/Versions/A/RubyCocoa
-dynamiclib -mmacosx-version-min=10.4 -undefined suppress
-flat_namespace -lxml2 -L../../misc/libffi -L../misc/libffi -lffi
/usr/local/lib/libruby.1.8.6.dylib
/usr/bin/libtool: for architecture cputype (16777223) cpusubtype (3)
object: /usr/local/lib/libgcc_s.10.4.dylib malformed object (unknown
load command 4)
** BUILD FAILED **
setup failed
'system /usr/bin/xcodebuild' failed
try 'ruby install.rb --help' for usage

-- 
Chris Carter
concentrationstudios.com
brynmawrcs.com

Re: [Rubycocoa-talk] Installation Issues on Tiger

[Eloy D. <elo...@gm...>]

Hi Chris,

Please see this mail for the problem: http://lists.sourceforge.jp/mailman/archives/rubycocoa-devel/2007-November/001194.html
And a patch from Kimura-san: http://trac.macports.org/projects/macports/ticket/13135

Eloy

On 5 nov 2007, at 17:20, Chris Carter wrote:

> So today I went to build RubyCocoa on my tiger machine.  To be sure, I
> reinstalled Ruby with --enable-shared and things.  When doing the
> binary installer I got a very generic "Error: Please try again
> message".  I tried building from source and am getting this error
> message after a lot of processing:
> saurasaurusrex:~/Desktop/RubyCocoa-0.12.0 cdcarter$ ruby install.rb  
> config
> install.rb: entering config phase...
> create ext/rubycocoa/extconf.rb
> create framework/GeneratedConfig.xcconfig
> create framework/src/objc/Version.h
> create tests/Makefile
> ---> framework
> create /Users/cdcarter/Desktop/RubyCocoa-0.12.0/framework/src/objc/ 
> osx_ruby.h
> ...
> create /Users/cdcarter/Desktop/RubyCocoa-0.12.0/framework/src/objc/ 
> osx_intern.h
> ...
> BSROOT="/Users/cdcarter/Desktop/RubyCocoa-0.12.0/framework/bridge- 
> support"
> CFLAGS="" /usr/local/bin/ruby build.rb
> Generating BridgeSupport metadata for: CoreFoundation ...
>    Collect metadata (9.581525 seconds)
> /usr/local/lib/ruby/1.8/rexml/text.rb:292:in `normalize': private
> method `gsub' called for true:TrueClass (NoMethodError)
>        from /usr/local/lib/ruby/1.8/rexml/element.rb:1082:in `[]='
>        from /usr/local/lib/ruby/1.8/rexml/element.rb:586:in  
> `add_attribute'
>        from ./gen_bridge_metadata.rb:1435:in `generate_xml_document'
>        from ./gen_bridge_metadata.rb:1419:in `each'
>        from ./gen_bridge_metadata.rb:1419:in `generate_xml_document'
>        from ./gen_bridge_metadata.rb:551:in `xml_document'
>        from ./gen_bridge_metadata.rb:1511:in `generate_xml'
>        from ./gen_bridge_metadata.rb:1511:in `open'
>        from ./gen_bridge_metadata.rb:1511:in `generate_xml'
>        from ./gen_bridge_metadata.rb:542:in `write'
>        from build.rb:106
>        from build.rb:50:in `measure'
>        from build.rb:104
>        from build.rb:62:in `each'
>        from build.rb:62
> config failed
> hook /Users/cdcarter/Desktop/RubyCocoa-0.12.0/framework/post- 
> config.rb failed:
> 'system BSROOT="/Users/cdcarter/Desktop/RubyCocoa-0.12.0/framework/ 
> bridge-support"
> CFLAGS="" /usr/local/bin/ruby build.rb' failed
> try 'ruby install.rb --help' for usage
>
> Building from trunk yields this:
> saurasaurusrex:~/rubycocoa cdcarter$ ruby install.rb config
> install.rb: entering config phase...
> create ext/rubycocoa/extconf.rb
> create framework/GeneratedConfig.xcconfig
> create framework/src/objc/Version.h
> create tests/Makefile
> ---> framework
> create /Users/cdcarter/rubycocoa/framework/src/objc/osx_ruby.h ...
> create /Users/cdcarter/rubycocoa/framework/src/objc/osx_intern.h ...
> BSROOT="/Users/cdcarter/rubycocoa/framework/bridge-support" CFLAGS=""
> /usr/local/bin/ruby build.rb
> Generating BridgeSupport metadata for: CoreFoundation ...
>    Collect metadata (13.559733 seconds)
> /usr/local/lib/ruby/1.8/rexml/document.rb:186:in `write': undefined
> local variable or method `transitive' for <UNDEFINED> ...
> </>:REXML::Document (NameError)
>        from ./gen_bridge_metadata.rb:1516:in `generate_xml'
>        from ./gen_bridge_metadata.rb:1516:in `open'
>        from ./gen_bridge_metadata.rb:1516:in `generate_xml'
>        from ./gen_bridge_metadata.rb:542:in `write'
>        from build.rb:106
>        from build.rb:50:in `measure'
>        from build.rb:104
>        from build.rb:62:in `each'
>        from build.rb:62
> config failed
> hook /Users/cdcarter/rubycocoa/framework/post-config.rb failed:
> 'system BSROOT="/Users/cdcarter/rubycocoa/framework/bridge-support"
> CFLAGS="" /usr/local/bin/ruby build.rb' failed
> try 'ruby install.rb --help' for usage
>
> Any ideas?  Am I missing something huge?
>
> -- 
> Chris Carter
> concentrationstudios.com
> brynmawrcs.com
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a  
> browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Rubycocoa-talk mailing list
> Rub...@li...
> https://lists.sourceforge.net/lists/listinfo/rubycocoa-talk

[Rubycocoa-talk] Installation Issues on Tiger

[Chris C. <cdc...@gm...>]

So today I went to build RubyCocoa on my tiger machine.  To be sure, I
reinstalled Ruby with --enable-shared and things.  When doing the
binary installer I got a very generic "Error: Please try again
message".  I tried building from source and am getting this error
message after a lot of processing:
saurasaurusrex:~/Desktop/RubyCocoa-0.12.0 cdcarter$ ruby install.rb config
install.rb: entering config phase...
create ext/rubycocoa/extconf.rb
create framework/GeneratedConfig.xcconfig
create framework/src/objc/Version.h
create tests/Makefile
---> framework
create /Users/cdcarter/Desktop/RubyCocoa-0.12.0/framework/src/objc/osx_ruby.h
...
create /Users/cdcarter/Desktop/RubyCocoa-0.12.0/framework/src/objc/osx_intern.h
...
BSROOT="/Users/cdcarter/Desktop/RubyCocoa-0.12.0/framework/bridge-support"
CFLAGS="" /usr/local/bin/ruby build.rb
Generating BridgeSupport metadata for: CoreFoundation ...
    Collect metadata (9.581525 seconds)
/usr/local/lib/ruby/1.8/rexml/text.rb:292:in `normalize': private
method `gsub' called for true:TrueClass (NoMethodError)
        from /usr/local/lib/ruby/1.8/rexml/element.rb:1082:in `[]='
        from /usr/local/lib/ruby/1.8/rexml/element.rb:586:in `add_attribute'
        from ./gen_bridge_metadata.rb:1435:in `generate_xml_document'
        from ./gen_bridge_metadata.rb:1419:in `each'
        from ./gen_bridge_metadata.rb:1419:in `generate_xml_document'
        from ./gen_bridge_metadata.rb:551:in `xml_document'
        from ./gen_bridge_metadata.rb:1511:in `generate_xml'
        from ./gen_bridge_metadata.rb:1511:in `open'
        from ./gen_bridge_metadata.rb:1511:in `generate_xml'
        from ./gen_bridge_metadata.rb:542:in `write'
        from build.rb:106
        from build.rb:50:in `measure'
        from build.rb:104
        from build.rb:62:in `each'
        from build.rb:62
config failed
hook /Users/cdcarter/Desktop/RubyCocoa-0.12.0/framework/post-config.rb failed:
'system BSROOT="/Users/cdcarter/Desktop/RubyCocoa-0.12.0/framework/bridge-support"
CFLAGS="" /usr/local/bin/ruby build.rb' failed
try 'ruby install.rb --help' for usage

Building from trunk yields this:
saurasaurusrex:~/rubycocoa cdcarter$ ruby install.rb config
install.rb: entering config phase...
create ext/rubycocoa/extconf.rb
create framework/GeneratedConfig.xcconfig
create framework/src/objc/Version.h
create tests/Makefile
---> framework
create /Users/cdcarter/rubycocoa/framework/src/objc/osx_ruby.h ...
create /Users/cdcarter/rubycocoa/framework/src/objc/osx_intern.h ...
BSROOT="/Users/cdcarter/rubycocoa/framework/bridge-support" CFLAGS=""
/usr/local/bin/ruby build.rb
Generating BridgeSupport metadata for: CoreFoundation ...
    Collect metadata (13.559733 seconds)
/usr/local/lib/ruby/1.8/rexml/document.rb:186:in `write': undefined
local variable or method `transitive' for <UNDEFINED> ...
</>:REXML::Document (NameError)
        from ./gen_bridge_metadata.rb:1516:in `generate_xml'
        from ./gen_bridge_metadata.rb:1516:in `open'
        from ./gen_bridge_metadata.rb:1516:in `generate_xml'
        from ./gen_bridge_metadata.rb:542:in `write'
        from build.rb:106
        from build.rb:50:in `measure'
        from build.rb:104
        from build.rb:62:in `each'
        from build.rb:62
config failed
hook /Users/cdcarter/rubycocoa/framework/post-config.rb failed:
'system BSROOT="/Users/cdcarter/rubycocoa/framework/bridge-support"
CFLAGS="" /usr/local/bin/ruby build.rb' failed
try 'ruby install.rb --help' for usage

Any ideas?  Am I missing something huge?

-- 
Chris Carter
concentrationstudios.com
brynmawrcs.com

Re: [Rubycocoa-talk] Can't get Objective-C method signature in Leopard

[Rod S. <rsc...@xm...>]

I am using the one that ships with Leopard.

Is it possible to install the trunk and keep things separate? I don't  
want to mess up my Leopard install.

Also, I had to release to fix these bugs so I moved the methods back  
into Objective-C.

Rod

On Nov 4, 2007, at 7:03 AM, Eloy Duran wrote:

> Hey Rod,
>
> I used to have a problem similar to this one.
> In my case I was unable to add/override instance methods, but was able
> to add/override class methods.
> Anyways, I have tried my code again to see if the problem still
> persisted in the current trunk, which it doesn't.
>
> Which version of RC are you using? The one that ships with Leopard?
> If so, could you give the trunk a try?
>
> Cheers,
> Eloy
>
> On 3 nov 2007, at 20:56, Rod Schmidt wrote:
>
>> The OSX module is required.
>>
>> I have imported the BackpackReminder class.
>>
>> 3) The CSS_class method does not exist on the ObjC side.
>>
>> One other piece of information is that BackpackReminder descends from
>> NSManagedObject. Could CoreData be messing things up? The inheritance
>> hierarchy is:
>>
>> NSManagedObject -> BackpackManagedObject -> BackpackReminder
>>
>> Rod
>>
>> On Nov 3, 2007, at 1:07 PM, Laurent Sansonetti wrote:
>>
>>> On Nov 3, 2007 1:18 PM, Rod Schmidt <rsc...@xm...> wrote:
>>>> I have the following Ruby code in my RubyCocoa app (in which I have
>>>> mostly Objective-C with some Ruby).
>>>>
>>>> class BackpackReminder
>>>>      def CSS_class
>>>>              date = NSDateToRubyDateTime(self.date)
>>>>              now = DateTime.now
>>>>              days_from_now = date.jd - now.jd
>>>>              if days_from_now <= 30 then
>>>>                      "day#{days_from_now}"
>>>>              else
>>>>                      "month#{self.months_from_now}"
>>>>              end
>>>>      end
>>>> end
>>>>
>>>> BackpackReminder is an Objective-C class, so I am reopening this
>>>> class
>>>> and adding the CSS_Class method. This worked fine in Tiger. When I
>>>> run
>>>> the app I get the following:
>>>>
>>>> 11/3/07 12:55:52 PM PackRat[1109] PageGenerator#generateHTML:
>>>> OSX::OCMessageSendException: Can't get Objective-C method signature
>>>> for selector 'CSS:class' of receiver
>>>> #<OSX::BackpackReminder_BackpackReminder_:0x265a5c
>>>> class='BackpackReminder' id=0x6115b0>
>>>> 11/3/07 12:55:52 PM PackRat[1109] Exception raised during posting  
>>>> of
>>>> notification.  Ignored.  exception: 'Can't get Objective-C method
>>>> signature for selector 'CSS:class' of receiver
>>>> #<OSX::BackpackReminder_BackpackReminder_:0x265a5c
>>>> class='BackpackReminder' id=0x6115b0>'  invoked observer method:
>>>> '*** -
>>>> [PackRatAppDelegate tableViewSelectionDidChange:]'  observer:
>>>> 0x6f3dd0  notification name:
>>>> 'NSTableViewSelectionDidChangeNotification'
>>>>
>>>> If I rename the method and remove the underscore and rename it
>>>> something like CSSClass, I get the same message (with the method
>>>> name
>>>> changed of course). Has something changed in the Leopard version of
>>>> RubyCocoa that prevents you from reopening classes and adding
>>>> methods?
>>>>
>>>
>>> No, nothing changed in this logic. However, most of the code that
>>> adds
>>> or overrides methods was ported to the ObjC 2.0 API, and maybe there
>>> is a regression in that area.
>>>
>>> I am nevertheless unable to reproduce this in a quick test.
>>>
>>> A few questions:
>>>
>>> 1/ Is the OSX module required?
>>>
>>> 2/ Does it also happen if you explicitly import the BackpackReminder
>>> class before doing the override? You can add ''OSX.ns_import :
>>> BackpackReminder'' at the beginning of the file to try that.
>>>
>>> 3/ Does the CSS_class method exists in the ObjC side?
>>>
>>> Thanks,
>>> Laurent
>>>
>>> -------------------------------------------------------------------------
>>> This SF.net email is sponsored by: Splunk Inc.
>>> Still grepping through log files to find problems?  Stop.
>>> Now Search log events and configuration files using AJAX and a
>>> browser.
>>> Download your FREE copy of Splunk now >> http://get.splunk.com/
>>> _______________________________________________
>>> Rubycocoa-talk mailing list
>>> Rub...@li...
>>> https://lists.sourceforge.net/lists/listinfo/rubycocoa-talk
>>
>>
>> -------------------------------------------------------------------------
>> This SF.net email is sponsored by: Splunk Inc.
>> Still grepping through log files to find problems?  Stop.
>> Now Search log events and configuration files using AJAX and a
>> browser.
>> Download your FREE copy of Splunk now >> http://get.splunk.com/
>> _______________________________________________
>> Rubycocoa-talk mailing list
>> Rub...@li...
>> https://lists.sourceforge.net/lists/listinfo/rubycocoa-talk
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a  
> browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Rubycocoa-talk mailing list
> Rub...@li...
> https://lists.sourceforge.net/lists/listinfo/rubycocoa-talk

[Rubycocoa-talk] Fwd: [ANN] Rucola first release.

[Eloy D. <elo...@gm...>]

I just updated the post to include the screencast that was showed at =20
RubyConf.

Eloy

Begin forwarded message:

> From: Eloy Duran <elo...@gm...>
> Date: 4 november 2007 14:59:53 GMT+01:00
> To: rub...@li...
> Subject: [ANN] Rucola first release.
>
> Hello,
>
> Yesterday we released the first alpha version of rucola:
> =
http://www.superalloy.nl/blog/2007/11/04/rucola-a-rubycocoa-application-bu=
ilder/
>
> Eloy
>
> =3D=20
> =3D=20
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> A Framework for building Cocoa applications in Ruby
>
> Rucola is a light weight framework that helps you write RubyCocoa =20
> apps.
> It allows you to build, test, and deploy applications using rake =20
> commands,
> eliminating the need to use XCode, however you can use XCode if you =20=

> wish.
>
> Rucola provides a set of generators to help you generate =20
> controllers, window controllers,
> and document-based applications. It also provides APIs for =20
> simplifying some of Objective-C=92s
> ways of doing things.

Re: [Rubycocoa-talk] Can't get Objective-C method signature in Leopard

[Eloy D. <elo...@gm...>]

Hey Rod,

I used to have a problem similar to this one.
In my case I was unable to add/override instance methods, but was able  
to add/override class methods.
Anyways, I have tried my code again to see if the problem still  
persisted in the current trunk, which it doesn't.

Which version of RC are you using? The one that ships with Leopard?
If so, could you give the trunk a try?

Cheers,
Eloy

On 3 nov 2007, at 20:56, Rod Schmidt wrote:

> The OSX module is required.
>
> I have imported the BackpackReminder class.
>
> 3) The CSS_class method does not exist on the ObjC side.
>
> One other piece of information is that BackpackReminder descends from
> NSManagedObject. Could CoreData be messing things up? The inheritance
> hierarchy is:
>
> NSManagedObject -> BackpackManagedObject -> BackpackReminder
>
> Rod
>
> On Nov 3, 2007, at 1:07 PM, Laurent Sansonetti wrote:
>
>> On Nov 3, 2007 1:18 PM, Rod Schmidt <rsc...@xm...> wrote:
>>> I have the following Ruby code in my RubyCocoa app (in which I have
>>> mostly Objective-C with some Ruby).
>>>
>>> class BackpackReminder
>>>       def CSS_class
>>>               date = NSDateToRubyDateTime(self.date)
>>>               now = DateTime.now
>>>               days_from_now = date.jd - now.jd
>>>               if days_from_now <= 30 then
>>>                       "day#{days_from_now}"
>>>               else
>>>                       "month#{self.months_from_now}"
>>>               end
>>>       end
>>> end
>>>
>>> BackpackReminder is an Objective-C class, so I am reopening this
>>> class
>>> and adding the CSS_Class method. This worked fine in Tiger. When I
>>> run
>>> the app I get the following:
>>>
>>> 11/3/07 12:55:52 PM PackRat[1109] PageGenerator#generateHTML:
>>> OSX::OCMessageSendException: Can't get Objective-C method signature
>>> for selector 'CSS:class' of receiver
>>> #<OSX::BackpackReminder_BackpackReminder_:0x265a5c
>>> class='BackpackReminder' id=0x6115b0>
>>> 11/3/07 12:55:52 PM PackRat[1109] Exception raised during posting of
>>> notification.  Ignored.  exception: 'Can't get Objective-C method
>>> signature for selector 'CSS:class' of receiver
>>> #<OSX::BackpackReminder_BackpackReminder_:0x265a5c
>>> class='BackpackReminder' id=0x6115b0>'  invoked observer method:
>>> '*** -
>>> [PackRatAppDelegate tableViewSelectionDidChange:]'  observer:
>>> 0x6f3dd0  notification name:
>>> 'NSTableViewSelectionDidChangeNotification'
>>>
>>> If I rename the method and remove the underscore and rename it
>>> something like CSSClass, I get the same message (with the method  
>>> name
>>> changed of course). Has something changed in the Leopard version of
>>> RubyCocoa that prevents you from reopening classes and adding
>>> methods?
>>>
>>
>> No, nothing changed in this logic. However, most of the code that  
>> adds
>> or overrides methods was ported to the ObjC 2.0 API, and maybe there
>> is a regression in that area.
>>
>> I am nevertheless unable to reproduce this in a quick test.
>>
>> A few questions:
>>
>> 1/ Is the OSX module required?
>>
>> 2/ Does it also happen if you explicitly import the BackpackReminder
>> class before doing the override? You can add ''OSX.ns_import :
>> BackpackReminder'' at the beginning of the file to try that.
>>
>> 3/ Does the CSS_class method exists in the ObjC side?
>>
>> Thanks,
>> Laurent
>>
>> -------------------------------------------------------------------------
>> This SF.net email is sponsored by: Splunk Inc.
>> Still grepping through log files to find problems?  Stop.
>> Now Search log events and configuration files using AJAX and a
>> browser.
>> Download your FREE copy of Splunk now >> http://get.splunk.com/
>> _______________________________________________
>> Rubycocoa-talk mailing list
>> Rub...@li...
>> https://lists.sourceforge.net/lists/listinfo/rubycocoa-talk
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a  
> browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Rubycocoa-talk mailing list
> Rub...@li...
> https://lists.sourceforge.net/lists/listinfo/rubycocoa-talk

[Rubycocoa-talk] [ANN] Rucola first release.

[Eloy D. <elo...@gm...>]

Hello,

Yesterday we released the first alpha version of rucola:
=
http://www.superalloy.nl/blog/2007/11/04/rucola-a-rubycocoa-application-bu=
ilder/

Eloy

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
A Framework for building Cocoa applications in Ruby

Rucola is a light weight framework that helps you write RubyCocoa apps.
It allows you to build, test, and deploy applications using rake =20
commands,
eliminating the need to use XCode, however you can use XCode if you =20
wish.

Rucola provides a set of generators to help you generate controllers, =20=

window controllers,
and document-based applications. It also provides APIs for simplifying =20=

some of Objective-C=92s
ways of doing things.=

Re: [Rubycocoa-talk] Leopard RubyCocoa & WebKit Failure

[Rich C. <ric...@ma...>]

Kimura,

That fixed it for me. I am in your debt.

Thanks,

RC
On Nov 3, 2007, at 11:32 AM, Laurent Sansonetti wrote:

> In my environment (Leopard + Leopard's ruby + RubyCocoa trunk),
> darkroom.rb still hangs. Ruby is taking 100% of CPU time.
>
> It's maybe a RubyCocoa trunk regression.
>
> Laurent
>
> On Nov 3, 2007, at 4:58 AM, kimura wataru wrote:
>
>> Hi,
>>
>> It seems that the content of window is not drew. I added
>> window.orderFront(), then darkroom.rb works fine on Leopard.
>>
>> Index: darkroom.rb
>> ===================================================================
>> --- darkroom.rb	(revision 2102)
>> +++ darkroom.rb	(working copy)
>> @@ -88,6 +88,7 @@
>>
>>      def webView_didFinishLoadForFrame(web_view, frame)
>>        viewport = web_view.mainFrame.frameView.documentView
>> +        viewport.window.orderFront(nil)
>>        viewport.window.display
>>        viewport.window.setContentSize([@options[:width],
>> (@options[:height] > 0 ? @options[:height] :  
>> viewport.bounds.height)])
>>        viewport.setFrame(viewport.bounds)
>>
>> On Sat, 27 Oct 2007 10:20:44 -0400, Rich Curtis wrote:
>>> Hi List,
>>>
>>> Tried running the RubyCocoa darkroom.rb (/Developer/Examples/
>>> RubyCocoa/
>>> Scripts/darkroom.rb) example today that came with the Leopard Dev
>>> Tools Examples and it horked:
>>>
>> -- 
>> kimura wataru
>>
>> -------------------------------------------------------------------------
>> This SF.net email is sponsored by: Splunk Inc.
>> Still grepping through log files to find problems?  Stop.
>> Now Search log events and configuration files using AJAX and a
>> browser.
>> Download your FREE copy of Splunk now >> http://get.splunk.com/
>> _______________________________________________
>> Rubycocoa-talk mailing list
>> Rub...@li...
>> https://lists.sourceforge.net/lists/listinfo/rubycocoa-talk
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a  
> browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Rubycocoa-talk mailing list
> Rub...@li...
> https://lists.sourceforge.net/lists/listinfo/rubycocoa-talk

Re: [Rubycocoa-talk] Can't get Objective-C method signature in Leopard

[Rod S. <rsc...@xm...>]

The OSX module is required.

I have imported the BackpackReminder class.

3) The CSS_class method does not exist on the ObjC side.

One other piece of information is that BackpackReminder descends from  
NSManagedObject. Could CoreData be messing things up? The inheritance  
hierarchy is:

NSManagedObject -> BackpackManagedObject -> BackpackReminder

Rod

On Nov 3, 2007, at 1:07 PM, Laurent Sansonetti wrote:

> On Nov 3, 2007 1:18 PM, Rod Schmidt <rsc...@xm...> wrote:
>> I have the following Ruby code in my RubyCocoa app (in which I have
>> mostly Objective-C with some Ruby).
>>
>> class BackpackReminder
>>        def CSS_class
>>                date = NSDateToRubyDateTime(self.date)
>>                now = DateTime.now
>>                days_from_now = date.jd - now.jd
>>                if days_from_now <= 30 then
>>                        "day#{days_from_now}"
>>                else
>>                        "month#{self.months_from_now}"
>>                end
>>        end
>> end
>>
>> BackpackReminder is an Objective-C class, so I am reopening this  
>> class
>> and adding the CSS_Class method. This worked fine in Tiger. When I  
>> run
>> the app I get the following:
>>
>> 11/3/07 12:55:52 PM PackRat[1109] PageGenerator#generateHTML:
>> OSX::OCMessageSendException: Can't get Objective-C method signature
>> for selector 'CSS:class' of receiver
>> #<OSX::BackpackReminder_BackpackReminder_:0x265a5c
>> class='BackpackReminder' id=0x6115b0>
>> 11/3/07 12:55:52 PM PackRat[1109] Exception raised during posting of
>> notification.  Ignored.  exception: 'Can't get Objective-C method
>> signature for selector 'CSS:class' of receiver
>> #<OSX::BackpackReminder_BackpackReminder_:0x265a5c
>> class='BackpackReminder' id=0x6115b0>'  invoked observer method:  
>> '*** -
>> [PackRatAppDelegate tableViewSelectionDidChange:]'  observer:
>> 0x6f3dd0  notification name:  
>> 'NSTableViewSelectionDidChangeNotification'
>>
>> If I rename the method and remove the underscore and rename it
>> something like CSSClass, I get the same message (with the method name
>> changed of course). Has something changed in the Leopard version of
>> RubyCocoa that prevents you from reopening classes and adding  
>> methods?
>>
>
> No, nothing changed in this logic. However, most of the code that adds
> or overrides methods was ported to the ObjC 2.0 API, and maybe there
> is a regression in that area.
>
> I am nevertheless unable to reproduce this in a quick test.
>
> A few questions:
>
> 1/ Is the OSX module required?
>
> 2/ Does it also happen if you explicitly import the BackpackReminder
> class before doing the override? You can add ''OSX.ns_import :
> BackpackReminder'' at the beginning of the file to try that.
>
> 3/ Does the CSS_class method exists in the ObjC side?
>
> Thanks,
> Laurent
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a  
> browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Rubycocoa-talk mailing list
> Rub...@li...
> https://lists.sourceforge.net/lists/listinfo/rubycocoa-talk

Re: [Rubycocoa-talk] Can't get Objective-C method signature in Leopard

[Laurent S. <lau...@gm...>]

On Nov 3, 2007 1:18 PM, Rod Schmidt <rsc...@xm...> wrote:
> I have the following Ruby code in my RubyCocoa app (in which I have
> mostly Objective-C with some Ruby).
>
> class BackpackReminder
>         def CSS_class
>                 date = NSDateToRubyDateTime(self.date)
>                 now = DateTime.now
>                 days_from_now = date.jd - now.jd
>                 if days_from_now <= 30 then
>                         "day#{days_from_now}"
>                 else
>                         "month#{self.months_from_now}"
>                 end
>         end
> end
>
> BackpackReminder is an Objective-C class, so I am reopening this class
> and adding the CSS_Class method. This worked fine in Tiger. When I run
> the app I get the following:
>
> 11/3/07 12:55:52 PM PackRat[1109] PageGenerator#generateHTML:
> OSX::OCMessageSendException: Can't get Objective-C method signature
> for selector 'CSS:class' of receiver
> #<OSX::BackpackReminder_BackpackReminder_:0x265a5c
> class='BackpackReminder' id=0x6115b0>
> 11/3/07 12:55:52 PM PackRat[1109] Exception raised during posting of
> notification.  Ignored.  exception: 'Can't get Objective-C method
> signature for selector 'CSS:class' of receiver
> #<OSX::BackpackReminder_BackpackReminder_:0x265a5c
> class='BackpackReminder' id=0x6115b0>'  invoked observer method: '*** -
> [PackRatAppDelegate tableViewSelectionDidChange:]'  observer:
> 0x6f3dd0  notification name: 'NSTableViewSelectionDidChangeNotification'
>
> If I rename the method and remove the underscore and rename it
> something like CSSClass, I get the same message (with the method name
> changed of course). Has something changed in the Leopard version of
> RubyCocoa that prevents you from reopening classes and adding methods?
>

No, nothing changed in this logic. However, most of the code that adds
or overrides methods was ported to the ObjC 2.0 API, and maybe there
is a regression in that area.

I am nevertheless unable to reproduce this in a quick test.

A few questions:

1/ Is the OSX module required?

2/ Does it also happen if you explicitly import the BackpackReminder
class before doing the override? You can add ''OSX.ns_import :
BackpackReminder'' at the beginning of the file to try that.

3/ Does the CSS_class method exists in the ObjC side?

Thanks,
Laurent

[Rubycocoa-talk] Can't get Objective-C method signature in Leopard

[Rod S. <rsc...@xm...>]

I have the following Ruby code in my RubyCocoa app (in which I have  
mostly Objective-C with some Ruby).

class BackpackReminder
	def CSS_class
		date = NSDateToRubyDateTime(self.date)
		now = DateTime.now
		days_from_now = date.jd - now.jd
		if days_from_now <= 30 then
			"day#{days_from_now}"
		else
			"month#{self.months_from_now}"
		end
	end
end

BackpackReminder is an Objective-C class, so I am reopening this class  
and adding the CSS_Class method. This worked fine in Tiger. When I run  
the app I get the following:

11/3/07 12:55:52 PM PackRat[1109] PageGenerator#generateHTML:  
OSX::OCMessageSendException: Can't get Objective-C method signature  
for selector 'CSS:class' of receiver  
#<OSX::BackpackReminder_BackpackReminder_:0x265a5c  
class='BackpackReminder' id=0x6115b0>
11/3/07 12:55:52 PM PackRat[1109] Exception raised during posting of  
notification.  Ignored.  exception: 'Can't get Objective-C method  
signature for selector 'CSS:class' of receiver  
#<OSX::BackpackReminder_BackpackReminder_:0x265a5c  
class='BackpackReminder' id=0x6115b0>'  invoked observer method: '*** - 
[PackRatAppDelegate tableViewSelectionDidChange:]'  observer:  
0x6f3dd0  notification name: 'NSTableViewSelectionDidChangeNotification'

If I rename the method and remove the underscore and rename it  
something like CSSClass, I get the same message (with the method name  
changed of course). Has something changed in the Leopard version of  
RubyCocoa that prevents you from reopening classes and adding methods?

Rod Schmidt

Re: [Rubycocoa-talk] Leopard RubyCocoa & WebKit Failure

[Laurent S. <lsa...@ap...>]

In my environment (Leopard + Leopard's ruby + RubyCocoa trunk),  
darkroom.rb still hangs. Ruby is taking 100% of CPU time.

It's maybe a RubyCocoa trunk regression.

Laurent

On Nov 3, 2007, at 4:58 AM, kimura wataru wrote:

> Hi,
>
> It seems that the content of window is not drew. I added
> window.orderFront(), then darkroom.rb works fine on Leopard.
>
> Index: darkroom.rb
> ===================================================================
> --- darkroom.rb	(revision 2102)
> +++ darkroom.rb	(working copy)
> @@ -88,6 +88,7 @@
>
>       def webView_didFinishLoadForFrame(web_view, frame)
>         viewport = web_view.mainFrame.frameView.documentView
> +        viewport.window.orderFront(nil)
>         viewport.window.display
>         viewport.window.setContentSize([@options[:width],  
> (@options[:height] > 0 ? @options[:height] : viewport.bounds.height)])
>         viewport.setFrame(viewport.bounds)
>
> On Sat, 27 Oct 2007 10:20:44 -0400, Rich Curtis wrote:
>> Hi List,
>>
>> Tried running the RubyCocoa darkroom.rb (/Developer/Examples/ 
>> RubyCocoa/
>> Scripts/darkroom.rb) example today that came with the Leopard Dev
>> Tools Examples and it horked:
>>
> -- 
> kimura wataru
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a  
> browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Rubycocoa-talk mailing list
> Rub...@li...
> https://lists.sourceforge.net/lists/listinfo/rubycocoa-talk

Re: [Rubycocoa-talk] Leopard RubyCocoa & WebKit Failure

[kimura w. <ki...@us...>]

Hi,

It seems that the content of window is not drew. I added
window.orderFront(), then darkroom.rb works fine on Leopard.

Index: darkroom.rb
===================================================================
--- darkroom.rb	(revision 2102)
+++ darkroom.rb	(working copy)
@@ -88,6 +88,7 @@
   
       def webView_didFinishLoadForFrame(web_view, frame)
         viewport = web_view.mainFrame.frameView.documentView
+        viewport.window.orderFront(nil)
         viewport.window.display
         viewport.window.setContentSize([@options[:width], (@options[:height] > 0 ? @options[:height] : viewport.bounds.height)])
         viewport.setFrame(viewport.bounds)

On Sat, 27 Oct 2007 10:20:44 -0400, Rich Curtis wrote:
> Hi List,
> 
> Tried running the RubyCocoa darkroom.rb (/Developer/Examples/RubyCocoa/ 
> Scripts/darkroom.rb) example today that came with the Leopard Dev  
> Tools Examples and it horked:
> 
-- 
kimura wataru