Re: [MacRuby-devel] Update (Laurent Sansonetti)
It would be interesting to know if MacRuby can be built on 10.8, at least. I don't have 10.8, but I heard there are problems with loading up BridgeSupport files. If one of you guys can try to build the code and report the result of your attempt, that would be helpful. If you fear the NDA thunder you can mail me directly, this way it won't be public :) Laurent On Thu, Apr 12, 2012 at 5:58 PM, Ben Mills wrote: > I don't think that information is prohibited by NDA. I will not be > discussing 10.8 or Xcode 4.4 features. If you'd still like this information, > I can provide it to you. > > > > On Thu, Apr 12, 2012 at 9:38 AM, Watson wrote: >> >> I don't have the OSX 10.8, so I can't confirm your problem. >> >> I want to know below, >> >> 1. Xcode install path. /Developer or /Applications >> 2. "xcode-select -print-path" command outputs. Empty, >> "/Developer/" or "/Applications/" >> 3. Your problem occurs only new project. it has been created by Xcode4.4. >> 4. Your problem occurs MacRuby's examples also. >> >> but, NDA >> >> 2012/4/13 James Chen : >> > >> > I also have this issue and a few others. But I'm afraid 10.8 and Xcode >> > 4.4 >> > is still under NDA so we cannot discuss it. >> > >> > >> > On 2012/04/12, at 23:58, Ben Mills wrote: >> > >> > What about 10.8 + Xcode 4.4? I just tried creating a new MacRuby project >> > (worked fine) but Xcode can't find the MacRuby framework. >> > >> > main.m:11:9: fatal error: 'MacRuby/MacRuby.h' file not found >> > >> > #import >> > >> > >> > >> > >> > If there's any way I can help with that, please let me know. >> > >> > >> > >> > >> > On Thu, Apr 12, 2012 at 7:04 AM, Watson wrote: >> >> >> >> Hi, >> >> >> >> We only added the install location to correspond to Xcode 4.3 for >> >> template and rb_nibtool. >> >> I think we did not change template itself. >> >> >> >> I had confirmed below combination when we corresponded to Xcode 4.3, >> >> and MacRuby worked to expected. >> >> >> >> OS X 10.6.8 + Xcode 3.2.6 >> >> OS X 10.6.8 + Xcode 4.2. >> >> OS X 10.7.3 + Xcode 4.2.1 >> >> OS X 10.7.3 + Xcode 4.3.2 >> >> >> >> >> >> If MacRuby is not work for you, let us know :) >> >> >> >> >> >> Thanks >> >> >> >> 2012/4/12 Laurent Sansonetti : >> >> > On Thu, Apr 12, 2012 at 8:32 AM, Tim Rand wrote: >> >> >> "First, we will release master as 0.12 (and just forget about 0.11). >> >> >> It >> >> >> is important since master has changes for the latest Xcode that have >> >> >> never been snipped yet." >> >> >> >> >> >> Does that mean the macruby project template will be updated to work >> >> >> with >> >> >> xcode 4.3.2--i.e. install into the updated directory location >> >> >> >> >> >> >> >> >> (/Applications/Xcode.app/Contents/Developer/Library/Xcode/Templates/Project\ >> >> >> Templates/Mac/Application/) and have a .xctemplate structure? >> >> >> Because >> >> >> I was >> >> >> just trying (but failing) to get figure out how to access the >> >> >> templates >> >> >> from >> >> >> the xcode 4.3.2. Moving the old templates (from >> >> >> /Library/Application\ >> >> >> Support/Developer/Shared/Xcode/Project\ Templates/Application/) >> >> >> didn't >> >> >> work. >> >> >> Looks like lots of stuff changed regarding xcode templates with this >> >> >> update. >> >> > >> >> > I am not sure about Xcode 4.3.2, but I tested master with 4.3.1 and >> >> > the templates seem to work as expected (also the IB support is >> >> > working >> >> > too). I believe the .xctemplate work was done a few releases ago, and >> >> > that the new changes in 0.12 are mostly about dealing with the fact >> >> > that Xcode is now installed in /Application/Xcode.app. >> >> > >> >> > Can you try one of the latest nightly bu
Re: [MacRuby-devel] Update (Laurent Sansonetti)
On Thu, Apr 12, 2012 at 8:32 AM, Tim Rand wrote: > "First, we will release master as 0.12 (and just forget about 0.11). It > is important since master has changes for the latest Xcode that have > never been snipped yet." > > Does that mean the macruby project template will be updated to work with > xcode 4.3.2--i.e. install into the updated directory location > (/Applications/Xcode.app/Contents/Developer/Library/Xcode/Templates/Project\ > Templates/Mac/Application/) and have a .xctemplate structure? Because I was > just trying (but failing) to get figure out how to access the templates from > the xcode 4.3.2. Moving the old templates (from /Library/Application\ > Support/Developer/Shared/Xcode/Project\ Templates/Application/) didn't work. > Looks like lots of stuff changed regarding xcode templates with this update. I am not sure about Xcode 4.3.2, but I tested master with 4.3.1 and the templates seem to work as expected (also the IB support is working too). I believe the .xctemplate work was done a few releases ago, and that the new changes in 0.12 are mostly about dealing with the fact that Xcode is now installed in /Application/Xcode.app. Can you try one of the latest nightly builds and let us know if it's still not working for you? Laurent ___ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
[MacRuby-devel] Update
Hi guys, So we had a team chat, and we agreed on the following. First, we will release master as 0.12 (and just forget about 0.11). It is important since master has changes for the latest Xcode that have never been snipped yet. I will work on this. In the meantime, if you can, please do install one of the latest nightly builds and let us know of any regression. It is likely that 0.12 will be one of the last releases before 1.0. Second, we will prepare a new landing page for the project, which will be hosted on GitHub. The page will be very minimal, as we intend to use the wiki for the real content. Josh volunteered to work on this, he does not need more help. Watson has been working on the necessary Wiki pages, but we might need more. If you're interested, the Wiki is open to anyone, you can create new pages or edit existing ones: https://github.com/macruby/macruby/wiki Third, we will migrate the tickets from trac to GitHub. Jake Smith and Dan Sinclair volunteered to work on this. We will coordinate so that the process will be as smooth as possible. No more help is required here. Fourth, we will move the nightly build system to a new infrastructure. I will provide a Mac Mini that will do the builds and push them on Amazon S3 (costs will be covered by my company). This will not happen right now, but somewhere in the future. We will probably do the first 3 items at once :) Laurent ___ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] Future of MacRuby
On Fri, Apr 6, 2012 at 9:09 PM, Jordan K. Hubbard wrote: > > On Apr 6, 2012, at 4:20 AM, Laurent Sansonetti > wrote: > > Yes, I'm still alive :) As you may have noticed, I have been absent > here for a few months. > > > [ Looks at Calendar] I think it was closer to 6 months, actually, but hey - > who's counting! :-) > [...] Jordan, I think you made it clear, several times, that Apple is not interested in developing MacRuby anymore [1]. There is no need to add another layer of unnecessary information here. We got it. If you guys want to contribute development time, then it's a different discussion. You have a lot of nice ideas, but talk is cheap. Laurent [1] You also know that's the reason I left, so lamenting on my temporary absence is somehow hypocritical, so say the least. I think that you know that free software works best when developers are employed. :) ___ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] The Future of MacRuby
Yes, ARC as is can't be used in MacRuby, but the principles can be ported. Which is what I did, more or less, in an experimental branch. Now, there are various challenges to solve in order to reach stability, but don't worry, we will get there. Laurent 2012/4/7 Francis Chong : > Automatic Reference Counting implements automatic memory management for > Objective-C objects and blocks. If you read MacRuby source code, you will > found that the VM is not even written in Objective-C! > > Henry Maddocks 於 2012年4月7日 下午7:13 寫道： > >> >> On 7/04/2012, at 6:13 PM, Joshua Ballanco wrote: >> >>> Regarding ARC, MacRuby cannot use ARC. That is, MacRuby cannot use the >>> Obj-C implementation of ARC. >> >> Why is that? >> >> Henry >> >> ___ >> 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 ___ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
[MacRuby-devel] Future of MacRuby
Hi guys, Yes, I'm still alive :) As you may have noticed, I have been absent here for a few months. Last year we got a baby, then we moved back to Europe. I decided to leave Apple a few months ago to achieve one of my dreams: work on a startup, in part so that I would be flexible in my time and be able to keep hacking on MacRuby. Believe it or not, in the near future I should have less pressure on myself and therefore I should have the time to hack on MacRuby again. I will happily resume maintaining MacRuby, like I did for the last 5 years. MacRuby is quite stable right now so the maintenance burden is less significant than before. Also, during my absence, Watson did a great job of smashing all sorts of incoming bugs, if he keeps up he will likely become the #1 committer of the project :). Mark Rada spent a lot of time triaging bugs and writing patches. And Josh Ballanco kept the IRC channel in activity. It's like the project never slept. BTW, the 0.11 release actually does exist, you can find it on the GitHub page. The release notes are still missing, but I will take care of this (we need to automate the whole process). One thing that people are worried about is that the Objective-C GC is being deprecated in Mountain Lion. That's not a surprise given that the emphasis is on ARC now. As Apple generally (but not always) removes deprecated APIs in the next release cycle, MacRuby needs to be changed this year to not depend on the GC anymore. I have been experimenting with different alternate memory models for MacRuby on my spare time, and one of them seems to work well, modulo a few leaks. It's similar to ARC in design (but it has a different implementation). I have been working on a MacRuby app with friends using the new code, so far so good. I will merge my branch with GitHub as soon as it's stable, with a few other improvements. That should happen before Mountain Lion ships, so no worries, we should be fine. What can you do to help? Well, keep using MacRuby :) Report bugs. Write cool samples and submit them on GitHub. Write tutorials covering a feature of OSX that was challenging to program in MacRuby. For the more technically-inclined, you can check the tickets, try creating patches, etc. Laurent ___ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] MacRuby and ARC was: Advice for Total Tyro
Hi Perry, On Tue, Oct 18, 2011 at 12:07 AM, Perry E. Metzger wrote: > On Mon, 17 Oct 2011 13:44:56 -0700 Matt Aimonetti > wrote: >> See my earlier reply, basically, you are right, it is technically >> possible to change the way MacRuby works to use an automatic >> reference counting approach. >> But it's far from being trivial. > > Wouldn't reference counting radically change the behavior of Ruby in > the presence of cycles though? It would no longer be exactly the same > language -- libraries that used cyclic data structures internally > would need to be rewritten. > Some people managed to have ref counting GCs that are able to deal with cycles. http://en.wikipedia.org/wiki/Reference_counting#Dealing_with_reference_cycles I also believe that CPython works similarly. Laurent ___ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
[MacRuby-devel] brace yourselves, 0.11 is coming!
Hi guys, No it isn't a joke, 0.11 is really coming out! I uploaded an installer, please give it a try with your project and let us know if it works, or not. https://github.com/downloads/MacRuby/MacRuby/MacRuby%200.11.zip In the meantime I'm preparing the release notes. If everything goes well, maybe 0.11 can see the light this week! GitHub's master branch is now using the 0.12 version number (which, hopefully, will turn into 1.0). Laurent ___ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] [ANN] Launch: MemoryCloud - Where memories live
A bit late to the party... but congratulations, it looks great, and thanks for using MacRuby :-) Laurent On Thu, Sep 1, 2011 at 6:16 PM, Steven Buxton wrote: > > http://memorycloudapp.com - We built this 100% in MacRuby 0.10 and it was a > blast to build. Started building it in 0.6 and worked on it all the way to > Lion and 0.10. Never had 1 issue in app approval with it being macruby! > About MemoryCloud -- > MemoryCloud stores your favorite photos and videos for you, allowing you to > reclaim precious hard drive space. > > Not backup, not synchronization. MemoryCloud is simple and safe storage for > the files that typically take up a lot of room. > > Here’s how it works: photos and videos occupy a lot of space on your Mac. > With MemoryCloud, you just drag and drop these files to store them on > the cloud; drag and drop again to retrieve. Smaller versions of the > originals are kept on your hard drive so you can still view a favorite photo > any time you want. > > Want to know what is being stored for you? MemoryCloud places a small > watermark on your compressed files, so you instantly know what has > been archived to the cloud. > > MemoryCloud provides a simple alternative to multiple CDs, memory cards and > external storage devices, allowing you to carry smaller versions of your > media with you. Finally, you don’t have to choose between cherished memories > and hard drive space. > > MemoryCloud offers: > > * Safe storage utilizing Amazon’s state-of-the-art cloud technology. > * A simple way to organize and access your favorite photos and videos. > * Full compatibility with both iPhoto and iTunes. > * The only cloud storage solution that also allows you to reclaim precious > hard drive space. > > Thanks! > Steven > > > > > > ___ > 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
Re: [MacRuby-devel] Invoking an obj-c method requiring a block
Hi Andy,
Blocks should work. Perhaps there is a problem with this very specific
API. Could you file a ticket? We will investigate.
Thanks
Laurent
On Sat, Aug 20, 2011 at 11:52 PM, Andy Park wrote:
> I tried using blocks today, to no avail.
>
> This didn't work:
> NSNotificationCenter.defaultCenter.addObserverForName
> "kDocSetSelection
> Changed", object:nil, queue:nil, usingBlock:Proc.new{ |notification|
> NSLog("notified")
> }
>
> But this did:
> NSNotificationCenter.defaultCenter.addObserver(self, selector:
> "handleM
> e:", name: "kDocSetSelectionChanged", object: nil)
>
> I found http://www.macruby.org/trac/ticket/760 that hinted MacRuby does
> impleme
> nt blocks, but also had references to BridgeSupport. I installed the preview-3
> version; what would be the reason the above didn't work?
>
> Thanks.
>
> ___
> 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
Re: [MacRuby-devel] -twolevel_namespace issue?
Hi Jeremy, Could the problem be fixed by linking statically your own copy of SQLite against the Amalgalite library, and perhaps passing all SQLite symbols to -unexported_symbols_list during ld time? I am guessing symbols wouldn't collide anymore this way. >From what I understand, it looks like it would be better to fix the problem in Amalgalite itself, and not in each client requiring it. Laurent On Mon, Sep 12, 2011 at 8:39 PM, Jeremy Hinegardner 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 > ___ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] Serialport IO and OS X Lion
Hi Robert I guess it can be either a problem in MacRuby or a problem in Lion. Can you share more details on this? Some system frameworks shipped with GC regressions in Lion, maybe that's the problem here. Laurent On Sat, Aug 20, 2011 at 9:42 PM, Robert Rice wrote: > Hi devotees, > > I was using an Obj-C wrapper for serial port IO written by Paolo Bosetti but > I found that it no longer works in Lion. Does anyone know what might have > changed? Does MacRuby have a better solution for serial IO yet than using an > Obj-C wrapper? > > Thanks, > Bob Rice > > ___ > 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
Re: [MacRuby-devel] linking an NSTextView with my AppDelegate
Hi Brice, AFAIK, IB support in Xcode4 was broken for a long time but has been fixed in the beta builds. Unless you can't use the beta, http://www.macruby.org/trac/ticket/1322 contains a workaround. Laurent On Mon, Sep 12, 2011 at 9:37 PM, Brice Ruth wrote: > Good afternoon - > > I saw a thread from August indicating that there was an issue with Xcode 4 > on Lion w/r/t linking in IB (matched exactly what I'm seeing). I went and > grabbed the latest Xcode 3.x and installed it on Lion - I now have the old > IB, but I still can't seem to see the attrs defined in my AppDelegate when I > try to link the TextView. Not sure what I'm doing wrong ... would anyone > mind stepping me through in a little more detail or pointing me to a more > detailed walk through? I was using Xcode 4 on Snow Leopard and everything > seemed to be working peachy ... I'm now on Lion, working on a new NSTextView > and I can't get it to link to anything anymore. > > I saw one response indicating that you need to tell IB to read the files - I > see a "Read class files ..." option in the menu - when I point that at my > AppDelegate, I get an error dialog in IB, when I point it at main_rb, I > don't get an error, but it still doesn't appear to work. > > I can't make heads or tails of the XML in the .xib, either - so no hope > there. > > Much obliged, > > Brice Ruth, FCD > Software Engineer, Madison WI > > ___ > 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
Re: [MacRuby-devel] macruby produces strings with encodings that differ from MRI
Hi Steve,
It would be nice to know what exactly in ruby-mysql causes the
problem. If you can reduce the problem to a simple code snippet or
point us to the ruby-mysql source code it would be great.
Thanks
Laurent
On Sun, Sep 18, 2011 at 8:38 AM, Steve Clarke wrote:
> Yes, looks like the same issue as ticket 742. I did look at tickets but
> failed to spot that.
>
> The comment on the ticket re only UTF-8 being required may be true - it
> certainly is for me. Sadly the ruby-mysql gem works in such a way that the
> difference between MRI and macruby breaks it.
>
> Steve
>
> On 18 Sep 2011, at 06:07, Watson wrote:
>
>> Hi,
>>
>> Maybe related to http://www.macruby.org/trac/ticket/742.
>> MacRuby ignore magic-comment, and uses default encoding UTF8.
>>
>> Thanks.
>>
>> 2011/9/18 Steve Clarke :
>>> Code
>>>
>>>
>>> ABC='ABC'
>>> puts "ABC[0] encoding is #{ABC[0].encoding}"
>>> puts "?\\xff encoding is #{?\xff.encoding}"
>>>
>>>
>>> Output
>>>
>>>
>>>
>>> MRI output
>>>
>>> ABC[0] encoding is US-ASCII
>>> ?\xff encoding is ASCII-8BIT
>>>
>>>
>>>
>>> macruby output
>>>
>>> ABC[0] encoding is UTF-8
>>> ?\xff encoding is UTF-8
>>>
>>>
>>> The encodings reported above did not seem to be effected by the encoding of
>>> the source file. I tried both ASCII and UTF-8.
>>>
>>> When the same code is executed in (mac)irb the results are the same for
>>> macirb as they are for macruby.
>>> irb for MRI however produces UTF-8 strings in both cases! This seemed very
>>> odd but I'm fairly sure it's because I have an environment variable:
>>> LANG=GB.UTF-8
>>> When I changed to LANG=GB.US_ASCII irb for MRI rendered 'abc'[0] with
>>> US_ASCII encoding. macirb still used UTF-8.
>>>
>>> (I discovered this when trying to get ruby-mysql to work with macruby. It
>>> doesn't work as-is but seems to work with a few mods that use
>>> force_encoding to make MRI and macruby produce the same outputs).
>>> I abandoned my earlier attempts to use postgres with macruby via the pg
>>> gem. It failed regularly but in unpredictable ways associated, as far as I
>>> could tell, with memory management problems.
>>>
>>>
>>> ___
>>> 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
>
> ___
> 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
Re: [MacRuby-devel] 0.11 schedule
It seems that the problem has already been reported: http://www.macruby.org/trac/ticket/1335. It has also been tagged as a blocker :) Laurent On Mon, Jun 20, 2011 at 5:51 PM, Morgan Schweers wrote: > Greetings, > I haven't filed a ticket yet; ran into it yesterday, and let myself get > distracted by my kids, once I got to a stable state again. :) > I'll reproduce it this evening and file a ticket with the output and what I > can figure out. > -- Morgan > > On Mon, Jun 20, 2011 at 3:54 PM, Laurent Sansonetti > wrote: >> >> Thanks Morgan. >> >> Have you filed a ticket about this? If it's something that used to >> work in past releases and doesn't anymore, then it's likely going to >> be a blocker, as we want to avoid regressions. >> >> Laurent >> >> On Mon, Jun 20, 2011 at 3:43 PM, Morgan Schweers >> wrote: >> > Greetings, >> > I just yesterday ran into a problem with the head of MacRuby on GitHub >> > that >> > makes it not possible to use Mechanize/Nokogiri, specifically the >> > redefinition of Node? >> > I see this if I just go >> > $ macirb >> > irb> require 'rubygems' >> > irb> require 'mechanize' >> > It looks like a bundle gets loaded that tries to redefine Node, >> > but...that >> > doesn't work for some reason? I'm not totally clear on what's going >> > wrong, >> > just that it was a show-stopper for me for moving to HEAD. I'm not at >> > home, >> > where I was having this problem in spades until I downgraded to 0.10, >> > but if >> > you install the mechanize gem on a 0.11 version it pretty consistently >> > fails >> > to load. >> > Since nokogiri and mechanize are pretty important to what I'm building, >> > it's >> > a bad place to be... :/ >> > -- Morgan >> > On Mon, Jun 20, 2011 at 3:18 PM, Laurent Sansonetti >> > wrote: >> >> >> >> Agreed! I attached the 0.11-blocker keyword. >> >> >> >> Thanks, >> >> Laurent >> >> >> >> On Mon, Jun 20, 2011 at 1:57 PM, Martin Schürrer >> >> wrote: >> >> > HI, >> >> > >> >> > shouldn't stuff like http://www.macruby.org/trac/ticket/505 be a >> >> > blocker? >> >> > >> >> > (I'm new to macruby, so I'm curious) >> >> > >> >> > Cheers, >> >> > Martin >> >> > >> >> > On Mon, Jun 20, 2011 at 22:20, Laurent Sansonetti >> >> > wrote: >> >> >> Hi guys, >> >> >> >> >> >> A lot of good work has been integrated into master recently, so it's >> >> >> now time to think about making a new release (hopefully it will be >> >> >> the >> >> >> last 0.x release!). >> >> >> >> >> >> Here is a list of bugs I think are blockers to this release: >> >> >> >> >> >> http://www.macruby.org/trac/ticket/1286 >> >> >> http://www.macruby.org/trac/ticket/1294 >> >> >> http://www.macruby.org/trac/ticket/1308 >> >> >> http://www.macruby.org/trac/ticket/1313 >> >> >> http://www.macruby.org/trac/ticket/1329 >> >> >> >> >> >> As always it is highly possible that I missed other blockers, so if >> >> >> you know about one please commit it, so that we can promote it with >> >> >> the 0.11-blocker keyword accordingly. >> >> >> >> >> >> Thanks! >> >> >> Laurent >> >> >> ___ >> >> >> 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 >> >> > >> >> ___ >> >> 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 >> > >> > >> ___ >> 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 > > ___ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] 0.11 schedule
Thanks Morgan. Have you filed a ticket about this? If it's something that used to work in past releases and doesn't anymore, then it's likely going to be a blocker, as we want to avoid regressions. Laurent On Mon, Jun 20, 2011 at 3:43 PM, Morgan Schweers wrote: > Greetings, > I just yesterday ran into a problem with the head of MacRuby on GitHub that > makes it not possible to use Mechanize/Nokogiri, specifically the > redefinition of Node? > I see this if I just go > $ macirb > irb> require 'rubygems' > irb> require 'mechanize' > It looks like a bundle gets loaded that tries to redefine Node, but...that > doesn't work for some reason? I'm not totally clear on what's going wrong, > just that it was a show-stopper for me for moving to HEAD. I'm not at home, > where I was having this problem in spades until I downgraded to 0.10, but if > you install the mechanize gem on a 0.11 version it pretty consistently fails > to load. > Since nokogiri and mechanize are pretty important to what I'm building, it's > a bad place to be... :/ > -- Morgan > On Mon, Jun 20, 2011 at 3:18 PM, Laurent Sansonetti > wrote: >> >> Agreed! I attached the 0.11-blocker keyword. >> >> Thanks, >> Laurent >> >> On Mon, Jun 20, 2011 at 1:57 PM, Martin Schürrer >> wrote: >> > HI, >> > >> > shouldn't stuff like http://www.macruby.org/trac/ticket/505 be a >> > blocker? >> > >> > (I'm new to macruby, so I'm curious) >> > >> > Cheers, >> > Martin >> > >> > On Mon, Jun 20, 2011 at 22:20, Laurent Sansonetti >> > wrote: >> >> Hi guys, >> >> >> >> A lot of good work has been integrated into master recently, so it's >> >> now time to think about making a new release (hopefully it will be the >> >> last 0.x release!). >> >> >> >> Here is a list of bugs I think are blockers to this release: >> >> >> >> http://www.macruby.org/trac/ticket/1286 >> >> http://www.macruby.org/trac/ticket/1294 >> >> http://www.macruby.org/trac/ticket/1308 >> >> http://www.macruby.org/trac/ticket/1313 >> >> http://www.macruby.org/trac/ticket/1329 >> >> >> >> As always it is highly possible that I missed other blockers, so if >> >> you know about one please commit it, so that we can promote it with >> >> the 0.11-blocker keyword accordingly. >> >> >> >> Thanks! >> >> Laurent >> >> ___ >> >> 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 >> > >> ___ >> 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 > > ___ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] 0.11 schedule
Agreed! I attached the 0.11-blocker keyword. Thanks, Laurent On Mon, Jun 20, 2011 at 1:57 PM, Martin Schürrer wrote: > HI, > > shouldn't stuff like http://www.macruby.org/trac/ticket/505 be a blocker? > > (I'm new to macruby, so I'm curious) > > Cheers, > Martin > > On Mon, Jun 20, 2011 at 22:20, Laurent Sansonetti > wrote: >> Hi guys, >> >> A lot of good work has been integrated into master recently, so it's >> now time to think about making a new release (hopefully it will be the >> last 0.x release!). >> >> Here is a list of bugs I think are blockers to this release: >> >> http://www.macruby.org/trac/ticket/1286 >> http://www.macruby.org/trac/ticket/1294 >> http://www.macruby.org/trac/ticket/1308 >> http://www.macruby.org/trac/ticket/1313 >> http://www.macruby.org/trac/ticket/1329 >> >> As always it is highly possible that I missed other blockers, so if >> you know about one please commit it, so that we can promote it with >> the 0.11-blocker keyword accordingly. >> >> Thanks! >> Laurent >> ___ >> 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 > ___ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
[MacRuby-devel] 0.11 schedule
Hi guys, A lot of good work has been integrated into master recently, so it's now time to think about making a new release (hopefully it will be the last 0.x release!). Here is a list of bugs I think are blockers to this release: http://www.macruby.org/trac/ticket/1286 http://www.macruby.org/trac/ticket/1294 http://www.macruby.org/trac/ticket/1308 http://www.macruby.org/trac/ticket/1313 http://www.macruby.org/trac/ticket/1329 As always it is highly possible that I missed other blockers, so if you know about one please commit it, so that we can promote it with the 0.11-blocker keyword accordingly. Thanks! Laurent ___ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] Does everyone do this with their MacRuby apps?
I think we need an "official" tutorial on the website on how to prepare an app for submission to the app store. Is someone here interested in contributing to it? Laurent On Jun 17, 2011, at 12:34 AM, Andre Lewis wrote: > I wrote the post at > http://redwoodapp.posterous.com/macruby-and-xcode-4-build-a-self-contained-ma, > but I haven't submitted to the app store yet. The post was very much in the > "just get it working" spirit. If anyone has better steps, would love to see > them! > > Andre > > > ___ > 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
Re: [MacRuby-devel] Re： Nokogiri leaks
The free function pointer is not honored by MacRuby, yet. But it can
be done :) Can you file a ticket?
Thanks,
Laurent
On Sat, May 28, 2011 at 8:07 AM, Watson wrote:
> Hi,
> I think that MacRuby needs to call a deallocating function which specified
> with Data_Wrap_Struct() macro.
>
>
> Thank you.
>
> 日付：2011年5月28日土曜日、時刻：23:13、差出人：Guido Soranzio：
>
> While experimenting with array controllers and NSTableViews, I was facing
> huge
> memory leaks. I thought the culprits were the Cocoa bindings but I have
> discovered
> that the Nokogiri gem is what is causing them.
>
> The following little test doesn't leak under Ruby 1.9.2 compiled with
> MacPorts,
> so it seems there is a problem with the underlying linking with libxml2
> instead.
>
> --
> require 'rubygems'
> require 'nokogiri'
>
> loop do
> doc = Nokogiri::HTML('TEST ')
> p = doc.css("p")[0].text
> print p
> end
> --
>
>
>
> --
> Guido
>
>
>
>
> ___
> 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
>
>
___
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] Dynamic refresh in a view - xcode 4 / MacRuby
Just one minor detail, the NSTimer callback method accepts an argument (which is a reference to the NSTimer object). So it should be: def drawWord(sender) … end If it works otherwise, then it's pure luck :) Laurent On May 24, 2011, at 10:50 PM, Thomas R. Koll wrote: > Laurent is right and and I think best would be for you to use a NSTimer. > > def drawWord > if !next_word >self.timer.invalidate >return > end > self.label.stringValue = next_word > self.setNeedsDisplay true > end > > def next_word > ... > end > > self.timer = NSTimer.scheduledTimerWithTimeInterval( 1/20.0, > target:self, selector:"drawWord:", userInfo:nil, repeats:true) > > > > Am 25.05.2011 um 02:06 schrieb az...@gmx.net: > >> I have a label that I have set to blank, and after a user clicks 'go' I >> generate a random word or number and use: >> >> self.label.stringValue = "some_word" >> >> to update the view. >> >> However, I would like to show 200 or so random words in quick succession >> before the final one is shown - just because it's too plain at the moment. >> Alternatively, I'd be happy with showing an animated graphic in its place - >> which is replaced by the final random word after a few seconds. >> >> I've tried things like: >> >> 100.times do >> num = rand(40) >> self.label.stringValue = num >> sleep 1 >> end >> >> But it doesn't work. I've also (after googling) tried .reloadData but to no >> avail as well. >> >> Any ideas on how to achieve this? Or pointers on how to add animations to my >> window/views? > > > -- > Thomas R. "TomK32" Koll, Ruby/Rails freelancer > http://ananasblau.com | http://github.com/TomK32 > > > > > ___ > 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
Re: [MacRuby-devel] Break in Block Fails only in Macruby
Indeed.
$ ./miniruby -e "require 'find'; p Find.find('.') { break 42 }"
nil
$ ruby1.9 -e "require 'find'; p Find.find('.') { break 42 }"
42
Can you file a ticket?
Thanks,
Laurent
On May 25, 2011, at 1:23 PM, Shannon Love wrote:
> Greetings,
>
> If I run the following under the system ruby 1.8.7:
>
> require 'find'
> starting_directory="/Users/developer/Desktop/Top"
> file_name_I_want_to_find="target_file.txt"
> path=Find.find(starting_directory) {|p| break p if
> p.include?(file_name_I_want_to_find) }
> puts "path = #{path}"
>
> ... I get the expected output:
>
> path = /Users/developer/Desktop/Top/Lev_1-2/Lev_2.1/target_file.txt
>
> However, if I run it under Macruby I get nothing, just:
>
> path =
>
> I'm running MacRuby 0.10 (ruby 1.9.2) [universal-darwin10.0, x86_64] on 10.6.7
>
> Not sure what is going on.
>
> Thanks,
> Shannon
>
>
> ___
> 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
Re: [MacRuby-devel] Dynamic refresh in a view - xcode 4 / MacRuby
Hi, It doesn't work because you're (probably) blocking the main thread, which is responsible for drawing. What you want to do instead is scheduling a timer inside the main run loop. Look at the NSTimer class. Also, don't forget to force the view to be redrawn, by using the setNeedsDisplay: method. HTH Laurent On Tue, May 24, 2011 at 5:06 PM, az...@gmx.net wrote: > I have a label that I have set to blank, and after a user clicks 'go' I > generate a random word or number and use: > > self.label.stringValue = "some_word" > > to update the view. > > However, I would like to show 200 or so random words in quick succession > before the final one is shown - just because it's too plain at the moment. > Alternatively, I'd be happy with showing an animated graphic in its place - > which is replaced by the final random word after a few seconds. > > I've tried things like: > > 100.times do > num = rand(40) > self.label.stringValue = num > sleep 1 > end > > But it doesn't work. I've also (after googling) tried .reloadData but to no > avail as well. > > Any ideas on how to achieve this? Or pointers on how to add animations to my > window/views? > ___ > 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
Re: [MacRuby-devel] Constant definitions
Hi Bob, https://github.com/MacRuby/MacRuby/commit/68ac3fcaf1041ef9b25fb3bc940a47f41505b7e5 happened. This fixes bugs but also introduces others. We have tickets covering the new bugs and Kouji-san is working on them. https://www.macruby.org/trac/ticket/1292 https://www.macruby.org/trac/ticket/1288 https://www.macruby.org/trac/ticket/1285 Laurent On May 24, 2011, at 8:46 AM, Robert Rice wrote: > Hi Fans: > > What changed on 5/19/2011? > > I haven't been able to use the nightly builds since 5/18/2011. Constant > definitions stopped working and I get an uninitialized constant xxx > (NameError) message wherever my code tries to reference a constant defined in > the same class. > > Thanks, > Bob Rice > > ___ > 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
Re: [MacRuby-devel] MacRuby WWDC Meetup
Hi Christian, I just tweeted a link to the page from the @MacRuby account, so I think it's going to be full very soon now :) Thanks for setting this up! Laurent On May 23, 2011, at 10:18 AM, Christian Niles wrote: > Hey All, > > The MacRuby WWDC Meetup is now 60% full! Make sure to RSVP if you really want > to make it. And if you have a ticket and change your mind, please free up > your spot for someone else. > > Also, the meetup will not be recorded, so you'll have to be there to > participate :) > > christian. > > On May 20, 2011, at 9:08 PM, Christian Niles wrote: > >> On May 20, 2011, at 1:55 PM, Laurent Sansonetti wrote: >> >>> I can't speak for Erik, but I'm not allowed to do any presentation. I can >>> attend the meeting, discuss the project and answer questions though (like a >>> BoF, which I thought was the plan here). >> >> I was expecting a pretty informal set of presentations too, hence why I >> asked whether we really needed the videographer. I didn't know about you >> couldn't present though. >> >> I'll let them know they can tape Erik if they want, but that's the only >> planned presentation. >> >> thanks! >> christian. >> ___ >> 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 ___ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] MacRuby WWDC Meetup
On May 20, 2011, at 1:03 PM, Christian Niles wrote: > On May 20, 2011, at 12:21 PM, Laurent Sansonetti wrote: > >> Hi Christian, >> >> Awesome! Thanks for setting this up! >> >> I think we should wait one more day before advertising the link on twitter, >> to make sure subscribers of the mailing-list can RSVP before. I will post a >> link to the event tomorrow via @MacRuby. > > That sounds reasonable. > > BTW, Pivotal has a videographer reserved for the event, and asked if we would > like the presentations recorded and placed on their tech talks page: > > http://pivotallabs.com/talks > > Will you and/or Erik's presentations be formal-ish enough to make this > worthwhile, or should we pass on recording them? I can't speak for Erik, but I'm not allowed to do any presentation. I can attend the meeting, discuss the project and answer questions though (like a BoF, which I thought was the plan here). Laurent ___ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] MacRuby WWDC Meetup
Hi Christian, Awesome! Thanks for setting this up! I think we should wait one more day before advertising the link on twitter, to make sure subscribers of the mailing-list can RSVP before. I will post a link to the event tomorrow via @MacRuby. Laurent On May 20, 2011, at 10:08 AM, Christian Niles wrote: > Hey Everyone! > > WWDC is getting close and I wanted to make sure the MacRuby community has a > chance to get together while everyone's in town. If you're going to be in > town and want to join us, please RSVP here: > > http://macrubymeetup.eventbrite.com/ > > Right now I have Erik Michaels-Ober and Laurent Sansonetti on board to give > some brief presentations. If anyone else feels like presenting a topic or a > project, let me know. > > Also, please help out and publicize this event. Attendance is limited to 50 > people, and it'd be nice to have a full house. > > christian. > ___ > 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
Re: [MacRuby-devel] macruby_deploy and nokogiri - LoadError on some mac
http://www.macruby.org/trac/ticket/1286 Laurent On May 18, 2011, at 1:57 PM, Laurent Sansonetti wrote: > Good catch! > > It looks like we could improve macruby_deploy to warn (or die?) if of the > embedded binaries link against something in /opt (or better, in anything but > the default link paths). That would make sure this problem would not happen > again. > > Laurent > > On May 18, 2011, at 9:06 AM, Eloy Duran wrote: > >> Hi, >> >> It seems that the nokogiri gem that you are bundling has been compiled >> against a iconv installation in /opt/local (macports|homebrew). Some users >> probably have it as well which is why they wouldn't complain, but people >> with a default osx installation don't. Here's what it does on my system, >> which uses only default system libs: >> >> % otool -L >> /Library/Frameworks/MacRuby.framework/Versions/0.11/usr/lib/ruby/Gems/1.9.2/gems/nokogiri-1.4.4/ext/nokogiri/nokogiri.bundle >> /Library/Frameworks/MacRuby.framework/Versions/0.11/usr/lib/ruby/Gems/1.9.2/gems/nokogiri-1.4.4/ext/nokogiri/nokogiri.bundle: >> >> /Library/Frameworks/MacRuby.framework/Versions/0.11/usr/lib/libmacruby.dylib >> (compatibility version 0.11.0, current version 0.11.0) >> /usr/lib/libexslt.0.dylib (compatibility version 9.0.0, current version >> 9.13.0) >> /usr/lib/libxslt.1.dylib (compatibility version 3.0.0, current version >> 3.24.0) >> /usr/lib/libxml2.2.dylib (compatibility version 10.0.0, current version >> 10.3.0) >> /usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version >> 7.0.0) >> /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current >> version 125.2.10) >> >> As you can see, it references /usr/lib/libiconv.2.dylib, not >> /opt/local/lib/libiconv.2.dylib. So it's probably best to only compile >> against system versions. >> >> To make sure this doesn't happen in the future, you should always test your >> app on clean installs of the system. It's pretty easy to keep a spare HD >> around with multiple version installs from which you boot and test the whole >> process. >> >> HTH >> >> On 18 mei 2011, at 17:24, Francis Chong wrote: >> >>> Hi >>> >>> I tried to use macruby_deploy to embed my macruby based mac app with gems >>> (/usr/local/bin/macruby_deploy --compile --embed --gem nokogiri) >>> >>> The resulting app run fine on my machine. However, on many of our testers, >>> the app failed with "LoadError". It seems nokogiri depends on a libiconv >>> with different version. (nokogiri.bundle requires version 8.0.0 or later, >>> but libiconv.2.dylib provides version 7.0.0) >>> >>> We cant ask our user to install each of those library. Are there any way I >>> can build the app embed the correct version of libiconv? >>> >>> Logs: >>> >>> dlopen(/Applications/ChineseIdiom.app/Contents/Frameworks/MacRuby.framework/Versions/0.10/usr/lib/ruby/site_ruby/1.9.2/nokogiri/nokogiri.bundle, >>> 9): Library not loaded: /opt/local/lib/libiconv.2.dylib >>> 18/05/2011 10:44:53 PM >>> [0x0-0x157b57a].hk.ignition.mac.ChineseIdiom[1576]Referenced from: >>> /Applications/ChineseIdiom.app/Contents/Frameworks/MacRuby.framework/Versions/0.10/usr/lib/ruby/site_ruby/1.9.2/nokogiri/nokogiri.bundle >>> 18/05/2011 10:44:53 PM >>> [0x0-0x157b57a].hk.ignition.mac.ChineseIdiom[1576]Reason: >>> Incompatible library version: nokogiri.bundle requires version 8.0.0 or >>> later, but libiconv.2.dylib provides version 7.0.0 - >>> /Applications/ChineseIdiom.app/Contents/Frameworks/MacRuby.framework/Versions/0.10/usr/lib/ruby/site_ruby/1.9.2/nokogiri/nokogiri.bundle >>> (LoadError) >>> 18/05/2011 10:44:53 PM >>> [0x0-0x157b57a].hk.ignition.mac.ChineseIdiom[1576] from >>> /Applications/ChineseIdiom.app/Contents/Resources/rb_main.rb:20:in `' >>> 18/05/2011 10:44:53 PM com.apple.launchd.peruser.501[191] >>> ([0x0-0x157b57a].hk.ignition.mac.ChineseIdiom[1576]) Exited with exit code: >>> 1 >>> >>> Thanks >>> >>> Francis Chong >>> Ignition Soft >>> http://ignition.hk >>> ___ >>> 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 > > ___ > 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
Re: [MacRuby-devel] macruby_deploy and nokogiri - LoadError on some mac
Good catch! It looks like we could improve macruby_deploy to warn (or die?) if of the embedded binaries link against something in /opt (or better, in anything but the default link paths). That would make sure this problem would not happen again. Laurent On May 18, 2011, at 9:06 AM, Eloy Duran wrote: > Hi, > > It seems that the nokogiri gem that you are bundling has been compiled > against a iconv installation in /opt/local (macports|homebrew). Some users > probably have it as well which is why they wouldn't complain, but people with > a default osx installation don't. Here's what it does on my system, which > uses only default system libs: > > % otool -L > /Library/Frameworks/MacRuby.framework/Versions/0.11/usr/lib/ruby/Gems/1.9.2/gems/nokogiri-1.4.4/ext/nokogiri/nokogiri.bundle > /Library/Frameworks/MacRuby.framework/Versions/0.11/usr/lib/ruby/Gems/1.9.2/gems/nokogiri-1.4.4/ext/nokogiri/nokogiri.bundle: > > /Library/Frameworks/MacRuby.framework/Versions/0.11/usr/lib/libmacruby.dylib > (compatibility version 0.11.0, current version 0.11.0) > /usr/lib/libexslt.0.dylib (compatibility version 9.0.0, current version > 9.13.0) > /usr/lib/libxslt.1.dylib (compatibility version 3.0.0, current version > 3.24.0) > /usr/lib/libxml2.2.dylib (compatibility version 10.0.0, current version > 10.3.0) > /usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version > 7.0.0) > /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current > version 125.2.10) > > As you can see, it references /usr/lib/libiconv.2.dylib, not > /opt/local/lib/libiconv.2.dylib. So it's probably best to only compile > against system versions. > > To make sure this doesn't happen in the future, you should always test your > app on clean installs of the system. It's pretty easy to keep a spare HD > around with multiple version installs from which you boot and test the whole > process. > > HTH > > On 18 mei 2011, at 17:24, Francis Chong wrote: > >> Hi >> >> I tried to use macruby_deploy to embed my macruby based mac app with gems >> (/usr/local/bin/macruby_deploy --compile --embed --gem nokogiri) >> >> The resulting app run fine on my machine. However, on many of our testers, >> the app failed with "LoadError". It seems nokogiri depends on a libiconv >> with different version. (nokogiri.bundle requires version 8.0.0 or later, >> but libiconv.2.dylib provides version 7.0.0) >> >> We cant ask our user to install each of those library. Are there any way I >> can build the app embed the correct version of libiconv? >> >> Logs: >> >> dlopen(/Applications/ChineseIdiom.app/Contents/Frameworks/MacRuby.framework/Versions/0.10/usr/lib/ruby/site_ruby/1.9.2/nokogiri/nokogiri.bundle, >> 9): Library not loaded: /opt/local/lib/libiconv.2.dylib >> 18/05/2011 10:44:53 PM >> [0x0-0x157b57a].hk.ignition.mac.ChineseIdiom[1576]Referenced from: >> /Applications/ChineseIdiom.app/Contents/Frameworks/MacRuby.framework/Versions/0.10/usr/lib/ruby/site_ruby/1.9.2/nokogiri/nokogiri.bundle >> 18/05/2011 10:44:53 PM >> [0x0-0x157b57a].hk.ignition.mac.ChineseIdiom[1576]Reason: >> Incompatible library version: nokogiri.bundle requires version 8.0.0 or >> later, but libiconv.2.dylib provides version 7.0.0 - >> /Applications/ChineseIdiom.app/Contents/Frameworks/MacRuby.framework/Versions/0.10/usr/lib/ruby/site_ruby/1.9.2/nokogiri/nokogiri.bundle >> (LoadError) >> 18/05/2011 10:44:53 PM >> [0x0-0x157b57a].hk.ignition.mac.ChineseIdiom[1576] from >> /Applications/ChineseIdiom.app/Contents/Resources/rb_main.rb:20:in `' >> 18/05/2011 10:44:53 PM com.apple.launchd.peruser.501[191] >> ([0x0-0x157b57a].hk.ignition.mac.ChineseIdiom[1576]) Exited with exit code: 1 >> >> Thanks >> >> Francis Chong >> Ignition Soft >> http://ignition.hk >> ___ >> 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 ___ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] Syntax Coloring in XCode 4
Hi Alec / Chris, You may want to tell the Xcode team: http://bugreporter.apple.com Laurent On Mon, May 16, 2011 at 8:13 PM, Chris Rhoden wrote: > Hey Alec, > This is something that's come up on the list previously; unfortunately, it's > out of our hands. Apple needs to support it with the way that things are > currently structured. > Sorry, mate. > > On Mon, May 16, 2011 at 9:54 PM, Alec Sloman wrote: >> >> Hello, >> Had a rough introduction to the community a few weeks back, so I'd like to >> start with an apology: sorry for being a jerk. Twitter isn't the place to >> complain. Again, my bad, humble apologies. >> I have been working with MacRuby since then and am *VERY* enthusiastic. >> But there's one small thing that is driving me crazy - the syntax coloring >> in XCode 4. Currently it only picks out strings and numbers. Have I done >> something incorrectly when installing MacRuby, or is this to be expected? Is >> there anything I can do to improve this? >> Keep up the fantastic work! >> Regards, >> Alec >> ___ >> MacRuby-devel mailing list >> MacRuby-devel@lists.macosforge.org >> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel >> > > > > -- > chrisrhoden > > ___ > 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
Re: [MacRuby-devel] String#sub/gsub and text encodings
Hi Caio, On May 16, 2011, at 2:21 PM, Caio Chassot wrote: > On 2011-05-16, at 00:37 , Laurent Sansonetti wrote: > >> Filling dups is always a good idea as it helps up prioritizing work. > > Oh Laurent, please let's not encourage this terrible dupes-as-voting-system > practice; just add a +1 button to tickets. > > Filling proper tickets is hard work. Time shouldn't be spent on filing known > dupes. (Filing accidental dupes still preferred than not filing anything at > all for laziness of searching to check it's not a dupe) Well I think it's quicker to file a dup than search through the entire database (using the awful Trac interface, but that's another topic), to then comment "hey, me too!". And let's also consider false positives (people thinking this ticket describes their bug, when it doesn't). I think it's a better idea to let the team triage the bugs, since they know about the big picture. Laurent ___ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] String#sub/gsub and text encodings
If the script works different in CRuby 1.9, then a ticket will be helpful too, as it is likely something we need to fix. I don't know by heart if it's a well-known issue, but we will figure it out later. Filling dups is always a good idea as it helps up prioritizing work. Thanks, Laurent On May 15, 2011, at 8:10 AM, Caio Chassot wrote: > Hi, > > Can you post some sample code? > > Thanks > > On Sun, May 15, 2011 at 11:50, Yasu Imao wrote: >> Hi, >> >> I just wrote a simple script for text processing and encountered a problem >> with String#sub/gsub. >> >> Original text: UTF-8 encoded ASCII character only text >> Replacing text: UTF-8 encoded text with ASCII and non-ASCII characters >> (including Japanese characters) >> >> The resulting text: all the non-ASCII characters were garbage. >> >> When I split the original text at the strings to be replaced and inserted >> the replacing text at these places, the resulting string object was fine; >> all the characters were kept as they should be in UTF-8 encoding. >> >> I checked the tickets, but couldn't find something like this. Is this a >> known issue? >> >> Best, >> Yasu >> ___ >> 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 ___ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] Invoking a block in MacRuby, instantiated in Objective-C
Hi Christian, I think I only implemented Ruby -> ObjC blocks support, not the other way around :) I didn't know Cocoa was exposing APIs returning ObjC blocks yet. Could you file a ticket? I will try to get that fixed in the upcoming release. Thanks, Laurent On May 15, 2011, at 1:42 PM, Christian Niles wrote: > Hey All, > > There's plenty of documentation showing how one can use Proc objects to > invoke Objective-C methods that accept block parameters, but I can't find any > way to invoke an Objective-C block from within a Ruby method. > > Without thinking I had assumed they'd be mapped to a Proc-like object, which > I could invoke with #call: > > def performOperation(operation, success:success_callback, > error:error_callback) > # ... > result = "..." > success_callback.call(result) > end > > But I get an error: undefined method `call' for #<__NSAutoBlock__:0x2006b6560> > > christian. > ___ > 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
Re: [MacRuby-devel] handlers and carets
Hi Pavlos,
You simply pass a Proc object.
handler = Proc.new do |result|
if result == …
...
end
oPanel.beginSheetModalForWindow self.window, completionHandler: handler
Make sure you installed the latest BridgeSupport preview before, available from
http://www.macruby.org/files.
Laurent
On May 6, 2011, at 5:38 PM, Pavlos Vinieratos wrote:
> hello. how can I write this in macruby?
> [oPanel beginSheetModalForWindow:[self window]
>
> completionHandler:^(NSInteger result) {
>
> if (result == NSFileHandlingPanelOKButton) {
>
> for (NSURL *fileURL in [oPanel URLs]) {
>
> // do something with fileURL
>
> }
>
> }
>
> }];
>
> the second arg is a handler..
>
> thank you
>
> --
> Pavlos Vinieratos
> ___
> 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
Re: [MacRuby-devel] Unable to Upload Application to the App store
Hi Daniel, What version of MacRuby are you using? You may want to try a nightly build as it contains up to date fixes in the deployment tool. Laurent On May 6, 2011, at 12:06 PM, Daniel Westendorf wrote: > Hi all, > > I'm running into some trouble uploading my application to the App store. I > have my main application target which validates fine when Archived. I have a > second target, which depends on the main target. This target uses > macruby_deploy with the arguments --compile --embed --gem sqlite3 --gem > sequel. When I go to validate this archive, I get the following: > > The binary is invalid. A symbolic link resolves to a file that doesn't exist. > Relative location: Thumper.app/Contents/Frameworks/MacRuby.framework/Headers > The binary is invalid. A symbolic link resolves to a file that doesn't exist. > Relative location: Thumper.app/Contents/Frameworks/MacRuby.framework/MacRuby > The binary is invalid. A symbolic link resolves to a file that doesn't exist. > Relative location: Thumper.app/Contents/Frameworks/MacRuby.framework/Resources > The binary is invalid. A symbolic link resolves to a file that doesn't exist. > Relative location: > Thumper.app/Contents/Frameworks/MacRuby.framework/Versions/0.10/Headers > > When I take the .app to a fresh install of 10.6 w/o Macruby installed, it > runs fine. I'm confused as to where to go from here. Does anyone have any > advice? > > Thanks! > > Daniel > ___ > 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
Re: [MacRuby-devel] hpricot and macruby?
Hi Daniel, I think the master branch is able to run hpricot, although I recommend using NSXMLDocument. Laurent On May 4, 2011, at 12:56 PM, macr...@djc.net wrote: > With: > MacRuby 0.10 (ruby 1.9.2) [universal-darwin10.0, x86_64] > and having done successfully: > macgem install hpricot ... > > I get this when trying to use the actual gem: > > dyld: lazy symbol binding failed: Symbol not found: _rb_enc_to_index > Referenced from: > /Library/Frameworks/MacRuby.framework/Versions/0.10/usr/lib/ruby/Gems/1.9.2/gems/hpricot-0.8.4/lib/fast_xs.bundle > Expected in: flat namespace > > is this a hpricot or macruby issue? > Any tips appreciated ... or do I give up, and attempt to convert this old > script to use: NSXMLDocument ? > (ruby 1.8.7 is core dumping, having its own problems, so I am hoping MacRuby > is up to the task...) > > -Daniel > > ___ > 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
Re: [MacRuby-devel] Failure with outlineView data source
Hi Malcolm, Have you tried removing the #to_s call in the outlineView:objectValueForTableColumn:byItem: method? An important thing to keep in mind when writing an outline view data source is to always return the same object reference for an item, not copies. The references must also be unique. Laurent On Sat, Apr 30, 2011 at 4:07 PM, Malcolm F wrote: > I'm getting crashes using an outlineView data source fed by an array of > numbers. The crash happens after fiddling around in the view, usually after > some variable small delay. Upon crash, the debugger is always stopped in > 'class_getSuperclass'. > > The crash only happens using Integers or Floats over 12. > > I've simplified it down to this sparse MyDocument class that can be put into > a document-based app. Put an outline view into MyDocument.xib and connect the > datasource delegate to MyDocument. > > I'm new at this, so if an experienced MacRubyist can show me what I'm doing > wrong, I will be very grateful. > thanks, m > > <> > class MyDocument < NSDocument > attr_accessor :dataSourceArray > > def init > super > if (self != nil) > # Add your subclass-specific initialization here. > # If an error occurs here, return nil. > end > self > end > > def awakeFromNib > #@dataSourceArray = [1,2,3,4,5,6,7,8,9,10,11,12] #survives > @dataSourceArray = [1,2,3,4,5,6,7,8,9,10,11,12,13] #crashes, anything over > 12 > > #@dataSourceArray = [0.to_i,8.to_i,116.to_i,224.to_i,400.to_i,1000.to_i] > #crashes > #@dataSourceArray = 13.0 #float also crashes > #@dataSourceArray = [10] #survives > #@dataSourceArray = [99] #crashes > #@dataSourceArray = 99 #crashes > #@dataSourceArray = 9 #survives > #@dataSourceArray = [NSNumber.numberWithInt(99)] #crashes > #@dataSourceArray = Array.new [117] #crashes > #@dataSourceArray = [1,2,3,4,[5,6],7,8,9,0] #survives > #@dataSourceArray = [0,8,116,224,400,1000] #crashes > #@dataSourceArray = [0.to_s,8.to_s,116.to_s,224.to_s,400.to_s,1000.to_s] > #survives > #@dataSourceArray = > [:zero,:eight,:onesixteen,:twotwentyfour,:fourhundred,:hundredyoh] #survives > end > > def windowNibName > "MyDocument" > end > > ## DataSource for OV ### > def outlineView(outlineView, numberOfChildrenOfItem:item) > if item.is_a? Array > return item.count > end > 1 > end > def outlineView(outlineView, isItemExpandable:item) > (item == nil) || ((item.is_a? Array) && (item.count > 0)) > end > def outlineView(outlineView, child:index, ofItem:item) > #returns child item objects > if item == nil > return @dataSourceArray #root item > end > if item.is_a? Array > return item[index] > end > return nil > end > def outlineView(outlineView, objectValueForTableColumn:tableColumn, > byItem:item) > # returns the object represented by the column at this item > item.to_s > end > > end > > <> > ___ > 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
Re: [MacRuby-devel] Sqlite3 without core data
Hi Petr, Have you tried using `macruby_deploy --embed --gem ...' instead of vendoring the gems by yourself? It should work out of the box, and you do not need to change LOAD_PATH. Laurent On Thu, Apr 28, 2011 at 1:16 AM, Petr Kaleta wrote: > Thanks for this hint, this lib looks great. Problem is, that I can't make it > work. I am loading all gems from vendor folder inside my app. So: > > $LOAD_PATH.unshift(File.join(File.dirname(__FILE__), > 'vendor/sqlite3-ruby/lib')) > $LOAD_PATH.unshift(File.join(File.dirname(__FILE__), 'vendor/sequel/lib')) > > require 'sqlite3' > require 'sequel' > > But the problem is, that when loading sqlite3 it raises this error: > > `loadExternalLibraries': no such file to load -- sqlite3/sqlite3_native > (LoadError) > > Which looks really strange... Hints? > > - Petr > > On Apr 18, 2011, at 8:00 PM, Joe West wrote: > >> On Mon, Apr 18, 2011 at 7:47 AM, Rolando Abarca >> wrote: >>> try sequel: http://sequel.rubyforge.org/ >>> >> >> +1 for Sequel >> ___ >> 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 > ___ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] macruby_deploy --embed bug
On Apr 17, 2011, at 2:18 PM, Nathaniel Talbott wrote: > On Sun, Apr 17, 2011 at 12:07 PM, Nathaniel Talbott > wrote: > >> Tonight I'll be able to submit a reproduction of the issue (have to >> run out now) but in the meantime, any ideas as to what the cause might >> be? > > After doing a bit of poking around and failing to find the root of the > problem, I decided to just fix up $LOAD_PATH by adding the following > at the top of rb_main.rb: […] Thanks for finding this also! It looks like the recent change to macruby_deploy in order to conform to new AppStore submissions broke the load path relocation. I corrected the problem in https://github.com/MacRuby/MacRuby/commit/f024e510389140e090aa3404ed18744fc6986ef6 MacRuby core has a very intensive test suite, but sadly we don't have any test for macruby_deploy yet. Maybe we should consider writing some at some point to avoid this kind of regressions. Laurent ___ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] BridgeSupport crash
On Apr 16, 2011, at 11:34 AM, Nathaniel Talbott wrote: > In the meantime, is there any simple workaround for 0.10? Would love > to get this app shipped in working form to my alpha testers > post-haste. Sadly no, but either your patch or embedding the master branch of MacRuby should work. At this point we only commit bug fixes to the master branch, it's very stable and always better than the last released version, so you may want to consider embedding it. Laurent ___ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] BridgeSupport crash
On Apr 16, 2011, at 2:30 PM, Nathaniel Talbott wrote: > On Sat, Apr 16, 2011 at 2:34 PM, Nathaniel Talbott > wrote: > >> Excellent! Can't wait to see your commit, since I've been playing with >> a fix and am curious if I'm even looking in the right place :-) > > Attached is my hacky patch; my sample app works if I build with it > (going to move on to getting my app out next!). Can't wait to see > Laurent's solution - mine feels sub-optimal. Your patch is a good workaround for you but cannot be included, as it's not going to work as expected if the user uses macruby_deploy --bs on a system where BridgeSupport preview has not been installed. I committed a fix that should work in all cases: we now parse the BridgeSupport file version number and propagate it to MacRuby core, which will accordingly load the hacks. https://github.com/MacRuby/MacRuby/commit/eedc8a3b28adc6933087e3b2694e2a1d902bd1ec Let me know if it works for you. I just wrote that patch and haven't got the time to fully test it yet. Once BridgeSupport preview ships with a version of Mac OS X, it will be time to finally get rid of the hacks :) Laurent ___ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] BridgeSupport crash
On Apr 16, 2011, at 6:52 AM, Nathaniel Talbott wrote: > On Sat, Apr 16, 2011 at 9:29 AM, Nathaniel Talbott > wrote: > >> I have not tried to get it to crash on my development box (though I'll >> probably attempt that next); perhaps the difference is running it on a >> box that truly has never had the new BridgeSupport installed? > > OK, running on this hunch, I got it to crash on my local dev box. > Reproduction is trivial: simply remove or rename > /System/Library/BridgeSupport/ruby-1.8/bridgesupportparser.bundle. > This file, which is added by the preview3 BridgeSupport installer, > seems to be at the root of the issue. Apparently it's required for > some reason if the BridgeSupport files are embedded within an app. Thanks a lot for finding this, I now know exactly what the problem is :) I will commit a fix shortly. Laurent ___ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] BridgeSupport crash
I can't seem to be able to reproduce the crash. I built a sample MacRuby project (DotView), ran macruby_deploy --bs --embed on it, verified that both MacRuby.framework and the BridgeSupport files were included, then I renamed all BridgeSupport directories on my system (to make sure MacRuby won't load them), ran the app through gdb, and verified that the BridgeSupport files were loaded from inside the app bundle (and also, that the app ran fine without crashing). Looking at your backtrace, it seems that MacRuby is crashing when loading the BridgeSupport of a framework that you embedded in your app. Do you have any framework (other than MacRuby) inside your app? If yes, did you generate a BridgeSupport file for it? Also, it would be interesting if you could reduce the problem to a sample .app that you can give me. Laurent On Apr 15, 2011, at 8:16 PM, Laurent Sansonetti wrote: > Hi Nathaniel, > > This is likely the same problem as http://www.macruby.org/trac/ticket/1217. > I'll have a look, hopefully I should be able to get a fix this week-end. > > Laurent > > On Apr 15, 2011, at 8:58 AM, Nathaniel Talbott wrote: > >> I have a MacRuby app that's working great on my local box, but when I >> put it on another box it crashes hard. Here's the relevant thread >> crash info: >> >> Exception Type: EXC_BAD_ACCESS (SIGSEGV) >> Exception Codes: KERN_INVALID_ADDRESS at 0x >> Crashed Thread: 0 Dispatch queue: com.apple.main-thread >> >> Thread 0 Crashed: Dispatch queue: com.apple.main-thread >> 0 libmacruby.1.9.2.dylib 0x00010010c4b1 >> rb_vm_resolve_const_value + 1537 >> 1 libmacruby.1.9.2.dylib 0x0001000f52f6 >> rb_objc_load_loaded_frameworks_bridgesupport + 374 >> 2 libmacruby.1.9.2.dylib 0x000100157f0a macruby_main + 362 >> 3 com.terralien.Elephant 0x0001142f 0x1 + 5167 >> 4 com.terralien.Elephant 0x000113f4 0x1 + 5108 >> >> The app runs fine on my own box, and the only difference I can figure >> between them is that I've installed BridgeSupport preview3, but the >> box it's crashing on hasn't. I'm doing a macruby_deploy --bs and have >> verified that the BridgeSupport files are being copied into the right >> spot in the .app file. >> >> Any ideas what might be wrong and/or how I can debug further? >> >> >> -- >> Nathaniel Talbott >> <:((>< >> ___ >> 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 ___ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] BridgeSupport crash
Hi Nathaniel, This is likely the same problem as http://www.macruby.org/trac/ticket/1217. I'll have a look, hopefully I should be able to get a fix this week-end. Laurent On Apr 15, 2011, at 8:58 AM, Nathaniel Talbott wrote: > I have a MacRuby app that's working great on my local box, but when I > put it on another box it crashes hard. Here's the relevant thread > crash info: > > Exception Type: EXC_BAD_ACCESS (SIGSEGV) > Exception Codes: KERN_INVALID_ADDRESS at 0x > Crashed Thread: 0 Dispatch queue: com.apple.main-thread > > Thread 0 Crashed: Dispatch queue: com.apple.main-thread > 0 libmacruby.1.9.2.dylib0x00010010c4b1 > rb_vm_resolve_const_value + 1537 > 1 libmacruby.1.9.2.dylib0x0001000f52f6 > rb_objc_load_loaded_frameworks_bridgesupport + 374 > 2 libmacruby.1.9.2.dylib0x000100157f0a macruby_main + 362 > 3 com.terralien.Elephant0x0001142f 0x1 + 5167 > 4 com.terralien.Elephant0x000113f4 0x1 + 5108 > > The app runs fine on my own box, and the only difference I can figure > between them is that I've installed BridgeSupport preview3, but the > box it's crashing on hasn't. I'm doing a macruby_deploy --bs and have > verified that the BridgeSupport files are being copied into the right > spot in the .app file. > > Any ideas what might be wrong and/or how I can debug further? > > > -- > Nathaniel Talbott > <:((>< > ___ > 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
Re: [MacRuby-devel] I want to talk about MacRuby support of Lion.
Hi Kouji, We can continue this conversation privately (off-list). I dropped you an e-mail. Laurent On Apr 7, 2011, at 7:49 PM, Takao Kouji wrote: > Hi, > > I have joined the "Mac Developer Program". > I am compiling and testing MacRuby on Mac OS X Lion Preview 2. > I am using CruiseControl.rb to compile and test MacRuby. > > I want to talk about MacRuby support of Lion > (especially icu-1060 directory and auto_zone_1060.h file) with somebody. > I think that I can talk if there is it between people joined "Mac Developer > Program". > > Thanks Kouji. > > --- > TAKAO Kouji > blog: http://d.hatena.ne.jp/kouji0625/ > twitter: takaokouji / projects: ruby, s7-seven > > ___ > 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
Re: [MacRuby-devel] WWDC ?
Hi Christian, According to https://www.macruby.org/trac/wiki/MacRubyWWDC09, about 20, but I remember there were many more people coming that night (maybe 2x more). And MacRuby is way more popular this year. I think that if the meetup is properly advertised, at least 50 people will come. Laurent On Apr 7, 2011, at 12:01 PM, Christian Niles wrote: > Hey Laurent, > > How many people came last year? I can start asking around and see if any > local companies have the space to host a meetup. > > christian. > > On Apr 6, 2011, at 6:34 PM, Laurent Sansonetti wrote: > >> (Sorry for the late reply!) >> >> I would be glad to attend any MacRuby meetup during WWDC, and reply to any >> question and discuss MacRuby's current state and future. >> >> Rich, if you still desire to organize something, please go ahead. Last year >> I tried to organize something but it was a failure, too many people came and >> I wasn't able to find a good place. Let's hope it will work out better this >> year :) >> >> Cheers, >> Laurent >> >> On Mar 30, 2011, at 7:31 PM, Rich Morin wrote: >> >>> Looking at http://www.sfruby.info/#upcoming, I don't >>> see anything scheduled during WWDC (June 6-10). If >>> the WWDC attendees in the crowd can settle on a date >>> (ideally, one that works for Jordan and Laurent :-), >>> I'll be happy to put in the schedule. >>> >>> I can probably also find a venue for the event; let >>> me know if this is an issue... >>> >>> -r >>> -- >>> http://www.cfcl.com/rdmRich Morin >>> http://www.cfcl.com/rdm/resume r...@cfcl.com >>> http://www.cfcl.com/rdm/weblog +1 650-873-7841 >>> >>> Software system design, development, and documentation >>> ___ >>> 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 > > ___ > 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
Re: [MacRuby-devel] WWDC ?
On Apr 6, 2011, at 10:10 PM, Rich Morin wrote: > At 6:34 PM -0700 4/6/11, Laurent Sansonetti wrote: >> (Sorry for the late reply!) >> >> I would be glad to attend any MacRuby meetup during WWDC, >> and reply to any question and discuss MacRuby's current >> state and future. >> >> Rich, if you still desire to organize something, please >> go ahead. Last year I tried to organize something but >> it was a failure, too many people came and I wasn't able >> to find a good place. Let's hope it will work out better >> this year :) > > Unfortunately, I can't find any schedule information for > the evenings of June 6-9. So, I'm not in a good position > to suggest a date. Would some folks that are attending > please let me know which evenings/times to avoid? Maybe we should make a quick poll (here + twitter)? I think the biggest challenge here would be to find the venue. Laurent ___ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] Tyro Needs Ruby vs. O-C Advice
Hi Bryan, I see that many people responded to that thread, but I would like to still add the following points: 1) MacRuby can't be used for iOS programming at this time. 2) In order to fully program in Objective-C, you must know C first. If you're a seasoned C programmer, picking Objective-C should just take a couple days (maximum). Otherwise, you will have to learn C before, which can be challenging, especially if you come from PHP. Ruby, the language MacRuby implements, is _much_ easier to learn. Using Cocoa from MacRuby does not require you to master Objective-C, you basically just need to learn about Objective-C classes and methods and how to use them in Ruby, then you can spend the rest of your time learning the Cocoa APIs. There is plenty of documentation available, including 2 books (currently being written) on this very specific topic :) HTH, Laurent On Mar 30, 2011, at 8:43 PM, Bryan Harrison wrote: > I've decided to use an upcoming sabbatical to teach myself OS X and iOS > programming. My background includes OS X systems administration and web > development, mostly using the Apache/MySQL/PHP model. I'm familiar with OOP > concepts and have trifled with any number of languages from C to AppleScript, > but am not fluent in any object oriented language. I've been exploring Xcode > 4 for a week and feel conversant with the IDE if not yet able to accomplish > anything with it. > > So… I understand that Cocoa is a given, but today's million dollar question > is Objective-C or MacRuby? I'm a blank slate with regard to both and so > could use some good advice. For example… > > What are the advantages of MacRuby over Objective-C? > > What are the advantage of O-C over Ruby? > > Is Xcode's support for O-C significantly better than it's handling of Ruby? > Do I care? > > At this point I'm primarily interested in OS X development, but iOS clearly > needs to run a close second. What's the current status of Ruby development > for iOS and is it likely to go anywhere in the nearish future? > > Any thoughts on the longer-term prospects of either language? > > Any thoughts from anybody will be much appreciated. > > Thanks, > Bryan > ___ > 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
Re: [MacRuby-devel] WWDC ?
(Sorry for the late reply!) I would be glad to attend any MacRuby meetup during WWDC, and reply to any question and discuss MacRuby's current state and future. Rich, if you still desire to organize something, please go ahead. Last year I tried to organize something but it was a failure, too many people came and I wasn't able to find a good place. Let's hope it will work out better this year :) Cheers, Laurent On Mar 30, 2011, at 7:31 PM, Rich Morin wrote: > Looking at http://www.sfruby.info/#upcoming, I don't > see anything scheduled during WWDC (June 6-10). If > the WWDC attendees in the crowd can settle on a date > (ideally, one that works for Jordan and Laurent :-), > I'll be happy to put in the schedule. > > I can probably also find a venue for the event; let > me know if this is an issue... > > -r > -- > http://www.cfcl.com/rdmRich Morin > http://www.cfcl.com/rdm/resume r...@cfcl.com > http://www.cfcl.com/rdm/weblog +1 650-873-7841 > > Software system design, development, and documentation > ___ > 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
Re: [MacRuby-devel] Moving to GitHub!
The move is now complete! I wrote a small message on the blog: http://www.macruby.org/blog/2011/03/26/github.html Now let's continue fixing 1.0 bugs :) Laurent On Mar 25, 2011, at 9:30 PM, Laurent Sansonetti wrote: > Hi guys, > > We finally decided to move MacRuby's source code repository from subversion > to Git, and GitHub seems to be the best place to do it. > > The move will happen somewhere this week-end, or Monday. The repository > address will be: https://github.com/MacRuby/MacRuby. Currently, this > repository is a mirror of the subversion one. > > Here is how we will proceed: > > 1) Add frequent contributors to the GitHub repository. [Done] > 2) Update the nightly build process to use the GitHub repository. [Done] > 3) Stop the GitHub repository mirroring. > 4) Empty the trunk branch of the subversion repository, and just keep a text > file saying that we moved to GitHub. > 5) Refresh the website. > > Once this is done, frequent contributors can commit to the central repository > on GitHub, and MacRuby's development can continue. We will keep the rest of > the infrastructure (such as Trac for managing the tickets), only the source > code repository moves. > > If you have any suggestion or concern let us know. Also, it's possible that I > forgot a step or two, as I'm writing this under the influence of a few > guinness :) Hopefully Eloy or Matt will correct me. > > Thanks! > Laurent > ___ > 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
[MacRuby-devel] Moving to GitHub!
Hi guys, We finally decided to move MacRuby's source code repository from subversion to Git, and GitHub seems to be the best place to do it. The move will happen somewhere this week-end, or Monday. The repository address will be: https://github.com/MacRuby/MacRuby. Currently, this repository is a mirror of the subversion one. Here is how we will proceed: 1) Add frequent contributors to the GitHub repository. [Done] 2) Update the nightly build process to use the GitHub repository. [Done] 3) Stop the GitHub repository mirroring. 4) Empty the trunk branch of the subversion repository, and just keep a text file saying that we moved to GitHub. 5) Refresh the website. Once this is done, frequent contributors can commit to the central repository on GitHub, and MacRuby's development can continue. We will keep the rest of the infrastructure (such as Trac for managing the tickets), only the source code repository moves. If you have any suggestion or concern let us know. Also, it's possible that I forgot a step or two, as I'm writing this under the influence of a few guinness :) Hopefully Eloy or Matt will correct me. Thanks! Laurent ___ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] Xcode 4 LLVM >= r127367
Hi Dave, Xcode4 does not expose the LLVM header files and libraries needed for MacRuby, so you will have to build and install LLVM by yourself (as outlined in the README.rdoc file). Xcode4, on the other side, installs clang, which can be used to compile MacRuby instead of gcc, but you will still need the LLVM libraries around. Laurent On Mar 23, 2011, at 6:37 PM, Dave Lee wrote: > Can the LLVM that comes with Xcode 4 be used to compile MacRuby 0.10? Is > there a way to determine which svn revision Xcode's LLVM was compiled from? > > thanks, > Dave > ___ > 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
[MacRuby-devel] [ANN] MacRuby 0.10
Hi, After just a couple weeks of development since the last release, MacRuby 0.10 is now available. Get it here while it's still hot! MacRuby is an implementation of Ruby 1.9 directly on top of Mac OS X core technologies such as the Objective-C runtime and garbage collector, the LLVM compiler infrastructure and the Foundation and ICU frameworks. It is the goal of MacRuby to enable the creation of full-fledged Mac OS X applications which do not sacrifice performance in order to enjoy the benefits of using Ruby. You can learn more about MacRuby, and download a binary installer, from the website: http://macruby.org Or about this release more specifically, on our blog: http://www.macruby.org/blog/2011/03/23/macruby010.html Enjoy, Laurent ___ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] 0.10 - update
Here are the release notes.
Highlights:
- Support for the new MacBook Pro hardware (SandyBridge processors).
- Fixes in macruby_deploy for App Store submissions.
- Xcode4 support.
- Minor stability fixes.
Changes:
- Fixed a bug where we would crash when protecting an internal call during an
exception raise.
- Fixed a bug in the BridgeSupport parser when loading IOKit, which contains
very large structures.
- Fixed a bug in IO#try_convert to properly raise a TypeError exception when
passed a wrong object.
- Fixed a regexp bug in the URI library to avoid a backtrace explosion.
- Fixed a bug in String#+ where non-string objects could be concatenated.
- Fixed a bug when break expressions inside hash iterations wouldn't be taken
into account.
- Fixed a bug in Array#fill(start, length) where passing a huge length would
cause a crash.
- Fixed various minor CRuby conformance bugs in Array.
- Implemented the Hash#{keep_if, select!} methods.
- Implemented the Set#{keep_if, select!} methods.
- Fixed a bug in the ostruct library where regexp global variables would be
overriden.
- Fixed a bug in macruby_deploy when passing --embed, to change the libmacruby
dyld identification name, to conform to App Store submission rules.
- Fixed a bug in macruby_deploy when using --gem on gems containing a space
character in their paths would break the deployment.
- Fixed a race condition crash in Thread#kill.
- Fixed a bug when compiling recursive method calls when methods actually
re-define themselves on the fly (this fixes the mustache library).
- Moved to LLVM 2.9.
- Fixed a bug where converting a NULL pointer as an opaque type value to Ruby
would not give nil (as in RubyCocoa).
- Fixed a bug in Hash#[]= to not duplicate a String key that is already frozen.
Tickets:
#1184 Bus Error occurs since r5265.
#1186 macirb segfaults when trying to tab complete an NSURL object
#1166 Segfaults occurs when was passed NULL pointer into rb_protect's 3rd
argument.
#794`pthread_mutex_unlock(&t->sleep_mutex)' failed: Invalid argument (22)
#734Mustache fails on call to render.
#1177 Hash.each doesn't exit on embedded return
#1171 `macruby_deploy --gem` problem with directories that have a space
#1179 OpenStruct overwrites regex globals - seriously breaks Rack/Sinatra
#1178 Mac App Store reviewers rejecting MacRuby app's due to library name
#1185 LLVM error running 1.9 distribution on Sandy Bridge
#1191 Assertion failed with define_method.
#1194 launch_msg(LAUNCH_KEY_CHECKIN) doesn't return nil when run outside of a
daemon/agent
Laurent
___
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
[MacRuby-devel] 0.10 - update
Hi guys, As the Xcode4 templates seem to be functional, I just branched trunk for the 0.10 release. I will do more testing and hopefully, 0.10 should be released either tonight or tomorrow! Development continues in trunk, which is now using the 0.11 version number. Laurent ___ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] Why the MacRuby does not implement cref?
Hi Kouji, I think that you're looking for the current_class variable of RoxorVM and the rb_vm_outer_t structure. That's how const lookup is implemented in MacRuby, basically. It is possible that the current implementation is not good enough in order to fix these issues and that a solution like CRuby should be implemented. But so far, every const lookup bug was able to be fixed. Laurent On Mar 22, 2011, at 1:37 AM, Takao Kouji wrote: > Hi, > > I'm trying to fix issues below. > > - #619: Constant scope in a block is determined at run-time? > - #828: A NameError, raised from evalling, gets the wrong constant name. > - #1095: Segfault on uninitialized constant in Rspec2 test > - #1167: NameError: uninitialized constant Hpricot::Container::Trav::Traverse > - #1192: Did not find nested constants. > > But, I could not find like cRuby's cref variable in compiler.cpp. > > I am wondering why the MacRuby does not implement cref? > Also, I am thinking about implementing cref myself. > I wonder if anyone would be opposed to this? > > Thanks Kouji. > > --- > TAKAO Kouji > blog: http://d.hatena.ne.jp/kouji0625/ > twitter: takaokouji / projects: ruby, s7-seven > > ___ > 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
Re: [MacRuby-devel] Proposal: splitting macrubyc UI from logic
Hi Mark, Sorry for the late reply. Could you file at ticket and add a link to the changes on github? I will look into this once we release 0.10. Thanks! Laurent On Mar 14, 2011, at 6:58 PM, Mark Rada wrote: > On 2011-03-14, at 16:05, Laurent Sansonetti wrote: > >> Hi Mark, >> >> As macrubyc's compilation logic is essentially spawning several command-line >> tools, I wonder if calling the logic directly from macruby_deploy is going >> to bring significant advantages, vs the complexity of splitting macrubyc. >> > > The splitting macrubyc was a low hanging fruit; macrubyc was almost split > already, so few changes were introduced. I don't think I introduced much > complexity, and in turn some clutter was separated from the initialization > process: > > - calls to #die were replaced with calls to #raise > - the option parser was moved out of the compiler class, now > Compiler#initialize takes a hash of options and just unpacks it > - most of the extra tool lookups (#locate) were moved to constants so they > only have to be looked up once > >> I think a better strategy would be to optimize what's slow in macrubyc (such >> as command-line options parsing), > > I don't think it's the command line parsing, I thinks it's the spawning of > new MacRuby processes which will have to JIT the compiler logic over and over > again for each file. > > But I guess a lot of that can be mitigated by compiling the compiler when it > becomes possible. > >> and better include the compilation strategy into Xcode (if possible). >> > > That does sound like a much better idea for macruby_deploy. > > However, I am rarely using Xcode to work with MacRuby, and there are other > places where calling the compiler directly will have benefit, such as a rake > task or during gem installation. Perhaps I am speaking for a minority in > these two cases > > Sent from my iDevice > >> Laurent >> >> On Mar 12, 2011, at 5:40 PM, Mark Rada wrote: >> >>> Hi, >>> >>> I have completed a proof of concept patch for MacRuby where I have split >>> the UI of macrubyc from the underlying logic so that tools like >>> macruby_deploy can make use of the compiler without having to spawn a new >>> macruby process for each file that needs to be compiled. This should also >>> be beneficial for compiling gems and the standard library. >>> >>> After having made this patch, I realized that there are still several >>> places in the compiler where a new process is spawned to perform part of >>> the compilation. I'm not really sure how much else can be lib-ified from >>> the other required components. Overall there are still a few places that I >>> know I can optimize without much work needed. >>> >>> Right now, compile time for ruby files with about 100-200 lines of code is >>> about 1(+/-0.1) seconds on my MBP. Spawning a new macruby process and >>> processing the macrubyc options takes about 0.25 seconds; so I think the >>> patch is still useful in the general case. >>> >>> The code for the changes is located in my MacRuby fork on github: >>> https://github.com/ferrous26/MacRuby/tree/libify-rubyc >>> >>> Mark Rada >>> mr...@marketcircle.com >>> >>> ___ >>> 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 > > ___ > 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
[MacRuby-devel] xcode4 templates - update
Hi guys, I know some of you are waiting for the Xcode4 templates. Some work has been committed to trunk. You should be able to create new MacRuby projects from Xcode4 (basic, document-based, core-data based or preference pane). Each template has a Deployment target builtin that will call macruby_deploy with --compile --embed (you can customize the arguments if needed). Also, a basic .rb File template is provided. According to Matt there is still a problem with the CoreData template, but besides that, I think it's good enough for 0.10. Please give trunk or tonight's nightly build a try and let us know what you think! Thanks, Laurent ___ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] MacRuby build issues with LLVM
Hi Geoffrey, Yes, you can use trunk or the latest nightly builds. We are still working on the Xcode4 templates to release 0.10, and it's taking some time (the new template system is very different, and quite complex to understand). But besides the templates, trunk is ready, so you can bundle it. Laurent On Mar 18, 2011, at 11:56 AM, Geoffrey Grosenbach wrote: > On Thu, Mar 10, 2011 at 1:34 PM, Laurent Sansonetti > wrote: >> Thanks for verifying the fixes. I will release trunk as 0.10 tomorrow >> evening. > > Is this still the plan? Many customers are on the new MacBook and I've > had them roll back to a previous version of my app so it launches. > > Or, should I build my own MacRuby from trunk (if it will be a while > before the official 0.10 release)? > > -- > Geoffrey Grosenbach > b...@topfunky.com > > PeepCode Screencasts > http://peepcode.com > ___ > 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
Re: [MacRuby-devel] TIL - Uncaught exceptions in threads cause SIGABRT in the main thread!
Hi Morgan, Well in theory, you should NOT get a segfault when doing that. When an exception isn't rescued inside a Thread, the correct behavior is that the thread will quit, and that the exception will be silently ignored. Then, once the Thread object is garbage collected, if the exception has not been retrieved from the Thread object (for instance, if #join has never been called on it), then a warning message is printed on stderr with the exception backtrace, for debugging purposes. It would be nice if you could reproduce the segfault in a small test case, because it looks bad (we should never segfault) :) Laurent On Mar 13, 2011, at 6:31 PM, Morgan Schweers wrote: > Greetings, > Today I Learned :) if a thread throws an exception that isn't rescued by the > top of the thread, it'll crash the app's main thread with 'Program received > signal: “SIGABRT”.' > > That's been plaguing me since I started doing MacRuby development; every time > I tried to start up multiple threads, the app became incredibly fragile and, > unlike the main thread, it wouldn't show ruby traces. > > Now I just wrap threads in begin/rescue blocks, and I'm all good. Good > programming practice anyway, but the failure mode is unobvious if you don't. > > Hopefully this helps someone else! > > -- Morgan > > ___ > 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
Re: [MacRuby-devel] "framework" method gotcha
Hi Christian, These tests should probably be removed, they are not used anymore (these were used before we switched to RubySpec). The correct thing to do is probably make a macruby spec (under the spec/macruby directory). How do you intend to change #framework exactly? Maybe you should work on a patch first, and we can iterate on it, then write the spec/test later. Thanks for helping :) Laurent On Mar 12, 2011, at 10:54 PM, Christian Niles wrote: > Cool. I've compiled MacRuby from source and discovered a test for the > 'framework' method in test-macruby/cases/framework_test.rb. > > What's the best way to run the tests in this directory? It doesn't seem to be > run by `rake spec` and I couldn't find another task that seemed to run these. > > On Mar 12, 2011, at 8:35 PM, Matt Aimonetti wrote: > >> Hi Christian, >> >> As long as performance isn't affected, I think that making #framework >> smarter shouldn't be a problem. >> >> - Matt >> >> Sent from my iPhone >> >> On Mar 12, 2011, at 17:19, Christian Niles wrote: >> >>> Hey All, >>> >>> I just spent a few hours banging my head against a gotcha with the >>> `framework` method -- if there happens to be a file or directory in the >>> current directory with the name of the framework, the method fails: >>> >>> $ touch Cocoa >>> $ macruby -e 'framework "Cocoa"' >>> -e:1:in `': framework at path `Cocoa' cannot be located (RuntimeError) >>> >>> $ rm Cocoa; mkdir Cocoa >>> $ macruby -e 'framework "Cocoa"' >>> -e:1:in `': framework at path `Cocoa' cannot be loaded: Error >>> Domain=NSCocoaErrorDomain Code=4 UserInfo=0x200241e20 "The bundle “Cocoa” >>> couldn’t be loaded because its executable couldn’t be located." >>> >>> I ran into this while trying to setup unit testing for a Cocoa framework >>> I'm writing. XCode 4 automatically creates a directory for each target you >>> create. Thus, when I tried to load my framework, it saw my project target >>> directory and thought it had found the framework. >>> >>> I think the `framework` method should be updated to avoid this gotcha. >>> Currently, it just tests for existence of a file or directory. I'm happy to >>> start working on a patch, but wanted to ask if there's any possible reason >>> the `framework` method is this naïve? >>> >>> christian. >>> ___ >>> 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 > > ___ > 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
Re: [MacRuby-devel] Proposal: splitting macrubyc UI from logic
Hi Mark, As macrubyc's compilation logic is essentially spawning several command-line tools, I wonder if calling the logic directly from macruby_deploy is going to bring significant advantages, vs the complexity of splitting macrubyc. I think a better strategy would be to optimize what's slow in macrubyc (such as command-line options parsing), and better include the compilation strategy into Xcode (if possible). Laurent On Mar 12, 2011, at 5:40 PM, Mark Rada wrote: > Hi, > > I have completed a proof of concept patch for MacRuby where I have split the > UI of macrubyc from the underlying logic so that tools like macruby_deploy > can make use of the compiler without having to spawn a new macruby process > for each file that needs to be compiled. This should also be beneficial for > compiling gems and the standard library. > > After having made this patch, I realized that there are still several places > in the compiler where a new process is spawned to perform part of the > compilation. I'm not really sure how much else can be lib-ified from the > other required components. Overall there are still a few places that I know I > can optimize without much work needed. > > Right now, compile time for ruby files with about 100-200 lines of code is > about 1(+/-0.1) seconds on my MBP. Spawning a new macruby process and > processing the macrubyc options takes about 0.25 seconds; so I think the > patch is still useful in the general case. > > The code for the changes is located in my MacRuby fork on github: > https://github.com/ferrous26/MacRuby/tree/libify-rubyc > > Mark Rada > mr...@marketcircle.com > > ___ > 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
Re: [MacRuby-devel] macruby_deploy not embedding all of MacRuby
Hi Kevin, It sounds like a data corruption problem, but it could also maybe due to running the application on an Intel 32-bit machine (because, as of 0.10, i386 support is not built in anymore by default). I would run md5 hashes on both the embedded dylib and the one in /Library/Frameworks to ensure that no data corruption happened. Laurent On Mar 11, 2011, at 3:33 PM, Kevin Colyar wrote: > I'm running the following command to prepare my app to share with testers. > > PATH="$PATH:/usr/local/bin" macruby_deploy --embed --compile > "$TARGET_BUILD_DIR/$PROJECT_NAME.app" > > On my machine, its says the app directory is ~25MB but testers get the > following error when they try to run it: > > dyld: Library not loaded: > @executable_path/../Frameworks/MacRuby.framework/Versions/0.10/usr/lib/libmacruby.dylib > Referenced from: /Applications/ViKing.app/Contents/MacOS/ViKing > Reason: no suitable image found. Did find: > > /Applications/ViKing.app/Contents/MacOS/../Frameworks/MacRuby.framework/Versions/0.10/usr/lib/libmacruby.dylib: > unknown file type, first eight bytes: 0x6C 0x69 0x62 0x6D 0x61 0x63 0x72 0x75 > > /Applications/ViKing.app/Contents/MacOS/../Frameworks/MacRuby.framework/Versions/0.10/usr/lib/libmacruby.dylib: > unknown file type, first eight bytes: 0x6C 0x69 0x62 0x6D 0x61 0x63 0x72 0x75 > Trace/BPT trap > > When I upload the app directory to a remote server it's ~55MB and works only > other's machines. > > I assume this is due to symbolic links. Has anyone else seen this or have a > fix for it? Perhaps I'm missing a flag that I need to pass to macruby_deploy. > > Thanks, > Kevin > > -- > Kevin Colyar > http://kevin.colyar.net > > ___ > 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
Re: [MacRuby-devel] Xcode 4 is out... any plan to integrate soon?
I just tested Xcode4 on a Snow Leopard machine, after having re-installed MacRuby, and it seems that outlets and actions are recognized again! Thanks for letting me know, I will prepare and integrate some templates into the upcoming 0.10 release. Laurent On Mar 11, 2011, at 12:53 PM, Shaun August wrote: > Sorry, I was looking in the wrong place. I can confirm the outlets ARE > working for me. To reiterate, I installed Xcode 4 and then the nightly build > from the installer package and not from the command line. > > > Thank you, > > > SHAUN AUGUST DIRECTOR OF DESIGN > > EOS LIGHTMEDIA CORPORATION > > 320 - 825 POWELL STREET, VANCOUVER, BC V6A 1H7 > > T 604 639 5488 / F 604 639 5489 / M 604 760-5475 / W eoslightmedia.com > > On 2011-03-11, at 12:50 PM, Shaun August wrote: > >> Hi All, >> >> I installed Xcode 4 and then the latest nightly build and the outlets are >> not working for me. >> >> >> Thanks >> >> Shaun >> >> >> >> >> >> On 2011-03-11, at 10:22 AM, Matt Aimonetti wrote: >> >>> Can you verify that the outlets are working? >>> Laurent said he would commit the templates shortly so they should be >>> available in a future nightly build. >>> >>> - Matt >>> >>> On Fri, Mar 11, 2011 at 8:59 AM, Manu wrote: >>> Interestingly, I made the mistake to remove Xcode 3.. so I have only Xcode >>> 4 but I see it working with an older project. >>> >>> So where can I find the template for MacRuby? And where should they be >>> installed? So far beside few path issues in the build it seems to mostly >>> work >>> >>> I created a new file SomeClass.rb and a class, and I see it working on the >>> Custom Class field of the interface >>> >>> Emmanuel >>> >>> On Mar 11, 2011, at 8:50 AM, Matt Aimonetti wrote: >>> Indeed and others couldn't get Xcode to work. - Matt On Fri, Mar 11, 2011 at 8:34 AM, Manu wrote: Ok . Seems like someone got it to work but did not explain how he did... On Mar 10, 2011, at 10:54 PM, Matt Aimonetti wrote: > Please refer to the other posts about the same topic sent today. > > - Matt > > On Thu, Mar 10, 2011 at 9:25 PM, Manu wrote: > Hi > > Now that Xcode 4 is out , and that MacRuby 0.9 is out, any plans to > integrate with Xcode 4? Just curious. I saw a post last month but was > wondering if there were any update > > Emmanuel > ___ > 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 >> ___ >> 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 ___ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
[MacRuby-devel] trunk depends on a new LLVM
For those compiling from the repository: MacRuby now requires LLVM 2.9. I tested revision 127367 to be okay, so I recommend this one. The README.rdoc file has been updated with newer instructions. Also, as trunk no longer builds for i386 by default, LLVM doesn't need to be built for it anymore, which results in a much faster build. For those using the nightly builds, we will make sure it gets updated. Laurent ___ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] Note of warning about Xcode 4
Hi Sven, On Mar 10, 2011, at 2:56 PM, Sven Schwyn wrote: > Hi Laurent > >> What Vincent is referring to is the Xcode 3 feature where IB would >> automatically reveal the outlets and actions written in Ruby. This is not >> working in Xcode 4, and may be the reason why you want to stick to Xcode 3. > > Well, it works for me. At least if by "reveal the outlets and actions" you > mean the following: > > Create application_controller.rb: > > class AppliationController > attr_accessor foobar > def do_this(sender) >puts @foobar > end > end > > Edit MainMenu.XIB: > > - Add an NSObject and set it to class ApplicationController > - Select the connection inspector for it > - The outlet "foobar" and the action "do_this" show up an can be linked to > elements Strange! It wasn't working before, maybe they fixed that. I don't use Xcode, so I didn't see. Can someone else verify this? If it all works, we can include some Xcode4 templates in tomorrow's release. Laurent ___ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] MacRuby build issues with LLVM
Yes, it was a problem in LLVM, which wasn't generating code for the proper architecture. I hope this was an exception and that we won't need to target new LLVM versions each time new architectures are introduced :) Thanks for verifying the fixes. I will release trunk as 0.10 tomorrow evening. Laurent On Mar 10, 2011, at 3:00 AM, Nick Ludlam wrote: > I can also confirm this now builds correctly. Thanks very much for the speedy > turnaround, Laurent. > > Out of interest, do you know why the Core i7 chip in this laptop behaves > differently to the Core 2 Duo in my previous laptop? Is it perhaps just that > LLVM is failing to detect the CPU correctly, and is creating code based on > incorrect assumptions? > > On 10 Mar 2011, at 02:27, Laurent Sansonetti wrote: > >> I got confirmation that trunk as of r5271 should work. Because of the >> severity of this problem, and the recent changes in macruby_deploy regarding >> App Store submissions, I think we should release 0.10 as soon as possible >> now. I will work on it. >> >> Laurent >> >> On Mar 9, 2011, at 4:09 PM, Laurent Sansonetti wrote: >> >>> Okay, I committed support for LLVM 2.9 as of r5269 and verified that no >>> regression is introduced (the spec suite runs fine). >>> >>> Please update your repository, do a rake clean, then build with the >>> CFLAGS="-D__SUPPORT_LLVM_29__" option. Example: $ rake >>> CFLAGS="-D__SUPPORT_LLVM_29__" jobs=8 >>> >>> If this fixes the problem, we might need to roll out a MacRuby release with >>> this new LLVM soon, as I suspect the problem will hit many people. >>> >>> Laurent >>> >>> On Mar 9, 2011, at 2:10 PM, Laurent Sansonetti wrote: >>> >>>> Okay, API breakage, but I can reproduce that on my machine :) I will hack >>>> on it later today and post a message here once it's supposed to compile, >>>> this way you can continue testing. >>>> >>>> Laurent >>>> >>>> On Mar 9, 2011, at 2:03 PM, Nick Ludlam wrote: >>>> >>>>> Ok, well it's not failing in the same way, but it's still failing: >>>>> >>>>> /usr/bin/gcc-4.2 -std=c99 -I. -I./include -pipe -fno-common -fexceptions >>>>> -fblocks -g -O3 -Wall -Wno-deprecated-declarations -Werror -arch x86_64 >>>>> -I./icu-1060 -c ucnv.c -o .objs/ucnv.o >>>>> /usr/bin/gcc-4.2 -std=c99 -I. -I./include -pipe -fno-common -fexceptions >>>>> -fblocks -g -O3 -Wall -Wno-deprecated-declarations -Werror -arch x86_64 >>>>> -I./icu-1060 -c encoding.c -o .objs/encoding.o >>>>> /usr/bin/g++-4.2 -I. -I./include -fblocks -g -Wall >>>>> -Wno-deprecated-declarations -Werror -arch x86_64 >>>>> -I/opt/llvm-macruby/include -D_DEBUG -D_GNU_SOURCE -D__STDC_LIMIT_MACROS >>>>> -D__STDC_CONSTANT_MACROS -O3 -fno-rtti -fno-common -Woverloaded-virtual >>>>> -I./icu-1060 -c main.cpp -o .objs/main.o >>>>> In file included from vm.h:593, >>>>> from main.cpp:17: >>>>> compiler.h:82: error: ISO C++ forbids declaration of ‘DIFactory’ with no >>>>> type >>>>> compiler.h:82: error: expected ‘;’ before ‘*’ token >>>>> rake aborted! >>>>> Command failed with status (1): [/usr/bin/g++-4.2 -I. -I./include >>>>> -fblocks ...] >>>>> >>>>> (See full trace by running task with --trace) >>>>> >>>>> >>>>> >>>>> >>>>> On 9 Mar 2011, at 21:34, Laurent Sansonetti wrote: >>>>> >>>>>> It looks like it might take a while until I get my hands on a new MBP, >>>>>> so could one try the following? >>>>>> >>>>>> 1) Grab a copy of >>>>>> https://llvm.org/svn/llvm-project/llvm/branches/release_29 using svn, >>>>>> then build it using the same instructions in README.rdoc. I am just >>>>>> hoping that this new version of LLVM supports the new hardware and that >>>>>> it doesn't introduce API breakage. >>>>>> 2) Re-build and install MacRuby trunk after doing a rake clean. >>>>>> >>>>>> Laurent >>>>>> >>>>>> On Mar 9, 2011, at 1:08 PM, Laurent Sansonetti wrote: >>>>>> >>>>>>> Sorry the late reply. It's probably because this
Re: [MacRuby-devel] Note of warning about Xcode 4
Hi Sven, On Mar 10, 2011, at 2:09 AM, Sven Schwyn wrote: > Hi > > Referring to Vincent's recent post: > >> - But the biggest problem is that currently there is no MacRuby support in >> the interface editor: the actions and properties added in the Ruby code >> won't appear in the interface editor. > > I've never had this kind of trouble not with the later betas nor the GM. What Vincent is referring to is the Xcode 3 feature where IB would automatically reveal the outlets and actions written in Ruby. This is not working in Xcode 4, and may be the reason why you want to stick to Xcode 3. Laurent ___ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] MacRuby build issues with LLVM
I got confirmation that trunk as of r5271 should work. Because of the severity of this problem, and the recent changes in macruby_deploy regarding App Store submissions, I think we should release 0.10 as soon as possible now. I will work on it. Laurent On Mar 9, 2011, at 4:09 PM, Laurent Sansonetti wrote: > Okay, I committed support for LLVM 2.9 as of r5269 and verified that no > regression is introduced (the spec suite runs fine). > > Please update your repository, do a rake clean, then build with the > CFLAGS="-D__SUPPORT_LLVM_29__" option. Example: $ rake > CFLAGS="-D__SUPPORT_LLVM_29__" jobs=8 > > If this fixes the problem, we might need to roll out a MacRuby release with > this new LLVM soon, as I suspect the problem will hit many people. > > Laurent > > On Mar 9, 2011, at 2:10 PM, Laurent Sansonetti wrote: > >> Okay, API breakage, but I can reproduce that on my machine :) I will hack on >> it later today and post a message here once it's supposed to compile, this >> way you can continue testing. >> >> Laurent >> >> On Mar 9, 2011, at 2:03 PM, Nick Ludlam wrote: >> >>> Ok, well it's not failing in the same way, but it's still failing: >>> >>> /usr/bin/gcc-4.2 -std=c99 -I. -I./include -pipe -fno-common -fexceptions >>> -fblocks -g -O3 -Wall -Wno-deprecated-declarations -Werror -arch x86_64 >>> -I./icu-1060 -c ucnv.c -o .objs/ucnv.o >>> /usr/bin/gcc-4.2 -std=c99 -I. -I./include -pipe -fno-common -fexceptions >>> -fblocks -g -O3 -Wall -Wno-deprecated-declarations -Werror -arch x86_64 >>> -I./icu-1060 -c encoding.c -o .objs/encoding.o >>> /usr/bin/g++-4.2 -I. -I./include -fblocks -g -Wall >>> -Wno-deprecated-declarations -Werror -arch x86_64 >>> -I/opt/llvm-macruby/include -D_DEBUG -D_GNU_SOURCE -D__STDC_LIMIT_MACROS >>> -D__STDC_CONSTANT_MACROS -O3 -fno-rtti -fno-common -Woverloaded-virtual >>> -I./icu-1060 -c main.cpp -o .objs/main.o >>> In file included from vm.h:593, >>> from main.cpp:17: >>> compiler.h:82: error: ISO C++ forbids declaration of ‘DIFactory’ with no >>> type >>> compiler.h:82: error: expected ‘;’ before ‘*’ token >>> rake aborted! >>> Command failed with status (1): [/usr/bin/g++-4.2 -I. -I./include -fblocks >>> ...] >>> >>> (See full trace by running task with --trace) >>> >>> >>> >>> >>> On 9 Mar 2011, at 21:34, Laurent Sansonetti wrote: >>> >>>> It looks like it might take a while until I get my hands on a new MBP, so >>>> could one try the following? >>>> >>>> 1) Grab a copy of >>>> https://llvm.org/svn/llvm-project/llvm/branches/release_29 using svn, then >>>> build it using the same instructions in README.rdoc. I am just hoping that >>>> this new version of LLVM supports the new hardware and that it doesn't >>>> introduce API breakage. >>>> 2) Re-build and install MacRuby trunk after doing a rake clean. >>>> >>>> Laurent >>>> >>>> On Mar 9, 2011, at 1:08 PM, Laurent Sansonetti wrote: >>>> >>>>> Sorry the late reply. It's probably because this version of LLVM that we >>>>> use cannot target the new CPU yet. I will investigate :) >>>>> >>>>> Laurent >>>>> >>>>> On Mar 9, 2011, at 12:10 PM, Nick Ludlam wrote: >>>>> >>>>>> Yes, this looks like it's exactly the problem I'm having, from the look >>>>>> of the log, so perhaps it's a Sandy Bridge / Core i5/7 issue. Curious! >>>>>> >>>>>> On 9 Mar 2011, at 19:56, Richard Sepulveda wrote: >>>>>> >>>>>>> I have a customer that is also having this same problem with my MacRuby >>>>>>> Mac App Store application running on his new MacBook Pro. I don't have >>>>>>> access to this type of Mac so I haven't been able to reproduce this >>>>>>> problem. >>>>>>> >>>>>>> He has tried MacRuby 0.8 and 0.9 versions of my app with the same >>>>>>> results. >>>>>>> >>>>>>> I can provide copies of my app to developers that would like to try to >>>>>>> reproduce the problem. >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>
Re: [MacRuby-devel] MacRuby build issues with LLVM
Okay, I committed support for LLVM 2.9 as of r5269 and verified that no regression is introduced (the spec suite runs fine). Please update your repository, do a rake clean, then build with the CFLAGS="-D__SUPPORT_LLVM_29__" option. Example: $ rake CFLAGS="-D__SUPPORT_LLVM_29__" jobs=8 If this fixes the problem, we might need to roll out a MacRuby release with this new LLVM soon, as I suspect the problem will hit many people. Laurent On Mar 9, 2011, at 2:10 PM, Laurent Sansonetti wrote: > Okay, API breakage, but I can reproduce that on my machine :) I will hack on > it later today and post a message here once it's supposed to compile, this > way you can continue testing. > > Laurent > > On Mar 9, 2011, at 2:03 PM, Nick Ludlam wrote: > >> Ok, well it's not failing in the same way, but it's still failing: >> >> /usr/bin/gcc-4.2 -std=c99 -I. -I./include -pipe -fno-common -fexceptions >> -fblocks -g -O3 -Wall -Wno-deprecated-declarations -Werror -arch x86_64 >> -I./icu-1060 -c ucnv.c -o .objs/ucnv.o >> /usr/bin/gcc-4.2 -std=c99 -I. -I./include -pipe -fno-common -fexceptions >> -fblocks -g -O3 -Wall -Wno-deprecated-declarations -Werror -arch x86_64 >> -I./icu-1060 -c encoding.c -o .objs/encoding.o >> /usr/bin/g++-4.2 -I. -I./include -fblocks -g -Wall >> -Wno-deprecated-declarations -Werror -arch x86_64 >> -I/opt/llvm-macruby/include -D_DEBUG -D_GNU_SOURCE -D__STDC_LIMIT_MACROS >> -D__STDC_CONSTANT_MACROS -O3 -fno-rtti -fno-common -Woverloaded-virtual >> -I./icu-1060 -c main.cpp -o .objs/main.o >> In file included from vm.h:593, >>from main.cpp:17: >> compiler.h:82: error: ISO C++ forbids declaration of ‘DIFactory’ with no type >> compiler.h:82: error: expected ‘;’ before ‘*’ token >> rake aborted! >> Command failed with status (1): [/usr/bin/g++-4.2 -I. -I./include -fblocks >> ...] >> >> (See full trace by running task with --trace) >> >> >> >> >> On 9 Mar 2011, at 21:34, Laurent Sansonetti wrote: >> >>> It looks like it might take a while until I get my hands on a new MBP, so >>> could one try the following? >>> >>> 1) Grab a copy of >>> https://llvm.org/svn/llvm-project/llvm/branches/release_29 using svn, then >>> build it using the same instructions in README.rdoc. I am just hoping that >>> this new version of LLVM supports the new hardware and that it doesn't >>> introduce API breakage. >>> 2) Re-build and install MacRuby trunk after doing a rake clean. >>> >>> Laurent >>> >>> On Mar 9, 2011, at 1:08 PM, Laurent Sansonetti wrote: >>> >>>> Sorry the late reply. It's probably because this version of LLVM that we >>>> use cannot target the new CPU yet. I will investigate :) >>>> >>>> Laurent >>>> >>>> On Mar 9, 2011, at 12:10 PM, Nick Ludlam wrote: >>>> >>>>> Yes, this looks like it's exactly the problem I'm having, from the look >>>>> of the log, so perhaps it's a Sandy Bridge / Core i5/7 issue. Curious! >>>>> >>>>> On 9 Mar 2011, at 19:56, Richard Sepulveda wrote: >>>>> >>>>>> I have a customer that is also having this same problem with my MacRuby >>>>>> Mac App Store application running on his new MacBook Pro. I don't have >>>>>> access to this type of Mac so I haven't been able to reproduce this >>>>>> problem. >>>>>> >>>>>> He has tried MacRuby 0.8 and 0.9 versions of my app with the same >>>>>> results. >>>>>> >>>>>> I can provide copies of my app to developers that would like to try to >>>>>> reproduce the problem. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Richard >>>>>> >>>>>> Here is a portion of the log that he sent me. >>>>>> >>>>>> 3/9/11 11:35:31 AM >>>>>> [0x0-0xe20e2].com.rsepulveda.quickalarmtrial[2927] LLVM ERROR: >>>>>> Cannot yet select: 0x101899010: f64 = bit_convert 0x10191ae10 [ORD=315] >>>>>> [ID=7] >>>>>> 3/9/11 11:35:31 AM >>>>>> [0x0-0xe20e2].com.rsepulveda.quickalarmtrial[2927]0x10191ae10: >>>>>> i64 = and 0x10191b510, 0x10189a110 [ORD=314] [ID=6] >>>>>> 3/9/11 11:35:31 AM >>>>>>
Re: [MacRuby-devel] MacRuby build issues with LLVM
Okay, API breakage, but I can reproduce that on my machine :) I will hack on it later today and post a message here once it's supposed to compile, this way you can continue testing. Laurent On Mar 9, 2011, at 2:03 PM, Nick Ludlam wrote: > Ok, well it's not failing in the same way, but it's still failing: > > /usr/bin/gcc-4.2 -std=c99 -I. -I./include -pipe -fno-common -fexceptions > -fblocks -g -O3 -Wall -Wno-deprecated-declarations -Werror -arch x86_64 > -I./icu-1060 -c ucnv.c -o .objs/ucnv.o > /usr/bin/gcc-4.2 -std=c99 -I. -I./include -pipe -fno-common -fexceptions > -fblocks -g -O3 -Wall -Wno-deprecated-declarations -Werror -arch x86_64 > -I./icu-1060 -c encoding.c -o .objs/encoding.o > /usr/bin/g++-4.2 -I. -I./include -fblocks -g -Wall > -Wno-deprecated-declarations -Werror -arch x86_64 -I/opt/llvm-macruby/include > -D_DEBUG -D_GNU_SOURCE -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -O3 > -fno-rtti -fno-common -Woverloaded-virtual -I./icu-1060 -c main.cpp -o > .objs/main.o > In file included from vm.h:593, > from main.cpp:17: > compiler.h:82: error: ISO C++ forbids declaration of ‘DIFactory’ with no type > compiler.h:82: error: expected ‘;’ before ‘*’ token > rake aborted! > Command failed with status (1): [/usr/bin/g++-4.2 -I. -I./include -fblocks > ...] > > (See full trace by running task with --trace) > > > > > On 9 Mar 2011, at 21:34, Laurent Sansonetti wrote: > >> It looks like it might take a while until I get my hands on a new MBP, so >> could one try the following? >> >> 1) Grab a copy of https://llvm.org/svn/llvm-project/llvm/branches/release_29 >> using svn, then build it using the same instructions in README.rdoc. I am >> just hoping that this new version of LLVM supports the new hardware and that >> it doesn't introduce API breakage. >> 2) Re-build and install MacRuby trunk after doing a rake clean. >> >> Laurent >> >> On Mar 9, 2011, at 1:08 PM, Laurent Sansonetti wrote: >> >>> Sorry the late reply. It's probably because this version of LLVM that we >>> use cannot target the new CPU yet. I will investigate :) >>> >>> Laurent >>> >>> On Mar 9, 2011, at 12:10 PM, Nick Ludlam wrote: >>> >>>> Yes, this looks like it's exactly the problem I'm having, from the look of >>>> the log, so perhaps it's a Sandy Bridge / Core i5/7 issue. Curious! >>>> >>>> On 9 Mar 2011, at 19:56, Richard Sepulveda wrote: >>>> >>>>> I have a customer that is also having this same problem with my MacRuby >>>>> Mac App Store application running on his new MacBook Pro. I don't have >>>>> access to this type of Mac so I haven't been able to reproduce this >>>>> problem. >>>>> >>>>> He has tried MacRuby 0.8 and 0.9 versions of my app with the same results. >>>>> >>>>> I can provide copies of my app to developers that would like to try to >>>>> reproduce the problem. >>>>> >>>>> Thanks, >>>>> >>>>> Richard >>>>> >>>>> Here is a portion of the log that he sent me. >>>>> >>>>> 3/9/11 11:35:31 AM >>>>> [0x0-0xe20e2].com.rsepulveda.quickalarmtrial[2927] LLVM ERROR: >>>>> Cannot yet select: 0x101899010: f64 = bit_convert 0x10191ae10 [ORD=315] >>>>> [ID=7] >>>>> 3/9/11 11:35:31 AM >>>>> [0x0-0xe20e2].com.rsepulveda.quickalarmtrial[2927]0x10191ae10: >>>>> i64 = and 0x10191b510, 0x10189a110 [ORD=314] [ID=6] >>>>> 3/9/11 11:35:31 AM >>>>> [0x0-0xe20e2].com.rsepulveda.quickalarmtrial[2927] 0x10191b510: >>>>> i64,ch = CopyFromReg 0x103911388, 0x10191c510 [ORD=314] [ID=5] >>>>> 3/9/11 11:35:31 AM >>>>> [0x0-0xe20e2].com.rsepulveda.quickalarmtrial[2927] >>>>> 0x103911388: ch = EntryToken [ORD=314] [ID=0] >>>>> 3/9/11 11:35:31 AM >>>>> [0x0-0xe20e2].com.rsepulveda.quickalarmtrial[2927] >>>>> 0x10191c510: i64 = Register %reg16384 [ORD=314] [ID=1] >>>>> 3/9/11 11:35:31 AM >>>>> [0x0-0xe20e2].com.rsepulveda.quickalarmtrial[2927] 0x10189a110: >>>>> i64 = Constant<-4> [ORD=314] [ID=2] >>>>> 3/9/11 11:35:31 AMcom.apple.launchd.peruser.501[112] >>>>> ([0x0-0
Re: [MacRuby-devel] MacRuby build issues with LLVM
It looks like it might take a while until I get my hands on a new MBP, so could one try the following? 1) Grab a copy of https://llvm.org/svn/llvm-project/llvm/branches/release_29 using svn, then build it using the same instructions in README.rdoc. I am just hoping that this new version of LLVM supports the new hardware and that it doesn't introduce API breakage. 2) Re-build and install MacRuby trunk after doing a rake clean. Laurent On Mar 9, 2011, at 1:08 PM, Laurent Sansonetti wrote: > Sorry the late reply. It's probably because this version of LLVM that we use > cannot target the new CPU yet. I will investigate :) > > Laurent > > On Mar 9, 2011, at 12:10 PM, Nick Ludlam wrote: > >> Yes, this looks like it's exactly the problem I'm having, from the look of >> the log, so perhaps it's a Sandy Bridge / Core i5/7 issue. Curious! >> >> On 9 Mar 2011, at 19:56, Richard Sepulveda wrote: >> >>> I have a customer that is also having this same problem with my MacRuby Mac >>> App Store application running on his new MacBook Pro. I don't have >>> access to this type of Mac so I haven't been able to reproduce this problem. >>> >>> He has tried MacRuby 0.8 and 0.9 versions of my app with the same results. >>> >>> I can provide copies of my app to developers that would like to try to >>> reproduce the problem. >>> >>> Thanks, >>> >>> Richard >>> >>> Here is a portion of the log that he sent me. >>> >>> 3/9/11 11:35:31 AM [0x0-0xe20e2].com.rsepulveda.quickalarmtrial[2927] >>> LLVM ERROR: Cannot yet select: 0x101899010: f64 = bit_convert 0x10191ae10 >>> [ORD=315] [ID=7] >>> 3/9/11 11:35:31 AM [0x0-0xe20e2].com.rsepulveda.quickalarmtrial[2927] >>> 0x10191ae10: i64 = and 0x10191b510, 0x10189a110 [ORD=314] [ID=6] >>> 3/9/11 11:35:31 AM [0x0-0xe20e2].com.rsepulveda.quickalarmtrial[2927] >>> 0x10191b510: i64,ch = CopyFromReg 0x103911388, 0x10191c510 [ORD=314] >>> [ID=5] >>> 3/9/11 11:35:31 AM [0x0-0xe20e2].com.rsepulveda.quickalarmtrial[2927] >>> 0x103911388: ch = EntryToken [ORD=314] [ID=0] >>> 3/9/11 11:35:31 AM [0x0-0xe20e2].com.rsepulveda.quickalarmtrial[2927] >>> 0x10191c510: i64 = Register %reg16384 [ORD=314] [ID=1] >>> 3/9/11 11:35:31 AM [0x0-0xe20e2].com.rsepulveda.quickalarmtrial[2927] >>> 0x10189a110: i64 = Constant<-4> [ORD=314] [ID=2] >>> 3/9/11 11:35:31 AM com.apple.launchd.peruser.501[112] >>> ([0x0-0xe20e2].com.rsepulveda.quickalarmtrial[2927]) Exited with exit code: >>> 1 >>> >>>> >>>> Nick and group, >>>> >>>> I'm seeing similar errors with the newest MacBook Pro -- after simply >>>> downloading the 1.9 binary and running macgem, macirb, or macrake. In >>>> other words, I'm not compiling from source, just trying to use the latest >>>> binary distribution on a core i7 laptop. >>>> >>>> $ sudo macgem install rack >>>> LLVM ERROR: Cannot yet select: 0x10509ba10: f64 = bit_convert 0x10508ef10 >>>> [ORD=2615] [ID=7] >>>> 0x10508ef10: i64 = and 0x105062a10, 0x10509b010 [ORD=2614] [ID=6] >>>> 0x105062a10: i64,ch = CopyFromReg 0x1039108a8, 0x105099510 [ORD=2614] >>>> [ID=5] >>>> 0x1039108a8: ch = EntryToken [ORD=2614] [ID=0] >>>> 0x105099510: i64 = Register %reg16384 [ORD=2614] [ID=1] >>>> 0x10509b010: i64 = Constant<-4> [ORD=2614] [ID=2] >>>> >>>> >>>> $ macirb >>>> LLVM ERROR: Cannot yet select: 0x104852410: f64 = bit_convert 0x104858c10 >>>> [ORD=186] [ID=7] >>>> 0x104858c10: i64 = and 0x104853c10, 0x104851910 [ORD=185] [ID=6] >>>> 0x104853c10: i64,ch = CopyFromReg 0x103b0d028, 0x104856010 [ORD=185] [ID=5] >>>> 0x103b0d028: ch = EntryToken [ORD=185] [ID=0] >>>> 0x104856010: i64 = Register %reg16384 [ORD=185] [ID=1] >>>> 0x104851910: i64 = Constant<-4> [ORD=185] [ID=2] >>>> >>>> >>>> $ macrake >>>> LLVM ERROR: Cannot yet select: 0x10506d810: f64 = bit_convert 0x105047310 >>>> [ORD=800] [ID=7] >>>> 0x105047310: i64 = and 0x105067d10, 0x105063010 [ORD=799] [ID=6] >>>> 0x105067d10: i64,ch = CopyFromReg 0x103b0cf68, 0x105043110 [ORD=799] [ID=5] >>>> 0x103b0cf68: ch = EntryToken [ORD=799] [ID=0] >>>> 0x105043110: i64 = Register %reg16384 [ORD=799] [ID=1] >>>> 0x1050
Re: [MacRuby-devel] MacRuby build issues with LLVM
Sorry the late reply. It's probably because this version of LLVM that we use cannot target the new CPU yet. I will investigate :) Laurent On Mar 9, 2011, at 12:10 PM, Nick Ludlam wrote: > Yes, this looks like it's exactly the problem I'm having, from the look of > the log, so perhaps it's a Sandy Bridge / Core i5/7 issue. Curious! > > On 9 Mar 2011, at 19:56, Richard Sepulveda wrote: > >> I have a customer that is also having this same problem with my MacRuby Mac >> App Store application running on his new MacBook Pro. I don't have >> access to this type of Mac so I haven't been able to reproduce this problem. >> >> He has tried MacRuby 0.8 and 0.9 versions of my app with the same results. >> >> I can provide copies of my app to developers that would like to try to >> reproduce the problem. >> >> Thanks, >> >> Richard >> >> Here is a portion of the log that he sent me. >> >> 3/9/11 11:35:31 AM [0x0-0xe20e2].com.rsepulveda.quickalarmtrial[2927] >> LLVM ERROR: Cannot yet select: 0x101899010: f64 = bit_convert 0x10191ae10 >> [ORD=315] [ID=7] >> 3/9/11 11:35:31 AM [0x0-0xe20e2].com.rsepulveda.quickalarmtrial[2927] >> 0x10191ae10: i64 = and 0x10191b510, 0x10189a110 [ORD=314] [ID=6] >> 3/9/11 11:35:31 AM [0x0-0xe20e2].com.rsepulveda.quickalarmtrial[2927] >> 0x10191b510: i64,ch = CopyFromReg 0x103911388, 0x10191c510 [ORD=314] >> [ID=5] >> 3/9/11 11:35:31 AM [0x0-0xe20e2].com.rsepulveda.quickalarmtrial[2927] >> 0x103911388: ch = EntryToken [ORD=314] [ID=0] >> 3/9/11 11:35:31 AM [0x0-0xe20e2].com.rsepulveda.quickalarmtrial[2927] >> 0x10191c510: i64 = Register %reg16384 [ORD=314] [ID=1] >> 3/9/11 11:35:31 AM [0x0-0xe20e2].com.rsepulveda.quickalarmtrial[2927] >> 0x10189a110: i64 = Constant<-4> [ORD=314] [ID=2] >> 3/9/11 11:35:31 AM com.apple.launchd.peruser.501[112] >> ([0x0-0xe20e2].com.rsepulveda.quickalarmtrial[2927]) Exited with exit code: 1 >> >>> >>> Nick and group, >>> >>> I'm seeing similar errors with the newest MacBook Pro -- after simply >>> downloading the 1.9 binary and running macgem, macirb, or macrake. In other >>> words, I'm not compiling from source, just trying to use the latest binary >>> distribution on a core i7 laptop. >>> >>> $ sudo macgem install rack >>> LLVM ERROR: Cannot yet select: 0x10509ba10: f64 = bit_convert 0x10508ef10 >>> [ORD=2615] [ID=7] >>> 0x10508ef10: i64 = and 0x105062a10, 0x10509b010 [ORD=2614] [ID=6] >>> 0x105062a10: i64,ch = CopyFromReg 0x1039108a8, 0x105099510 [ORD=2614] [ID=5] >>> 0x1039108a8: ch = EntryToken [ORD=2614] [ID=0] >>> 0x105099510: i64 = Register %reg16384 [ORD=2614] [ID=1] >>> 0x10509b010: i64 = Constant<-4> [ORD=2614] [ID=2] >>> >>> >>> $ macirb >>> LLVM ERROR: Cannot yet select: 0x104852410: f64 = bit_convert 0x104858c10 >>> [ORD=186] [ID=7] >>> 0x104858c10: i64 = and 0x104853c10, 0x104851910 [ORD=185] [ID=6] >>> 0x104853c10: i64,ch = CopyFromReg 0x103b0d028, 0x104856010 [ORD=185] [ID=5] >>> 0x103b0d028: ch = EntryToken [ORD=185] [ID=0] >>> 0x104856010: i64 = Register %reg16384 [ORD=185] [ID=1] >>> 0x104851910: i64 = Constant<-4> [ORD=185] [ID=2] >>> >>> >>> $ macrake >>> LLVM ERROR: Cannot yet select: 0x10506d810: f64 = bit_convert 0x105047310 >>> [ORD=800] [ID=7] >>> 0x105047310: i64 = and 0x105067d10, 0x105063010 [ORD=799] [ID=6] >>> 0x105067d10: i64,ch = CopyFromReg 0x103b0cf68, 0x105043110 [ORD=799] [ID=5] >>> 0x103b0cf68: ch = EntryToken [ORD=799] [ID=0] >>> 0x105043110: i64 = Register %reg16384 [ORD=799] [ID=1] >>> 0x105063010: i64 = Constant<-4> [ORD=799] [ID=2] >>> >>> >>> >>> Interestingly, the macruby interpreter runs without error. "macgem --help" >>> and "macgem --version" also run fine (but these options produce errors with >>> macirb or macrake). >>> >>> FWIW, I only have Xcode 4 DP2 installed on this machine... although I >>> assume the MacRuby framework doesn't have any runtime dev tool >>> dependencies? (My understanding was it could be bundled with apps and >>> distributed to end users who don't have dev tools installed.) >>> >>> Scott >>> >>> On Wednesday, March 9, 2011 at 10:40 AM, Joshua Ballanco wrote: Nick, I'm currently using Homebrew's llvm with MacRuby. Try passing the "--universal" switch when you install llvm (i.e. "brew install llvm --universal"). You also might try building and installing clang at the same time (i.e. "brew install llvm --universal --clang") and see if clang can compile a simple C hello world to rule out llvm bugs. Cheers, Josh On Wed, Mar 9, 2011 at 5:41 AM, Nick Ludlam wrote: > Yes, I've double checked that I'm running 2.8 RELEASE, and it's still > bailing out with that cryptic message. The only other thing I can think > of is to remove XCode 4 and reinstall the current XCode3 release. > > On 9 Mar 2011, at 03:37, Matt Aimonetti wrote: >>> >> ___ >>
Re: [MacRuby-devel] macgem and macirb broken after trunk r5248 (0.10) install
Hi Franco, As the version number got changed, I recommend starting with a fresh copy of MacRuby, by doing a `rake clean'. Then, you can build the project as usual, then you may want to delete the /Library/Frameworks/MacRuby.framework directory before doing a `rake install' (though this should not be necessary). Laurent On Feb 26, 2011, at 1:09 AM, Franco Rondini wrote: > Hello guys, > After checking out r5248 trunk (0.10) ( my previous svn co was of r5235 > (0.9)) the: > rake jobs=2 it's OK > sudo rake install aborts this way: > > /usr/bin/install -c -m 0755 ext/bigdecimal/lib/bigdecimal/jacobian.rbo > /Library/Frameworks/MacRuby.framework/Versions/0.10/usr/lib/ruby/site_ruby/1.9.2/bigdecimal > install: > /Library/Frameworks/MacRuby.framework/Versions/0.10/usr/lib/ruby/site_ruby/1.9.2/bigdecimal: > No such file or directory > rake aborted! > > so i fix it making the missing path by hand to finally get the 0.10 installed: > > cd /Library/Frameworks/MacRuby.framework/Versions/ > mkdir 0.10 > cd 0.10 > mkdir usr > cd usr > mkdir lib > cd lib > mkdir ruby > cd ruby > mkdir site_ruby > cd site_ruby > mkdir 1.9.2 > cd 1.9.2 > mkdir bigdecimal > cd bigdecimal > > cd ~Projects/macruby/MacRuby-trunk > sudo rake install > [snip] > ** Execute install > MacBook-di-Franco-Rondini:MacRuby-trunk ronda$ macruby --version > MacRuby 0.10 (ruby 1.9.2) [universal-darwin10.0, x86_64] > > Unfortunately the following problems have arisen: >> macirb > /usr/local/bin/macirb:3:in `': no such file to load -- ripper/core > (LoadError) >> macgem > /usr/local/bin/macgem:9:in `': uninitialized constant > Gem::ConfigFile::YAML (NameError) > MacBook-di-Franco-Rondini:MacRuby-trunk ronda$ > > could it be something wrong in my environment settings? > ..btw with the previous revisions, build and install without problems > Thanks, Bye > Franco > > ___ > 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
Re: [MacRuby-devel] stopping to build for i386
Hi Eric, On Feb 24, 2011, at 2:19 PM, Eric Christopherson wrote: > On Tue, Feb 22, 2011 at 8:31 PM, Laurent Sansonetti > wrote: >> Hi, >> As of r5239 in trunk, the default build process will no longer build for >> both i386 and x86_64, but just x86_64. This is an attempt at accelerating >> the build process and reducing the framework objects size. >> We are however not removing any i386-related code from the project, and one >> will still be able to build a 32-bit version of MacRuby by passing >> archs=i386 to rake. We will also consider fixing i386 bugs. But we want to >> start discouraging people to target i386 hardware for MacRuby apps, for >> several reasons (codebase not well tested, runtime / exception handling >> differences, floating point precision loss, etc.). The i386-related code >> could eventually be removed from MacRuby after 0.10. >> This is not an irrevocable decision, though. If people complain we will >> revert the change. But I want to give it a try. >> Laurent > > How hard do you imagine it would be for other developers to keep the > 386 code going after 0.10? It wouldn't be very easy, I'm afraid. But we can keep the code is there is a demand. Laurent___ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] iokit again
Hi Joel, Support is almost complete, be patient a bit more. Also, please follow up on the ticket (that's what they are meant to be used for). Laurent On Feb 23, 2011, at 12:20 PM, Joel Reymont wrote: > I'm chomping at the bit to have IOKit support in MacRuby. > > Can you tell me what needs to be done for IOKit support [1]? > > I may be able to do the work and submit a patch. > > Thanks in advance, Joel > > [1] http://www.macruby.org/trac/ticket/1126 > > -- > - mac osx device driver ninja, kernel extensions and user-land usb drivers > -++--- > http://wagerlabs.com | @wagerlabs | http://www.linkedin.com/in/joelreymont > -++--- > > ___ > 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
[MacRuby-devel] [ANN] MacRuby 0.9
Hi, After about 2 months of development since the last release, MacRuby 0.9 is now available. Get it here while it's still hot! MacRuby is an implementation of Ruby 1.9 directly on top of Mac OS X core technologies such as the Objective-C runtime and garbage collector, the LLVM compiler infrastructure and the Foundation and ICU frameworks. It is the goal of MacRuby to enable the creation of full-fledged Mac OS X applications which do not sacrifice performance in order to enjoy the benefits of using Ruby. You can learn more about MacRuby, and download a binary installer, from the website: http://macruby.org Or about this release more specifically, on our blog: http://www.macruby.org/blog/2011/02/24/macruby09.html Enjoy, Laurent ___ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
[MacRuby-devel] MacRuby 0.9 release notes
Here are the release notes for MacRuby 0.9! An e-mail announcing the release
will be following.
Highlights:
- Lots of stability fixes (crashers, memory leaks and race conditions), and a
few performance improvements.
- The internal representation of Strings changed from a dual binary / UTF-16
model to a pure binary one, principally to avoid problems in multithreaded
applications. Performance should remain the same in most cases.
- The macruby_deploy program has been enhanced to embed RubyGems (with
dependencies) and BridgeSupport files. See the new respective --gem and --bs
options.
- The libmacruby-static.a library is not built by default anymore, because
static compilation is still a work in progress.
- Upgraded to RubyGems 1.4.2.
Changes:
- Fix a bug in IO.open() where numeric file descriptors could not be passed as
the first argument.
- Fix an assertion that could happen when calling #methods & friends on a class
that contains a method name larger than 100 characters.
- Fix a bug in IO.open() where the given path would not be handled as a path
(calling #to_path if necessary).
- Fix a bug in the YAML extension where yajl_free() would be called on a NULL
pointer.
- Fix a bug in the OpenSSL extension, when calling ossl_pkey_sign().
- Fix a bug where calling a method defined with #define_method with a block
accepting a splat argument (arity -2) would crash.
- Fix Ruby warnings in the YAML extension.
- Fix a bug when some splat methods defined with #define_method() would
segfault at dispatch time.
- Improve the internal rb_eql() routine for performance, makes faster hash
lookup / keys comparison operations.
- Improve the hashing function for Arrays.
- Move the conformsToProtocol: and performSelector: default logic on direct
pure-Ruby subclasses.
- Fix a bug in IO#close_write where IOError would not be thrown if the stream
was readable and non-duplex.
- Fix a bug in IO#write where an exception would be raised if the stream was
read-only when writing 0 bytes of data.
- Fix a bug in Kernel.require where a file path starting with '~' would not be
loaded.
- Fix a bug in String#gsub! where we would segfault during string concatenation.
- Fix a bug in the compilation of scopes where the current_block_arg state
variable wouldn't be re-entrant (this fixes the compilation of the mechanize
library).
- Fix bugs in String#inspect when called on a string that contains invalid and
non-BMP characters.
- Fix a potential memory crasher in String#sub and String#gsub where free'd
memory would be reused.
- Fix a bug where $FILENAME, $* and $-W could be changed.
- Fix a bunch of bugs in Array methods where SecurityError would not be raised
when $SAFE is 4.
- Fix a bug in Kernel#untrust where an exception would not be raised on a
frozen object.
- Fix a bug in Kernel#trust where an exception would not be raised on a frozen
object.
- Fix a bug in Kernel#trust where an exception would not be raised if $SAFE is
equal or greater than 3.
- Fix a crash in Rational#rationalize due to registering the method with a
wrong arity.
- Fix a bug when we would free outer memory but still keep outers pointing to
that memory location, causing crashes later during const lookup (this fixes
rspec).
- Fix a bug in Struct#hash when called on recursive structs.
- Fix a bug in Array#== when called with recursive arrays.
- Fix a bug in StringIO#puts when called with recursive arrays.
- Fix a bug in Exception#== when an infinite loop would be entered when
comparing exceptions from different classes.
- Fix a bug when #initialize_copy would not raise an exception when called on
Object or BasicObject.
- Add support for encodings ISO8859_{2..16}.
- Fix a bug in String#search_codepoint where breaks were ignored.
- Fix a bug in OpenSSL::BN#to_s.
- Fix a bug in OpenSSL::PKey::DH#compute_key.
- Fix a bug in OpenSSL::X509::Attribute#to_der.
- Fix a bug in OpenSSL::PKCS5.pbkdf2_hmac(_sha1).
- Fix a bug in OpenSSL::PKey::DSA#syssign.
- Fix a bug in OpenSSL's ossl_x509store_initialize() function where an internal
value would not properly be initialized.
- Fix a bunch of bugs in Array methods where an exception would not be raised
when passing very large indexes or ranges.
- Fix a bug in Array#inspect where an untrusted string would not be returned.
- Fix a bug in String#unpack when called with a block.
- Add support for variadic objc method dispatch in the parser.
- Fix a bug in Socket.pair where the sockets would not be yielded when passing
a block.
- Fix a bug in Socket.pair(domain, type, protocol) and Socket.new(domain, type,
protocol) where protocol would not be an optional argument.
- Fix a bug in Socket.getservbyport(port) where a port outside the uint16 range
would be accepted.
- Fix a bug in Socket.getservbyport where the network byte order value would
not be passed to the underlying API.
- Fix a memory leak and potential crasher in Regexp's internal
rb_reg_matcher_new() function.
- Fix various memory leaks and potential
Re: [MacRuby-devel] 0.9 update
Hi Andre, Thanks for reporting this. Are you using the new macruby_deploy --gem option to embed the gems? Laurent On Feb 23, 2011, at 5:33 PM, Andre Lewis wrote: > It would be nice if you could try the latest nightly build with your app and > favorite Ruby lib > > My app is working with 0.9. My build process embeds MacRuby in the app > bundle, and packages the Nokogiri and Gdata gems. Everything is working so > far with 0.9. > > Thanks! Cheers, > > Andre > > ___ > 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
Re: [MacRuby-devel] 0.9 update
Hi Thomas, Yes that would be awesome! Please file a new ticket and attach your sample there, and we will review and add it to the samples repository :) Laurent On Feb 23, 2011, at 12:25 AM, Thomas R. Koll wrote: > > Great timing, I've switched from 0.8 to edge just a few days ago due to > a bug that was fixed two days after 0.8 came out. :) > > Btw, can I contribute an example of a StatusBarMenu with a custom view in one > of the menuitems? > > ciao, tom > > > Am 22.02.2011 um 23:20 schrieb Laurent Sansonetti: > >> Hi guys, >> >> 0.9 is now ready to be released! (really!). The trunk branch has been copied >> as branches/0.9 and we will continue the development on trunk, which now >> uses the 0.10 version number. >> >> It would be nice if you could try the latest nightly build with your app and >> favorite Ruby lib, and let me know if you find anything wrong, as I had to >> change (again) the const lookup rules to fix a regression. yesterday. I did >> a bit of testing and I'm confident the fix is good, but I would prefer to >> see more testing. >> >> http://www.macruby.org/files/nightlies/macruby_nightly-2011-02-22.pkg >> >> If I don't hear anything bad, 0.9 will be released Friday :) > > ___ > 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
Re: [MacRuby-devel] NoMethodError (ib_outlets)
Hi Rob, ib_outlets is an old RubyCocoa craft that is not supported in MacRuby since a long time. You can define IB outlets using the attr_writer or attr_accessor methods. You can define IB actions by defining methods accepting a single argument, named 'sender'. There are lots of documentation about this on the net. Here is a pointer to a nice tutorial that you might be interested to follow. http://blog.phusion.nl/2010/03/12/creating-our-very-first-mac-application-with-ruby-how-exciting/#more-509 Laurent On Feb 23, 2011, at 1:57 PM, Rob Gleeson wrote: > Hi > > I'm giving my first MacRuby application a shot, and I'm sort of blind to be > honest :) > I've added a NSWindowController, attached it to my window, saved the classes > in Interface Builder, but when I build and run my application, I get a > NoMethodError for 'ib_outlets'. > > My controller inherits from NSResponder. > > The stranger thing is, I guess, when I remove any code referencing > ib_outlets, the same error is raised again. NoMethodError. > > Any advice? What class defines ib_outlets? Am I doing it completely wrong? > Thanks. > > -- > Rob > > > > > > ___ > 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
[MacRuby-devel] stopping to build for i386
Hi, As of r5239 in trunk, the default build process will no longer build for both i386 and x86_64, but just x86_64. This is an attempt at accelerating the build process and reducing the framework objects size. We are however not removing any i386-related code from the project, and one will still be able to build a 32-bit version of MacRuby by passing archs=i386 to rake. We will also consider fixing i386 bugs. But we want to start discouraging people to target i386 hardware for MacRuby apps, for several reasons (codebase not well tested, runtime / exception handling differences, floating point precision loss, etc.). The i386-related code could eventually be removed from MacRuby after 0.10. This is not an irrevocable decision, though. If people complain we will revert the change. But I want to give it a try. Laurent___ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] Towards a compile option for macgem
I think that macgem should just compile the gem source files during installation, by default. We could eventually add a --no-compile argument to skip the compilation. There is just one problem: AOT compilation does not remember the DWARF metadata yet, so backtraces won't be complete. This is the reason why we are not doing this, yet. I believe we have a ticket track the AOT compilation problem, once it's fixed, we can turn this on. Maybe we can do this for 0.10. Laurent On Feb 22, 2011, at 9:18 AM, Joshua Ballanco wrote: > Hey Mark, > > I agree with Matt that macruby_deploy needs work in this area, and any effort > you can contribute (or experience that you have gained from working on your > gem plugin) would be greatly appreciated. That said, I think a gem plugin is > a separate (and, IMHO at least, as valuable) issue. > > So then, my personal view on the options you outlined: > > - A gemspec property (e.g. spec.compile_for_macruby = true) > > This seems more apt of an addition for MacRuby specifically. Unfortunately, > it seems that extraneous gemspec properties are not ignored, but if they > were, this would be a prime candidate for an option that is only used by > macgem. Now that I'm thinking about it, though, I wonder why we wouldn't just > have MacGem compile all gems? > > - A gem command: > gem compile nokogiri > gem compile —remove-original-files nokogiri > • I can’t remove the original *.rb files and leave *.rbo files by > default because of how rubygems identifies gems (unless I modify gemspec > files) > > This seems most in keeping with how other gem extensions work. I don't think > removing original files is all that important though, since keeping them > around is also useful for debugging gems. > > >> - A gem install option > >> gem install —compile nokogiri > > Maybe this is better handled with an option in .gemrc? or an environment > variable? > > I'm afraid I'm a bit too swamped at the moment to lend a hand directly, but I > like the direction you're going, and I'll definitely keep an eye on where > this is going. > > Cheers, > > Josh > ___ > 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
Re: [MacRuby-devel] NSLocalizedString
We could add such a method in MacRuby core, but I wonder if it will be really
that much of a use. NSLocalizedString macros are used in Objective-C programs
because they are parsed by the genstrings command-line tool, to generate the
translation file. I am not sure if genstrings can be used on Ruby files.
At some point we will need a l10n solution for MacRuby apps, though. I am
wondering if there isn't already a Ruby library for this? (something like
gettext?).
Laurent
On Feb 22, 2011, at 9:50 AM, Eloy Duran wrote:
> Something like this:
>
> module Kernel
> private
>
> def NSLocalizedString(key, value)
>NSBundle.mainBundle.localizedStringForKey(key, value:value, table:nil)
> end
> end
>
> On 21 feb 2011, at 23:56, Charles Steinman wrote:
>
>> On Mon, Feb 21, 2011 at 8:23 AM, Martin Hawkins
>> wrote:
>>> Changing the line to
>>> return NSBundle.mainBundle.localizedStringForKey("Today", value:"Today
>>> title string", table:nil)
>>> works but NSLocalizedString is supposed to be a Foundation Function,
>>> so should be 'freely' available in MacRuby, shouldn't it?
>>
>> The trouble is that NSLocalizedString is not actually a function —
>> it's a macro, so MacRuby can't call it. It really just needs to be
>> reimplemented, but until then the NSBundle methods are precisely
>> equivalent.
>>
>> — Chuck
>> ___
>> 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
___
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
[MacRuby-devel] 0.9 update
Hi guys, 0.9 is now ready to be released! (really!). The trunk branch has been copied as branches/0.9 and we will continue the development on trunk, which now uses the 0.10 version number. It would be nice if you could try the latest nightly build with your app and favorite Ruby lib, and let me know if you find anything wrong, as I had to change (again) the const lookup rules to fix a regression. yesterday. I did a bit of testing and I'm confident the fix is good, but I would prefer to see more testing. http://www.macruby.org/files/nightlies/macruby_nightly-2011-02-22.pkg If I don't hear anything bad, 0.9 will be released Friday :) Thanks, Laurent___ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
[MacRuby-devel] 0.9 update
Hi guys, 0.9 is now ready to be released! (really!). The trunk branch has been copied as branches/0.9 and we will continue the development on trunk, which now uses the 0.10 version number. It would be nice if you could try the latest nightly build with your app and favorite Ruby lib, and let me know if you find anything wrong, as I had to change (again) the const lookup rules to fix a regression. yesterday. I did a bit of testing and I'm confident the fix is good, but I would prefer to see more testing. http://www.macruby.org/files/nightlies/macruby_nightly-2011-02-22.pkg If I don't hear anything bad, 0.9 will be released Friday :) Thanks, Laurent___ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] WeakRef advice
Hi Alan, Do you control the data structure that holds a reference to 'B'? If yes, you may want to use NSHashTable which supports weak references. To me, this sounds like a design problem. Maybe your project can be re-architectured to avoid this pattern. Laurent On Feb 15, 2011, at 12:22 AM, Alan Skipp wrote: > Hi Laurent, > Thanks for the response. In essence the problem I have is something like this: > > Object 'A' is created, then to handle Key Value Observing, Object 'B' is > created which holds an instance variable to Object 'A'. 'B' is held in a hash > or array somewhere. Object 'B' only has a purpose while 'A', is in use, when > this is no longer the case I want 'B' to self destruct. However, 'B' is held > in a hash and holds a reference to 'A', so neither object goes out of scope > and neither can be garbage collected. > > If I changed the implementation perhaps I could avoid this problem, though > I'm not sure what the solution would be as yet. > > al > > On 14 Feb 2011, at 22:09, Laurent Sansonetti wrote: > >> Hi Alan, >> >> MacRuby should have the same problem. ObjectSpace._id2ref in MacRuby >> basically maps an object pointer value to a numerical description, and the >> GC recycles objects. >> >> I am curious why you need weak references, though. MacRuby is able to detect >> and deal with reference cycles, so you shouldn't need to worry about leaks. >> Is there another use case that I'm forgetting? >> >> Laurent > > ___ > 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
Re: [MacRuby-devel] WeakRef advice
Hi Alan,
MacRuby should have the same problem. ObjectSpace._id2ref in MacRuby basically
maps an object pointer value to a numerical description, and the GC recycles
objects.
I am curious why you need weak references, though. MacRuby is able to detect
and deal with reference cycles, so you shouldn't need to worry about leaks. Is
there another use case that I'm forgetting?
Laurent
On Feb 14, 2011, at 5:48 AM, Alan Skipp wrote:
> Hello everyone,
> I've been doing some research into weak references in ruby and from what I've
> read it seems that Ruby's WeakRef implementation is both inefficient and
> unsafe. Here is the thread discussing the matter:
> http://redmine.ruby-lang.org/issues/show/4168
>
> As Macruby has a different garbage collector I don't know if these problems
> are also present?
>
> I am working on a blocks based API for Key Value Coding and need to keep a
> weak reference to objects.
> Here is a very basic example of how this would look in garbage collected
> Objective-C:
>
> @interface Observer : NSObject
> {
>__weak id obj;
> }
>
> @implementation
> - (Observer *)initObservedObject:(id)object
> {
> obj = object;
> }
>
>
> Essentially I just need a Macruby equivalent of the above. Is there a simple
> way to have a weak referenced instance variable in Macruby?
>
> al
> ___
> 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
Re: [MacRuby-devel] MacRuby 0.9 - crash using Proc.new with NSArray.enumerateObjectsUsingBlock
Hi Jonathan,
Your snippet does not require the Foundation framework. Add the following line
to your script
framework 'Foundation'
You will also need MacRuby 0.8 and the latest BridgeSupport Preview 3 release.
Then let us know if you still reproduce the crash.
The snippet works fine in my environment :(
Laurent
On Feb 13, 2011, at 8:55 AM, Jonathan Waddilove wrote:
> Hi, another MacRuby 0.9 question...
>
> I've been trying to use lambda and/or Proc.new to provide callback blocks (as
> suggested in Matt's excellent draft book). Again I have seen discussions
> about problems in this area and for me all the suggested variants of code
> fail.
>
> Here's a snip of failing code:
>
> #!/usr/local/bin/macruby
> puts "Ruby Version: #{RUBY_VERSION}, MacRuby Version: #{MACRUBY_VERSION}"
>
> a = [1, 2, 3, 4, 5,]
>
> a.enumerateObjectsUsingBlock(Proc.new {|obj, index, stop|
> puts "I'll bet this never displays"
> })
>
> and here's the resulting crash...
>
> Any suggestions? many thanks, Jonathan
>
>
> Process: macruby [23078]
> Path:
> /Library/Frameworks/MacRuby.framework/Versions/0.8/usr/bin/macruby
> Identifier: macruby
> Version: ??? (???)
> Code Type: X86-64 (Native)
> Parent Process: ruby [23074]
>
> Date/Time: 2011-02-13 16:50:33.806 +
> OS Version: Mac OS X 10.6.6 (10J567)
> Report Version: 6
>
> Exception Type: EXC_BAD_ACCESS (SIGSEGV)
> Exception Codes: KERN_INVALID_ADDRESS at 0x
> Crashed Thread: 0 Dispatch queue: com.apple.main-thread
>
> Application Specific Information:
> objc[23078]: garbage collection is ON
>
> Thread 0 Crashed: Dispatch queue: com.apple.main-thread
> 0 ??? 00 0 + 0
> 1 ??? 0x000102d63ac6 0 + 4342561478
> 2 libmacruby.dylib 0x00010014a0b3 rb_vm_dispatch + 1331
> 3 ??? 0x000102d5a536 0 + 4342523190
> 4 ??? 0x000102d63806 0 + 4342560774
> 5 libmacruby.dylib 0x000100162d53 rb_vm_run + 531
> 6 libmacruby.dylib 0x0001000408f0 ruby_run_node + 80
> 7 macruby 0x00010d28 main + 152
> 8 macruby 0x00010c88 start + 52
>
> Thread 1:
> 0 libSystem.B.dylib 0x7fff88fe5f8a __workq_kernreturn +
> 10
> 1 libSystem.B.dylib 0x7fff88fe639c _pthread_wqthread +
> 917
> 2 libSystem.B.dylib 0x7fff88fe6005 start_wqthread + 13
>
> Thread 0 crashed with X86 Thread State (64-bit):
> rax: 0x7fff5fbfddc0 rbx: 0x rcx: 0x7fff5fbfdf0f
> rdx: 0x
> rdi: 0x0002000bed00 rsi: 0x0002000bec00 rbp: 0x7fff5fbfdf40
> rsp: 0x7fff5fbfdcf8
> r8: 0x0002 r9: 0x0005 r10: 0x0001
> r11: 0x000100af9000
> r12: 0x0002000bec00 r13: 0x r14: 0x0005
> r15: 0x
> rip: 0x rfl: 0x00010246 cr2: 0x
>
> Binary Images:
> 0x1 -0x10ff7 +macruby ??? (???)
> <4408616F-9F77-025F-C278-91F945728AB0> /usr/local/bin/macruby
> 0x13000 -0x100a29fd7 +libmacruby.dylib 0.8.0 (compatibility
> 0.8.0) <8910242D-90F3-32AC-A4CA-99D5C316AEB8>
> /Library/Frameworks/MacRuby.framework/Versions/0.8/usr/lib/libmacruby.dylib
>0x7fff5fc0 - 0x7fff5fc3bdef dyld 132.1 (???)
> <486E6C61-1197-CC7C-2197-82CE505102D7> /usr/lib/dyld
>0x7fff801f1000 - 0x7fff802aafff libsqlite3.dylib 9.6.0 (compatibility
> 9.0.0) <2C5ED312-E646-9ADE-73A9-6199A2A43150> /usr/lib/libsqlite3.dylib
>0x7fff802ba000 - 0x7fff80478fff libicucore.A.dylib 40.0.0
> (compatibility 1.0.0) <781E7B63-2AD0-E9BA-927C-4521DB616D02>
> /usr/lib/libicucore.A.dylib
>0x7fff809d - 0x7fff80a8dff7 com.apple.CoreServices.OSServices 357
> (357) <7B22626F-D544-1955-CC53-240F4CACEB4A>
> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/OSServices.framework/Versions/A/OSServices
>0x7fff815d5000 - 0x7fff815ebfef libbsm.0.dylib ??? (???)
> <42D3023A-A1F7-4121-6417-FCC6B51B3E90> /usr/lib/libbsm.0.dylib
>0x7fff817b9000 - 0x7fff817bdff7 libmathCommon.A.dylib 315.0.0
> (compatibility 1.0.0) <95718673-FEEE-B6ED-B127-BCDBDB60D4E5>
> /usr/lib/system/libmathCommon.A.dylib
>0x7fff81cbb000 - 0x7fff81d05ff7 com.apple.Metadata 10.6.3 (507.15)
> <5170FCE0-ED6C-2E3E-AB28-1DDE3F628FC5>
> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/Metadata.framework/Versions/A/Metadata
>0x7fff8208d000 - 0x7fff82310ff7 com.apple.Foundation 6.6.4 (751.42)
>
> /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation
>0x7fff82318000 - 0x7fff82340fff com.apple.Dictionary
[MacRuby-devel] macruby_deploy changes
Hi guys, For those who are not following trunk, macruby_deploy got some changes recently: - The --gem option is added. This option will embed the given RubyGem and its dependencies inside the application's bundle. ex. $ macruby_deploy --embed --gem nokogiri Foo.app - The --bs option is added. This option will embed the system BridgeSupport files inside the application's bundle. This can be useful if you rely on BridgeSupport preview. ex. $ macruby_deploy --embed --bs Foo.app - A bug has been fixed, when macruby_deploy was called with --embed but not --compile. The main application executable would not have its load path updated. This was a serious problem. - When using --embed, the 'Current' symlink of the framework is now deleted. Apparently this fixes the Mac AppStore validation process which was following both '0.9' and 'Current' symlinks and ending with a "Payload not declared in Package info" error. Please give tonight's nightly build a try and let us know if you find something wrong :) Laurent___ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] error: gc operation on unregistered thread
It is not a MacRuby problem. This message is triggered by the GC when an operation (allocation, collection, whatever) happens on a thread that has not been registered. I suspect macfuse spawns new pthreads without calling the objc_registerThreadWithCollector() function. Laurent On Feb 9, 2011, at 4:43 PM, Joel Reymont wrote: > I get a bunch of errors like this when running the hellofs MacFUSE example > [1]: > > macruby(25346,0x107082000) malloc: *** auto malloc[25346]: error: GC > operation on unregistered thread. Thread registered implicitly. Break on > auto_zone_thread_registration_error() to debug. > > Is this a MacRuby problem? How do I fix it? > > Thanks, Joel > > [1] http://www.macruby.org/trac/ticket/922 > > -- > - mac osx device driver ninja, kernel extensions and user-land usb drivers > -++--- > http://wagerlabs.com | @wagerlabs | http://www.linkedin.com/in/joelreymont > -++--- > > ___ > 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
Re: [MacRuby-devel] macfuse example broken again?
Please open a new ticket and we will look :) Laurent On Feb 9, 2011, at 7:49 AM, Joel Reymont wrote: > Is it just me or has the hellofs example [1] stopped working again? > > [1] http://www.macruby.org/trac/ticket/922 > > -- > - mac osx device driver ninja, kernel extensions and user-land usb drivers > -++--- > http://wagerlabs.com | @wagerlabs | http://www.linkedin.com/in/joelreymont > -++--- > > ___ > 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
Re: [MacRuby-devel] BridgeSupport Requirement
Hi Martin,
Are you sure you embedded the BridgeSupport file defining the
kInternetEventClass constant?
Looking on my system, it's in the HIServices.bridgesupport file.
You need to embed all BridgeSupport file dependencies, not only Cocoa or
Foundation. Here is a command snippet that will embed *all* of them:
$ find /System/Library/Frameworks -name "*.bridgesupport" -exec cp {}
/path/to/MyApp.app/Contents/Resources/BridgeSupport \;
That is going to increase your app bundle of about 7MB. You can remove the
frameworks files you don't use after,. The solution we will implement in
macruby_deploy might be a bit smarter by only embedding the files you need.
Laurent
On Feb 9, 2011, at 12:24 AM, Martin Hawkins wrote:
> Laurent,
> Your suggestion didn't work. We've taken to defining the constants
> locally (it's KInternetEventClass KAEGetURL for NSAppleEventManager
> that are causing all this).
> I'm having difficulty testing this because I'm relying on a third
> party to do so - I had to upgrade both my iMac and Powerbook to
> BridgeSupport Preview 3, so unless I can roll back on one of them
> (which you said was difficult) it's going to be hard to fix this.
>
> regards
> Martin
>
> On Feb 8, 10:54 pm, Laurent Sansonetti wrote:
>
>> Seems good! Let us know if it does not work.
>>
>>>>>> I think we should add an option to macruby_deploy to automate this.
>>>>>> Could you file a ticket?
>>
>>> Will file a ticket now.
>>
>> Thanks. I added the 0.9-blocker keyword, as I think it should go with the
>> --gem option too.
>>
>> Laurent
>>
>> ___
>> MacRuby-devel mailing list
>> MacRuby-de...@lists.macosforge.orghttp://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
___
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] BridgeSupport Requirement
On Feb 8, 2011, at 5:30 AM, Martin Hawkins wrote: > Thank you for the replies. > >>> On 8/02/2011, at 10:50 PM, Laurent Sansonetti wrote: >> >>>> Hi Martin, >> >>>> There is a way: if you copy the .bridgesupport files of your system inside >>>> your application's bundle, under the Resources/BridgeSupport directory, >>>> MacRuby should look at them in priority. >> >>>> Examples: >> >>>>Foo.app/Contents/Resources/BridgeSupport/Foundation.bridgesupport >>>>Foo.app/Contents/Resources/BridgeSupport/AppKit.bridgesupport >>>>etc. > > Just to confirm - > I have added a folder under Resources in Xcode called BridgeSupport > into which I have copied > AppKit.bridgesupport > CoreServices.bridgesupport > Cocoa.bridgesupport and > Foundation.bridgesupport > > When I build now, I see the Contents/Resources/BridgeSupport directory > containing the .bridgesupport files, so it seems to have had the > desired effect. > I'll be able to get it tested soon and I'll let you know if there are > any further problems. Seems good! Let us know if it does not work. >>>> I think we should add an option to macruby_deploy to automate this. Could >>>> you file a ticket? > > Will file a ticket now. Thanks. I added the 0.9-blocker keyword, as I think it should go with the --gem option too. Laurent___ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] BridgeSupport Requirement
Yep it does.
But if you copy the BridgeSupport file under the "special"
Resources/BridgeSupport directory of your .app bundle, you do not need to pass
the full path nor use #load_bridge_support_file. You can just use #framework as
before.
Laurent
On Feb 8, 2011, at 1:56 AM, Robert Payne wrote:
> If you specify a full path does Bridge Support behave this way? Such as
>
> load_bridge_support_file NSBundle.mainBundle.pathForResource("MyFramework",
> ofType:"bridgesupport")
>
> Robert
>
> On 8/02/2011, at 10:50 PM, Laurent Sansonetti wrote:
>
>> Hi Martin,
>>
>> There is a way: if you copy the .bridgesupport files of your system inside
>> your application's bundle, under the Resources/BridgeSupport directory,
>> MacRuby should look at them in priority.
>>
>> Examples:
>>
>> Foo.app/Contents/Resources/BridgeSupport/Foundation.bridgesupport
>> Foo.app/Contents/Resources/BridgeSupport/AppKit.bridgesupport
>> etc.
>>
>> I think we should add an option to macruby_deploy to automate this. Could
>> you file a ticket?
>>
>> Laurent
>>
>> On Feb 8, 2011, at 1:07 AM, Martin Hawkins wrote:
>>
>>> I installed BridgeSupport Preview 3 in order to resolve some issues
>>> related to errors looking up constant values. The new BridgeSupport
>>> worked fine and the application I have been working runs fine. I have
>>> 'embedded' MacRuby so that it can be distributed but here I come
>>> unstuck.
>>>
>>> When run on a computer that does not have the BridgeSupport upgrade,
>>> it crashes; it seems that, while the app makes no reference to the
>>> MacRuby framework, it does need the new version of BridgeSupport in
>>> order to run.
>>>
>>> This makes the notion of an embedding fragile - is there a way to
>>> embed the required BridgeSupport, or must I require that users upgrade
>>> their BrigeSupport before they install my app.?
>>> ___
>>> 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
>
> ___
> 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
Re: [MacRuby-devel] BridgeSupport Requirement
Hi Martin, There is a way: if you copy the .bridgesupport files of your system inside your application's bundle, under the Resources/BridgeSupport directory, MacRuby should look at them in priority. Examples: Foo.app/Contents/Resources/BridgeSupport/Foundation.bridgesupport Foo.app/Contents/Resources/BridgeSupport/AppKit.bridgesupport etc. I think we should add an option to macruby_deploy to automate this. Could you file a ticket? Laurent On Feb 8, 2011, at 1:07 AM, Martin Hawkins wrote: > I installed BridgeSupport Preview 3 in order to resolve some issues > related to errors looking up constant values. The new BridgeSupport > worked fine and the application I have been working runs fine. I have > 'embedded' MacRuby so that it can be distributed but here I come > unstuck. > > When run on a computer that does not have the BridgeSupport upgrade, > it crashes; it seems that, while the app makes no reference to the > MacRuby framework, it does need the new version of BridgeSupport in > order to run. > > This makes the notion of an embedding fragile - is there a way to > embed the required BridgeSupport, or must I require that users upgrade > their BrigeSupport before they install my app.? > ___ > 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
Re: [MacRuby-devel] Subject: Re: Strange NSDate behavior building 32 bit v 64 bit
Hi Richard, 0.7 is a bit old at this point, I recommend using the latest release, 0.8. This said, nightly builds have been pretty stable so far, so you may want to try one too. This is basically what will be released as 0.9 very soon (this week maybe!). Laurent On Jan 31, 2011, at 7:59 PM, Richard Sepulveda wrote: > Thanks for the rapid response to this problem. I will verify that it works > with my project as > soon as I can get MacRuby built. I also ran into some other strangeness in > 32-bit mode but this may fix > those issues as well. I will give an update soon. > > Another question, my project is currently using the default 0.7 MacRuby > framework included in XCode. I assume > that I should include this fix in the latest 0.7 or 0.8 build and run all of > the test suites to verify that I didn't > break anything in the build process? > > Thanks again, > > Richard > > On Jan 31, 2011, at 3:22 PM, Vincent Isambart wrote: > >> Sorry, I'm not patient so I filed the ticket: >> http://www.macruby.org/trac/ticket/1143 >> And fixed it in r5215 :D >> http://www.macruby.org/trac/changeset/5215/ >> >> On Feb 1, 2011, at 8:07 AM, Laurent Sansonetti wrote: >> >>> Like Jordan said :) >>> >>> Please file a ticket and we will get this fixed in 0.9. Bugs breaking >>> applications are considered as a priority. >>> >>> I think 0.9 should remain 32/64 bits, but the release after may drop 32-bit >>> support (unless people really need it). I can add a note in the 0.9 release >>> notes and then we can see if people complain. >>> >>> Laurent >>> >>> On Jan 31, 2011, at 12:07 PM, Jordan K. Hubbard wrote: >>> >>>> Fair enough, I did not realize that you'd already deployed an app based on >>>> MacRuby and had already received bug reports (which suggests that the >>>> number of 32 bit users is clearly non-zero, at least!). Have you filed a >>>> ticket in trac with a reduction (e.g. the minimum code necessary to >>>> demonstrate the problem) yet? That will allow us to track and prioritize >>>> the work for possible inclusion in 0.9 (or later, depending on how things >>>> go). >>>> >>>> Thanks, >>>> >>>> - Jordan >>>> >>>> On Jan 31, 2011, at 2:41 AM, Richard Sepulveda wrote: >>>> >>>>> That makes perfectly good sense but i unfortunately started selling a >>>>> MacRuby app on the App Store >>>>> for i386 and 64 bit machines. And a few people are experiencing this >>>>> issue. I was just hoping >>>>> for a quick workaround to make them happy. And I would discontinue >>>>> selling the 32 bit version >>>>> on the next release. >>>>> >>>>> But i can't see anything obvious other than rewriting all of my NSDate >>>>> based code in Objective-C or >>>>> waiting for a fix. i include the MacRuby framework in my Pkg so that is >>>>> possible. >>>>> >>>>> Richard >>>> >> > ___ > 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
Re: [MacRuby-devel] Subject: Re: Strange NSDate behavior building 32 bit v 64 bit
Like Jordan said :) Please file a ticket and we will get this fixed in 0.9. Bugs breaking applications are considered as a priority. I think 0.9 should remain 32/64 bits, but the release after may drop 32-bit support (unless people really need it). I can add a note in the 0.9 release notes and then we can see if people complain. Laurent On Jan 31, 2011, at 12:07 PM, Jordan K. Hubbard wrote: > Fair enough, I did not realize that you'd already deployed an app based on > MacRuby and had already received bug reports (which suggests that the number > of 32 bit users is clearly non-zero, at least!). Have you filed a ticket in > trac with a reduction (e.g. the minimum code necessary to demonstrate the > problem) yet? That will allow us to track and prioritize the work for > possible inclusion in 0.9 (or later, depending on how things go). > > Thanks, > > - Jordan > > On Jan 31, 2011, at 2:41 AM, Richard Sepulveda wrote: > >> That makes perfectly good sense but i unfortunately started selling a >> MacRuby app on the App Store >> for i386 and 64 bit machines. And a few people are experiencing this issue. >> I was just hoping >> for a quick workaround to make them happy. And I would discontinue selling >> the 32 bit version >> on the next release. >> >> But i can't see anything obvious other than rewriting all of my NSDate based >> code in Objective-C or >> waiting for a fix. i include the MacRuby framework in my Pkg so that is >> possible. >> >> Richard >> >>> Message: 2 >>> Date: Sun, 30 Jan 2011 22:08:38 -0800 >>> From: "Jordan K. Hubbard" >>> To: "MacRuby development discussions." >>> >>> Subject: Re: [MacRuby-devel] Strange NSDate behavior building 32 bit v >>> 64 bit >>> Message-ID: >>> Content-Type: text/plain; charset="us-ascii" >>> >>> I suppose this begs the question: Does anyone really *require* 32 bit >>> support for MacRuby at this point? SnowLeopard is already the minimum >>> supported config, and the only Intel 32 bit-only platforms (very early >>> MacBook and Mac Mini configurations) are several years old now. I don't >>> want to sound like an unfeeling ogre to anyone who actually has such a >>> configuration, mind you, but how big of an installed base does this really >>> represent? >>> >>> - Jordan >>> >>> On Jan 30, 2011, at 8:49 PM, Vincent Isambart wrote: >>> > 1. Modified the Valid Archetectures to "i386 x86_64" There's a simple way to run macruby (or any other program) on the command line in 32 bits: just add "arch -i386" before the name of the program to execute: $ macruby -v MacRuby 0.9 (ruby 1.9.2) [universal-darwin10.0, x86_64] $ arch -i386 macruby -v MacRuby 0.9 (ruby 1.9.2) [universal-darwin10.0, i386] >> ___ >> 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 ___ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] Gems again; signing records
Hi Caio, On Jan 28, 2011, at 2:39 PM, Caio Chassot wrote: > On 2011-01-28, at 20:30 , Laurent Sansonetti wrote: >> >> As I suggested on IRC yesterday, I think we should add a --gem argument to >> macruby_deploy, which would make sure the given gems and their dependencies >> are unpacked inside the application bundle. > > It could be great if this involved a bit of magic, so you only specify the > gems you need in a single place. > > Maybe it's overkill, but we could rely on Bundler. I'm a Bundler hater turned > devotee. It really helps keep a tight grip on a project's gem dependencies, > locking versions and all. With the added benefit to pull gems from custom > paths and git repos. > > I suppose such support could be built on top of a simpler --gem argument in a > rake task, though. I would rather avoid any dependency. I agree that keeping track of the gems you need in a single place is a good idea, though. Maybe we should refactor the Xcode templates to do so, eventually. Another possibility would be to scan the application's source code and auto-detect the list of gems, but I prefer to avoid that. Laurent___ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] Gems again; signing records
Hi Martin, I think we now get the "how to embed gems in a MacRuby Xcode project?" question every week. I think it's time that we provide a way to automate that and properly document it on the website. As I suggested on IRC yesterday, I think we should add a --gem argument to macruby_deploy, which would make sure the given gems and their dependencies are unpacked inside the application bundle. I created the following ticket to track this change, and I believe it should be done for 0.9. https://www.macruby.org/trac/ticket/1137 Laurent On Jan 28, 2011, at 9:41 AM, Martin Hawkins wrote: > I know this has been asked before but his is driving me nuts.It' s > been a frustrating day; I've been trying to use the UUID gem and have > still not been able to 'require' it successfully. > > I have installed uuid using macgem and have unpacked it to a vendor > directory, so I now have : > vendor -- macaddr-1.0.0 -- lib -- macaddr.rb > -- uuid-2.3.1 -- lib -- uuid.rb > > Obviously, there's more, but those are important bits. > > I have tried the following, after googling, with no success, on the > basis that the files are 'require'd and once loaded, can be 'require'd > again by simple reference: > In rb_main.rb > > $:.unshift File.join(File.dirname(__FILE__), 'Vendor/uuid-2.3.1/lib') > $:.unshift File.join(File.dirname(__FILE__), 'Vendor/macaddr-1.0.0/ > lib') > > require 'macaddr' > require 'uuid' > > However, when I try to require 'macaddr' or 'uuid' from another class > definition file, I get 'no such file to load'. > > I've tried setting ENV['GEM_HOME']='/Users/martin/work/macruby/onWeb/ > PeepOpen/Vendor' in rb_main.rb; that seemed to make no difference. > > I've tried using the full path: > require '/Users/martin/work/macruby/onWeb/xx/Vendor/macaddr-1.0.0/ > lib/macaddr' > require '/Users/martin/work/macruby/onWeb/xx/Vendor/uuid-2.3.1/lib/ > uuid' > and this produces a 'no such file to load -- fileutils' - neither gem > depends on fileutils ! > > But hey, I tried it and it refused to build - 'checking for Magick- > config... no' > > So I have two questions: > > 1. What is the *proper* way of incorporating gems into a MacRuby > project using XCode to build and run; and > 2. All I want to do is sign records for later comparison. Can anybody > suggest an alternative method, other than using UUID? > > thanks > ___ > 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
