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

Groups > comp.lang.forth > #31946 > unrolled thread

Graphics wordset primitive semantics survey - filled/stroked

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

Contents

  Graphics wordset primitive semantics survey - filled/stroked Roger Levy <roger.levy@gmail.com> - 2014-06-27 08:24 -0700
    Re: Graphics wordset primitive semantics survey - filled/stroked AKK <akk@nospam.org> - 2014-06-27 19:51 +0200
      Re: Graphics wordset primitive semantics survey - filled/stroked Roger Levy <roger.levy@gmail.com> - 2014-06-27 08:55 -0700
    Re: Graphics wordset primitive semantics survey - filled/stroked Roger Levy <roger.levy@gmail.com> - 2014-06-27 09:02 -0700
    Re: Graphics wordset primitive semantics survey - filled/stroked bruce.mcfarling@gmail.com - 2014-06-27 16:02 -0700
      Re: Graphics wordset primitive semantics survey - filled/stroked Roger Levy <roger.levy@gmail.com> - 2014-06-27 16:54 -0700
        Re: Graphics wordset primitive semantics survey - filled/stroked bruce.mcfarling@gmail.com - 2014-06-27 17:44 -0700
          Re: Graphics wordset primitive semantics survey - filled/stroked Roger Levy <roger.levy@gmail.com> - 2014-06-27 19:30 -0700
            Re: Graphics wordset primitive semantics survey - filled/stroked bruce.mcfarling@gmail.com - 2014-06-27 22:42 -0700
              Re: Graphics wordset primitive semantics survey - filled/stroked albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-06-28 11:50 +0000
    Re: Graphics wordset primitive semantics survey - filled/stroked "Elizabeth D. Rather" <erather@forth.com> - 2014-06-27 14:51 -1000
      Re: Graphics wordset primitive semantics survey - filled/stroked Roger Levy <roger.levy@gmail.com> - 2014-06-27 19:55 -0700
        Re: Graphics wordset primitive semantics survey - filled/stroked "Elizabeth D. Rather" <erather@forth.com> - 2014-06-27 17:23 -1000
          Re: Graphics wordset primitive semantics survey - filled/stroked Roger Levy <roger.levy@gmail.com> - 2014-06-27 22:12 -0700
            Re: Graphics wordset primitive semantics survey - filled/stroked "Elizabeth D. Rather" <erather@forth.com> - 2014-06-27 21:16 -1000
        Re: Graphics wordset primitive semantics survey - filled/stroked bruce.mcfarling@gmail.com - 2014-06-27 23:17 -0700
        Re: Graphics wordset primitive semantics survey - filled/stroked albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-06-28 11:58 +0000
    Re: Graphics wordset primitive semantics survey - filled/stroked Paul Rubin <no.email@nospam.invalid> - 2014-06-28 11:54 -0700
    Re: Graphics wordset primitive semantics survey - filled/stroked "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-06-28 15:00 -0400
      Re: Graphics wordset primitive semantics survey - filled/stroked BruceMcF <agila61@netscape.net> - 2014-06-28 12:59 -0700

#31946 — Graphics wordset primitive semantics survey - filled/stroked

I'm working on a component for drawing graphics primitives, called PencilBox.

This is a survey to find out about opinions regarding the semantics of drawing filled and stroked primitives.

A)
: filled ( -- )
0 0 at   filled   100 200 draw-box     
\ if FILLED is omitted, primitives are drawn stroked.
0 0 at            100 200 draw-box


B)
0 0 at            100 200 draw-box
0 0 at            100 200 draw-boxf


C)
0 0 at            100 200 draw-box
0 0 at            100 200 draw-box-filled


D)
0 0 at            100 200 draw-box-stroked
0 0 at            100 200 draw-box-filled

[toc] | [next] | [standalone]

#31951

Am 27.06.2014 17:24, schrieb Roger Levy:
> I'm working on a component for drawing graphics primitives, called PencilBox.
>
> This is a survey to find out about opinions regarding the semantics of drawing filled and stroked primitives.
>
> A)
> : filled ( -- )
> 0 0 at   filled   100 200 draw-box
> \ if FILLED is omitted, primitives are drawn stroked.
> 0 0 at            100 200 draw-box
>
>
> B)
> 0 0 at            100 200 draw-box
> 0 0 at            100 200 draw-boxf
>
>
> C)
> 0 0 at            100 200 draw-box
> 0 0 at            100 200 draw-box-filled
>
>
> D)
> 0 0 at            100 200 draw-box-stroked
> 0 0 at            100 200 draw-box-filled
>

You asked for opinions!  ;-)

A) barely usable for embedded systems
B) for fat systems: better use OS functions or libraries
C) remember turtle graphics?

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

#31953

Incoherent, nonsensical, instigative, unconstructive response.  Your feedback is discarded.  ;)

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

#31955

Disclaimer: PencilBox targets desktop OS's, and platforms that Allegro 5 can target. http://alleg.sourceforge.net/download.html

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

#31976

On Friday, June 27, 2014 11:24:09 AM UTC-4, Roger Levy wrote:
> I'm working on a component for drawing graphics primitives, called PencilBox.

> This is a survey to find out about opinions regarding the semantics of drawing filled and stroked primitives.

> A)
> : filled ( -- )
> 0 0 at   filled   100 200 draw-box     
> \ if FILLED is omitted, primitives are drawn stroked.
 
> 0 0 at            100 200 draw-box

> B)
> 0 0 at            100 200 draw-box
> 0 0 at            100 200 draw-boxf
> 
> C)
> 0 0 at            100 200 draw-box
> 0 0 at            100 200 draw-box-filled
> 
> D)
> 0 0 at            100 200 draw-box-stroked
> 0 0 at            100 200 draw-box-filled

For primitives, I'd rather

\ draw-box ( pt1 pt2 -- )
\ draw-box-styled ( pt1 pt2 style -- )

... since I'd rather do:

Box: MyBox
0 0 100 200 MyBox box!
   or
0 0 MyBox pt1!
100 200 MyBox pt2 !

filled-style MyBox style!
   or
stroked-style MyBox style!

MyBox DrawABox

: DrawABox ( box-id -- )
   DUP >R box@ R> style@ ?DUP IF draw-box-styled ELSE draw-box THEN ;

... and:

\ draw-box ( pt1 pt2 -- )
\ draw-box-styled ( pt1 pt2 style-id -- )

... supports that style just fine.

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

#31978

> For primitives, I'd rather
> 
> 
> 
> \ draw-box ( pt1 pt2 -- )
> 
> \ draw-box-styled ( pt1 pt2 style -- )
> 
> 
> 
> ... since I'd rather do:
> 
> 
> 
> Box: MyBox
> 
> 0 0 100 200 MyBox box!
> 
>    or
> 
> 0 0 MyBox pt1!
> 
> 100 200 MyBox pt2 !
> 
> 
> 
> filled-style MyBox style!
> 
>    or
> 
> stroked-style MyBox style!
> 
> 
> 
> MyBox DrawABox
> 
> 
> 
> : DrawABox ( box-id -- )
> 
>    DUP >R box@ R> style@ ?DUP IF draw-box-styled ELSE draw-box THEN ;
> 
> 
> 
> ... and:
> 
> 
> 
> \ draw-box ( pt1 pt2 -- )
> 
> \ draw-box-styled ( pt1 pt2 style-id -- )
> 
> 
> 
> ... supports that style just fine.


your practice of using dedicated fetchers and setters is really interesting.  in my system i need to remember what the type of everything is and i just realized it can be both distracting to remember and hard to read.  my code is littered with >field's and @'s and i have been thinking about this problem lately.

i don't know about having to pass points.  this requires allocation of points if you want to do a calculation on points just for drawing.  how would your code look to handle that situation?

also the turtle paradigm e.g. AT , AT> and +AT is incredibly convenient for drawing grids, tilemaps, arrays of things, text, polygons etc.  so i'm still leaning on that side.

styled is a good idea, allows the option of the style parameter being a constant or an object.

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

#31981

On Friday, June 27, 2014 7:54:37 PM UTC-4, Roger Levy wrote:
> your practice of using dedicated fetchers and setters is really interesting.  in my system i need to remember what the type of everything is and i just realized it can be both distracting to remember and hard to read.  my code is littered with >field's and @'s and i have been thinking about this problem lately.

With Mini-OOF I'd just call them my@ and my! as methods of the object but if not using objects, its convenient to encapsulate that.

> i don't know about having to pass points.  this requires allocation of points if you want to do a calculation on points just for drawing.  how would your code look to handle that situation?

When the stack says ( pt1 ) that's a stack comment for a point as a pair of cells for X-Y position. Its ( pt1 ) in case there's a situation where resolution is higher than cell range and a point is three or four cells.

> also the turtle paradigm e.g. AT , AT> and +AT is incredibly convenient for drawing grids, tilemaps, arrays of things, text, polygons etc.  so i'm still leaning on that side.

Yes, but the graphic primitives doesn't have to be turtled to use turtle graphics ~ if the graphics primitives word on a clean set of points on the stack, a turtle operation can be
   \ draw box with a corner at the current point & a corner at ( pt ) 
   \ making ( pt ) the current point
   : BoxDraw ( pt box-id -- )
      >R 2DUP AT@ R> draw-box AT! ;

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

#31984

 
> Yes, but the graphic primitives doesn't have to be turtled to use turtle graphics ~ if the graphics primitives word on a clean set of points on the stack, a turtle operation can be
> 
>    \ draw box with a corner at the current point & a corner at ( pt ) 
> 
>    \ making ( pt ) the current point
> 
>    : BoxDraw ( pt box-id -- )
> 
>       >R 2DUP AT@ R> draw-box AT! ;

This is that turtle thing.  It's built on Allegro, where the primitives are like this.

https://www.allegro.cc/manual/5/al_draw_rectangle

void al_draw_rectangle(float x1, float y1, float x2, float y2, ALLEGRO_COLOR color, float thickness)

If people want to directly use the Allegro bindings they can do that.  I'm trying to simplify it in order to rapidly build interfaces.

I can't say I can begin to get my head around a stack comment that isn't one cell per word!  Yet that works for you?

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

#31990

On Friday, June 27, 2014 10:30:57 PM UTC-4, Roger Levy wrote:
> I can't say I can begin to get my head around a stack comment that isn't one cell per word!  Yet that works for you?

Most often with ( ca u ) stack text references as ( str )

I reckon most people comment doubles as individual items, eg:
   UM+ ( u1 u2 -- ud1 )
... would be understood by a lot of people as not changing the stack depth, but, even though its a 2->1 operation, since it consumes two single celled unsigned inputs with a double cell unsigned result.

Different people have different preferences for how they comment significantly paired cells ~ for me, anytime I use a stack notation that varies for Forth94 spec notation, I document it somewhere near the top of the file so I don't forget what I was thinking if I see it again a few years later.

But I wouldn't set forward anything I write in Forth as a model, I'm just a duffer who uses Forth for some things because Forth and awk are languages I can bang away on getting a small part at a time right until I get the result I want.

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

#31995

In article <70b30cee-f6d3-4057-9cbc-bb200cb49d96@googlegroups.com>,
 <bruce.mcfarling@gmail.com> wrote:
>On Friday, June 27, 2014 10:30:57 PM UTC-4, Roger Levy wrote:
>> I can't say I can begin to get my head around a stack comment that
>isn't one cell per word!  Yet that works for you?
>
>Most often with ( ca u ) stack text references as ( str )

I use sc (string constant) with the implication that the word
doesn't change the area ca[0:u-1] , so it could be in ROM.

Groetjes Albert
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

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

#31982

On 6/27/14 5:24 AM, Roger Levy wrote:
> I'm working on a component for drawing graphics primitives, called PencilBox.
> 
> This is a survey to find out about opinions regarding the semantics of drawing filled and stroked primitives.
...

We had a very extensive graphics package in polyFORTH. It defined
"world" and "screen" coordinates, several vector arithmetic words,
drawing words, etc. Here's a summary (2D):

* "Vectors" are y, x pairs. X is on top, as it usually changes fastest.

* Vector arithmetic included V+ and V- (add/subtract 2 vectors) and V*/
(scale a vector by a ratio of scalers).

* The vector CP contained the "current position". By convention, 0,0 in
screen coordinates was the upper left corner.

* You move the cursor using DRAW ( y x ) which moves the cursor relative
to CP. Higher-level words included +DRAW ( dy dx in screen coordinates)
and *DRAW ( dy dx in world coordinates)

* Mode words controlled whether DRAW would make a line or just move the
cursor invisibly. These included OFF (no line) or ON (a line, which
could be controlled by current styles and colors). DRAW itself was a
vectored word, set by mode words such as SOLID, DASHED, etc.

* Standard shapes included RECTANGLE ( dy dx ), CIRCLE ( radius), and
others.

* PAINT ( y x ) filled the space surrounding y,x until pixels were
encountered of a different color, according to the "current color".

So, to draw a red rectangle outlined in white, you could say:

10 20 OFF DRAW (invisibly position the cursor)
100 150 WHITE RECTANGLE
15 25 RED PAINT

All the "mode" words (OFF, ON, WHITE, etc.) stay set until changed.

Overall, the combination of modes and action words is a lot more
manageable than having different words like draw-box, draw-box-filled,
etc. As a design strategy, I'd suggest starting by outlining all the
capabilities you want, and then designing the whole package top-down,
rather than starting with the low-level words.

Cheers,
Elizabeth

-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

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

#31987

> We had a very extensive graphics package in polyFORTH. 

Is a copy of it hosted somewhere?  I'd like to be able to look at the source.

> * "Vectors" are y, x pairs. X is on top, as it usually changes fastest.
> * Vector arithmetic included V+ and V- (add/subtract 2 vectors) and V*/

I have something like this, just in X Y order.   My convention is currently using the number of coordinates.  So 2+ doesn't mean 2 + it means your V+.  Did polyFORTH also handle 3D coordinates?

> * You move the cursor using DRAW ( y x ) which moves the cursor relative
> to CP. Higher-level words included +DRAW ( dy dx in screen coordinates)
> and *DRAW ( dy dx in world coordinates)

DRAW is currently taken in my system.  So maybe it would be LINETO or something.  (Speaking of taken words, this leads me to another question.)  

Since I'm basing it on a library that is basically a buffer between me and the GPU, I don't have total freedom.  Stuff like rectangles and ovals are batched operations, basically done with vertex buffers that get placed or have already been placed in the GPU's memory (and in optimized C) so that they can be fast.  The fewer calls I make, the more efficient the graphics.  So drawing lots of lines would be unfavorable.  Unless I basically re-built what Allegro does.  Which I have attempted before and pretty much tossed out because it was way more code than I wanted to maintain.

I know ... this is one of the downsides of using external libraries, besides being a consequence of how modern GPU's work.  My hands are somewhat tied.  (Also if anybody says why don't you just use software graphics it's much better etc, I will kill you on the spot. ;)

> * Mode words controlled whether DRAW would make a line or just move the
> cursor invisibly. These included OFF (no line) or ON (a line, which
> could be controlled by current styles and colors). DRAW itself was a
> vectored word, set by mode words such as SOLID, DASHED, etc.

Nice!  That's the way to do it! 

My burning question is.. ON ? OFF ?  Was this all in a vocab?  Or was ON and OFF not a thing yet?  I'd think that redefining these would make it tricky for the user.

> Overall, the combination of modes and action words is a lot more
> manageable than having different words like draw-box, draw-box-filled,
> etc. As a design strategy, I'd suggest starting by outlining all the
> capabilities you want, and then designing the whole package top-down,
> rather than starting with the low-level words.

You are quite right and I'll take this into account.  I'm in a bit of trouble because part of me wants to also revamp the lexicon that makes up the code that would be using these words a lot - my OOP flavor and game object definitions.  Bit of a chicken and egg problem.  

Part of me wants to wipe the slate clean and do things again from the top down as it should be, armed with way more knowledge than I have before.  My Glypher system was modeled after ColorForth and wouldn't you know it I had almost no idea what to do with it when it was "ready".  This is what happens when you don't have a clear goal.  

I really need to know how you were able to make the lexicon so clean and simple in a potentially complex application domain.  Does it become a kind of design constraint?  E.G. since graphics words are in a vocab, you must segregate your app into "display output code", and "everything else".  Alternatively you'd be ALSO'ing and PREVIOUS'ing all over the place.  Assuming they were in a vocab.

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

#31988

On 6/27/14 4:55 PM, Roger Levy wrote:
>> We had a very extensive graphics package in polyFORTH.
> 
> Is a copy of it hosted somewhere?  I'd like to be able to look at the source.

Not at this time. We think about doing that sometimes, but it's all in
blocks, and would require some conversion to be readable in files.

>> * "Vectors" are y, x pairs. X is on top, as it usually changes fastest.
>> * Vector arithmetic included V+ and V- (add/subtract 2 vectors) and V*/
> 
> I have something like this, just in X Y order.   My convention is currently using the number of coordinates.  So 2+ doesn't mean 2 + it means your V+.  Did polyFORTH also handle 3D coordinates?

We have done both 2D and 3D graphics, but not in the same application.
The standard package is 2D, and we modified it for the app that needed 3D.

>> * You move the cursor using DRAW ( y x ) which moves the cursor relative
>> to CP. Higher-level words included +DRAW ( dy dx in screen coordinates)
>> and *DRAW ( dy dx in world coordinates)
> 
> DRAW is currently taken in my system.  So maybe it would be LINETO or something.  (Speaking of taken words, this leads me to another question.)

Well, I'd be inclined to use LINE, being biased toward English words. :-)


> Since I'm basing it on a library that is basically a buffer between me and the GPU, I don't have total freedom.  Stuff like rectangles and ovals are batched operations, basically done with vertex buffers that get placed or have already been placed in the GPU's memory (and in optimized C) so that they can be fast.  The fewer calls I make, the more efficient the graphics.  So drawing lots of lines would be unfavorable.  Unless I basically re-built what Allegro does.  Which I have attempted before and pretty much tossed out because it was way more code than I wanted to maintain.
> 
> I know ... this is one of the downsides of using external libraries, besides being a consequence of how modern GPU's work.  My hands are somewhat tied.  (Also if anybody says why don't you just use software graphics it's much better etc, I will kill you on the spot. ;)

Yes, if you're using an external library that's going to heavily affect
your design. It's inevitable.


>> * Mode words controlled whether DRAW would make a line or just move the
>> cursor invisibly. These included OFF (no line) or ON (a line, which
>> could be controlled by current styles and colors). DRAW itself was a
>> vectored word, set by mode words such as SOLID, DASHED, etc.
> 
> Nice!  That's the way to do it!
> 
> My burning question is.. ON ? OFF ?  Was this all in a vocab?  Or was ON and OFF not a thing yet?  I'd think that redefining these would make it tricky for the user.

The style at FORTH, Inc. is really not to use a whole lot of
vocabularies and not to worry a lot about renamings. The compiler gives
a message if there's a renaming, and it's easy to look and see if it's a
dangerous conflict or, in the more normal case, if the word is being
used in a local context in a way that won't have a practical effect. For
example, in the section of the program that controls some equipment,
there might be ON and OFF words controlling the gear, but that's no
where near the graphics package and the code that's drawing the pretty
pictures. If there appear to be real conflicts, one can always think of
different words or use a vocabulary.

>> Overall, the combination of modes and action words is a lot more
>> manageable than having different words like draw-box, draw-box-filled,
>> etc. As a design strategy, I'd suggest starting by outlining all the
>> capabilities you want, and then designing the whole package top-down,
>> rather than starting with the low-level words.
> 
> You are quite right and I'll take this into account.  I'm in a bit of trouble because part of me wants to also revamp the lexicon that makes up the code that would be using these words a lot - my OOP flavor and game object definitions.  Bit of a chicken and egg problem.
> 
> Part of me wants to wipe the slate clean and do things again from the top down as it should be, armed with way more knowledge than I have before.  My Glypher system was modeled after ColorForth and wouldn't you know it I had almost no idea what to do with it when it was "ready".  This is what happens when you don't have a clear goal.
> 
> I really need to know how you were able to make the lexicon so clean and simple in a potentially complex application domain.  Does it become a kind of design constraint?  E.G. since graphics words are in a vocab, you must segregate your app into "display output code", and "everything else".  Alternatively you'd be ALSO'ing and PREVIOUS'ing all over the place.  Assuming they were in a vocab.

Yes, vocabularies are a mixed blessing. That's why we don't use them
unless we have an actual conflict for which that's the most practical
remedy.

Cheers,
Elizabeth

-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

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

#31989

> Not at this time. We think about doing that sometimes, but it's all in
> blocks, and would require some conversion to be readable in files.

I'll do it for you.

> > My burning question is.. ON ? OFF ?  Was this all in a vocab?  Or was ON and OFF not a thing yet?  I'd think that redefining these would make it tricky for the user.
> 
> 
> The style at FORTH, Inc. is really not to use a whole lot of
> vocabularies and not to worry a lot about renamings. The compiler gives
> a message if there's a renaming, and it's easy to look and see if it's a
> dangerous conflict or, in the more normal case, if the word is being
> used in a local context in a way that won't have a practical effect. For
> example, in the section of the program that controls some equipment,
> there might be ON and OFF words controlling the gear, but that's no
> where near the graphics package and the code that's drawing the pretty
> pictures. If there appear to be real conflicts, one can always think of 
> different words or use a vocabulary.

I've sort of taken this stance when it comes to phases of an app.   Knowing that lexicons can be tested separately gives you some freedom in naming.  

The holistic approach and the modular approach come head-to-head here.  I want to make the code for a game as simple as possible, so my "game engine" isn't even fully a separate thing yet, if it ever will be.  The stuff on the bottom is a bunch of components that depend on a couple base components, to make up a big lexicon that I like to assume is there.  

But if I tell someone for instance that I have a graphics wordset, the first thing they want to know is how robust and general-purpose it is.  When you redefine words, like for example the way you did with ON and OFF, (which of course would be nice to be able to do with peace of mind), the answer is complicated.  You say, well I designed it for this specific purpose and it has to be loaded at a specific place in the app, and will likely have to be modified if brought into other applications (it's not "shared"), but doing that isn't a big deal *if you know what you are going to do with it*. It may even need 2 versions resident if you're mixing 2D and 3D, and you have to segregate all 2D and 3D code.  Who would even be able to remember all that?  So you end up not sharing this thing.

This way of looking at the development of an app makes the heads of most people, and especially artists, explode.  They want all the buttons and they want them labeled.  Heck, it makes my head explode.  For one, if you build stuff on top of Graphics2D and then change a bunch of semantics in Graphics2DPlus, the old stuff must also be modified.  It's a cascade effect of incompatibility, but people want more reuse, so things Must Be Unified.  

See Unity3D and Haxe/OpenFL, two strategies for the same goal done in different ways, and both ridiculously complex.  But they do Everything You Could Want.  It's just clunky and verbose and complicated.  Results are mixed.

Getting back to the way you guys did things in the 80's.  For a thing to have an identity but no fixed form - this is the kind of thing that scares people away like garlic for vampires.  And yet they come in contact with it every day, just not in code - nature, people, their very reality.  People want API's to be like Plato's essential forms.  A function in a library must have precisely consistent semantics across projects, and lots of people must be able to share code built on top of that.  Versioning is critical.

I don't really know where all that was going.  It's late and I failed to reach a conclusion.

> Yes, vocabularies are a mixed blessing. That's why we don't use them
> unless we have an actual conflict for which that's the most practical
> remedy.

Yes.  That makes sense.

People look to prescription in an attempt to cut down on the things they must think about. 

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

#31993

On 6/27/14 7:12 PM, Roger Levy wrote:
> 
>> Not at this time. We think about doing that sometimes, but it's all in
>> blocks, and would require some conversion to be readable in files.
> 
> I'll do it for you.
> 
>>> My burning question is.. ON ? OFF ?  Was this all in a vocab?  Or was ON and OFF not a thing yet?  I'd think that redefining these would make it tricky for the user.
>>
>>
>> The style at FORTH, Inc. is really not to use a whole lot of
>> vocabularies and not to worry a lot about renamings. The compiler gives
>> a message if there's a renaming, and it's easy to look and see if it's a
>> dangerous conflict or, in the more normal case, if the word is being
>> used in a local context in a way that won't have a practical effect. For
>> example, in the section of the program that controls some equipment,
>> there might be ON and OFF words controlling the gear, but that's no
>> where near the graphics package and the code that's drawing the pretty
>> pictures. If there appear to be real conflicts, one can always think of
>> different words or use a vocabulary.
> 
> I've sort of taken this stance when it comes to phases of an app.   Knowing that lexicons can be tested separately gives you some freedom in naming.
> 
> The holistic approach and the modular approach come head-to-head here.  I want to make the code for a game as simple as possible, so my "game engine" isn't even fully a separate thing yet, if it ever will be.  The stuff on the bottom is a bunch of components that depend on a couple base components, to make up a big lexicon that I like to assume is there.
> 
> But if I tell someone for instance that I have a graphics wordset, the first thing they want to know is how robust and general-purpose it is.  When you redefine words, like for example the way you did with ON and OFF, (which of course would be nice to be able to do with peace of mind), the answer is complicated.  You say, well I designed it for this specific purpose and it has to be loaded at a specific place in the app, and will likely have to be modified if brought into other applications (it's not "shared"), but doing that isn't a big deal *if you know what you are going to do with it*. It may even need 2 versions resident if you're mixing 2D and 3D, and you have to segregate all 2D and 3D code.  Who would even be able to remember all that?  So you end up not sharing this thing.

But the graphics wordset has nothing to do with the equipment controls,
which may not even be present in *this* application that uses graphics.
It's pretty self-contained, except for using lower-level words in the
system. The trick is to maintain your layers.

> This way of looking at the development of an app makes the heads of most people, and especially artists, explode.  They want all the buttons and they want them labeled.  Heck, it makes my head explode.  For one, if you build stuff on top of Graphics2D and then change a bunch of semantics in Graphics2DPlus, the old stuff must also be modified.  It's a cascade effect of incompatibility, but people want more reuse, so things Must Be Unified.

Well, Forth makes some peoples' heads explode. Maintain your layers as
internally consistently as possible.

> See Unity3D and Haxe/OpenFL, two strategies for the same goal done in different ways, and both ridiculously complex.  But they do Everything You Could Want.  It's just clunky and verbose and complicated.  Results are mixed.

Pick one and go with it. Don't try to do everything in the same program.

> Getting back to the way you guys did things in the 80's.  For a thing to have an identity but no fixed form - this is the kind of thing that scares people away like garlic for vampires.  And yet they come in contact with it every day, just not in code - nature, people, their very reality.  People want API's to be like Plato's essential forms.  A function in a library must have precisely consistent semantics across projects, and lots of people must be able to share code built on top of that.  Versioning is critical.

Not sure exactly what you mean here by "an identity but no fixed form".
I worked with several kinds of graphics terminsls, some image-processing
equipment, some plotters (remember plotters?) and other devices. The
drivers were all different at the bottom, of course, and there were some
details that were different, but the basics were all quite consistent.

> I don't really know where all that was going.  It's late and I failed to reach a conclusion.

Get a good night's sleep :-)

>> Yes, vocabularies are a mixed blessing. That's why we don't use them
>> unless we have an actual conflict for which that's the most practical
>> remedy.
> 
> Yes.  That makes sense.
> 
> People look to prescription in an attempt to cut down on the things they must think about.

Prescriptions are good, consistency is good, but I don't like black
boxes whose internals are untouchable. To make a black box that can do
anything you might ever want to do without change means it has to be
horrendously large and complicated, which creates its own set of
problems. I like a model that is simple, clean and logically designed,
that can be easily adapted to a particular situation.

Cheers,
Elizabeth

-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

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

#31992

On Friday, June 27, 2014 10:55:57 PM UTC-4, Roger Levy wrote:
> My burning question is.. ON ? OFF ?  Was this all in a vocab?  Or was ON and OFF not a thing yet?  I'd think that redefining these would make it tricky for the user.

In natural language we are used to the same word meaning different things in different contexts. If I say that Germany absolutely slaughtered Portugal in the World Cup, few people would inquire whether the police had been called to the scene of the crime.

If you see the words used in example with commentary saying what the words are doing, the difference between (implied-pen) ``OFF'' and ``Extra-Warnings OFF'' isn't really confusing. If the ``Extra-Warnings OFF'' will be inside the compiled code that is is more context-explicit, the name clash between ON and OFF may not matter.

And there's matters of taste. Some people would find ``FALSE Extra-Warnings !'' just as clear, after all, and prefer to reserve ON and OFF for application-specific operations.

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

#31996

In article <ffba5ebd-385e-4a26-8f52-42d1878ee348@googlegroups.com>,
Roger Levy  <roger.levy@gmail.com> wrote:
<SNIP>
>
>Part of me wants to wipe the slate clean and do things again from the
>top down as it should be, armed with way more knowledge than I have
>before.  My Glypher system was modeled after ColorForth and wouldn't you
>know it I had almost no idea what to do with it when it was "ready".
>This is what happens when you don't have a clear goal.
>
>I really need to know how you were able to make the lexicon so clean and
>simple in a potentially complex application domain.  Does it become a
>kind of design constraint?  E.G. since graphics words are in a vocab,
>you must segregate your app into "display output code", and "everything
>else".  Alternatively you'd be ALSO'ing and PREVIOUS'ing all over the
>place.  Assuming they were in a vocab.

Refactoring is the first line of attack. But it may fail
and according to the mythical man month a second system from scratch will
come out much better (but not the third system).

In my experience rewriting from scratch once you get everything straightened
out in your head is less work than you might expect.
Chuck Moore does it all the time. You save enormously in testing time.

Groetjes Albert
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

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

#32014

Roger Levy <roger.levy@gmail.com> writes:
> This is a survey to find out about opinions regarding the semantics of
> drawing filled and stroked primitives.

Something wrong with PostScript?

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

#32015

On Fri, 27 Jun 2014 11:24:09 -0400, Roger Levy <roger.levy@gmail.com>  
wrote:

> I'm working on a component for drawing graphics primitives, called  
> PencilBox.
>
> This is a survey to find out about opinions regarding the semantics of  
> drawing filled and stroked primitives.
>
> A)
> : filled ( -- )
> 0 0 at   filled   100 200 draw-box
> \ if FILLED is omitted, primitives are drawn stroked.
> 0 0 at            100 200 draw-box
>
>
> B)
> 0 0 at            100 200 draw-box
> 0 0 at            100 200 draw-boxf
>
>
> C)
> 0 0 at            100 200 draw-box
> 0 0 at            100 200 draw-box-filled
>
>
> D)
> 0 0 at            100 200 draw-box-stroked
> 0 0 at            100 200 draw-box-filled

Well, first, I'm not a "real" Forth programmer, but I don't like
the "at".  I'd like all four numbers together, at once, and an
ability to update some of them later.

Second, did you specify if "100 200" was a set of two points,
or a set of two offsets, e.g., width, height?

I'd rather that "0 0" be a point and "100 200" be lengths relative
 from that point.  The reason is so that the initial corner of the
box can change without having to update a second set of points.
I.e., by having "100 200" be lengths, not another set of corner
points, you can move around a fixed size box by updating a single
point, not two points.

E.g., for a 100x200 box with origin at 10,10 which form is it?

10 10 at    110 210 draw-box  \ 110 210 are a corner point
10 10 at    100 200 draw-box  \ 100 200 offsets from 10 10


Rod Pemberton

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

#32018

On Saturday, June 28, 2014 3:00:05 PM UTC-4, Rod Pemberton wrote:
> I'd rather that "0 0" be a point and "100 200" be lengths relative 
> from that point.  The reason is so that the initial corner of the
> box can change without having to update a second set of points.

Though with turtle graphics and a simple primitive, you can do the same thing ...

AT@ 100 200 +AT AT@ draw-box

... so the simple ( y1 x1 y2 x2 -- ) graphics primitive would support turtle graphic oriented draw box operations that are either absolute or relative.

: DrawABox ( pt -- ) AT@ 2SWAP 2DUP AT! draw-box ;
: +DrawABox ( +pt -- ) AT@ 2SWAP +AT! AT@ draw-box ;

[toc] | [prev] | [standalone]

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

csiph-web