I think it would be easier to collaborate on a project like this if we had a good forum - where threads can be sticked, announcements be posted etc
It's one of the things I miss from the PHP world, where there are lots of communities using forums very effectively. From support to collaboration, to just getting to know each other. I actually came to Ruby (Rails) so I could move away from forum-based sites (which I've been into for years) but I'd be willing to do one last one for Ruby if enough people wanted it - we could have separate categories for projects like MacRuby, Rails, etc, with their respective leaders having mod permissions to post announcements/stick threads etc (but the low level 'spam' moderating etc would be left to me and my mod team. Does that interest anyone? Aston On 13 Sep 2011, at 21:37, Jeremy Hinegardner wrote: > True, waiting on Laurent for this may be the wrong approach. I have done > a fair bit of my own investigation, and do not know where to go next, hence > posting here. > > In short, yes, Amalgalite uses and exposes more features of SQLite than are > generally available from default builds, and even OSX's non-default build, > hence embedding it in the ruby extension itself. > > To help, I would really like to understand the pros/cons of using flat vs. > twolevel namespaces with respect to MacRuby and extensions. > > enjoy, > > -jeremy > > On Tue, Sep 13, 2011 at 12:11:06PM -0700, Jordan K. Hubbard wrote: >> I'm not Laurent, but I'll also say that simply waiting for him to answer >> this question may be the wrong approach. For one, the project (in order to >> truly be successful) needs to move away from the "single point of failure" >> model that over-reliance on Laurent has historically represented. This >> means that it needs to grow some of its own talent and expertise and the >> "wait and see what Laurent says" approach runs counter to this objective. >> Second, this may be a problem that really needs to be addressed in the >> Amalgalite gem itself since any component which ships with duplicate >> technology to what's in the OS runs the risk of the same namespace (and >> other) conflicts. Are the additional compile-time features really that >> important to the gem? >> >> Thanks, >> >> - Jordan >> >> On Sep 13, 2011, at 8:12 AM, Jeremy Hinegardner wrote: >> >>> Thanks, and lets hope Laurent can tell us what to do here :-). >>> >>> enjoy, >>> >>> -jeremy >>> >>> On Mon, Sep 12, 2011 at 07:39:37PM -0700, Matt Aimonetti wrote: >>>> That's a good question, and honestly I have no idea :( >>>> Laurent is on vacation so he's not checking the mailing list, but he should >>>> be back soon and hopefully he will have an answer. >>>> >>>> - Matt >>>> >>>> On Mon, Sep 12, 2011 at 11:39 AM, Jeremy Hinegardner >>>> <jer...@hinegardner.org >>>>> wrote: >>>> >>>>> Hey all, >>>>> >>>>> I develop the Amalgalite gem[1] and it ships with its own copy of SQLite. >>>>> It does this as it adds in additional compile-time features, and I try and >>>>> keep it as current as posssible. >>>>> >>>>> The problem is that since MacRuby is linked to CoreServices etc, the >>>>> sqlite >>>>> library that ships with OSX gets linked at runtime before the sqlite >>>>> library >>>>> that is built into the amalgalite gem extension. I've encountered this >>>>> before[2] with amalgalite, when it was loaded with my 'hitimes' gem (which >>>>> on osx links >>>>> against -framework CoreServes). >>>>> >>>>> I am wondering what the appropriate approach is here. I was able to fix >>>>> this in >>>>> MRI by compiling MRI with -twolevel_namespace and I think there is an open >>>>> ticket >>>>> with ruby-core to see if MRI on osx should be compiled with that flag. >>>>> >>>>> I attempted to compile MacRuby with -twolevel_namespace to resolve this, >>>>> and I >>>>> was unsuccessful. There appeared to be other flags that conflicted with >>>>> it. >>>>> >>>>> I would expect something like this may also affect the nokogiri gem as >>>>> limxml2 >>>>> is also a system library on osx, and may conflict with the version that >>>>> nokogiri >>>>> expects. >>>>> >>>>> Thoughts? Opinions? I'm sure this is a rare case, Amalgalite may be the >>>>> only >>>>> project that could experience an issue like this. What is the best way to >>>>> handle >>>>> this in the MacRuby ecosystem? >>>>> >>>>> enjoy, >>>>> >>>>> -jeremy >>>>> >>>>> [1] - https://github.com/copiousfreetime/amalgalite >>>>> [2] - >>>>> https://github.com/copiousfreetime/amalgalite/blob/master/lib/amalgalite/sqlite3/version.rb#L42-L56-54 >>>>> -- >>>>> ======================================================================== >>>>> Jeremy Hinegardner jer...@hinegardner.org >>>>> >>>>> _______________________________________________ >>>>> MacRuby-devel mailing list >>>>> MacRuby-devel@lists.macosforge.org >>>>> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel >>>>> >>> >>> -- >>> ======================================================================== >>> Jeremy Hinegardner jer...@hinegardner.org >>> >>> _______________________________________________ >>> MacRuby-devel mailing list >>> MacRuby-devel@lists.macosforge.org >>> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel >> > > -- > ======================================================================== > Jeremy Hinegardner jer...@hinegardner.org > > _______________________________________________ > MacRuby-devel mailing list > MacRuby-devel@lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel _______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
