Oude grap: Gnu Visual Basic

Ik stootte toevallig op een oude 1-april grap, waarin iemand Richard Stallman het uitbrengen van een Visual Basic cloon laat aankondigen: Gnu Visual Basic. Ik kan niet afleiden uit de brongegevens van wanneer deze grap dateert, maar waarschijnlijk van voor Gambas enige bekendheid had. Als je niet beter wist zou je zelfs denken dat het over Gambas gaat (waarom begint het met een G? Gnu’s Alternative Means BASic? – Sorry Minisini, but you never really explained where the G A M came from – or were you really bitten by a shrimp?)

Het zou oorspronkelijk gepubliceerd zijn op freshmeat (dat ondertussen freecode heet). Momenteel is het nog na te lezen op deze site: www.shlomifish.org/humour/GNU-Visual-Basic
Om het artikel geloofwaardig te maken werd zelfs een website gemaakt over Gnu Visual Basic, maar het e-mail adres daarop spreekt boekdelen:
owner-gnuvb@april.org

Naar die site moet je niet op zoek gaan want die staat nu vol opdringerige reklame, kwestie van nog een beetje van de URL-bekendheid te profiteren zeker.

Kijk dus liever naar het origineel: gambas (op sourceforge)

Probeer niet te debuggen (Don’t TRY to DEBUG)

Tijdens het werken aan een project kan je snel “DEBUG” code tussenvoegen om feedback of een resultaat te kunnen volgen in de commandolijn onderaan…   Working on code, I encoutered an interesting problem using DEBUG …

DEBUG "test"
toont “test” in het zwarte venster, maar evengoed kan je een variabele laten zien:
DEBUG sSqlStatement
of nog iets duidelijker voor jezelf:
DEBUG "SQL statement is:" & sSqlStatement

Een andere techniek is het gebruik van TRY (code) / IF ERROR (code).

Mijn fout was de combinatie van de twee:

TRY DEBUG resultOfProcedure()
IF ERROR
(code)
ELSE
(code)
ENDIF

In de IDE werk dat perfect, maar het probleem steekt de kop op als je het project compileert; de DEBUG code wordt niet meer uitgevoerd (tenzij je compileert met behoud van DEBUG code), en de applicatie crasht.

Het behouden van DEBUG code kan je aanzetten in de IDE bij het compileren naar een uitvoerbaar programma:

Menu: Project, Make, Executable (ctrl-alt-m)

Open daar onderaan > Options en kies “Keep debugging information in executable”

Door dit verschil kon ik de fout opsporen: door de TRY DEBUG combinaties te vervangen door TRY PRINT werkte de uitvoerbare versie wel na “make executable”.

English version:(Don’t TRY to DEBUG)



Problem using DEBUG

If you code:
DEBUG "test"
it shows “test” in the black window underneath the Gambas IDE, but of course it is more interesting to show the content of a variable
DEBUG sSqlStatement
maybe with some explanation on the same line (in case the variable is empty):
DEBUG "SQL statement is:" & sSqlStatement

Another thing is the use of TRY (code) / IF ERROR (code).

My error was the combination of both:

TRY DEBUG resultOfProcedure()
IF ERROR
(code)
ELSE
(code)
ENDIF

In the IDE it does what you want, but the problem pops up if you run the compiled project.
The DEBUG code is not included any more* and your program crashes.
* Except if you compile with option to keep debug info.

In the IDE, you find the option to keep the DEBUG code here:

Menu: Project, Make, Executable (ctrl-alt-m)

Open > Options and check

“Keep debugging information in executable”.

If you run the program afterwards, the “TRY-DEBUG” crash will not happen. If you replace TRY DEBUG by TRY PRINT, the crash will not happen any more in the compiled program.
Problem identified!

Commandolijn, SHELL: Distributie en versie opvragen

Een commandolijnprogramma kan je vanuit Gambas uitvoeren met SHELL of EXEC.

bv:

EXEC [ "ls", "-lF"]

Vanaf er “wildcards” in komen, als een ‘*’ om een reeks niet op voorhand gedefinieerde files aan te duiden, moet je SHELL gebruiken.

bv:

SHELL "ls /etc/*release"

Je kan in de Gambas IDE in het console venster onderaan de resultaten zien.

Je kan de uitvoer naar een variabele binnen Gambas sturen door de lijn te eindigen met

TO sVariabele

Klein voorbeeldje:

Maak een nieuw project “Command line application”

plak in MMain:

' Gambas module file

PUBLIC sParameter AS String
PUBLIC sCommand AS String
PUBLIC sAnswer AS String

PUBLIC sLine1 AS String
PUBLIC sLine2 AS String


PUBLIC SUB Main()

  sCommand = "ls /etc/*release"
  
  SHELL sCommand TO sAnswer
  
  DEBUG "Answer was: >" & Trim$(sAnswer) & "<"
  
  sAnswer = Trim$(sAnswer)
  
  sCommand = "cat " & sAnswer
  
  SHELL sCommand TO sAnswer
  
  DEBUG "Answer was: >" & Trim$(sAnswer) & "<"
  
  sLine1 = Left$(sAnswer, String.InStr(sAnswer, gb.NewLine))
  
  DEBUG "sLine1 is: " & sLine1
  
END

Hier kan je code uittesten die je elders in een grotere applicatie inbouwt; sParameter en sLine2 dienden daarvoor.