From: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX - 2008-09-07 20:13:11
|
As started some weeks ago - by requesting a project for abcl on common-lisp.net - I'm working on a better (read faster/more reliable) infrastructure for the project. Today, a small step was taken by copying the content of the SF repository to common-lisp.net. Please note that this does not mean I'm separating J and ABCL (yet). The two repositories are exact copies at this moment. In the weeks to come, work will need to be done on these items: - website - a nice domain name (abcl.org didn't work out, not even for USD400...) - establishing Trac service (bug registration and Wiki) - setting a direction for going forward Bye, Erik. |
From: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX - 2008-09-07 20:24:02
|
On Sun, Sep 7, 2008 at 10:13 PM, XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX wrote: > As started some weeks ago - by requesting a project for abcl on > common-lisp.net - I'm working on a better (read faster/more reliable) > infrastructure for the project. Today, a small step was taken by > copying the content of the SF repository to common-lisp.net. > > Please note that this does not mean I'm separating J and ABCL (yet). > The two repositories are exact copies at this moment. > > In the weeks to come, work will need to be done on these items: > > - website > - a nice domain name (abcl.org didn't work out, not even for USD400...) > - establishing Trac service (bug registration and Wiki) > - setting a direction for going forward And I forgot to mention: releases for both ABCL and J. (The sooner the better: any takers?) Bye, Erik. |
From: Mark E. <ev...@pa...> - 2008-09-08 07:48:44
|
Erik Huelsmann wrote: […] > And I forgot to mention: releases for both ABCL and J. (The sooner the > better: any takers?) > Releases in what sense? Pushing a binary from SVN up to common-lisp.net? I can definitely help with the ABCL part of that kind of release process, as I have ASDF definitions plus new code for platform detection within ABCL (mainly generalizing the idea of *platform* to work across more UNIX-like systems) for BUILD-ABCL and TEST-ABCL. What I am weak on is a) running this stuff under win32 and b) what a functional J actually looks on, which is why creating reproducible tests that we can meaningfully triage bug reports across will be very helpful (running on a JVM can mean a greater platform variance than more traditional software distribution mechanisms) Some random thoughts on what release engineering for ABCL might involve: 1. is J truly separable from ABCL? Let's prove it by creating a j.jar that needs abcl.jar in its CLASSPATH to work. Getting this sort of release engineering done early will help in the long run. And provides the right kind of path 1.1 With a j.jar, J becomes the "first-class" consumer of ABCL: we support releasing it in its current state until someone shows up who has a real interest in extending J in some manner. Getting tests that show a given release of J is acceptable would help create a better release process. 1.2 We create an easily extendable test suite for ABCL that includes 1.2.1 The ANSI tests 1.2.2 the stuff under src/org/armedbear/lisp/tests 1.2.3 What we need to gain confidence that our fixes for ABCL are not messing up things that we thought were working This test suite becomes a consumer of ABCL as well, but is not included in abcl.jar. 3. We start building releases with JDK-1.5 from Sun as the most common JVM "platform" out there. I can do older releases with JDK-1.4 under ia32-solaris-5.11 if neeeded, but this would be in a special binary. Something like Retroweaver (??) could help "back porting" anything we end up doing with Java 5 specific features like Annotations, but I could use some help here because I haven't regularly used JDK-1.4 since 2005. 4. We plan on skipping JDK-1.6 as a target platform, going directly for the first widely deployed OpenJDK to implement JSR-292. This set of target platforms currently contains only the Da Vinci VM by John Rose et. at. at Sun. 4.1 ABCL 1.0 would run on Java 5 4.2 ABCL 2.0 would run on Java 7 (and redo the underlying Java class structure to efficiently utilize JSR-292's invokedynamic) -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now." |
From: Mark E. <ev...@pa...> - 2008-09-08 07:54:56
|
Mark Evenson wrote: […] > Releases in what sense? Pushing a binary from SVN up to > common-lisp.net? err, "pushing a binary built from SVN up to common-lisp.net?" -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now." |
From: Ville V. <vil...@gm...> - 2008-09-08 10:19:38
|
On Mon, Sep 8, 2008 at 10:48 AM, Mark Evenson <ev...@pa...> wrote: > 4. We plan on skipping JDK-1.6 as a target platform, going directly for > the first widely deployed OpenJDK to implement JSR-292. This set of > target platforms currently contains only the Da Vinci VM by John Rose > et. at. at Sun. > 4.2 ABCL 2.0 would run on Java 7 (and redo the underlying Java class > structure to efficiently utilize JSR-292's invokedynamic) What about JSR-223, aka Java Scripting? I've been toying with the idea of 1) J using the java scripting framework 2) abcl providing the canonical lisp implementation for java scripting This would allow J to be independent of abcl/lisp, allowing scripts for J to be written in any language supported by the scripting framework. It would also allow abcl to be used by projects other than J (that's of course alredy possible at the moment but maybe it would be nicer to integrate well to JSR-223 if that's supposed to be "the official way to integrate java to other languages"). JSR-223 is apparently available starting from Java 6, so it's also available on Java 7. So it's not a short-term target. |
From: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX - 2008-09-09 09:31:54
|
On Mon, Sep 8, 2008 at 9:48 AM, Mark Evenson <ev...@pa...> wrote: > XXXXXXXXXXXXXX wrote: > […] > >> And I forgot to mention: releases for both ABCL and J. (The sooner the >> better: any takers?) >> > > Releases in what sense? Well, I was looking at what's currently there, for starters. My idea was to do with what we have available, building plans to improve it after we have some visible evidence of the fact that the project lives again. So, in this case that would mean creating abcl and j tar and zip files for source distribution. After we have the old-but-unreleased code out, we can take the following steps: - create a binary distritution for ABCL - split the j.jar file in an abcl.jar and a j.jar - create a binary release for J Then, when we finish all this, upon a release, we create 2 source releases (Windows [.zip] and Unix[.tar.gz]) and a binary release (which doesn't need localization!) > Pushing a binary from SVN up to common-lisp.net? > I can definitely help with the ABCL part of that kind > of release process, as I have ASDF definitions plus new code for > platform detection within ABCL (mainly generalizing the idea of > *platform* to work across more UNIX-like systems) for BUILD-ABCL and > TEST-ABCL. Looking at the above, I think it's even simpler than creating a binary distribution: we need to run the tests and create a source distribution, afaics. > What I am weak on is a) running this stuff under win32 and b) what a > functional J actually looks on, which is why creating reproducible tests > that we can meaningfully triage bug reports across will be very helpful > (running on a JVM can mean a greater platform variance than more > traditional software distribution mechanisms) You're waaayyyy ahead of me :-) > Some random thoughts on what release engineering for ABCL might involve: > > 1. is J truly separable from ABCL? Let's prove it by creating a j.jar > that needs abcl.jar in its CLASSPATH to work. Getting this sort of > release engineering done early will help in the long run. And provides > the right kind of path I think making this split will simply amount to adjusting the build.xml file the right way; ie. introducing an abcl.jar file which will be created next to the j.jar file. Only 1 problem: I have no experience with the Ant build system (as a creator). > 1.1 With a j.jar, J becomes the "first-class" consumer of ABCL: we > support releasing it in its current state until someone shows up who has > a real interest in extending J in some manner. Getting tests that show > a given release of J is acceptable would help create a better release > process. Absolutely! And I think we will need a release process defined. > 1.2 We create an easily extendable test suite for ABCL that includes > 1.2.1 The ANSI tests > > 1.2.2 the stuff under src/org/armedbear/lisp/tests Agreed. > 1.2.3 What we need to gain confidence that our fixes for ABCL are not > messing up things that we thought were working > This test suite becomes a consumer of ABCL as well, but is not included > in abcl.jar. That would be nice. However, I think the current tests/ directory is excluded upon j.jar creation. > 3. We start building releases with JDK-1.5 from Sun as the most common > JVM "platform" out there. I can do older releases with JDK-1.4 under > ia32-solaris-5.11 if neeeded, but this would be in a special binary. > Something like Retroweaver (??) could help "back porting" anything we > end up doing with Java 5 specific features like Annotations, but I could > use some help here because I haven't regularly used JDK-1.4 since 2005. Well, there's one problem with javac1.4, because I've introduced generics to silence compiler warnings about unchecked code: they are 1.5 level compatibility. Does your solaris 1.4 JDK support generics? > 4. We plan on skipping JDK-1.6 as a target platform, going directly for > the first widely deployed OpenJDK to implement JSR-292. This set of > target platforms currently contains only the Da Vinci VM by John Rose > et. at. at Sun. Having a MOP at all would be more of a priority to me than using the invokedynamic instruction, especially because that would bring ABCL on par with some of the other implementations out there. *Having* the functionality is required before you can work on the speed of the implementation :-) However, what's great here is that this is open source and everybody gets to scratch his/her itch, meaning that if this is your priority, that's perfectly fine (and I'll support it too, btw). > 4.1 ABCL 1.0 would run on Java 5 > > 4.2 ABCL 2.0 would run on Java 7 (and redo the underlying Java class > structure to efficiently utilize JSR-292's invokedynamic) Bye, Erik. |
From: Mark E. <ev...@pa...> - 2008-09-09 13:12:23
|
XXXXXXXXXXXXXX wrote: […] > So, in this case that would mean creating abcl and j tar and zip files > for source distribution. After we have the old-but-unreleased code > out, we can take the following steps: What about a single source distribution for everything? The "cost" of carrying around J is quite minimal, as long as we eliminate it in the binary distribution. Having a single source for J and ABCL until more J advocates step forward increases the chances of finding same. > - create a binary distritution for ABCL > - split the j.jar file in an abcl.jar and a j.jar > - create a binary release for J I can get the ABCL build.xml to do that. […] > >> 1.2 We create an easily extendable test suite for ABCL that includes > >> 1.2.1 The ANSI tests >> >> 1.2.2 the stuff under src/org/armedbear/lisp/tests > > Agreed. > >> 1.2.3 What we need to gain confidence that our fixes for ABCL are not >> messing up things that we thought were working > Please see a candidate for [TEST-ABCL] ASDF wrapping [TEST-ABCL]: http://code.google.com/p/abcl-dynamic-install/source/browse/trunk/abcl/abcl-test.asd […] > That would be nice. However, I think the current tests/ directory is > excluded upon j.jar creation. I'll fix that when I get a build 'build.xml' to build 'abcl.jar' and 'j.jar' from the commandline > >> 3. We start building releases with JDK-1.5 from Sun as the most common >> JVM "platform" out there. I can do older releases with JDK-1.4 under >> ia32-solaris-5.11 if neeeded, but this would be in a special binary. >> Something like Retroweaver (??) could help "back porting" anything we >> end up doing with Java 5 specific features like Annotations, but I could >> use some help here because I haven't regularly used JDK-1.4 since 2005. > > Well, there's one problem with javac1.4, because I've introduced > generics to silence compiler warnings about unchecked code: they are > 1.5 level compatibility. Does your solaris 1.4 JDK support generics? > I propose we only release post Java 5 compatible code from now on. We should be able to fix the source by stripping out the annotations, right? But I see this as a specialized build process done by somebody "who knows what they are doing". I'd release such pre Java 5 binaries occasionally, but not sweat if they aren't available: when people who want to contribute such release engineering step forward, we'll revisit this later. […] > Having a MOP at all would be more of a priority to me than using the > invokedynamic instruction, especially because that would bring ABCL on > par with some of the other implementations out there. *Having* the > functionality is required before you can work on the speed of the > implementation :-) However, what's great here is that this is open > source and everybody gets to scratch his/her itch, meaning that if > this is your priority, that's perfectly fine (and I'll support it too, > btw). > >> 4.1 ABCL 1.0 would run on Java 5 Then you're firmly in the "ABCL 1.0" camp. I'm not going to waste too much time now thinking about "ABCL 2.0", other than to watch the results of the Sun VM Dynamic Language Implementation Workshop (Sep. 24 - 26 in CA) remotely. Thinking of "ABCL 2.0" helps to evaluate the feature set of "ABCL 1.0" much more ruthlessly. Mark <ev...@pa...> |
From: Alan R. <ala...@gm...> - 2008-09-09 14:39:16
|
FWIW I support the idea of splitting the projects, both at the source and distribution levels. -Alan On Tue, Sep 9, 2008 at 5:31 AM, XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX wrote: > On Mon, Sep 8, 2008 at 9:48 AM, Mark Evenson <ev...@pa...> wrote: >> XXXXXXXXXXXXXX wrote: >> […] >> >>> And I forgot to mention: releases for both ABCL and J. (The sooner the >>> better: any takers?) >>> >> >> Releases in what sense? > > Well, I was looking at what's currently there, for starters. My idea > was to do with what we have available, building plans to improve it > after we have some visible evidence of the fact that the project lives > again. > > So, in this case that would mean creating abcl and j tar and zip files > for source distribution. After we have the old-but-unreleased code > out, we can take the following steps: > > - create a binary distritution for ABCL > - split the j.jar file in an abcl.jar and a j.jar > - create a binary release for J > > Then, when we finish all this, upon a release, we create 2 source > releases (Windows [.zip] and Unix[.tar.gz]) and a binary release > (which doesn't need localization!) > >> Pushing a binary from SVN up to common-lisp.net? >> I can definitely help with the ABCL part of that kind >> of release process, as I have ASDF definitions plus new code for >> platform detection within ABCL (mainly generalizing the idea of >> *platform* to work across more UNIX-like systems) for BUILD-ABCL and >> TEST-ABCL. > > Looking at the above, I think it's even simpler than creating a binary > distribution: we need to run the tests and create a source > distribution, afaics. > >> What I am weak on is a) running this stuff under win32 and b) what a >> functional J actually looks on, which is why creating reproducible tests >> that we can meaningfully triage bug reports across will be very helpful >> (running on a JVM can mean a greater platform variance than more >> traditional software distribution mechanisms) > > You're waaayyyy ahead of me :-) > >> Some random thoughts on what release engineering for ABCL might involve: >> >> 1. is J truly separable from ABCL? Let's prove it by creating a j.jar >> that needs abcl.jar in its CLASSPATH to work. Getting this sort of >> release engineering done early will help in the long run. And provides >> the right kind of path > > I think making this split will simply amount to adjusting the > build.xml file the right way; ie. introducing an abcl.jar file which > will be created next to the j.jar file. Only 1 problem: I have no > experience with the Ant build system (as a creator). > >> 1.1 With a j.jar, J becomes the "first-class" consumer of ABCL: we >> support releasing it in its current state until someone shows up who has >> a real interest in extending J in some manner. Getting tests that show >> a given release of J is acceptable would help create a better release >> process. > > Absolutely! And I think we will need a release process defined. > >> 1.2 We create an easily extendable test suite for ABCL that includes > >> 1.2.1 The ANSI tests >> >> 1.2.2 the stuff under src/org/armedbear/lisp/tests > > Agreed. > >> 1.2.3 What we need to gain confidence that our fixes for ABCL are not >> messing up things that we thought were working > >> This test suite becomes a consumer of ABCL as well, but is not included >> in abcl.jar. > > That would be nice. However, I think the current tests/ directory is > excluded upon j.jar creation. > >> 3. We start building releases with JDK-1.5 from Sun as the most common >> JVM "platform" out there. I can do older releases with JDK-1.4 under >> ia32-solaris-5.11 if neeeded, but this would be in a special binary. >> Something like Retroweaver (??) could help "back porting" anything we >> end up doing with Java 5 specific features like Annotations, but I could >> use some help here because I haven't regularly used JDK-1.4 since 2005. > > Well, there's one problem with javac1.4, because I've introduced > generics to silence compiler warnings about unchecked code: they are > 1.5 level compatibility. Does your solaris 1.4 JDK support generics? > >> 4. We plan on skipping JDK-1.6 as a target platform, going directly for >> the first widely deployed OpenJDK to implement JSR-292. This set of >> target platforms currently contains only the Da Vinci VM by John Rose >> et. at. at Sun. > > Having a MOP at all would be more of a priority to me than using the > invokedynamic instruction, especially because that would bring ABCL on > par with some of the other implementations out there. *Having* the > functionality is required before you can work on the speed of the > implementation :-) However, what's great here is that this is open > source and everybody gets to scratch his/her itch, meaning that if > this is your priority, that's perfectly fine (and I'll support it too, > btw). > >> 4.1 ABCL 1.0 would run on Java 5 >> >> 4.2 ABCL 2.0 would run on Java 7 (and redo the underlying Java class >> structure to efficiently utilize JSR-292's invokedynamic) > > 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=/ > _______________________________________________ > armedbear-j-devel mailing list > arm...@li... > https://lists.sourceforge.net/lists/listinfo/armedbear-j-devel > |
From: Ville V. <vil...@gm...> - 2008-09-09 14:53:09
|
On Tue, Sep 9, 2008 at 5:39 PM, Alan Ruttenberg <ala...@gm...> wrote: > FWIW I support the idea of splitting the projects, both at the source > and distribution levels. > -Alan I'd think that we can do separate+combined releases for now. The split becomes much more interesting/feasible if we have JSR-223 in place on both sides. That needs to wait until we are ready to make Java 7 versions of abcl and J. |
From: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX - 2008-09-09 15:27:59
|
On Tue, Sep 9, 2008 at 4:53 PM, Ville Voutilainen <vil...@gm...> wrote: > On Tue, Sep 9, 2008 at 5:39 PM, Alan Ruttenberg > <ala...@gm...> wrote: >> FWIW I support the idea of splitting the projects, both at the source >> and distribution levels. >> -Alan > > I'd think that we can do separate+combined releases for now. Right. In one of my earlier mails I detailed my view on how to proceed there. >The split becomes much > more interesting/feasible if we have JSR-223 in place on both sides. Well, I guess this depends on what we're trying to achieve by splitting the projects. Myself, I think that the projects could attract more interest as separate projects (Common Lisp tends to scare the average Java developer). This does not require elimination of the dependency of J on ABCL, though: ABCL can still be the scripting language for J as long as we're not releasing anything Java 7 based. > That needs to wait until > we are ready to make Java 7 versions of abcl and J. Yes. But when I look at when we'll be able to *require* Java 7 as the lowest level of support, I don't think this is going to be any time soon: usually it takes 3 to 4 years for a new release to become widely available. Setting the minimum level to 7 hence would be due in 3 to 4 years starting today *if* Java 7 would be released today. There's no harm ofcourse in having part of the code conditionalised on the target java platform, meaning that some ABCL/J features won't be available if the target isn't Java7 (however, they will be in the sources in case you do want them). I'm just trying to manage expectations here :-) I don't mind (would even encourage) supporting Java 7 specific features, however, Java 5/6 isn't gone yet for a long time to come. I'll see whether I can come up with a list of things which I consider important in terms of a shorter term future. I'd like to hear from others too. Although I have seen others express their views already, I still need to collect that input in order to create some overview. Bye, Erik. |
From: Ville V. <vil...@gm...> - 2008-09-09 15:54:05
|
On Tue, Sep 9, 2008 at 6:28 PM, XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX wrote: >>The split becomes much >> more interesting/feasible if we have JSR-223 in place on both sides. > Well, I guess this depends on what we're trying to achieve by > splitting the projects. Myself, I think that the projects could Having (at some point in the future) a java-scripting ability in J means that abcl can be the scripting language of J, in addition to other options. That's only a good thing for J. Same ability in abcl allows abcl itself to be used for anything compatible with java-scripting. That's why I see that as a worthy goal, although not something that should be pursued immediately. > attract more interest as separate projects (Common Lisp tends to scare > the average Java developer). This does not require elimination of the > dependency of J on ABCL, though: ABCL can still be the scripting > language for J as long as we're not releasing anything Java 7 based. Yes, this is probably a "marketing" issue. J itself does not contain lisp code. >> That needs to wait until >> we are ready to make Java 7 versions of abcl and J. > Yes. But when I look at when we'll be able to *require* Java 7 as the > lowest level of support, I don't think this is going to be any time Actually.. I think for abcl, we could build JSR-223 support on _top_ of abcl, without having to require it. JSR-223 support in J is a more intrusive change. So, we could build the JSR-223 support to abcl whenever we feel like, since the situation would still be J -> (vanilla) abcl and JSR223 scripting user -> JSR 223 scripting adaptation -> (vanilla) abcl then, much later, the situation for J changes to J -> JSR 223 scripting adaptation -> (vanilla) abcl -VJV- |
From: Mark E. <ev...@pa...> - 2008-09-09 16:10:33
|
Erik Huelsmann wrote: > On Tue, Sep 9, 2008 at 4:53 PM, Ville Voutilainen > <vil...@gm...> wrote: >> On Tue, Sep 9, 2008 at 5:39 PM, Alan Ruttenberg >> <ala...@gm...> wrote: >>> FWIW I support the idea of splitting the projects, both at the source >>> and distribution levels. >>> -Alan >> I'd think that we can do separate+combined releases for now. > > Right. In one of my earlier mails I detailed my view on how to proceed there. > >> The split becomes much >> more interesting/feasible if we have JSR-223 in place on both sides. > > Well, I guess this depends on what we're trying to achieve by > splitting the projects. Myself, I think that the projects could > attract more interest as separate projects (Common Lisp tends to scare > the average Java developer). This does not require elimination of the > dependency of J on ABCL, though: ABCL can still be the scripting > language for J as long as we're not releasing anything Java 7 based. > >> That needs to wait until >> we are ready to make Java 7 versions of abcl and J. > > Yes. But when I look at when we'll be able to *require* Java 7 as the > lowest level of support, I don't think this is going to be any time > soon: usually it takes 3 to 4 years for a new release to become widely > available. Setting the minimum level to 7 hence would be due in 3 to 4 > years starting today *if* Java 7 would be released today. > > There's no harm ofcourse in having part of the code conditionalised on > the target java platform, meaning that some ABCL/J features won't be > available if the target isn't Java7 (however, they will be in the > sources in case you do want them). Such conditionalization of the ABCL source tree would make compilations actually much tougher, especially since Java as a source language doesn't have even some primitive macroization as present in ANSI C. We'd have to rely on an external tool, the Java would break in many IDEs etc. > I'm just trying to manage expectations here :-) I don't mind (would > even encourage) supporting Java 7 specific features, however, Java 5/6 > isn't gone yet for a long time to come. […] To reiterate my proposal for "ABCL 1.0" and "ABCL 2.0" (and remember that ABCL-0.0.10.20 does NOT really run that well under Java 6 for reasons that have no been immediately apparent in about a week of profiling). This proposal reflects my personal views that a) I am primarily interested in ABCL and b) we owe out to Peter Graves to at least keep J at its current level of functionality. ABCL 1.0 ======== 1. The priority of most of the ABCL community (all three of us!) 2. Targeted to Java 5. No Java 6 only features. Backporting to JDK 1.4 a subpriority. 3. Mostly about gathering tests, and stabilizing the current code base without major changes. Priorities like "working MOP" and "hunchentoot runs" are defined and evaluated as to what is possible 4. Should be released in the next eighteen months (possibly with a monthly ABCL 0.1, ABCL 0.2, etc. like SBCL) ABCL 2.0 ======== 1. Where all the features go that don't make it into ABCL 1.0 2. Where we look at possibly redoing the core ABCL class structure to make more efficient uses of post Java 5 JDKs. 3. Hooks up with the rest of the JVM dynamic language community (jruby, jpython, scala, clojure, kawa) in terms of possibliy reusing commonly used frameworks (bytecode synthesizers, dynamic dispatch efficiency tricks, etc.) -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now." |
From: Ville V. <vil...@gm...> - 2008-09-09 16:24:10
|
On Tue, Sep 9, 2008 at 7:10 PM, Mark Evenson <ev...@pa...> wrote: >> There's no harm ofcourse in having part of the code conditionalised on >> the target java platform, meaning that some ABCL/J features won't be > Such conditionalization of the ABCL source tree would make compilations > actually much tougher, especially since Java as a source language > doesn't have even some primitive macroization as present in ANSI C. > We'd have to rely on an external tool, the Java would break in many IDEs > etc. If we'd want to do such conditionalization (I don't see it necessary at this point), we could do it by building with ANT. Meaning separate source files for Java7/others and then building different sets of source files for different targets. Not hard at all, but as I said, not necessary. The IDEs are capable of importing an existing ANT project. |
From: Mark E. <ev...@pa...> - 2008-09-09 16:50:28
|
Ville Voutilainen wrote: > On Tue, Sep 9, 2008 at 7:10 PM, Mark Evenson <ev...@pa...> wrote: >>> There's no harm ofcourse in having part of the code conditionalised on >>> the target java platform, meaning that some ABCL/J features won't be >> Such conditionalization of the ABCL source tree would make compilations >> actually much tougher, especially since Java as a source language >> doesn't have even some primitive macroization as present in ANSI C. >> We'd have to rely on an external tool, the Java would break in many IDEs >> etc. > > If we'd want to do such conditionalization (I don't see it necessary at this > point), we could do it by building with ANT. Meaning separate source > files for Java7/others and then building different sets of source files for > different targets. Not hard at all, but as I said, not necessary. The IDEs > are capable of importing an existing ANT project. I would like to always maintain the ability of unix$ ant compile to at least attempt a local bootstrap compilation. Currently the code in abcl-dynamic-install [abcld] tries to maintain "buildability" in this sense (bugs, patches, tests welcome!) [abcld]: http://code.google.com/p/abcl-dynamic-install/source/browse/trunk/abcl/build.xml -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now." |
From: Mark E. <ev...@pa...> - 2008-09-08 09:59:13
|
Just wondering: is there an HTTP only way to access the common-lisp.net SVN repos? Firewall situation in the lab makes non port-80 and port-443 mechanisms with HTTP/1.0 wrapping problematic. Mark <ev...@pa...> -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now." |
From: Mark E. <ev...@pa...> - 2008-09-08 11:48:13
|
Ville Voutilainen wrote: […] > What about JSR-223, aka Java Scripting? I've been toying with the idea of > 1) J using the java scripting framework > 2) abcl providing the canonical lisp implementation for java scripting > > This would allow J to be independent of abcl/lisp, allowing scripts for J > to be written in any language supported by the scripting framework. It would > also allow abcl to be used by projects other than J (that's of course > alredy possible > at the moment but maybe it would be nicer to integrate well to JSR-223 > if that's supposed to be "the official way to integrate java to other > languages"). I haven't really looked at JSR-223, but in principle this sounds like an interesting idea for the community that is interested in J. Putting "reading JSR-223" on my TODO list… Mark -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now." |
From: Ville V. <vil...@gm...> - 2008-09-08 15:09:53
|
On Mon, Sep 8, 2008 at 2:48 PM, Mark Evenson <ev...@pa...> wrote: > I haven't really looked at JSR-223, but in principle this sounds like an > interesting idea for the community that is interested in J. > Putting "reading JSR-223" on my TODO list… An introductionary article is at http://java.sun.com/developer/technicalArticles/J2SE/Desktop/scripting/ |
From: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX - 2008-09-08 14:20:19
|
On Mon, Sep 8, 2008 at 11:59 AM, Mark Evenson <ev...@pa...> wrote: > Just wondering: is there an HTTP only way to access the common-lisp.net SVN > repos? Firewall situation in the lab makes non port-80 and port-443 > mechanisms with HTTP/1.0 wrapping problematic. I have brought this up on the common-lisp.net development list (for the site, that is, not for ABCL). I'm awaiting a response now. I assume you mean to check out the sources, right? Do you have a HTTPS proxy server? If so, I should create a plugin for Subversion some day which allows svn: traffic over HTTPS proxy servers (it's possible!). Bye, Erik. |
From: Mark E. <ev...@pa...> - 2008-09-08 14:55:12
|
XXXXXXXXXXXXXX wrote: […] > Do you have a HTTPS proxy server? If so, I should create a plugin for > Subversion some day which allows svn: traffic over HTTPS proxy servers > (it's possible!). Then let's make such a plugin in ABCL… ;) Not really such a showstopper for me: just that I have to set up such svn proxies myself (from public UNIX hosts that I control) when on my corporate net. Meanwhile, I have an SVN copy under the [abcl-dynamic-install (abcld) Google code project][abcld]. I'll use this as public "scratch" space before shaping patches back to the Common-Lisp.net repos (via Erik). This version should be conservatively stable, and is starting to acquire a ressucitation of the [ABCL test framework based on :RT][test-abcl]. [abcld]: http://code.google.com/p/abcl-dynamic-install/source/browse/#svn/trunk/abcl [abcl-test]: http://code.google.com/p/abcl-dynamic-install/source/browse/trunk/abcl/abcl-test.asd -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now." |
From: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX - 2008-09-08 19:30:13
|
On Mon, Sep 8, 2008 at 4:55 PM, Mark Evenson <ev...@pa...> wrote: > XXXXXXXXXXXXXX wrote: > […] >> >> Do you have a HTTPS proxy server? If so, I should create a plugin for >> Subversion some day which allows svn: traffic over HTTPS proxy servers >> (it's possible!). > > Then let's make such a plugin in ABCL… ;) > > Not really such a showstopper for me: just that I have to set up such svn > proxies myself (from public UNIX hosts that I control) when on my corporate > net. I found http://www.agroman.net/corkscrew/, which does exactly what I mean. It connects to an HTTP proxy and uses the CONNECT method to set up a connection from the proxy to an outside host. If your proxy is permissive enough, this should also allow connecting to the svn:// protocol port 3690. > Meanwhile, I have an SVN copy under the [abcl-dynamic-install (abcld) Google > code project][abcld]. I'll use this as public "scratch" space before > shaping patches back to the Common-Lisp.net repos (via Erik). That's fine too, ofcourse... > This version > should be conservatively stable, and is starting to acquire a ressucitation > of the [ABCL test framework based on :RT][test-abcl]. > > [abcld]: > http://code.google.com/p/abcl-dynamic-install/source/browse/#svn/trunk/abcl > > [abcl-test]: > http://code.google.com/p/abcl-dynamic-install/source/browse/trunk/abcl/abcl-test.asd You mean you're starting to work (again, maybe) on a testing framework you already started? /me adds looking at that to the todo list. Bye, Erik. |
From: Mark E. <ev...@pa...> - 2008-09-09 05:52:36
|
XXXXXXXXXXXXXX wrote: […] >> >> [abcl-test]: >> http://code.google.com/p/abcl-dynamic-install/source/browse/trunk/abcl/abcl-test.asd > > You mean you're starting to work (again, maybe) on a testing framework > you already started? /me adds looking at that to the todo list. > This is merely an ASDF wrapping of the existing test framework in the ABCL source tree. Actually, I don't currently include the existing tests in the ASDF definition, merely the test/clos.lisp and test/gray-streams.lisp as places to test the resepective functionality. Use RT:DO-TESTS to run the loaded tests. Mark -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now." |