[0.0.10.20] IMPORT of NIL broken

Erik Huelsmann wrote:
[…]
>>
>> 62 out of 21702 total tests failed
> 
> And again we're doing better: only 58 failing tests now.

Somewhere in fixing the package stuff, you broke the following (which 
occurs in SLIME's "swank.lisp"):

(let ((package (make-package :swank-io-package :use '())))
     (import '(nil t quote) package))

After this is eval'd SWANK-IO-PACKAGE should have three symbols, but the 
NIL doesn't show up in the package under 0.0.10.20.  This was working in 
0.0.10.19.

Back to trying to decipher why your changes broke this,

Mark

--

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

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

Re: [0.0.10.20] IMPORT of NIL broken

On Mon, Sep 1, 2008 at 6:05 PM, Mark Evenson <evenson <at> panix.com> wrote:
> Erik Huelsmann wrote:
> […]
>>>
>>> 62 out of 21702 total tests failed
>>
>> And again we're doing better: only 58 failing tests now.
>
> Somewhere in fixing the package stuff, you broke the following (which occurs
> in SLIME's "swank.lisp"):
>
> (let ((package (make-package :swank-io-package :use '())))
>    (import '(nil t quote) package))
>
> After this is eval'd SWANK-IO-PACKAGE should have three symbols, but the NIL
> doesn't show up in the package under 0.0.10.20.  This was working in
> 0.0.10.19.
>
> Back to trying to decipher why your changes broke this,

I already know. NIL is LISTP, however, it's also SYMBOLP, so, the
LISTP tests are not correct. I'll commit the correct code (which was
already in %IMPORT, btw) in a few minutes.

Bye,

Erik.
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes

J-the-editor

(I sent this message to the list yesterday, but I never saw it get through.
I hope this will not be a dup)

Hello,

Recently there's been a question on the developers mailinglist whether
there's still any interest in J "as in the general purpose text and code
editor" (maybe it might've been a good idea to have sent that question to
the armedbear-j-users list too?).

Anyway, I have the feeling J-as-in-the-editor isn't really used anymore by
anyone. Or is it? Noone showed any particular interest in J, right?

I happend to be a long time user of J (I think I started using J in 2000,
maybe even 1999). During that period, I sent a few minor patches, mostly
related to the Python-mode (software developement in Python is what I do
for a living). Since the latest official release (was it 2004, maybe
2005?) there hasn't been any serious development on J anymore if I'm not
mistaken.

I have a bit of a sentimental feeling about this: J has really grown on me
in all these years (especially the XML mode with it oh-so easy way of
inserting XML elements, and the quick hack in the Python-mode to enable
so-called "doctest mode"), but I also think any codebase without
active maintenance or userbase is bound to render obsolete.

So, basically, is J dead? Are there any users still out there? Or have
people migrated away - like I'm currently doing, dusting of my .emacs
file? Although my Java-skills are rusty to say the least, maybe I could
chip a little maintenance-time when there're more people to collaborate

Re: J-the-editor

Hi,

I was pleasantly suprised by the quick responses to my post. I got two
on-list replies and one off-list reply. That, so far, makes up for a
known userbase of four people.

Usually inquiries like hit on only the top of the iceberg, but I'm not
so sure in this particular case.

Anyway, I see a couple of ways things can go from here on:

1) Everything stays as it is. J will see hardly any updates, and the
people that chose to use J are basically on their own in keeping J
running for themselves.

2) Someone steps up as "the maintainer for J" like someone did for the
ABCL implementation. At least the effort for keeping J's codebase
compatible with whatever the most common Java versions are can then be
shared. Maybe there's even some patches lying around that can be applied
and released.

3) A group of people want to give J a second life and starts actively
maintaining, possibly even developing, the code base (I know I have some
user-interface related ideas still for J), tries to reach out to new
users, does some marketing etc.

Actually, I don't see 3) happening without 2). Similarly, 2) can only
happen if there're enough people in 1).

Do you think that, with the four of use, it might be worthwhile to start

Re: J-the-editor

I sent this last night.  It was supposed to go to the group, but my  
mail client only sent it back to jw

I have used J since the beginning.  I worked with Peter at Symantec for 
many years.   Peter was always known for writing editors.  It's actually 
how he got the job with Symantec in the first place.  When Peter learned 
how to program in Java, it seemed fitting that his first java project 
should be an editor and J was born.  I have used J since it's first 
incarnation and I use it still every single day.  I use it for coding 
just about everything from C to XML.

It's funny now to see people wonder if J has any use with all the 
interest in the lisp interpreter.  If I remember correctly the lisp 
interpreter project started out to be the macro language for J only.  
Through popular demand it became its own standalone entity.

So, if anyone asks if the J project should be continued, I would give an 
emphatic "yes" to that question.  The thing works so well as to not even 
need any updates for several years, but it should be available should 
someone want to add more features or functionality.

Bruce Hellstrom

Jan-Wijbrand Kolman wrote:
> (I sent this message to the list yesterday, but I never saw it get through.
> I hope this will not be a dup)
>
>
> Hello,
>

Re: behavior of DIRECTORY with wild pathnames

On Tue, Sep 2, 2008 at 7:59 PM, Ville Voutilainen
<ville.voutilainen <at> gmail.com> wrote:
> On Mon, Aug 25, 2008 at 11:09 PM, Ville Voutilainen
> <ville.voutilainen <at> gmail.com> wrote:
>> Well, I have a new version that does not attempt recursion into
>> non-directories (and thus does not attempt to list contents of
>> non-directories). I'm not sure if that's sufficient, but here's yet
>> another version of the patch. This last modification was done
>> by removing the pointless concatenation of file-namestring
>> before recursion, it's nil for directories. So now I just check
>> the file-namestring and don't recurse at all if it exists.
>> Any more issues? For me, it looks like this patch is done.
>
> Hi Erik, any progress wrt this patch?

Thanks for the heads up: it's committed now.

Thanks for the patch too btw.

Bye,

Erik.

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

Re: J-the-editor

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

_______________________________________________
armedbear-j-devel mailing list
armedbear-j-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/armedbear-j-devel

Re: J-the-editor

On 9/3/08, Marcin Tustin <mm3 <at> zepler.net> wrote:
> What does it need in the way of maintenance?

Well, when I look at the bug/feature request lists, people have taken
the time to write patches for functionality they were missing (a C#
mode, for example).

Next to that: software does not only need maintenance, but when
maintenance is done, it also needs releases. Some people think you do
not, but version numbers are a great way of doing your marketing.
(Yes, even OSS projects need to work on their marketing: do you have
any idea how many OSS editors there are - and hence need to compete
with?)

So, this is about making sure users sending mails actually get their
messages answered; making sure fixes get released in publicly visible
releases; taking time to reward people who write fixes by applying
those fixes; etc.

I've accepted maintenance, but am only interested in the Common Lisp
part. This means that anybody who wants to chip in to maintain J is
greatly welcome. Possibly, we can even split up the project since that
would do justice (in terms of visibility) to both components. Ofcourse
J depends on ABCL, but if we do the split correctly, it could still be
done in a non-intrusive way.

Bye,

Erik.

> On Tue, Sep 2, 2008 at 9:21 PM, Jan-Wijbrand Kolman <jw <at> n--tree.net> wrote:
> >
> > Hi,
> >
> >
> > I was pleasantly suprised by the quick responses to my post. I got two
> > on-list replies and one off-list reply. That, so far, makes up for a
> > known userbase of four people.
> >
> > Usually inquiries like hit on only the top of the iceberg, but I'm not
> > so sure in this particular case.
> >
> > Anyway, I see a couple of ways things can go from here on:
> >
> > 1) Everything stays as it is. J will see hardly any updates, and the
> > people that chose to use J are basically on their own in keeping J
> > running for themselves.
> >
> > 2) Someone steps up as "the maintainer for J" like someone did for the
> > ABCL implementation. At least the effort for keeping J's codebase
> > compatible with whatever the most common Java versions are can then be
> > shared. Maybe there's even some patches lying around that can be applied
> > and released.
> >
> > 3) A group of people want to give J a second life and starts actively
> > maintaining, possibly even developing, the code base (I know I have some
> > user-interface related ideas still for J), tries to reach out to new
> > users, does some marketing etc.
> >
> > Actually, I don't see 3) happening without 2). Similarly, 2) can only
> > happen if there're enough people in 1).
> >
> > Do you think that, with the four of use, it might be worthwhile to start
> > sharing some efforts in keeping J running? Like testing J on various
> > Java versions and platforms (I tried compiling it today on a fresh
> > Ubuntu install, and it didn't work - I still need to find out why and
> > report the findings).
> >
> >
> >
> > Kind regards,
> > jw
> >
> > --
> > Jan-Wijbrand Kolman
> > jw <at> n--tree.net
> >
> >
> -------------------------------------------------------------------------
> >
> > This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> > Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> > Grand prize is a trip for two to an Open Source event anywhere in the
> world
> >
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> > _______________________________________________
> >
> > armedbear-j-devel mailing list
> > armedbear-j-devel <at> lists.sourceforge.net
> >
> https://lists.sourceforge.net/lists/listinfo/armedbear-j-devel
> >
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> armedbear-j-devel mailing list
> armedbear-j-devel <at> lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/armedbear-j-devel
>
>

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

Re: ArmedBear status with ANSI tests

> And again we're doing better: only 58 failing tests now.

Is there any progress with the "long version of
define-method-combination"? Last time I checked, the gcl ansi
tests did not run all out-of-the-box because of this problem. Erik,
how do you run the tests? Now that my
patch queue is empty, I could start looking at the remaining failing
tests and see if I can patch some of
the problems.

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

Re: [j-users] J-the-editor

> On Tue, Sep 2, 2008 at 4:27 PM, Marcin Tustin <mm3 <at> zepler.net> wrote:
>> What does it need in the way of maintenance?

On Tue, 2 Sep 2008 17:07:09 -0700, "David Martin" <davidhmartin <at> gmail.com>
wrote:
> Regarding what it needs for maintenance, at a minimum it doesn't build
> out-of-the-box using latest versions of Java. At least, I downloaded
> the source and tried to build via ant, using JDK 1.6, and was
> unsuccessful.

Exactly. Newer Java versions have seen the light of the day since the
latest offical release and I couldn't get J compiled yesteryday on a clean
Ubuntu where I installed sun-java6-jdk and did a ./configure; make; make
install. Compilation using sun-java5-jdk appeared to succeed, but then J
wouldn't start, crashing with some stackoverflow error.

Anyway, IMHO, codebases in active use need maintenance.

> Regarding the 3 options, I think there's a fourth, which is to fork
> and reimplement. I don't think there's anything particularly wrong
> with the existing code base, but a lot of time has passed, and there
> may be some interesting language options that weren't available 5
> years ago.
> 
> Having said that, I'm afraid I can't really be involved at this time,
> much as this would normally interest me. I'm effectively working two
> jobs these days, so I simply don't have the cycles to spare.

I quickly thought about such a fourth option as well, however being
involved a couple community driven open-source projects I know one thing:
you have to start simple and with a low ambition levels to get anything
done. It is just too easy to find yourself tangled in long and interesting
discussions about how thing *could* be or *should* be without getting some
actual code out.

For me the first low-ambition step would be: get J compiled and running
again on a fresh Ubuntu install. This is something I can realistically
speaking try to do. Let's share these eepxeriences on the mailinglist and
see if this can get any ball (however small or big the ball actually is)
rolling.

Thanks for you replies!!
regards,
jw

--
Jan-Wijbrand Kolman
jw <at> n--tree.net

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/