Subject | Re: Architectural Cleanliness: CVT_move |
---|---|
Author | paulruizendaal |
Post date | 2003-12-22T10:27:41Z |
On 21 Dec 2003 at 13:41, Jim Starkey wrote:
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.
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.
(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).
important. Could you please elaborate, if you have time. Anybody else
can jump in too, to explain.
know it was you who added UDF's by descriptor, but anybody would have
deserved more civility.
information.
see no use for such a thing"
Paul
>>This message thread could be more prophetic than Helen imagined:not
>>only does the UDF interface expose an internal engine structure, it[..snip..]
>>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
>>
> useless. All this begs the larger question of serious, e.g. Java,Fully agree. The timescale will be many months, even years. Not 3
> embedded language.
>
> For the purposes of FB2.0/Vulcan, I think it's a non-issue.
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:to 'multitasked
>>1. Change the design paradigm from 'stalling looper'
>>VM'. This will make the code flow easier to understand & maintain.It
>>is mostly a semantic change: if you think about it, impure areas inseparately,
>>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
> 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 areaexists
> so many requests can share a compiled request. No matter how fastyou
> make the compiler, not having to compile will always be faster.The
> impure area is a hidden jewel waiting to be exploited by compiledwhether
> statement caching. Nickolay and I are of different minds as to
> statement caching should be client or server side, but then hehasn'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 Wheretype
>>casts are necessary is known at compile time. Figuring this out(i.e.
>>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
>>value union + null flag)know the
>>
> Pish-tosh. Since records can be of different format, you don't
> datatype until runtime. Some decisions about datatype,particularly
> datatypes of operations, can be determined at compile time, butthese
> 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 moresympathy
> 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 aAgain, I don't understand this, but I take it as a "no, thank you, we
>>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.
see no use for such a thing"
Paul