Hi Mark,
Thanks for your interest.
You don't have to wait for Apple to review my app. You can download a free copy
from RiceCNC.com, but because the app is for machine control you can't do much
with it without having a hobby milling machine and getting a Digilent "ChipKit"
Uno32 µP board ($29.
Hello Robert,
I'm glad to hear you finally solved your problems :)
Would you mind telling us when your application in on the App Store? I think
it's good to see what other people are building with Macruby to motivate more
people to start using it :)
Rgards,
Mark.
--
Mark Villacampa
Twitt
Hi Daniel,
I think that my earlier problems with macruby_deploy were due to a corrupted
Xcode project file. It finally became corrupted to the point where Xcode
wouldn't open it. After rebuilding it using the latest Macruby project
template, I had no problem submitting my app to the Mac App Sto
Oh, that's totally my fault. A recent change related to making MacRuby
installable to locations other than /Library/Frameworks. It has broken how the
nightly build script creates the installer package. I will try to have this
fixed for the next nightly build.
Thanks for the info,
Mark
Hi Mark,
Specifically, the current nightly build installer creates a sim link for
macruby_deploy in /usr/local/bin/ to
"/tmp/macruby-nightly/Library/Frameworks/MacRuby.framework/Versions/Current/usr/bin/macruby_deploy"
instead of an executable. I get "command not found" trying to run
macruby_d
Hi Bob,
Could you elaborate more on the first issue? That seems like a regression but I
didn't have that issue myself.
Also, could you please open it as a ticket on github?
The second issue I can confirm, but that code hasn't changed recently, so I
think that bug has been there for quite some t
Hi,
Seems that the recent nightly installs don't correctly install the
macruby_deploy and other executable tools. I had to back up to the 23rd.
Also, it seems that macruby_deploy only deletes the .rb file if the .rbo file
didn't already exist in the build directory. If both the .rb file and .rb
Hi Daniel,
I have an update. If I add the --no-stdlib argument along with the --embed,
then my archive passes validation but doesn't run. I only see an "Exited with
code: 1 error in the console log. Is there a way to get an error message to
determine only what I need from the framework?
Thanks
Hi guys,
I have no bundled anything for the app store myself, but I recall something
from earlier this year. The email thread can be found here:
http://lists.macosforge.org/pipermail/macruby-devel/2012-June/008841.html
HTH,
Mark
On 2012-09-20, at 3:50 PM, Robert Carl Rice wrote:
> H
Hi Daniel:
When I use the arguments:
--compile --codesign "3rd Party Mac Developer Application: Robert Rice"
I get an app bundle that runs and passes validation but then is rejected as an
"invalid binary" because the executable doesn't enable sandboxing.
When I add the embed argument:
--compile
Bob,
I've deployed to the App Store without issue. Are you using the --embed
argument for the Deployment target?
dw
On Thu, Sep 20, 2012 at 11:47 AM, Robert Carl Rice wrote:
> The silence is defening!
>
> Is anyone able to get a compiled and sandboxed MacRuby project accepted to
> the App Store
The silence is defening!
Is anyone able to get a compiled and sandboxed MacRuby project accepted to the
App Store?
If I understand how macruby_deploy works then it seems that it is trying to
duplicate a lot of work that Xcode does by post-processing an Xcode application
package. It also seems
Hi ,
I am trying to do "rails console" but get the same error of nokogiri.
AND I am getting the error same as in this post when I use otool.
What can I do to solve this problem ?
Thanks,
Bhavin
___
MacRuby-devel mailing list
MacRuby-devel@lists
Geez, I keep forgetting about other encodings…I would hope they already work,
but the tests will still have to be added/changed to cover those cases.
Both the issues that James brought up are fixed now, and I believe the code
dealing with them were the only parts of macruby_deploy to have been a
I would recommend spaces, punctation and even two-byte characters from asian
languages. People all over the world working in all different languages and
text systems will (hopefully) be using macruby. You've got to plane on not
having a standard character set.
On Jul 21, 2011, at 9:09 AM, Elo
Our test fixture app should probably include a space in the name so we can
ensure this doesn't happen anymore.
On 21 jul. 2011, at 11:37, James Chen wrote:
> Mark,
>
> I saw this is fixed on github. Installed the July 21 nightly build and tried
> again. Now it has another error on lipo:
>
>
Mark,
I saw this is fixed on github. Installed the July 21 nightly build and tried
again. Now it has another error on lipo:
$ macruby_deploy --compile --embed --stdlib --bs Gmail\ Notifr.app
*** Deployment started
*** Embedding MacRuby.framework
*** Embed BridgeSupport system files
*** Fix instal
Wow, that would be great! Thanks Mark.
James
On Thu, Jul 21, 2011 at 12:53 PM, Mark Rada wrote:
> Oopsie, I'll get that fixed in a few moments...unless it's fixed by the
> time I finish this email.
>
> Sent from my iDevice
>
> On 2011-07-20, at 23:30, James Chen wrote:
>
> Hey guys,
>
> I have
Oopsie, I'll get that fixed in a few moments...unless it's fixed by the time I
finish this email.
Sent from my iDevice
On 2011-07-20, at 23:30, James Chen wrote:
> Hey guys,
>
> I have an app with a space in the name. macruby_deploy fails to do its job:
>
>
> $ macruby_deploy --compile --e
Hey guys,
I have an app with a space in the name. macruby_deploy fails to do its job:
$ macruby_deploy --compile --embed --bs Gmail\ Notifr.app
*** Deployment started
*** Embedding MacRuby.framework
*** Embed BridgeSupport system files
*** Fix install path of binaries
*** Fix identification name
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
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
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,
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
I was able to fix this problem with the following script:
#!/bin/sh
APP="MyApp"
SOURCE_BUILD_DIR="build/Release"
TARGET_BUILD_DIR="build/Deploy"
LOCAL="$SOURCE_BUILD_DIR/$APP.app/"
REMOTE="$TARGET_BUILD_DIR/$APP.app/"
rsync --progress $* -avzut $LOCAL $REMOTE --exclude .DS_Store --copy-links
P
> Also, I am very interested in helping with a test suite for ruby_deploy as
> there are other changes I'd like to make to it; I was having a bit of
> difficulty getting started due to how ruby_deploy wants to load the compiler.
> Please let me know how I can help!
I’ve just pushed a spec for `
The parts of stdlib that are compiled are being included in the app bundle. The
list of which libs are compiled is in rakelib/builder.rake in the AOT_STDLIB
constant.
There is a bug though, because .rb files should be removed from the stdlib if a
.rbo equivalent is present.
I don't think that
Btw, do you really need the complete stdlib? If not, you can use the --stdlib
option to only keep those you really need. (see macruby_deploy --help)
On 5 mei 2011, at 13:27, Petr Kaleta wrote:
> Thanks for reply, that works. So after deploying, my whole application has
> about 45MB (zipped 12MB
Sounds good for me.
On May 5, 2011, at 4:25 PM, Eloy Duran wrote:
> Hmm, yes this is a problem. Maybe we should add separate options for
> compiling stdlib and gems and start keeping a list of libs known to not work
> well with AOT compilation which can then be excluded? I don't like adding
>
Hmm, yes this is a problem. Maybe we should add separate options for compiling
stdlib and gems and start keeping a list of libs known to not work well with
AOT compilation which can then be excluded? I don't like adding another option
so we could also compile everything with --compile, but this
I think Laurent and I were discussing some issues with the AOT compiling of
certain stdlib files causing problems. My specific case was from the RSS module.
https://www.macruby.org/trac/ticket/1020
On 5 May 2011, at 14:39, Eloy Duran wrote:
> Aha indeed! Yes we should definitely compile them im
Aha indeed! Yes we should definitely compile them imo. But I’m not
sure if there’s a good reason for excluding stdlib and gems from
compilation. The last time I tried there was no problem with compiling
it all. Can you change this in source/bin/ruby_deploy and see if your
app works good afterwards?
Yes, you said, that it compile all files from Resources directory, but gems are
embeded in Framework directory. So thats why, they are not compiled. Can be
STDLIB compiled as well?
- Petr
On May 5, 2011, at 2:34 PM, Eloy Duran wrote:
> No, that's not right. The embed code is run before the com
Here is sample application source code + archive
http://cl.ly/2m060z0t1C1B18442m33
Than I run:
env ARCHS='x86_64' macruby_deploy --compile --embed --gem rest-client --bs
MemoryTesting.app
Which produced this package http://cl.ly/3Y03050r3q1E0p1q453D In the package
contents there you can see,
No, that's not right. The embed code is run before the compile code
and the compile code uses the following to select all ruby files in
the Resources directory of the app bundle:
def compile_files
Dir.glob(File.join(app_resources, '**', '*.rb'))
end
It would be great if you can upload a s
I have just pushed a fix for this:
https://github.com/MacRuby/MacRuby/commit/82ab10ee484a14e4939b8b13c3f4f14fd1298955
Please try it out!
Hmm, I’ll have to dig deeper to see how the embedded gems are actually
loaded. My assumption was that rubygems would not be loaded at all,
which is usually the c
Now I am looking in the application package and embeded gems are not compiled.
And as you can see here http://cl.ly/240t0v3q2O221X3U113u some ruby files
compiled are, but there are source files as well. Embeded STDlib is not
compiled at all http://cl.ly/2d2D2R2L451m2C2x472J
Is this right?
On M
Thanks for reply, that works. So after deploying, my whole application has
about 45MB (zipped 12MB). My only question is, can I somehow speedup
application start? Now it takes about 10 seconds (loading gems & project files).
- Petr
On May 5, 2011, at 12:13 PM, Eloy Duran wrote:
> No it's not y
No it's not your fault, it seems the code assumes a ENV variable
that's set by Xcode. This is the offending code:
compile_options = { bundle: true, output: obj, files: [source] }
# Use Xcode ARCHS env var to determine which archs to compile for
compile_options[:archs] = ENV
Hi everyone, I'd like to deploy my Macruby app using:
macruby_deploy --compile --embed --gem rest-client --gem sequel --bs Issues.app
but I'm getting this error:
*** Deployment started
*** Embedding MacRuby.framework
*** Embed RubyGems libdirs:
/Library/Frameworks/MacRuby.framework/Versions/0.1
On Sun, Apr 17, 2011 at 9:56 PM, Laurent Sansonetti
wrote:
> 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.
Perfect - the fix works great. Thanks!
--
Nathaniel Talbott
<:((
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
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 decide
I'm now on master in order to get the BridgeSupport fix, but my
archived applications are erroring now due to a LOAD_PATH issue.
Basically, the embedded framework is in:
Elephant.app/Contents/Frameworks/MacRuby.framework/Versions/Current
But the LOAD_PATH for the app is now:
Elephant.app/C
MD5 hashes match. I am building my app on an encrypted disk image if that
would matter at all. I wouldn't think it would affect it.
My tester is on a 64bit machine. I'll try building it on 0.9 and see if
that helps.
Any idea why the directory size would be so dramatically different?
Kevin
On
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
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: Libr
Just wanted to report from the field that gem packaging in the new
macruby_deploy is working great. It really simplified our build scripts. For
reference:
PATH="$PATH:/usr/local/bin" macruby_deploy --embed
"$TARGET_BUILD_DIR/Redwood.app" --gem nokogiri --gem gdata_19 --compile
Thanks for this hug
Thanks Mark. Yeah, that's what I've got. Under Versions, Current is linked to
0.9 inside of which is:usr/lib/ruby/Gems1.9.2/
This has:
cache/ doc/ gems/ specifications/
So it looks like it should work
On Mar 1, 2011, at 18:57 , Russ McBride wrote:
>
> I've stopped fighting with gems and just gave into the new --gem option in
> macruby_deploy today. Alas, I'm fighting with gems again.
>
> My app, which I'm adding features to, btw, has been running quite nicely here
> at UC Berkeley to driv
macruby_deploy gets the rubygems source code to actually look up the gem.
You mentioned that you use RVM. Did you configure your GEM_PATH and GEM_HOME so
that they point to the non-RVM places or were you just making the directories
yourself?
Rubygems looks for its cache of gemspecs to find the g
oh, the command I'm using in my build script
PATH="$PATH:/usr/local/bin" macruby_deploy --gem action_mailer
--embed "$TARGET_BUILD_DIR/$PROJECT_NAME.app"
___
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosfo
I've stopped fighting with gems and just gave into the new --gem option in
macruby_deploy today. Alas, I'm fighting with gems again.
My app, which I'm adding features to, btw, has been running quite nicely here
at UC Berkeley to drive Selenium as a web app probing and monitoring device.
I'm g
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
54 matches
Mail list logo
