[armedbear-devel] long

Tue Mar 23 06:51:12 UTC 2010

Ok LarKC now supports full Common Lisp now. (ready for consumption!)

Now passes LarKC UnitTest (and runs LarKC) and ANSI-TESTs

Although I am checking in at
http://larkc.svn.sourceforge.net/viewvc/larkc/branches/LarKC_CommonLisp_Extensions/
as well.. I am trying to pace myself

Though I'd consume it with

 hg clone https://logicmoo-invoke-interface.googlecode.com/hg/ larkc-platform

Build with ant -f lisp-build.xml

run with

java -jar lib/larkc-platform.jar

Armed Bear Common Lisp 0.20.0-dev
Java 1.6.0_14 Sun Microsystems Inc.
Java HotSpot(TM) 64-Bit Server VM
Low-level initialization completed in 8.531 seconds.
LISP_HOME = C:\development\logicmoo-invoke-interface\bin\com\cyc\tool\subl\jrtl\nativeCode\commonLisp\
Startup completed in 13.297 seconds.
Type ":help" for a list of available commands.
CL-USER(1):

The number long  vs bigint - the reason for the email discussion can be tested.

On Wed, Mar 17, 2010 at 3:38 AM, dmiles at users.sourceforge.net
<logicmoo at gmail.com> wrote:
> On Tue, Mar 16, 2010 at 10:25 PM, Alan Ruttenberg
> <alanruttenberg at gmail.com> wrote:
>> On Wed, Mar 17, 2010 at 12:34 AM, dmiles at users.sourceforge.net
>> <logicmoo at gmail.com> wrote:
>>> On Tue, Mar 16, 2010 at 8:57 AM, Alessio Stalla <alessiostalla at gmail.com> wrote:
>>>> On Tue, Mar 16, 2010 at 4:41 PM, Alan Ruttenberg
>>>> <alanruttenberg at gmail.com> wrote:
>>>>>
>>>>> On Mar 16, 2010, at 8:47 AM, dmiles at users.sourceforge.net wrote:
>>>
>>> The java lisp I work on has bignum types that get demoted and promoted
>>> as needed.
>>
>> So, this begs the question: What is the difference between your lisp
>> and ABCL?
>
> ABCL is CommonLisp
> LarKC is SubLisp written to support the Cyc® application, allowing it
> to run both under Lisp environments
> and as a Java application generated by a SubL-to-Java translator.
>
> It was 4 years ago as I was able to complete a highly successful merge
> the two code bases of ABCL and the JavaLisp that LarKC uses.
> It ran both languages equally well (since SubLisp is compatible with
> common lisp when used from its own lisp package)..  And passed at
> least the same ANSI-TESTs
> At that time, ABCL was only passing 90 some ansi-tests, LarKC project
> hadn't started, and the JavaLisp's development was secret.
>
> Code-wise the major difference was I took parts of the ABCL
> compiler/interpreter to make it targets the JavaLisp's lisp object
> system which is based on java interfaces instead of ABCLs current
> non-interface representations.  For instance you could take any
> working java source (like JENA or DROOLS).. and add the lisp
> interfaces  Vector, Cons, Symbol, HashTable, StructureObject etc, as
> long as you add whatever methods they contracted, Lisp could not tell
> the difference between it and something it had produced on its own.
> This often allowed zero "re-representation" of data between java and
> lisp.   (This also lets generator tools like
> beanshell/jruby/jython/etc  to implement Mixins with any superclass or
> implementation they please)
>
> Another difference is most all symbol functions are converted to final
> static methods... and static methods just call static methods..
> calling more static method (when this is undesirable the user uses
> "define-public" which means its #'funcallable outside of the java file
> is in).. this made it so not as many java must be "new"ed while the
> lisp application is running.
>
>> Is your lisp ready for consumption?
>
> The merge of ABCL took four months of the following routine:
>
> 1) Balance plates for 10-16 hours - run the ansi-tests watch them all
> smash.. start all over the next day.
> 2) Balance plates for one hour . watch the ansi-tests for 5 minutes..
> repeat 15 more times (only 10 start overs!)..
> 3) next day only lost 3 hours!
> 4) next day lost no hours.
> 5) next day get brave and improve something difficult - failure - lose
> 1-3 whole days of life
> 6) next day only lose 5 hours
> 7) smile/talk to wife/family for 15 minutes
> 8) get brave and improve something difficult - success!
> 9) goto 1 - repeat this loop 15-20 times
>
> So since then, the original JavaLisp (with a few bits an pieces from
> the above merge in it) has become the central platform of LarKC.
>
> The new ABCL team has improved ABCL in some great ways (ansi-tests
> went from ~90 failures to ~28 failures).
>
> So I have developed amnesia and starting over the with the LarKC
> project doing the same merge because this time it is open sourced.
> Integrating those same features from above and reusing the ABCL's
> compiler and current improvements and incorporating new ones when they
> happen.
>
> With lessons learned for this time around... It should only take 1-2
> months to complete full ansi lisp compatibility again
>
>
>> Does it make sense to combine efforts?
>
> Probably, but I brought this up to ABCL a few times in the last 16
> months.. They have accepted some ansi-test fixes but I don't think
> they like the redesign of ABCL into a something that is an unknown
> quantity for them.  Some parts of the new design/merge to ABCL were
> very brutal.  (and required the above work loop)
>
>>
>> I'm intrigued as I see it's associated with LarKC, and mostly I use
>> ABCL for projects related to ontology and semweb.
>>
>> -Alan
>>
>
> Indeed as LarKC is an application framework for writing semweb apps.
> My *goal* is to make it easier for people to write LarKC plug-ins. If
> they want to write in lispy language currently means they must learn
> SubLisp and then be willing to write in it afterwards.  To anyone that
> submits to doing this, I think they will get more out of the ability
> to use Common Lisp instead.   I'd like LarKC module authors to be able
> to leverage tools like Pellet in the middle of their code. They
> currently can plug in Pellet into the pipeline as module..just as LSW
> could be another pipeline module. (Pipeline modules can be called by
> each other).
>
> -Doug
>
>>>
>>> SubLFixnum  -> int
>>> SubLLongBignum -> long
>>> SubLBigIntBignum -> BigInteger
>>>
>>> The code is at http://larkc.svn.sourceforge.net/viewvc/larkc/branches/LarKC_CommonLisp_Extensions/platform/src/com/cyc/tool/subl/jrtl/nativeCode/type/number/
>>>
>>>
>>>
>>>
>>>
>>>
>>>>
>>>>> -Alan
>>>>>
>>>>>>
>>>>>>
>>>>>> On Mon, Mar 15, 2010 at 11:47 PM, Alan Ruttenberg
>>>>>> <alanruttenberg at gmail.com> wrote:
>>>>>>>
>>>>>>> Am I right to observe that abcl coerces any number > fixnum size to bigint?
>>>>>>> I'm having trouble calling a java method that takes a long. I seem to
>>>>>>> have worked around it calling the method with (new 'long
>>>>>>> "9223372036854775807") rather than 9223372036854775807 .
>>>>>>>
>>>>>>> Is this the desired behavior?
>>>>>>>
>>>>>>> -Alan
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> armedbear-devel mailing list
>>>>>>> armedbear-devel at common-lisp.net
>>>>>>> http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> armedbear-devel mailing list
>>>>> armedbear-devel at common-lisp.net
>>>>> http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel
>>>>>
>>>>
>>>
>>
>