headers
Peter Graves | 7 May 2004 04:23

0.20.2.12

A new development snapshot (j 0.20.2.12, ABCL 0.0.3.10) is available:

    http://armedbear.org/j.zip          (source)
    http://armedbear.org/j-jar.zip      (just j.jar)

This snapshot fixes the C mode indentation bug reported by Kevin
Ellwood on the j-users list.

In addition, there are a few ABCL-related changes.

On Linux, you can now feed --enable-libabcl to ./configure along with
your other favorite options, and (on a good day) the native library
libabcl.so will then be built and installed. The script formerly known
as abl is now known as abcl, and if you do --enable-libabcl, the abcl
script will automatically contain the needed options to set
LD_LIBRARY_PATH appropriately at runtime.

The point of libabcl.so is to install a native SIGINT handler so that
in the abcl interpreter, Ctrl C (or Ctrl Alt C in a j Lisp shell) can
be used to interrupt the Lisp process if it appears to be hung. In
previous versions, Ctrl C (or Ctrl Alt C in a Lisp shell) simply
terminated the Lisp process.

This functionality doesn't work 100% correctly yet (the TOP-LEVEL
restart is, despite its name, functionally equivalent to the CONTINUE
restart, for one thing), but if the alternative is terminating the Lisp
process, even a somewhat broken SIGINT handler is probably better than
nothing. Work continues.

You can tell if the SIGINT handler has been built and installed
(Continue reading)

Permalink | Reply | 0 comments |
headers
rcj.putman | 10 May 2004 22:49

win32 abcl

Hi,

just a few things about building/using J on native WinXP:

 - abcl Home Directory - 

I think the place where .abclrc is found is determined by
System.getProperty("user.home") which on a windows system is something
like "H:\Documents and Settings\My Name" which is not usually where
you want these sort of files.  For example, .emacs etc. is found by
using the HOME environment variable defaulting to c:\

 - Building J without Cygwin -

I know the official line is to use cygwin, but it doesn't run very
well on my laptop (runs out of resources) and it seems a bit overkill
to use for compiling and linking a few files.

The only problem is having to manually generate
\src\org\armedbear\lisp\Site.java (using Site.java.in and replacing
LISP_HOME = "h:/lisp/j/src/org/armedbear/lisp"; or something)
Couldn't this be a setting in .abclrc, like the way CMUCL finds its
source?

I'll admit up front to being clueless about java and I was wondering
whats the point of having the .lisp files in the jar file if java can't
find them anyway?

I'm not really asking you to change things if you like the way things
are, its just thought there might be someone else who prefers to build
(Continue reading)

Permalink | Reply | 3 comments |
headers
Peter Graves | 12 May 2004 05:21

Re: win32 abcl

On Mon, 10 May 2004 at 21:49:42 +0100, rcj.putman <at> physics.org wrote:
> Hi,
>
> just a few things about building/using J on native WinXP:

Before moving on to the specifics, I should mention that your message
got me motivated to try out j/abcl on Windows for the first time in
quite a while (long enough that I don't even remember when the last
time was).

And the result, as far as abcl was concerned, wasn't pretty.

I think I've fixed most of the major breakage now, and I plan to post a
new snapshot in the next day or two, when I'm reasonably sure that my
fixes didn't cause any collateral damage.

The main problem was that abcl didn't know how to handle CR/LF line
terminations. As a result, READ-LINE and READ-CHAR (at a minimum)
didn't work from the REPL. This also screwed up abcl's ACL-alike
support for top-level abbreviated commands (:cd, :pwd, :ld, etc.).

Another problem was that RENAME-FILE, on Windows only, would fail if
the target file existed, which prevented COMPILE-FILE from compiling
the same file a second time (unless you deleted the .fasl in between).

These things are now fixed in CVS, and the next snapshot should work
much better.

>  - abcl Home Directory -
>
(Continue reading)

Permalink | Reply | 2 comments |
headers
rcj.putman | 12 May 2004 23:19

Re: win32 abcl

Peter Graves <peter <at> armedbear.org> writes:

> On Mon, 10 May 2004 at 21:49:42 +0100, rcj.putman <at> physics.org wrote:
> ...
> Before moving on to the specifics, I should mention that your message
> got me motivated to try out j/abcl on Windows for the first time in
> quite a while (long enough that I don't even remember when the last
> time was).

Thanks very much for your time on that.  I can appreciate how much
effort it takes setting up a test system for an os that you don't
normally use.

> ...
> These things are now fixed in CVS, and the next snapshot should work
> much better.
>

Great.  BTW, do you want to hear about problems/patches for the cvs
version, or is that work in progress?  To put it another way - some
developers here see cvs as a backup for their work for that day,
others prefer to always run a test suite before commiting.

> ...
> Ideally, too, the build process should generate scripts to launch j and
> abcl for the platform in question, so a bit more substitution is
> necessary.
>

ok, but the batch files I use to launch j are just
(Continue reading)

Permalink | Reply | 1 comment |
headers
Peter Graves | 13 May 2004 17:07

Re: win32 abcl

On Wed, 12 May 2004 at 22:19:47 +0100, rcj.putman <at> physics.org wrote:
> Great.  BTW, do you want to hear about problems/patches for the cvs
> version, or is that work in progress?  To put it another way - some
> developers here see cvs as a backup for their work for that day,
> others prefer to always run a test suite before commiting.

Well, I never commit anything to CVS unless I _think_ it's gonna work...

For abcl, normally I do run the ANSI test suite after every significant
change, but it's not always practical to do that (if I'm working on my
laptop, for example, it takes about an hour to run the tests, and it's
no fun to have them running in the background).

I don't think of SourceForge CVS as just a backup, though; I've got the
source mirrored locally in Perforce for that.

> > ...
> > Ideally, too, the build process should generate scripts to launch j and
> > abcl for the platform in question, so a bit more substitution is
> > necessary.
> >
>
> ok, but the batch files I use to launch j are just
>
> -------------------------------------------------------------------------
> rem
> rem startj.bat - Launch j from the Windows toolbar
> rem create a shortcut to this batch file
> rem right-click - properties Run-> minimized to avoid seeing the dos box
> rem
(Continue reading)

Permalink | Reply | 0 comments |
headers
Peter Graves | 18 May 2004 03:31

0.20.2.13

A new development snapshot (j 0.20.2.13, ABCL 0.0.3.11) is available:

    http://armedbear.org/j.zip          (source)
    http://armedbear.org/j-jar.zip      (just j.jar)

This snapshot adds the command p4Log, which is a wrapper for the
Perforce "filelog -l" command on the current buffer. The various
Perforce-related commands are now documented (Alt X, "apropos p4" will
give you links to them).

I see now that I forgot to document the p4AutoEdit preference. If
you're using Perforce with a quick and reliable connection, setting
p4AutoEdit to true will let you edit files without having to check them
out explicitly first (j will automatically do "p4 edit" for you when
you make the first change to the file).

This snapshot also fixes a lot of Windows-specific ABCL bugs, in fact,
all of them, as far as I know. The remaining ABCL bugs should all be
platform-independent, in the time-honored Java tradition of "write
once, bugs everywhere".

I've also made an attempt to get j's Ant-based build system to work
better, particularly on Windows. This is not to say that it works well,
but maybe it now requires a bit less fiddling. The configure/make build
system is still your best bet on Linux.

The version of ABCL in this snapshot fails 84 out of 16350 total tests
in the GCL ANSI test suite, for a nominal compliance of 99.486% (insert
usual disclaimers here). With the current fixes, the test results are
identical on Linux and Windows, but two pathname-related tests are
(Continue reading)

Permalink | Reply | 0 comments |
headers
Peter Graves | 18 May 2004 17:41

Bug 955880

Bug 955880:

    Summary: split not working

    Initial Comment:
    J 0.20.2.11
    Java 1.4.2_04 Sun Microsystems Inc.
    Slackware Linux current (linux 2.6.5)

    Split/Unsplit window do not work, J opened for a couple
    of hours with no apparent problems.

    J log:

    May 18 14:31:00.375 ERROR Assertion failed!
    May 18 14:31:00.397 ERROR
    org.armedbear.j.AssertionException
            at org.armedbear.j.Debug.assertTrue(Debug.java:33)
            at org.armedbear.j.Editor.activate(Editor.java:5810)
            at org.armedbear.j.Frame.splitWindow(Frame.java:427)
            at org.armedbear.j.Editor.splitWindow(Editor.java:7137)

The assertion failure occurred because the buffer that was going to be
activated in the new window (after the split) was not present in j's
buffer list. If you were just doing a normal F10 split, this should be
the same buffer that was open in the full window before you did F10, so
it's very odd that it was not in the buffer list. I don't think I've
ever seen this error before.

So the big question is, what was the buffer you were looking at in the
(Continue reading)

Permalink | Reply | 2 comments |
headers
Peter Graves | 19 May 2004 16:03

Re: Bug 955880

Following up, Ludo wrote:

    Hi Peter, thanks as always for being so quick in replying to
    bugs. The file I had opened was a remote ftp file on a
    non-standard port. I have passive ftp and save in place
    turned on in J's prefs.

    While we're at it, J "forgets" the port for ftp connections,
    ie if I open a file such as ftp://myserver:8021/myfile in
    the "recent Files" list I get an entry for
    ftp://myserver/myfile and I seem to remember the same
    applies to J's session, if I close and reopen J non of my
    session files (thos on non-standard ftp ports) are reopened.
    So maybe the same thing applies to the Split bug.

Starting with the original issue, I still need a step-by-step scenario
to reproduce the bug. F10 works fine for me when I start out looking at
an FTP buffer. The act of splitting the window (per se) doesn't create
a new buffer or have any impact on the existing buffer, except that
after the split the existing buffer is displayed in two different
windows, so things like the use of non-standard FTP ports, save-in-
place, etc., shouldn't have any bearing on the assertion failure.

So, I still need that step-by-step scenario to reproduce the bug...

If the bug isn't readily reproducible, could you clarify whether you
were just splitting the window using F10, or did you do something
different (Ctrl Alt O, for example)?

There's a second issue here, the matter of j forgetting the use of a
(Continue reading)

Permalink | Reply | 1 comment |
headers
Peter Graves | 20 May 2004 02:37

0.20.2.14

Tonight's development snapshot (j 0.20.2.14, ABCL 0.0.3.12) is up:

    http://armedbear.org/j.zip          (source)
    http://armedbear.org/j-jar.zip      (just j.jar)

This snapshot fixes bug 956694, a StringIndexOutOfBoundsException
involving the electricPound command (mapped by default to '#') in C
mode.

This snapshot also fixes five more ABCL test failures on the GCL ANSI
test suite (79 failures to go).

Thanks for your support.

-Peter

-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
Permalink | Reply | 0 comments |
headers
Ludovico Magnocavallo | 22 May 2004 15:23

Re: Bug 955880

> So, I still need that step-by-step scenario to reproduce the bug...

I could manage to reproduce the bug, even working from the same desktop 
on the same files.

> If the bug isn't readily reproducible, could you clarify whether you
> were just splitting the window using F10, or did you do something
> different (Ctrl Alt O, for example)?

No, I was just trying to split the window after having unsplitted it a 
few minutes before (and maybe swithced file).

> There's a second issue here, the matter of j forgetting the use of a
> non-standard port for FTP connections when you later try to reopen the
> same file from the recent files list. I haven't had a chance to
> investigate that part of the problem yet, but I will try to look into
> it in the next week or so and get it fixed. In any case, as mentioned,
> that shouldn't have anything to do with the assertion failure.

Thanks, it's just a very little annoyance, nothing that stops me from 
using J.

Ludo

-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
(Continue reading)

Permalink | Reply | 0 comments |

Gmane