Thank you for the lengthy help! I know that took a lot out of your time. I
for one really do appretiate your thoughtfulness. Please take that to heart.
I really mean that. I think that when you use cmdedit in my case it causes
the commands file created in the data directory to loose data. When you type
'save' while in the command editor or cmdedit. As for the aedit commands
this eludes me I have poured through that section of code and don't see
nothing really out of the ordinary. My resolution: Don't use cmdedit at all
until I get enough knowledge about c programming to locate identify and fix
the problem at hand. Would be nice if someone else might have had the same
problem with OLC 2.1 and fixed it, and may-be shared that knowledge on this
forum. *sigh* not my luck. Thanks again.
Dantin
----- Original Message -----
From: "Steve Boleware" <[EMAIL PROTECTED]>
To: "ROM Mailing List" <[email protected]>
Sent: Sunday, November 25, 2001 3:35 PM
Subject: Re: Question
> > I got this on the log screen.
> >
> > BUG: slow_olc_cmds : table NULL, editor 1
> >
> > Could someone translate this into laymans terms? I know I was in
aedit
> > and I typed commands on the prompt to view all possible commands.
Nothing
> > happened. I think thats what triggered this message. Could someone help
me
> > out with it?
> >
> > Dantin
>
> Good afternoon Dantin,
> Seeing as noone has yet offered a valid response to your question,
> I figure i will give it a go. :)
> First: "slow_olc_cmds :", having no idea of your editor of choice
> for changing code i will ask if you have a cygwin version of "grep",
> if not do a windows version of search for the above mentioned line.
> This is what appeared in your logfile, correct? It would then make
> sense to find where in the code that message is generated. Once you
> have found that block of code use your newfound knowledge along with
> the information of what you were doing when it crashed, you mentioned
> that you were in "aedit" when you typed a command and that the
> resulting entry in the logfile was the outcome. Armed with that info
> you can then use logic to read through your code and find what went
> wrong. Some people have mentioned trying to get your ROM into a *nix
> box. Some have also mentioned using "printf" statements. Both are valid
> solutions to finding code errors, (*nix for the gdb support, and printf
> as a poormans gdb) if you are stuck in a windows environment, the way to
> go would be the printf method, sure it takes a while but it will help you
> become more familiar with your code (actually reading it when you insert
> the statements). the second method mentioned was putting oyur code on a
> *nix box. For your purposes of coding and learning rom this would be
ideal.
> a box that can run linux could be as simple as an old pentium or a 486!
> if you want you could even use a multi-boot box... *nix on one partition
> and windows on another. LAST on the list would be trying to use GDB in
> Cygwin, windows uses a different stack structure, and as such when a
program
> that is run in a emulator window crashes it contains almost no usefull
info.
>
> I hope that above helps in some way.
>
> /-------------------------------------------------------------\
> | Steve Boleware | Beginning Coder |
> | [EMAIL PROTECTED] | Student of Life |
> | ICQ: 11120901 | |
> \-------------------------------------------------------------/
>
>
> --
> ROM mailing list
> [email protected]
> http://www.rom.org/cgi-bin/mailman/listinfo/rom
