Re: [9fans] output of ps(1) memory usage

Re: [9fans] output of ps(1) memory usage

[YAMANASHI Takeshi]

> > Is there an easy way to determine the amount of memory
> > really inuse (or physically mapped?) within a process?
>
> cat /proc/<pid>/segment.  The first number is the

Thank you, all.

I have mistakenly thought that the output of ps/segment
concerns about the virtual memory, not physically mapped.

Now that I understand the ps/segment output correctly,
I revise my question as follows:

Is there a way to determine the amount of swapped pages
of a process?  I just want to complete the equation,
	virutal memory usage of a process =
	  swapped or not paged in + physically mapped
--
YAMANASHI Takeshi

Re: [9fans] output of ps(1) memory usage

[Russ Cox]

/proc/pid/segment shows you virtual memory allocation,
not physical.  There is no way to find out which pages
in a process are swapped and which are not at a per-page
granularity.  Of course, if /dev/swap tells you nothing is
swapped out, then nothing is swapped out.  It is also hard
to tell what is not yet paged in.

You could walk around in the kernel's page tables,
but that's not portable and not very clean.

Russ

[9fans] alg to make a good colour palette for a graph

[George Michaelson]

totally non Plan9 question but people here oftentimes have nice simple algs
which work well across lots of contexts.

I need to make a set of <n> visually distinctive colours in rgb space such
that I can feed the rgb values into a tool (RRD) to graph with.

Microsloth picks colours for you. a very nasty muted set. Gnuplot repeats the
same palette of colours over and over again.

I read in the RRD list of a technique to map the <n> as equidistant points
distributed in HSV space, and then use them. But, no code.

N varies. Usually its less than 15. In those cases I think I can use an
Acronymic 'Richard Of York Gave Battle In Vain' selection. But for one case I
am looking at, I need 250+ reasonably distinctive colours.

I thought about just taking a 256colourmap, and randomizing it, and using the
entire palette that way. It should mean no two adjacent colours are very alike
which is fine for a stacked line chart.

Is there something simple and nice, which I can do in AWK? Something which
will go into the ff-space and pick good colour combos? The obvious things I
come up with make gray (for a stunningly obvious reason) It would be super
nice to have up to 25 or 30 colours which are all mutually equi-distant in
some sense.

clues? I've tried web browsing. its phenominal how few things seem remotely
relevant from keyword searches using colourspace, colourmap, palette, graph.

-George

Re: [9fans] alg to make a good colour palette for a graph

[Eric Grosse]

It depends on the monitor.  Take a look at
   http://plan9.bell-labs.com/cm/cs/doc/85/4-01.ps.gz
That solution (which used l2 optimization over a psychophysical
color difference metric) gave very good results, but is way too
complicated for awk.    You can run the computation once, build
a decent spline approximation to the hue curve, and use awk to
interpolate in the table, given <n>.   That's the approach of
   http://plan9.bell-labs.com/netlib/graphics/rainbow.c.gz

Eric

Re: [9fans] alg to make a good colour palette for a graph

[George Michaelson]

Many, many thanks. perfecto!

-George

Re: [9fans] alg to make a good colour palette for a graph

[Skip Tavakkolian]

> totally non Plan9 question but people here oftentimes have nice simple algs
> which work well across lots of contexts.

I agree. There is so much to be learned from people on this list,
just by observing/listening in.

On a somewhat related note, I wanted to share my pick for a new
book of algorithms; It is called "Hacker's Delight" by Henry S.
Warren Jr.

[9fans] Re: alg to make a good colour palette for a graph

[Jim Choate]

On Thu, 20 Feb 2003, Skip Tavakkolian wrote:

> On a somewhat related note, I wanted to share my pick for a new
> book of algorithms; It is called "Hacker's Delight" by Henry S.
> Warren Jr.

I agree, I got it a couple of months ago and have enjoyed it. Is most
useful for those working in assembly and compilers but it's also just a
good read (if you like didling bits ;).


 --
    ____________________________________________________________________

      We are all interested in the future for that is where you and I
      are going to spend the rest of our lives.

                              Criswell, "Plan 9 from Outer Space"

      ravage@ssz.com                            jchoate@open-forge.org
      www.ssz.com                               www.open-forge.org
    --------------------------------------------------------------------

[9fans] UTF-8 handling in non-plan9 app: help finding bug

[George Michaelson]

Not a plan9 bug, but I'd appreciate debug help. I am UTF-8 illiterate.

This From: address appears to render in my gui as 

	From: 'binary meant to be korean', <user@dom.ain>

Is this because the UTF-8 decoder has mapped a 16 byte char into ASCII which
ends with a comma, and the gui hasn't made this SMTP legal? Some people think
From: any crap you like <real@dom.ain> is ok, but 
From: "other crap" <real@dom> is clearly nicer, since you can probably quote 
the trailling ,

equally, the "," may not be there. it might be the UTF-8 decoder or something
else is broken.

so can one of you RUNIC wizards tell me if this is valid hypotheses? Is this
actually a bug their side, sending invalid RFC822/SMTP header? 

-george

	From:    =?UTF-8?B?7LKc66y07Zi4?= <cmh@nic.or.kr>
	To:      "George Michaelson" <ggm@apnic.net>

Re: [9fans] UTF-8 handling in non-plan9 app: help finding bug

[Russ Cox]

I sent myself a message with that From: line,
and saw a From with three Unicode characters:
cc9c, bb34, and d638.  No comma.

Russ

Re: [9fans] UTF-8 handling in non-plan9 app: help finding bug

[David Presotto]

[-- Attachment #1: Type: text/plain, Size: 556 bytes --]

The base64 string decodes to 9 UTF bytes whose hex values are:

	ec b2 9c eb ac b4 ed 98 b8

Not a comma in there.

This UTF string converts to 3 Unicode characters:

	cc9c bb34 d638

This is in the right range for Korean and there isn't a comma
in there at all.

All the =?charset?encoding?stuff?= is supposed to be treated as a
single symbol so you needn't worry about commas in there anyways.

My best guess is that your gui saw some characters that it couldn't
figure out how to display and stuck in its own goofie looking From:
line.

[-- Attachment #2: Type: message/rfc822, Size: 2521 bytes --]

From: George Michaelson <ggm@apnic.net>
To: 9fans@cse.psu.edu
Subject: [9fans] UTF-8 handling in non-plan9 app: help finding bug
Date: Mon, 24 Mar 2003 11:48:06 +1000
Message-ID: <20030324114806.78f6cf04.ggm@apnic.net>


Not a plan9 bug, but I'd appreciate debug help. I am UTF-8 illiterate.

This From: address appears to render in my gui as 

	From: 'binary meant to be korean', <user@dom.ain>

Is this because the UTF-8 decoder has mapped a 16 byte char into ASCII which
ends with a comma, and the gui hasn't made this SMTP legal? Some people think
From: any crap you like <real@dom.ain> is ok, but 
From: "other crap" <real@dom> is clearly nicer, since you can probably quote 
the trailling ,

equally, the "," may not be there. it might be the UTF-8 decoder or something
else is broken.

so can one of you RUNIC wizards tell me if this is valid hypotheses? Is this
actually a bug their side, sending invalid RFC822/SMTP header? 

-george

	From:    =?UTF-8?B?7LKc66y07Zi4?= <cmh@nic.or.kr>
	To:      "George Michaelson" <ggm@apnic.net>

Re: [9fans] UTF-8 handling in non-plan9 app: help finding bug

[Boyd Roberts]

George Michaelson wrote:

>	From:    =?UTF-8?B?7LKc66y07Zi4?= <cmh@nic.or.kr>
>
That's a totally bogus interpretation 'cos that's a:

    route-addr with a non-null phrase

My guess is that it smashed it into two addresses, seperated by a comma,
'cos the MIME encoded atom was a case it couldn't cope with.

It would have been better to encode it as the hex chars in a comment
or a quoted atom, as it would appear it can't cope with real utf-8:

    "cc9c bb34 d638" <cmh@nic.or.kr>

    (cc9c bb34 d638) <cmh@nic.or.kr>

Or even:

    (Unrepresentable UNICODE hex values follow) "cc9c bb34 d638" 
<cmh@nic.or.kr>

Re: [9fans] UTF-8 handling in non-plan9 app: help finding bug

[Russ Cox]

Actually it's a completely valid form.  Go read RFC 2047.

Re: [9fans] UTF-8 handling in non-plan9 app: help finding bug

[Jack Johnson]

On Tue, Mar 25, 2003 at 05:15:56PM +0100, Boyd Roberts wrote:
> George Michaelson wrote:
>    (Unrepresentable UNICODE hex values follow) "cc9c bb34 d638" 
> <cmh@nic.or.kr>

If it's unrepresentable, why not just do:

	cmh@nic.or.kr

?

-Jack

Re: [9fans] UTF-8 handling in non-plan9 app: help finding bug

[Boyd Roberts]

Russ Cox wrote:

>Actually it's a completely valid form.  Go read RFC 2047.
>
>  
>
Ahh, I was being too terse -- again.  I was referring
to the way the user agent mangled the completely valid
address.

Re: [9fans] UTF-8 handling in non-plan9 app: help finding bug

[Boyd Roberts]

Jack Johnson wrote:

>If it's unrepresentable, why not just do:
>
>	cmh@nic.or.kr
>  
>
Loss of data is a bad idea.  You should try and hang onto it somehow.

Re: [9fans] UTF-8 handling in non-plan9 app: help finding bug

[George Michaelson]

I updated my bug report and sent in the first response which clarified it as a
GUI stuffup. base (n)MH deals with it ok, but its ugly to look at. I suppose
if I was insane enough to run a shell mailtool in a UTF-8 aware terminal It
would have looked fine.

thanks for all the feedback.

-george

[9fans] Re: alg to make a good colour palette for a graph

[Jim Choate]

On Fri, 21 Feb 2003, Steve Simon wrote:

> I picked up somecode from Graphics gems to do this,
> it was good enough for me though I wouldn't vouch
> the optimal-ness of its solution.
>
> The file is colorquant.c, I cannot find which volume of
> gems its from but I could send you the code if you like.

Google is your friend, all the code from all five volumes is available on
the web at the Graphics Gem homesite, which by the way will take you to
their e-zine on graphics related topics.


 --
    ____________________________________________________________________

      We are all interested in the future for that is where you and I
      are going to spend the rest of our lives.

                              Criswell, "Plan 9 from Outer Space"

      ravage@ssz.com                            jchoate@open-forge.org
      www.ssz.com                               www.open-forge.org
    --------------------------------------------------------------------