Re: Determining the length of "long"?

[Dominik Vogt <dominik.vogt@xxxxxx>]

On Fri, Sep 12, 2014 at 08:10:19PM +0200, Roman Neuhauser wrote:
> # dominik.vogt@xxxxxx / 2014-09-12 19:04:44 +0200:
> > > see getconf(1)[0] and unistd.h(0P)[1], specifically
> > > _POSIX_V6_ILP32_OFF32 and its brethren.
> > 
> > Ah great, that pointed exactly to what I need.
> 
> glad to be of help!  i would have brought these up earlier but you said
> 
> > inside a zsh script (without using external programs, of course).
> 
> which seemed to disqualify getconf(1)...  the clarification was also
> very subtle: :)

I know.  :-)  But I'm not immune to learning when a certain
approach causes more trouble than it saves you.  Actually I didn't
know a simple configuration program was around and wanted to avoid
using a monster like perl or gcc, because latency does matter.

> > the shell is absolutely the right tool here (combine several unix
> > command line programs in a pipe, filter their output and generate
> > a wm command from that)
>
> overall a good reminder of the need for precise problem statements. :)

Yes, but easy to say afterwards when one already know the solution. :)

What the script actually does is:

 * When started by fvwm it is passed an input and an output file
   descriptor to receive and send data from and to the wm core as
   numbers on the command line.  (The direction from fvwm to the
   script is disabled in that case).
 * Then, and that is the new feature, it determines automatically
   if binary longs are 32 bit or 64 bit and chooses a function
   to send strings to fvwm.  (The length of the string is sent as
   a binary long value which is hard coded to 160.)
 * Then it goes into an endless loop and sleeps for a while with
   zselect.  When it wakes up it

    * calls ps to determine the process that uses the most cpu
    * extracts the used memory percentage prom /proc/meminfo
    * uses strftime to get the current time and date in a certain
      format

   All this information is wrapped in wm commands and sent to the
   window manager core which forwards it to another module
   (FvwmButtons) which in turn updates the labels of some buttons
   to these strings.

As I always have a plethora of zshs running anyway, this approach
turned out to be very easy to implement, and does not use much
resources.  In earlier attempts to get this right there was a
noticeable lag, say, when playing kobodeluxe.

Eventually we'll make the fvwm module interface easier to use and
then it won't be necessary to determine details of the machine
architecture anymore.

Ciao

Dominik ^_^  ^_^

-- 

Dominik Vogt