From: Jan-Wijbrand K. <jw...@n-...> - 2008-09-02 08:19:29
|
(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 with. If not, then let me take this opportunity to say a sincere and whole hearted "Thank You Peter" for the having developed J, an editor that deserves to have had a much, much bigger audience. Kind regards, jw -- Jan-Wijbrand Kolman jw...@n-... |
From: Jan-Wijbrand K. <jw...@n-...> - 2008-09-02 20:21:13
|
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...@n-... |
From: Bruce H. <bh...@br...> - 2008-09-02 20:36:13
|
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, > > > 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 > with. > > If not, then let me take this opportunity to say a sincere and whole > hearted "Thank You Peter" for the having developed J, an editor that > deserves to have had a much, much bigger audience. > > > Kind regards, > jw > > -- > Jan-Wijbrand Kolman > jw...@n-... > > > ------------------------------------------------------------------------- > 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 > arm...@li... > https://lists.sourceforge.net/lists/listinfo/armedbear-j-devel > |
From: Marcin T. <mm...@ze...> - 2008-09-02 23:27:26
|
What does it need in the way of maintenance? On Tue, Sep 2, 2008 at 9:21 PM, Jan-Wijbrand Kolman <jw...@n-...> 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...@n-... > > ------------------------------------------------------------------------- > 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 > arm...@li... > https://lists.sourceforge.net/lists/listinfo/armedbear-j-devel > |
From: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX - 2008-09-03 07:30:56
|
On 9/3/08, Marcin Tustin <mm...@ze...> 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...@n-...> 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...@n-... > > > > > ------------------------------------------------------------------------- > > > > 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 > > arm...@li... > > > 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 > arm...@li... > https://lists.sourceforge.net/lists/listinfo/armedbear-j-devel > > |
From: Jan-Wijbrand K. <jw...@n-...> - 2008-09-03 07:47:10
|
On Wed, 3 Sep 2008 09:31:07 +0200, XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX wrote: > On 9/3/08, Marcin Tustin <mm...@ze...> 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. Exactly! > 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. I think splitting the code bases would indeed do justice to both projects *and* would make the scope of development and maintenance much more clear to the outside world. Being somehwat interested in *helping* maintaining J, I would not dare claim I can maintain J. My Java skills in developement and making releases is very very outdated. But I'd like to learn and help. Let's start out by sharing experiences on the mailinglist again! kind regards, jw |
From: Jan-Wijbrand K. <jw...@n-...> - 2008-09-03 07:34:53
|
> On Tue, Sep 2, 2008 at 4:27 PM, Marcin Tustin <mm...@ze...> wrote: >> What does it need in the way of maintenance? On Tue, 2 Sep 2008 17:07:09 -0700, "David Martin" <dav...@gm...> 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...@n-... |
From: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX - 2008-09-03 08:51:14
|
On 9/3/08, Jan-Wijbrand Kolman <jw...@n-...> wrote: > 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. Well, forking a project is not something you need to do here: forking is done when you have incompatible opinions of how a program should be developed further. This is no the case here: we have no-one "defending" an "old" strategy, so anyone stepping in here can basically outline his plans and go ahead. Hence, there's no need for forking. Reimplementing is not something I'd advise: have a look at the code tree and you'll find J is actually quite big. I like the idea of 'low ambitions', or to put it more attractively: to proceed in a hands-on manner, addressing problems when they come up. Bye, Erik. |
From: Eric M. <eri...@fr...> - 2008-09-03 08:42:00
|
Jan-Wijbrand Kolman écrivait: > I think splitting the code bases would indeed do justice to both projects > *and* would make the scope of development and maintenance much more clear > to the outside world. In my opinion, separating the code bases would be a mistake. I currently use ABCL/J for a small research project at work, where J is used by a non-programmer to interact with a CL application. We don't use J in a sophisticated way, but it would be convenient to allow a toolbar button to invoke some Lisp code, for instance. I attempted briefly to implement this, without success. I think J/ABCL would have more value with a higher level of integration between the two components, rather than less coupling (though preserving the ability to produce a standalone abcl.jar is clearly useful). I should admit that I'm not interested in contributing to the Java parts of the project, but may contribute in a minor way to the CL code. Eric |
From: Ville V. <vil...@gm...> - 2008-09-03 10:30:54
|
On Wed, Sep 3, 2008 at 11:41 AM, Eric Marsden <eri...@fr...> wrote: > In my opinion, separating the code bases would be a mistake. I agree. It's highly doubtful (at least to me) that J would survive such a split. I suggest that people wait a little while before doing any drastic reorganization. I have for some time been toying with the idea of looking at J. My personal interest is much more geared towards abcl, but it's possible that I may have time to look at J bugs/requests. I have to say that I've never used J, so don't get too excited yet. :) I also unfortunately have very limited amount of time to spend for either abcl or J. I have however done some patches for abcl already, so I wouldn't rule out the possiblility of finding time to do the same for J. -VJV- |
From: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX - 2008-09-03 12:13:22
|
On 9/3/08, Eric Marsden <eri...@fr...> wrote: > Jan-Wijbrand Kolman écrivait: > > > I think splitting the code bases would indeed do justice to both projects > > *and* would make the scope of development and maintenance much more clear > > to the outside world. > > In my opinion, separating the code bases would be a mistake. > I currently use ABCL/J for a small research project at work, where J is > used by a non-programmer to interact with a CL application. We don't use > J in a sophisticated way, but it would be convenient to allow a toolbar > button to invoke some Lisp code, for instance. I attempted briefly to > implement this, without success. I think J/ABCL would have more value > with a higher level of integration between the two components, rather > than less coupling (though preserving the ability to produce a standalone > abcl.jar is clearly useful). Well, I'm not saying that a high level of integration between the two isn't usefull. However, what I tried to say is: the core Common Lisp project would be able to draw much more attention (hence benefit) if it were stand alone. Maybe J even so. Any integration can be dealt with on either side just as well when the two projects are integrated as when not. The way I'm thinking about it is this: currently abcl is much like elisp - built into an editor - with the notable difference that the editor itself isn't being developed in Lisp. I'd like the J integration to be handled much more like SLIME with Emacs: an extention to the editor built on a lisp which is not an integral part of the SLIME or Emacs projects. > I should admit that I'm not interested in contributing to the Java parts > of the project, but may contribute in a minor way to the CL code. This demonstrates my case: the intersection of people interested in ABCL and those interested in J may be smaller than either project can attract if they're not attached to each other. But: I've also read the remainder of the thread and I won't push forward with a split of the project at this moment. Let's see what happens at the side of the interest in J - and if anybody is interested in developing the integration between the two. Bye, Erik. |