Re: [cp-patches] RFC: File/VMFile improvement
Hi there again,
What about this pending patch? I didn't quite understand the discussion
around it. IMO the file handling is very platform dependend and while we
could handle this generically, I find this path very inconvenient, as it
clutters the code, where it could be easy, and it certainly isn't very
good for efficiency. I agree that this is not necessarily VM dependent,
but instead platform dependend? But I don't think that we should
introduce some kind of platform-layer that complements the VM layer in
some way. As Jeroen already pointed out, often times the VM is somewhat
tied to the platform(s) it supports and thus can just as well provide a
reasonable implementation of file handling.
As for the VMBlahSocketImpl, I would very much like to have this mess
cleaned up (I know, I introduced this in the first place). I came to
think of that we don't really need this anyway, as the specs already
have a way of abstracting this stuff out (by defining the SocketImpl
abstract classes) and we simply added another unnecessary layer here.
So may I commit this change to the VMFile class for now? Or should we go
another way of splitting out platform dependend stuff?
/Roman
Roman Kennke schrieb:
Jeroen Frijters schrieb:
Hi Roman,
The attached patch file is empty.
Ugh. My bad. Here it is.
/Roman
Index: vm/reference/java/io/VMFile.java
===
RCS file: /cvsroot/classpath/classpath/vm/reference/java/io/VMFile.java,v
retrieving revision 1.8
diff -u -1 -2 -r1.8 VMFile.java
--- vm/reference/java/io/VMFile.java7 Jun 2006 15:09:40 - 1.8
+++ vm/reference/java/io/VMFile.java15 Aug 2006 15:41:49 -
@@ -29,24 +29,27 @@
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 java.io;
+import java.net.MalformedURLException;
+import java.net.URL;
+
import gnu.classpath.Configuration;
import gnu.java.io.PlatformHelper;
/**
* @author Michael Koch ([EMAIL PROTECTED])
*/
final class VMFile
{
// FIXME: We support only case sensitive filesystems currently.
static final boolean IS_CASE_SENSITIVE = true;
static final boolean IS_DOS_8_3 = false;
@@ -200,24 +203,126 @@
{
int pos = PlatformHelper.lastIndexOfSeparator(path);
if (pos == -1)
return path;
if (PlatformHelper.endWithSeparator(path))
return ;
return path.substring(pos + File.separator.length());
}
/**
+ * Returns the path as an absolute path name. The value returned is the
+ * current directory plus the separatory string plus the path of the file.
+ * The current directory is determined from the codeuser.dir/code system
+ * property.
+ *
+ * @param path the path to convert to absolute path
+ *
+ * @return the absolute path that corresponds to codepath/code
+ */
+ static String getAbsolutePath(String path)
+ {
+if (File.separatorChar == '\\'
+ path.length() 0 path.charAt (0) == '\\')
+ {
+// On Windows, even if the path starts with a '\\' it is not
+// really absolute until we prefix the drive specifier from
+// the current working directory to it.
+return System.getProperty (user.dir).substring (0, 2) + path;
+ }
+else if (File.separatorChar == '\\'
+ path.length() 1 path.charAt (1) == ':'
+ ((path.charAt (0) = 'a' path.charAt (0) = 'z')
+ || (path.charAt (0) = 'A' path.charAt (0) = 'Z')))
+ {
+// On Windows, a process has a current working directory for
+// each drive and a path like G:foo\bar would mean the
+// absolute path G:\wombat\foo\bar if \wombat is the
+// working directory on the G drive.
+String drvDir = null;
+try
+ {
+drvDir = new File (path.substring (0, 2)).getCanonicalPath();
+ }
+catch (IOException e)
+ {
+drvDir = path.substring (0, 2) + \\;
+ }
+
+// Note: this would return C:\\. for the path C:., if \
+// is the working folder on the C drive, but this is
+// consistent with what Sun's JRE 1.4.1.01 actually returns!
+if (path.length() 2)
+ return drvDir + '\\' + path.substring (2, path.length());
+else
+ return drvDir;
+ }
+else if (path.equals())
+ return System.getProperty (user.dir);
+
RE: [cp-patches] RFC: File/VMFile improvement
Roman Kennke wrote: What about this pending patch? I certainly would like to see it go. Regards, Jeroen
Re: [cp-patches] RFC: File/VMFile improvement
Hi,
Jeroen Frijters schrieb:
Roman Kennke wrote:
What about this pending patch?
I certainly would like to see it go.
Ok. Dalibor also expressed that he'd like to see it in. So here it goes.
2006-08-21 Roman Kennke [EMAIL PROTECTED]
* java/io/File.java
(getAbsolutePath): Fetch absolute path from
VMFile.getAbsolutePath(). Moved actual impl to there.
(isAbsolute): Let VMFile determine the absoluteness.
(toURL): Let VMFile convert the filename.
* vm/reference/java/io/VMFile.java
(getAbsolutePath): New method.
(isAbsolute): New method.
(toURL): New method.
/Roman
Index: java/io/File.java
===
RCS file: /cvsroot/classpath/classpath/java/io/File.java,v
retrieving revision 1.65
diff -u -1 -2 -r1.65 File.java
--- java/io/File.java 29 Jun 2006 09:59:57 - 1.65
+++ java/io/File.java 21 Aug 2006 09:21:14 -
@@ -418,63 +418,26 @@
* This method returns the path of this file as an absolute path name.
* If the path name is already absolute, then it is returned. Otherwise
* the value returned is the current directory plus the separatory
* string plus the path of the file. The current directory is determined
* from the codeuser.dir/code system property.
*
* @return The absolute path of this file
*/
public String getAbsolutePath()
{
if (isAbsolute())
return path;
-else if (separatorChar == '\\'
- path.length() 0 path.charAt (0) == '\\')
- {
-// On Windows, even if the path starts with a '\\' it is not
-// really absolute until we prefix the drive specifier from
-// the current working directory to it.
-return System.getProperty (user.dir).substring (0, 2) + path;
- }
-else if (separatorChar == '\\'
- path.length() 1 path.charAt (1) == ':'
- ((path.charAt (0) = 'a' path.charAt (0) = 'z')
- || (path.charAt (0) = 'A' path.charAt (0) = 'Z')))
- {
-// On Windows, a process has a current working directory for
-// each drive and a path like G:foo\bar would mean the
-// absolute path G:\wombat\foo\bar if \wombat is the
-// working directory on the G drive.
-String drvDir = null;
-try
- {
-drvDir = new File (path.substring (0, 2)).getCanonicalPath();
- }
-catch (IOException e)
- {
-drvDir = path.substring (0, 2) + \\;
- }
-
-// Note: this would return C:\\. for the path C:., if \
-// is the working folder on the C drive, but this is
-// consistent with what Sun's JRE 1.4.1.01 actually returns!
-if (path.length() 2)
- return drvDir + '\\' + path.substring (2, path.length());
-else
- return drvDir;
- }
-else if (path.equals())
- return System.getProperty (user.dir);
else
- return System.getProperty (user.dir) + separatorChar + path;
+ return VMFile.getAbsolutePath(path);
}
/**
* This method returns a codeFile/code object representing the
* absolute path of this object.
*
* @return A codeFile/code with the absolute path of the object.
*
* @since 1.2
*/
public File getAbsoluteFile()
{
@@ -648,33 +611,25 @@
/**
* This method returns true if this object represents an absolute file
* path and false if it does not. The definition of an absolute path varies
* by system. As an example, on GNU systems, a path is absolute if it starts
* with a /.
*
* @return codetrue/code if this object represents an absolute
* file name, codefalse/code otherwise.
*/
public boolean isAbsolute()
{
-if (separatorChar == '\\')
- return path.startsWith(dupSeparator) ||
- (path.length() 2
- ((path.charAt(0) = 'a' path.charAt(0) = 'z') ||
- (path.charAt(0) = 'A' path.charAt(0) = 'Z'))
- path.charAt(1) == ':'
- path.charAt(2) == '\\');
-else
- return path.startsWith(separator);
+return VMFile.isAbsolute(path);
}
/**
* This method tests whether or not the file represented by this object
* is a directory. In order for this method to return codetrue/code,
* the file represented by this object must exist and be a directory.
*
* @return codetrue/code if this file is a directory, codefalse/code
* otherwise
*
* @exception SecurityException If reading of the file is not permitted
*/
@@ -989,32 +944,25 @@
/**
* This method returns a codeURL/code with the codefile:/code
* protocol that represents this file. The exact form of this URL is
* system dependent.
*
* @return A codeURL/code for this object.
*
* @exception MalformedURLException If the URL cannot be created
* successfully.
*/
public URL toURL() throws MalformedURLException
Re: [cp-patches] RFC: File/VMFile improvement
Roman Kennke wrote: Hi there again, What about this pending patch? I didn't quite understand the discussion around it. IMO the file handling is very platform dependend and while we could handle this generically, I find this path very inconvenient, as it clutters the code, where it could be easy, and it certainly isn't very good for efficiency. I agree that this is not necessarily VM dependent, but instead platform dependend? But I don't think that we should introduce some kind of platform-layer that complements the VM layer in some way. As Jeroen already pointed out, often times the VM is somewhat tied to the platform(s) it supports and thus can just as well provide a reasonable implementation of file handling. Sorry, that was kind of a bikeshed issue. VM-vs-platform isn't *that* big a deal, it just feels clumsy, and has been used as an I don't understand this umbrella in the past. As for the VMBlahSocketImpl, I would very much like to have this mess cleaned up (I know, I introduced this in the first place). I came to think of that we don't really need this anyway, as the specs already have a way of abstracting this stuff out (by defining the SocketImpl abstract classes) and we simply added another unnecessary layer here. This is true, and it's the same with java.nio (it's essentially a service provider interface through the SelectorProvider class). There is *some* value in isolating these platform-specific bits as much as possible (and keeping them, and the amount of JNI code, to a minimum!), and making porting Classpath a low-barrier-to-entry. What, if any, performance tradeoffs there are is a good question, however. So may I commit this change to the VMFile class for now? Or should we go another way of splitting out platform dependend stuff? Sorry for not looking at it. The patch looks reasonable to me. Real code is always preferable to me bickering about vaporware :-)
RE: [cp-patches] RFC: File/VMFile improvement
Casey Marshall wrote: Tom Tromey wrote: It seems to me that this is an area we haven't handled very well: this isn't really a VM thing per se -- the code could very well be written in pure java -- but rather a platform thing. I agree that adding special cases in File just makes the code uglier and uglier. But, we could delegate to a pure java platform class, with instances for posixy, Windows, Windows CE, etc, and share the code across all VMs. We do something vaguely similar to this in libgcj (though in the specific case of File we put the platform stuff in native code). FWIW I agree. Some of us were chatting about this on IRC, and not only are these VM interfaces more often than not platform interfaces (or with some things, all they rely on is JNI and standard C), but they do lead to performance hits (witness our direct ByteBuffer). I think putting some design thought into this is a good idea, because right now I don't think we have any clear idea about what the scope or purpose of VM/platform interfaces are. Right now, it looks like it's just an ad-hoc catch-all for anything that can't be done in pure Java -- you slap a VM class on it, and hack up the core class. I disagree. In most cases the VM decides what platforms to support and how to do this, so it does make some sense to move this stuff into the VM interface. This combined with the fact that native methods are very inconvenient for some VMs (like IKVM), we decided to add this extra indirection layer where the VM can decide to do things differently. I realise that for gcj people it may look like there is a significant difference between (e.g.) VMFile and VMThread, but other VMs replace both these classes. BTW, if there are specific cases (like ByteBuffer you mention), I'm more than willing to discuss alternatives to find a better alternative to suites everyone. I think that in many cases the VM interface design suffers from the fact that not enough VM implementers participate in the design. Regards, Jeroen
Re: [cp-patches] RFC: File/VMFile improvement
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jeroen Frijters wrote:
Casey Marshall wrote:
Tom Tromey wrote:
It seems to me that this is an area we haven't handled very
well: this
isn't really a VM thing per se -- the code could very well be
written in pure java -- but rather a platform thing.
I agree that adding special cases in File just makes the code uglier
and uglier. But, we could delegate to a pure java platform class,
with instances for posixy, Windows, Windows CE, etc, and share the
code across all VMs.
We do something vaguely similar to this in libgcj (though in the
specific case of File we put the platform stuff in native code).
FWIW I agree. Some of us were chatting about this on IRC, and not only
are these VM interfaces more often than not platform interfaces (or
with some things, all they rely on is JNI and standard C), but they do
lead to performance hits (witness our direct ByteBuffer).
I think putting some design thought into this is a good idea, because
right now I don't think we have any clear idea about what the scope or
purpose of VM/platform interfaces are. Right now, it looks like it's
just an ad-hoc catch-all for anything that can't be done in
pure Java -- you slap a VM class on it, and hack up the core class.
I disagree. In most cases the VM decides what platforms to support and
how to do this, so it does make some sense to move this stuff into the
VM interface. This combined with the fact that native methods are very
inconvenient for some VMs (like IKVM), we decided to add this extra
indirection layer where the VM can decide to do things differently.
OK. But I could argue back that VMs for whom native methods don't work
are broken as far a Java goes. I think you're saying that because
platform details, like how files and sockets work, are easier for you to
implement in the VM layer, that they're necessarily VM-specific, and
not platform-specific. I couldn't disagree more with that.
There's also no rule saying that you have to use Classpath's version of
a class in your VM/system. If we can set things up such that as long as
you implement these classes *to the Java specification,* everything
works, you can have whatever implementation suits your system, and just
load that class first.
I realise that for gcj people it may look like there is a significant
difference between (e.g.) VMFile and VMThread, but other VMs replace
both these classes.
Yeah, if I were writing a VM for Windows, I'd re-implement both. But,
VMThread would necessarily be tied to the VM's internals; VMFile would
be tied to how Windows handles files, having little to do with the VM
itself.
BTW, if there are specific cases (like ByteBuffer you mention), I'm more
than willing to discuss alternatives to find a better alternative to
suites everyone. I think that in many cases the VM interface design
suffers from the fact that not enough VM implementers participate in the
design.
ByteBuffer (and Channels and Selectors -- that is, things that are
basically created with factory methods and service providers) are a
little different, because we can, e.g., control what version we use at
runtime with system properties. So posixy systems can return a fast,
native implementation, and other systems can return their own
implementation.
If we keep the VM* interface thing, I think a better design is to stop
passing the core class to a static VM method, with the native state
inside the core class, and just make these VM classes instance classes,
with the native state associated with the instance.
An example I'm thinking of is VMPlainSocketImpl. PlainSocketImpl has an
int field for the native file descriptor (and that makes just plain no
sense, either way), and passes itself to VMPlainSocketImpl methods,
which rips the descriptor integer out of that instance. I think it's
better to make VMPlainSocketImpl an instance class, and keep the native
state in that instance; in our default implementation, this would be an
integer file descriptor, and we'd have method pairs like so in the VM class:
public void vmMethod(args...) throws IOException
{
vmMethod(native_fd, args...);
}
private static native void vmMethod(int native_fd, args...) throws...
So the *interface* for the VM class is the public instance method, and
is the only one a VM writer needs to implement. Our default
implementation then just implements the function in the obvious, fast
way for POSIX. Maybe you can explain why passing an object to a static
method makes more sense than that (I can't see how; all it adds is a
litany of JNI calls to *every* method call).
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.3 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iQEVAwUBROLRteRILCRAfKHCAQK1dAf/W2jQgbJ1h3Ru9+z3unRfAylRMp308vpk
Dj5DCYfxHzQUnoYN4Dd+VeCmxrenaTxzj+WBcbeJZC1E5PW775q3WhKUOLgsrJ/z
SbeSq6VGarUYx+GQ3apTy0vrPtB+apcMY2scPJ21iyiGrK+9AsQ+S6b1CHDUk/K1
RE: [cp-patches] RFC: File/VMFile improvement
Hi Casey, I just about exploded when I read the first part of your message ;-) But at the end of your message I discovered that we completely misunderstood each other and that we agree much more than we disagree. With that in mind, here are my responses including to the parts that I initially found so inflammatory. (I know I'm an idiot for writing a response without having first read the entire message, but I can't help being passionate about this stuff.) Casey Marshall wrote: OK. But I could argue back that VMs for whom native methods don't work are broken as far a Java goes. True, but totally irrelevant. I said native methods are very inconvenient for some VMs. IKVM supports native methods just fine, but that doesn't mean that they are a good idea. I think you're saying that because platform details, like how files and sockets work, are easier for you to implement in the VM layer, that they're necessarily VM-specific, and not platform-specific. I couldn't disagree more with that. No, I'm saying that not all VMs are like the traditional C based VMs. BTW, this is not just IKVM, there are other Classpath VMs that also prefer to write their native code in Java. There's also no rule saying that you have to use Classpath's version of a class in your VM/system. That's true and sometimes I do decide to specialize a class (for example with the java.util.concurrent stuff) if the cost of using a VM interface is too high, but we all benefit if we share code. I realise that for gcj people it may look like there is a significant difference between (e.g.) VMFile and VMThread, but other VMs replace both these classes. Yeah, if I were writing a VM for Windows, I'd re-implement both. That has nothing to do with it. Just so you know, the *same* IKVM *binaries* run on Windows/Linux/MacOSX. The platform I code against is .NET/Mono, not the OS. That's also the reason why native code makes no sense for me. If we keep the VM* interface thing, I think a better design is to stop passing the core class to a static VM method, with the native state inside the core class, and just make these VM classes instance classes, with the native state associated with the instance. I thought that we already do that in most cases where it makes sense. An example I'm thinking of is VMPlainSocketImpl. PlainSocketImpl has an int field for the native file descriptor (and that makes just plain no sense, either way), and passes itself to VMPlainSocketImpl methods, which rips the descriptor integer out of that instance. I think it's better to make VMPlainSocketImpl an instance class, and keep the native state in that instance; in our default implementation, this would be an integer file descriptor, and we'd have method pairs like so in the VM class: I totally agree, but do you know why VMPlainSocketImpl is such a mess? Because it wasn't designed, someone just blindly applied the idea that native methods should be moved to the VM class. When VMPlainSocketImpl was introduced I should have stepped in and proposed something like what you just did, but I didn't because IKVM had already specialized the entire PlainSocketImpl class, so I was lazy and let it slide. So the *interface* for the VM class is the public instance method, and is the only one a VM writer needs to implement. Our default implementation then just implements the function in the obvious, fast way for POSIX. Maybe you can explain why passing an object to a static method makes more sense than that (I can't see how; all it adds is a litany of JNI calls to *every* method call). I think you *completely* misunderstood my position, as this is not at all what I was advocating. I completely agree with the VMPlainSocketImpl design you just proposed. Regards, Jeroen
Re: [cp-patches] RFC: File/VMFile improvement
Jeroen Frijters wrote: Hi Casey, I just about exploded when I read the first part of your message ;-) But at the end of your message I discovered that we completely misunderstood each other and that we agree much more than we disagree. Yeah, in the end we probably do agree more than we think ;-) I was being on the aggressive side in that email, but not hurtfully so. Really that part is mostly bikeshed material (i.e., what's VM and what's platform, and the terminology is a minefield of misunderstanding), and I don't see much disagreement on the conclusion -- that some of the VM interfaces are a mess, and are inefficient, and that something like I've proposed may be a good solution. I'm still working on a patch to fix this for socket NIO (I posted a preliminary version to this list). Thanks.
Re: [cp-patches] RFC: File/VMFile improvement
Hi again, we are having problems here with java.io.File on Windows CE. Which handles files different again than other Windows and of course different than Unix. I could have hacked some more special casing in there. But I'd like to propose to pull some more methods into VMFile. See ChangeLog and attached patch. Basically this moves the impl of getAbsolutePath(), isAbsolute() and toURL() to VMFile. The last patch here had a mistake. Here comes the corrected one. 2006-08-15 Roman Kennke [EMAIL PROTECTED] * java/io/File.java (getAbsolutePath): Fetch absolute path from VMFile.getAbsolutePath(). Moved actual impl to there. (isAbsolute): Let VMFile determine the absoluteness. (toURL): Let VMFile convert the filename. * vm/reference/java/io/VMFile.java (getAbsolutePath): New method. (isAbsolute): New method. (toURL): New method. /Roman
RE: [cp-patches] RFC: File/VMFile improvement
Hi Roman, The attached patch file is empty. Regards, Jeroen -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Roman Kennke Sent: Tuesday, August 15, 2006 17:31 To: Roman Kennke Cc: classpath-patches@gnu.org Subject: Re: [cp-patches] RFC: File/VMFile improvement Hi again, we are having problems here with java.io.File on Windows CE. Which handles files different again than other Windows and of course different than Unix. I could have hacked some more special casing in there. But I'd like to propose to pull some more methods into VMFile. See ChangeLog and attached patch. Basically this moves the impl of getAbsolutePath(), isAbsolute() and toURL() to VMFile. The last patch here had a mistake. Here comes the corrected one. 2006-08-15 Roman Kennke [EMAIL PROTECTED] * java/io/File.java (getAbsolutePath): Fetch absolute path from VMFile.getAbsolutePath(). Moved actual impl to there. (isAbsolute): Let VMFile determine the absoluteness. (toURL): Let VMFile convert the filename. * vm/reference/java/io/VMFile.java (getAbsolutePath): New method. (isAbsolute): New method. (toURL): New method. /Roman
RE: [cp-patches] RFC: File/VMFile improvement
Roman Kennke wrote: Jeroen Frijters schrieb: Hi Roman, The attached patch file is empty. Ugh. My bad. Here it is. Thanks. Looks like a good change to me. Regards, Jeroen
Re: [cp-patches] RFC: File/VMFile improvement
Roman == Roman Kennke [EMAIL PROTECTED] writes: Roman we are having problems here with java.io.File on Windows CE. Which Roman handles files different again than other Windows and of course Roman different than Unix. [...] Roman Maybe we should get rid of all the special casing anyway and provide a Roman default straightforward impl for Posixy systems, for the sake of Roman efficiency and cleanness. It seems to me that this is an area we haven't handled very well: this isn't really a VM thing per se -- the code could very well be written in pure java -- but rather a platform thing. I agree that adding special cases in File just makes the code uglier and uglier. But, we could delegate to a pure java platform class, with instances for posixy, Windows, Windows CE, etc, and share the code across all VMs. We do something vaguely similar to this in libgcj (though in the specific case of File we put the platform stuff in native code). Tom
Re: [cp-patches] RFC: File/VMFile improvement
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tom Tromey wrote: Roman == Roman Kennke [EMAIL PROTECTED] writes: Roman we are having problems here with java.io.File on Windows CE. Which Roman handles files different again than other Windows and of course Roman different than Unix. [...] Roman Maybe we should get rid of all the special casing anyway and provide a Roman default straightforward impl for Posixy systems, for the sake of Roman efficiency and cleanness. It seems to me that this is an area we haven't handled very well: this isn't really a VM thing per se -- the code could very well be written in pure java -- but rather a platform thing. I agree that adding special cases in File just makes the code uglier and uglier. But, we could delegate to a pure java platform class, with instances for posixy, Windows, Windows CE, etc, and share the code across all VMs. We do something vaguely similar to this in libgcj (though in the specific case of File we put the platform stuff in native code). FWIW I agree. Some of us were chatting about this on IRC, and not only are these VM interfaces more often than not platform interfaces (or with some things, all they rely on is JNI and standard C), but they do lead to performance hits (witness our direct ByteBuffer). I think putting some design thought into this is a good idea, because right now I don't think we have any clear idea about what the scope or purpose of VM/platform interfaces are. Right now, it looks like it's just an ad-hoc catch-all for anything that can't be done in pure Java -- you slap a VM class on it, and hack up the core class. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQEVAwUBROIpJuRILCRAfKHCAQIX5wf/aog1Jk+M1HNBKd7HZ6vzciTuPAynvlZ+ U+v7fvGI4FWaoCMUidB3rwov+gJhTXFpJpBy7ytGRExgpaJNp2Mp3kDpUJiInwYs pGh4rmzPvEd8dgkRyL7e4ccBF9ze7Ix7DzhXsldgNypOBDN+Bs7e1A9PjClnxQN8 t84Ii6YKeiifusAPRtgkmsS1wKF4PbCZ7YOdtT/BI6PfaERpgI4V/EnKASwx5Zp2 Z43NGTi/vvRb+qeOFbfhs8XA41EK5eb7ODDD6+W88PKcPUGLgaDlWHCP92XZdrS2 I/K4Ca9vluGs94WcMaflz7dFv9ofko4s9LmygqTIY+I8BKaXz2jTTw== =V2jF -END PGP SIGNATURE-
