RUN command 'File not found' error

[donnybowers]

Not sure why this is happening. I've tested '/usr/bin/firefox' in the terminal and it executes Firefox. With the RUN command it gives a file not found error. Am I doing something wrong? is it a bug? or is it something that just hasn't been implemented yet in alpha 347?


run "/usr/bin/firefox"


Here is the error dump:


==2019/3/5==23:05:12==BEGIN RUNTIME DIAGNOSTIC DUMP
Note: this file stored in VisualWorks #source (UTF-8) encoding

Cause of Dump: Unhandled exception: Project/module /usr/bin/firefox not found.
Smalltalk Version: 'VisualWorks®, Pre-Release 8.3.2 (apr18.3) of April 20, 2018'
Object Memory versionId: #[172 40 76 176 83 2 3 4 172 47 76 176]
Class creating this dump: ErrorDumper
------------------------------------------------------------
Active Process
Process named: 'Unnamed Process'
Process priority: 50
Process identity hash: 4572
Context Stack:
[1] RuntimeError>>raiseSignal
[2] optimized [] in Director>>direct:
[3] BlockClosure>>cull:
[4] RuntimeError(GenericException)>>performHandler:
[5] RuntimeError(GenericException)>>propagatePrivateFrom:
[6] RuntimeError(GenericException)>>propagateFrom:
[7] RuntimeError(GenericException)>>propagate
[8] RuntimeError(GenericException)>>raiseSignal
[9] RuntimeError>>raiseSignal
[10] RunFrame>>animate:
[11] optimized [] in [] in Director>>direct:
[12] OrderedCollection>>do:
[13] optimized [] in Director>>direct:
[14] BlockClosure>>on:do:
[15] ProgramDirector(Director)>>direct:
[16] ProgramDirector>>direct:
[17] ProgramDirector(Director)>>for:direct:
[18] ProgramDirector>>for:direct:
[19] Program>>runWithDirector:
[20] optimized [] in Program>>runForked
[21] BlockClosure>>on:do:
[22] optimized [] in Process class>>forBlock:priority:

------------------------------------------------------------
Unhandled Exception:
class: UnhandledException
creator: UnhandledException
errorString: Unhandled exception: Project/module /usr/bin/firefox not found.
parameter: a RuntimeError

==2019/3/5==23:05:12==END RUNTIME DIAGNOSTIC DUMP



[Chris Iverson]

"Project/module <name> not found"


I'm guessing RUN in LB5 hasn't actually been hooked up to run external programs yet. Instead, it's currently only got the Run BASIC module functionality, which lets you put functions in external source files, and then call them in a different file. (Not gonna lie; I am going to abuse the hell out of this. It's sooooo useful.)

Here's an example. Save this as modTest.bas:

Function doAdd(num1, num2)
   doAdd = num1 + num2
End Function

In the same folder, save and run this(as anything):

run "modTest.bas", #test

input "Enter number 1.>";a
input "Enter number 2.>";b

sum = #test doAdd(a, b)

print
print "Sum of values: ";sum

[Carl Gundel]

Mar 6, 2019 0:21:34 GMT -5 Chris Iverson said:

"Project/module <name> not found"


I'm guessing RUN in LB5 hasn't actually been hooked up to run external programs yet. Instead, it's currently only got the Run BASIC module functionality, which lets you put functions in external source files, and then call them in a different file. (Not gonna lie; I am going to abuse the hell out of this. It's sooooo useful.)

Here's an example. Save this as modTest.bas:

Function doAdd(num1, num2)
   doAdd = num1 + num2
End Function

In the same folder, save and run this(as anything):

run "modTest.bas", #test

input "Enter number 1.>";a
input "Enter number 2.>";b

sum = #test doAdd(a, b)

print
print "Sum of values: ";sum

Yeah, that functionality will probably be renamed LIBRARY.

  library "modTest.bas", #test

[donnybowers]

Mar 6, 2019 8:31:10 GMT -5 Carl Gundel said:

Mar 6, 2019 0:21:34 GMT -5 Chris Iverson said:

"Project/module <name> not found"


I'm guessing RUN in LB5 hasn't actually been hooked up to run external programs yet. Instead, it's currently only got the Run BASIC module functionality, which lets you put functions in external source files, and then call them in a different file. (Not gonna lie; I am going to abuse the hell out of this. It's sooooo useful.)

Here's an example. Save this as modTest.bas:

Function doAdd(num1, num2)
   doAdd = num1 + num2
End Function

In the same folder, save and run this(as anything):

run "modTest.bas", #test

input "Enter number 1.>";a
input "Enter number 2.>";b

sum = #test doAdd(a, b)

print
print "Sum of values: ";sum

Yeah, that functionality will probably be renamed LIBRARY.

  library "modTest.bas", #test

That's really cool. These libraries will add a lot of power as our collections of them grows.

Will "modTest.lib" work the same as "modTest.bas"?

[Chris Iverson]

I'm guessing that's one of those "to be determined" things.

We don't know yet how compiled applications will be distributed; we don't know if it'll be possible to include compiled LB "modules" like that, or if it's all mashed together from source at compile time.

(This wasn't an issue in Run BASIC, because the source is ALWAYS available server-side, and NEVER available client-side.)

[donnybowers]

So I've been playing around with the RUN command. It appears to work exactly like the RUN command in RunBASIC. I don't think I would change that unless you plan to change it in RunBASIC too. I would say though, that this doesn't work like a "LIBRARY" or "INCLUDE" command (at least not as I would think of it), which would include another program within the current program. I love the idea of having that Library command and keeping the RUN command just as it currently is so that LB and RB remain alike in this respect.

But, (obviously) the thing I was trying to use RUN for in the OP was to shell to an external program. In many traditional BASICS, there was a "SHELL" command (i.e. BASIC, BASICA, GWBASIC, Turbo BASIC etc.) that allowed you to either shell to the commandline or else to send a command to run an external program. Being able to shell to a commandline (or terminal) would be nice, but not nearly as valuable as just being able to shell to an external executable. I don't know how the RUN command in LB4 worked programmatically, but it was capable of shelling to external Linux programs when run in Wine. I really hope that this functionality will be possible in the future stable version of LB5 while at the same time keeping the current RUN command functionality (to call up a BASIC program, and execute it - thus exiting the current program) and also the idea of a new added LIBRARY command that allows inline insertions of code from a library code file (probably less important than the RUN and SHELL functionalities). I don't necessarily expect to see it in the next alpha version, but I really hope that's the plan for the completed version.

So I see three functionalities here (which I'm currently calling RUN, SHELL and LIBRARY), the first two of which I believe are very important:

1. RUN - meaning the RUN command as it is now and just like it is in RunBASIC (for LB5 ".bas;.tkn?..." programs).
2. SHELL (or a second functionality of RUN?) - that runs external executables, batch files? (Microsoft), bash files (Linux) etc.
3. LIBRARY  - which would run code "inline" (meaning it executes that code and then continues on the next line) from a library file. This would be great for commonly used functions etc.

[Chris Iverson]

That is how RUN behaved in LB4 and down; it let you ask the operating system to invoke an external program of your choice.

I don't think the RUN command should be overloaded like that. I think it should retain it's old LB4 syntax, for compatibility with old programs, and I agree with the new syntax being instead moved to a LIBRARY command.

It makes sense to me, thinking of dynamic languages like Python.

LIBRARY "file", #test

Is functionally equivalent to

import file as test

in Python.


Maybe that's what it should be called? "IMPORT"?

[donnybowers]

May 20, 2019 18:26:22 GMT -5 Chris Iverson said:

That is how RUN behaved in LB4 and down; it let you ask the operating system to invoke an external program of your choice.

I don't think the RUN command should be overloaded like that. I think it should retain it's old LB4 syntax, for compatibility with old programs, and I agree with the new syntax being instead moved to a LIBRARY command...

I agree. But, I'm seeing three different functionalities here that may require three different key words. I agree that having the external shell incorporated in the RUN command could possibly be overload, which is really my point. I'm only bringing it up because I'm seeing three different functionalities here.

1 - RUN as in the way RunBASIC works and the way the current RUN command works in LB5 alpha build 349.
2 - SHELL which executes an external command and may or may not be incorporated in RUN (which doesn't matter to me, whatever seems better to Carl from the development perspective).
3 - LIBRARY which would be very different from both of the above because all it does is insert an external code file into the current program wherever it is called, like INCLUDE in PHP or TurboBASIC, and I'm guessing in commands in Python etc.

Personally I think the third functionality. "LIBRARY", would be really nice to have, but not nearly as valuable as the first two.

[donnybowers]

One of the reasons I'm so excited about LB5 is that we will be able to do things in Linux, using commandline tools like "texttohtml" or "texttopdf" and a thousand other things without ever opening a terminal. But it requires the ability to shell to those commands, which are external programs. I have used utilities like "youtube-dl" from LB 4.x simply by sending the command and my parameters through the RUN command.  I'm seeing possibilities that to me are just as powerful as (maybe more powerful than) the LB4.x feature of using Windows API.

It really doesn't matter to me if I have to type RUN "youtube-dl" or SHELL "youtube-dl". What does matter to me is I wouldn't want to lose the ability to also type RUN "myprogram.bas" and have it execute another BASIC program, like you can do in RunBASIC and like you can do right now in LB5 build 349. Both of these functionalities are very high on my wish list for LB5. What keywords we have to use to do it is not all that important to me in the grand scheme of things. But I do kind of like the idea of RunBASIC and LB5 being the same wherever possible. Even backward compatibility, while it's a good idea wherever possible, isn't that important to me, or I should say, "won't be that important to me once we have a help file to guide us through any new syntax".

[donnybowers]

Actually, when I first made this post, I thought that the RUN command was completely broken. I just now discovered that I could use it like you use it in RunBASIC, and I LOVE IT!!! I wouldn't want to see that functionality go away. And I guess that's my main point now that I've realized what the Run command does in LB5 right now. That and the fact that I really want something that also allows me to run external commands, just like I can now do in LB4.x. The semantics and syntax of it are much less important to me than the functionality itself. Naturally, I want LB to remain LB and not morph into some other language. But hopefully you get my point. If three different commands would work out better, so be it. Or if all three functionalities are merged into one command or two, all the better (?). It's the functionality I'm addressing.

Of course I still don't know how the new LB will work. Whether it will use a tokenized runtime engine (with .tkn files), create standalone executables or if it will be more like an interpreted BASIC. With the power of modern computers I wonder if it really even matters that much as long as you can make a distributeable program. But, the LB4.x version of the RUN command is great in my opinion. I don't care if it uses .tkn or .bas files, as long as you can run them. I'm reminded of some of the .tkn "menu" and "program manager" example programs from back in the day.

[Chris Iverson]

Don't get me wrong, I don't want that functionality to go away, either. Heck, I said above how excited I am to have it in LB. I'm just not sure I want it tied to the RUN command.

Yes, it makes it more compatible with Run BASIC, but that's the thing: Run BASIC is NOT compatible with Liberty BASIC. It's similar, but there's quite a bit you'd have to change to get an average LB program running in RB.

Liberty BASIC SHOULD be compatible with ITSELF. If Carl wants to fit the functionality of both onto the RUN command, great!

If it's only one thing that gets tied to the RUN command, and the other thing gets a new command(either the LB4 RUN gets called SHELL, or the LB5 RUN gets called LIBRARY or IMPORT or something), then I want LB4 to win out, for compatibility with existing LB code. Put the larger burden of change onto the adaptation where a bunch of stuff is going to have to change already, anyway.


I think we're basically saying the same thing(we want the functionality of both), we're just differing on the exact syntax.

[Carl Gundel]

I think we briefly discussed this in an earlier thread. The command as implemented in Liberty BASIC will be called LIBRARY. Then I will reimplement RUN to do what LBers expect.

[donnybowers]

May 20, 2019 22:35:14 GMT -5 Carl Gundel said:

I think we briefly discussed this in an earlier thread. The command as implemented in Liberty BASIC will be called LIBRARY. Then I will reimplement RUN to do what LBers expect.

Sounds like a plan. I can deal with that.