On Mon, 21 Apr 2008 14:26:57 GMT, wrote:
> On 14 Apr., 17:55, "Auric__" <not.my.r...@[EMAIL PROTECTED]
> wrote:
>> On Sun, 13 Apr 2008 11:08:56 GMT, wrote:
>> > On 11 Apr., 18:30, "Auric__" <not.my.r...@[EMAIL PROTECTED]
> wrote:
>> >> INSTALLING:
>> >> As before, I had to edit the makefile to find my libX11. I
>> >> again recommend either mentioning this in the README, or
>> >> finding someone who knows how to write a configure script. (I'm
>> >> using a very standard Slackware install; this *will* be a
>> >> problem for people besides me.)
>>
>> > There exists the file src/read_me.txt which explains this
>> > problem.
>>
>> Okay. I only looked at the top-level README.
>
> Doing a configure script is at my to-do list but not at
> the top of it.
I know. Just thought I'd mention it.
>> >> The compile had no errors, but lots of warnings -- maybe double
>> >> the last time. The previous warnings were all complaints about
>> >> type casting; they're still there but this one added
>> >> "'variablename' is declared but not used" and "'variablename'
>> >> may be used uninitialized". [shrug]
>>
>> > Interestingly gcc is not able to recognize when the states of
>> > two variables are connected. Such as a global fail_flag variable
>> > and a local condition variable (cond). The connection is: As
>> > long as fail_flag is FALSE the cond variable is initialised.
>> > When the fail_flag is TRUE the cond variable is not used and
>> > therefore it could be in an uninitialized state. At several
>> > places I use such connected variable states which are not
>> > recognized by the gcc optimizer and are therefore flagged with a
>> > warning. I accept such warnings in performance critical paths. I
>> > am not willing to do "unnecessary" initialisations in
>> > performance critical paths of the program. At places that are
>> > not performance critical I do some of this "unnecessary"
>> > initialisations just to avoid such warnings. OTOH I was able to
>> > remove some of this "may be used uninitialized" messages by
>> > reordering program code.
>>
>> As I've said, I'm not much of a C-family programmer. [shrug]
>
> This is ok.The Seed7 package should not require too much
> C knowledge. Sorry for the delay in my response. I was
> busy doing the next release. This time I was not able
> to add something to the Bas7 interpreter, sorry for that.
> But at least I added a chapter about C compiler warnings
> to the file seed7/src/read_me.txt . BTW.: Instead of
> improvements for Bas7, several improvements were done to
> sup****t bigInteger's better. Really big integers with
> unlimited precision. Well, unlimited as long as you do not
> run out of memory. Some small programs which compute PI to
> 1000 digits were also added.
That's interesting. How'd you do the bigints?
>> >> The BASIC programs all run a bit slow. (I can't recall if this
>> >> was happening in the previous version; I was mostly looking to
>> >> see if they worked at all.) I chalk it up to the fact that the
>> >> interpreter is itself interpreted, but you may want to check
>> >> for yourself.
>>
>> > Yes, if you call Bas7 with './hi bas7 myProg', the Bas7
>> > interpreter is itself interpreted. That way you have two levels
>> > of interpretation. But it is also possible to compile the Bas7
>> > interpreter with './hi comp bas7' in the seed7/prg directory.
>> > This should produce a bas7 executable which can be used to
>> > execute basic programs with './bas7 myProg'.
>>
>> I never noticed that. I'll try it tonight or so.
>
> Did you do tests with the compiled Bas7 interpreter?
Sorry, no. Last week was a little bit of hell for me; I didn't get
much of anything done. If I can keep my eyes open tonight, I'll try
it, but no promises.
>> >> Also, text-mode colors still aren't there. (I realize they're
>> >> probably pretty low on the todo list.) *This* is what I meant
>> >> last time by "no colors". (I ran a BASIC program that "tests"
>> >> VGA colors.)
>>
>> > The text colors work in graphic windows (but there are lots of
>> > other problems with graphic windows). The solution I plan for
>> > text colors is to have always graphic windows (also for text
>> > only programs). That way it would not be necessary to improve my
>> > console (screen) driver to work with colors.
>>
>> Not for me. I tried a few different BASIC color toys under plain
>> terminal (no X), xterm, Konsole, and GNOME Terminal. I'll send
>> them to you tomorrow so you can see if it's just me.
>
> I am looking forward for them
I'll try to remember to bring them tomorrow -- but again, no promises.
>> >> I haven't tried any actual graphical programs, but then, I
>> >> don't think that I have any with line numbers...
>>
>> > Bas7 can also execute basic programs without line numbers.
>> > It has also sup****t for various features of QBasic (DO, SELECT,
>> > structured IF, ...). Several im****tant features of QBasic are
>> > currently not sup****ted with Bas7: Subprograms and functions
>> > with parameters (subprograms without parameters work), user
>> > defined types, common blocks... I do not want to advertise the
>> > features of QBasic that Bas7 sup****ts, until more of them work.
>>
>> I'll try some of the demos I wrote (they're all pretty simple) and
>> let you know.
>
> Ok.
As long as bas7 sup****ts something resembling QBASIC's SCREEN 12, they
*should* work. As with everything else, I'll try to test tonight, but
no promises.
--
That's right, baby -- information hiding.
-- D. Alexander Garrett
|
