BaCon 3.0.1 Bugs

[alexfish]

Hi Peter

Latest Beta :: the %* not Printing

Example


%numb=12334
PRINT %n


This will work


%numb=12334
PRINT (int)%n
PRINT (double)%n



BR
Alex

[Pjot]

Hi Alex,

Your use of the '%' symbol is wrong, it is a suffix so it should be put behind the variable name.

numb% = 12334
PRINT numb%


HTH
Peter

[alexfish]

Thanks Peter

Thought had read somewhere %* , it be incidental that one worked in previous beta.

so looks like a bug fix as well.

BR
Alex

[alexfish]

Hi Peter

got a problem with NULL

SUB TEST_NULL(int null)


END SUB


TEST_NULL(TRUE)
TEST_NULL(NULL)

can also check this


GLOBAL hug_file_selected$ = "test 1" TYPE STRING
GLOBAL hug_file = "test 2" TYPE STRING

SUB TEST_STRINGS_1()
PRINT hug_file_selected$
PRINT "------------------"
PRINT ""
'@ this is not recognized
PRINT hug_file
END SUB

SUB CALLBACK_TEST_STRINGS_2(void *data)
LOCAL file TYPE char*
LOCAL file2 TYPE STRING

file=data
file2=file
PRINT "file path 'file' : ",file
PRINT "file path 'file2' : ",file
'@ this will crash
hug_file_selected$=file
PRINT "file path 'hug_file_selected$': " , hug_file_selected$
END SUB

TEST_STRINGS_1
CALLBACK_TEST_STRINGS_2("/home/user")


Looks like in the real app the crash happens on the PRINT statement
IE PRINT "file path 'hug_file_selected$': " , hug_file_selected$

in the have fixed by changing the data in the callback to 'void* data'
so may find this one useful , this is my code

SUB FILE_CHOSEN(void *data,Evas_Object *obj,void* event_info)
PRINT "pick"
LOCAL file TYPE char*
file = event_info

PROTO printf
IF (file) THEN

hug_file_selected$=file
PRINT hug_file_selected$
printf("File chosen: %s\n", file)
ELSE

hug_file_selected$="none"
END IF

END SUB

BR
Alex

[Pjot]

got a problem with NULL

I think the NULL program works as expected - you get a compile error when passing NULL (in C used for pointers) to an 'int' type:

Cause: passing argument 1 of 'TEST_NULL' makes integer from pointer without a cast [enabled by default]

So this is normal. The line would work if you change it as follows:

SUB TEST_NULL(int* null)

END SUB

But now the first line passing TRUE will fail. But this is normal C behavior.

For your second program, note that the variable 'hug_file' is considered to be a pointer to a string, because you have omitted the '$' sign at the end of the variable name. Therefore, BaCon does not know the type of value you're pointing to, and PRINT needs a specification with FORMAT:

PRINT hug_file FORMAT "%s\n"

The crash in the second SUB is more peculiar. The reason is that you perform a declaration and assignment in the same line for the variable 'hug_file_selected$'. That means you are already hardcoding a pointer to some memory where the characters "test 1" are stored. Therefore, you cannot change that pointer at a later stage.

If you want to do such a thing, it must be done as follows (complete working program):

GLOBAL hug_file_selected$ TYPE STRING
GLOBAL hug_file = "test 2" TYPE STRING

SUB TEST_STRINGS_1()

PRINT hug_file_selected$
PRINT "------------------"
PRINT ""
PRINT hug_file FORMAT "%s\n"

END SUB

SUB CALLBACK_TEST_STRINGS_2(void *data)

LOCAL file TYPE char*
LOCAL file2 TYPE STRING

file=data
file2=file

PRINT "file path 'file' : ",file
PRINT "file path 'file2' : ",file

hug_file_selected$=file
PRINT "file path 'hug_file_selected$': " , hug_file_selected$

END SUB

hug_file_selected$ = "test 1"

TEST_STRINGS_1
CALLBACK_TEST_STRINGS_2("/home/user")


HTH
Peter

[alexfish]

If you want to do such a thing, it must be done as follows (complete working program):

Thought would test the bits with pointer , changed it to function


GLOBAL hug_file_selected$ TYPE STRING
GLOBAL hug_file = "test 2" TYPE STRING

SUB TEST_STRINGS_1()

PRINT hug_file_selected$
PRINT "------------------"
PRINT ""
PRINT hug_file FORMAT "%s\n"

END SUB

FUNCTION CALLBACK_TEST_STRINGS_2(void *data)

LOCAL file TYPE char*
LOCAL file2 TYPE STRING

PRINT "file path 'file' : ",file
PRINT "file path 'file2' : ",file

hug_file_selected$=file
PRINT "file path 'hug_file_selected$': " , hug_file_selected$

data= 1
RETURN data

END FUNCTION

hug_file_selected$ = "test 1"

TEST_STRINGS_1
CALLBACK_TEST_STRINGS_2("/home/user")

'@ now see if can pointer with no err

PASS_NUM = 500

a = CALLBACK_TEST_STRINGS_2(&PASS_NUM)

IF a THEN

PRINT " :PASS_NUM --> " , PASS_NUM

ELSE
PRINT "fail"
END IF


Many thanks
Alex

[bitvast]

TYPEOF$ isn't giving any output for the new suffixes:


DECLARE a$
DECLARE b
DECLARE c%
DECLARE d#

PRINT TYPEOF$(a$)
PRINT TYPEOF$(b)
PRINT TYPEOF$(c%)
PRINT TYPEOF$(d#)
char*
long

[Pjot]

Thanks bitvast,

Good catch! Fixed in the latest beta.

BR
Peter

[bitvast]

Peter, maybe I'm misunderstanding something, but if the % suffix denotes long just as a variable without a suffix does, then why use it?

I suppose it doesn't matter if there are two ways of declaring a long, but for pure BaCon (not using C types) the three types are NUMBER, FLOATING, and STRING

NUMBER: no suffix - x
FLOATING: # suffix - x#
STRING: $ suffix - x$

I suppose you could have the % for another type of NUMBER, e.g. an int, but this can be declared explicitly using TYPE.

[vovchik]

Dear bitvast,

Another excellent find - you do have a knack for these things. Thanks.

With kind regards,
vovchik

[Pjot]

but if the % suffix denotes long just as a variable without a suffix does, then why use it?

Yeah, well, that's true - I do not really have an answer to that, other than just being 'consequent'. Each of the three main types have their own suffix now. If the '%' suffix didn't exist, then probably we would see people asking the opposite

But for function names, it does make sense. If a RETURN returns an expression, then the '%' suffix can force the type of the returned value to long. (And this can also be forced with 'TYPE'.)

BR
Peter

[bitvast]

Jun 29, 2014 14:22:23 GMT 1 Pjot said:

But for function names, it does make sense. If a RETURN returns an expression, then the '%' suffix can force the type of the returned value to long. (And this can also be forced with 'TYPE'.)

Good point. 

[bitvast]

Peter,

This is ok:


DECLARE x% = 1
DECLARE x# = 1
DECLARE x$ = "1"

but with multiple assignments I get an error with the string.

DECLARE x% = 1, y% = 2
DECLARE x# = 1, y# = 2
DECLARE x$ = "1", y$ = "2"

In file included from baconshell.bac.c:2:0:
baconshell.bac.h:11:48: warning: initialization makes integer from pointer without a cast [enabled by default]
x__b2c__string_var = "1", y__b2c__string_var = "2";
^
baconshell.bac.h:11:1: error: initializer element is not computable at load time
x__b2c__string_var = "1", y__b2c__string_var = "2";
^
make: *** [baconshell.bac.o] Error 1

[vovchik]

Dear bitvast,

I am not certain that amalgamated declarations and assignments are such a good idea in the first place, but they are convenient. Multiple assignment/declaration in one line - with different types - requires some extra work for the parser and may slow things down in terms of compilation. I don't think this is a bug per se, because Peter, in his examples, does not give any of that nature. You might be asking for a "feature", though, which is fine, but I wonder what ramifications this might have, if any, on the speed of parsing.

With kind regards,
vovchik

[Pjot]

All,

Well, the program works without the string assignments. So multiple assignments in one line for floats and integers are OK. Therefore it makes sense that it should work for strings also.

And indeed, in none of the existing programs such an assignment is used. In fact, this possibility is simply not implemented in BaCon. So, technically, it is not a bug, but a 'missing feature'

Anyway, it is fixed in the latest beta.

BR
Peter