On 29 January 2014 04:15, Rob Withers <robert.w.withers at gmail.com> wrote:
> Ok, I'm Robert, for professional reasons and done.  Charlie Robert is my
> nickname from long time back.  So let me stick to this email address...
>
> On Jan 28, 2014, at 1:54 PM, Eliot Miranda <eliot.miranda at gmail.com> wrote:
>
> Hi Charlie,
>
>
> On Fri, Jan 24, 2014 at 9:11 PM, charlie robert <charlie.robert at icloud.com>
> wrote:
>>
>> I was curious whether java may be used in Cog.  I recall a fair project
>> with the serialization and core pojo representation, but my memory   Might
>> java interoperate natively, so as to call a java function in smalltalk, as a
>> smalltalk call with a closure/continuation, or perhaps in the other
>> direction?
>
>
> I'm sure one can write a Smalltalk/Java interconnect.  There are a number of
> ways to do it.  What are your requirements?  What do you mean by "native"
> operation?  e.g. VisualAgeForJava?
>
>
> My requirements, hmm.
>
> 1 - I would like to have .class files able to load in your VM/ObjectMemory.
> 2 - I would like java byte codes "JITted" into Smalltalk byte codes.
> 3 - I would like if one side (squeak) could invoke the other side (java)
> without explicit wrappers, and vice versa.  I mean this as native.
> 4 - I would like java serialization support.
> 5 - like JVM 8 has a byte code for reflective lookup, I would like Smalltalk
> bytecodes to have one bytecode for direct invocation, and bypass the
> reflective meta call
> 6 - I want to run scala on Cog/Spur
> 7 - then the "JIT"...I would like the program to start in dynamic mode then
> "JIT" with a call to the inferencer to determine type.
>
> This way, we have a JVM with mutable refs (become) so it would be a JVM++.
>
> The thing that gets me is that barely anything really interoperates.
>
>
>>
>>  COudl a scala type inferencer be built in Spur’s runtime? runtime?
>
>
> I'm not sure what you mean.  Could you elaborate?  Spur is an object
> representation and set of garbage collection/memory management facilities.
> As such wouldn't it live below any type inferencer?
>
>
> Ok it is the inner Cog axle I think of, not Spur.  The lookup and invocation
> of a send, of a method.  At its root handler it could call an inline scala
> type inferencer.

I don't understand this. Type inference happens at compile time. Once
you have bytecodes, there is no type inference going on.

As an example, once Scala has compiled, method lookup is all about JVM
bytecodes, which have no idea about the Scala type system. In fact,
the Scala-ness has _disappeared_ after compilation, which is why you
can decompile the bytecodes as plain Java. (Well, where "plain" means
"mangled to pieces, and has random metadata scattered everywhere".)

frank

>> Eliot, I am quite intrigued on your blog post on Spur’s object stack
>> representation.  Does this format touch on the heap structure of an object?
>
>
> What exactly do you mean by "Spur’s object stack representation"?  Do you
> mean Spur's object representation, or do you mean the ObjStack datatype?
> The latter is merely a segmented stack, like building OrderedCollection out
> of a linked list of pages, each page containing up to N elements.
>
>
>
> So Spur specifies heap structure?  Vis-a-Vis the lack of interoperability,
> Cap'n Proto would be just the thing to interoperate java and squeak and
> scala and groovy.   You own the metal so you can do whatever you imagine.
>
>>  Either way, using Cap’n Proto in the heap and Spur for the stack/queue
>> structures would be really nice if someone had one.  Does a lord or lady own
>> such a magic item +4?  on a raspberry?
>
>
> https://plus.google.com/+KentonVarda/posts/GRJ4h4w2UN9?  Or am I being
> cynical?
>
>
> I am missing all this, 'cuse me '
>
> Indeed, best,
> Robert
>
>
>>
>> so sorry for all that noise ,
>> - charlie (Rob WIthers)
>
>
> --
> best,
> Eliot