Forum
Portal

Welcome, Guest
You have to register before you can post on our site.

Username
  

Password
  

Search Forums

(Advanced Search)

Forum Statistics
» Members: 258
» Latest member: manuelzo75
» Forum threads: 1,074
» Forum posts: 6,434

Full Statistics

Online Users
There are currently 331 online users.
» 0 Member(s) | 329 Guest(s)
Bing, Google

Latest Threads
.tap file code not execut...
Forum: Help & Support
Last Post: Zoran
04-28-2025, 10:59 AM
» Replies: 4
» Views: 206
Exit from more than one l...
Forum: Wishlist
Last Post: Duefectu
04-23-2025, 10:06 PM
» Replies: 3
» Views: 265
put small ASM programs li...
Forum: How-To & Tutorials
Last Post: Zoran
04-18-2025, 02:02 PM
» Replies: 6
» Views: 1,529
Creating +3 Menus - Loadi...
Forum: Help & Support
Last Post: merlinkv
04-16-2025, 02:08 PM
» Replies: 6
» Views: 522
Randomize not very random...
Forum: Help & Support
Last Post: Zoran
04-08-2025, 10:40 AM
» Replies: 4
» Views: 422
Scope rules
Forum: Bug Reports
Last Post: Zoran
04-04-2025, 09:46 AM
» Replies: 2
» Views: 292
Using constants not allow...
Forum: Bug Reports
Last Post: baltasarq
03-19-2025, 10:00 PM
» Replies: 8
» Views: 1,021
404 page not found
Forum: Documentation
Last Post: boriel
03-08-2025, 07:16 PM
» Replies: 5
» Views: 2,857
Spectrum keywords codes
Forum: Bug Reports
Last Post: boriel
03-08-2025, 11:00 AM
» Replies: 1
» Views: 400
ZXodus][Engine
Forum: ZX Basic Compiler
Last Post: boriel
02-19-2025, 11:43 PM
» Replies: 69
» Views: 213,510

 
  concatenation of a str and a str function result (*solved*)
Posted by: programandala.net - 04-17-2010, 07:45 PM - Forum: Bug Reports - Replies (13)

I cannot understand the reason of some errors I'm getting about converting a string into a value and a value into a string.

In order to debug, I wrote a simplified version of the code:

Code:
dim a as ubyte

let a = 10
print "Yes: "+stringIF(a,"yes")+"..." ' ERROR: Cannot convert string to a value. Use VAL() function
print "Nothing: "+stringIF(0,"yes")+"..."
stop

function stringIf(condition as uinteger,text as string) as string

    if condition then
        return text
    else
        return ""
    end if

end function

stringIf is a simple alternative to the Sinclair Basic use of AND with strings:

Code:
LET A$ = "string" AND condition

So I can port it this way:

Code:
let aString = stringIf(condition,"string")

I don't understand why the following line fails:

Code:
print "Yes: "+stringIF(a,"yes")+"..." ' ERROR: Cannot convert string to a value. Use VAL() function

I tried an alternative, but nothing changed:

Code:
dim a as ubyte
dim t as string

let a = 10
let t = "Yes: "+stringIF(a,"yes")+"..." ' ERROR: Cannot convert string to a value. Use VAL() function
let t = "Nothing: "+stringIF(0,"yes")+"..."
stop

Beside those simple tests, I did several tries in the original code, and noted "FINE" or "ERROR" (all variables are DIMed as ubyte):

Code:
    #define true 1

    tell("Son las "+str(currentHour)+stringIf(currentMinute<>0,":"+stringIf(currentMinute<10,"0")+str(currentMinute))+" de la noche.") ' ERROR : Cannot convert string to a value. Use VAL() function
    print "Son las "+str(currentHour)+stringIf(currentMinute<>0,":"+stringIf(currentMinute<10,"0")+str(currentMinute))+" de la noche.") ' ERROR : Cannot convert string to a value. Use VAL() function
    print "Son las "+str(currentHour) ' FINE
    print "Son las "+str(currentHour)+str(currentMinute)+" de la noche." ' FINE
    print "Son las "+stringIf(currentMinute<>0,":") ' ERROR: Cannot convert string to a value. Use VAL() function
    print "Son las "+stringIf(true,":") ' ERROR: Cannot convert string to a value. Use VAL() function
    print stringIf(true,":") ' FINE

One of the tries caused both errors at the same time (string into value and vice versa!):

Code:
    #define true 1
    dim temp as string
    ' the following line gets two errors:
    ' Cannot convert value to string. Use STR() function
    ' Cannot convert string to a value. Use VAL() function
    let temp = "Son las "+stringIf(true,":")
    print temp

The stringIf function is defined to return a string, so I cannot understand what's the problem.

I tried another thing... Maybe it has to do with concatenation... Let's see:

Code:
print "Yes: ";stringIf(a,"yes");"..." ' FINE

it compiles! So the problem has something to do with string concatenation.

I'm stuck. I need some enlightenment.

Print this item

  A help forum
Posted by: programandala.net - 04-17-2010, 07:16 PM - Forum: Wishlist - Replies (2)

Boriel,
I miss a fourth forum for asking for help. I'm working on my second port from Sinclair Basic to ZX Basic, and sometimes I need some help about some issue that it's not in the docs, and I cannot find it in the sources. Meanwhile, I'll keep on using the bugs forum.
What do you think?

Print this item

  error line numbers affected by #if(n)def
Posted by: programandala.net - 04-16-2010, 07:21 PM - Forum: Bug Reports - No Replies

I realized the line numbers shown in the error reports don't include the lines discarded by #ifdef and #ifndef. I mean, the lines of the source discarded by #ifdef and #ifndef are not counted.
I guess the compiler discards those parts before doing the next pass, but the annoyng effect is the lines of errors and warnings are not real.
This is a problem, mainly with long programs where conditional compilation is used a lot.

Print this item

  const as string?
Posted by: programandala.net - 04-16-2010, 06:29 PM - Forum: Bug Reports - Replies (6)

I got the following error with both 1.2.5 and 1.2.6:

"Initializer expression is not constant"

The line is:

const prompt as string = chr(18,1,62,18,0,8)

I supossed the reason is the chr() calculation, so I put a literal string instead:

const prompt as string = "my prompt"

but nothing changed, the error remains.

The wiki page on CONST is not written, so I searched for CONST in the sources for examples. I searched all the sources for a "const as string" example (using a regular expression), but found nothing.

Are constant strings forbidden?

Print this item

  String Issues
Posted by: britlion - 04-16-2010, 05:15 AM - Forum: Bug Reports - Replies (3)

I'm having a weird issue. I have the following code setting a string:

Code:
IF currentMatchType=FACUP then let faCupMatchCountString="Round "+STR$(faCupMatchCount)
   IF faCupMatchCount=7 Then let faCupMatchCountString="Semi-Final"
   ELSEIF faCupMatchCount=8 Then let faCupMatchCountString="Final"
   END IF

Later on it prints that string. On a 1-6 it prints "Round 1" / "Round 2" and so on. As soon as the FaCupMatchCount hits 7 it prints gibberish and/or crashes...


Is there a potential issue in the string handling, or have I written more notoriously bad code?

The thing is, it works for the earlier numbers...
(yes, I can provide the whole program again if you wish... It's sometimes difficult to tell if I've done something amiss, or the compiler has - we've had array bounds checking issues already!)

If I change the code so both Ifs say "8" then it prints "Round 7" as expected, and then prints gibberish instead of "Final"

Here's the code that actually prints it at the point that it fails:
Code:
if currentMatchType=FACUP then print "F.A.Cup Match - ";faCupMatchCountString
    else PRINT "League Match - ";
       IF division=4 then print "League 2"
          elseif division=3 then print "League 1"
          elseif division=2 then print "Championship"
          else print "Premier League"
       END IF
    END IF

It prints "F.A. Cup Match - " and then gibberish on the screen.

Print this item

  for-next repeats forever because of data type limit
Posted by: programandala.net - 04-09-2010, 01:15 AM - Forum: Bug Reports - Replies (4)

Hi all,

I'm working on my first port from Sinclair Basic to ZX Basic. I'm excited about it. I'd love to program compiled versions of some old programs of mine, but first I need to acquaint with this wonderful and impressive tool.

I'm using ZX Basic 1.2.0 under Debian GNU/Linux.

Well, I think I found a kind of bug. Here you are the test:

Code:
' The following loop works as expected:

dim b0 as ubyte

for b0=0 TO 254
    print at 0,0;"b0=";b0;"    "
next b0

' The following loop works as expected too:

dim b1 as uinteger

for b1=0 TO 255
    print at 1,0;"b1=";b1;"    "
next b1

' But the following loop starts again forever:

dim b2 as ubyte

for b2=0 TO 255
    print at 2,0;"b2=";b2;"    "
next b2

border 4
print "This message never will be printed"
pause 0

I found the problem because I needed a loop from 0 to 255, so I used the ubyte data type for the index variable. Then I realized the loop repeated forever!

I guess the reason is NEXT increases the loop index before cheking it, so 256 becomes 0 after storing it back into the ubyte variable and the check gets wrong: the loop starts again because the index is zero! I guess the same happens with other data types, as long as their limits are reached, but I didn't try.

Do you think this is a language feature or a compiler bug? Smile

I'm programming a project in FreeBASIC too, but I didn't try this. I'll try a similar code and I'll see what happens.

Print this item

  ZXBasic 1.2.6-r1542
Posted by: boriel - 04-05-2010, 11:07 PM - Forum: Bug Reports - Replies (5)

Okay. This release is already available for download, and fixes a -O3 bug (another one). The most common effect is some optimizations NOT being done.
Please, download and test: <!-- m --><a class="postlink" href="http://www.boriel.com/files/zxb/zxbasic-1.2.6r1542.msi">http://www.boriel.com/files/zxb/zxbasic-1.2.6r1542.msi</a><!-- m -->

Print this item

  Internal Types
Posted by: britlion - 03-31-2010, 07:54 AM - Forum: Bug Reports - Replies (3)

This issues a warning: "Test.bas:22: warning: Redundant operation ABS for unsigned value"

Surely if a Byte is signed, then (Byte-Byte) is signed as well?

Is this an internal issue, or is it me doing something wrong, and I should be casting, here?

(I know poking the routine with fspDataStart is a bad idea - I needed label to be able to make this compile on its own to demonstrate the query - I'm not really writing horrifically wrong self-modifying code!)

Code:
fspDataStart:
SUB fspCollisionCheck()
    dim sprite as uInteger
    dim xCoords(3) as Byte
    dim yCoords(3) as Byte
    dim i,j as uByte
    
    let sprite=@fspDataStart
    for i=0 to 3
     if (PEEK sprite) mod 2 =1 then:
      let xCoords(i)=PEEK (sprite+2)
      let yCoords(i)=PEEK (sprite+2)
      poke sprite,1
     end if
     let sprite=sprite+43
    next i
    
    let sprite=@fspDataStart
    
    for i=0 to 2
     for j=i+1 to 3
       if ABS (xCoords(i)-xCoords(j)) < 2 AND ABS (yCoords(i)<yCoords(j)) <2 THEN poke (sprite+43*i), PEEK (sprite+43*i) + ((1 SHL i) SHL (j-i)) : END IF
     next j
    next i
END SUB
Print this item

  Version 1.2.5 released!
Posted by: boriel - 03-26-2010, 07:07 PM - Forum: ZX Basic Compiler - No Replies

Ok, this release is just 1.2.5-r1513h renamed. I think it's quite stable now, and if new bugs are found, they will be fixed on 1.2.6.
So, those interested, please, download from: <!-- m --><a class="postlink" href="http://www.boriel.com/files/zxb">http://www.boriel.com/files/zxb</a><!-- m -->

Thanks to Britlion, apenao, LCD & carloscomputer. They've detected more than 30 bugs. In fact this version fixes so many that some parts has been completely rewritten. If you use any older version, do please upgrade to this one immediately. This version could be considered as a "Service Pack Update".

Changes since v.1.2.4
===================================

  • Assembler:
    • ! Under some pathological cases, compiling or assembling will last for exponential time (minutes to hours!), due to a possible bug/misuse of a regular expression. Fixed. Now it takes linear time.
    • + Added support for IXh, IXl, IYh, IYl registers.
    • + Added support for DEFS macro. Now DEFS n, B creates a block of n times byte B
    • ! Instructions LD A, R and LD R, A where also missing. Fixed.
  • Compiler
    • ! The optimizer -O2 was broken, and contained 3 bugs. Fixed.
    • ! The optimizer -O3 was broken, and contained more than 15 bugs. It's been almost completely rewritten. Fixed. Now it even tries to optimize ASM users code. :!:
    • ! The @operator was broken under some circumstances (array accesses and variables). Fixed.
    • ! The memory heap was also broken almost always when using any string in the program (INKEY$, STR$, CHR$, $ variables). Fixed.
    • ! Signed LONG division was wrong for positive divisors. Fixed.
    • ! Byte comparison operators < > = >= <= were sometimes bugged. Fixed.
    • ! using MOD with Fixed type was unsupported. Fixed. Now MOD used Fixed type.
    • ! INT(Fixed) was wrong. Fixed.
    • ! Temporary attributes BOLD and ITALIC were disabled. Now they are back.

    Probably some more other fixed, but these are the most important. :wink:

Print this item

  "Son of" Incorrect Line numbers
Posted by: britlion - 03-23-2010, 07:59 AM - Forum: Bug Reports - No Replies

There *is* in fact a line number bug. It's in the inline assembly.

Code:
asm
;THIS IS A COMMENT
;THIS IS A COMMENT
;THIS IS A COMMENT
;THIS IS A COMMENT
;THIS IS A COMMENT
;THIS IS A COMMENT
;THIS IS A COMMENT
;THIS IS A COMMENT
;THIS IS A COMMENT
;THIS IS A COMMENT
;THIS IS A COMMENT
;THIS IS A COMMENT
;THIS IS A COMMENT
;THIS IS A COMMENT
;THIS IS A COMMENT
;THIS IS A COMMENT
;THIS IS A COMMENT
LD F,F
end asm

If you try to compile that, you'll be pointed at line 1 for errors, when in fact it's in line 19.

Over a reasonably large program, with includes and lots of documentation, the place you can be told "Unexpected Token" can be a very very long way away from the real number. Apparently comments aren't counted as lines for that error - I'm guessing they are pre-parsed out by that point.

Sorry if this isn't going to be trivial to solve!

Print this item