Hi Lars,
> > Thanks in advance for that one! The missing Said() is a major showstopper
> > right now...
>
> I keep thinking maybe we should try to roll our own Parse()/Said() pair. Yes,
> I realize that they have come a long way since the beginning, but we don't
> _really_ understand the algorithms, there may be bugs we don't know about,
> and they may in turn affect further development. And the Said() function is
> just plain difficult (the path avoiding in SCI1 is going to be as well, but
> at least then we'll have patent descriptions of the algorithm (only general
> ideas, the computations aren't mentioned with one word)).
Actually, I'd prefer an implementation with a homemade design. However, I
don't know enough about the parser to pull this off, and I don't know
whether you do, either.
We can already verify whether the grammatical structure represented by the
input token sequence is valid (this is done while building the current
parse tree). Effectively, the only thing we need to do now is to match
that sequence against said specs. /Syntactically/, Said specs are a
finite sequence of elements from the operator set O := {',', '&', '/',
'(', ')', '[', ']', '#', '<', '>'} and the word list W. Also, you have
sent me an inductive definition of the semantics (yacc implementation is
in src/core/said.y) (sorry for repeating all these things, btw).
However, this still doesn't provide means for matching token strings to
said specs. To do that, we'd need to have at least an idea of what the
individual operators mean; applying this idea to said.y might (!) do the
trick.
So, let me do some more summarization (most of this information was
gathered from Dark Minister and may not be entirely valid):
a,b e W any word
x e (W u O)+ any expression
a matches the word a
a b matches the sequence 'ab' (b follows a)
a,b matches the word a (X)OR the word b (OR or XOR?)
/a matches any sequence ending with the word a
a> matches any sequence starting with the word a
(x) matches the expression x
[x] matches the expression x OR the empty string
a<b matches a AND b, in any order
If those are correct (big if), I should be able to implement them
manually. I'll try to do this tomorrow (giving you enough time to
object (I hope)). I'll first need to build a new grammar, though.
> Maybe you could do a 'simsaid <address>' console command like the 'simkey'
> you made way back, to allow us to beta-test more extensively until Said() is
> finished? Also, it would probably be a help for me to have a testing
> environment for Parse()/Said() which we don't have at the moment.
Good idea. I'll do that.
> Regarding that missing Graph() subfunction: I don't know if it's necessary at
> all. I think it was originally used to update the screen in rare cases. But
> the fact is that FreeSCI updates the screen a lot more than Sierra's SCI did.
> Yes, there is still that segfault which may be related,
Segfault? When?
> but it may also have
> other reasons - for instance your DisposeClone() function (IIRC) disposes a
> lot more than it should. underBits are really the bytecode's responsibility.
I thought so, too, but QG1 started running out of hunk space fairly
quickly without it. If Sierra SCI really doesn't handle them, that problem
was caused by a bug in a different place; the code should isse a warning
instead.
> In closing: ATM, I've got an IT project/report for my school and exams going
> right now. Though I will keep on working with FreeSCI as intensely as
> possible, it may get a bit slow. Yes, I must admit that I've been laying low
> on SCI research for a long time...
NP. I practically abandoned the project for over three months, too. Take
your time for your exams; they're more important than this project is.
llap,
Christoph
