Re: RE: [Wxruby-dev] Cable ties

[Bob Calco]

I vote for Cable - I have a design plan for creating the Ruby emitter, which I 
will attempt to make public this week so we can collaborate on it.

Sorry for my long silence; my wife has been in the hospital on bedrest (32 
weeks pregnant) for the last four weeks, and will be in another 4-8 weeks, and 
I've been doing a lot of Mr. Mom lately.

- Bob Calco
> 
> From: "Curt Hibbs" <address@hidden>
> Date: 2003/02/16 Sun PM 01:07:55 CST
> To: <address@hidden>, 
>       <address@hidden>
> Subject: RE: [Wxruby-dev] Cable ties
> 
> repeater wrote:
> > curt wrote:
> > > If you are interested in joining the project, perhaps you would be
> > > interested in checking out Cable to see if we can use it in
> > place of SWIG.
> >
> > hmm this is interesting. i'd like to test it out, but at first sight it
> > seems to be only supporting tcl right now.
> 
> A ruby emitter would need to be created, so the question is how
> easy/difficult does this appear to be, and the next question would be
> whether the payoff would be worth the effort.
> 
> The problem with SWIG is that it isn't sophisticated enough about processing
> C++ header files, so it becomes necessary to write interface files, and
> these interface files require ongoing maintenance to stay in sync with the
> underlying C++ source code. This is probably an acceptable "evil" if there
> is no other choice. However being able to process C++ header files directly
> (without the need to interface files) would be preferable.
> 
> I'm trying to take a long-term view here. I'm (slightly) more concerned
> about the long-term maintenance costs than the initial development costs.
> 
> > i suggest our modus operandi with Cable:
> > a) wait until perl/python hordes releases a binding. there are
> > many more of
> > them, and the path to ruby is better from there, so we can easily create a
> > binding based on their attempts. (better than being the 2nd non-tcl
> > interpreted lang)
> > b) as the p-language bindings realize, and if Cable is as amazing as they
> > claim, surely some projects will start to utilize it. it is best to make a
> > judgement call about the amount of effort and functionality needed by
> > looking at a working large example.
> >
> > i'd consider the Cable route a wait-and-see don't you think.
> > overdepending right now could damage the progress of the swig route.
> 
> I think we would probably pick one route (SWIG or Cable) and stick with it.
> I wouldn't see us changing later on.
> 
> > and about the swig sentiment, the main critique seems to be too much
> > micro-management, but i think if we are clever we could avoid it in this
> > project. but ho! the best way to regain my sanity, is to dive
> > into swig-land
> > a bit and see for myself
> 
> Sure, I just want to avoid, if possible, being in the position of having to
> manually synchronize a bunch of interface files with a large set of C++
> header files. I initially tried to use SWIG without interface files
> (theoretically possible) but gave up because SWIG couldn't properly parse
> all of wxWinbdow's C++ header files.
> 
> Curt
> 
> 
> 
> _______________________________________________
> Wxruby-dev mailing list
> address@hidden
> http://mail.nongnu.org/mailman/listinfo/wxruby-dev
>