«

On Dec 20, 10:27*am, ImpalerCore <jadil...@gmail.com> wrote:
> On Dec 19, 6:44*am, luserXtrog <mijo...@yahoo.com> wrote:
>
>
>
> > I feel I need a fresh perspective (or many, ideally)
> > on my program. It's grown to where I can't quite keep
> > it all in my head and making new additions has become
> > a game of "how did I do this elsewhere?"
>
> > A zip file containing c and postscript source and a makefile
> > are available at:http://code.google.com/p/xpost/downloads/list
> <snip>
>
> I think you're getting to the point where you're going to need a
> documentation system. *First off, browsing for functionality in a
> browser is much easier than grepping files. *You forget things like
> order of arguments, semantics for elements in a struct, or the meaning
> of return values. *I recommend spending some time learning and
> creating some documentation in Doxygen (or similar) to get a feel for
> what's possible. *Without a good system of documentation, you will
> likely spend lots of additional time rereading code to learn how to
> use the functions you've created months ago. *

Agreed. One of my dreams for the project is to make it a self-
documenting
literate program (the uber-quine) producing a pdf book describing
itself.
But I really should learn some sort of documenting system now to get
the
whole process started.

>Here's an example of
> some doxygenated comments from my list library.
>
<snip very nice example for space>

> In my documentation, I describe the parameters, return values,
> semantic details if needed, and provide an example that demonstrates
> its usage with expected results.

I've tried to avoid the need for this level of detail in comments
by building, as directly as I could, a mapping between the published
standard and the semantics of the program. Hence parameters and return
values for the O* functions are directly from the Adobe book.
But, of course, that has the drawback that anyone who doesn't own
the book can't make as much sense of the program.

Point taken. Each function should have some description.

> The drawback of this is that it is a *lot* more work, especially if
> you want to create (non-boring) examples that demonstrate something
> interesting about the semantics of the function. *The payoff is that
> you can go back at a later time and grok the function much easier than
> having to reread code you wrote months or years ago. *And if you make
> the time to go through the documentation, any semantic quirks that pop
> up (like NULL pointers) will be addressed in the documentation, and
> hopefully won't bite you again or someone that follows you. *Again let
> me re-emphasize, doing what I do is a *lot* of extra work, and may not
> be compatible in some work environments.
>
> Second, I think you may want to look at partitioning functionality
> into a couple of libraries. *Library is the basic component of reuse
> in C, and if or when you do something new, the work you put into the
> functionality for the postscript parser will be easier to apply to
> something else if pertinent pieces are nicely encapsulated in a
> library.

Indeed. I've been trying to build up the graphics functionality as
a library. It's a lot of work just to track down the sources (texts
and journals from 70s-80s), let alone understanding and implementing
the algorithms. (I've lost count of how many times I've read about
the Bresenham line drawing algorithm; I'm still not sure I "get it.")

As for this project, I'm having some trouble envisioning which pieces
should be partitioned off. They all seem so interrelated! The parser
(just a scanner, really; I think there's one point where it recurses
and that's only for scanning literal procedures) has to know about
the object types and how to create each of them.

I think the virtual memory store for composite objects (dictionaries,
arrays,
and strings) might be the best thing to break off first. I've just
discovered
in another thread that my simplistic implementation (with each save-
level
as an anonymous mmap) doesn't duplicate a legacy quirk of the original
Adobe implementation (restoring an earlier save-level doesn't rollback
string contents) which all other interpreters have followed.

So I need to modify the implentation of this part without disturbing
the
rest of the program. "Modularity to the rescue?"

> That's all I got for now.

Much obliged.

On Dec 19, 5:44*am, luserXtrog <mijo...@yahoo.com> wrote:
> I feel I need a fresh perspective (or many, ideally)
> on my program. It's grown to where I can't quite keep
> it all in my head and making new additions has become
> a game of "how did I do this elsewhere?"
>
> A zip file containing c and postscript source and a makefile
> are available at:http://code.google.com/p/xpost/downloads/list
>
> I chose a BSD licence because I don't know any better.
>
> There are probably too few comments.
> So even comments like "this part needs more comments"
> are desirable.
>
> And in more than a few places I'm certainly guilty
> of attempting to be cute and/or clever. But to all
> appearances, it all works somehow.
>
> A little toc:
> arr.c arr.h * *array operators (functions)
> bool.c bool.h * boolean operators
> color.c color.h * color operators
> control.c control.h * control operators
> dic.c dic.h * dictionary operators
> err.c err.h * error handling (c-part)
> err.ps * error handling (ps-part)
> file.c file.h * file operators
> global.c global.h * global variables (yes, I know. bad. sorry)
> * * * * * * all the stacks are here
> init.c init.h * *initialize (c-part)
> init.ps * *initialize (ps-part)

init.ps defines a procedure just before it begins executing
user statements that shows off its one trick. The code
suggest you can run it two ways, but 'fill' isn't implemented
yet in this version so only 'stroke' works:

634(1)02:44 AMpost 0> xpost
initgraphics...found a TrueColor class visual at default depth.
drawWindow()
Xpost Version 0c
PS>{stroke}wheel

I probably should've turned off the 'printf's before uploading.
The text just indicates how the lines are being batched up for
X11.

> lim.h * implementation limits
> main.c * *main function and central loop
> math.c math.h * math operators
> matrix.c matrix.h * *matrix operators
> obj.h * *the object structure
> oper.c oper.h * the operator interface (function-pointer-objects)
> paint.c paint.h * just stroke
> path.c path.h * path construction (no curves)
> poly.c poly.h * *polymorphic operators
> squiggle.ps * *a doodle (no showpage)
> sta.c sta.h * stack manipulation operators
> str.c str.h * *string operators
> tok.c tok.h * the token operator (the lexical scanner)
> type.c type.h * type and attribute operators
> vm.c vm.h * virtual memory (mmap requires POSIX)
> x.c x.h * the X11 functions
>
> TIA

On Dec 19, 5:44*am, luserXtrog <mijo...@yahoo.com> wrote:
> I feel I need a fresh perspective (or many, ideally)
> on my program. It's grown to where I can't quite keep
> it all in my head and making new additions has become
> a game of "how did I do this elsewhere?"
>
> A zip file containing c and postscript source and a makefile
> are available at:http://code.google.com/p/xpost/downloads/list

I have uploaded a revised version which includes
commentary for all functions and at the tops of
all files. Should increase legibility.

> A little toc:
> arr.c arr.h * *array operators (functions)
> bool.c bool.h * boolean operators
> color.c color.h * color operators
> control.c control.h * control operators
> dic.c dic.h * dictionary operators
> err.c err.h * error handling (c-part)
> err.ps * error handling (ps-part)
> file.c file.h * file operators
> global.c global.h * global variables (yes, I know. bad. sorry)
> * * * * * * all the stacks are here
> init.c init.h * *initialize (c-part)
> init.ps * *initialize (ps-part)
> lim.h * implementation limits
> main.c * *main function and central loop
> math.c math.h * math operators
> matrix.c matrix.h * *matrix operators
> obj.h * *the object structure
> oper.c oper.h * the operator interface (function-pointer-objects)
> paint.c paint.h * just stroke
> path.c path.h * path construction (no curves)
> poly.c poly.h * *polymorphic operators
> squiggle.ps * *a doodle (no showpage)
> sta.c sta.h * stack manipulation operators
> str.c str.h * *string operators
> tok.c tok.h * the token operator (the lexical scanner)
> type.c type.h * type and attribute operators
> vm.c vm.h * virtual memory (mmap requires POSIX)
> x.c x.h * the X11 functions

I'm investigating using Cairo for the graphics.
That would eliminate 10 files.

Switching to cairo has dramatically accelerated my efforts.
As per suggestions, I have
- reduced the number of files (by consolidating the graphics)
- increased file sizes (by writing more functions)
- added comments for all operators (even those that don't exist)

http://code.google.com/p/xpost/downloads/list

Any advice or comments are greatly appreciated.

One question.
When including a header from a location not in the compiler
search path, is it better to pack the path into the #include
directive, thus

#include <cairo/cairo.h>

or as a command-line option via the makefile, thus

CFLAGS=-I/usr/include/cairo

?

["Followup-To:" header set to comp.lang.c.]

On Wed, 2010-12-29, luser- -droog wrote:
....
> One question.
> When including a header from a location not in the compiler
> search path, is it better to pack the path into the #include
> directive, thus
>
> #include <cairo/cairo.h>
>
> or as a command-line option via the makefile, thus
>
> CFLAGS=-I/usr/include/cairo
>
> ?

IMHO,

#include <cairo/cairo.h>

is the better one. It says the file is cairo/cairo.h, relative to some
base include path. One well-known such path is /usr/include/.

Alternatively, do what the cairo documentation says.

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

On Dec 29, 4:02*pm, Jorgen Grahn <grahn+n...@snipabacken.se> wrote:
> ["Followup-To:" header set to comp.lang.c.]
>
> On Wed, 2010-12-29, luser- -droog wrote:
>
> ...
>
> > One question.
> > When including a header from a location not in the compiler
> > search path, is it better to pack the path into the #include
> > directive, thus
>
> > #include <cairo/cairo.h>
>
> > or as a command-line option via the makefile, thus
>
> > CFLAGS=-I/usr/include/cairo
>
> > ?
>
> IMHO,
>
> #include <cairo/cairo.h>
>
> is the better one. It says the file is cairo/cairo.h, relative to some
> base include path. One well-known such path is /usr/include/.

Sadly, it doesn't work. cairo.h can't find its other files.

> Alternatively, do what the cairo documentation says.

Yeah. I saw all that pkg-config stuff at
http://cairographics.org/FAQ/ .
I'm not sure why, but I don't like it.
Probably misunderstanding masquerading as fear.

On Wed, 29 Dec 2010 16:13:33 -0500, luser- -droog <> wrote:

> Switching to cairo has dramatically accelerated my efforts.
> As per suggestions, I have
> - reduced the number of files (by consolidating the graphics)
> - increased file sizes (by writing more functions)
> - added comments for all operators (even those that don't exist)
>
> http://code.google.com/p/xpost/downloads/list
>
> Any advice or comments are greatly appreciated.
>
> One question.
> When including a header from a location not in the compiler
> search path, is it better to pack the path into the #include
> directive, thus
>
> #include <cairo/cairo.h>

Like Jorgen, I'd prefer the include line above -- but on the grounds that any human being reviewing the code learns at one glance where cairo.h is, and needn't go chasing through the makefile's CFLAGS options.

Cheers, -- tlvp

> or as a command-line option via the makefile, thus
>
> CFLAGS=-I/usr/include/cairo
>
> ?
>


--
Avant de repondre, jeter la poubelle, SVP

On Dec 20, 12:02*am, Gene <gene.ress...@gmail.com> wrote:
> On Dec 19, 6:44*am, luserXtrog <mijo...@yahoo.com> wrote:
>
>
>
>
>
> > I feel I need a fresh perspective (or many, ideally)
> > on my program. It's grown to where I can't quite keep
> > it all in my head and making new additions has become
> > a game of "how did I do this elsewhere?"
>
> > A zip file containing c and postscript source and a makefile
> > are available at:http://code.google.com/p/xpost/downloads/list
>
> > I chose a BSD licence because I don't know any better.
>
> > There are probably too few comments.
> > So even comments like "this part needs more comments"
> > are desirable.
>
> > And in more than a few places I'm certainly guilty
> > of attempting to be cute and/or clever. But to all
> > appearances, it all works somehow.
>
> I count a bit over 2,700 sloc. *It's typical for an inexperienced
> programmer to start losing control of a program at about this size if
> there's been no design work or scaffolding before coding. * If that's
> what's happened, you won't regain control. *Get a good book on data
> structures and another on software design. *Read them. Start over.
> Chalk this one up to a learning experience.

it'snot impossible to regain control. Refactorise madly. Though
personnally I'd do the redesign. Hopefully there will be lots of
utilities to salvage from the first design.

On Dec 20, 12:48*am, "BartC" <b...@freeuk.com> wrote:
> "Gene" <gene.ress...@gmail.com> wrote in message
>
> news:8c538e83-4c6b-4818-80ed-...
>
>
>
>
>
> > On Dec 19, 6:44 am, luserXtrog <mijo...@yahoo.com> wrote:
> >> I feel I need a fresh perspective (or many, ideally)
> >> on my program. It's grown to where I can't quite keep
> >> it all in my head and making new additions has become
> >> a game of "how did I do this elsewhere?"
>
> >> A zip file containing c and postscript source and a makefile
> >> are available at:http://code.google.com/p/xpost/downloads/list
>
> >> I chose a BSD licence because I don't know any better.
>
> >> There are probably too few comments.
> >> So even comments like "this part needs more comments"
> >> are desirable.
>
> >> And in more than a few places I'm certainly guilty
> >> of attempting to be cute and/or clever. But to all
> >> appearances, it all works somehow.
>
> > I count a bit over 2,700 sloc. *It's typical for an inexperienced
> > programmer to start losing control of a program at about this size if
> > there's been no design work or scaffolding before coding. * If that's
> > what's happened, you won't regain control. *Get a good book on data
> > structures and another on software design. *Read them. Start over.
> > Chalk this one up to a learning experience.
>
> I had a quick look. 2700 loc seems tiny for any sort of interpreter.

well certainly for a Postscript interpreter!

> My main criticism might be that it is split up into too many files,
> averaging just 100 lines per module and 23 lines per header file.
>
> I'm not surprised it's difficult to keep it all together. In fact I'd be
> tempted to put it all into one file.

sailing perilously close to my personnel limits to filesize. If he's
going to implement a complete Postscript interpreter I'd expect it to
get too large for a single file.

On Wed, 2010-12-29, luser- -droog wrote:
> On Dec 29, 4:02*pm, Jorgen Grahn <grahn+n...@snipabacken.se> wrote:
>> ["Followup-To:" header set to comp.lang.c.]
>>
>> On Wed, 2010-12-29, luser- -droog wrote:
>>
>> ...
>>
>> > One question.
>> > When including a header from a location not in the compiler
>> > search path, is it better to pack the path into the #include
>> > directive, thus
>>
>> > #include <cairo/cairo.h>
>>
>> > or as a command-line option via the makefile, thus
>>
>> > CFLAGS=-I/usr/include/cairo
>>
>> > ?
>>
>> IMHO,
>>
>> #include <cairo/cairo.h>
>>
>> is the better one. It says the file is cairo/cairo.h, relative to some
>> base include path. One well-known such path is /usr/include/.
>
> Sadly, it doesn't work. cairo.h can't find its other files.

*Checking on my own system, which has this "cairo" thing installed*

Yeah, /usr/include/cairo/cairo.h contains lines like

#include <cairo-features.h>
#include <cairo-deprecated.h>

It's very unclear to me why they chose to do it that way -- it would
have worked if they had written

#include "cairo-features.h"
#include "cairo-deprecated.h"

because that causes the search to include the directory where
<cairo/cairo.h> was found. Perhaps that's a gcc-ism, and they need to
support some compiler which doesn't do it like that? Most other
libraries on my system either use (a) the second form above, or
(b) the equivalent of #include <cairo/cairo-features.h>.

Anyway, then they're really not intending you to say <cairo/cairo.h> and you
cannot do it. It's an unfortunate choice IMHO to *both* make that
decision and install in a non-standard location (/usr/include/cairo/)
because that forces them to ...

>> Alternatively, do what the cairo documentation says.
>
> Yeah. I saw all that pkg-config stuff at
> http://cairographics.org/FAQ/ .
> I'm not sure why, but I don't like it.
> Probably misunderstanding masquerading as fear.

.... invent strange ways for your build system to find the right
compiler flags. That's what that pkg-config stuff is, nothing more.

% pkg-config --cflags --libs cairo
-D_REENTRANT -I/usr/include/cairo -I/usr/include/freetype2
-I/usr/include/directfb -I/usr/include/libpng12
-I/usr/include/pixman-1 -lcairo

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .