Re: Using a workspace-based VM in Eclipse
Hi, On 22 Dec 2005 12:34:42 -0700, Tom Tromey <[EMAIL PROTECTED]> wrote: > To do this, follow the wiki instructions to check out and build > Classpath and Cacao (as always, this VM is chosen because all the > needed build bits are in its cvs repository... hint to the other VM > developers). > Hint taken. The necessary files are now in JamVM's cvs repository. This is your patch with a couple of changes by Raif that adds the .cvsignore files and adds an Autogen Builder to create, among other things, the configure script. Rob. > Once that is done, check out the fakejdk project from > :pserver:[EMAIL PROTECTED]:/cvs/rhug, module 'fakejdk'. > (This ought to auto-build, but if not, apply the usual Clean hack.) > This just makes a little project consisting of symlinks -- it is a > huge hack. > > Now, go to Window->Preferences->Java->Installed JREs and choose > 'Add...' to add a new one. I named mine "Cacao". For the JRE home > directory, choose $workspace/fakejdk. Then turn off "Use default > system libraries" and you can edit the Source attachment of the new > JRE to point to the classpath directory in the workspace. > > Once this is done you can pick this JRE for launchers, or to build > other projects against. This is nice because it means these projects > don't have to necessarily depend on Classpath -- there is a layer of > indirection, so you can build and run them against the system VM if > you prefer to do that, without modifying the shared build setup. > > Tom ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Using a workspace-based VM in Eclipse
>> Anyway, commit that if you like. You have rhug access, right? Mark> No I don't think I have rhug access. You do now :-) Mark> It looks like the native side gets rebuild a lot though. I guess there Mark> are some dependencies wrong since I seem to trigger a full rebuild of Mark> cacao a lot when running mauve for example. I've seen similar things on occasion. We probably need to track them down more precisely and turn them into Eclipse PRs. The external builder support seems to leave a few things to be desired... Tom ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Using a workspace-based VM in Eclipse
Hi Tom, On Thu, 2005-12-22 at 15:53 -0700, Tom Tromey wrote: > Yeah, that one is super bogus. And, I think, not actually needed. > > Anyway, commit that if you like. You have rhug access, right? No I don't think I have rhug access. > Mark> Strangely the attach source step didn't work. I always get: > Mark> Assertion failed; Path for IClasspathEntry must be absolute > > Hmm. Did you choose Workspace... when specifying the source path? I > did... anyway, check your .log, maybe this is a bug somewhere. It happens before that. When hitting the Edit... button. I worked around it by just removing the rt.jar and readding it by hand. Then I can Edit and attach source for the classpath workspace. > Mark> Wow! That is really nice. It seems to work instantly. Edit the project > Mark> or edit classpath and on a rerun your changes are there :) > > Yup, this is why I think Eclipse is the easiest way to develop > Classpath. At least, that is true for the Java side of things. For > the native code the traditional tools are probably still in the lead. It looks like the native side gets rebuild a lot though. I guess there are some dependencies wrong since I seem to trigger a full rebuild of cacao a lot when running mauve for example. Cheers, Mark signature.asc Description: This is a digitally signed message part ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Using a workspace-based VM in Eclipse
Mark> One of the symlinks didn't work for me. Attached is a patch for the Mark> tools.jar to try and find it in some other location. Generated by Mark> eclipse of course :) Yeah, that one is super bogus. And, I think, not actually needed. Anyway, commit that if you like. You have rhug access, right? Mark> Strangely the attach source step didn't work. I always get: Mark> Assertion failed; Path for IClasspathEntry must be absolute Hmm. Did you choose Workspace... when specifying the source path? I did... anyway, check your .log, maybe this is a bug somewhere. Mark> Wow! That is really nice. It seems to work instantly. Edit the project Mark> or edit classpath and on a rerun your changes are there :) Yup, this is why I think Eclipse is the easiest way to develop Classpath. At least, that is true for the Java side of things. For the native code the traditional tools are probably still in the lead. Tom ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Using a workspace-based VM in Eclipse
Hi Tom, On Thu, 2005-12-22 at 12:34 -0700, Tom Tromey wrote: > Once that is done, check out the fakejdk project from > :pserver:[EMAIL PROTECTED]:/cvs/rhug, module 'fakejdk'. > (This ought to auto-build, but if not, apply the usual Clean hack.) > This just makes a little project consisting of symlinks -- it is a > huge hack. One of the symlinks didn't work for me. Attached is a patch for the tools.jar to try and find it in some other location. Generated by eclipse of course :) > Now, go to Window->Preferences->Java->Installed JREs and choose > 'Add...' to add a new one. I named mine "Cacao". For the JRE home > directory, choose $workspace/fakejdk. Then turn off "Use default > system libraries" and you can edit the Source attachment of the new > JRE to point to the classpath directory in the workspace. Strangely the attach source step didn't work. I always get: Assertion failed; Path for IClasspathEntry must be absolute > Once this is done you can pick this JRE for launchers, or to build > other projects against. This is nice because it means these projects > don't have to necessarily depend on Classpath -- there is a layer of > indirection, so you can build and run them against the system VM if > you prefer to do that, without modifying the shared build setup. Wow! That is really nice. It seems to work instantly. Edit the project or edit classpath and on a rerun your changes are there :) Thanks, Mark Index: build === RCS file: /cvs/rhug/fakejdk/build,v retrieving revision 1.1 diff -u -r1.1 build --- build 22 Dec 2005 19:01:09 - 1.1 +++ build 22 Dec 2005 22:51:40 - @@ -38,7 +38,13 @@ cd $top/lib # FIXME: tools.jar # We have to merge with java-gcj-compat. -cp /usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/lib/tools.jar tools.jar +if test -f /usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/lib/tools.jar; then + cp /usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/lib/tools.jar tools.jar +elif test -f /usr/lib/jvm/java-1.4.2-gcj-4.0-1.4.2.0/lib/tools.jar; then + cp /usr/lib/jvm/java-1.4.2-gcj-4.0-1.4.2.0/lib/tools.jar tools.jar +else + cp /usr/lib/jvm/java-*-gcj-*/lib/tools.jar tools.jar +fi cd $top/jre/bin ln -s $classpath/install/bin/$vm java signature.asc Description: This is a digitally signed message part ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Using a workspace-based VM in Eclipse
I've checked in the Eclipse jar builder to Classpath head, and now my fakejdk project is available. This means you can easily start playing with an in-workspace VM in Eclipse. To do this, follow the wiki instructions to check out and build Classpath and Cacao (as always, this VM is chosen because all the needed build bits are in its cvs repository... hint to the other VM developers). Once that is done, check out the fakejdk project from :pserver:[EMAIL PROTECTED]:/cvs/rhug, module 'fakejdk'. (This ought to auto-build, but if not, apply the usual Clean hack.) This just makes a little project consisting of symlinks -- it is a huge hack. Now, go to Window->Preferences->Java->Installed JREs and choose 'Add...' to add a new one. I named mine "Cacao". For the JRE home directory, choose $workspace/fakejdk. Then turn off "Use default system libraries" and you can edit the Source attachment of the new JRE to point to the classpath directory in the workspace. Once this is done you can pick this JRE for launchers, or to build other projects against. This is nice because it means these projects don't have to necessarily depend on Classpath -- there is a layer of indirection, so you can build and run them against the system VM if you prefer to do that, without modifying the shared build setup. Tom ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Hacking Classpath in Eclipse
> "Tom" == Tom Tromey <[EMAIL PROTECTED]> writes: Tom> My current fake jdk here just makes a bunch of symlinks and then Tom> builds a .jar. But I'm considering moving the jar-making step into Tom> Classpath and having it run in the background... I'll try to play with Tom> this soon. I tried this out and it seems to work great. The key is to make the jar builder run in the background. At least, with my basic testing, this doesn't result in a noticeable build performance drop. I'll check in my fake jdk project to the rhug cvs soon. Tom ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
clarification: java.swing.text.NumberFormatter
Hi, I should point out that java.swing.text.NumberFormatter's stringToValue function is actually its parent class's stringToValue function (java.swing.text.InternationalFormatter), and all of the comments about NumberFormatter's stringToValue function are actually about InternationalFormatter's stringToValue function -- I just forgot which file I was looking at when I wrote my previous email. All of the substantive stuff still holds. Though i did notice that the third option is actually going to be have NumberFormatter sets valueClass to be Double, not Number, since Double can actually be instantiated and has a constructor which takes a string. Thanks, Chris Lansdown -- "Let us endeavor so to live that when we come to die even the undertaker will be sorry." -- Mark Twain, "Pudd'nhead Wilson's Calendar" == Evil Overlord Quote of the Day (www.eviloverlord.com) = 214. If a malignant being demands a sacrificial victim have a particular quality, I will check to make sure said victim has this quality immediately before the sacrifice and not rely on earlier results. (Especially if the quality is virginity and the victim is the hero's girlfriend.) ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
java.swing.text.NumberFormatter
Hi, NumberFormatter's stringToValue function currently checks to see if the valueClass is not null, and if so, converts its value to that. The problem is that valueClass gets set in java.swing.text.DefaultFormatter's constructor sets valueClass to be Object.class, so the lines: if (valueClass != null) o = super.stringToValue(o.toString()); have the effect of always setting the returned value to a String, even though NumberFormatter properly converts the thing to a number first. Two alternative fixes would be to get rid of the always setting valueClass in DefaultFormatter's constructor (I have no idea what the implications of this are), and changing the condition to: if(valueClass != null && valueClass != Object.class) etc. Since there's no sense in trying to cast something up to an object anyhow. Alternatively, maybe the constructor of NumberFormat should set the valueClass to Number? Thanks, Chris Lansdown -- "Let us endeavor so to live that when we come to die even the undertaker will be sorry." -- Mark Twain, "Pudd'nhead Wilson's Calendar" == Evil Overlord Quote of the Day (www.eviloverlord.com) = 214. If a malignant being demands a sacrificial victim have a particular quality, I will check to make sure said victim has this quality immediately before the sacrifice and not rely on earlier results. (Especially if the quality is virginity and the victim is the hero's girlfriend.) ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Hacking Classpath in Eclipse
On Thu, 2005-12-22 at 09:05 -0700, Tom Tromey wrote: > Tom> This is an example of why it would be very useful to make Classpath > Tom> fully bootstrappable by merging e.g. cp-tools, gjdoc, gij and gcjx into > Tom> the Classpath repository/build system. Long term I guess this is where > Tom> we're headed but this is just another data point that we're going in the > Tom> right direction. > > For Eclipse-based builds we really don't want all of this; in > particular we don't want or need a compiler here. Using the built-in > Eclipse compiler is superior. > > >> Ideally Eclipse would offer the possibility of auto-exporting the > >> build results as a .jar. That would solve this entirely. > > Tom> Yes, I've wanted that in several other situations. Let's file an > Tom> enhancement bug with Eclipse. > > Are you filing it? If so tell me the PR and I will add myself. https://bugs.eclipse.org/bugs/show_bug.cgi?id=121901 Tom ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
[Bug swing/25517] JFormattedTextField doesn't fire ActionEvent when VK_ENTER is hit
--- Comment #2 from cvs-commit at developer dot classpath dot org 2005-12-22 16:53 --- Subject: Bug 25517 CVSROOT:/cvsroot/classpath Module name:classpath Branch: Changes by: Lillian Angel <[EMAIL PROTECTED]> 05/12/22 15:36:39 Modified files: . : ChangeLog javax/swing/plaf/basic: BasicLookAndFeel.java BasicTextUI.java Log message: 2005-12-21 Lillian Angel <[EMAIL PROTECTED]> PR classpath/25517 * javax/swing/plaf/basic/BasicLookAndFeel.java (initComponentDefaults): Added focus map for FormattedTextField. Mauve test updated for this. * javax/swing/plaf/basic/BasicTextUI.java (createKeyMap): Fixed to get key bindings from the input map. There is not .keyBindings default in BasicL&F (same with the JDK). (installKeyBoardActions): Removed unneeded code. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/classpath/classpath/ChangeLog.diff?tr1=1.5882&tr2=1.5883&r1=text&r2=text http://cvs.savannah.gnu.org/viewcvs/classpath/classpath/javax/swing/plaf/basic/BasicLookAndFeel.java.diff?tr1=1.76&tr2=1.77&r1=text&r2=text http://cvs.savannah.gnu.org/viewcvs/classpath/classpath/javax/swing/plaf/basic/BasicTextUI.java.diff?tr1=1.60&tr2=1.61&r1=text&r2=text -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25517 ___ Bug-classpath mailing list Bug-classpath@gnu.org http://lists.gnu.org/mailman/listinfo/bug-classpath
Re: Hacking Classpath in Eclipse
Tom> This is an example of why it would be very useful to make Classpath Tom> fully bootstrappable by merging e.g. cp-tools, gjdoc, gij and gcjx into Tom> the Classpath repository/build system. Long term I guess this is where Tom> we're headed but this is just another data point that we're going in the Tom> right direction. For Eclipse-based builds we really don't want all of this; in particular we don't want or need a compiler here. Using the built-in Eclipse compiler is superior. >> Ideally Eclipse would offer the possibility of auto-exporting the >> build results as a .jar. That would solve this entirely. Tom> Yes, I've wanted that in several other situations. Let's file an Tom> enhancement bug with Eclipse. Are you filing it? If so tell me the PR and I will add myself. Tom ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Hacking Classpath in Eclipse
> "Mark" == Mark Wielaard <[EMAIL PROTECTED]> writes: >> Ideally Eclipse would offer the possibility of auto-exporting the >> build results as a .jar. That would solve this entirely. Mark> Wouldn't it be enough if we could convince eclipse to accept a Mark> "hand-made jre"? I mean one where you can you explicitly set the Mark> individual binaries that make up the tools that eclipse expects? Plus Mark> convincing the built-in eclipse compiler to use a flat (non-jar/zip) Mark> bootclasspath? Yeah, this approach would work as well. I've been mostly looking for a quick hack, since I don't want to spend a lot of time on this. Eclipse won't let you set up a standard vm whose boot class path is a directory, I tried that. I wonder if a 'glibj.jar -> .' symlink would work :-). (Doubtful) My current fake jdk here just makes a bunch of symlinks and then builds a .jar. But I'm considering moving the jar-making step into Classpath and having it run in the background... I'll try to play with this soon. I can send the symlink script if you want it, it is just the dumb/obvious thing. Mark> If you take a quick look at Mark> org/eclipse/jdt/internal/launching/StandardVMType.java it looks like Mark> this class just needs a set of setters and a way to override that auto Mark> detection. Or maybe we need a new subclass of AbstractVMType that Mark> creates an IVMInstall just based on user defined locations that can be Mark> plugged into the standard JRE preferences dialog as override to the Mark> autodetecting StandardVMType? Yeah, I looked at this a little. There is an extension point for this (org.eclipse.jdt.launching.vmInstallTypes) so you can make your own plugin that provides a new type of VM. It is unclear whether this can use a flat install (but maybe the problem is the documentation and not the code -- I didn't try). Tom ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Security manager problem
Hi Mark,
Thanks for your quick reply, and apologies for my egregiously slow
one...
Mark Wielaard wrote:
> On Mon, 2005-12-12 at 17:55 +, Gary Benson wrote:
> > Gary Benson wrote:
> > > Robert Lougher wrote:
> > > > Do you have a testcase?
> > >
> > > If you build and run the attached testcase you ought to see
> > > only one checkPermission() between "Calling checkRead()" and
> > > "Done". ... In reality, JamVM chokes on it pretty hard. I
> > > _think_ what is happening is that the System.out.println in
> > > checkPermission() is itself doing some initialisation which
> > > causes security checks, causing an infinite loop.
> >
> > The initialisation in question turns out to be:
> >
> > 1. Loading java.lang.StringBuffer to build the message.
> > 2. Loading java.io.PrintStream to print it out.
> > 3. Converting the message to bytes using String.getBytes(encoding).
> >
> > Any one of them will trigger a security check and hence an infinite
> > loop.
>
> Aha! There is your clue. libgcj hasn't merged in the new nio charset
> provider setup. And indeed creating a new CharsetProvider requires a
> RuntimePermission("charsetProvider"). Even for creating the default
> provider. Which obviously should always be created, otherwise
> nothing works. It is safe in this case since we know the default
> provider doesn't do nasty things (or at least we hope so). So you
> need the attached patch to gnu/java/nio/charset/Provider.java.
Works perfectly, thanks.
> But even then you need some more workaround.
[snip]
>
> All this seems to come from having a user defined security
> manager loaded by a user defined class loader (the default
> System/Application class loader). We need to do ClassLoader.
> loadClass() checks in that case. But as shown in this example
> that leads very easily to recursive checkPermission() calls.
>
> I don't have a good idea how to make this easier. Any ideas?
Not really. It'd be interesting to see how other JVMs handle this,
but I doubt it matters much as extending SecurityManager isn't really
necessary these days.
Cheers (and Merry Christmas!)
Gary
___
Classpath mailing list
Classpath@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath
Re: Hacking Classpath in Eclipse
On Wed, 2005-12-21 at 19:21 -0700, Tom Tromey wrote: > > "Mark" == Mark Wielaard <[EMAIL PROTECTED]> writes: > > Mark> I found a cute hack to actually run a single mauve Testlet from within > Mark> eclipse using the just compiled classpath: > > Mark> $ mkdir -p ~/workspace/classpath/install/jre/lib > Mark> $ touch ~/workspace/classpath/install/jre/lib/rt.jar > > Mark> Now as by magic you can add ~/workspace/classpath/install as JRE to > Mark> eclipse (under Preferences -> Java -> JREs) and then configure Runners > Mark> to use that alternative jre. > > Note that this will work for running something, but not if you want > to compile against that JRE. > > For the latter I think we need to come up with some kind of "fake jdk" > project. I actually have the start of one here, but I haven't > finished polishing it yet. This is an example of why it would be very useful to make Classpath fully bootstrappable by merging e.g. cp-tools, gjdoc, gij and gcjx into the Classpath repository/build system. Long term I guess this is where we're headed but this is just another data point that we're going in the right direction. > > Ideally Eclipse would offer the possibility of auto-exporting the > build results as a .jar. That would solve this entirely. Yes, I've wanted that in several other situations. Let's file an enhancement bug with Eclipse. Tom ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Hacking Classpath in Eclipse
On 12/22/05, Mark Wielaard <[EMAIL PROTECTED]> wrote: > Wouldn't it be enough if we could convince eclipse to accept a > "hand-made jre"? I mean one where you can you explicitly set the > individual binaries that make up the tools that eclipse expects? Plus > convincing the built-in eclipse compiler to use a flat (non-jar/zip) > bootclasspath? (I believe ecj can use dirs already, but haven't > checked.) Yeah, I had the same thought, but not time yet to investigate a way to patch Eclipse, so that you can specify more details. It's definitely on my TODO list. Stephan Michels. ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Hacking Classpath in Eclipse
Hi, On Wed, 2005-12-21 at 19:21 -0700, Tom Tromey wrote: > Note that this will work for running something, but not if you want > to compile against that JRE. > > For the latter I think we need to come up with some kind of "fake jdk" > project. I actually have the start of one here, but I haven't > finished polishing it yet. > > Ideally Eclipse would offer the possibility of auto-exporting the > build results as a .jar. That would solve this entirely. Wouldn't it be enough if we could convince eclipse to accept a "hand-made jre"? I mean one where you can you explicitly set the individual binaries that make up the tools that eclipse expects? Plus convincing the built-in eclipse compiler to use a flat (non-jar/zip) bootclasspath? (I believe ecj can use dirs already, but haven't checked.) It feels like eclipse is just trying to be too clever in its "jre detection". Maybe if the "JRE definitions" preference box had an "override - I know what I am doing" box, so you could fill in the individual parts that make up the "StandardVMType" thing. If you take a quick look at org/eclipse/jdt/internal/launching/StandardVMType.java it looks like this class just needs a set of setters and a way to override that auto detection. Or maybe we need a new subclass of AbstractVMType that creates an IVMInstall just based on user defined locations that can be plugged into the standard JRE preferences dialog as override to the autodetecting StandardVMType? Cheers, Mark signature.asc Description: This is a digitally signed message part ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
