[MacRuby-devel] -twolevel_namespace issue?

Tue Sep 13 14:59:12 PDT 2011

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 <jeremy at 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                              jeremy at hinegardner.org
>>>>> 
>>>>> _______________________________________________
>>>>> MacRuby-devel mailing list
>>>>> MacRuby-devel at lists.macosforge.org
>>>>> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
>>>>> 
>>> 
>>> -- 
>>> ========================================================================
>>> Jeremy Hinegardner                              jeremy at hinegardner.org 
>>> 
>>> _______________________________________________
>>> MacRuby-devel mailing list
>>> MacRuby-devel at lists.macosforge.org
>>> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
>> 
> 
> -- 
> ========================================================================
> Jeremy Hinegardner                              jeremy at hinegardner.org 
> 
> _______________________________________________
> MacRuby-devel mailing list
> MacRuby-devel at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel