BaCon (Beta 3.0.4)

[alexfish]

Hi Peter

Vovchik was asking about the size of the Exec when compiling Bacon using TCC , via PM

The PM below

Hi Vovchik

Latest Bacon 3.0.4 Quick test of one of the demos

gcc exec size 11.9 KiB

using Latest version of tcc compiled from source using gcc to compile on board

tcc exec size 8.9 KiB

U will get an error on Bacon that will show like a failed build. but it does produce an
exec. had not noticed that one before , generally tcc = the larger of the two
was in the habit of using tcc for repetitive testing/dev apps , did the final compile with gcc. now need to test the results of UPX

the message..

File '/usr/lib/libbacon.a'

Line 1: !<arch>

Cause: 'ARGUMENT$' defined twice

will report this one in Bugs

BR
Alex

[Pjot]

Hi Alex,

Indeed TCC will generate some warnings, but the binary is created and actually works.

So yes, you're right. I noticed the issue with TCC as soon as BaCon moved to the 'libbacon.a' static library construction to eliminate dead code. In the beginning there were a lot of errors with TCC, most of which now have been resolved already.

The reason for these left-over warnings is that TCC is very strict when it comes to global symbols used in external libraries. However, gcc, Compaq and clang have no issues here at all. So, I am not sure if this is related to TCC, and if so, what can be done about it. But I will take another look at it.

BR
Peter

[Pjot]

Hi Alex,

In an unexpected flash of divine inspiration I was able to find a suitable fix for the TCC warning issue

It is solved in the latest beta.

BR
Peter

[alexfish]

Hi Peter

Tested U'r "unexpected flash of divine inspiration",
does exactly as it says.

Thanks again for another "unexpected flash of divine inspiration".

BR
Alex

[alexfish]

Hi Peter

Can test these two bits of code

demo 1


B$="Start"

PRINT B$

B$= "End"

PRINT B$

demo 2

DECLARE B$="Start" TYPE char*

PRINT B$

B$ = "End"

PRINT B$

BR
Alex

[Pjot]

Thanks Alex,

Both of the programs can be compiled, but the second one shows a memory corruption. It is similar to the issue observed before, where string arrays were assigned a value in their declaration.

This was a very easy fix, as the preparation was already done for the arrays.

You can find the latest in the usual location.

BR
Peter

[airr]

Hi, found a couple of things when compiling on MacOS.

1 - Make fails with the following (same happened with 3.0.3)
bash ./bacon.sh -d build bacon.bac
./bacon.sh: line 41: syntax error in conditional expression: unexpected token `('
./bacon.sh: line 41: syntax error near `+(*'
./bacon.sh: line 41: `    if [[ ${KSH_VERSION} = +(* 93*) ]]'
make: *** [bacon] Error 2

I got around this by changing the "+(* 93*)" to "$(* 93*)", which may not be right but I was able to successfully compile using Bash-3.2.57 (native version on my Mac [Yosemite]).

2 - "PRAGMA INCLUDE" looks in "/usr/include" for any C-header files, and if not found defaults to looking in the current directory.

Since a lot of 3rd-party libraries (compiled manually) default to installing into "/usr/local", you might want to add a check for "/usr/local/include" as well.

Thanks,

AIR.

[Pjot]

Thanks airr,

I will take a look at it.

BR
Peter

[Pjot]

Hi airr,

For (1), I have seen this error before with older versions of BASH 3.2 on Linux also. There, the variable $BASH returns an empty result, causing BaCon to take the KSH definitions, which is wrong. I hope this is also causing your issue.

For (2), I have added the check on '/usr/local/include' in the latest beta.

Thanks,
Peter

[airr]

Jul 16, 2015 20:46:45 GMT 1 Pjot said:

Hi airr,

For (1), I have seen this error before with older versions of BASH 3.2 on Linux also. There, the variable $BASH returns an empty result, causing BaCon to take the KSH definitions, which is wrong. I hope this is also causing your issue.

For (2), I have added the check on '/usr/local/include' in the latest beta.

Thanks,
Peter

Hi, Peter.

The $BASH variable is set under OSX. The issue, I believe, comes about because there's no check for $KSH_VERSION.

When I modify bacon.sh like this:

# Are we using BASH?
if [[ -n $BASH ]]
then
   if [[ ${BASH_VERSINFO[0]}$((${BASH_VERSINFO[1]}+0)) -lt 32 ]]
   then
       echo "System error: this is BASH version ${BASH_VERSION}. BaCon needs BASH 3.2 or higher to run!"
       exit 1
   fi
   # Set the extended globbing option in BASH
   shopt -s extglob
   typeset -rx g_FLOATFACT="(1.0*"
   typeset -rx g_FUNCTFACT="()"
   typeset -rx g_OPENFACT="\("
fi

if [[ -n $KSH_VERSION ]];then
   # Check Kornshell version
   if [[ ${KSH_VERSION} = +(* 93*) ]]
   <...>


Then it compiles with no errors.

Thanks for #2,

AIR.

[Pjot]

Thanks airr,

If the BASH variable is set, then in the original code the KSH part should not be executed...?

However, I see now that a similar issue occurs in Redhat 4 (BASH variable is set but still the KSH part is executed / parsed). I guess the BASH interpreter tries to parse and evaluate *all* code before actually executing it.

Thanks for isolating the issue, I will think of some other syntax for the "+(* 93*)"-part.

BR
Peter

[alexfish]

Hi Peter

not sure about this one...

here using hug.bac + KEY and RESETKEY within a TIMEOUT FUNCTION

FUNCTION get_key()
LOCAL i TYPE int
i= KEY
PRINT i

RESETKEY
REM PRINT KEY
RETURN TRUE

END FUNCTION

in the above code have to define an integer . a direct "PRINT KEY" does not work. msg = is of type long , int required.
also the RESET seem to return the pointer and not a value EDIT :: the 300772 looks like it is the value.. IE retest = same

the terminal aout

100
300772
300772
104
300772
102
106
300772
103
300772
107
300772


BR
Alex

[Pjot]

Hi Alex,

Sorry for my late response, but I was traveling.

For your problem, you have to realize that 'KEY' actually is a function. Therefore, in order for PRINT to work properly, you have to use brackets. If you do not use the brackets then PRINT will print the actual address of the KEY function instead.


PRINT KEY()


HTH
Peter

[alexfish]

Hi Peter

Got it .. as in forgot it ..

Thanks + BR

Alex

PS::

If wondering why the aout , was trying to see what was going on.


perhaps can try something like this with hug , one has to click on the terminal after raising the window (bacon gui) use terminal mode.

then type away


INCLUDE hug.bac

FUNCTION get_key()
PRINT hug_gui_properties.last_key_pressed
i= KEY()
PRINT i

RESETKEY
REM PRINT KEY
RETURN TRUE

END FUNCTION

Win= WINDOW("Test",600,400)


TIMEOUT(500,get_key)

DISPLAY