Re: [GUMP] Build Failure - Fop
Jochen Maes wrote: do you have the J.D.K. 1.3.1 installed? Because i had the same error with the J.D.K.1.2.2 and then i installed J.D.K.1.3.1 and everything worked... try it... I am running with Sun JDK 1.3.1.2 on RedHat Linux 7.2. With the same machine and same configuration. The builds worked on the 23rd, but failed on the 24th: http://jakarta.apache.org/builds/gump/2002-01-23/xml-fop.html http://jakarta.apache.org/builds/gump/2002-01-24/xml-fop.html Hmmm. It looks like xml-fop didn't change during that period. Furthermore, there is a null pointer exception in the xslt transformation. Copying xalan-dev and will try to see if I can narrow down when this apparent regression was introduced. - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [GUMP] Build Failure - FOP
One little thing I forgot to mention. On Fri, 14 Dec 2001, Sam Ruby [EMAIL PROTECTED] wrote: [about FOP's xslt task] Finally, there is a depends attribute which can declare other files which are referenced for the uptodate check. This can be done with the uptodate task. This is the only part that is slightly messy as it requires multiple targets to be created in order to achieve the same result. If it can be done with uptodate and multiple targets, dependset will probably work - making for one dependset and one style for each xslt. Adding a way to name additional dependencies in style is a good idea, anyway IMHO. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [GUMP] Build Failure - FOP
On Fri, 14 Dec 2001, Keiron Liddle [EMAIL PROTECTED] wrote: Thanks, I have updated the build file to use the manifest under jar, works fine. Great! Looking at the hostname I think that it is better left out, it may cause computers to attempt to connect to the internet when resolving the hostname. As the original task would have done before. I guess my response to your commit message hasn't made it to fop-dev yet. As Diane pointed out, you can get the hostname from the environment (at least on Windows and Unix systems), see http://marc.theaimsgroup.com/?l=ant-userm=100802855231701w=2 for example. I don't know much about xslt apart from - it works. So you know more than me. What sort of things need to be done/added? Will it become a core task or optional? There is a built-in Ant task named style that has been built-in for a long time. It performs XSLT transformations, so it seems to be in the same area as xslt. I haven't looked at the code of FOP's task, but I assume that it must be doing something better than style does and therefore I would love to see style improved. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [GUMP] Build Failure - FOP
Stefan Bodewig wrote: I guess my response to your commit message hasn't made it to fop-dev yet. I've manually approved two more messages. Anyone on the fop-dev team want to volunteer to become moderator? My guess is that the current moderator has become backlogged for some reason. There is a built-in Ant task named style that has been built-in for a long time. It performs XSLT transformations, so it seems to be in the same area as xslt. I haven't looked at the code of FOP's task, but I assume that it must be doing something better than style does and therefore I would love to see style improved. Looking at both, I believe that fop could make use of the style tag. The primary difference between the two is that style was designed to support running multiple inputs through one stylesheet, xslt was designed to support sending one input. If fop were to use style for all of its fontfile.xsl transformations, it likely would see a noticable speedup in processing (and as this step takes a while, I'm sure that the speedup would be most welcome). There are a few secondary differences. xslt has a smart attribute which can be used to disable the check to see if the output is already up to date - this apparently is never used. It also has a mergefile attribute which will append the contents of the specified file to the target - again never used. Finally, there is a depends attribute which can declare other files which are referenced for the uptodate check. This can be done with the uptodate task. This is the only part that is slightly messy as it requires multiple targets to be created in order to achieve the same result. And since the style task doesn't have a smart flag, there only way to force the translation to be done is to delete the output. - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [GUMP] Build Failure - FOP
On Fri, 14 Dec 2001, Sam Ruby [EMAIL PROTECTED] wrote: Stefan Bodewig wrote: I guess my response to your commit message hasn't made it to fop-dev yet. I've manually approved two more messages. Thanks, shouldn't be necessary any longer, I've subscribed to fop-dev shortly after sending my last post. xslt has a smart attribute which can be used to disable the check to see if the output is already up to date Corresponds to style's force attribute. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [GUMP] Build Failure - Fop
I think I know what's going on, but I don't have all pieces together to test it (yet) - does it work if you move the taskdef for FOP's manifest task out of the target and make it a sibling of target? Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [GUMP] Build Failure - Fop
On 2001.12.13 15:07 Sam Ruby wrote: This is the first time I have seen such a failure - collisions on Ant task names. Did something change in Ant yesterday which made the properties file take precidence over taskdefs? Is there some way that the Ant and FOP teams can work together to produce a combined manifest task which satisifies all requirements? We can update the FOP build to use the core ant manifest task and a new ant. This is no real problem. The only thing that our task does that is different is a BUILD-ID it has Date-Time (user@host [os]). It probably is not really important. It would good to simply use the ant tasks rather than having our own ones. How stable are these tasks and any other new tasks. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [GUMP] Build Failure - Fop
On Thu, 13 Dec 2001, Sam Ruby [EMAIL PROTECTED] wrote: Did something change in Ant yesterday which made the properties file take precidence over taskdefs? No, at least not yesterday. What has changed yesterday is that we've added a new task named manifest, so there simply hasn't been any collision before that. Is there some way that the Ant and FOP teams can work together to produce a combined manifest task which satisifies all requirements? Ant's manifest task can do all things FOP's does, AFAICS. You'd have to replace the attributes with nested attribute elements and explicit names, that's all. On the other hand, this would make FOP's build process depend on an unreleased version of Ant. I'll try to see why Ant's task definition takes precedence, because it shouldn't be that way. Thanks for the heads-up. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [GUMP] Build Failure - Fop
A quick fix, change the package target to
target name=package depends=compile,hyphenation
echo message=Creating the jar file ${build.dir}/${name}.jar/
jar jarfile=${build.dir}/${name}.jar
basedir=${build.dest}
includes=org/**,conf/**,hyph/**
manifest
attribute name=Main-Class value=${main.class} /
attribute name=Class-Path value=${runtime.classpath} /
attribute name=Implementation-Title value=${Name} /
attribute name=Implementation-Version value=${version} /
attribute name=Implementation-Vendor value=Apache Software Foundation
(http://xml.apache.org/fop/)/
/manifest
/jar
/target
this will work with Ant 1.4 and later. Still looking into the other
issues.
Stefan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: [GUMP] Build Failure - FOP
I'm currently not subscribed to fop-dev and responding to a post I've
picked up from the archives, sorry, please keep ant-dev in the CC.
Keiron Liddle [EMAIL PROTECTED] wrote:
We can update the FOP build to use the core ant manifest task and a
new ant. This is no real problem.
I don't see Ant's next release before February, most probably even
later, so I'd rather recommend to use the manifest nested into jar
approach, which is going to work with Ant 1.4 and 1.4.1.
The only thing that our task does that is different is a BUILD-ID
it has Date-Time (user@host [os]).
You should be able to emulate that using property expansion, something
like
tstamp
pattern property=ts format=MMdd-HHmmss-z /
/tstamp
jar ...
manifest
attribute name=Build-Id value=${ts} (${user.name} ...) /
/manifest
/jar
you get the idea. Hostname would be the only tricky part.
How stable are these tasks and any other new tasks.
The manifest task itself is just a wrapper around the nested
manifest element of jar, which has been around for some time (and
even has JUnit testcases).
I think it is quite stable, but still hasn't been tested by that many
people. I'm not aware of any other tasks - but we should talk about
adding the things that make your xslt task the preferred choice over
style to Ant's core task so that people outside the FOP community
can benefit from it as well 8-)
Cheers
Stefan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: [GUMP] Build Failure - FOP
--- Stefan Bodewig [EMAIL PROTECTED] wrote: Hostname would be the only tricky part. Can't you get it from the environment -- HOSTNAME on *nix, COMPUTERNAME on Win* (or is COMPUTERNAME only an NT thing)? Diane = ([EMAIL PROTECTED]) __ Do You Yahoo!? Check out Yahoo! Shopping and Yahoo! Auctions for all of your unique holiday gifts! Buy at http://shopping.yahoo.com or bid at http://auctions.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [GUMP] Build Failure - FOP
Thanks, I have updated the build file to use the manifest under jar, works
fine. Looking at the hostname I think that it is better left out, it may
cause computers to attempt to connect to the internet when resolving the
hostname.
I don't know much about xslt apart from - it works.
What sort of things need to be done/added?
Will it become a core task or optional?
On 2001.12.13 18:03 Stefan Bodewig wrote:
I'm currently not subscribed to fop-dev and responding to a post I've
picked up from the archives, sorry, please keep ant-dev in the CC.
Keiron Liddle [EMAIL PROTECTED] wrote:
We can update the FOP build to use the core ant manifest task and a
new ant. This is no real problem.
I don't see Ant's next release before February, most probably even
later, so I'd rather recommend to use the manifest nested into jar
approach, which is going to work with Ant 1.4 and 1.4.1.
The only thing that our task does that is different is a BUILD-ID
it has Date-Time (user@host [os]).
You should be able to emulate that using property expansion, something
like
tstamp
pattern property=ts format=MMdd-HHmmss-z /
/tstamp
jar ...
manifest
attribute name=Build-Id value=${ts} (${user.name} ...) /
/manifest
/jar
you get the idea. Hostname would be the only tricky part.
How stable are these tasks and any other new tasks.
The manifest task itself is just a wrapper around the nested
manifest element of jar, which has been around for some time (and
even has JUnit testcases).
I think it is quite stable, but still hasn't been tested by that many
people. I'm not aware of any other tasks - but we should talk about
adding the things that make your xslt task the preferred choice over
style to Ant's core task so that people outside the FOP community
can benefit from it as well 8-)
Cheers
Stefan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: [GUMP] Build Failure - Fop
Keiron Liddle wrote: I would like to raise an issue about this. I am not complaining, just pointing out some things. Remember - the point of Gump is to encourage people to communicate. Are the fop and batik people communicating, or is the gump nags the only form of communication for these changes between the two projects? I Fop is updated to comply with the api in the current batik cvs then fop will only work with that cvs build. So for example if a release of fop is made in the meantime (eg. 0.20.1 and 0.20.2) then they will only work with the batik version that comes with the build. It is not possible for the user to get the latest version of batik, for example batik 1.1, when it comes out and use that. It might be possible to release a new version of fop but this is a bit more difficult and time consuming in our current situation. This gets worse when another project is using fop and batik (eg. cocoon) and may also be updating the jars at various times. Absolutely correct. Realistically a proper version of fop can only be released along with a stablised api version of batik. It seems that keeping up to date with cvs of other libs doesn't always solve any problems and may actually create some. Agreed. My stated preference is that batik provide backwards compatible APIs, perhaps deprecated. Failing that, it would be nice if they could tell you once and for all, this is what the new API is going to be, instead of you having to discover a new change that impacts you every week or so. It may also be possible with reflection tricks or ant tricks (I can point out plenty of examples of each) to write a single source base that either can work with each, or at least can compile against each. But failing that, the options as I see it are: 1) try to stay up, and hope that batik releases first. 2) revert to the last release, but keep the gump runs and nags as informational. 3) revert to the last releaes, keep the gump runs, but discontinue the nags 4) drop xml-fop from gump entirely at the moment. You are right to be thinking about these issues in the way that you are. I probably should start a FAQ for gump as too many people assume that any reported compilation error should be fixed, but that is not always the correct solution. - Sam Ruby P.S. In a prior time where one project was routinely breaking another, I took the step of adding a notification to the culprit if their project's name was found in any of the error messages in the compilation of the victims project. My goal is to do whatever it takes to get the projects talking. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Xslt task issue (was Re: [GUMP] Build Failure - Fop)
Hi fellow foppers, Concerning the recent GUMP build failures, Sam Ruby wrote: ... the following change: http://cvs.apache.org/viewcvs.cgi/xml-xalan/java/src/org/apache/xalan/templates/FuncDocument.java.diff?r1=1.23r2=1.24 ..causes the following build failure: http://jakarta.apache.org/builds/gump/2001-08-18/xml-fop.html Our stylesheets (like genconst.xsl) which use the XSLT document function with an input nodeset are failing. The problem is that Xalan isn't finding the base URL for the node in the XML document. In fact it doesn't have a URL for the input XML document at all! I now see that the reason for this is that the Xslt task used in the fop build is building a DOM Document from the input file and passing that to the transformer. If I modify org.apache.fop.tools.anttasks.Xslt to directly pass the input XML filename to the XSLTransform.transform method, the latest version of Xalan works correctly, since it now finds the base URL. We are building the DOM tree to handle the mergefile which is used when building the font files. In order to work with the new version of Xalan, we need to find some way to let it know the system ID of the original input document. Perhaps we could create a DOMSource directly? Or pass the system ID separately? Or find some other way to handle the font mapping files without building the DOM tree? I haven't thought much about the best way to do this; I'll probably mull it over a bit, but it would be nice to hear from those of you who have already mucked about with this stuff (Tore, Kelly, Fotis?). Regards, Karen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: [GUMP] Build Failure - Fop
Hi Sam, Can you do a clean checkout? We now include (and use) the Avalon Framework and LogKit 1.0b4. In addition, we reorganized a few things. It should build fine if you do. -Steve -Original Message- From: Sam Ruby [mailto:[EMAIL PROTECTED]] Sent: Tuesday, August 21, 2001 8:56 AM To: [EMAIL PROTECTED] Subject: [GUMP] Build Failure - Fop This email is autogenerated from the output from: http://jakarta.apache.org/builds/gump/2001-08-21/xml-fop.html Build results exceed maximum length.Please see URL above for details. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: [GUMP] Build Failure - Fop
Steven Coffman wrote: Can you do a clean checkout? We now include (and use) the Avalon Framework and LogKit 1.0b4. In addition, we reorganized a few things. It should build fine if you do. This looks like the same problem that I tracked down on the 18th and reported here. Namely that the following change: http://cvs.apache.org/viewcvs.cgi/xml-xalan/java/src/org/apache/xalan/templates/FuncDocument.java.diff?r1=1.23r2=1.24 ...causes the following build failure: http://jakarta.apache.org/builds/gump/2001-08-18/xml-fop.html My purpose of running Gump is to get people to actually talk. When FOP recently made a change that broke Cocoon, the right thing apparently was to change cocoon. In this case, Xalan has recently made a change that will ultimately break FOP's build process. Karen Lease did some more analysis of this problem, and came to the conclusion that I think the FOP XSL is correct, but of course, I could be wrong... I would be interested in hearing what other Xalan developers think... - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [GUMP] Build Failure - Fop
Hi fop and xalan dev, The problem here seems to be that the XSLT document function, when called with a single argument which is a node-set (in the fop case, a single element or attribute node) is now using the current directory as the base URI to resolve relative URI references. It should use the base URI of the node, which would seem to be the base URI of the XML document containing the node. The documents FOP is trying to process are in the same directory as the original XML documnent being processed. I think the FOP XSL is correct, but of course, I could be wrong... Regards, Karen Lease Fairly Fanatic Fopper Sam Ruby wrote: FYI - The following change: http://cvs.apache.org/viewcvs.cgi/xml-xalan/java/src/org/apache/xalan/templates/FuncDocument.java.diff?r1=1.23r2=1.24 ..causes the following build failure: http://jakarta.apache.org/builds/gump/2001-08-18/xml-fop.html - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [GUMP] Build Failure - Fop
I've tried to work out what the problem with this is without success. The information suggests there is no xalan1 and that xalan2 is present (at least for the first bit). I've tried using the current xalan2 cvs without any problems. Does anyone know what the problem might be? Could it be xerces? Are there any other changes in the way that Gump is doing the build? On Fri, 27 Jul 2001 11:51:45 Sam Ruby wrote: This email is autogenerated from the output from: http://jakarta.apache.org/builds/gump/2001-07-27/xml-fop.html Buildfile: build.xml init-avail: init-filters-xalan1: init-filters-xalan2: [copy] Copying 1 file to /home/rubys/jakarta/xml-fop/build/src/codegen init: [echo] --- Fop 0.19.0-CVS [1999-2001] prepare: [echo] Preparing the build directories [mkdir] Created dir: /home/rubys/jakarta/xml-fop/build/src/org/apache/fop/fo/properties [mkdir] Created dir: /home/rubys/jakarta/xml-fop/build/src/org/apache/fop/render/pdf/fonts [mkdir] Created dir: /home/rubys/jakarta/xml-fop/build/src/org/apache/fop/svg [mkdir] Created dir: /home/rubys/jakarta/xml-fop/build/classes/conf [mkdir] Created dir: /home/rubys/jakarta/xml-fop/build/classes/hyph [copy] Copying 3 files to /home/rubys/jakarta/xml-fop/build/classes/conf codegen: [echo] Resetting codegen directory [copy] Copying 35 files to /home/rubys/jakarta/xml-fop/build/src/codegen [echo] Generating the java files from xml resources [null] [null] xslt [null] in: ./build/src/codegen/svgelements.xml [null] style: ./src/codegen/propmaker.xsl [null] out: ./build/src/codegen/svgproperties.xml [null] [null] java.lang.Exception: no transformer class found [null] at org.apache.fop.tools.xslt.XSLTransform.transform(Unknown Source) [null] at org.apache.fop.tools.xslt.XSLTransform.transform(Unknown Source) [null] at org.apache.fop.tools.anttasks.Xslt.transform(Unknown Source) [null] at org.apache.fop.tools.anttasks.Xslt.execute(Unknown Source) [null] at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:104) [null] at org.apache.tools.ant.Task.perform(Task.java:240) [null] at org.apache.tools.ant.Target.execute(Target.java:164) [null] at org.apache.tools.ant.Target.performTasks(Target.java:182) [null] at org.apache.tools.ant.Project.executeTarget(Project.java:568) [null] at org.apache.tools.ant.Project.executeTargets(Project.java:527) [null] at org.apache.tools.ant.Main.runBuild(Main.java:453) [null] at org.apache.tools.ant.Main.start(Main.java:154) [null] at org.apache.tools.ant.Main.main(Main.java:177) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [GUMP] Build Failure - Fop
On Mon, 30 Jul 2001, Keiron Liddle [EMAIL PROTECTED] wrote: I've tried to work out what the problem with this is without success. The information suggests there is no xalan1 and that xalan2 is present (at least for the first bit). I think it is that JAXP 1.1 is present (and thus the TraX interface) but no Xalan2. Looking at the latest GUMP run http://jakarta.apache.org/builds/gump, the problem seems to be fixed. Hmm, yes, there is a commit by Sam to Alexandria that adds a dependency of xalan2 is needed for FOP that seems to have fixed it. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [GUMP] Build Failure - Fop
Karen Lease [EMAIL PROTECTED] wrote: I see there are several of these. I guess they are coming from the automatic nightly build. Yes, I think so (not sure whether Sam is reading this list and as I'm at least a little familiar with Gump, I thought I should jump in). This message comes from a system named Gump, which knows a whole bunch of projects and how they depend on each other. Every night Gump will do a CVS update for all projects and build each project with the latest code of all other projects - for the results look around at http://jakarta.apache.org/builds/gump/. The source code for Gump can be found as a proposal in Jakarta's Alexandria project. This is not only going to find problems within a single project, but also helps to track down incompatibilities with older versions that might get into your code. The situation for FOP seems to be of this type. FOP gets built against the CVS version of Xalan-J2 and this one obviously has changed in a way that FOP's current build system cannot deal with. I must admit that I don't know much about how the build process works. Does anyone know what we should do to find and fix the problem? I'm even less familiar with FOP's build and haven't looked at the stylesheets at all. Looking at the error message alone, it seems as if the problem was indeed in the stylesheet and not within Xalan (maybe Xalan has become more strict?). Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [GUMP] Build Failure - Fop
Hi all, I see there are several of these. I guess they are coming from the automatic nightly build. The exception is being thrown by the stylesheet itself because one of its named templates sees an unexpected situation. Since none of the xsl or foproperties.xml files in codegen has been touched for a couple of months, I can only think that this is compiling with a recent Xalan which doesn't work with the FOP XSL. I must admit that I don't know much about how the build process works. Does anyone know what we should do to find and fix the problem? Regards, Karen Sam Ruby wrote: This email is autogenerated from the output from: http://jakarta.apache.org/builds/gump/2001-06-16/xml-fop.html Buildfile: build.xml init-avail: init-filters-xalan1: init-filters-xalan2: [copy] Copying 1 file to /home/rubys/jakarta/xml-fop/build/src/codegen init: [echo] --- Fop 0.19.0-CVS [1999-2001] prepare: [echo] Preparing the build directories [mkdir] Created dir: /home/rubys/jakarta/xml-fop/build/src/org/apache/fop/fo/properties [mkdir] Created dir: /home/rubys/jakarta/xml-fop/build/src/org/apache/fop/render/pdf/fonts [mkdir] Created dir: /home/rubys/jakarta/xml-fop/build/src/org/apache/fop/svg [mkdir] Created dir: /home/rubys/jakarta/xml-fop/build/classes/conf [mkdir] Created dir: /home/rubys/jakarta/xml-fop/build/classes/hyph [copy] Copying 3 files to /home/rubys/jakarta/xml-fop/build/classes/conf codegen: [echo] Resetting codegen directory [copy] Copying 35 files to /home/rubys/jakarta/xml-fop/build/src/codegen [echo] Generating the java files from xml resources xslt in: ./build/src/codegen/svgelements.xml style: ./src/codegen/propmaker.xsl out: ./build/src/codegen/svgproperties.xml xslt in: ./build/src/codegen/allprops.xml style: ./build/src/codegen/genconst.xsl out: ./build/src/org/apache/fop/fo/properties/Constants.java xslt in: ./build/src/codegen/foproperties.xml style: ./build/src/codegen/properties.xsl out: ./build/src/org/apache/fop/fo/properties/fo_ignore_this.java file:///home/rubys/jakarta/xml-fop/build/src/codegen/properties.xsl; Line 12; Column 14; Do colorkw.xml file:home/rubys/jakarta/xml-fop/build/src/codegen/propinc.xsl; Line 54; Column 36; [SNIP] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
