sablevm-developer — SableVM developer mailing list

Re: [Sablevm-developer] Re: Running Ant? - update

[Prof. E. M. G. <eti...@uq...>]

Archie Cobbs wrote:
> 
> Along these lines, below are some patches I submitted to Classpath
> (against their version 0.05) for implementing several reflection
> methods non-natively instead of natively and relying on fewer native
> methods.

Hi Archie,

Would you be interested in getting CVS write access?  I assume you have 
clean-room status, own your code, and agree to license it appropriately?

[For SableVM-specific code, I ask that you license it under SableVM's license 
(LGPL), and that you keep ownership of the Copyright on your contributions.  I 
additionally ask you to to grant me permission to make minor modifications to 
the license terms (add an exception, for example), in case a problem is found 
later that would prevent SableVM achieve its objectives, including:
1- Remaining Free, yet also
2- Be usable to run non-Free programs.

I don't think using such an exception will be necessary, as the GNU LGPL already 
  seems to achieve this goal, but some people think that using SableVM in the 
embedded world could require some special exception].

Also, as this is part of the class library, I ask of SableVM developers making 
significant changes in that part to fill out the FSF papers to assign their 
modifications to Classpath back to the FSF (as I will merge all these changes 
into Classpath CVS at an appropriate time).

It also simplifies the maintenance of file headers: no need to add the names of 
additional copyright holders (other than the FSF) in class-library files.

Maybe you already have signed the FSF papers?  [If not, I am sure Classpath 
people will ask you for it before committing any substantial patch of yours; FSF 
policy].

Etienne

-- 
Etienne M. Gagnon, Ph.D.             http://www.info.uqam.ca/~egagnon/
SableVM:                                       http://www.sablevm.org/
SableCC:                                       http://www.sablecc.org/

Re: [Sablevm-developer] Re: Running Ant? - update

[Archie C. <ar...@de...>]

Prof. Etienne M. Gagnon wrote:
> I hereby make a call for help to all SableVM deleopers: Your help
> would be highly appreciated for completing the implementation of
> reflection in SableVM.  If you follow my example and try to do a
> maximum of things in Java and only make native calls when abolutely
> necessary, then it would be an excellent exercise for you to start
> working on SableVM, and test your understanding of the internal
> organization of the VM.

Along these lines, below are some patches I submitted to Classpath
(against their version 0.05) for implementing several reflection
methods non-natively instead of natively and relying on fewer native
methods.

Hopefully these will get into Classpath soon, so perhaps they would
come for free in a future upgrade of SableVM's Classpath classes.

-Archie

__________________________________________________________________________
Archie Cobbs     *     Precision I/O      *     http://www.precisionio.com

diff -ur -x cvs classpath-0.05/vm/reference/java/lang/Class.java java/lang/Class.java
--- classpath-0.05/vm/reference/java/lang/Class.java	Sat Oct 26 11:41:59 2002
+++ java/lang/Class.java	Wed Mar 12 16:02:58 2003
@@ -42,11 +42,14 @@
 import java.lang.reflect.Constructor;
 import java.lang.reflect.Field;
 import java.lang.reflect.InvocationTargetException;
+import java.lang.reflect.Member;
 import java.lang.reflect.Method;
 import java.net.URL;
 import java.security.AllPermission;
 import java.security.Permissions;
 import java.security.ProtectionDomain;
+import java.util.ArrayList;
+import java.util.Arrays;
 import gnu.java.lang.ClassHelper;
 
 /*
@@ -137,15 +146,10 @@
    * @throws ExceptionInInitializerError if the class loads, but an exception
    *         occurs during initialization
    */
-  //XXX This does not need to be native.
-  public static native Class forName(String name)
-    throws ClassNotFoundException;
-  /*
+  public static Class forName(String name) throws ClassNotFoundException
   {
-    return forName(name, true,
-                   VMSecurityManager.getClassContext()[1].getClassLoader());
+    return forName(name, true, VMSecurityManager.currentClassLoader());
   }
-  */
 
   /**
    * Use the specified classloader to load and link a class. If the loader
@@ -313,7 +317,7 @@
    * void                V
    * array type          [<em>element type</em>
    * class or interface, alone: &lt;dotted name&gt;
-   * class or interface, as element type: L&lt;dotten name&gt;;
+   * class or interface, as element type: L&lt;dotted name&gt;;
    *
    * @return the name of this class
    */
@@ -400,46 +404,7 @@
    * @see Array
    * @since 1.1
    */
-  public Class getComponentType()
-  {
-    if (isArray())
-      try
-        {
-          String name = getName();
-          switch (name.charAt(1))
-            {
-            case 'B':
-              return byte.class;
-            case 'C':
-              return char.class;
-            case 'D':
-              return double.class;
-            case 'F':
-              return float.class;
-            case 'I':
-              return int.class;
-            case 'J':
-              return long.class;
-            case 'S':
-              return short.class;
-            case 'Z':
-              return boolean.class;
-            default:
-              return null;
-            case '[':
-              name = name.substring(1);
-              break;
-            case 'L':
-              name = name.substring(2, name.length() - 1);
-            }
-          return Class.forName(name, false, getClassLoader());
-        }
-      catch(ClassNotFoundException e)
-        {
-          // Shouldn't happen, but ignore it anyway.
-        }
-    return null;
-  }
+  public native Class getComponentType();
 
   /**
    * Get the modifiers of this class.  These can be decoded using Modifier,
@@ -478,6 +443,20 @@
   }
 
   /**
+   * Perform security checks common to all of the methods that
+   * get members of this Class.
+   */
+  private void memberAccessCheck(int which) {
+    SecurityManager sm = System.getSecurityManager();
+    if (sm != null) {
+      sm.checkMemberAccess(this, which);
+      Package pkg = getPackage();
+      if (pkg != null)
+	sm.checkPackageAccess(pkg.getName());
+    }
+  }
+
+  /**
    * If this is a nested or inner class, return the class that declared it.
    * If not, return null.
    *
@@ -498,7 +477,22 @@
    * @throws SecurityException if the security check fails
    * @since 1.1
    */
-  public native Class[] getClasses();
+  public Class[] getClasses() {
+    memberAccessCheck(Member.PUBLIC);
+    return internalGetClasses();
+  }
+
+  /**
+   * Like <code>getClasses()</code> but without the security checks.
+   */
+  private Class[] internalGetClasses() {
+    ArrayList list = new ArrayList();
+    list.add(Arrays.asList(nativeGetDeclaredClasses(true)));
+    Class superClass = getSuperclass();
+    if (superClass != null)
+      list.add(Arrays.asList(superClass.internalGetClasses()));
+    return (Class[])list.toArray(new Class[list.size()]);
+  }
 
   /**
    * Get all the public fields declared in this class or inherited from
@@ -512,7 +506,28 @@
    * @throws SecurityException if the security check fails
    * @since 1.1
    */
-  public native Field[] getFields();
+  public Field[] getFields() {
+    memberAccessCheck(Member.PUBLIC);
+    return internalGetFields();
+  }
+
+  /**
+   * Like <code>getFields()</code> but without the security checks.
+   */
+  private Field[] internalGetFields() {
+    ArrayList list = new ArrayList();
+    list.add(Arrays.asList(nativeGetDeclaredFields(true)));
+    if (isInterface()) {
+      Class[] interfaces = getInterfaces();
+      for (int i = 0; i < interfaces.length; i++)
+	list.add(Arrays.asList(interfaces[i].internalGetFields()));
+    } else {
+      Class superClass = getSuperclass();
+      if (superClass != null)
+	list.add(Arrays.asList(superClass.internalGetFields()));
+    }
+    return (Field[])list.toArray(new Field[list.size()]);
+  }
 
   /**
    * Get all the public methods declared in this class or inherited from
@@ -530,7 +545,25 @@
    * @throws SecurityException if the security check fails
    * @since 1.1
    */
-  public native Method[] getMethods();
+  public Method[] getMethods() {
+    memberAccessCheck(Member.PUBLIC);
+    return internalGetMethods();
+  }
+
+  /**
+   * Like <code>getMethods()</code> but without the security checks.
+   */
+  private Method[] internalGetMethods() {
+    ArrayList list = new ArrayList();
+    list.add(Arrays.asList(nativeGetDeclaredMethods(true)));
+    Class[] interfaces = getInterfaces();
+    for (int i = 0; i < interfaces.length; i++)
+      list.add(Arrays.asList(interfaces[i].internalGetMethods()));
+    Class superClass = getSuperclass();
+    if (superClass != null)
+      list.add(Arrays.asList(superClass.internalGetMethods()));
+    return (Method[])list.toArray(new Method[list.size()]);
+  }
 
   /**
    * Get all the public constructors of this class. This returns an array of
@@ -544,7 +577,10 @@
    * @throws SecurityException if the security check fails
    * @since 1.1
    */
-  public native Constructor[] getConstructors();
+  public Constructor[] getConstructors() {
+    memberAccessCheck(Member.PUBLIC);
+    return nativeGetDeclaredConstructors(true);
+  }
 
   /**
    * Get a public field declared or inherited in this class, where name is
@@ -561,7 +597,26 @@
    * @see #getFields()
    * @since 1.1
    */
-  public native Field getField(String name) throws NoSuchFieldException;
+  public Field getField(String name) throws NoSuchFieldException {
+    memberAccessCheck(Member.PUBLIC);
+    Field[] fields = nativeGetDeclaredFields(true);
+    for (int i = 0; i < fields.length; i++) {
+      Field field = fields[i];
+      if (field.getName().equals(name))
+	return field;
+    }
+    Class[] interfaces = getInterfaces();
+    for (int i = 0; i < interfaces.length; i++) {
+      try {
+	return interfaces[i].getField(name);
+      } catch (NoSuchFieldException e) {
+      }
+    }
+    Class superclass = getSuperclass();
+    if (superclass != null)
+      return superclass.getField(name);
+    throw new NoSuchFieldException();
+  }
 
   /**
    * Get a public method declared or inherited in this class, where name is
@@ -585,8 +640,62 @@
    * @see #getMethods()
    * @since 1.1
    */
-   public native Method getMethod(String name, Class[] args)
-     throws NoSuchMethodException;
+  public Method getMethod(String name, Class[] args)
+	throws NoSuchMethodException {
+    memberAccessCheck(Member.PUBLIC);
+    for (Class c = this; c != null; c = c.getSuperclass()) {
+      Method match = matchMethod(c.nativeGetDeclaredMethods(true), name, args);
+      if (match != null)
+	return match;
+    }
+    throw new NoSuchMethodException();
+  }
+
+  /** 
+   * Find the best matching method in <code>list</code> according to
+   * the definition of ``best matching'' used by <code>getMethod()</code>
+   *
+   * <p>
+   * Returns the method if any, otherwise <code>null</code>.
+   *
+   * @param list List of methods to search
+   * @param name Name of method
+   * @param args Method parameter types
+   * @see #getMethod()
+   */
+  private static Method matchMethod(Method[] list, String name, Class[] args) {
+    Method match = null;
+    for (int i = 0; i < list.length; i++) {
+      Method method = list[i];
+      if (!method.getName().equals(name))
+	continue;
+      if (!matchParameters(args, method.getParameterTypes()))
+	continue;
+      if (match == null
+	  || match.getReturnType().isAssignableFrom(method.getReturnType()))
+	match = method;
+    }
+    return match;
+  }
+
+  /**
+   * Check for an exact match between parameter type lists.
+   * Either list may be <code>null</code> to mean a list of
+   * length zero.
+   */
+  private static boolean matchParameters(Class[] types1, Class[] types2) {
+    if (types1 == null)
+      return types2 == null || types2.length == 0;
+    if (types2 == null)
+      return types1 == null || types1.length == 0;
+    if (types1.length != types2.length)
+      return false;
+    for (int i = 0; i < types1.length; i++) {
+      if (!types1[i].equals(types2[i]))
+	return false;
+    }
+    return true;
+  }
 
   /**
    * Get a public constructor declared in this class. If the constructor takes
@@ -602,8 +711,16 @@
    * @see #getConstructors()
    * @since 1.1
    */
-  public native Constructor getConstructor(Class[] args)
-    throws NoSuchMethodException;
+  public Constructor getConstructor(Class[] args) throws NoSuchMethodException {
+    memberAccessCheck(Member.PUBLIC);
+    Constructor[] constructors = nativeGetDeclaredConstructors(true);
+    for (int i = 0; i < constructors.length; i++) {
+      Constructor constructor = constructors[i];
+      if (matchParameters(args, constructor.getParameterTypes()))
+	return constructor;
+    }
+    throw new NoSuchMethodException();
+  }
 
   /**
    * Get all the declared member classes and interfaces in this class, but
@@ -617,7 +734,17 @@
    * @throws SecurityException if the security check fails
    * @since 1.1
    */
-  public native Class[] getDeclaredClasses();
+  public Class[] getDeclaredClasses() {
+    memberAccessCheck(Member.DECLARED);
+    return nativeGetDeclaredClasses(false);
+  }
+
+  /**
+   * Like <code>getDeclaredClasses()</code> but without the security checks.
+   *
+   * @param pulicOnly Only public classes should be returned
+   */
+  private native Class[] nativeGetDeclaredClasses(boolean pulicOnly);
 
   /**
    * Get all the declared fields in this class, but not those inherited from
@@ -631,7 +758,17 @@
    * @throws SecurityException if the security check fails
    * @since 1.1
    */
-  public native Field[] getDeclaredFields();
+  public Field[] getDeclaredFields() {
+    memberAccessCheck(Member.DECLARED);
+    return nativeGetDeclaredFields(false);
+  }
+
+  /**
+   * Like <code>getDeclaredFields()</code> but without the security checks.
+   *
+   * @param pulicOnly Only public fields should be returned
+   */
+  private native Field[] nativeGetDeclaredFields(boolean pulicOnly);
 
   /**
    * Get all the declared methods in this class, but not those inherited from
@@ -649,7 +786,17 @@
    * @throws SecurityException if the security check fails
    * @since 1.1
    */
-  public native Method[] getDeclaredMethods();
+  public Method[] getDeclaredMethods() {
+    memberAccessCheck(Member.DECLARED);
+    return nativeGetDeclaredMethods(false);
+  }
+
+  /**
+   * Like <code>getDeclaredMethods()</code> but without the security checks.
+   *
+   * @param pulicOnly Only public methods should be returned
+   */
+  private native Method[] nativeGetDeclaredMethods(boolean pulicOnly);
 
   /**
    * Get all the declared constructors of this class. This returns an array of
@@ -663,7 +810,19 @@
    * @throws SecurityException if the security check fails
    * @since 1.1
    */
-  public native Constructor[] getDeclaredConstructors();
+  public Constructor[] getDeclaredConstructors() {
+    memberAccessCheck(Member.DECLARED);
+    return nativeGetDeclaredConstructors(false);
+  }
+
+  /**
+   * Like <code>getDeclaredConstructors()</code> but without
+   * the security checks.
+   *
+   * @param pulicOnly Only public constructors should be returned
+   */
+  private native Constructor[]
+	nativeGetDeclaredConstructors(boolean publicOnly);
 
   /**
    * Get a field declared in this class, where name is its simple name. The
@@ -678,8 +837,15 @@
    * @see #getDeclaredFields()
    * @since 1.1
    */
-  public native Field getDeclaredField(String name)
-    throws NoSuchFieldException;
+  public Field getDeclaredField(String name) throws NoSuchFieldException {
+    memberAccessCheck(Member.DECLARED);
+    Field[] fields = nativeGetDeclaredFields(false);
+    for (int i = 0; i < fields.length; i++) {
+      if (fields[i].getName().equals(name))
+	return fields[i];
+    }
+    throw new NoSuchFieldException();
+  }
 
   /**
    * Get a method declared in this class, where name is its simple name. The
@@ -702,8 +868,14 @@
    * @see #getDeclaredMethods()
    * @since 1.1
    */
-   public native Method getDeclaredMethod(String name, Class[] args)
-     throws NoSuchMethodException;
+   public Method getDeclaredMethod(String name, Class[] args)
+		throws NoSuchMethodException {
+    memberAccessCheck(Member.DECLARED);
+    Method match = matchMethod(nativeGetDeclaredMethods(false), name, args);
+    if (match != null)
+      return match;
+    throw new NoSuchMethodException();
+  }
 
   /**
    * Get a constructor declared in this class. If the constructor takes no
@@ -719,8 +891,17 @@
    * @see #getDeclaredConstructors()
    * @since 1.1
    */
-  public native Constructor getDeclaredConstructor(Class[] args)
-    throws NoSuchMethodException;
+  public Constructor getDeclaredConstructor(Class[] args)
+		throws NoSuchMethodException {
+    memberAccessCheck(Member.DECLARED);
+    Constructor[] constructors = nativeGetDeclaredConstructors(false);
+    for (int i = 0; i < constructors.length; i++) {
+      Constructor constructor = constructors[i];
+      if (matchParameters(args, constructor.getParameterTypes()))
+	return constructor;
+    }
+    throw new NoSuchMethodException();
+  }
 
   /**
    * Get a resource using this class's package using the

Re: [Sablevm-developer] Question about _svmf_exit_object_monitor()

[Archie C. <ar...@de...>]

Prof. Etienne M. Gagnon wrote:
> You're the second person to ask me about it.  The first person was one
> of the members of my evaluation committee during my
> Ph.D. defense. :-)  So, as you were not there, I'll restate my answer.

Wow, such eminent company... :-)

> > My question is: is this inflate operation strictly necessary? Won't
> > these other threads properly handle inflating the lock when they wake up?
> 
> It is not *strictly* necessary, but it is highly desirable to avoid a
> potential pathological case.  [Avoiding another pathological situation
> (i.e. busy-wait) was the reason for adding this more complex unlocking
> protocol!].
> 
> Imagine that the thin lock owner thread holds a very large number of
> thin locks, and that it repeatedly acquires and releases one last
> thin-lock repeatedly, e.g.:
> 
> synchronized(o1){
>  synchronized(o2){
>   ...
>    ...
>     synchronized(o10000000){
>      for(i=0; i<1000000000000;i++){
>       synchronized(a){
>        do something short;
>       } // synch
>      } // loop
> ...
> 
> Assuming there is contention on o1, o2, ..., o10000000, when "a" is
> unlocked, the VM *must* visit the list of 10000000 contending threads.
> If we don't inflate o1,02,... then we must keep the list of contending
> threads.  On the next iteration, when we release "a" again, we must
> revisit this whole 10000000 element list (searching for threads
> contending on "a").  Of course, you can start thinking about how to
> maintain a more complex data structure so that you don't have to
> revisit the whole list, but then you end-up with complex code in an
> operation that we want to be as simple and as fast as possible, as it
> is on the critical path of application execution.  Inflating the
> locks, on the other hand, allows us to keep a very simple and
> strait-forward implementation without having to worry about
> pathological cases.
> 
> Personally, I think it would be more interesting to experiment and
> study the necessity or not of having a "lock deflation" policy to
> revert some fat locks to thin locks.  Mind you that deflating a fat
> lock can be quite tricky to do, regardless of the policy, if you want
> to avoid over-synchronization or bugs in corner cases.
>      
> Does this answer your question satisfactorily?

Yes it does.. thanks very much. For my purposes then, we can compromise:
that is, simply try to inflate the lock when unlocking, but if an out
of memory situation occurs, then just leave the lock deflated. This
would permit the "unlock" operation to be treated as "should always
succeed unless there is a bug", yet we still address the concern you
raise above in all except out of memory situations. But in those situations,
performance is the least of your problems, so it's ok to fall back.

I had also wondered about the question of deflating fat locks as
well. It would definitely be interesting to explore the tradeoffs.
The main question is: how can the VM tell (or guess) at how often
an object is contended?

For example, we could devote a few bits in the object's type descriptor
that indicated what percentage of this type's objects required inflating
their locks. Then we could deflate only if this value was "very low", etc.

Thanks,
-Archie

__________________________________________________________________________
Archie Cobbs     *     Precision I/O      *     http://www.precisionio.com

Re: [Sablevm-developer] sablevm description

[Chris P. <chr...@ma...>]

Okay, I hadn't considered the negative side of things.  Perhaps I should 
have asked, "What's the rationale for not having the word Java appear 
...".  Anyway, thanks for the explanation.

Chris

Prof. Etienne M. Gagnon wrote:

>"Java" is a trademark.  SableVM is in no relation whatsoever with that
>trademark.
>
>From my discussions with the FSF people, I gathered that it would
>apparently be acceptable to write: a portable bytecode interpreter for
>the Java language.  But, I want sablevm to remain open, in the medium
>to long term, to making non-standard extentions to the virtual
>machine.  One could easily think that getting parametric types into
>the VM & a related bytecode verifier would be far preferable to Sun's
>current proposal to add parametric types in the high-level language
>that get erased when compiled to bytecode (thus compromizing the
>security, e.g. imagine a "Stack of SecureChannels" where the VM only
>instanciates a normal Stack + malicious network class accessing the
>Stack object...)
>
>I personally can live without the word Java in the short description
>of the package.  The web page already adds: "implementing the Java
>virtual machine specification, second edition".  I think 99% of people
>understand that SableVM is a Jvm.
>
>Also, SableVM is already linked from most web sites linking to Free
>Jvms.
>
>In summary, I'd like to remain away from any even remote legal problem
>related to this trademark.  Remember that Sun actually forced many web
>page owners and projects to remove the word "java" from their
>URLs/projects names.
>
>  
>
>>Don't you think you should say "portable Java bytecode interpreter"?  
>>You might get more hits.
>>    
>>
>
>Don't we already have enough hits?!!!  I think SF reports a rating of
>98.x%.  That's quite high.  I suggest we concentrate on making SableVM
>run more applications, instead of over-hyping it.
>
>Etienne
>
>On Thu, Mar 20, 2003 at 11:24:14PM -0500, Chris Pickett wrote:
>  
>
>>Hi Etienne,
>>
>>On sourceforge, the current description for sablevm is:
>>
>>SableVM is a portable bytecode interpreter. Its goals are to be 
>>reasonably small, fast, and efficient, as well as providing a 
>>well-designed and robust platform for conducting research. This version 
>>fixes a few bugs.
>>
>>    
>>
>
>
>  
>

Re: [Sablevm-developer] Question about _svmf_exit_object_monitor()

[Prof. E. M. G. <eti...@uq...>]

Hi Archie,

You're the second person to ask me about it.  The first person was one
of the members of my evaluation committee during my
Ph.D. defense. :-)  So, as you were not there, I'll restate my answer.


> My question is: is this inflate operation strictly necessary? Won't
> these other threads properly handle inflating the lock when they wake up?

It is not *strictly* necessary, but it is highly desirable to avoid a
potential pathological case.  [Avoiding another pathological situation
(i.e. busy-wait) was the reason for adding this more complex unlocking
protocol!].

Imagine that the thin lock owner thread holds a very large number of
thin locks, and that it repeatedly acquires and releases one last
thin-lock repeatedly, e.g.:

synchronized(o1){
 synchronized(o2){
  ...
   ...
    synchronized(o10000000){
     for(i=0; i<1000000000000;i++){
      synchronized(a){
       do something short;
      } // synch
     } // loop
...

Assuming there is contention on o1, o2, ..., o10000000, when "a" is
unlocked, the VM *must* visit the list of 10000000 contending threads.
If we don't inflate o1,02,... then we must keep the list of contending
threads.  On the next iteration, when we release "a" again, we must
revisit this whole 10000000 element list (searching for threads
contending on "a").  Of course, you can start thinking about how to
maintain a more complex data structure so that you don't have to
revisit the whole list, but then you end-up with complex code in an
operation that we want to be as simple and as fast as possible, as it
is on the critical path of application execution.  Inflating the
locks, on the other hand, allows us to keep a very simple and
strait-forward implementation without having to worry about
pathological cases.

Personally, I think it would be more interesting to experiment and
study the necessity or not of having a "lock deflation" policy to
revert some fat locks to thin locks.  Mind you that deflating a fat
lock can be quite tricky to do, regardless of the policy, if you want
to avoid over-synchronization or bugs in corner cases.
     
Does this answer your question satisfactorily?

Etienne

> 
> This question has the following implications: inflating a lock can
> possibly throw an exception if we run out of memory. This is in fact
> the only failure mode of _svmf_exit_object_monitor() other than throwing
> an IllegalMonitorStateException.
> 
> For internal VM locks, we can assume that IllegalMonitorStateException
> will never be thrown unless there is a bug. So if we can also eliminate
> the call to _svmf_inflate_lock_no_exception(), then we can assume that
> _svmf_exit_object_monitor() will never return an error except in case
> of a bug. This would then make using object locks internally to the VM
> easier, because we'd never have a weird failure case to handle when unlocking.
> 
> Thanks,
> -Archie
> 
> __________________________________________________________________________
> Archie Cobbs     *     Precision I/O      *     http://www.precisionio.com
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: Tablet PC.  
> Does your code think in ink? You could win a Tablet PC. 
> Get a free Tablet PC hat just for playing. What are you waiting for? 
> http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en
> _______________________________________________
> Sablevm-developer mailing list
> Sab...@li...
> https://lists.sourceforge.net/lists/listinfo/sablevm-developer

-- 
Etienne M. Gagnon, Ph.D.             http://www.info.uqam.ca/~egagnon/
SableVM:                                       http://www.sablevm.org/
SableCC:                                       http://www.sablecc.org/

Re: [Sablevm-developer] Re: Running Ant? - update

[Prof. E. M. G. <eti...@uq...>]

On Thu, Mar 20, 2003 at 02:48:10PM -0500, David B?langer wrote:
>...
> This is a bug in classpath unless the JVM spec is unclear.
>...

No, the bug is mine, as I modified Classpath to do most of the tedious
work in Java.  The original Classpath code only had a single native
call delegating all the work to the VM...  I know my code is quite
incomplete.  Full reflection requires quite a lot of boring code.
Doing an efficient implementation is relatively difficult, too.  (I
admit that one could easily argue that reflection does not need to be
implemented efficiently).

I hereby make a call for help to all SableVM deleopers: Your help
would be highly appreciated for completing the implementation of
reflection in SableVM.  If you follow my example and try to do a
maximum of things in Java and only make native calls when abolutely
necessary, then it would be an excellent exercise for you to start
working on SableVM, and test your understanding of the internal
organization of the VM.


> I fixed the exception bug but I still cannot get it to build.  I get the
> error:
>     ...
>     [javac] Compiling 209 source files to
>     /home/david/sablecc/sablecc-2.18.0/classes
> 
>     BUILD FAILED
>     file:/home/david/sablecc/sablecc-2.18.0/build.xml:173: IO error
>     scanning directory /home/david/sablecc/sablecc-2.18.0/classes
> 
> Any clue of what could cause that error?


I will have to investigate.  If anybody beats me to it, all the
better. ;-)

Etienne



-- 
Etienne M. Gagnon, Ph.D.             http://www.info.uqam.ca/~egagnon/
SableVM:                                       http://www.sablevm.org/
SableCC:                                       http://www.sablecc.org/

Re: [Sablevm-developer] sablevm description

[Prof. E. M. G. <eti...@uq...>]

"Java" is a trademark.  SableVM is in no relation whatsoever with that
trademark.

=46rom my discussions with the FSF people, I gathered that it would
apparently be acceptable to write: a portable bytecode interpreter for
the Java language.  But, I want sablevm to remain open, in the medium
to long term, to making non-standard extentions to the virtual
machine.  One could easily think that getting parametric types into
the VM & a related bytecode verifier would be far preferable to Sun's
current proposal to add parametric types in the high-level language
that get erased when compiled to bytecode (thus compromizing the
security, e.g. imagine a "Stack of SecureChannels" where the VM only
instanciates a normal Stack + malicious network class accessing the
Stack object...)

I personally can live without the word Java in the short description
of the package.  The web page already adds: "implementing the Java
virtual machine specification, second edition".  I think 99% of people
understand that SableVM is a Jvm.

Also, SableVM is already linked from most web sites linking to Free
Jvms.

In summary, I'd like to remain away from any even remote legal problem
related to this trademark.  Remember that Sun actually forced many web
page owners and projects to remove the word "java" from their
URLs/projects names.

> Don't you think you should say "portable Java bytecode interpreter"? =20
> You might get more hits.

Don't we already have enough hits?!!!  I think SF reports a rating of
98.x%.  That's quite high.  I suggest we concentrate on making SableVM
run more applications, instead of over-hyping it.

Etienne

On Thu, Mar 20, 2003 at 11:24:14PM -0500, Chris Pickett wrote:
> Hi Etienne,
>=20
> On sourceforge, the current description for sablevm is:
>=20
> SableVM is a portable bytecode interpreter. Its goals are to be=20
> reasonably small, fast, and efficient, as well as providing a=20
> well-designed and robust platform for conducting research. This version=
=20
> fixes a few bugs.
>=20


--=20
Etienne M. Gagnon, Ph.D.             http://www.info.uqam.ca/~egagnon/
SableVM:                                       http://www.sablevm.org/
SableCC:                                       http://www.sablecc.org/

[Sablevm-developer] sablevm description

[Chris P. <chr...@ma...>]

Hi Etienne,

On sourceforge, the current description for sablevm is:

SableVM is a portable bytecode interpreter. Its goals are to be 
reasonably small, fast, and efficient, as well as providing a 
well-designed and robust platform for conducting research. This version 
fixes a few bugs.

........

Don't you think you should say "portable Java bytecode interpreter"?  
You might get more hits.

Chris

[Sablevm-developer] Question about _svmf_exit_object_monitor()

[Archie C. <ar...@de...>]

Etienne-

Question about _svmf_exit_object_monitor(). In the case where the lock
is fat and the thread reference count is going to zero (so that the
monitor is really being released), and there is contention, you iterate
through the list of other threads contending for the monitor and wake
them up. But if one of these threads is actually contending for a
different object monitor (owned by the current thread) than the one
we're presently unlocking, then you inflate that object's lock.

My question is: is this inflate operation strictly necessary? Won't
these other threads properly handle inflating the lock when they wake up?

This question has the following implications: inflating a lock can
possibly throw an exception if we run out of memory. This is in fact
the only failure mode of _svmf_exit_object_monitor() other than throwing
an IllegalMonitorStateException.

For internal VM locks, we can assume that IllegalMonitorStateException
will never be thrown unless there is a bug. So if we can also eliminate
the call to _svmf_inflate_lock_no_exception(), then we can assume that
_svmf_exit_object_monitor() will never return an error except in case
of a bug. This would then make using object locks internally to the VM
easier, because we'd never have a weird failure case to handle when unlocking.

Thanks,
-Archie

__________________________________________________________________________
Archie Cobbs     *     Precision I/O      *     http://www.precisionio.com

[Sablevm-developer] Re: Running Ant? - update

[David <db...@cs...>]

Hi Etienne,

I fixed the exception bug but I still cannot get it to build.  I get the
error:
    ...
    [javac] Compiling 209 source files to
    /home/david/sablecc/sablecc-2.18.0/classes

    BUILD FAILED
    file:/home/david/sablecc/sablecc-2.18.0/build.xml:173: IO error
    scanning directory /home/david/sablecc/sablecc-2.18.0/classes

Any clue of what could cause that error?


About the bug fixed:

This is a bug in classpath unless the JVM spec is unclear.

Method.invoke(Object o, Object[] args) takes an Object[] for the
arguments.  Primitive must be wrapped.

Ant passes a Boolean[] as the args which is assignable to
Object[].  However, the classpath do this for primitive saying it
simplifies the VM:
boolean[] wrapper =3D new boolean[1];
wrapper[0] =3D ((Boolean) args[i]).booleanValue();
args[i] =3D wrapper;

but this last statement throws a ArrayStoreException since
boolean[] is not assignable to Boolean (it is however assignable to
type Object).

I have included a patch that should fix that first problem.
		    =20

David

On Thu, Mar 20, 2003 at 10:39:43AM -0500, Prof. Etienne M. Gagnon wrote:
> Hi David,
>=20
> I tried using Ant to compile ("ant compile") my newest SableCC (2.18.0)=
=20
> package on Debian/PowerPC, using sablevm 1.0.8 (with *direct*-threading=
, as=20
> *inline*-threading needs tuning on ppc).
>=20
> I get a java.lang.ArrayStoreException in j.l.r.Method line 391.
>=20
> Didn't you say that you were able to run Ant on SableVM?
>=20
> =C9tienne
> --=20
> Etienne M. Gagnon, Ph.D.             http://www.info.uqam.ca/~egagnon/
> SableVM:                                       http://www.sablevm.org/
> SableCC:                                       http://www.sablecc.org/
>=20

--=20

---

David B=E9langer
Graduate Student
School of Computer Science
McGill University
Office: MC226

Web page:   http://www.cs.mcgill.ca/~dbelan2/
Public key: http://www.cs.mcgill.ca/~dbelan2/public_key.txt

Re: [Sablevm-developer] Re: prcs vs. cvs vs. subversion

[Lhotak O. <ol...@sa...>]

It looks like they settled on per-repository revision numbers. However,
when you ask for a change log inside a directory, it only lists changes
affecting that directory and the files and directories recursively
inside it.

I should add that The Subversion Book (http://svnbook.red-bean.com/) is
very well written and readable, and a good source of information for any
of you looking to find out more about svn.

Ondrej

On Thu, Mar 20, 2003 at 04:23:57PM +0100, Grzegorz B. Prokopski wrote:
> W li¶cie z czw, 20-03-2003, godz. 14:57, Lhotak Ondrej pisze: 
> > - Per-repository revision numbers rather than per-file are a nice way to
> >   keep track of which versions of files go together. Atomic commits are
> >   nice too.
> 
> I may be wrong but I when I read SVN roadmap about 2(?) years ago they
> were taking about per-directory revision numbers instead of per-file 
> (or per-repository). It might have changed since that time though.
> 
> Thank you for your comprehensive answer.
> It was pleasure to read it.
> 
> 				Grzegorz B. Prokopski
> -- 
> Grzegorz B. Prokopski <ga...@de...>
> Debian http://www.debian.org/
> 

[Sablevm-developer] Re: Running Ant?

[David <db...@cs...>]

On Thu, Mar 20, 2003 at 10:39:43AM -0500, Prof. Etienne M. Gagnon wrote:
> Hi David,
>=20
> I tried using Ant to compile ("ant compile") my newest SableCC (2.18.0)=
=20
> package on Debian/PowerPC, using sablevm 1.0.8 (with *direct*-threading=
, as=20
> *inline*-threading needs tuning on ppc).
>=20
> I get a java.lang.ArrayStoreException in j.l.r.Method line 391.
>=20

> Didn't you say that you were able to run Ant on SableVM?

I am not a big Ant user, I just tried it on a small example.  (Actually,
I was expecting to have some bug reports about Ant eventually).

I will have a look at it.

David

>=20
> =C9tienne
> --=20
> Etienne M. Gagnon, Ph.D.             http://www.info.uqam.ca/~egagnon/
> SableVM:                                       http://www.sablevm.org/
> SableCC:                                       http://www.sablecc.org/
>=20

--=20

---

David B=E9langer
Graduate Student
School of Computer Science
McGill University
Office: MC226

Web page:   http://www.cs.mcgill.ca/~dbelan2/
Public key: http://www.cs.mcgill.ca/~dbelan2/public_key.txt

[Sablevm-developer] Running Ant?

[Prof. E. M. G. <eti...@uq...>]

Hi David,

I tried using Ant to compile ("ant compile") my newest SableCC (2.18.0) p=
ackage=20
on Debian/PowerPC, using sablevm 1.0.8 (with *direct*-threading, as=20
*inline*-threading needs tuning on ppc).

I get a java.lang.ArrayStoreException in j.l.r.Method line 391.

Didn't you say that you were able to run Ant on SableVM?

=C9tienne
--=20
Etienne M. Gagnon, Ph.D.             http://www.info.uqam.ca/~egagnon/
SableVM:                                       http://www.sablevm.org/
SableCC:                                       http://www.sablecc.org/

Re: [Sablevm-developer] Re: prcs vs. cvs vs. subversion

[Grzegorz B. P. <ga...@de...>]

W liście z czw, 20-03-2003, godz. 14:57, Lhotak Ondrej pisze: 
> - Per-repository revision numbers rather than per-file are a nice way to
>   keep track of which versions of files go together. Atomic commits are
>   nice too.

I may be wrong but I when I read SVN roadmap about 2(?) years ago they
were taking about per-directory revision numbers instead of per-file 
(or per-repository). It might have changed since that time though.

Thank you for your comprehensive answer.
It was pleasure to read it.

				Grzegorz B. Prokopski
-- 
Grzegorz B. Prokopski <ga...@de...>
Debian http://www.debian.org/

Re: [Sablevm-developer] .cvsignore

[Prof. E. M. G. <eti...@uq...>]

You can maintain your own .cvs ignore.  I do not like .cvsignore files to=
 be=20
checked in CVS (.cvsignore is an inherently local preference kind of file=
).

Instead, I personally use the attached script, when I want to cleanup my =

directory before a commit.  (I type: "make distclean ; ./r)

It's called "r" like in remove, and kept short (one letter) for convenien=
ce...

Etienne

David B=E9langer wrote:
> Hello,
>=20
> This is a suggestion.
>=20
> It would be good to have .cvsignore files for all
> automatically generated files in the SableVM repository.
> I have my own collection and I could send them to have
> them checkin.
>=20
--=20
Etienne M. Gagnon, Ph.D.             http://www.info.uqam.ca/~egagnon/
SableVM:                                       http://www.sablevm.org/
SableCC:                                       http://www.sablecc.org/

[Sablevm-developer] Re: prcs vs. cvs vs. subversion

[Lhotak O. <ol...@sa...>]

On Wed, Mar 19, 2003 at 09:50:27PM -0500, Chris Pickett wrote:
> Hi Ondrej,
> 
> Can you send a message to this list discussing why you chose Subversion 
> over PRCS (apart from the lack of client-server functionality)?  Can you 
> also tell us how Subversion is working out for Soot?  Problems, 
> benefits, support ... whatever.  Things like branch management are 
> particularly interesting.
> 
> Cheers,
> Chris

How long a response are you looking for? :)

We agreed that prcs was getting in our way due to missing features and
important bugs. Most annoying missing features were:
- no way to get per-file change log. Result was Soot littered with
  comments like "Who did this? Why? and When?" which any half-decent
  system should easily answer. Even per-repository change log is clumsy.
  If you can't easily see your old versions, why even have version
  control at all?
- no clean way to revert local changes made to a file.
- no network access
Most annoying bugs were:
- the mechanism tracking which versions had been merged often broke,
  causing people to inadvertently undo other peoples' changes, because
  prcs thought it had merged them when it hadn't
- the mechanism for inserting properties such as the version number into
  the versioned files was broken, and often forgot to do it. Someone had
  decided to use it for code (to encode the version string) rather than
  just comments, leading to often uncompilable code.

We agreed that we wanted to switch away from prcs. I evaluated a wide
range of alternatives. This quickly narrowed down to cvs and svn. The
main other runner-ups were arch, bitkeeper, and p4. Arch is still not
stable enough. Judging from its mailing list, there appears to be no
progress. It is overkill and too complicated for our needs. Bitkeeper is
also more complicated than we need; if Soot were being developed by ten
independent groups like Sable, it would probably be a good choice. It
is proprietary, though the free-beer-when-used-for-open-source licence
seems quite reasonable. P4 would probably have been the best choice from
a technical point of view, but it is very similar to svn, and there are
really no compelling reasons to choose it over svn (except perhaps a
bit of maturity). Its disadvantage is that it's proprietary, and its
free-beer-when-used-for-open-source licence appears to require much more
paperwork than the one for bitkeeper.

So it was between cvs and svn. Svn is designed as a replacement for cvs,
meaning that it fixes cvs's design problems, while attempting to
maintain all its features and a similar interface. Key advantages of
svn over cvs:
- Directories and file moves are versioned. This is particularly
  important for Java, since the placement of a file has semantic
  meaning: to move a class to a different package, you must move the
  file to a different directory. An indirect advantage of this is that
  we were able to convert our existing prcs repository into svn. I had
  earlier tried to convert it to cvs, but ended up with a clutter of
  many empty subdirectories which had been removed in prcs.
- Per-repository revision numbers rather than per-file are a nice way to
  keep track of which versions of files go together. Atomic commits are
  nice too.
- Tagging and branching first appear odd to someone corrupted by cvs,
  but if you are not so corrupted, the svn way of doing it is much
  simpler and more intuitive. They support a cheap copy operation.
  To tag, you just make a (cheap) copy of the current state of the
  project. To branch, you make a cheap copy and continue working on it.
- Disconnected operation. Svn makes a full copy of each file you
  checkout in its own .svn directory, so you can perform many operations
  (eg. diff, revert, ...) without being connected to the repository.

The main potential advantages of cvs over svn are maturity/stability,
and third-party tool support. In terms of maturity/stability, the
following is from the svn FAQ:

> Is Subversion stable enough for me to use for my own projects?
> 
> We think so!
> Because:
>     * We believe that Subversion is stable and have confidence in our
> code, in fact, we've been self-hosting since September of 2001--eating
> our own caviar so to speak. We declared alpha because we're ready for
> the world to try Subversion.
>     * After 10 months of self-hosting, we haven't lost any data at all.
>     * The filesystem schema is stable now and shouldn't undergo any
> changes before 1.0. In the off-chance that the schema does change, we
> will provide a dump/load utility to aid you in the migration.
>     * In order to make Subversion as stable as possible, we need more
> people to use Subversion. If you use Subversion on a day-to-day basis,
> you can help us find and fix any bugs that might turn up. It may sound
> risky at first, but odds are that if you find any bugs they will be
> minor inconveniences as opposed to data destroyers.

In my experience (in using svn on Soot and other toy projects, and
when evaluating it), the back end is rock solid, while the front-end
exhibits the odd minor annoyance. None of the annoyances I've seen were
data-destroying; typically, they affect the client-side metadata in the
workspace. Pat claims that cvs sometimes has similar annoyances; we've
certainly seen many more with prcs than with svn. Development is very
active (I couldn't keep up with the mailing list), and bugs are fixed
promptly. There are typically about two releases a month.

As far as third-party support, it is catching up fast. We were
particularly interested in ViewCVS, which does support svn.

One to-be-implemented feature is the equivalent of cvs annotate (the
blame finder); it is planned for this summer. For the impatient, there
exists a free perl script to do this with p4, and it would probably be
easy to modify to work with svn.

You asked about branching and merging. Currently, svn gives you full
control over a merge, and (unlike prcs) doesn't try to guess which
version(s) you meant. Specifically, svn merge takes as arguments three
(versions of) directories. It makes a diff from dir1 to dir2, and then
uses it to patch dir3. Then you get to resolve any conflicts. This works
very well if you have, say, a stable and a development branch, and you
want to port a specific change (bug fix) from one to the other. It works
slightly less well if you have an experimental branch with new features,
and you want to merge the whole branch into your main branch, especially
if you've already merged specific changes from the main branch into the
experimental branch. This is the same with cvs. Remembering what has
already been merged and using that information in future merges is a
to-be-implemented feature.

You asked how it's working out for Soot. Svn is a joy to use compared to
prcs, which was a constant source of frustration. I suspect that cvs
would be similar, but I have no regrets about having chosen svn over
cvs. As far as support, the only problems that we encountered were
already reported and fixed before we encountered them, so we haven't
needed to ask for any support.

I hope this answers your question. I am not subscribed to sablevm-dev,
so please cc me any followups.

Ondrej

[Sablevm-developer] prcs vs. cvs vs. subversion

[Chris P. <chr...@ma...>]

Hi Ondrej,

Can you send a message to this list discussing why you chose Subversion 
over PRCS (apart from the lack of client-server functionality)?  Can you 
also tell us how Subversion is working out for Soot?  Problems, 
benefits, support ... whatever.  Things like branch management are 
particularly interesting.

Cheers,
Chris

Re: [Sablevm-developer] _svm?_ prefixes

[Prof. E. M. G. <eti...@uq...>]

On Wed, Mar 19, 2003 at 05:22:58PM -0500, David B?langer wrote:
> Could someone tell me the prefix convention/meaning.
> 
> So far I figure out:
> _svmt_* for types
> _svmv_* for value
> but I'm confuse with when _svm{h,m,f} are used.


_svmt_*: type (usually typedef of a struct)
_svmv_*: global variable
_svmf_*: function
_svmm_*: macro
_svmh_*: hidden function... A function which should never be called
         directly by a SableVM programmer, it is instead called
         through a macro.  (e.g., if you wish to call a _svmh_
         function, you should find its related _svmm_ macro and call
         it instead).

You're welcome to add this explanation in the /doc directory. ;-)

Etienne


-- 
Etienne M. Gagnon, Ph.D.             http://www.info.uqam.ca/~egagnon/
SableVM:                                       http://www.sablevm.org/
SableCC:                                       http://www.sablecc.org/

Re: [Sablevm-developer] _svm?_ prefixes

[Chris P. <chr...@ma...>]

Etienne, please respond in a manner we can include in a document somewher=
e.

After looking at the subversion source, I think it would be good if we=20
had a 'HACKING' file in /sablevm with coding guidelines, where to get=20
started, the stuff we discussed in that README I made, etc. etc.

So I'd like to put your answer in this file.

Cheers,
Chris

David B=E9langer wrote:

>Hello,
>
>Could someone tell me the prefix convention/meaning.
>
>So far I figure out:
>_svmt_* for types
>_svmv_* for value
>but I'm confuse with when _svm{h,m,f} are used.
>
>Thanks,
>David
>
>---
>
>David B=E9langer
>Graduate Student
>School of Computer Science
>McGill University
>Office: MC226
>
>Web page:   http://www.cs.mcgill.ca/~dbelan2/
>Public key: http://www.cs.mcgill.ca/~dbelan2/public_key.txt
>
> =20
>

[Sablevm-developer] _svm?_ prefixes

[David <db...@cs...>]

Hello,

Could someone tell me the prefix convention/meaning.

So far I figure out:
_svmt_* for types
_svmv_* for value
but I'm confuse with when _svm{h,m,f} are used.

Thanks,
David

---

David B=E9langer
Graduate Student
School of Computer Science
McGill University
Office: MC226

Web page:   http://www.cs.mcgill.ca/~dbelan2/
Public key: http://www.cs.mcgill.ca/~dbelan2/public_key.txt

Re: [Sablevm-developer] skip vs. nop

[Chris P. <chr...@ma...>]

Prof. Etienne M. Gagnon wrote:

> Hi Chris,
>
> Here's a more elaborate answer.
>
> Chris Pickett wrote:
>
>> Why are there SKIP and NOP instructions?  What is the difference?
>
>
> The body is quite different.  NOP does nothing in its body while SKIP 
> increments the PC.  This makes a big difference within an inlined 
> sequence.  Once inlined, NOP becomes a real NOP -> it consumes 0 
> processor cycle, while SKIP still does something -> it increases the 
> value of PC.  This is, in fact, key to the implementation of 
> thread-safe preparation sequences.  See my CC2003 paper for details.
>
I understand.  I thought instructions.m4.c defined them both to be the 
same, but looking again I realize NOP has no pc++.

Are there details in CC2003 that aren't in your thesis?  In general, 
which papers contain information about the workings of SableVM that 
aren't in your thesis?

Chris

Re: [Sablevm-developer] skip vs. nop

[Prof. E. M. G. <eti...@uq...>]

Hi Chris,

Here's a more elaborate answer.

Chris Pickett wrote:
> Why are there SKIP and NOP instructions?  What is the difference?

The body is quite different.  NOP does nothing in its body while SKIP increments 
the PC.  This makes a big difference within an inlined sequence.  Once inlined, 
NOP becomes a real NOP -> it consumes 0 processor cycle, while SKIP still does 
something -> it increases the value of PC.  This is, in fact, key to the 
implementation of thread-safe preparation sequences.  See my CC2003 paper for 
details.

Etienne

-- 
Etienne M. Gagnon, Ph.D.             http://www.info.uqam.ca/~egagnon/
SableVM:                                       http://www.sablevm.org/
SableCC:                                       http://www.sablecc.org/

Re: [Sablevm-developer] suggestion: sablevm developer doc

[Prof. E. M. G. <eti...@uq...>]

[I think my first version of this message got lost by human error...]

On Tue, Mar 18, 2003 at 01:18:09PM -0500, Chris Pickett wrote:
> ... If someone fixes something in the experimental branch, do 
> they submit a patch for it to be included in the non-experimental branch?

Yep (until the change to subversion, if it indeed works as intended).

> I have no problem being restricted to not committing anything to the main 
> development  module unless explicitly asked.

I would say, unless explicitly agreed upon (on the ML or in person).

> Maybe you want to send an email to the info-cvs list I gave a link to, 
> explaining the current problems and the specifics of our project (# of 
> developers, CVS version, code size, etc.), and see what they have to say 
> about your solution.

If I'm right, some of the cvs developers take now part in subversion
development, so no need to tell them about things they already know
about.  (They do know.)

> >1- You change your SF user account name to something more professional.
> > 
> >
> I already did that ... immediately after you asked me ... it's cpickett 

Good.

> now (look at the comment I just made in the bug tracker).  you can even 
> close those bugs and re-open them if you don't want ihatemcgill to show 
> up in the bug tracker.


If the bugs are not closed within a few weeks, it might be worth the effort.

> >2- You ask me for it, and we make the mandatory agreement on legal issues.
> > 
> >
> Ok, I'm asking you.  I can sign whatever you want me to sign.  As for a 
> clean room, I can guarantee that much for sure.

Search the ML archive for my latest policy on contributions.  Usually,
no signed documents are involved (I do not require Copyright
assignment, as does the FSF).  We can discuss the details at our
meeting.

> Okay, I can do that.  Or maybe I'll switch to using Subversion (since it 
> sounds like you want to try it in the future)

Great!  This would allow me to get first-hand feedback about it.
Please do so. :-) [This would be a good way to test it's braches and
merge mechanisms].  Test as much as you can, inluding moving/renaming
files, etc., if possible.

> 
> Basically, there are two reasons why I would like the 
> sablevm-experimental module:
> 

OK.  I'll add the module.

Etienne

-- 
Etienne M. Gagnon, Ph.D.             http://www.info.uqam.ca/~egagnon/
SableVM:                                       http://www.sablevm.org/
SableCC:                                       http://www.sablecc.org/

Re: [Sablevm-developer] suggestion: sablevm developer doc

[Chris P. <chr...@ma...>]

>
>
>>The only thing I can do, if you want to put all sort of stuff into
>>CVS, is to start a "distinct module", sablevm-experimental, that could
>>live in parallel, where there would be, again, a single trunk, but
>>where all developers can check-in stuff freely (as long as the code is
>>licensed appropriately, no non-clean-room contribution as usual).
>>  
>>
>> In fact, it would have 2 brances: Trunk & Vendor branch.  The latter
>> would track changes in the sablevm module.
>
>> What do you, and others, think of this?
>
>I think that's fine, but what potential problems do you see w.r.t. synchronization?  If someone fixes something in the experimental branch, do they submit a patch for it to be included in the non-experimental branch?
>
I meant "module", not "branch" here.

Re: [Sablevm-developer] suggestion: sablevm developer doc

[Prof. E. M. G. <eti...@uq...>]

Hi David,

> It is fine with me.  I wasn't expecting my suggestion to turn into a debate
> about which version management system is best, I just wanted some space
> to put my document draft... :(

Not your fault.  I guess every project has to debate some technical
details from time to time.  I hope we're done for a little while. ;-)

Just in case you did not know, you automatically gain CVS write access
when you are added as a developer of the project (on the SF project
page).

To set your local snapshot for write access, you have to read the SF
documentation and the instructions in:

(Developer CVS Access via SSH)
  http://sourceforge.net/cvs/?group_id=5523

(Other CVS/SSH related docs).
  E. Information for Members (Developers) of SourceForge.net Projects
  F. Version Control with CVS (Concurrent Versions System)
  http://sourceforge.net/docman/?group_id=1

The /doc directory has already been added, so you simply need to "cvs
add doc/yourdoc ; cvs commit" when you are ready.

IMPORTANT:  Always provide a meaningful commit message.  Thanks.

Have fun!

Etienne

-- 
Etienne M. Gagnon, Ph.D.             http://www.info.uqam.ca/~egagnon/
SableVM:                                       http://www.sablevm.org/
SableCC:                                       http://www.sablecc.org/