Author Topic: Manual Error Reporting  (Read 414 times)

crcasey

  • Newbie
  • *
  • Posts: 21
    • View Profile
Manual Error Reporting
« on: November 15, 2016, 05:27:00 PM »
I think that a line of code may have been left out of the first example of the manual section 2.7.1 on Array Initializers.

The comments do not match the statements in the first example block.

-Cecil

Vectrex32

  • Administrator
  • Full Member
  • *****
  • Posts: 101
    • View Profile
Re: Manual Error Reporting
« Reply #1 on: November 15, 2016, 05:40:46 PM »
Yup, that's a mistake. Thanks for catching it.

- Bob

crcasey

  • Newbie
  • *
  • Posts: 21
    • View Profile
Re: Manual Error Reporting
« Reply #2 on: November 15, 2016, 08:23:54 PM »
If I am reading the manual correctly the initializer returns a handle(pointer) to the array, which can either then be stored in a variable as a handle, or be used directly as a function argument.  In the second case what happens to the array when the function ends?

Does each handle keep a record of objects tied to it so that garbage collection happens?

Or another case say you store the array handle in the variable asdf. 
Then you do asdf=nul.
What happens to the array data?

I guess I wonder how much program memory there is and what you have done for garbage collection?

-Cecil

Vectrex32

  • Administrator
  • Full Member
  • *****
  • Posts: 101
    • View Profile
Re: Manual Error Reporting
« Reply #3 on: November 15, 2016, 08:27:59 PM »
Arrays that are no longer referenced by any variable or sprite are deallocated - the memory is freed.

- Bob

crcasey

  • Newbie
  • *
  • Posts: 21
    • View Profile
Re: Manual Error Reporting
« Reply #4 on: November 15, 2016, 09:04:37 PM »
Arrays that are no longer referenced by any variable or sprite are deallocated - the memory is freed.

- Bob

Are you actively managing memory fragmentation? 
Are there times when garbage collection will cause a slowdown in processing?  Assume something stupid like a stereo 16 bit, 1024 bin FFT running as part of the 32 bit side main loop.
Would those slowdowns ever show on the vectrex side as duplicate frames or stuttering?

-Cecil

Vectrex32

  • Administrator
  • Full Member
  • *****
  • Posts: 101
    • View Profile
Re: Manual Error Reporting
« Reply #5 on: November 15, 2016, 09:27:42 PM »
I'm using reference counting so there's no garbage collector and therefore no slowdowns. Freed memory blocks are coalesced with adjacent blocks (as you'd expect from C's malloc and free), but it's conceivable that memory fragmentation could cause a crash. There's no virtual memory or Windows 3.1-like moveable memory, so there's not much I can do if your BASIC program uses arrays in such a way as to cause fragmentation.

- Bob

crcasey

  • Newbie
  • *
  • Posts: 21
    • View Profile
Re: Manual Error Reporting
« Reply #6 on: November 15, 2016, 09:31:10 PM »
Good to know, Thanks.  I was wondering how much underlying OS you had to roll in.

I found another manual error.  Section 4.9 on functions.  No final output of the command in the example.

Assuming debug mode.

-Cecil

Vectrex32

  • Administrator
  • Full Member
  • *****
  • Posts: 101
    • View Profile
Re: Manual Error Reporting
« Reply #7 on: November 15, 2016, 09:36:18 PM »
You mean I don't say what value gets printed? It's an exercise left for the reader. :-)

- Bob

crcasey

  • Newbie
  • *
  • Posts: 21
    • View Profile
Re: Manual Error Reporting
« Reply #8 on: November 15, 2016, 10:09:13 PM »
I have gotten through the manual, and have talked with you for most of my questions.

You understand a language when you can read a program and run it in your head.  I know a couple.

The language is quite clear so that is in it's favor.
Stream or file objects will make it better.
But you could use the load .. reastart to do something like that.

In parts of the middle of the docuemnet some ways that you would be seeing the basic are not clear.
Example, one section refers to connecting to the card with a serial terminal (hardware manual).  The other section(near the end of the language doc) acts like the basic will be an .EXE on the host system. 

Maybe a bit of rework in that area to note that the whole basic system is on the card, not a system, so is totally portable.
 
That's what I got in the first read.
-Cecil


Vectrex32

  • Administrator
  • Full Member
  • *****
  • Posts: 101
    • View Profile
Re: Manual Error Reporting
« Reply #9 on: November 15, 2016, 10:23:19 PM »
The other section(near the end of the language doc) acts like the basic will be an .EXE on the host system. 

I wrote GSBASIC to be embeddable in any system or to run stand-alone on a PC, so that's why the GSBASIC manual sometimes mentions a host system. Currently, Vectrex32 is the only place I've used GSBASIC.

- Bob

crcasey

  • Newbie
  • *
  • Posts: 21
    • View Profile
Re: Manual Error Reporting
« Reply #10 on: November 15, 2016, 11:40:10 PM »
The other section(near the end of the language doc) acts like the basic will be an .EXE on the host system. 

I wrote GSBASIC to be embeddable in any system or to run stand-alone on a PC, so that's why the GSBASIC manual sometimes mentions a host system. Currently, Vectrex32 is the only place I've used GSBASIC.

- Bob

Just people reading the Vec32 manual seeing references to a win exe they have never seen may make the manual read a bit off.

I tried to read the manual as a newby on one side, and a techy on the other, that was why I split the qusetions up.

=Cecil
« Last Edit: November 15, 2016, 11:43:17 PM by crcasey »