LB Booster
Programming >> Compatibility with LB4 >> File or path not found at line 0 Error? http://lbb.conforums.com/index.cgi?board=compatibility&action=display&num=1467448155 File or path not found at line 0 Error?
Post by Coda on Jul 2nd, 2016, 08:29am
Hi, I have been programming most of my life and have been using Liberty Basic to create gui software for many years. I have only just stumbled across LBB and got VERY excited as I thought, "WOW! A compiler for LB!" So, I downloaded it and ran it and opened the 2000 odd line program I have been working on and all I get is this message when I try to run it: "Error! File or path not found at line 0" Now this didn't make a great deal of sense to me as the only file my program is dependent on are a few bitmaps which are loaded at the beginning and they haven't moved. To test this theory, I rem'ed all the loadbmp commands and I still get the same error. So, I now have no clue because my program doesn't access any other files and because my program has no line numbers this doesn't help me trace what is happening which could be basically anything at this point. Anyone know why this would happen?
Re: File or path not found at line 0 Error?
Post by Coda on Jul 2nd, 2016, 08:47am
Ok... so, I've figured it out. I had neglected to rem out one of the bitmap references. The program now runs. I now have two new questions though. 1. Can't LBB use relative paths? My program would need it to... that seems to be the issue. It doesn't like my relative paths. and 2. Now that the program IS actually running, it is about 10-20 times slower than LB. I don't understand... Isn't it supposed to be faster? Isn't that the whole point? Or is it only faster once compiled and slower before compiling?
Re: File or path not found at line 0 Error?
Post by Richard Russell on Jul 2nd, 2016, 09:53am
Relative paths should be fine. LBB will treat a relative path the same way as Windows does, i.e. as relative to the 'current directory'. Under almost all circumstances the current directory will be the same as DefaultDir$ but if you call the SetCurrentDirectory API that can result in them being different. I would suggest you perform some simple tests to establish why your relative paths aren't working.
Quote:
Now that the program IS actually running, it is about 10-20 times slower than LB. I don't understand...
Normally, you will find that 'pure BASIC' code (things like calculations) run much faster under LBB than under LB; you can confirm that by running the 'elapsed.bas' and 'sieve2.bas' programs supplied with LB 4.04 and LB 4.5.0. Programs that make heavy use of graphics typically run at about the same speed as LB, although with a bit of tuning you can often get a better performance from LBB.
What I suggest you do is to take advantage of the Profiler feature of LBB. Run your program in the profiler ('Run... Profile Program' menu option) and look to see where the time is being spent. A likely explanation for a program running significantly more slowly in LBB is heavy use of a feature that is native to LB but emulated in LBB. A classic example of this is the WORD$() function which can, in certain circumstances, run much more slowly in LBB.
The probability is that whatever is causing your program to run slowly can be easily worked around by a small change to the code. Once you have discovered what it is, report back here and we should be able to give more specific advice.
Quote:
Isn't it supposed to be faster? Isn't that the whole point?
It's part of the point, yes, but if you browse the Benefits section of the LBB Help File you will see that there are many other reasons for using it.
Richard. Re: File or path not found at line 0 Error?
Post by Coda on Jul 3rd, 2016, 05:21am
Thanks for the advice, Richard. I think I know what is happening with the slowing issue. I took your advice and ran the profiler. The main calculations loop of my program has quite a number of print statement so that I can easily debug as working. When you issue the nomainwin directive in standard LB, these are ignored by the runtime engine and the program speeds up dramatically as if they are not there and only slows down again when you allow a mainwin for debugging. According to the profiler, LBB is not ignoring these and still executing them in the absence of a main window and taking up valuable processor time. I can remove them or rem them to solve this but it might be worth making LBB ignore these if a nomainwin directive is issued if it's possible to do and if you plan any updates. I often program like this as I find debuggers very cumbersome and I often only need to know the value of 1 or 2 specific variables at one specific point to work out what is going wrong. So it's very easy to print it to a main window and then remove these lines before compilation or tokenisation. Perhaps it's a bad habit of mine but as I learnt to program prior to anything resembling a debugger became standard, it's force of habit that isn't going to change at this point...
That said, I'm not sure removing them will still make it much FASTER than LB though... but it will likely bring it to a comparable speed.
As for the relative paths problem, I am still trying to work that one out. I will report back what I find if anything.
Re: File or path not found at line 0 Error?
Post by Richard Russell on Jul 3rd, 2016, 10:41am
my program has quite a number of print statement so that I can easily debug as working... According to the profiler, LBB is not ignoring these
That's very interesting, and it isn't something I have considered previously. In LBB nomainwin only hides the main window, it does not actually close it, so as you say any print statements still execute and they may take a significant amount of time.
I don't think there's an easy way for me to fix this, at least for programs running in the IDE. As things stand, in LBB you can debug a program without having to 'recompile' it, and because the debugger overrides the presence of nomainwin I need any print statements to be active. In principle I could automatically delete the print statements in a program compiled to an EXE which would solve the problem, but you'd have to accept a slow-running program when run in the IDE.
Quote:
That said, I'm not sure removing them will still make it much FASTER than LB though... but it will likely bring it to a comparable speed.
If your program outputs a fair amount of graphics you may find that using the technique described in this wiki article speeds things up somewhat.