Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.postscript > #2969 > unrolled thread

Dev Environment for Postscript - solutions/desiderata?

Back to article view | Back to comp.lang.postscript

Contents

  Dev Environment for Postscript - solutions/desiderata? luser droog <luser.droog@gmail.com> - 2016-12-13 21:42 -0800
    Re: Dev Environment for Postscript - solutions/desiderata? luser droog <luser.droog@gmail.com> - 2016-12-13 23:39 -0800
    Re: Dev Environment for Postscript - solutions/desiderata? jdaw1 <jdawiseman@gmail.com> - 2016-12-14 01:20 -0800
    Re: Dev Environment for Postscript - solutions/desiderata? Carlos <angus@quovadis.com.ar> - 2016-12-14 16:49 +0100
    Re: Dev Environment for Postscript - solutions/desiderata? Andre Majorel <cheney@halliburton.com> - 2016-12-15 22:20 +0000
      Re: Dev Environment for Postscript - solutions/desiderata? luser droog <luser.droog@gmail.com> - 2016-12-17 00:58 -0800

#2969 — Dev Environment for Postscript - solutions/desiderata?

My experience with C programming is that it is often better
to organize programs into multiple source files so related
functions are together and the program pieces obey a 
"module discipline" to interoperate, the sum of which 
supports the needed functionality of the program.

I feel in my bones that my postscript code should be
better organized in this direction. Even a highly
"modular" program like ibis presents a barrier to
understanding by the simple fact that it's all stuffed
into one file. Eg.

http://codereview.stackexchange.com/questions/117320/document-formatting-markup-engine-in-postscript

The code is "just a big wall of text" at first glance,
and 90% of potential answerers don't have the energy to
penetrate to the good stuff (hypothesis).

But PostScript doesn't quite have the tools that a C
programmer has with make and the pre-processor.

We have 
http://www.math.ubc.ca/~cass/graphics/manual/code/psinc
but it needs modification to cope with indented (file)run
commands.

Has anyone else come up with solutions for working with
multi-file postscript "applications" and automatically
producing amalgamated sources which are compatible with
-dSAFER?

What other "nice to have"s are there for building bigger
things with PostScript?

[toc] | [next] | [standalone]

#2970

On Tuesday, December 13, 2016 at 11:42:01 PM UTC-6, luser droog wrote:

> But PostScript doesn't quite have the tools that a C
> programmer has with make and the pre-processor.
> 
> We have 
> http://www.math.ubc.ca/~cass/graphics/manual/code/psinc
> but it needs modification to cope with indented (file)run
> commands.
> 

For the record, I inline this perl script here:

#!/usr/bin/perl

# This reads in ps files, printing out all lines except
# ^( ... ) run
# where it performs an inclusion --- recursively.
# The current directory is updated.
# I think I got the skeleton from p. 192 of "Programming Perl"

use File::Basename;

include("", STDIN, 0, "stdin");

# insert a file into output

sub include {
        local($curdir, $input, $depth, $cf) = @_;
        $i = $depth; 
        while ($i > 0) {
                print STDERR "  ";
                $i--;
        }
        print STDERR "Opening $cf\n";
        $fh++;
        while ($_ = <$input>) {
                if (/^\((.*)\)[ ]*run/) {
                        ($name, $dir, $suffix) = fileparse($1, '');
                        if ($dir eq './') {
                                $dir = "";
                        }
                        $file = "$curdir$dir$name$suffix";
                        # print STDERR "file to open = {$file}\n";
                        if (open($fh, $file)) {
                                print "\n";
                                print "% - Inserting $name ----------------------\n\n";
                                include($curdir.$dir, $fh, $depth+1, $file);
                        } else {
                                print("Current directory $curdir.$dir\n");
                                print STDERR "Unable to open $file\n";
                                exit 1;

                        }  
                } else {
                        print $_;
                }
        }
        if ($input ne STDIN) {
                $i = $depth; 
                while ($i > 0) {
                        print STDERR "  ";
                        $i--;
                }
                print "\n";
                print "% - closing $name ------------------------\n";
                print STDERR "Closing $cf\n";
                close($input);
        }
}

[toc] | [prev] | [next] | [standalone]

#2971

> I feel in my bones that my postscript code should be
> better organized in this direction. Even a highly
> "modular" program like ibis presents a barrier to
> understanding by the simple fact that it's all stuffed
> into one file.

Very much agree that the one-file paradigm of PostScript hinders programming. My program — available via http://www.jdawiseman.com/placemat.html — is a text block 13k lines long. Lots of goodies in it, but who would ever find them?

As has been said elsewhere, PostScript is showing its age.

[toc] | [prev] | [next] | [standalone]

#2972

On 14/12/2016 6:42, luser droog wrote:
[...]
> Has anyone else come up with solutions for working with
> multi-file postscript "applications" and automatically
> producing amalgamated sources which are compatible with
> -dSAFER?

I never liked the "(file) run" idiom, except for quick hacks; I prefer
to load dependencies using either resources or running the files
sequentially, both of which avoid triggering -dSAFER.  Anyway, inlinig
dependencies is useful for distribution, so it's good that there are
ways to do that, too.

The easiest method is to just run each file in sequence:

   gs file1.ps file2.ps file3.ps main.ps

to create an amalgamated file, concatenate them:

   cat file1.ps file2.ps file3.ps main.ps > program.ps

The other method I know is to use resources. Loading them from the
filesystem is allowed by -dSAFER, and if you follow DSC conventions
you can inline them.

The venerable psutils suite (available on any GNU/Linux or *BSD
distribution) comes with two scripts that can help with that:
"includeres" inserts resources in place of "%%IncludeResource" DSC
comments; "extractres" does the opposite, skipping duplicates.

Running "includeres" a couple of times on the main file (to inline
resources inside inlined resources, etc), then "extractres" to
eliminate duplicates, then "includeres" again, you can get an
amalgamated source for distribution.

My 2c.
-- 

[toc] | [prev] | [next] | [standalone]

#2973

On 2016-12-14, luser droog <luser.droog@gmail.com> wrote:

> My experience with C programming is that it is often better
> to organize programs into multiple source files so related
> functions are together and the program pieces obey a 
> "module discipline" to interoperate, the sum of which 
> supports the needed functionality of the program.

Right.

> I feel in my bones that my postscript code should be
> better organized in this direction. Even a highly
> "modular" program like ibis presents a barrier to
> understanding by the simple fact that it's all stuffed
> into one file. Eg.
>
> http://codereview.stackexchange.com/questions/117320/document-formatting-markup-engine-in-postscript
>
> The code is "just a big wall of text" at first glance,
> and 90% of potential answerers don't have the energy to
> penetrate to the good stuff (hypothesis).
>
> But PostScript doesn't quite have the tools that a C
> programmer has with make and the pre-processor.
>
> We have 
> http://www.math.ubc.ca/~cass/graphics/manual/code/psinc
> but it needs modification to cope with indented (file)run
> commands.
>
> Has anyone else come up with solutions for working with
> multi-file postscript "applications" and automatically
> producing amalgamated sources which are compatible with
> -dSAFER?

Some years ago, I wrote a program that does what you're
describing : replace "(file) run" operations with the contents
of that file. It's a quick hack but it does what I need.

> What other "nice to have"s are there for building bigger
> things with PostScript?

There's another program like cat -n except that the number is
the file offset of the first character of the line. Helps locate
errors in your PostScript code (Ghostview/Ghostscript likes to
tell you at which /file offset/ errors occurred).

DSC requires far more boiler-plate than I can remember, let
alone type. I've been meaning to write a preprocessor to take
care of that for me.

-- 
André Majorel http://www.teaser.fr/~amajorel/
"Pauvreté n'est pas vice ! Parbleu ! Un vice est agréable."
  -- _Passe-temps_

[toc] | [prev] | [next] | [standalone]

#2974

On Thursday, December 15, 2016 at 4:20:07 PM UTC-6, Andre Majorel wrote:
> On 2016-12-14, luser droog <luser.droog@gmail.com> wrote:
> 
> > What other "nice to have"s are there for building bigger
> > things with PostScript?
> 
> There's another program like cat -n except that the number is
> the file offset of the first character of the line. Helps locate
> errors in your PostScript code (Ghostview/Ghostscript likes to
> tell you at which /file offset/ errors occurred).
> 

Xpost relieves that need by printing the stacks with pstack.
You can then read the top of the exec stack (bottom of the 
printout) to find where you error occurred.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.postscript

csiph-web