headers
Mark Evenson | 1 May 2010 08:22
Picon
Favicon

Re: [armedbear-cvs] r12620 - trunk/abcl/src/org/armedbear/lisp

On 4/30/10 2:48 PM, Erik Huelsmann wrote:

> On Fri, Apr 16, 2010 at 3:41 PM, Mark Evenson<mevenson@...>  wrote:
>> Author: mevenson
>> Date: Fri Apr 16 09:41:21 2010
>> New Revision: 12620
>>
>> Log:
>> Use interpreted form in a FASL if compliation fails.
>
> Although I think this is a great fallback, it seems to be
> automatically selected right now. I'm affraid of the negative side
> effects of that scenario: people will not notice that their code
> wasn't compiled, but is now interpreted instead. The ultimate side
> effect could be that we don't get any reports anymore regarding
> brokenness of our compiler.
>
> In my eyes, there are 2 ways forward with this: 1) We undo this
> option; this leaves users at a loss when compilation fails; they'll
> need to use the entire file uncompiled. 2) We make the fallback a
> selectable restart; this way, compilation gets interrupted, the user
> is aware and we're much more likely to receive our feedback. But the
> user isn't restricted to using a fully interpreted file anymore.
>
> Quite possibly, you can read my preference through the lines already:
> I think option (2) is *really* nice.

Certainly the restart seems the very much Lispy way to go, as it informs 
the user while fixing the problem.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mark Evenson | 1 May 2010 08:26
Picon
Favicon

Re: Running "ant test.abcl": Pathname error

On 4/30/10 8:26 PM, Erik Huelsmann wrote:
> Hi Mark,
>
>
> Today I tried to run ABCL's tests on Windows. I seem to have an issue,
> either with the new ASDF stuff, or with the new Pathname stuff. I'm
> not sure which, but hopefully you do. This is the output I get from
> "ant test.abcl" on Windows:
>
>       [java]   Error while trying to load definition for system abcl
> from pathname C:\Users\Erik\Documents\abcl-j\abcl.asd:
>   Pathname has no namestring: #P(:DEVICE "C" :DIRECTORY (:ABSOLUTE
> "Users" "Erik" "Documents" "abcl-j") :NAME "abcl-test-lisp" :TYPE
> "asd.lnk" :VERSION :NEWEST)
>       [java] Java Result: 2
>       [echo] Finished recording test output in abcl-test-20101530-1515.log.
>
>
> While I'm not asking you to fix it, could you indicate where I should
> start looking?

Carlos Ungil's mail to <armedbear-develop <at> …> of 04.30.2010 diagnoses 
this as a problem with the pathname translation function, he suggests:

> Is there a reason why the pathname has to start with "/:"? I changed it to
> #P"/jar:file/**.*" (and made a similar change inside translate-jar-pathname,
> from "/:jar:file/" to "/jar:file/"). This seems to work on both macosx
> and windows
> (at least I can load asdf systems).
(Continue reading)

Permalink | Reply | 6 comments |
headers
Mark Evenson | 1 May 2010 09:39
Picon
Favicon

Constructing Pathnames from "file" scheme URLs fixed in r12641 (was Re: debug stack overflow? (to track down regression))

On 4/29/10 8:25 PM, Alessio Stalla wrote:
> On Wed, Apr 28, 2010 at 10:39 PM, Alan Ruttenberg
> <alanruttenberg@...>  wrote:
>> This is what stack overflows:
>>
>> (pathname-host "file:///Users/alanr/repos/obi/trunk/src/ontology/branches/obi.owl")
>
> I can reproduce it: the Pathname(String) constructor apparently goes
> on infinite recursion with file: urls.

This should be fixed with [r12641][1].  Thanks for the report.

[1]: http://trac.common-lisp.net/armedbear/changeset/12641

--

-- 
"A screaming comes across the sky.  It has happened before, but there
is nothing to compare to it now."
Permalink | Reply | 0 comments |
headers
Carlos Ungil | 1 May 2010 10:14
Picon

Re: Running "ant test.abcl": Pathname error

On Sat, May 1, 2010 at 8:26 AM, Mark Evenson <evenson@...> wrote:
> There is no reason that I can remember that I coded it that way:  I just
> needed an intermediate path to match via the TRANSLATE-JAR-PATHNAME
> function.  If his suggestion works, we should patch ASDF as included in
> ABCL for 0.20, and then propagate the patch back to ASDF2 when we get a
> chance.

In fact there are still some problems with the change I proposed: if
there are multiple devices involved, paths are not resolved properly.
For example, if I remember correcly when the current directory was D:
an ASDF system somewhere in D: couldn't be loaded because the path
"/Documents And Settings/....../.cache" was in C: and not in D: (but
device info was not included in the translated pathname). I'll try to
look at it, but a first glance at Pathname.java suggests that it won't
be easy to fix...

Carlos
Permalink | Reply | 2 comments |
headers
Mark Evenson | 1 May 2010 10:44
Picon
Favicon

Re: Running "ant test.abcl": Pathname error

On 5/1/10 10:14 AM, Carlos Ungil wrote:
[…]

> In fact there are still some problems with the change I proposed: if
> there are multiple devices involved, paths are not resolved properly.
> For example, if I remember correcly when the current directory was D:
> an ASDF system somewhere in D: couldn't be loaded because the path
> "/Documents And Settings/....../.cache" was in C: and not in D: (but
> device info was not included in the translated pathname). I'll try to
> look at it, but a first glance at Pathname.java suggests that it won't
> be easy to fix...

Could you briefly describe what sort of behavior you see as necessary to 
introduce to Pathname.java?  The current Pathname implementation was 
designed to incorporate both Windows drive letters as DEVICE and the 
location of the JAR as a list of PATHNAMEs in the DEVICE, so I think we 
just need to get the translation right in ASDF2 rather than re-work 
Pathname.java.  Then again, I might have missed something, so would be 
interested in understanding a bit more about your analysis.

--

-- 
"A screaming comes across the sky.  It has happened before, but there
is nothing to compare to it now."
Permalink | Reply | 0 comments |
headers
Mark Evenson | 1 May 2010 14:25
Picon
Favicon

Re: Running "ant test.abcl": Pathname error

On 5/1/10 8:26 AM, Mark Evenson wrote:
> On 4/30/10 8:26 PM, Erik Huelsmann wrote:
>> Hi Mark,
>>
>>
>> Today I tried to run ABCL's tests on Windows. I seem to have an issue,
>> either with the new ASDF stuff, or with the new Pathname stuff. I'm
>> not sure which, but hopefully you do. This is the output I get from
>> "ant test.abcl" on Windows:
>>
>>        [java]   Error while trying to load definition for system abcl
>> from pathname C:\Users\Erik\Documents\abcl-j\abcl.asd:
>>    Pathname has no namestring: #P(:DEVICE "C" :DIRECTORY (:ABSOLUTE
>> "Users" "Erik" "Documents" "abcl-j") :NAME "abcl-test-lisp" :TYPE
>> "asd.lnk" :VERSION :NEWEST)
>>        [java] Java Result: 2
>>        [echo] Finished recording test output in abcl-test-20101530-1515.log.
>>
>>
>> While I'm not asking you to fix it, could you indicate where I should
>> start looking?

After further analysis, the problem reported by Erik is not related to 
the issue that Carlos is looking at solving.  Under win32, ASDF2 is 
trying to make a Pathname that contains a TYPE whose value is "asd.lnk" 
to work with Windows shortcuts.  ABCL asserts that TYPE cannot have a 
'.' character in it on an attempt to return a namestring.

When I get the time, I planning on relaxing the constraint that a 
namestring will not be returned under Windows if the TYPE string ends
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mark Evenson | 1 May 2010 15:19
Picon
Favicon

Re: Running "ant test.abcl": Pathname error

On 4/30/10 8:26 PM, Erik Huelsmann wrote:
> Hi Mark,
>
>
> Today I tried to run ABCL's tests on Windows. I seem to have an issue,
> either with the new ASDF stuff, or with the new Pathname stuff. I'm
> not sure which, but hopefully you do. This is the output I get from
> "ant test.abcl" on Windows:
>
>       [java]   Error while trying to load definition for system abcl
> from pathname C:\Users\Erik\Documents\abcl-j\abcl.asd:
>   Pathname has no namestring: #P(:DEVICE "C" :DIRECTORY (:ABSOLUTE
> "Users" "Erik" "Documents" "abcl-j") :NAME "abcl-test-lisp" :TYPE
> "asd.lnk" :VERSION :NEWEST)
>       [java] Java Result: 2
>       [echo] Finished recording test output in abcl-test-20101530-1515.log.

This should be fixed with [12642][1].  Now to tackle the problems 
reported by Carlos…

[1]: http://trac.common-lisp.net/armedbear/changeset/12642

--

-- 
"A screaming comes across the sky.  It has happened before, but there
is nothing to compare to it now."
Permalink | Reply | 0 comments |
headers
Mark Evenson | 1 May 2010 19:51
Picon
Favicon

Re: Patches for ASDF2 for translation function

On 4/30/10 1:59 AM, Carlos Ungil wrote:

[…]

> On MacOSX, and I guess on all non-Windows systems, #p"/:jar:file/**/*.*" equals
> (make-pathname :type :wild :name :wild :directory '(:absolute
> ":jar:file" :wild-inferiors))
>
> On Windows, this pathname is parsed differently: the result is a
> relative directory
> in a device called "/" (as mentioned in a trac ticket, this causes an error).
>
> Is there a reason why the pathname has to start with "/:"? I changed it to
> #P"/jar:file/**.*" (and made a similar change inside translate-jar-pathname,
> from "/:jar:file/" to "/jar:file/"). This seems to work on both macosx
> and windows
> (at least I can load asdf systems).
>
> I wonder if something else might be broken with the change.

ASDF systems should now load properly in ABCL under windows with 
[r12644][1].  In addition, the Windows drive letter is now used to 
properly disambiguate cache entries.  Please let me know if you find any 
other issues, and thanks for the report!

[1]: http://trac.common-lisp.net/armedbear/changeset/12644

--

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

Permalink | Reply | 2 comments |
headers
Carlos Ungil | 1 May 2010 20:18
Picon

Re: Patches for ASDF2 for translation function

On Sat, May 1, 2010 at 7:51 PM, Mark Evenson <evenson@...> wrote:
> ASDF systems should now load properly in ABCL under windows with
> [r12644][1].  In addition, the Windows drive letter is now used to
> properly disambiguate cache entries.  Please let me know if you find any
> other issues, and thanks for the report!
>
> [1]: http://trac.common-lisp.net/armedbear/changeset/12644

That's great, thanks a lot. I'll check the new version on Monday, when
I have access to the machine were I noticed the problem with multiple
devices.

Cheers,

Carlos
Permalink | Reply | 0 comments |
headers
Erik Huelsmann | 1 May 2010 22:47
Picon
Gravatar

Ticket #93: (VALUES) interpreted as NIL by the reader

Hi James,

Working towards an 0.20 release, I had a look at ticket 93 which was
filed by you (from the wording I concluded that it must have been a
regression).

Although it didn't turn out to be a regression: this issue must have
been in our sources for a looong time, it turned out to be easy to
fix: r12645 fixes this bug and its cousin in read-delimited-list,
which caused the same error.

Anyway, the issue you reported has been fixed. Thanks for your report!

Bye,

Erik.
Permalink | Reply | 0 comments |

Gmane