BaCon CALL documentation error?

For discussions about programming, programming questions/advice, and projects that don't really have anything to do with Puppy.
Post Reply
Message
Author
PaulR
Posts: 249
Joined: Wed 04 May 2005, 18:45
Location: UK

BaCon CALL documentation error?

#1 Post by PaulR »

According to http://www.basic-converter.org/documentation.html#CALL

CALL

"...calls a subroutine if the sub is defined at the end of the program."

I found this to be incorrect - it only seems to work if the SUB is defined at the start of the program (and it does not seem to be required in that case anyway).

Just in case anyone else is banging their head against a wall with this as I've just done for an hour :D (the compiler log message wasn't very helpful in my case).

Paul

User avatar
vovchik
Posts: 1507
Joined: Tue 24 Oct 2006, 00:02
Location: Ukraine

#2 Post by vovchik »

Dear Paul,

CALL is used if an invocation is made prior to the definition of the SUB. For all practical purposes, you should program like in Pascal, defining your global vars, doing imports, writing your SUBs and FUNCTIONs and then calling a "MAIN". It will make life easier and the code much more readable after, say, three months. :)

With kind regards,
vovchik

PS. And then very little need for CALL. Sometimes yes, but mostly no.

PaulR
Posts: 249
Joined: Wed 04 May 2005, 18:45
Location: UK

#3 Post by PaulR »

Hi vovchik

I understand but it doesn't seem to work in that way. I had my program laid out like so (with the SUB at the end):

Some code here
CALL foo()
END

SUB foo()
...
ENDSUB


If I restructure it like this it works....

SUB foo()

ENDSUB

Some code here
CALL foo()
END

Thanks for the reply,

Paul

User avatar
vovchik
Posts: 1507
Joined: Tue 24 Oct 2006, 00:02
Location: Ukraine

#4 Post by vovchik »

Dear Paul,

I have a coded few thousand programs/subs and functions in BaCon and have not run across your problem. You first define the subs and then invoke them in your main, which, preferably, should be short and situated at the end of your code.

With kind regards,
vovchik

User avatar
sunburnt
Posts: 5090
Joined: Wed 08 Jun 2005, 23:11
Location: Arizona, U.S.A.

#5 Post by sunburnt »

PaulR; Everything you type is checked to be sure it lines up with what it does.
The program has to read the SUB/FUNCTION first or the main code calling it has nothing to call.
Even Bash throws an error if you call a function before the function is read.

You get an error if a string variable is used without setting it first.
A string variable does not default to "", it equals "null" ( not the same ).
So set new strings you are going to use "empty": NewStr$ = ""

Integers default to 0, which is nice as you don`t need to set them first to use them.
And I think all the number types default to 0, but I have not checked this out... vovchik.?
.

User avatar
sunburnt
Posts: 5090
Joined: Wed 08 Jun 2005, 23:11
Location: Arizona, U.S.A.

#6 Post by sunburnt »

vovchik; A Q if I could.

I`m writing a general purpose GUI maker.
It reads a file for commands to make the GUI.
It then needs another file for the click events.

My problem is you can`t use variables to specify include files.
For the GUI maker to be truly useful it has to be like GtkDialog and be reusable.
So different GUI files need event files named for that GUI file.
/path/FileName.gui
/path/FileName.clk
The other problem is that you can`t use text read from a file for BaCon code.

Here`s the GUI file, very simple and quick to write ( unlike GtkDialog ):

Code: Select all

win mkDlgs Demo.
lbl This is a demo. of mkDlgs
lbl Look at the file mkDlgs.gui
lbl It has the GUI instructions.
sepLine
cmbOptions
btnCombo Which Combo Item is Selected?
sepLine
chkTest This is a Check Box.
btnCheck Is Check Box on or off?
entText This is a text Entry Box.
btnEntry Print Contents of Entry Box.
btnEnd Close
# So no including a dynamically named file, and text can`t be used for code.
I think you see the problem. If you really want to see the code just say so.
.
Last edited by sunburnt on Fri 05 Apr 2013, 08:37, edited 2 times in total.

User avatar
vovchik
Posts: 1507
Joined: Tue 24 Oct 2006, 00:02
Location: Ukraine

#7 Post by vovchik »

Dear Terry,

I have also thought that it would be convenient to do this:

Code: Select all

+-----------+
|bla bla bla|
|bla bla bla|
|..[[ OK ]].|
+-----------+
and have a little program generate the code. I would pass the ascii gui text and the actions files on the command line as two arguments and have the gui designer then spit out the code. Food for thought...

With kind regards,
vovchik

PS. Or one ascii text file containing the mockup in ascci plus the actions, suitably marked.

User avatar
sunburnt
Posts: 5090
Joined: Wed 08 Jun 2005, 23:11
Location: Arizona, U.S.A.

#8 Post by sunburnt »

I thought of that too, but text could only call a predetermined set of actions.
IF the line is XXX THEN call SUB.
How can text be made to be usable commands to Bacon?

The very best would be able to include the event file.
So then all of the the events would have to be in one file, not the best setup.
Or one included file could include many different event files, only all of them.

Bash has many capabilities that Basic doesn`t even come close to.
It`s horribly limiting... Almost a stunted language.

vovchik; If I`ve missed something that solves this, please give me an example.

PaulR
Posts: 249
Joined: Wed 04 May 2005, 18:45
Location: UK

#9 Post by PaulR »

Sorry to bring this back on topic :lol:

Here's the original problem. Main code followed including a CALL to the SUB defined after the main code, which according to the docs should work as I first posted:

CALL - "...calls a subroutine if the sub is defined at the end of the program."

Code: Select all

OPEN "." FOR DIRECTORY AS mydir
REPEAT
    GETFILE myfile$ FROM mydir
    IF myfile$ != "." AND myfile$ != ".." THEN
		IF RIGHT$(myfile$, 4) = ".txt" THEN
			CALL parseFile(myfile$)
		ENDIF
		
	END IF
UNTIL ISFALSE(LEN(myfile$))
CLOSE DIRECTORY mydir
END

SUB parseFile(STRING fileName$)
'code here
ENDSUB
The compiler complains:

Code: Select all

/usr/lib/gcc/i486-slackware-linux/4.7.1/../../../../i486-slackware-linux/bin/ld:./read_files_dirs.bac.parseFile.tmp: file format not recognized; treating as linker script
/usr/lib/gcc/i486-slackware-linux/4.7.1/../../../../i486-slackware-linux/bin/ld:./read_files_dirs.bac.parseFile.tmp:3: syntax error
collect2: error: ld returned 1 exit status
Which I don't understand. Is there some other error in my program or are the docs wrong? In any event, re-arranging the code as I would in C or Pascal such that the functions etc come first everything works ok :D

Paul

User avatar
vovchik
Posts: 1507
Joined: Tue 24 Oct 2006, 00:02
Location: Ukraine

#10 Post by vovchik »

Dear Paul,

The following works for me (try adding a newline to the end of your code), although the STANDARD BaCon way would be to put the SUB first and then the main:

Code: Select all

OPEN "." FOR DIRECTORY AS mydir
REPEAT
	GETFILE myfile$ FROM mydir
	IF myfile$ != "." AND myfile$ != ".." THEN
		IF RIGHT$(myfile$, 4) = ".plx" THEN
			CALL parseFile(myfile$)
		END IF
	END IF
UNTIL ISFALSE(LEN(myfile$))
CLOSE DIRECTORY mydir
END

SUB parseFile(STRING fileName$)
'code here
	PRINT fileName$
END SUB
BaCon could be coughing because of something in your SUB code.

With kind regards,
vovchik

PaulR
Posts: 249
Joined: Wed 04 May 2005, 18:45
Location: UK

#11 Post by PaulR »

Hi vovchik

Very odd. I added a newline to my code and the compiler falls over as before. I copy/pasted your example and it had the same problem. I added a newline to your code an it compiles fine!

I'll stick to the conventional layout in future :)

At least I know I wasn't banging my head against the wall because of a mistake I'd made (for a change!).

Best regards

Paul[/b]

User avatar
L18L
Posts: 3479
Joined: Sat 19 Jun 2010, 18:56
Location: www.eussenheim.de/

BaCon CALL documentation error?

#12 Post by L18L »

PaulR wrote:....I added a newline to your code an it compiles fine!....
http://murga-linux.com/puppy/viewtopic. ... &start=477

:arrow: BaCon NEW LINE documentation error :wink:

PaulR
Posts: 249
Joined: Wed 04 May 2005, 18:45
Location: UK

#13 Post by PaulR »

But my code wouldn't compile even with a new line at the end. Maybe there's some invisible character luring in the code that I copied from the net...

Paul

User avatar
vovchik
Posts: 1507
Joined: Tue 24 Oct 2006, 00:02
Location: Ukraine

#14 Post by vovchik »

Dear Paul,

I use Geany, and it shows most of those weird chars as squares with some numbers inside. Save the code back as UNICODE-UTF8 and with Unix line endings (under the Document menu in Geany). Or cat the code to a terminal and copy from there. I have often seen weird chars in code coming from the DOS/M$ world. Usually, that stuff just needs to be removed/obliterated via search and replace. :)

With kind regards,
vovchik

PaulR
Posts: 249
Joined: Wed 04 May 2005, 18:45
Location: UK

#15 Post by PaulR »

sunburnt, I'm not sure if this would help but here goes:

You could put your commands in a plain text file, parse that file and write it out in BaCon source form then invoke Bacon to compile it.

For example, command.txt containing this line

label Type of cheese

is parsed and written into the file myprog.bac as

label123=MARK("Type of cheese"), 50, 100)

where '123', '50' and '100' are either included in the command.txt or calculated in the parser. (If you're including them in the source you might as well just write the program though I suppose!).

You could then execute 'bacon myprog.bac' - you'd end up with an executable built from a simple text only command file.

You could expand the technique to add your event handlers so a line in command.txt like;

button OK, confirmAction

would create the button, attach the sub confirmAction and copy/paste the confirmAction section from your click.txt file into myprog.bac.

Paul

User avatar
sunburnt
Posts: 5090
Joined: Wed 08 Jun 2005, 23:11
Location: Arizona, U.S.A.

#16 Post by sunburnt »

Thanks Paul; But you can`t use a variable for a callback like this:

Code: Select all

CALLBACK(widgetID_, callSUB$)
All Bacon commands, callbacks, and array dimensions have to be literals.
Where as in Bash you can use a variable for just about anything.

And you can`t make the event code into an exec. file either.
It may need to manipulate the controls in the main GUI.
Both the GUI and event files need to be simple text files.

Post Reply