headers
Bob the Hamster | 1 Mar 2005 09:35
Favicon

RE: weird numeric-selection bug?

On Tue, Mar 01, 2005 at 01:38:42PM +1300, TeeEmCee wrote:
> Someone posted about this on the helpme board earlier, and I have the
> same bug, under DOSBOX on all my windows XP machines.
> 
> This seems to occur on all menus and number inputs, whether you type
> in the number or shift to it with left and right keys.

I had previously stated that I could not reproduce this. I retract that 
statement. I am seeing this symptom on DOSBOX on my Mac. I guess I 
wasn't paying enough attention before ;)

Knowing how those menus work, this bug feels VERY strange to me. There 
are two possibilities I want to investigate.

(1) Is DOSBOX sending spurious keyboard events of some kind? I am 
working on a small keytest app to check this out, but it needs more 
work.

(2) Are all "N1 > N2" wrong in DOSBOX? This seems utterly impossible, 
since it should mess up nearly every DOS program ever. How then is > 
checking be wrong in only the one specific situation of OHRRPGCE menus? 
What makes the bounds checking on menus different?

This is almost certainly a DOSBOX bug, but we may be able to help them 
fix it, or at least find a workaround.

---
James Paige
(Continue reading)

Permalink | Reply | 0 comments |
headers
David Gowers | 1 Mar 2005 19:45
Picon

weird numeric-selection bug? (fix!)

The latest DOSBox (0.63 CVS) says 'some keyboard fixes' in the changelog. by 
the time I send this I'll have finished recompiling it and can tell if it 
fixes this.
Edit -- Yep! it's fixed! So upgrade to 0.63!

While i'm waiting for that.. If lexing something produces tokens, what does 
parsing produce? Well, a token is just a representor; so parsing produces 
tokens too; but i don't like calling them the same thing..

With my stack based architecture, they are all very much like instructions fed 
into a highly programmable CPU. the term 'instruction' is better, but still 
doesn't note the basic distinction between lexical units and parsed phrases.
hah, i answered my own question: ''a lex' for what the lexer sees as a unit, 
and 'a phrase' for what the parser sees as a unit.

I appreciate the simplicity of the HSS format much more now -- while lexing 
QBASIC code is easy, parsing QBASIC lexes is rather less easy.
I've found i have to split the parsing up into stages; the first one i am 
working on currently, "build symbol table"; this compresses function and 
array declarations into single phrases.
Each stage will compress the stack into less, more language-independent 
phrases, so that at the end the stack phrases are independent of QB-isms.

--
Neo
Permalink | Reply | 3 comments |
headers
Bob the Hamster | 2 Mar 2005 13:22
Favicon

weird numeric-selection bug? (fix!)

On Wed, Mar 02, 2005 at 02:28:33PM -0500, David Gowers wrote:
> The latest DOSBox (0.63 CVS) says 'some keyboard fixes' in the changelog. by 
> the time I send this I'll have finished recompiling it and can tell if it 
> fixes this.
> Edit -- Yep! it's fixed! So upgrade to 0.63!

Hmm. Testing with 0.63 on linux, I see the bug. Do you mean that it is 
fixed in CVS *after* 0.63? (like in an unreleased 0.63.1 or 0.64?)

> I appreciate the simplicity of the HSS format much more now -- while lexing 
> QBASIC code is easy, parsing QBASIC lexes is rather less easy.
> I've found i have to split the parsing up into stages; the first one i am 
> working on currently, "build symbol table"; this compresses function and 
> array declarations into single phrases.
> Each stage will compress the stack into less, more language-independent 
> phrases, so that at the end the stack phrases are independent of QB-isms.

I was thinking about your translexing project. GOTO's are impossible to 
directly translate into python (and most other sane languages). I did a 
search, and to my undying shame, I actually still have 65 of them 
scattered around the code.

Fortunately nearly all of them are used in contexts where an "EXIT DO" 
would be far more appropriate. I will work on purging the code of all 
embarrassing GOTO's

---
James
(Continue reading)

Permalink | Reply | 2 comments |
headers
Mike Caron | 2 Mar 2005 13:57

weird numeric-selection bug? (fix!)

It's ok, GOTO happens to everyone when they start. Particularly in a 
language like QBasic which tries to be both high and low level at the 
same time.

Mike Caron
Final Fantasy Q
http://finalfantasyq.com

Bob the Hamster wrote:

>On Wed, Mar 02, 2005 at 02:28:33PM -0500, David Gowers wrote:
>  
>
>>The latest DOSBox (0.63 CVS) says 'some keyboard fixes' in the changelog. by 
>>the time I send this I'll have finished recompiling it and can tell if it 
>>fixes this.
>>Edit -- Yep! it's fixed! So upgrade to 0.63!
>>    
>>
>
>Hmm. Testing with 0.63 on linux, I see the bug. Do you mean that it is 
>fixed in CVS *after* 0.63? (like in an unreleased 0.63.1 or 0.64?)
> 
>  
>
>>I appreciate the simplicity of the HSS format much more now -- while lexing 
>>QBASIC code is easy, parsing QBASIC lexes is rather less easy.
>>I've found i have to split the parsing up into stages; the first one i am 
>>working on currently, "build symbol table"; this compresses function and 
>>array declarations into single phrases.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Simon Bradley | 2 Mar 2005 16:39
Picon

weird numeric-selection bug? (fix!)

All these fancy loops and calls turn into GOTOs in the end, after
they're compiled. :-) There's nothing inherently wrong with them, in
my opinion. I look on it as one of those rules that it's okay to break
as long as you understand why the rule is there. :-)

(Okay, so I can't think of any occasion I would actually use one
outside of assembly language, where you don't have much choice, but
that's not the point.)

Simon

On Wed, 02 Mar 2005 15:57:08 -0500, Mike Caron
<pkmnfrk <at> finalfantasyq.com> wrote:
>  It's ok, GOTO happens to everyone when they start. Particularly in a
> language like QBasic which tries to be both high and low level at the same
> time.
>  Mike Caron Final Fantasy Q http://finalfantasyq.com 
>  
>  Bob the Hamster wrote: 
>  On Wed, Mar 02, 2005 at 02:28:33PM -0500, David Gowers wrote: 
>  The latest DOSBox (0.63 CVS) says 'some keyboard fixes' in the changelog.
> by the time I send this I'll have finished recompiling it and can tell if it
> fixes this. Edit -- Yep! it's fixed! So upgrade to 0.63! Hmm. Testing with
> 0.63 on linux, I see the bug. Do you mean that it is fixed in CVS *after*
> 0.63? (like in an unreleased 0.63.1 or 0.64?) 
>  I appreciate the simplicity of the HSS format much more now -- while lexing
> QBASIC code is easy, parsing QBASIC lexes is rather less easy. I've found i
> have to split the parsing up into stages; the first one i am working on
> currently, "build symbol table"; this compresses function and array
> declarations into single phrases. Each stage will compress the stack into
(Continue reading)

Permalink | Reply | 0 comments |
headers
David Gowers | 2 Mar 2005 17:13
Picon

weird numeric-selection bug? (fix!)


My parser is going great: 
* WHILE/WEND
* DO/ LOOP support is nearly in; 
* I recently added compression of END {IF|SUB|DEF|FUNCTION|TYPE) pairs.
* I am about to add code that adds endifs to the single line IF THEN ELSE 
statements
*  i worked out rvalues and wrote a stack 'op' to parse an rvalue.

yes, i shall translate goto-># comment goto for the time being
and label: into #label:
Twould be great to not neod to do any fiddling-around of that kind.

I propose a new lump, "system.txt"[1] to deal with future forking. This will 
hold a text string like "OHRRPGCE" which will indicate which editor it was 
made with; so accurate compatibility-detection can be achieved; as soon as a 
fork or derivative is released, the version-number in gen is not enough. 
(format V6 of a fork is almost certainly different from the hypothetical V6 
of a future OHRRPGCE)
I am willing to make the appropriate patch if this is approved.

[1] or 'editor.txt'. I haven't figured out a really good name yet.
Permalink | Reply | 29 comments |
headers
Mike Caron | 2 Mar 2005 17:30

weird numeric-selection bug? (fix!)

I think we should burn that bridge when we get to it, as right now 
there's only one version of the OHR, and it looks like your 
compiler/parser (I'm not entirely clear as to what you're doing)
A) Won't be done for a while, what with all the funky QBasic syntax
and
B) Might obsolete the original QBasic source, if you're successful

Perhaps you should put it on SourceForge or something.

(Oh, and BTW, I don't think there's any DEF/ END DEF blocks. DEF SEG is 
a statement)

Mike Caron
Final Fantasy Q
http://finalfantasyq.com

David Gowers wrote:

>My parser is going great: 
>* WHILE/WEND
>* DO/ LOOP support is nearly in; 
>* I recently added compression of END {IF|SUB|DEF|FUNCTION|TYPE) pairs.
>* I am about to add code that adds endifs to the single line IF THEN ELSE 
>statements
>*  i worked out rvalues and wrote a stack 'op' to parse an rvalue.
>
>yes, i shall translate goto-># comment goto for the time being
>and label: into #label:
>Twould be great to not neod to do any fiddling-around of that kind.
>
(Continue reading)

Permalink | Reply | 25 comments |
headers
David Gowers | 2 Mar 2005 23:39
Picon

weird numeric-selection bug? (fix!)

Oh, i sillily forgot to answer the original q about .63 vs cvs. yes i was 
vague; i mean cvs. i always use a fairly recent cvs if i can.
The changelog says 0.63

Mike: actually, it could be made optional (only existing in forked RPG 
formats), and call it 'fork.txt'. That way, the only change needed to ohr 
would be to check if it exists -- this change can be done as soon as the 
first fork is released.

I intend to clear some things up.

a) think of a line of qbasic as a sentence, and a program as a book.
this is what my software does:
   1. QB->lex(lexing is like identifying the meaning of individual words in a 
sentence). this produces a series of lexes
   2. QB->parse(parsing is like identifying the meaning of a particular phrase 
i.e grouping of 'words'). this produces 'pars' in a language-independent 
format.
  3. Python->unparse. this goes straight from pars to text. for an example, i 
quote:
-cut-
def unparse_level_1(s, symbols, scope, data):
    "unparse level 1 instructions"
    o = data["output"]
    imports = data["imports"]

    i = s.pop()
    typ = i[0]

    if typ == DECLARE:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bob the Hamster | 2 Mar 2005 23:40
Favicon

weird numeric-selection bug? (fix!)

> yes, i shall translate goto-># comment goto for the time being
> and label: into #label:
> Twould be great to not neod to do any fiddling-around of that kind.

Yeah, I'll be getting rid of the GOTO's soon.
Can you convert a GOSUB/label/RETURN into a global-scoped function 
somehow? There are a heckofa lot of GOSUBs, and I don't think I want to 
even attempt to fully purge the code of their evil.

> I propose a new lump, "system.txt"[1] to deal with future forking. This will 
> hold a text string like "OHRRPGCE" which will indicate which editor it was 
> made with; so accurate compatibility-detection can be achieved; as soon as a 
> fork or derivative is released, the version-number in gen is not enough. 
> (format V6 of a fork is almost certainly different from the hypothetical V6 
> of a future OHRRPGCE)
> I am willing to make the appropriate patch if this is approved.
> 
> [1] or 'editor.txt'. I haven't figured out a really good name yet.

I doubt that the RPG format will ever go to 6 in the OHRRPGCE. Most 
changes in lump format can be hacked in backwards compatabilyly. For 
example, rather than re-sizing the GAMENAME.DT6 lump, neccesitating an 
RPG format version number increase, instead I added BINSIZE.BIN and 
ATTACK.BIN and left GAMENAME.DT6 alone. In other places you will notice 
I use a magic number (usually 4444) to indicate a new lump feature-- a 
hack yes, but I prefer that sort of hack over a version-number based 
hack :)

There is already a string in ARCHINYM.LMP that contains the version of 
the editor that the file was created with... but this currently doesn't
(Continue reading)

Permalink | Reply | 0 comments |
headers
TeeEmCee | 2 Mar 2005 23:43
Picon

weird numeric-selection bug? (fix!)

Not really true. I've already made a battleless version of game.exe
(experimental for now, I want to recreate it later using version
quarternion as a base). Mods will likely add features that the
original game.exe doesn't support, and there needs to be some way for
different versions of game.exe to work out if they can run an RPG
file. I think two things should be included: what it was made
with/for, and whether it is compatible with the original OHRRPGCE
engine, so that if no fundamental changes have been made, the original
will still run it.

"B) Might obsolete the original QBasic source, if you're successful"

I worry too :/

On Wed, 02 Mar 2005 19:30:07 -0500, Mike Caron
<pkmnfrk <at> finalfantasyq.com> wrote:
> I think we should burn that bridge when we get to it, as right now
> there's only one version of the OHR, and it looks like your
> compiler/parser (I'm not entirely clear as to what you're doing)
> A) Won't be done for a while, what with all the funky QBasic syntax
> and
> B) Might obsolete the original QBasic source, if you're successful
> 
> Perhaps you should put it on SourceForge or something.
> 
> (Oh, and BTW, I don't think there's any DEF/ END DEF blocks. DEF SEG is
> a statement)
> 
> Mike Caron
> Final Fantasy Q
(Continue reading)

Permalink | Reply | 24 comments |

Gmane