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

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

cvx before storing works in one place, but not in another

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

Contents

  cvx before storing works in one place, but not in another Cecil Westerhof <Cecil@decebal.nl> - 2014-08-06 19:58 +0200
    Re: cvx before storing works in one place, but not in another luser- -droog <mijoryx@yahoo.com> - 2014-08-06 22:01 -0700
      Re: cvx before storing works in one place, but not in another Cecil Westerhof <Cecil@decebal.nl> - 2014-08-07 14:45 +0200
        Re: cvx before storing works in one place, but not in another luser- -droog <mijoryx@yahoo.com> - 2014-08-14 01:15 -0700
    Re: cvx before storing works in one place, but not in another jdaw1 <jdawiseman@gmail.com> - 2014-08-10 07:41 -0700

#1952 — cvx before storing works in one place, but not in another

I had the following code:
    dup 5 eq {
        /borderPart (borderPart5) cvx def
    } {
        dup 4 eq {
            /borderPart (borderPart4) cvx def
        } {
            dup 3 eq {
                /borderPart (borderPart3) cvx def
            } {
                dup 2 eq {
                    /borderPart (borderPart2) cvx def
                } {
                    /borderPart (borderPart1) cvx def
                } ifelse
            } ifelse
        } ifelse
    } ifelse

Not very neat, so I made a kind of switch statement:
    /mydict 6 dict def
    mydict         1 (borderPart1) put
    mydict         2 (borderPart2) put
    mydict         3 (borderPart3) put
    mydict         4 (borderPart4) put
    mydict         5 (borderPart5) put
    mydict (default) (borderPart5) put
    dup mydict exch known {
        mydict exch get
    } {
        pop
        mydict (default) get
    } ifelse
    /borderPart exch def

Works fine, but there is a strange difference. The last statement can
not be:
    /borderPart exch cvx def

If I do that I get at the place the function is executed:
   Error: /stackunderflow in --exec-

Also strange, if I after
    /borderPart exch cvx def
do:
    /borderPart ==
this gives:
    /borderPart

Without the number.
What could be happening here?

It is not very important: I just do a cvx before the exec, but I am
just curious. ;-)

-- 
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof

[toc] | [next] | [standalone]

#1955

On Wednesday, August 6, 2014 12:58:49 PM UTC-5, Cecil Westerhof wrote:
> I had the following code:
> 
>     dup 5 eq {
>         /borderPart (borderPart5) cvx def
>     } {
>         dup 4 eq {
>             /borderPart (borderPart4) cvx def
>         } {
>             dup 3 eq {
>                 /borderPart (borderPart3) cvx def
>             } {
>                 dup 2 eq {
>                     /borderPart (borderPart2) cvx def
>                 } {
>                     /borderPart (borderPart1) cvx def
>                 } ifelse
>             } ifelse
>         } ifelse
>     } ifelse
> 
> Not very neat, so I made a kind of switch statement:
> 
>     /mydict 6 dict def
>     mydict         1 (borderPart1) put
>     mydict         2 (borderPart2) put
>     mydict         3 (borderPart3) put
>     mydict         4 (borderPart4) put
>     mydict         5 (borderPart5) put
>     mydict (default) (borderPart5) put
>     dup mydict exch known {
>         mydict exch get
>     } {
>         pop
>         mydict (default) get
>     } ifelse
>     /borderPart exch def
> 
> Works fine, but there is a strange difference. The last statement can
> not be:
>     /borderPart exch cvx def
> 
> If I do that I get at the place the function is executed:
>    Error: /stackunderflow in --exec-

That much makes sense. But you should be getting the same error 
with the original code if you're doing

    borderPart exec

If borderPart is defined as an executable string, then mentioning
the executable name `borderPart` will load and execute the string,
yielding an executable name borderPartN, and executing that as well.

I'd write your switch statement a little more concisely

  /mydict <<
    1 /borderPart1 cvx
    2 /borderPart2 cvx
    3 /borderPart3 cvx
    4 /borderPart4 cvx
    5 /borderPart5 cvx
    /default 1 index
  >> def
  mydict 1 index known not {pop /default} if
  mydict exch get
  /borderPart exch def

I think most of your strings would be better as names. 
When used as a dictionary key, a string is automatically
converted into a name anyway. So
  (default) 5 def
is functionally identical to
  /default cvx 5 def
but needlessly creates a string object in memory.

> Also strange, if I after
>     /borderPart exch cvx def
> do:
>     /borderPart ==
> this gives:
>     /borderPart
> 
> Without the number.
> What could be happening here?

Here you've created a literal name, so it does not automatically
load the associated value. If you were to drop the slash, it would
automatically load, and then execute if the resulting value is 
executable. So, to just view the "value", use the literal name and
an explicit `load`.

    /borderPart load ==

> It is not very important: I just do a cvx before the exec, but I am
> just curious. ;-)
> 

But for the overall task here, maybe it would be simpler to use strings.
Assuming an integer in the range 0..9 is on the stack,

    (borderPart?) dup dup length 1 sub % n str str i
    4 3 roll % str str i n
    (0) 0 get add % str str i n+chr('0')
    put % str
    cvx % executable-str

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

#1961

Op Thursday 7 Aug 2014 07:01 CEST schreef luser:

>> /mydict 6 dict def
>> mydict         1 (borderPart1) put
>> mydict         2 (borderPart2) put
>> mydict         3 (borderPart3) put
>> mydict         4 (borderPart4) put
>> mydict         5 (borderPart5) put
>> mydict (default) (borderPart5) put
>> dup mydict exch known {
>> mydict exch get
>> } {
>> pop
>> mydict (default) get
>> } ifelse
>> /borderPart exch def
>>
>> Works fine, but there is a strange difference. The last statement
>> can not be: /borderPart exch cvx def
>>
>> If I do that I get at the place the function is executed:
>> Error: /stackunderflow in --exec-
>
> That much makes sense. But you should be getting the same error 
> with the original code if you're doing
>
> borderPart exec
>
> If borderPart is defined as an executable string, then mentioning
> the executable name `borderPart` will load and execute the string,
> yielding an executable name borderPartN, and executing that as well.
>
> I'd write your switch statement a little more concisely
>
> /mydict <<
> 1 /borderPart1 cvx
> 2 /borderPart2 cvx
> 3 /borderPart3 cvx
> 4 /borderPart4 cvx
> 5 /borderPart5 cvx
> /default 1 index
>>> def
> mydict 1 index known not {pop /default} if
> mydict exch get
> /borderPart exch def

I went for:
    /mydict <<
        1        /borderPart1
        2        /borderPart2
        3        /borderPart3
        4        /borderPart4
        5        /borderPart5
        /default /BorderPart1
    >> def
    dup mydict exch known {
        mydict exch get
    } {
        pop
        mydict /default get
    } ifelse
    /borderPart exch def

Putting cvx behind the definitions went wrong. Also
    /default 1 index 
went wrong.

I look in it/the rest later.

Thanks for the info.

-- 
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof

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

#1972

On Thursday, August 7, 2014 7:45:42 AM UTC-5, Cecil Westerhof wrote:
> 
> I went for:
>     /mydict <<
>         1        /borderPart1
>         2        /borderPart2
>         3        /borderPart3
>         4        /borderPart4
>         5        /borderPart5
>         /default /BorderPart1
>     >> def
>     dup mydict exch known {
>         mydict exch get
>     } {
>         pop
>         mydict /default get
>     } ifelse
>     /borderPart exch def
> 

Looks good. I think the fiddly code could be a little nicer,
though. How about

     mydict exch 2 copy known not {
         pop /default
     } if get
     /borderPart exch def

? Both of your clauses do `get` as their last action.
So that factors-out straight-away. Then 2 copy makes
a "scratch pair" for `known` to consume, so if it is
known in the dict, it can fall straight through to 
the `get`. If `known not`, replace the key 
with /default, then fall through to the `get`.

> Putting cvx behind the definitions went wrong. Also
>     /default 1 index 
> went wrong.

`1 index` pushes a copy of thing just below the top of stack.
It's like the Forth OVER operator. It's often useful when 
duplicating elements in arrays and dicts. Read as: "ditto".
So, in my example it was setting default to the *last* item
in the list, /borderPart5, which matched the semantics in 
the first post. Now you're setting it to /borderPart1. 
Did the requirements change?

> 
> I look in it/the rest later.
> 
> Thanks for the info.

Toujours, mon frère.

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

#1970

I've had access problems with code before. From memory, it was something like {... null ...} into which I tried to put a replacement for the null. Exactly one of Distiller and GhostScript didn't like it, but both seem to be happy with the likes of [currenttransfer   /exec cvx   1   /exch cvx   /sub cvx  ...] cvx bind settransfer

[toc] | [prev] | [standalone]

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

csiph-web