You could try packaging a simple hello world app with both the
original setting and the changed setting, and see if there's an
obvious difference between the packages. My guess would be that it's
possible that with the larger option, the generated DMG will be
larger, which may be undesirable. I haven't looked at the code, but
is it possible to figure out how big the files are and then set the
size to grow() appropriately?
On May 23, 2009, at 16:28, 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
