Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Package Truffle stdlib files into tarball #2466

Closed
nirvdrum opened this Issue Jan 16, 2015 · 6 comments

Comments

Projects
None yet
4 participants
@nirvdrum
Copy link
Contributor

nirvdrum commented Jan 16, 2015

Since Truffle has a long ways to go before being widely useful, we've whitelisted the standard libraries we think are okay to load. These are implemented by way of stubs in lib/ruby/truffle/mri and they basically do a require_relative back to the standard lib file in JRuby. The problem is these stubs aren't currently being packaged so anyone using the tarballs as the source for their installation can't use even the whitelisted libs.

@mkristian -- Any help you can provide with packaging would be much appreciated.

@mkristian

This comment has been minimized.

Copy link
Member

mkristian commented Jan 16, 2015

to add those files to jruby-stdlib jar is easy and with it goes to lla the
other distribution forms.

BUT is it really the way to go: pack those "all" included ?

as far as I understand truffle is optional, so if I do not want to use
truffle I want "truffle" free artifacts. using ruby scripting in a java
even if it is only "puts 'hello world'" means I need to add 20MB or more
extra libraries to get it working.

rather I would like specifiy a classifier "truffle" to get the truffle and
NOT get the stuff truffle replaces (as far I understand this that would be
IR). unfortunately maven does pick only another jar with the classifier and
not another pom.xml (which different dependencies). but it could be done in
a similar manner as 'jruby-noasm' which collects the jruby-core with the
right classifier.

I am not talking about jruby-dist which is anyways "all inclusive" ;)

so jruby should become more modular in the way it gets distributed.

On Fri, Jan 16, 2015 at 2:44 AM, Kevin Menard notifications@github.com
wrote:

Since Truffle has a long ways to go before being widely useful, we've
whitelisted the standard libraries we think are okay to load. These are
implemented by way of stubs in lib/ruby/truffle/mri and they basically do a
require_relative back to the standard lib file in JRuby. The problem is
these stubs aren't currently being packaged so anyone using the tarballs as
the source for their installation can't use even the whitelisted libs.

@mkristian https://github.com/mkristian -- Any help you can provide
with packaging would be much appreciated.


Reply to this email directly or view it on GitHub
#2466.

@nirvdrum

This comment has been minimized.

Copy link
Contributor Author

nirvdrum commented Jan 16, 2015

dist is the problem. ruby-build uses the nightly tarballs (and the versioned ones upon release) for installation. They currently don't include everything needed to run Truffle-backed JRuby.

@chrisseaton chrisseaton referenced this issue Jan 16, 2015

Closed

Release 9k Preview #2445

4 of 4 tasks complete
@chrisseaton

This comment has been minimized.

Copy link
Contributor

chrisseaton commented Jan 16, 2015

We're working on some ideas to reduce the size of the Truffle code (it's generated code, so we're improving the generator), so it may not be quite as bad as 20MB. I'll let you know as we experiment.

As you say, jruby-dist (the binary tarballs, right?) and JRuby complete I think should include all backends, and I think that's always the way it's been understood to work. Truffle's a runtime configuration option, not an entirely separate product.

We're happy to work with you on some finer grained packaging as well. Personally, I don't see the issue as it's only a few MB and we don't have separate packages for indy and non-indy, but if you know of use cases I'll trust your judgement on that. Let us know if you need us to help. It's already possible to remove Truffle by brute force deleting the classfiles from the jar and users will get a nice error message.

Do we need to do anything to help you get our stdlib into the tarballs and complete?

@mkristian

This comment has been minimized.

Copy link
Member

mkristian commented Jan 16, 2015

just give me time until tomorrow and then there will be the truffle stuff
included. just do not want to push things and then go to bed without being
to fix the build in case I break it.

maybe my wish to modularize it is not so important, but it is already half
way: remove Truffle by brute force deleting the classfiles from the jar =>
just put it into two jars.

On Fri, Jan 16, 2015 at 10:59 PM, Chris Seaton notifications@github.com
wrote:

We're working on some ideas to reduce the size of the Truffle code (it's
generated code, so we're improving the generator), so it may not be quite
as bad as 20MB. I'll let you know as we experiment.

As you say, jruby-dist (the binary tarballs, right?) and JRuby complete I
think should include all backends, and I think that's always the way it's
been understood to work. Truffle's a runtime configuration option, not an
entirely separate product.

We're happy to work with you on some finer grained packaging as well.
Personally, I don't see the issue as it's only a few MB and we don't have
separate packages for indy and non-indy, but if you know of use cases I'll
trust your judgement on that. Let us know if you need us to help. It's
already possible to remove Truffle by brute force deleting the classfiles
from the jar and users will get a nice error message.

Do we need to do anything to help you get our stdlib into the tarballs and
complete?


Reply to this email directly or view it on GitHub
#2466 (comment).

@enebo

This comment has been minimized.

Copy link
Member

enebo commented Jan 16, 2015

The other thing to consider if that Ruboto needs to be able to not include Truffle due to size being much more important. They are doing this outside our build processes but it is still worth mentioning.

@chrisseaton

This comment has been minimized.

Copy link
Contributor

chrisseaton commented Jan 16, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.