Latest Steam Update Broke My Project

Previous topic - Next topic

bigsofty

Looks like the test modifications, that should have been removed, that I tested a few weeks ago (see my posts regarding the removing ".self" compiler modification in Steam beta) have now made there way in the the the actual newly updated Steam version of GLB!?!? See... https://www.glbasic.com/forum/index.php?topic=11453.msg101179#msg101179 post.

I now simply cant compile my code. I tried to modify around this error but my project is over 150 thousand lines of code, spread across 129 files... and gave up after an hour.

Obviously this was compiling fine before the update last week.

"gui.gbas"(1685) error : GPC0007 wrong argument type

Code (glbasic) Select
FUNCTION GetWidgetID%: name$
IF name$="" THEN RETURN -1
LOCAL i%, w AS TWidget
FOREACH w IN self.w[]
IF name$=w.text$[WB_NAME_STRING] THEN RETURN i%
INC i%
NEXT
RETURN -1
ENDFUNCTION


Its the same piece of code that was tested here(https://www.glbasic.com/forum/index.php?topic=11453.msg101179#msg101179) after the test modification was made to the Steam beta compiler which has made its way into the release build. This was supposed to be dropped for causing these errors a few weeks ago. Unfortunately, this is only the first of a lot of of compiler errors now in my code.

Cheers,

Ian.

"It is practically impossible to teach good programming style to students that have had prior exposure to BASIC.  As potential programmers, they are mentally mutilated beyond hope of regeneration."
(E. W. Dijkstra)

SnooPI

Damn, bad news  :(
I admit that for the moment I still only use the old version, so I don't have this kind of problem.

It seems that there are quite a few issues with the Steam version, I hope Gernot can fix them (I would like to help him but I don't know how).

Good luck Bigsofty  :|

Kitty Hello

#2
Quote from: bigsofty on 2021-Mar-16
Code (glbasic) Select
FUNCTION GetWidgetID%: name$
LOCAL i%, w AS TWidget
FOREACH w IN self.w[]
NEXT


Both, the compiler and you happen to be right. The error message is quite bad, though.
You declare a variable 'w' of type TWidget, which shadows the variable self.w[] of type DGArray<TWidget>. Remove the 'LOCAL w AS TWidget', please.

I fixed this bug in the compiler, but I hope I'm not adding other bugs with this. I'll add it to the beta as an update, soon.

bigsofty

#3
Thank you SnooPI and thank you Gernot, your support is really appreciated.  :booze:

Now, thew, bare with me please! :) Just be be clear, this is a new bug in the compiler that was introduced when an attempt was made by you Gernot to change the behaviour in the compiler of when dealing with ".self" a couple of weeks back. My code I am showing here is years old and has worked fine up until Sunday when I downloaded the latest Steam release patch.

Also I will do as you ask and modify my code around this error(we already did this in the previous thread) but, please be patient with me, I am a little unclear why? This is only something that was introduced after a failed attempt to add functionality to the compiler, wouldn't it be easier to simply roll back this part of the compiler code to where it was working fine? No functionality would be lost. This should affect Shoebox for example.

The reason the I would declare(not so much in this sub) the iterator variable, for use in a FOREACH block is because of scope. Logically the declaring the variable as a LOCAL(or even on a global) outside of FOREACH block means that it will be used somewhere in else within the function. If I had use an IF/THEN/BREAK within the FOREACH then I would not want scope errors when trying to access "w" outside the FOREACH block, in this case. This used to work fine, so there is actually a loss of functionality when working around this bug.

Again, to reiterate, this is not a new compiler bug, it's one that's been introduced with the previous beta and with no added functionality to the compiler, simply rolling back the code pre ".self" modification hopefully this shouldn't add any bugs as it was a new bug introduced to old compiler code only a couple of weeks back.






EDIT:

I did the modifications as asked and now this is not working...

"material.gbas"(82) error : GPC0007 wrong argument type

Code (glbasic) Select

FOREACH m IN self.m[] // <------------------- THIS IS LINE 82
m.combined% = ASL((m.alpha#)*255,24)+ASL(m.blue#*255,16)+ASL(m.green#*255,8) + m.red#*255
NEXT


I'm feeling a little dejavu here ;) These are the same modifications you asked me to make to the same code when the bug was introduced in the last beta(see here a couple of weeks ago... https://www.glbasic.com/forum/index.php?topic=11453.msg101179#msg101179 )

Here is the full type by the way(which again, was years old working code)...

Code (glbasic) Select
TYPE TMaterials

filename$
totalMaterials%
m[] AS TMaterial

FUNCTION SetUp:
DIM self.m[0]
self.Update()
ENDFUNCTION

FUNCTION Update:
self.totalMaterials%=LEN(self.m[])
ENDFUNCTION

FUNCTION Render:
ENDFUNCTION

FUNCTION Destroy:
DIM self.m[0]
self.Update()
ENDFUNCTION

FUNCTION ReadFile: filename$
LOCAL f%,l$
LOCAL n%,t$[]
LOCAL i%
LOCAL m AS TMaterial
self.Destroy()
self.SetUp()
f%=GENFILE()
OPENFILE(f%, filename$, TRUE)
//DEBUG "Start read TMaterials.ReadFile("+filename$+") file >\n"
REPEAT
READLINE f%, l$
n%=SPLITSTR(l$,t$[]," ")
IF LEN(t$[])=0 THEN CONTINUE
SELECT t$[0]
CASE "newmtl"
DIMPUSH self.m[], m
self.m[-1].name$=t$[1]
CASE "Kd"
self.m[-1].red# = t$[1]; self.m[-1].green# = t$[2]; self.m[-1].blue# = t$[3]
CASE "Tr"
self.m[-1].alpha# = t$[1]
CASE "Ns"
self.m[-1].size# = t$[1]
CASE "#"
DEFAULT
ENDSELECT
UNTIL ENDOFFILE(f%)

FOREACH m IN self.m[] // <------------------- THIS IS LINE 82
m.combined% = ASL((m.alpha#)*255,24)+ASL(m.blue#*255,16)+ASL(m.green#*255,8) + m.red#*255
NEXT
//DEBUG "< End read material file\n"

CLOSEFILE f%
ENDFUNCTION

FUNCTION GetMaterialIndex%: findname$
LOCAL matIndex%=0
FOREACH mat IN self.m[]
IF mat.name$ = findname$ THEN BREAK
INC matIndex%
NEXT
IF matIndex%=LEN(self.m[])
myDEBUG ( "Error in GetMaterialIndex(): Material '"+findname$+"', not found!\n" )
END
RETURN -1
ENDIF
RETURN matIndex%
ENDFUNCTION

ENDTYPE


TYPE TMaterial
name$
red#
blue#
green#
alpha# = 1.0
combined% = 0xffffffff
size# = 32
ENDTYPE
Cheers,

Ian.

"It is practically impossible to teach good programming style to students that have had prior exposure to BASIC.  As potential programmers, they are mentally mutilated beyond hope of regeneration."
(E. W. Dijkstra)

Kitty Hello

GPC - GLBasic Precompiler V.17.312
Your code compiled fine, here.

bigsofty

#5
 The Steam version (not beta) is GLBasic Precompiler V.17.200, this is the current Steam Release version, that was updated at the weekend to  V.17.200.

... I just downloaded the beta which is GLBasic Precompiler V.17.312. I am now getting a new error.

"protoList.gbas"(73) error : GPC0007 wrong argument type :

Code (glbasic) Select
FUNCTION SET_F: F[] AS TGOProto
self.F = F // <------------ This is line 73
ENDFUNCTION // Full array swap


F[] is just an array within a type.

I must stress that I haven't used this Beta, the last one I used was a couple of weeks ago and I was getting some errors then. I will mirror what you have done Gernot and do a separate compile on the previous code to see if that piece of is now compiling on the new beta.
Cheers,

Ian.

"It is practically impossible to teach good programming style to students that have had prior exposure to BASIC.  As potential programmers, they are mentally mutilated beyond hope of regeneration."
(E. W. Dijkstra)

bigsofty

#6
I just tried the code I posted(The full TMaterials type in Reply #3 above) on the beta GLBasic Precompiler V.17.312 and it compiles, which is great!  That very reassuring TBH. =D

I haven't executed it as its pretty out of context but the Precompiler usually does an excellent runtime error prevention I'm sure it will be fine.

Seems "self.F" above is still causing further errors though.





EDIT:

Here is the modified type showing the ".self=" error...

See... "FUNCTION AddBuggedFunc:"

Code (glbasic) Select
TYPE TMaterials

filename$
totalMaterials%
m[] AS TMaterial

FUNCTION SetUp:
DIM self.m[0]
self.Update()
ENDFUNCTION

FUNCTION Update:
self.totalMaterials%=LEN(self.m[])
ENDFUNCTION

FUNCTION Render:
ENDFUNCTION

FUNCTION Destroy:
DIM self.m[0]
self.Update()
ENDFUNCTION

FUNCTION ReadFile: filename$
LOCAL f%,l$
LOCAL n%,t$[]
LOCAL i%
LOCAL m AS TMaterial
self.Destroy()
self.SetUp()
f%=GENFILE()
OPENFILE(f%, filename$, TRUE)
//DEBUG "Start read TMaterials.ReadFile("+filename$+") file >\n"
REPEAT
READLINE f%, l$
n%=SPLITSTR(l$,t$[]," ")
IF LEN(t$[])=0 THEN CONTINUE
SELECT t$[0]
CASE "newmtl"
DIMPUSH self.m[], m
self.m[-1].name$=t$[1]
CASE "Kd"
self.m[-1].red# = t$[1]; self.m[-1].green# = t$[2]; self.m[-1].blue# = t$[3]
CASE "Tr"
self.m[-1].alpha# = t$[1]
CASE "Ns"
self.m[-1].size# = t$[1]
CASE "#"
DEFAULT
ENDSELECT
UNTIL ENDOFFILE(f%)

FOREACH m IN self.m[] // <------------------- THIS IS LINE 82
m.combined% = ASL((m.alpha#)*255,24)+ASL(m.blue#*255,16)+ASL(m.green#*255,8) + m.red#*255
NEXT
//DEBUG "< End read material file\n"

CLOSEFILE f%
ENDFUNCTION

FUNCTION GetMaterialIndex%: findname$
LOCAL matIndex%=0
FOREACH mat IN self.m[]
IF mat.name$ = findname$ THEN BREAK
INC matIndex%
NEXT
IF matIndex%=LEN(self.m[])
// myDEBUG ( "Error in GetMaterialIndex(): Material '"+findname$+"', not found!\n" )
END
RETURN -1
ENDIF
RETURN matIndex%
ENDFUNCTION

//*************************************** ERROR ************************************

FUNCTION AddBuggedFunc: matArray[] AS TMaterial
self.m[] = matArray
ENDFUNCTION

//***********************************************************************************

ENDTYPE


TYPE TMaterial
name$
red#
blue#
green#
alpha# = 1.0
combined% = 0xffffffff
size# = 32
text$[]
ENDTYPE

Cheers,

Ian.

"It is practically impossible to teach good programming style to students that have had prior exposure to BASIC.  As potential programmers, they are mentally mutilated beyond hope of regeneration."
(E. W. Dijkstra)

Kitty Hello

For a quick fix, please write (old style) self.m[] = matArray[] // <-- the final braces are the problem. Don't omit so far.

bigsofty

That's the last error message squashed well done Gernot!  :enc:

As you can tell this is quite a relief, I've a very large project and I was was trying to keep proper working hours with it. So each day missed was a days work lost. But all's good now, I can jump back in.  :good:

One thing I noticed here though, is that maybe I should take more of an active roll in beta updates. If there is any beta updates posted in the future, drop me a message please and I'll happily run it through my behemoth of a project to test the compiler and also provide some feedback.
Cheers,

Ian.

"It is practically impossible to teach good programming style to students that have had prior exposure to BASIC.  As potential programmers, they are mentally mutilated beyond hope of regeneration."
(E. W. Dijkstra)