[cp-patches] FYI: Small bug in copy-vmresources.sh.in on small platform
Hi,
I have spotted a small problem on Darwin5/6 with copy-vmresources.sh.in.
We need to add a '.' after some 'find' commands. This patch does this.
ChangeLog:
2005-12-11 Guilhem Lavaux [EMAIL PROTECTED]
* lib/copy-vmresources.sh.in: Added some '.' after find.
Regards,
Guilhem.
Index: lib/copy-vmresources.sh.in
===
RCS file: /cvsroot/classpath/classpath/lib/copy-vmresources.sh.in,v
retrieving revision 1.2
diff -u -r1.2 copy-vmresources.sh.in
--- lib/copy-vmresources.sh.in 2 Nov 2005 21:04:10 - 1.2
+++ lib/copy-vmresources.sh.in 11 Dec 2005 13:10:56 -
@@ -9,11 +9,11 @@
for p in ${vmdirs}; do
if test -d $p/META-INF; then
(cd $p/META-INF;
-dirs=`find -name CVS -prune -o -type d -print`;
+dirs=`find . -name CVS -prune -o -type d -print`;
for u in ${dirs}; do
mkdir -p ${destMetaDir}/${u};
done;
-files=`find -name CVS -prune -o -type f -print`;
+files=`find . -name CVS -prune -o -type f -print`;
for u in ${files}; do
cp ${u} ${destMetaDir}/${u};
done
___
Classpath-patches mailing list
Classpath-patches@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath-patches
[cp-patches] RFC: Adding a cache for locale information
Hi,
Using ant we may have discovered that multiple creation of a
SimpleDateFormat object can lead to a big slowdown. I am proposing the
addition of a simple cache system. LocaleCache would cache
ResourceBundle objects and some parsed strings in a WeakHashMap. If it
is needed LocaleCache will create these objects and in the other case
extract them directly from the cache.
This patch shows DateFormatSymbols can be easily modified to follow this
scheme.
Regards,
Guilhem.
ChangeLog:
2005-12-11 Guilhem Lavaux [EMAIL PROTECTED]
* gnu/java/util/LocaleCache.java: New file.
* java/text/DateFormatSymbols.java: Use the cache instead of
reparsing the properties each time the object is created.
Index: gnu/java/util/LocaleCache.java
===
RCS file: gnu/java/util/LocaleCache.java
diff -N gnu/java/util/LocaleCache.java
--- /dev/null 1 Jan 1970 00:00:00 -
+++ gnu/java/util/LocaleCache.java 11 Dec 2005 13:19:25 -
@@ -0,0 +1,144 @@
+/* gnu.java.util.LocaleCache
+ Copyright (C) 2003 Free Software Foundation, Inc.
+
+This file is part of GNU Classpath.
+
+GNU Classpath is free software; you can redistribute it and/or modify
+it under the terms of the GNU General Public License as published by
+the Free Software Foundation; either version 2, or (at your option)
+any later version.
+
+GNU Classpath is distributed in the hope that it will be useful, but
+WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+General Public License for more details.
+
+You should have received a copy of the GNU General Public License
+along with GNU Classpath; see the file COPYING. If not, write to the
+Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
+02110-1301 USA.
+
+Linking this library statically or dynamically with other modules is
+making a combined work based on this library. Thus, the terms and
+conditions of the GNU General Public License cover the whole
+combination.
+
+As a special exception, the copyright holders of this library give you
+permission to link this library with independent modules to produce an
+executable, regardless of the license terms of these independent
+modules, and to copy and distribute the resulting executable under
+terms of your choice, provided that you also meet, for each linked
+independent module, the terms and conditions of the license of that
+module. An independent module is a module which is not derived from
+or based on this library. If you modify this library, you may extend
+this exception to your version of the library, but you are not
+obligated to do so. If you do not wish to do so, delete this
+exception statement from your version. */
+
+package gnu.java.util;
+
+import java.util.WeakHashMap;
+import java.util.ResourceBundle;
+import java.util.Locale;
+import java.util.MissingResourceException;
+
+public class LocaleCache
+{
+ static private LocaleCache singleton = new LocaleCache();
+
+ private WeakHashMap cache;
+
+ private LocaleCache()
+ {
+cache = new WeakHashMap();
+ }
+
+ static public LocaleCache getCache()
+ {
+return singleton;
+ }
+
+ private String[] getStringArray(Locale locale, String key)
+ {
+return getLocaleInformationBundle(locale).getString(key).split(\u00ae);
+ }
+
+ public String[] getCacheStringArray(Locale locale, String key)
+ {
+String localeStr = locale.toString();
+
+if (.equals(localeStr))
+ return getStringArray(locale, key);
+
+String keyStr = localeStr + +key+ + key;
+String[] array = (String[])cache.get(keyStr);
+
+if (array == null)
+ {
+ array = getStringArray(locale, key);
+ cache.put(keyStr, array);
+ }
+
+return array;
+ }
+
+ private String[][] getZoneStrings(Locale locale)
+ {
+ResourceBundle res = getLocaleInformationBundle(locale);
+try
+ {
+ int index = 0;
+ String data = res.getString(zoneStrings);
+ String[] zones = data.split(\u00a9);
+ String[][] array = new String[zones.length][];
+ for (int a = 0; a zones.length; ++a)
+ array[a] = zones[a].split(\u00ae);
+ return array;
+ }
+catch (MissingResourceException e)
+ {
+ return new String[0][];
+ }
+ }
+
+ public String[][] getCacheZoneStrings(Locale locale)
+ {
+String localeStr = locale.toString();
+
+if (.equals(localeStr))
+ return getZoneStrings(locale);
+
+String keyStr = localeStr + +zone_strings;
+String[][] array = (String[][])cache.get(keyStr);
+
+if (array == null)
+ {
+ array = getZoneStrings(locale);
+ cache.put(keyStr, array);
+ }
+
+return array;
+ }
+
+ public ResourceBundle getLocaleInformationBundle(Locale loc)
+ {
+String localeStr = loc.toString();
+
+if (.equals(localeStr))
+
Re: [cp-patches] Patch: fix Float/DoubleBuffer.compareTo in the presence of NaN
Hi Anthony, On Tue, 2005-12-06 at 18:50 -0800, Anthony Green wrote: Does it do the right thing if a is NaN and b is not? Or vice versa? If so, this is ok. Yes, definitely. Although I have what is probably an even simpler patch now. I'll commit the following later tomorrow unless there are objections. No objections. But you seem to have forgotten to actually commit this change. Cheers, Mark signature.asc Description: This is a digitally signed message part ___ Classpath-patches mailing list Classpath-patches@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-patches
Re: [cp-patches] RFC: Patch for duplicate entries in serialPersistentFields
On Sat, 2005-12-10 at 20:16 +0100, Guilhem Lavaux wrote:
Hi,
Here is a patch which (partially) fix a regression in kaffe. If you
define a class like that:
class A
{
private static final ObjectStreamField[] serialPersistentFields =
{
new ObjectStreamField(i, int.class),
new ObjectStreamField(i, int.class)
};
/* ... */
};
then the JDK throws an InvalidClassException in ObjectStreamClass.lookup.
This goes against the API. However it is true that we must take into
account the presence of duplicate fields. So I propose we throw an
InvalidClassException on writing the object if this sort of situation
happens.
Why not do similar and throw the InvalidClassException from
ObjectStreamClass.lookup()?
(But then document that clearly in our version of course.)
If you do like in your patch then at least document this behavior. It is
slightly confusing that ObjectStreamClass.lookup() returns a non-null
result, but getFields() suddenly returns an empty ObjectStreamField
array as if there are no Serializable fields. Now user code has no real
way to check whether that is because the ObjectStreamClass is invalid
(because of bogus serialPersistentFields) or because it just has no
serializable fields.
Cheers,
Mark
signature.asc
Description: This is a digitally signed message part
___
Classpath-patches mailing list
Classpath-patches@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath-patches
Re: [cp-patches] RFC: Patch for duplicate entries in serialPersistentFields
Mark Wielaard wrote:
On Sat, 2005-12-10 at 20:16 +0100, Guilhem Lavaux wrote:
Hi,
Here is a patch which (partially) fix a regression in kaffe. If you
define a class like that:
class A
{
private static final ObjectStreamField[] serialPersistentFields =
{
new ObjectStreamField(i, int.class),
new ObjectStreamField(i, int.class)
};
/* ... */
};
then the JDK throws an InvalidClassException in ObjectStreamClass.lookup.
This goes against the API. However it is true that we must take into
account the presence of duplicate fields. So I propose we throw an
InvalidClassException on writing the object if this sort of situation
happens.
Why not do similar and throw the InvalidClassException from
ObjectStreamClass.lookup()?
(But then document that clearly in our version of course.)
Because we would not have the same API. ObjectStreamClass.lookup may not
throw any exception (except the default ones like Error, NPE, ...).
If you do like in your patch then at least document this behavior. It is
slightly confusing that ObjectStreamClass.lookup() returns a non-null
result, but getFields() suddenly returns an empty ObjectStreamField
array as if there are no Serializable fields. Now user code has no real
way to check whether that is because the ObjectStreamClass is invalid
(because of bogus serialPersistentFields) or because it just has no
serializable fields.
Ok. I may add some documentation on that.
Cheers,
Guilhem.
___
Classpath-patches mailing list
Classpath-patches@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath-patches
Re: [cp-patches] RFC: Adding a cache for locale information
Hi, On Sun, 2005-12-11 at 14:20 +0100, Guilhem Lavaux wrote: Using ant we may have discovered that multiple creation of a SimpleDateFormat object can lead to a big slowdown. I am proposing the addition of a simple cache system. LocaleCache would cache ResourceBundle objects and some parsed strings in a WeakHashMap. If it is needed LocaleCache will create these objects and in the other case extract them directly from the cache. This patch shows DateFormatSymbols can be easily modified to follow this scheme. If you are really seeing big speedups then this makes sense. Do you have an indication of how much time/resources are involved? Some comments on this patch. - The cache can be accessed from multiple Threads so all access should be synchronized. - When does Locale.toString() every return the empty String? - In getZoneStrings() you now catch/handle the case of a MissingResourceException. Why wasn't this needed before? Does this change the semantics? - The use of ClassLoader.getSystemClassLoader() cannot be done in all context. If you know this is safe here (I believe it is) then you can use a doPrivilieged() call here. Or maybe even add a new Action for getting the System Class Loader in gnu.java.security.action since it is done more often in the core classes. (This was wrong in the original code so isn't a new issue. If you decide not to fix it then please file a bug report for it.) Minor nitpicks: - There are multiple lines 80 chars. - There should be spaces around all operators like + or =. Cheers, Mark signature.asc Description: This is a digitally signed message part ___ Classpath-patches mailing list Classpath-patches@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-patches
Re: [cp-patches] RFC: Adding a cache for locale information
Mark Wielaard wrote: Hi, On Sun, 2005-12-11 at 14:20 +0100, Guilhem Lavaux wrote: Using ant we may have discovered that multiple creation of a SimpleDateFormat object can lead to a big slowdown. I am proposing the addition of a simple cache system. LocaleCache would cache ResourceBundle objects and some parsed strings in a WeakHashMap. If it is needed LocaleCache will create these objects and in the other case extract them directly from the cache. This patch shows DateFormatSymbols can be easily modified to follow this scheme. If you are really seeing big speedups then this makes sense. Do you have an indication of how much time/resources are involved? I first wanted to test on ant's build itself but it hasn't improved anything. I (or mnemoc) will test eclipse's build... Some comments on this patch. - The cache can be accessed from multiple Threads so all access should be synchronized. Ok. No problem. - When does Locale.toString() every return the empty String? If both language and variants are empty. We should never use this case though. - In getZoneStrings() you now catch/handle the case of a MissingResourceException. Why wasn't this needed before? Does this change the semantics? I haven't changed the semantics. The catch was already there. By the way, I will also remove the code from DateFormatSymbols in the next patch as it becomes unused. - The use of ClassLoader.getSystemClassLoader() cannot be done in all context. If you know this is safe here (I believe it is) then you can use a doPrivilieged() call here. Or maybe even add a new Action for getting the System Class Loader in gnu.java.security.action since it is done more often in the core classes. (This was wrong in the original code so isn't a new issue. If you decide not to fix it then please file a bug report for it.) Ok. I will fix this... Minor nitpicks: - There are multiple lines 80 chars. - There should be spaces around all operators like + or =. Ok. I'll post a new patch asap. Cheers, Guilhem. ___ Classpath-patches mailing list Classpath-patches@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-patches
Re: [cp-patches] RFC: Patch for duplicate entries in serialPersistentFields
Hi Guilhem, On Sun, 2005-12-11 at 16:41 +0100, Guilhem Lavaux wrote: Why not do similar and throw the InvalidClassException from ObjectStreamClass.lookup()? (But then document that clearly in our version of course.) Because we would not have the same API. ObjectStreamClass.lookup may not throw any exception (except the default ones like Error, NPE, ...). O man, it is a checked exception... How ugly. I see why you don't want to do that. If you do like in your patch then at least document this behavior. It is slightly confusing that ObjectStreamClass.lookup() returns a non-null result, but getFields() suddenly returns an empty ObjectStreamField array as if there are no Serializable fields. Now user code has no real way to check whether that is because the ObjectStreamClass is invalid (because of bogus serialPersistentFields) or because it just has no serializable fields. Ok. I may add some documentation on that. One other suggestion. Might it make sense to do the caching, comparing and sorting in getSerialPersistentFields()? As it is done now we seem to copy and sort this array a lot of times. Cheers, Mark signature.asc Description: This is a digitally signed message part ___ Classpath-patches mailing list Classpath-patches@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-patches
Re: [cp-patches] RFC: Patch for duplicate entries in serialPersistentFields
Hi Mark, Mark Wielaard wrote: Hi Guilhem, On Sun, 2005-12-11 at 16:41 +0100, Guilhem Lavaux wrote: Why not do similar and throw the InvalidClassException from ObjectStreamClass.lookup()? (But then document that clearly in our version of course.) Because we would not have the same API. ObjectStreamClass.lookup may not throw any exception (except the default ones like Error, NPE, ...). O man, it is a checked exception... How ugly. I see why you don't want to do that. If you do like in your patch then at least document this behavior. It is slightly confusing that ObjectStreamClass.lookup() returns a non-null result, but getFields() suddenly returns an empty ObjectStreamField array as if there are no Serializable fields. Now user code has no real way to check whether that is because the ObjectStreamClass is invalid (because of bogus serialPersistentFields) or because it just has no serializable fields. Ok. I may add some documentation on that. One other suggestion. Might it make sense to do the caching, comparing and sorting in getSerialPersistentFields()? As it is done now we seem to copy and sort this array a lot of times. Yes we can factorize some code. However the double sort in setFields is necessary: first we compare the names and then we want the full sort relatively also to types. Cheers, Guilhem. ___ Classpath-patches mailing list Classpath-patches@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-patches
[cp-patches] Re: RFC: Patch for duplicate entries in serialPersistentFields
Why not do similar and throw the InvalidClassException from
ObjectStreamClass.lookup()?
(But then document that clearly in our version of course.)
Because we would not have the same API. ObjectStreamClass.lookup may not
throw any exception (except the default ones like Error, NPE, ...).
O man, it is a checked exception... How ugly.
I see why you don't want to do that.
This is an ugly suggestion, but it may provide a way to achieve compatibility
with this particular broken part of the spec.
Jeroen pointed out to me a while back that you can use generics to throw an
unchecked exception:
private class EvilT extends Throwable {
private static void evilThrow(Throwable t) throws T {
throw (T) e; // Unchecked cast, will always succeed!
}
}
...
EvilRuntimeException.evilThrow(new InvalidClassException());
This works because EvilRuntimeException.evilThrow only declares that it will
throw RuntimeException but the cast from InvalidClassException to
RuntimeException is an unchecked one which disappears at runtime. So this code
really will throw an InvalidClassException from a method that doesn't declare
itself as throwing one.
Evil! But maybe the way to go in this case?
Stuart.
___
Classpath-patches mailing list
Classpath-patches@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath-patches
Re: [cp-patches] Re: RFC: Patch for duplicate entries in serialPersistentFields
Stuart Ballard wrote: Jeroen pointed out to me a while back that you can use generics to throw an unchecked exception: There's also a way to do this without using JDK 1.5 stuff, but it's even uglier :-) Construct a class (dynamically) that has a default constructor that simply throws whatever exception you want. Then invoke Class.newInstance() on the class. -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com ___ Classpath-patches mailing list Classpath-patches@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-patches
Re: [cp-patches] Re: RFC: Patch for duplicate entries in serialPersistentFields
Archie Cobbs wrote: Stuart Ballard wrote: Jeroen pointed out to me a while back that you can use generics to throw an unchecked exception: There's also a way to do this without using JDK 1.5 stuff, but it's even uglier :-) Construct a class (dynamically) that has a default constructor that simply throws whatever exception you want. Then invoke Class.newInstance() on the class. Bah ! I would rather use a native function that will throw directly InvalidClassException. The problem is that's will be anyway hidden to the general user and that he/she may be surprised getting that sort of exception. Guilhem. ___ Classpath-patches mailing list Classpath-patches@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-patches
[cp-patches] FYI: Add branch rules to hacking guide
Hi,
This adds the branch rules we discussed on the main list to the Hacking
Guide.
2005-12-11 Mark Wielaard [EMAIL PROTECTED]
* doc/hacking.texinfo: Add section on branches.
I also added a page to the developer wiki to document all branches:
http://developer.classpath.org/mediation/ClasspathBranches
Committed,
Mark
Index: hacking.texinfo
===
RCS file: /cvsroot/classpath/classpath/doc/hacking.texinfo,v
retrieving revision 1.38
diff -u -r1.38 hacking.texinfo
--- hacking.texinfo 15 Jul 2005 08:54:10 - 1.38
+++ hacking.texinfo 11 Dec 2005 21:27:18 -
@@ -83,6 +83,11 @@
Working on the code, Working with others
+* Branches::
+* Writing ChangeLogs::
+
+Working with branches
+
* Writing ChangeLogs::
Programming Goals
@@ -807,10 +812,68 @@
constraints).
@menu
+* Branches::
+* Writing ChangeLogs::
[EMAIL PROTECTED] menu
+
[EMAIL PROTECTED] Branches, Writing ChangeLogs, Hacking Code, Hacking Code
[EMAIL PROTECTED] node-name, next, previous, up
[EMAIL PROTECTED] Working with branches
+
+Sometimes it is necessary to create branch of the source for doing new
+work that is disruptive to the other hackers, or that needs new
+language or libraries not yet (easily) available.
+
+After discussing the need for a branch on the main mailinglist with
+the other hackers explaining the need of a branch and suggestion of
+the particular branch rules (what will be done on the branch, who will
+work on it, will there be different commit guidelines then for the
+mainline trunk and when is the branch estimated to be finished and
+merged back into the trunk) every GNU Classpath hacker with commit
+access should feel free to create a branch. There are however a couple
+of rules that every branch should follow:
+
[EMAIL PROTECTED]
+
[EMAIL PROTECTED] All branches ought to be documented in the developer wiki at
[EMAIL PROTECTED]://developer.classpath.org/mediation/ClasspathBranches}, so
+we can know which are live, who owns them, and when they die.
+
[EMAIL PROTECTED] Some rules can be changed on a branch. In particular the branch
+maintainer can change the review requirements, and the requirement of
+keeping things building, testing, etc, can also be lifted. (These
+should be documented along with the branch name and owner if they
+differ from the trunk.)
+
[EMAIL PROTECTED] Requirements for patch email to classpath-patches and for paperwork
[EMAIL PROTECTED] be lifted. See @ref{Requirements}.
+
[EMAIL PROTECTED] A branch should not see it as ``private'' or
+``may be broken at random times''. It should be as much as possible
+something that you work on with a team (and if there is no team - yet
+- then there is nothing as bad as having a completely broken build to
+get others to help out).
+
[EMAIL PROTECTED] Merges from the trunk to a branch are at the discretion of the
+branch maintainer.
+
[EMAIL PROTECTED] A merge from a branch to the trunk is treated like any other patch.
+In particular, it has to go through review, it must satisfy all the
+trunk requirements (build, regression test, documentation).
+
[EMAIL PROTECTED] There may be additional timing requirements on merging a branch to
+the trunk depending on the release schedule, etc. For instance we may
+not want to do a branch merge just before a release.
+
[EMAIL PROTECTED] itemize
+
+If any of these rules are unclear please discuss on the list first.
+
[EMAIL PROTECTED]
* Writing ChangeLogs::
@end menu
[EMAIL PROTECTED] Writing ChangeLogs, , Hacking Code, Hacking Code
[EMAIL PROTECTED] Writing ChangeLogs, , Branches, Hacking Code
@comment node-name, next, previous, up
@section Documenting what changed when with ChangeLog entries
signature.asc
Description: This is a digitally signed message part
___
Classpath-patches mailing list
Classpath-patches@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath-patches
Re: [Jessie-discuss] Re: RFC: merging GNU Crypto and Jessie
Hi, On Thu, 2005-12-08 at 20:07 -0800, Casey Marshall wrote: On Dec 8, 2005, at 11:25 AM, Anthony Green wrote: My only concern is there be some trivial mechanism to generate a US export-friendly version GNU Classpath, like.. $ configure --disable-munitions Good point. We should have a switch for this in configure. Probably adding the appropriate lines to standard.omit will do it? Also, J2SE has the ExemptionMechanism class, which is currently not much more than a stub in Classpath. I mean, it's trivially easy to get around this restriction with free software -- you just change the source -- but including a real implementation of that class may be enough to satisfy these restrictions. I wouldn't use --disable-munitions, though. The US Government spooks believe crypto is a munition, but I don't. My understanding is that the US government has made it simpler to distribute FOSS crypto code in recent years, but I have a situation where I actually need to strip all export controlled crypto. To be honest, I'm not sure what specific algorithms this means. It's possible that Classpath already contains some. Yes. RSA is export-controlled for key sizes larger than 40 bits, IIRC. In any case, it would be nice if the configury and build process could automatically handle the absence of crypto algorithms. Should this disable compiling the standard crypto library bits, too (javax.crypto and javax.net.ssl), or just the algorithms? As far as I know even the hooks fall under this. Although I am not against having some configure options to put parts of the core library into standards.omit I don't think it is really needed. When the first parts of GNU Crypto was merged into GNU Classpath (and indirectly into GCC and other projects) FSF legal made sure that all FSF distributed GNU software would be able to be distributed (as source) from ftp.gnu.org from mirrors. See the statement on savannah: https://savannah.gnu.org/faq/?admin=group_id=5802question=Savannah_-_Is_there_any_restriction_on_cryptographic_software.txt Similar notices have been placed on ftp.gnu.org and other distribution sites (ftp://ftp.gnu.org/CRYPTO.README). We really don't need more then that as long as we distribute GNU Classpath as Free Software. 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: [Jessie-discuss] Re: RFC: merging GNU Crypto and Jessie
Hi Anthony, On Sun, 2005-12-11 at 03:47 -0800, Anthony Green wrote: You're missing my point, which is that _I_ have a requirement to redistribute GNU Classpath with no export-restricted software. What's good enough for the FSF is not good enough for me. It would nice if there was a convenient way of doing this. Sure, and please do propose a patch to help you if you are willing to maintain that. But beware that you probably need guidance from a legal adviser to make sure you strip out and distribute only those parts not covered by the BXA. All I was saying is that it isn't a necessity for GNU Classpath as a project, or people redistributing GNU Classpath as Free Software. And binary derivatives from distributions and other projects already have to handle this if they have the misfortune to be distributed from inside the USA. See for example the Debian crypto guidelines [1] on how to deal with the the BIS/ENC notification procedures (I assume Fedora has similar guidelines). So, the situation doesn't change from when we first started distributing crypto hooks and algorithms with GNU Classpath [2]. Cheers, Mark [1] http://www.debian.org/legal/cryptoinmain [2] http://lists.gnu.org/archive/html/classpath/2004-08/msg00076.html signature.asc Description: This is a digitally signed message part ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: [Jessie-discuss] Re: RFC: merging GNU Crypto and Jessie
On Sun, 2005-12-11 at 12:40 +0100, Mark Wielaard wrote: As far as I know even the hooks fall under this. Although I am not against having some configure options to put parts of the core library into standards.omit I don't think it is really needed. When the first parts of GNU Crypto was merged into GNU Classpath (and indirectly into GCC and other projects) FSF legal made sure that all FSF distributed GNU software would be able to be distributed (as source) from ftp.gnu.org from mirrors. See the statement on savannah: https://savannah.gnu.org/faq/?admin=group_id=5802question=Savannah_-_Is_there_any_restriction_on_cryptographic_software.txt Similar notices have been placed on ftp.gnu.org and other distribution sites (ftp://ftp.gnu.org/CRYPTO.README). We really don't need more then that as long as we distribute GNU Classpath as Free Software. You're missing my point, which is that _I_ have a requirement to redistribute GNU Classpath with no export-restricted software. What's good enough for the FSF is not good enough for me. It would nice if there was a convenient way of doing this. Merging GNU Crypto into GNU Classpath without regards to this issue is moving in a bad direction for me (and perhaps others). AG ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Introducing builder.classpath.org
Hi Leo, On Fri, 2005-12-09 at 22:26 -0800, Leo Simons wrote: On Thu, Dec 08, 2005 at 02:49:18PM +0100, Mark Wielaard wrote: We are currently using Tom Tromey's build scripts Could I get a URL for those? Sounds like a good use case for a certain project I'm working on :-) :-) I was afraid someone would ask for them. Especially someone who actually has a nice, clean, auto-builder setup like gump... :) I would like to also have gump running on builder. But I thought it was good to have at least the bootstrapping environment (runtime, compiler and core libraries plus rudimentary core test suites) available before doing the more higher level setups. You are right, we shouldn't just have them available on builder.classpath.org, but distribute them more widely so others can also easily setup auto-builders/testers. The scripts aren't that complicated though, they are basically helpers for checking out, configuring, building and running some standard targets. Tom, would you be OK with setting up a new classpath CVS module builder and have the scripts available there with a rudimentary README how to bootstrap an auto-tester? Cheers, Mark -- Escape the Java Trap with GNU Classpath! http://www.gnu.org/philosophy/java-trap.html Join the community at http://planet.classpath.org/ signature.asc Description: This is a digitally signed message part ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: [Jessie-discuss] Re: RFC: merging GNU Crypto and Jessie
On Sun, 2005-12-11 at 13:50 +0100, Mark Wielaard wrote: All I was saying is that it isn't a necessity for GNU Classpath as a project, or people redistributing GNU Classpath as Free Software. I'm being told that there are situations where this second part is not true, which is why I need to remove the export controlled code. AG ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: [Jessie-discuss] Re: RFC: merging GNU Crypto and Jessie
Hi Anthony, On Sun, 2005-12-11 at 05:38 -0800, Anthony Green wrote: On Sun, 2005-12-11 at 13:50 +0100, Mark Wielaard wrote: All I was saying is that it isn't a necessity for GNU Classpath as a project, or people redistributing GNU Classpath as Free Software. I'm being told that there are situations where this second part is not true, which is why I need to remove the export controlled code. If there are situations where you are not able to (re)distribute the GNU Classpath source code and/or follow the the BIS/ENC notification procedures as done by the various GNU/Linux distros to distribute binary derivatives of GNU Classpath as Free Software works then please let us know. And follow up with some more concrete information about these situations. I am happy to discuss this with FSF legal and see if there are procedures to help in your situation. How are these situations different from distributing GPG, GCC, Mozilla, OpenSSH, etc? 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: [Jessie-discuss] Re: RFC: merging GNU Crypto and Jessie
On Sun, 2005-12-11 at 15:19 +0100, Mark Wielaard wrote: If there are situations where you are not able to (re)distribute the GNU Classpath source code and/or follow the the BIS/ENC notification procedures as done by the various GNU/Linux distros to distribute binary derivatives of GNU Classpath as Free Software works then please let us know. I don't think my situation is relevant to public Linux distros. I'm told the rules are different when you want to make a private distribution of FOSS crypto code (ie. not easily found on a public web/ftp site). In my specific case, it's easier just to remove the problematic code completely. AG ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: StatCVS runs free!
Hi David, On Wed, 2005-12-07 at 16:58 +, David Gilbert wrote: ...I decided it couldn't be too hard to get StatCVS[1] working the same way (StatCVS uses JFreeChart for the charts it generates). Here's the latest run for Mauve CVS generated, for the first time, with JamVM, GNU Classpath and cairo-java: http://www.object-refinery.com/classpath/mauve/statcvs/ So cool! The graphs look fine and smooth. It seems the characters printed vertically (like on the y-axis) seems rotated the wrong way. Alas, the process is too memory hungry to process (on my machine) the 226MB log file generated for Classpath CVS. If you use Kaffe it has some support for tracking memory issues through JVMPI. See http://gnu.wildebeest.org/diary/index.php?p=104 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
lists.gnu.org and savannah.gnu.org (CVS) updates
Hi all, I talked to the GNU system administrators about the slowness of the mailinglists at times. They told me they are working on a completely new setup. Today I received the latest FRee Software Foundation Bulletin which has an article about the cool new machines that have been bought, how to install LinuxBIOS on it and what they are planning to do with them. I haven't seen this online yet, but if you become an FSF associate member you will get the paper version [1]. I'll let you know when it is online. It might take some time (weeks/months) till the whole infrastructure has moved though. It will reduce the amount of spam we need to moderate considerably and make the lists more snappy. Also savannah has seen some updates. - You can now use rsync to get a full copy of the CVS repostitory: http://savannah.gnu.org/forum/forum.php?forum_id=4142 - There is support for GNU Arch http://savannah.gnu.org/forum/forum.php?forum_id=4165 (I don't think we want to switch to that, but when subversion support hits savannah we might want to use that. No timeline yet on when/if that will be available though.) - All CVS services have now been put on cvs.savannah.gnu.org http://savannah.gnu.org/forum/forum.php?forum_id=4168 You will notice that last one when running CVS update. It will explain that you have to update the Root of your CVS working directory. If you the cvsutils installed then you can easily switch to the new CVS location by running this in your CVS working copy: cvschroot savannah-user-name@cvs.savannah.gnu.org:/cvsroot/classpath Cheers, Mark [1] Follow this link http://member.fsf.org/join?referrer=6 and make me happy! I only need 2 more referrers to receive this great gift: http://www.fsf.org/associate/referral-2004 signature.asc Description: This is a digitally signed message part ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: lists.gnu.org and savannah.gnu.org (CVS) updates
On Sun, 2005-12-11 at 19:47 +0100, Mark Wielaard wrote: - All CVS services have now been put on cvs.savannah.gnu.org http://savannah.gnu.org/forum/forum.php?forum_id=4168 You will notice that last one when running CVS update. It will explain that you have to update the Root of your CVS working directory. If you the cvsutils installed then you can easily switch to the new CVS location by running this in your CVS working copy: cvschroot savannah-user-name@cvs.savannah.gnu.org:/cvsroot/classpath And for those of you using anonymous CVS you need to switch to pserver: $ cvschroot :pserver:[EMAIL PROTECTED]:/cvsroot/classpath 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: lists.gnu.org and savannah.gnu.org (CVS) updates
Mark Wielaard wrote: - All CVS services have now been put on cvs.savannah.gnu.org http://savannah.gnu.org/forum/forum.php?forum_id=4168 You will notice that last one when running CVS update. It will explain that you have to update the Root of your CVS working directory. If you the cvsutils installed then you can easily switch to the new CVS location by running this in your CVS working copy: cvschroot savannah-user-name@cvs.savannah.gnu.org:/cvsroot/classpath And for those of you using anonymous CVS you need to switch to pserver: $ cvschroot :pserver:[EMAIL PROTECTED]:/cvsroot/classpath Hmm.. could this new infrastructure include possible a switchover from CVS to Subversion? (I'm so used to SVN now that CVS is gotten pretty gross to deal with). -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Proposal: Graphics2D rewrite branch
Hi, On Wed, 2005-12-07 at 12:05 -0700, Tom Tromey wrote: Tom == Thomas Fitzsimmons [EMAIL PROTECTED] writes: Tom I'd like to propose a new branch in the GNU Classpath CVS repository: Tom graphics2d-rewrite. Patches to this branch should be sent to Tom classpath-patches@gnu.org with a subject line prefix of [g2d rewrite]. Tom Commit policy is the same as GNU Classpath trunk. I say go for it. Yes, if you think you need a branch for this rewrite please do (call it something descriptive like cairo-graphics2d). I can see that if you want to just phase out GdkGraphics and always use a new setup around CairoGraphics2D that it might be nice to have a branch to not disturb the work of others. But as said by some others if at all possible do the work on the trunk. That does make it easier for others to follow/help out. Furthermore I think we should adopt gcc-ish branch rules. These are pretty reasonable and have proven to work well in practice. Namely: * Any Classpath developer can make a branch for any purpose. All branches ought to be documented somewhere, so we can know which are live, who owns them, and when they die. I don't know where we would put this though (suggestions?) I'll create a page in the wiki http://developer.classpath.org/mediation/ClasspathBranches * Some rules can be changed on a branch. In particular the branch maintainer can change the review requirements, and the requirement of keeping things building, testing, etc, can also be lifted. (These should be documented along with the branch name and owner if they differ from the trunk.) Requirements for patch email to classpath-patches and for paperwork *cannot* be lifted. And you should not see it as private or may be broken at random times. It should be as much as possible something that you work with a team on (and if there is no team - yet - then there is nothing as bad as having a completely broken build to get others to help out). * Merges from the trunk to a branch are at the discretion of the branch maintainer. * A merge from a branch to the trunk is treated like any other patch. In particular, it has to go through review, it must satisfy all the trunk requirements (build, regression test, documentation). This rule prevents folks from working around trunk rules by making a branch :-) These rules sound very good. I will add them to the Hacking Guide. There may be additional timing requirements on merging a branch to the trunk depending on the release schedule, etc. For instance we may not want to do a branch merge just before a release. Good point. I believe we do communicate very well on the mailing-lists. So I don't think this will ever be a problem. But the release master (which seems to be me atm, although we never officially created that role) should have a veto in the last few weeks before a stable release for any branch - trunk merges. 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: Proposal: Graphics2D rewrite branch
Mark == Mark Wielaard [EMAIL PROTECTED] writes: Requirements for patch email to classpath-patches and for paperwork *cannot* be lifted. Mark And you should not see it as private or may be broken at random Mark times. It should be as much as possible something that you work with a Mark team on (and if there is no team - yet - then there is nothing as bad as Mark having a completely broken build to get others to help out). Actually, I think it is reasonable to have a may be broken branch. In fact this is one of the main reasons for having a branch -- if you can keep stuff building and working, in many cases you won't need a branch at all. As for private, I think we should be careful. Nothing in Classpath can truly be private, the point is we're building something in common. But it can be reasonable to have a rule like, 'please ask me before committing to this branch'. Tom ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Introducing builder.classpath.org
Mark == Mark Wielaard [EMAIL PROTECTED] writes: Mark Tom, would you be OK with setting up a new classpath CVS module Mark builder and have the scripts available there with a rudimentary README Mark how to bootstrap an auto-tester? Yeah, I don't mind. Aside from the embarrassment that is ;-) Tom ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
[commit-cp] classpath ./ChangeLog lib/copy-vmresources.sh.in
CVSROOT:/cvsroot/classpath Module name:classpath Branch: Changes by: Guilhem Lavaux [EMAIL PROTECTED] 05/12/11 13:14:05 Modified files: . : ChangeLog lib: copy-vmresources.sh.in Log message: 2005-12-11 Guilhem Lavaux [EMAIL PROTECTED] * lib/copy-vmresources.sh.in: Added some '.' after find. CVSWeb URLs: http://savannah.gnu.org/cgi-bin/viewcvs/classpath/classpath/ChangeLog.diff?tr1=1.5789tr2=1.5790r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/classpath/classpath/lib/copy-vmresources.sh.in.diff?tr1=1.2tr2=1.3r1=textr2=text
[commit-cp] classpath ./ChangeLog doc/hacking.texinfo
CVSROOT:/cvsroot/classpath Module name:classpath Branch: Changes by: Mark Wielaard [EMAIL PROTECTED] 05/12/11 21:55:08 Modified files: . : ChangeLog doc: hacking.texinfo Log message: * doc/hacking.texinfo: Add section on branches. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/classpath/classpath/ChangeLog.diff?tr1=1.5790tr2=1.5791r1=textr2=text http://cvs.savannah.gnu.org/viewcvs/classpath/classpath/doc/hacking.texinfo.diff?tr1=1.38tr2=1.39r1=textr2=text
