About the test.abcl failures

6 messages Options
Embed this post
Permalink
Ville Voutilainen

About the test.abcl failures

Reply Threaded More More options
Print post
Permalink
It looks like some of our internal test failures are caused by the
tests not running in the proper directory. The
test.abcl target runs the tests in the $basedir, which is incorrect
for some tests, I think. Mark, any idea
how to instruct the tests to run in test/lisp/abcl? It seems our
abcl.asd wants to be loaded from the current
directory, so I'm asking for advise before changing our build.xml,
because I don't know what has been intended
here.

------------------------------------------------------------------------------
Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
is a gathering of tech-side developers & brand creativity professionals. Meet
the minds behind Google Creative Lab, Visual Complexity, Processing, &
iPhoneDevCamp as they present alongside digital heavyweights like Barbarian
Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com 
_______________________________________________
armedbear-j-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/armedbear-j-devel
Mark Evenson

Re: About the test.abcl failures

Reply Threaded More More options
Print post
Permalink
Ville Voutilainen wrote:
> It looks like some of our internal test failures are caused by the
> tests not running in the proper directory. The
> test.abcl target runs the tests in the $basedir, which is incorrect
> for some tests, I think. Mark, any idea
> how to instruct the tests to run in test/lisp/abcl? It seems our
> abcl.asd wants to be loaded from the current
> directory, so I'm asking for advise before changing our build.xml,
> because I don't know what has been intended
> here.

Hmmm.  The location of where 'abcl.asd' gets loaded shouldn't affect
things, but maybe I missed something.

Could you give a pointer to which tests in the internal test suite you
think are failing?

I'll have a look now to see if I see anything obvious.

Mark


--
"A screaming comes across the sky.  It has happened before, but there
is nothing to compare to it now."

------------------------------------------------------------------------------
Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
is a gathering of tech-side developers & brand creativity professionals. Meet
the minds behind Google Creative Lab, Visual Complexity, Processing, &
iPhoneDevCamp as they present alongside digital heavyweights like Barbarian
Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com 
_______________________________________________
armedbear-j-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/armedbear-j-devel
Ville Voutilainen

Fwd: About the test.abcl failures

Reply Threaded More More options
Print post
Permalink
Forgot to cc the list. Here's the gist of it.


---------- Forwarded message ----------
From: Ville Voutilainen <[hidden email]>
Date: Fri, May 29, 2009 at 10:49 PM
Subject: Re: About the test.abcl failures
To: Mark Evenson <[hidden email]>


On Fri, May 29, 2009 at 10:41 PM, Mark Evenson <[hidden email]> wrote:
> Hmmm.  The location of where 'abcl.asd' gets loaded shouldn't affect things,
> but maybe I missed something.

I tried to use dir=test-dir where test-dir is the location of abcl
tests. That results
in asdf failing to load the abcl module.

> Could you give a pointer to which tests in the internal test suite you think
> are failing?

probe-file.3 is the first one I looked, it will fail if (probe-file
p#"./") is not the same as
the path pointed to by *this-directory*, which is determined by
*load-file-truename*.
That means that the file loaded (file-system-tests.lisp) must be loaded from the
current directory (./). If not, the test fails.

------------------------------------------------------------------------------
Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
is a gathering of tech-side developers & brand creativity professionals. Meet
the minds behind Google Creative Lab, Visual Complexity, Processing, &
iPhoneDevCamp as they present alongside digital heavyweights like Barbarian
Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com 
_______________________________________________
armedbear-j-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/armedbear-j-devel
Ville Voutilainen

Re: About the test.abcl failures

Reply Threaded More More options
Print post
Permalink
In reply to this post by Mark Evenson
On Fri, May 29, 2009 at 10:41 PM, Mark Evenson <[hidden email]> wrote:
> Could you give a pointer to which tests in the internal test suite you think
> are failing?

See this little test snippet, it's mostly copy-paste from the test itself:

(format t "*load-truename* is ~a~%" *load-truename*)
(let ((test-dir
       (make-pathname :host (pathname-host *load-truename*)
                      :device (pathname-device *load-truename*)
                      :directory (pathname-directory *load-truename*)))
      (test-path #p"./"))
  (format t "test-dir: ~a~%" test-dir)
  (format t "test-path: ~a~%" (probe-file test-path)))

now, if we run this in the abcl main directory, we get

CL-USER(1): (load "probe-file-test.lisp")
*load-truename* is /home/ville/project_nonsvn/abcl/probe-file-test.lisp
test-dir: /home/ville/project_nonsvn/abcl/
test-path: /home/ville/project_nonsvn/abcl/
T

if we run it in, say test/, we get

CL-USER(1): (load "../probe-file-test.lisp")
*load-truename* is /home/ville/project_nonsvn/abcl/probe-file-test.lisp
test-dir: /home/ville/project_nonsvn/abcl/
test-path: /home/ville/project_nonsvn/abcl/test/
T

Note the different paths, which obviously causes the eql test in the
test case to
fail.

------------------------------------------------------------------------------
Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
is a gathering of tech-side developers & brand creativity professionals. Meet
the minds behind Google Creative Lab, Visual Complexity, Processing, &
iPhoneDevCamp as they present alongside digital heavyweights like Barbarian
Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com 
_______________________________________________
armedbear-j-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/armedbear-j-devel
Mark Evenson

Re: Fwd: About the test.abcl failures

Reply Threaded More More options
Print post
Permalink
In reply to this post by Ville Voutilainen
Ville Voutilainen wrote:
[…]
>
> On Fri, May 29, 2009 at 10:41 PM, Mark Evenson <[hidden email]> wrote:
>> Hmmm.  The location of where 'abcl.asd' gets loaded shouldn't affect things,
>> but maybe I missed something.
>
> I tried to use dir=test-dir where test-dir is the location of abcl
> tests. That results
> in asdf failing to load the abcl module.

ASDF usually works by looking for ASDF '*.asd' definitions in the
locations specified by ASDF:*CENTRAL-REGISTRY*.  Under systems with
symbolic links groked by the Lisp (I don't think Windows works well for
this), one just creates symbolic links to one of the locations in
ASDF:*CENTRAL-REGISTRY* which enables ASDF to determine all the
pathnames specified in the ASDF file.

For instance, I usually piggyback off of SBCL so I can use its working
ASDF-INSTALL package to install ASDF systems to play around with, so I
have the following statement in my '.abclrc' file:

   (require 'asdf)
   (pushnew '(merge-pathnames ".sbcl/systems/" (user-homedir-pathname))
       asdf:*central-registry*)

Then, if I have ABCL installed under ~/work/abcl, I can just add a
symlink like

     unix$ ln -s ~/work/abcl/abcl.asd ~/.sbcl/systems/abcl.asd

and I can always refer to the ABCL ASDF definition regardless of what
the current directory of the ABCL REPL happens to be.

>> Could you give a pointer to which tests in the internal test suite you think
>> are failing?
>
> probe-file.3 is the first one I looked, it will fail if (probe-file
> p#"./") is not the same as
> the path pointed to by *this-directory*, which is determined by
> *load-file-truename*.
> That means that the file loaded (file-system-tests.lisp) must be loaded from the
> current directory (./). If not, the test fails.

Apparently, I included a workaround that isn't working anymore (I don't
remember writing this, but it is there).  The code in the RUN function
'test/lisp/abcl/package.lisp' attempts to set the
*DEFAULT-PATHNAME-DEFAULTS* to the *LOAD-TRUENAME* of this file, but
apparently this isn't working anymore.  Perhaps the PROGV form has been
broken in the meantime?



--
"A screaming comes across the sky.  It has happened before, but there
is nothing to compare to it now."

------------------------------------------------------------------------------
Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
is a gathering of tech-side developers & brand creativity professionals. Meet
the minds behind Google Creative Lab, Visual Complexity, Processing, &
iPhoneDevCamp as they present alongside digital heavyweights like Barbarian
Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com 
_______________________________________________
armedbear-j-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/armedbear-j-devel
Mark Evenson

7 of 228 failures in 'test.abcl' with svn.12016 (was Re: About the test.abcl failures)

Reply Threaded More More options
Print post
Permalink
In reply to this post by Ville Voutilainen
Ville Voutilainen wrote:
> It looks like some of our internal test failures are caused by the
> tests not running in the proper directory. The
> test.abcl target runs the tests in the $basedir, which is incorrect
> for some tests, I think. Mark, any idea
> how to instruct the tests to run in test/lisp/abcl?

I finally got some time to fix this in commit svn.12016.  Now, the
'test.abcl' target reports only 7 of 228 test failures.

--
"A screaming comes across the sky.  It has happened before, but there
is nothing to compare to it now."

------------------------------------------------------------------------------
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables unlimited
royalty-free distribution of the report engine for externally facing
server and web deployment.
http://p.sf.net/sfu/businessobjects
_______________________________________________
armedbear-j-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/armedbear-j-devel