This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Summary: | Options for Binaries path not saved | ||
---|---|---|---|
Product: | ruby | Reporter: | sauvray <sauvray> |
Component: | Code | Assignee: | Torbjorn Norbye <tor> |
Status: | RESOLVED FIXED | ||
Severity: | blocker | ||
Priority: | P3 | ||
Version: | 6.x | ||
Hardware: | PC | ||
OS: | Windows XP | ||
Issue Type: | DEFECT | Exception Reporter: |
Description
sauvray
2007-02-23 15:24:09 UTC
Tested on Linux, Saves well but is ignored at the end (embedded rails used...) this works for me (but maybe i don't get the point); - go to Tools|Options|Ruby installation - change ruby interpret to e.g. /somefolder/ruby - change rails to e.g. /somefolder/rails - push OK - restart ide - I go to Tools|Options|Ruby installation -> settings are persistant NetBeans IDE Dev (Build 200702251900) 1.6.0; Java HotSpot(TM) Client VM 1.6.0-b105 Linux version 2.6.17-10-generic running on i386 cs_CZ (nb); UTF-8 + ruby from update center musilt2, As I said persistence works in Linux but not in Windows. And anyway even on Linux it is ignored. I just tried on Linux, and it worked for me. Here's the process I followed: Start NetBeans - create a Ruby project. JRuby is indexed. Open Tools | Options, modify the Ruby interpreter to "/usr/bin/ruby" (I at first made a mistake and changed only the path, so I had /usr/bin/jruby - that won't work). I also modified the rails binary to /usr/bin/rails/. I closed the dialog and exited the IDE. I verified that in my userdir, I had the following file: ~/.netbeans/dev/config/Preferences/org/netbeans/modules/ruby/project.properties It contained: % cat project.properties #Tue Feb 27 16:37:42 PST 2007 ruby=/usr/bin/ruby newApplicationCount=8 rails=/usr/bin/rails When I started the IDE, it proceeded to index /usr/lib/ruby/1.8 etc. To double check, after the indexing completed I did require 'i' and hit code completion with the caret after the i - I got the match require 'i486-linux/rbconfig' I ctrl-clicked on it and it warped into the rbconfig.rb file in my native Ruby installation under /usr/. Sauvray, can you try the above steps and see where your behavior is different from mine? I actually ran into a bug that I fixed: I recently added behavior that would also index Ruby code under site_ruby/. If you run the IDE with assertions on (which might be the case for all dev builds) this will assert if you installation does not have e.g. /usr/lib/ruby/site_ruby/. If you run into this assertion, either create the above directory, or get the latest version - I just checked in a fix. It should hit the update center within 24 hours. Alternatively, get a kit from http://deadlock.netbeans.org/hudson/ - those are updated almost immediately. Hi Tor, As I said since beginning, the problem of persistence would appear on Windows only. In Linux the options are persisted correctly (through the project.properties) and with today's NB snapshot together with updated Modules, the indexing takes it into account, so that's great! * Common Scripting Language API/Support 0.14.0/0.17.0.1.1.1.1.3 * Embedded Ruby 0.11.0, JRuby Implementation 0.92.4, Rake-Based Project Support 0.10.0, Ruby IDE Support 0.20.0, Ruby On Rails 1.1600.0, Ruby on Rails Project Support 0.16.0, Ruby Projects 0.17.0.1 So at the end I have the original bug that is still present with latest snapshots : Tools / Options | Miscellaneous / Ruby installation binaries path won't be saved under Windows. When I manually edit project.properties to point to my path, things go well! Thanks for reproducing this; it's interesting to know that the problem is related to the actual Preferences API calls. I really don't know why they wouldn't work on Windows - the code is pretty trivial. I'll have to investigate next time I'm near a Windows machine. At least there is a temporary workaround now; I'll add that to the wiki. Hi Tor, In fact the persistence on windows will work when you wait a bit before reopening the option dialog box. To reproduce : Open options : PATHA is set for option1, Set PATHB instead and Click OK and reopen immediately the options, you'll see PATHA is still there (as the cache didn't take into account your modification), then desperately you click OK again with PATHA which will remain then... I had a quick look at the code UpdateHelper... And it seems as if it's a problem of Synchronization (maybe the NetBeans ProjectManager Mutex or the way it is used or the way you cache configuration). It can be reproduced with any of the items from the Tools / Options | Miscellaneous, so the bug could be fixed by another transversal api team and not you except if it's a bad way way you're all using the api or caching ;) I would note that much the same is happening on OS X. I specified a different jruby installation, and it saved the correct values to ~/.netbeans/dev/config/Preferences/org/netbeans/modules/ruby/project.properties ~/.netbeans/dev/config/Preferences/org/netbeans/modules/ruby $ more project.properties #Sun Mar 11 07:48:26 CDT 2007 ruby=/Users/epowell/Development/jrubydev/jruby/bin/jruby rails=/Users/epowell/Development/jrubydev/jruby/bin/rails rdoc=/Users/epowell/Development/jrubydev/jruby/bin/rdoc rake=/Users/epowell/Development/jrubydev/jruby/bin/rake However, when I start up an irb session, it shows the Netbeans-default jruby paths: irb(main):001:0> $LOAD_PATH => ["/Users/epowell/.netbeans/dev/jruby-0.9.2/lib/ruby/site_ruby/1.8", "/Users/epowell/.netbeans/dev/jruby-0.9.2/lib/ruby/site_ruby", "/Users/epowell/.netbeans/dev/jruby-0.9.2/lib/ruby/1.8", "/Users/epowell/.netbeans/dev/jruby-0.9.2/lib/ruby/1.8/java", "lib/ruby/1.8", "."] The IRB console behaving this way is a slightly different issue. The IRB console is hardcoded to JRuby at the moment because it allowed nice readline integration (completion handling, command history, etc.). Launching external processes (which would be required for running other installations) wouldn't allow us to do this - the output window doesn't have integrated I/O etc - there's a separate text field for input (although this is hopefully going to be fixed for milestone 9 by issue #84375). With the rails console etc. I realize I'm going to have to change this soon. Regarding persistence/setting of ruby installations: I've just fixed various issues relating to running native ruby (including other versions than 1.8) so it should mostly work now. I'm not sure what's wrong with the persistence code here, but I'm going to replace it completely with a proper paltform chooser (ala the Java Platform manager). Reassigning this issue to newly created 'ruby' component. I have access to Windows now and I tried to reproduce it - but it worked for me. Is still a problem on your system? (The bug is nearly six months old now and a LOT has changed in the code so I'm hoping this is fixed.) Hi tor, Indeed, it's fixed since some month already. Sébastien. |