IRBConsole crashes in trunk, regression appeared in 6407 (probably)
---
Key: JRUBY-2368
URL: http://jira.codehaus.org/browse/JRUBY-2368
Project: JRuby
Issue Type: Bug
Hi Stephen,
Thanks for taking time to make a explanation of why the problem with naming and
co-existence. Things are clearer for me now.
Surely convincing the ruby developer world to add a "j" to all generated gem
tasks if running under jruby is a much bigger problem then just renaming the
bui
'ant spec' failures on on MacOS
---
Key: JRUBY-2369
URL: http://jira.codehaus.org/browse/JRUBY-2369
Project: JRuby
Issue Type: Bug
Components: Core Classes/Modules
Affects Versions: JRuby 1.1
M C wrote:
Hi Stephen,
Thanks for taking time to make a explanation of why the problem with naming and
co-existence. Things are clearer for me now.
Surely convincing the ruby developer world to add a "j" to all generated gem
tasks if running under jruby is a much bigger problem then just rena
Hi folks,
While we're at it, it seems that the new rubygems 1.1.0 is actually
installing 'jgem' binary under JRuby now, not "gem" :)
These are messages during upgrade to rubygems 1.1
install -c -m 0755 /tmp/gem /opt/work/jruby.git/bin/jgem
"If `gem` was installed by a previous RubyGems installati
On Sun, Apr 6, 2008 at 12:58 AM, Charles Oliver Nutter
<[EMAIL PROTECTED]> wrote:
> - We need to consider what version number we might want for
> JRuby.next...1.2? 2.0? Tom suggested 3.0 since it wouldn't confuse people
> about JRuby 2.0/Ruby 2.0. I think it's open for discussion.
I'd go with 1.
On Mon, Apr 7, 2008 at 8:22 AM, pat eyler <[EMAIL PROTECTED]> wrote:
> On Sun, Apr 6, 2008 at 12:58 AM, Charles Oliver Nutter
> <[EMAIL PROTECTED]> wrote:
> > - We need to consider what version number we might want for
> > JRuby.next...1.2? 2.0? Tom suggested 3.0 since it wouldn't confuse
> peopl
On Mon, Apr 7, 2008 at 8:25 AM, Dean Wampler <[EMAIL PROTECTED]> wrote:
>
> I think we should follow Java's example and use both "1.X" and "X"
> simultaneously. We should also use a random generator to arbitrarily insert
> one or the other in all documentation, emails, etc.
Mixing Roman and Arabic
M C wrote:
First of all congrats to the development team for releasing jruby 1.1!
Impressive work!!
I took a brief look at it yesterday and from a user perspective I have a
a few initial suggestions for 1.1.x in addition to the areas of Java
Integration and performance that you mention (which
Vladimir Sizikov wrote:
Hi folks,
While we're at it, it seems that the new rubygems 1.1.0 is actually
installing 'jgem' binary under JRuby now, not "gem" :)
These are messages during upgrade to rubygems 1.1
install -c -m 0755 /tmp/gem /opt/work/jruby.git/bin/jgem
"If `gem` was installed by a pr
Ola Bini wrote:
Good goals. I still believe that focused performance work on Rails is
still very much needed.
Absolutely...and with the release behind us (and 1.1.1 probably going
out the door in a week or two) we can really start to do that.
- Charlie
--
pat eyler wrote:
On Sun, Apr 6, 2008 at 12:58 AM, Charles Oliver Nutter
<[EMAIL PROTECTED]> wrote:
- We need to consider what version number we might want for
JRuby.next...1.2? 2.0? Tom suggested 3.0 since it wouldn't confuse people
about JRuby 2.0/Ruby 2.0. I think it's open for discussion.
Charles Oliver Nutter wrote:
pat eyler wrote:
On Sun, Apr 6, 2008 at 12:58 AM, Charles Oliver Nutter
<[EMAIL PROTECTED]> wrote:
- We need to consider what version number we might want for
JRuby.next...1.2? 2.0? Tom suggested 3.0 since it wouldn't confuse
people
about JRuby 2.0/Ruby 2.0. I th
Ola Bini wrote:
We can always do a repeated sequence out of the current releases. So
that means the next major release should be 2.1 (1.0 + 1.1), and the one
after that 3.2.
That way we will get really lovely and high version numbers quickly,
while avoiding the sticky 2.0
Nice...so in a few y
Charles Oliver Nutter wrote:
Ola Bini wrote:
We can always do a repeated sequence out of the current releases. So
that means the next major release should be 2.1 (1.0 + 1.1), and the
one after that 3.2.
That way we will get really lovely and high version numbers quickly,
while avoiding the sti
--- Den man 7/4/08 skrev Charles Oliver Nutter <[EMAIL PROTECTED]>:
> FYI, we're chasing this down on the RubyGems side and
> we'll get them to
> change it back to just "gem". JRuby shouldn't
> be the only impl forced to
> have a differently-named 'gem' script.
Seems like RubyGems are already do
JRuby startup time significantly slower than MRI
Key: JRUBY-2370
URL: http://jira.codehaus.org/browse/JRUBY-2370
Project: JRuby
Issue Type: Bug
Components: Performance
Affects Ve
src dist is not including Rakefile
--
Key: JRUBY-2371
URL: http://jira.codehaus.org/browse/JRUBY-2371
Project: JRuby
Issue Type: Bug
Components: Miscellaneous
Affects Versions: JRuby 1.1
Sample script java2.rb doesn't neccesarily open the correct file
Key: JRUBY-2372
URL: http://jira.codehaus.org/browse/JRUBY-2372
Project: JRuby
Issue Type: Bug
Compon
Charles' home folder is not primary location of jruby
-
Key: JRUBY-2373
URL: http://jira.codehaus.org/browse/JRUBY-2373
Project: JRuby
Issue Type: Bug
Components: Miscellaneous
20 matches
Mail list logo
