Until someone figures out what the hack really means [ dmg.grow(...) ] I wouldn't consider it a patch. Clues can be found in rep/binject/ext/binject_c/binject.c and hfslib.c (the grow_hfs function). Without knowing much about that code, I can only guess that its the max size of the .dmg - it could also be the minimum for all I know and using a high value might be wasting space and larger downloads for simple apps. Since we're in C code, that explains the crash instead of a ruby trace.
Someone who really knows the code will have to make those changes. I'm not comfy in there. Since a lot of pack.rb is a Shoes page/applet one could add a gui field to specify the size with a default to the 10MB limit for the rare occasion someone packs in a lot of stuff. Better yet, a clever person could write code to better guess the proper value. Won't be me. --Cecil On Sat, 2009-05-23 at 16:28 -0700, Noah Thorp wrote: > I wonder if there are side effects to setting this value rather than > sensing the size of the application. I have a github account... just > not sure if it is best as a trunk or local fix without knowing much > about the internals of shoes. > > -Noah > > On May 23, 2009, at 3:48 PM, e deleflie wrote: > > >> Hey Cecil, > >> > >> Thank you! The hack you suggested worked I now have a dmg file which > >> includes the 10mb ffmpeg file. > > > > great! > > > > Assuming that _why doesn't read all messages in all threads, how can > > we make sure this fix gets put into the source ... is it all about > > github? Does someone have an account on github that they can push this > > through? > > > > Etienne > > > >> Yes, ffmpeg wrappers are a major pain with all the targets. The > >> biggest pain > >> though is the licensing problem for encoders - I am still sorting > >> out the > >> legal implications of distributing aac and h264 encoders. So far > >> it looks > >> murky and not encouraging. ffmpegX gets around this by having you > >> download > >> ffmpeg from some other site and can't legally automate this > >> process. I think > >> that removes the simplicity that I want to deliver to the user. > >> Blech, I > >> hate licensing quagmires! > >> > >> I just built a quick shoes prototype of a 1 click transcoder. If > >> the the > >> legal stuff doesn't get in the way, the idea is to have a batch > >> encoder with > >> a configurable yaml file with ffmpeg parameters. It will upload > >> files to a > >> website once the transcoding is done. The idea being that it does the > >> conversion locally to one or several formats and can post the files > >> to a > >> designated web service. This is instead of requiring the user to > >> upload > >> gigabytes of data and it eliminates (or reduces) the need for a > >> transcoding > >> farm. I think it would be benificial for lots of small sites that > >> require > >> transcoding for their initial content, although it's usefulness > >> peters out > >> after you change your mind about what formats you need. > >> > >> Anyway... I'll stop there since it's not really that super shoes > >> related. > >> > >> If you want to chat more about the ffmpeg stuff email me. > >> > >> Best, > >> Noah > >> > >> On May 22, 2009, at 10:39 PM, Cecil Coupe wrote: > >> > >>> It's difficult meta problem. I'm on Linux (Ubuntu 9.04) and I'd > >>> like a > >>> little shoes app that front ends ffmpeg. Except.... it has to > >>> front end > >>> the ffmpeg I have, not the one someone thinks I need. Cross platform > >>> reaching out to system installed dynamic libraries from inside > >>> Shoes is > >>> a problem I shudder to think about. Mostly, Shoes won't. Hint's > >>> are in > >>> the installer code. For good reasons it maybe shouldn't. Bundling > >>> your > >>> own ffmpeg is also a big problem if you cover all the architectures, > >>> that's no fun either. > >>> > >>> ffmepgX was (is) an awesome GUI wrapper. I still miss it on Linux. A > >>> Shoes version would be a fine achievement. Keep me (or the list) > >>> informed. > >>> > >>> --Cecil > >>> > >>> On Fri, 2009-05-22 at 21:37 -0700, Noah Thorp wrote: > >>>> > >>>> Cecil. Thanks for the lead I will have a look at that! I agree with > >>>> you that I would prefer to find the bug rather than downloading > >>>> files > >>>> - seem cleaner. I will have a look and see how it goes. It might > >>>> lead > >>>> me to automating other aspects of the build process as well once > >>>> I see > >>>> how the packaging works. > >>>> > >>>> Thanks! > >>>> Noah > >>>> > >>>> On May 22, 2009, at 8:44 PM, Cecil Coupe wrote: > >>>> > >>>>> I hate to follow up my own message but > >>>>> > >>>>> pack.rb line 156 (my older version of shoes) has this line of ruby > >>>>> dmg.grow(10) > >>>>> > >>>>> That seems like an arbitrary number that some folks have > >>>>> reported. I > >>>>> don't know what dmg.grow() does, but a hacker might up that to > >>>>> 30 or > >>>>> 40 > >>>>> and see what happens. Or one could read the docs for binject. > >>>>> Where > >>>>> that > >>>>> pack.rb is on your system and which copy of shoes you are using > >>>>> if you > >>>>> have multiples... > >>>>> > >>>>> Just something to look at. > >>>>> --Cecil > >>>>> > >>>>> > >>>>> On Fri, 2009-05-22 at 21:00 -0600, Cecil Coupe wrote: > >>>>>> > >>>>>> It might be easier to debug and fix the problem than implement a > >>>>>> workaround, IMHO. It looks like most of the action starts in > >>>>>> lib/shoes/pack.rb - I don't have an OS X box anymore so I can't > >>>>>> be > >>>>>> very > >>>>>> helpful. Might be an easy fix if you can find all the parts. > >>>>>> > >>>>>> > >>>>>> > >>>>>> On Fri, 2009-05-22 at 21:24 -0500, Roy Wright wrote: > >>>>>>> > >>>>>>> Maybe as a work around, implement a download and install > >>>>>>> ffmpeg as > >>>>>>> needed instead of including the binary in the package? > >>>>>>> Similar to > >>>>>>> how a > >>>>>>> shoes app can download and install shoes... > >>>>>>> > >>>>>>> HTH, > >>>>>>> Roy > >>>>>>> > >>>>>>> Noah Thorp wrote: > >>>>>>>> > >>>>>>>> Thanks for the encouragement. I have plans to post the open > >>>>>>>> source > >>>>>>>> transcoder (ffmpeg wrapper) once it had reaches a certain level > >>>>>>>> of alpha > >>>>>>>> maturity. It's a very simple but useful app. I could post it to > >>>>>>>> github > >>>>>>>> early if it would help troubleshooting. But, it seems like it > >>>>>>>> may > >>>>>>>> be an > >>>>>>>> issue simply with including large files in an OS X package. > >>>>>>>> > >>>>>>>> Thanks, > >>>>>>>> Noah > >>>>>>>> > >>>>>>>> On May 22, 2009, at 5:31 PM, e deleflie wrote: > >>>>>>>> > >>>>>>>>> Hi Noah, > >>>>>>>>> > >>>>>>>>> I dont think you are falling outside of the use case it was > >>>>>>>>> intended > >>>>>>>>> for ... I think its just a bug. > >>>>>>>>> > >>>>>>>>> I dont have a work-around for you .... (maybe someone else > >>>>>>>>> does) ... > >>>>>>>>> but if we shout loud enough .... _why might hear our plea to > >>>>>>>>> have a > >>>>>>>>> look at this bug. > >>>>>>>>> > >>>>>>>>> So it looks like large binaries (5 to 10MB and up?) included > >>>>>>>>> in a > >>>>>>>>> folder and packaged up, for OSX, cause the packager to crash. > >>>>>>>>> > >>>>>>>>> Etienne > >>>>>>>>> > >>>>>>> > >>>>>> > >>>>> > >>>> > >>> > >> > >> >
