BaCon 3.0.2 (Beta) Bugs

[alexfish]

Hi Peter

getting problem with latest BaCon beta(gui)
bacon not tested.

shows in hug_elm.bac
SUB INIT
CONST mouse=0
CONST HUG_FALSE = 0
CONST HUG_TRUE = 1
GLOBAL HUG_WINDOW_TYPE = 0
GLOBAL hug_value_double TYPE double
GLOBAL HUG_WIDGET_SHOW = 1
GLOBAL hug_id = 0
GLOBAL LAST_CANVAS=0
GLOBAL hug_canvas = 0
DECLARE hug_widget_text$ ASSOC STRING
DECLARE hug_evas_widget ASSOC NUMBER
GLOBAL *HugMain TYPE Widget
LOCAL argc TYPE int


DECLARE WIDGET
REM Global properties of the HUG GUI

GLOBAL RECORD hug_gui_properties
LOCAL last_key_pressed, timeout_id, canvas, freeze, canvasid
LOCAL mousex, mousey, scroll, button TYPE int
LOCAL options$, gl$, clip$ TYPE STRING
END RECORD

hug_gui_properties.gl$ = "NONE"
hug_gui_properties.scroll = -1
hug_gui_properties.button = -1
hug_gui_properties.mousex = -1
hug_gui_properties.mousey = -1
hug_gui_properties.canvasid = 0
hug_gui_properties.clip$ = "CLIPBOARD"

GLOBAL RECORD properties[255]
LOCAL xsize, ysize TYPE int :'Size of the widget
LOCAL signal TYPE int :'What signal we listen to
LOCAL *sig_widget TYPE Widget :'Which widget listens to the signal
LOCAL caption$ TYPE STRING :'Text in the widget
LOCAL type$ TYPE STRING :'Widget type
LOCAL *attach TYPE Widget :'What widget children can attach to
LOCAL *layer TYPE Widget
LOCAL group TYPE int
LOCAL other$ TYPE STRING
LOCAL selected_text$ TYPE STRING
LOCAL mode TYPE int
LOCAL start TYPE double
LOCAL end TYPE double
LOCAL step TYPE double
LOCAL *sig_timer TYPE Ecore_Timer
LOCAL *menu_item TYPE Elm_Object_Item
LOCAL class TYPE int
END RECORD

GLOBAL RECORD  evas[2000]
LOCAL xsize, ysize ,height , width TYPE int
LOCAL *canvas TYPE Evas
LOCAL *sig_widget TYPE Widget
LOCAL caption$ TYPE STRING
LOCAL type$ TYPE STRING
LOCAL r , g , b , a TYPE int
LOCAL signal TYPE int
LOCAL class TYPE int
END RECORD
' define mouse properties
properties[0].type$="mouse"
properties[0].signal=20
IF elm_init(0,0) THEN
PRINT "elm init"

ELSE
PRINT "elm_init fail : check dev libs"
END
END IF

END SUB

Error indicates duplication in GLOBAL RECORD evas
LOCAL *sig_widget TYPE Widget

there be also a one in GLOBAL RECORD properties

have not tested any other forms of RECORD

BR
Alex

[Pjot]

Hi Alex,

Even without testing I can see you are right. The LOCAL statement registers the variable name internally, and only takes into account if the variable was declared within a FUNCTION or not.

The functionality to also notice a current RECORD name, was something I had put on the "TODO" list, when redesigning BaCon towards 3.0.

And since nobody came up with complaints yet, and as there were so many other issues popping up, I never looked at it again, until now.

So as a temporary workaround, please use different variable names. This issue will be fixed in 3.0.2.

Best regards
Peter

[Pjot]

Hi Alex,

It took some time, but the fix for this problem is ready and can be obtained from the beta directory.

The below program demonstrates that record members and regular variables with the same name now will not cause a conflict.

Regards
Peter


DECLARE x
DECLARE y$

RECORD one
LOCAL x
LOCAL y$
END RECORD

RECORD two
LOCAL x
LOCAL y$
END RECORD

x = 10
PRINT x

one.x = 5
PRINT one.x

two.x = 6
PRINT two.x

one.y$ = "Hello"
two.y$ = "World"
y$ = "Cruel"

PRINT one.y$, y$, two.y$


[vovchik]

Dear Peter,

Thanks for the new beta. I have encountered a little problem using this function:


INCLUDE "hug.bac"
INIT

IMPORT "gdk_pixbuf_loader_new()" FROM HUGLIB$("gdk") TYPE long
IMPORT "gdk_pixbuf_loader_write(long,unsigned char*, long int, int)" FROM HUGLIB$("gdk") TYPE int
IMPORT "gdk_pixbuf_loader_close(long,int)" FROM HUGLIB$("gdk") TYPE int
IMPORT "gdk_pixbuf_loader_get_pixbuf(long)" FROM HUGLIB$("gdk") TYPE long

' ------------------
FUNCTION SVG_BUFF(STRING svg$)
' ------------------
LOCAL pixloader, pixbuf TYPE long
LOCAL size, k, res TYPE int
size = LEN(svg$)
LOCAL raw_array TYPE unsigned char ARRAY size
FOR k = 0 TO size - 1
raw_array[k] = ASC(MID$(svg$, k + 1, 1))
NEXT k
pixloader = gdk_pixbuf_loader_new()
res = gdk_pixbuf_loader_write(pixloader, raw_array, size, 0)
res = gdk_pixbuf_loader_close(pixloader, 0)
pixbuf = gdk_pixbuf_loader_get_pixbuf(pixloader)
RETURN pixbuf
END FUNCTION


The error I get is the following:


In file included from 3dcube-gtk3.bac.h:3996:0,
                from 3dcube-gtk3.bac.c:2:
3dcube-gtk3.SVG_BUFF.h: In function 'SVG_BUFF':
3dcube-gtk3.SVG_BUFF.h:25:14: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
raw_array[k]=(unsigned char*)ASC(MID__b2c__string_var(svg__b2c__string_var, k + 1, 1));
             ^
3dcube-gtk3.SVG_BUFF.h:25:13: warning: assignment makes integer from pointer without a cast [enabled by default]
raw_array[k]=(unsigned char*)ASC(MID__b2c__string_var(svg__b2c__string_var, k + 1, 1));


Any ideas why?

With kind regards,
vovchik

[Pjot]

Thanks Bogdan,

The array 'raw_array' is declared as a dynamic array. As you may see from the CHANGES file:

static arrays should not be registered as pointer type

But this also should be applied to dynamic arrays, of course ...my bad, I will fix it tonight.

Thx
Peter

[Pjot]

Bogdan,

Your problem should be fixed in the latest beta.

Please let me know if you run into other issues.

BR
Peter

[vovchik]

Dear Peter,

I tested the dynamic array bit and all is now OK. Many thanks...

With kind regards,
vovchik

[bitvast]

There seems to be a problem with PULL and floats:


PUSH 19.37
PUSH "string"
PUSH 54

PULL num1%
PRINT num1%

PULL str$
PRINT str$

PULL num2#
PRINT num2#
54
string
0

also:-

num# = 19.37

PUSH num#
PULL num#
PRINT num#

19

[Pjot]

Thanks bitvast,

This problem does not occur in the Shell version of BaCon, but it occurs in the binary versions. It is fixed in the latest beta.

Regards
Peter

[bitvast]

In the manual in the section on "Returning arrays from functions", the demo program gives an error:


FUNCTION demo
   LOCAL array TYPE int ARRAY 10 STATIC
   FOR x = 0 TO 9
       array[x] = x
   NEXT
   RETURN array
END FUNCTION
DECLARE my_array TYPE int ARRAY 10
my_array = demo()


In file included from baconshell.bac.h:15:0,
from baconshell.bac.c:2:
baconshell.demo.h: In function 'demo':
baconshell.demo.h:17:1: warning: return makes integer from pointer without a cast [enabled by default]
return (array);
^
baconshell.bac.c: In function 'main':
baconshell.bac.c:66:10: warning: assignment makes pointer from integer without a cast [enabled by default]
my_array = demo();
^

[basica]

Oct 6, 2014 18:58:47 GMT 1 bitvast said:

In the manual in the section on "Returning arrays from functions", the demo program gives an error:


FUNCTION demo
   LOCAL array TYPE int ARRAY 10 STATIC
   FOR x = 0 TO 9
       array[x] = x
   NEXT
   RETURN array
END FUNCTION
DECLARE my_array TYPE int ARRAY 10
my_array = demo()


bitvast,

Strange, I just tried it PRINT my_array[9]
9 and it worked. This is Bacon 3.0.1
EDIT: I just realized this is the new beta - maybe useful to know it worked before....)

Regards,
basica
(You are doing a great job on the manual - nice style -easy to follow - very inviting)

[Pjot]

Thanks bitvast,

Good catch! This typically is an error which occurs in the beta release. Should not happen in 3.0.1.

The reason for this is the explicit casting in expressions. The type of arrays is registered as the original type without pointer indication.

However, in case of a RETURN, which relies on the variable type registration, we need the pointer indication also.

I will improve 3.0.2 beta further and fix this issue.

BR
Peter

[bitvast]

Oct 6, 2014 21:00:47 GMT 1 basica said:

(You are doing a great job on the manual - nice style -easy to follow - very inviting)

Thanks basica, glad you like it.

[Pjot]

Hi bitvast,

The issue with returning dynamic arrays from functions was repaired in the latest version of beta 3.0.2.

BR
Peter

[vovchik]

Dear Peter,

Thanks for the fix. The error has disappeared.

With kind regards,
vovchik