On 21 Dec 2003 at 13:41, Jim Starkey wrote:

>>This message thread could be more prophetic than Helen imagined:

not

>>only does the UDF interface expose an internal engine structure, it
>>exposes one that shouldn't be there. In my opinion, runtime
>>descriptors will go the way of the Dodo, perhaps not in FB2.0, but
>>certainly before FB3.0
>>

[..snip..]

> useless. All this begs the larger question of serious, e.g. Java,
> embedded language.
>
> For the purposes of FB2.0/Vulcan, I think it's a non-issue.

Fully agree. The timescale will be many months, even years. Not 3
months, for sure. Although I'm quite close to achieving the goal of
getting Compiere to work with FB, prototyping all the ideas around
modifying the VM will take much longer.

>>There are three things that could be better, I think:
>>1. Change the design paradigm from 'stalling looper'

to 'multitasked

>>VM'. This will make the code flow easier to understand & maintain.

It

>>is mostly a semantic change: if you think about it, impure areas in
>>requests are like stack frames and the type field of JRD_NODs are
>>like opcodes, etc.
>>
> You are talking about two things that should be considered

separately,

> looper and the impure area.

I think you misunderstand me. I do not propose to store the state of
the VM (virtual CPU, virtual stack, etc.) on the C/C++ stack. I don't
see the advantage of that (and you mention some important drawbacks
too).

What I have in mind is a more a change of presentation than a change
of actual logic:
request -> virtual process
JRD_NOD tree(s) -> virtual code sections
impure area(s) -> virtual stack/heap
looper -> virtual CPU
etc.

> The impure area is a complete different story. The impure area

exists

> so many requests can share a compiled request. No matter how fast

you

> make the compiler, not having to compile will always be faster.

The

> impure area is a hidden jewel waiting to be exploited by compiled
> statement caching. Nickolay and I are of different minds as to

whether

> statement caching should be client or server side, but then he

hasn't

> been exposed to the power of filtersets.

Two points here.
(1) I fully agree on impure areas being a jewel. This is why I think
they shouldn't be hidden, hanging of the end of a request structure,
but be a first class citizen. This is one of the things I think will
be achieved by the change in presentation mentioned above.
(2) Not compiling is certainly better. This is why we have
prepare/execute. I agree that many contemporary client RAD tools
don't promote doing things the prepare/execute way, but just do
exec_immed's. Here server side chacing would be a benefit. How would
this work? (All I can think of now is to check for identical SQL
strings vs. recent history for the same client attachment).

>>3. Move type casting decisions from the runtime to the compiler.

SQL

>>is a strongly typed language and I believe so is GDML/blr Where

type

>>casts are necessary is known at compile time. Figuring this out
>>repeatedly at runtime is inefficient, as is the overhead of
>>maintaining type information (i.e descriptors). Hence, descriptors
>>will be superfluous. The runtime will work with 'naked' values

(i.e.

>>value union + null flag)
>>
> Pish-tosh. Since records can be of different format, you don't

know the

> datatype until runtime. Some decisions about datatype,

particularly

> datatypes of operations, can be determined at compile time, but

these

> are more the exception than the rule.

Hmmm... I don't get this. Sounds like I missed something crucially
important. Could you please elaborate, if you have time. Anybody else
can jump in too, to explain.

> Now that I'm being accused of brain-death, I have a little more

sympathy

> for the advocates of list civility.

I appologise for being abrasive; I got carried away a bit. Didn't
know it was you who added UDF's by descriptor, but anybody would have
deserved more civility.

> Gosh, a new value struct sounds remarkably like a descriptor.

Could you

> kindly explain the difference to those of us who are brain dead?

The difference is that the new struct would not contain type
information.

>>Slightly off-topic, I do see the need to provide UDF users with a
>>tool to cast types, especially from date to string and vice versa.
>>Would it be an idea to kill the current CVT_move entry point and to
>>bundle a separate dynamic lib with a type conversion utility like
>>CVT_move. I was thinking of doing something like that anyway.
>>
> Hard problem, no existence proof of a solution. Good luck.

Again, I don't understand this, but I take it as a "no, thank you, we
see no use for such a thing"

Paul