E.g., if fpi existed, I would add a shebang like this to my code:

#!/usr/bin/env fpi

Cheers,

Andrew Pennebaker
www.yellosoft.us

On Sat, Oct 15, 2011 at 00:25, Andrew Pennebaker <

InstantFPC <http://wiki.freepascal.org/InstantFPC>

Thanks ik. Merf, it appears fpc can't compile when a shebang is added. In future versions, can fpc treat shebangs as comments so that instantfpc code could be compiled like normal Free Pascal code?

$ cat hello.pas
#!/usr/bin/env instantfpc
program Hello;
begin
writeln('Hello World!')
end.

$ fpc hello.pas
Free Pascal Compiler version 2.4.4 [2011/05/01] for i386 Copyright (c) 1993-2010 by Florian Klaempfl
Target OS: Darwin for i386
Compiling hello.pas
hello.pas(1,1) Error: Illegal char constant
hello.pas(1,2) Fatal: Syntax error, "BEGIN" expected but "const string" found
Fatal: Compilation aborted
Error: /usr/local/bin/ppc386 returned an error exitcode (normal if you did not specify a source file to be compiled)

Cheers,

Andrew Pennebaker
www.yellosoft.us

On Sat, Oct 15, 2011 at 00:43, Andrew Pennebaker <

$ chmpd +x hello.pas
$ ./hello.pas

Opps,
$ chmod +x hello.pas

Yeah, I know to chmod my scripts before dot-slashing them. It's just that fpc can't handle shebangs, and I don't want to have to choose either scripting or compiled. I like my Pascal code to be work in either mode.

Cheers,

Andrew Pennebaker
www.yellosoft.us

Andrew Pennebaker wrote

Yeah, I know to chmod my scripts before dot-slashing them. It's just that fpc can't handle shebangs, and I don't want to have to choose either scripting or compiled. I like my Pascal code to be work in either mode.

Gosh, (Free)Pascal is a compiler, not an interpreted script language as you seem to be accustomed to!

Ralf

I get the impression that you want to use Pascal for something it wasn't designed for. Even if you can find some kind of solution, it will probably be a bad hack. But that question is probably for fpc-other.

So anyway, the only solution I can think of is to automatically comment out the shebang by calling sed or something from your makefile if you "compile as a program". (As fas as I understand, this is exactly equivalent to what instantfpc does in the background, since it is NOT an interpreter. So what you do is in fact make a lot of fuss about two different ways of generating and running exactly the same executable.) You can even remove the comment after compilation again. This is as bad style as using the old #if 0 construction for debug code in C, though.

Good look,
Roland

Roland Schäfer wrote

Good look,

I meant "luck", of course.

Andrew Pennebaker wrote

Thanks ik. Merf, it appears fpc can't compile when a shebang is added. In future versions, can fpc treat shebangs as comments so that instantfpc code could be compiled like normal Free Pascal code?

.
.

While I agree with others suggesting that you try to use FPC in a way which it has not been designed for, there is probably a fairly simple answer for your question (not requiring you to create special scripts or makefiles, using sed, etc.). I have no experience with instantfpc myself, but looking at the Wiki page, it seems that it may be used also just for compilation of the source code if you always invoke instantfpc for compilation (with the right parameters, especially --skip-run) instead of using FPC directly. Again, not that I would consider it a very efficient or reasonable approach, but if you need to do this for whatever reason, it should apparently address your need.

Tomas

In our previous episode, Andrew Pennebaker said:

Thanks ik. Merf, it appears fpc can't compile when a shebang is added. In future versions, can fpc treat shebangs as comments so that instantfpc code could be compiled like normal Free Pascal code?

I'm not sure that went into 2.4.4 at the same time instantfpc itself did, possibly it is only in versions after 2.4.4.

Andrew Pennebaker wrote

Yeah, I know to chmod my scripts before dot-slashing them. It's just that fpc can't handle shebangs, and I don't want to have to choose either scripting or compiled. I like my Pascal code to be work in either mode.

It's always compiled.
instantfpc just strips the first line, passes the rest to the compiler and executes the resulting program. Add some caching for performance, and that's it.

Michael.

In our previous episode, Michael Van Canneyt said:

I still think instantfpc fails miserably in my primary need for scripting: installing FPC :-)

InstantFPC <http://wiki.freepascal.org/InstantFPC>

Now, you realy made my day :))
I am using FPC and Lazarus for very nice things almost every day and I love it.
I missed something like InstantFPC. Congratulations!!! Please keep up the good work guys.

Best regards,
Mihai

So you need some packer for instantfpc scripts which puts together fpc and basic rtl which are uncompressed for the actual installation :)

Good idea, van de Voort. Can someone confirm that fpc plays nicely with shebangs in a version after 2.4.4?

And Schäfer, I respect Pascal for being a compiled language. I myself and fond of Haskell. But Haskell has a scripted mode, and instantfpc, like all good interpreters, compiles code in the background. It's simply a convenience to write scripts, whether the language you're using is mostly interpreted or mostly compiled.

Cheers,

Andrew Pennebaker
www.yellosoft.us

Andrew Pennebaker wrote

Good idea, van de Voort. Can someone confirm that fpc plays nicely with shebangs in a version after 2.4.4?

It doesn't.

Jonas

In our previous episode, Andrew Pennebaker said:

Good idea, van de Voort. Can someone confirm that fpc plays nicely with shebangs in a version after 2.4.4?

I just tried, and it doesn't. I assume that it was talked about and got stuck in my mind, but it never really was implemented.

It works surprisingly good with FPC, probably because small programs in FPC don't need special parameters to compile.

It's simply a convenience to write scripts, whether the language

you're using is mostly interpreted or mostly compiled.

Whether scripting language or compiled language, you have to write the same code in both cases. Where is the difference?

The only advantage for scripts is that the source code is directly visible and cannot be hidden. But that can also be a disadvantage.

Nevertheless, I don't see any use in InstantFPC. The program starts much faster if it has already been compiled and there is no need to compile the source in the background before startup.

Hestermann:

Indeed, compiled programs will always run faster than interpreted programs. The value in scripting is that an interpreted environment allows coders to rapidly go through write code / test code loops. Interpreters let you explore your own codebase, like gdb but far more powerful.

Adding shebangs to fpc wouldn't kill Pascal or compiled programming. It would welcome scripting programmers into the Pascal community, and let Pascal programmers write and test code more quickly. The same programs that use instantfpc work in fpc; it turns out instantfpc runs fpc in the background. The main difference is that fpc currently borks on shebangs--but it doesn't have to.

Again, there's no need to fret about interpreted vs compiled. Even for compiled languages, there are interpreted options.

Haskell -> GHCi
Java -> Beanshell
Erlang -> erl

Finally, adding scripting capability to a programming language allows coders to use a language to be used for shell scripts. If you love Pascal, you might want to write sysadmin tools in Pascal to automate your workflow.

Cheers,

Andrew Pennebaker
www.yellosoft.us

On Sat, Oct 15, 2011 at 12:13 PM, Jürgen Hestermann <

Adding shebangs to fpc wouldn't kill Pascal or compiled programming.

Of course not. It just binds man power to something useless (IMO).

It would welcome scripting programmers into the Pascal community, and

let Pascal programmers write and test code more quickly.

More quickly? That sounds as if you never programmed in an integrated developement environment. How do you write scripts? With a text editor? Then you don't have a debugger at hand, no syntax highlighting, etc. And this lets you write code quick? Not for me.

Again, there's no need to fret about interpreted vs compiled.

I only don't get it why someone would like to write "scripts" instead of programs. Sounds quite masochistic. I know there are "real" script languages that live from a certain level of abstraction. But Pascal? That's a compiler language for fast programs.

Even for compiled languages, there are interpreted options.

But why?

Finally, adding scripting capability to a programming language allows

coders to use a language to be used for shell scripts. If you love Pascal, you might want to write sysadmin tools in Pascal to automate your workflow.

I do that all the time. But they are all compiled executables that I can launch from any script. Why should I force a compiler run at each executable runtime?

"Ralf A. Quint" hat am 15. Oktober 2011 um 05:03 geschrieben:

It's not enough to ignore the shebang line.
You need some extra stuff/options/parameters to compile scripts and run them in various contexts.
See instantfpc.
 

Gosh, (Free)Pascal is a compiler, not an interpreted script language as you seem to be accustomed to!

Mattias

Tomas Hajny hat am 15. Oktober 2011 um 10:19 geschrieben:

Yes, instantfpc has quickly become more flexible and more comfortable. You can now use it on Linux, BSD, OS X, Windows. You can run pascal programs as web script similar to php scripts. You can compile and debug instantfpc programs in Lazarus.
 
Mattias
 

Kannst Du mir mal verraten warum Du hier meine Antwort qoutest aber dann dem OP antwortest?

Ralf

Andrew Pennebaker wrote

Indeed, compiled programs will always run faster than interpreted programs. The value in scripting is that an interpreted environment allows coders to rapidly go through write code / test code loops. Interpreters let you explore your own codebase, like gdb but far more powerful.

Sorry, but you might have to learn proper software development skills... And learn to use the right tool for a task. Scripting tools/languages have their purpose, compiled languages/environments have theirs. Forcing some clutches of some scripting languages onto a compiled language just doesn't make sense, you are just promoting software bloat at it's best. Why use a multi-megabyte compiler to shuffle around more megabytes of data to compile a more or less small script each time it is run instead of using a more appropriate and efficient tool...

Finally, adding scripting capability to a programming language allows coders to use a language to be used for shell scripts. If you love Pascal, you might want to write sysadmin tools in Pascal to automate your workflow.

Actually I do, and that all without the whole shebang...

Ralf

Like?

Something funny (of course instantfpc cashes but even when compiling it takes only twice the time of bash and as soon as a script is cached, instantfpc beats bash each time by the factor of two):

$ time bash ./test.sh
Hello world

real 0m0.049s
user 0m0.010s
sys 0m0.020s
$ time instantfpc test.pp
Hello world

real 0m0.027s
user 0m0.000s
sys 0m0.030s

"Ralf A. Quint" hat am 15. Oktober 2011 um 19:15 geschrieben:

Weil ich eigentlich noch was schreiben wollte, dann aber mein Neffe interveniert hat.
Einerseits hast du recht, andererseits spielt das fuer den shebang keine Rolle.

Mattias

How do you write scripts? With a text editor? Then you don't have a debugger at hand, no syntax highlighting, etc. And this lets you write code quick? Not for me.

There may be a language barrier here. When I say "text editor", I mean something like vi, Emacs, TextMate, Eclipse. Syntax highlighting and code completion are often a given.

No debugger at hand? An interpreter *is* a debugger.

Sorry, but you might have to learn proper software development skills...

The final result of a project may be compiled code, but that doesn't mean we are restricted from using an interpreted environment to develop that code. You can use the same tools + an interpreter. That's an extra tool for software development, not the only one. If you don't like using instantfpc, you don't have to. But if you do, it would be nice if fpc played nicely with instantfpc-enabled code.

Scripting tools/languages have their purpose, compiled languages/environments have theirs.

Aye, scripting language and compiled languages often serve different purposes, but that doesn't mean they have to. You can write shell scripts in Haskell and compile executables in Ruby. Interpreted languages compile code in the background, so the difference is superficial.

Forcing some clutches of some scripting languages onto a compiled language just doesn't make sense, you are just promoting software bloat at it's best.

Yes, software bloat is to be avoided. In the simplest terms, I'm asking for fpc to consider shebangs as comments. That little syntactical addition wouldn't bloat fpc by much at all, but it would allow the same code to be compiled by fans of fpc, and interpreted by fans of instantfpc.

The current situation forces coders to decide "I'm going to write compiled code" or "I'm going to write interpreted code." That's kind of sad, because when you do want to use fpc, you don't want to go through a friend's code and manually remove his shebangs. By adding shebang comments, fpc would be able to run instantfpc programs. This feature unites programmers, it doesn't divide them.

Cheers,

Andrew Pennebaker
www.yellosoft.us

Andrew Pennebaker wrote

Yes, software bloat is to be avoided. In the simplest terms, I'm asking for fpc to consider shebangs as comments. That little syntactical addition wouldn't bloat fpc by much at all, but it would allow the same code to be compiled by fans of fpc, and interpreted by fans of instantfpc.

You are aware that InstantFPC isn't interpreting the source file in the sense of e.g. a Basic interpreter? It only strips the shebang and invokes FPC with the parameters passed in the shebang. Afterwards the resulting executable is started using the parameters that were passed when invoking the script.

If you still want FPC to ignore a shebang on the first line, you are always welcome to provide a patch and then it can be discussed whether this patch should be included in trunk.

Regards,
Sven

On Sat, October 15, 2011 19:56, Andrew Pennebaker wrote: .
.

No debugger at hand? An interpreter *is* a debugger.

No, not with InstantFPC (even if I should consider InstantFPC an interpreter which it isn't). Interpreters don't provide real debugging support (stepping through the code line by line, watching content of used variables, etc.) automatically (i.e. you may only get these features if a debugging support is added to the interpreter directly or provided as an add-on together with the interpreter - certainly not something given).

.
.

.
.

What's wrong with my suggestion to use instantfpc for compilation too if you need to use the same file both for compilation and direct execution?

Tomas

Barth:

Yes, there is a distinction to be made between an interpreted environment, say, GHCi, and instantfpc, which is simply a compiler wrapper just advanced enough to let you ./ your Pascal programs. With a little more work, instantfpc could become an interpreted environment.

I'll see if I can patch the fpc code to add shebangs as comments.

Cheers,

Andrew Pennebaker
www.yellosoft.us

15.10.2011 2:25, Andrew Pennebaker пишет:

There are some interpreters for object pascal, f.e. RemObject Pascal Script, DWScript. It`s easy to make command line interpreter based on one of them.

http://wiki.freepascal.org/DelphiWebScript
http://wiki.freepascal.org/Pascal_Script

Yes, there is a distinction to be made between an interpreted environment, say, GHCi, and instantfpc, which is simply a compiler wrapper just advanced enough to let you ./ your Pascal programs.

But hiding away the compilation step from the user does not turn a compiler language into an interpreter language. There is no benefit in doing so. You can simply compile your programs and then use the executable in your scripts. Where is the problem? Why insist on doing this in the background?

With a little more work, instantfpc could become an interpreted

environment.

I doubt that. It was not made for this.

Jürgen Hestermann wrote

But hiding away the compilation step from the user does not turn a compiler language into an interpreter language. There is no benefit in doing so. You can simply compile your programs and then use the executable in your scripts. Where is the problem?

There is no "problem". It's simply a matter of convenience. You may not think it to be more convenient to edit source code and then "run" it without an explicit compilation step in between, but other people obviously do. Trying to convince other people that there is no benefit or trying to make them convince you that there is a benefit is unlikely to lead anywhere.

That said, adding a hack to the compiler to ignore a she-bang if it appears at the start of a source file is extremely unlikely to ever happen (and I'm personally not inclined to accept such patches). As Mattias mentioned, if you want to compile such source code you can use instantfpc itself to compile the binary.

Jonas

Me neither. fpc is a compiler, not an interpreter... instantfpc is a nice trick, and you can do some neat tricks with it (web scripting for example), but it remains a trick.

Michael.

There are plenty who do believe it's convenient to hide compilation in the background--the users of instantfpc. Syntax for shebangs in fpc would bridge instantfpc and traditional Pascal code. You would no longer have to treat instantfpc code as a special case, because fpc wouldn't mind the shebangs.

It's the same for case statements and if statements. If you really prefer if statements for everything, you can write everything with if statements. But for those who recognize the convenience of case statements, it's nice to have case statements.

Adding shebangs would not change the nature of Pascal. It's first and foremost a compiled, highly optimized language. Shebangs would allow Pascal to better fill the Unix scripting niche.

I'm working on a patch, but when I compile fpc, the resulting binary appears to completely ignore the new syntax, insisting that #! is the beginning of an invalid character. Can anyone fix this?

if (c = '#') then
  begin
    readchar;
    if c = '!' then
        begin
          readchar;
          repeat
            readchar;
          until (c = #10) or (c = #13);
        end;
  end
$ cat hello.pas
#!/usr/bin/env instantfpc
program Hello;
begin
writeln('Hello World!')
end.
$ fpc hello.pas
hello.pas(1,1) Error: Illegal char constant
hello.pas(1,2) Fatal: Syntax error, "BEGIN" expected but "const string"
found

Cheers,

Andrew Pennebaker
www.yellosoft.us

Andrew Pennebaker hat am 16. Oktober 2011 um 19:53 geschrieben:

There are plenty who do believe it's convenient to hide compilation in the background--the users of instantfpc. Syntax for shebangs in fpc would bridge instantfpc and traditional Pascal code. You would no longer have to treat instantfpc code as a special case, because fpc wouldn't mind the shebangs.

The great feature of instantfpc is that it combines two steps: compiling and runnning. The other great feature is that it uses a cache directory, so that the source directory does not get polluted by ppu and executables and that it starts scripts faster than php, bash etc. This way you get the speed of a compiled program combined with the ease of use of a script. If you add the ability to fpc to ignore the shebang line, you are still missing the important features of instantfpc.
In other words: As long as you don't add the other abilities to fpc too, you still need instantfpc.
 
 
 

 
Normally a shebang script does not create files - it can run in a readonly directory.
 
 

 
To compile use:
instantfpc --skip-run -B hello.pas
 
If you don't like typing so much, define an alias for your shell. alias ifp='instantfpc --skip-run -B' 
 
Mattias