[9fans] presentation preparation

[9fans] presentation preparation

[Sam]

I'm working on a presentation and am
wondering what approach other 9'ers take
to preparing slides.  I'm thinking
a full screen page(1) would be sufficient
and I could use the extant doc prep
tools I'm becoming increasingly familiar
with.

Tips, tricks, and/or suggestions are welcomed.

Cheers,

Sam

Re: [9fans] presentation preparation

[Scott Schwartz]

| I could use the extant doc prep
| tools I'm becoming increasingly familiar
| with.

Not a Plan 9 specific answer, but...  I rather like latex with the
prosper package.  Ideally it is used to make pdf, and can take advantage
of acroread's features, but straight ps output should be usable.

Re: [9fans] presentation preparation

[andrey mirtchovski]

We were discussing latex presentations on this list some time ago (Russ
posted a fix to page to handle some mangled PostScript)...

I've done fine with presenting pdf or ps in a full-screen 'page' window on a
1024x768 laptop screen...

When talking about Plan 9 it is also useful to be able to hide the
presentation screen and show a few examples right there on the spot,
demo-style :)

I've sent Sam a sample presentation already, but didn't want to bother the
list with it. Another suggestion at the time was to use troff :)

andrey

On Sat, 15 Feb 2003, Scott Schwartz wrote:

> | I could use the extant doc prep
> | tools I'm becoming increasingly familiar
> | with.
>
> Not a Plan 9 specific answer, but...  I rather like latex with the
> prosper package.  Ideally it is used to make pdf, and can take advantage
> of acroread's features, but straight ps output should be usable.
>

Re: [9fans] presentation preparation

[Ralph Corderoy]

Hi andrey,

> Another suggestion at the time was to use troff :)

Bob Diertens' http://www.science.uva.nl/~bobd/useful/gpresent/ is useful
for producing PDF presentations using GNU troff.

Cheers,

--
Ralph Corderoy.      http://inputplus.co.uk/ralph/     http://troff.org/

[9fans] union directories

[Jack Johnson]

Ronald G. Minnich wrote:
 > truthfully, how many of you out there started out using disk/kfscmd
 > allow when you wanted to modify the kernel source?

I'll admit it, but I'm still a newbie so I have an extension of this
question.

Is there any way to, say, recompile a source tree with subfolders
without pre-creating those subfolders in the union directory?  Or,
what's the correct way to do something like:

mkdir 9
bind -bc 9 9
bind -ac /sys/src/9 9
cd 9
mk

(though that's not what I'm doing, I'm just needed an easy example)

-Jack

Re: [9fans] union directories

[Russ Cox]

there's no good way to do a recursive bind.
for the kernel you could piece it together with

t=/usr/you/9
bind -bc $t/pc /sys/src/9/pc
bind -bc $t/boot /sys/src/9/boot
cd /sys/src/9/pc
mk

Re: [9fans] union directories

[Adrian Tritschler]

Jack Johnson wrote:
> Ronald G. Minnich wrote:
>> truthfully, how many of you out there started out using disk/kfscmd
>> allow when you wanted to modify the kernel source?

I'll admit it.  How many knew any other way?  How many yet know?  Maybe a
little mention on the Wiki at
http://plan9.bell-labs.com/wiki/plan9/Compiling_kernels would be helpful.

Several months into my plan9 learning and I'm still getting my head around the
plan9 way of doing some things... most things...

> I'll admit it, but I'm still a newbie so I have an extension of this
> question.
> 
> Is there any way to, say, recompile a source tree with subfolders
> without pre-creating those subfolders in the union directory?  Or,
> what's the correct way to do something like:
> 
> mkdir 9
> bind -bc 9 9
> bind -ac /sys/src/9 9
> cd 9
> mk
> 
> (though that's not what I'm doing, I'm just needed an easy example)
> 
> -Jack

	Adrian

---------------------------------------------------------------
Adrian Tritschler    mailto:Adrian.Tritschler@its.monash.edu.au
Latitude 38°S, Longitude 145°E, Altitude 50m,      Shoe size 44
---------------------------------------------------------------

Re: [9fans] presentation preparation

[Richard Miller]

> I'm working on a presentation and am
> wondering what approach other 9'ers take
> to preparing slides.

I write slides in html [actually in a simpler syntax which is
translated to html by an awk script] and use charon to display
them.

-- Richard

Re: [9fans] presentation preparation

[Russ Cox]

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

Attached are some presentations I've done using
troff and page, along with tools that make them
easier.

You can play with the variables at the end of tmac.ppt
(or the definitions themselves) to add color to various
parts.

I tend to shy away from color usually, though.
The auth talk is black and white, while the oscpu
presentation adds grey.

Russ

[-- Attachment #2: doc.tar.gz --]
[-- Type: application/octet-stream, Size: 12370 bytes --]

Re: [9fans] presentation preparation

[Fco.J.Ballesteros]

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

An alternative is to use either the foils macro package or
a derivative. This is the one I use along with the respective mkfile
with view, print, ... targets

hth

[-- Attachment #2: slides.tgz --]
[-- Type: application/x-tar, Size: 7848 bytes --]

Re: [9fans] how to avoid a memset() optimization

[Russ Cox]

>   He doesn't need to know about volatile -- that's the whole point.
>   Once "experienced" programmer has set the buffer that way, the
>   less experienced just gets less chance to screw himself up

I'd still rather see it closer to the use that needs it.
If you're used to seeing secmemset then seeing
memset is a big red flag.  If you're used to seeing
memset with a volatile declaration, then you have
to seek out the volatile declaration, which might not
be anywhere near the call to memset.

This is a stupid argument anyway.  Volatile is a crock.
Here's another problem.  Suppose I'm worried that
leaking the processor flags at the end of my computation
might reveal something about the secret key.  I want to
clear them.  I could do something like:

	x = 0 & 0;

which in this particular case will clear the appropriate
flags.  But now the compiler comes along and optimizes
away the whole expression.  Where do I put my volatile
to make that stay?  Hmm?  The answer is not more crappy
qualifiers.  The answer is clearly dumber compilers.

Russ

Re: [9fans] how to avoid a memset() optimization

[Douglas A. Gwyn]

Russ Cox wrote:
> This is a stupid argument anyway.  Volatile is a crock.
> Here's another problem.  Suppose I'm worried that
> leaking the processor flags at the end of my computation
> might reveal something about the secret key.  I want to
> clear them.  I could do something like:
> 	x = 0 & 0;
> which in this particular case will clear the appropriate
> flags.  But now the compiler comes along and optimizes
> away the whole expression.  Where do I put my volatile
> to make that stay?  Hmm?  The answer is not more crappy
> qualifiers.  The answer is clearly dumber compilers.

Do you really want the compiler to always generate code
	MOV	R1,#0
	MOV	R2,#0
	AND	R2,R1
	MOV	R2,X(SP)
?  Almost any modern compiler will peform the AND at
compiler time (constant folding), and most customers want
that.  Anyway, I don't see why you need to AND in this
context.  Are you talking about the C and V bits?  If some
other process can inspect those for your process I'd think
it could inspect a whole lot more..

It is certainly true that we could really use better access
to the C bit from higher-level language source code.  This
shows up especially in the MP library.  But exploiting too
specific knowledge about the workings of a specific platform
can be dangerous, as we've seen historically.  If anybody
can devise a *nice* way to get at the C bit in MP coding,
please let me know so that it can be proposed for C0x.

Re: [9fans] how to avoid a memset() optimization

[Sam]

> Do you really want the compiler to always generate code
> 	MOV	R1,#0
> 	MOV	R2,#0
> 	AND	R2,R1
> 	MOV	R2,X(SP)

Yes, yes, and yes.  Optimizations which intelligently manage
register allocation are about as far as *I* appreciate.  Do
precisely what I say, and no less.  If I write poor code,
boo hoo for me.  Heavily optimizing compilers will *never*
make all coders equal and generally cause more headaches
than they're worth.

I do appreciate some warnings (ie if I forget to initialize
a variable to zero before I use it), but some of them are
just irritating.  Brantley looked over my shoulder a while
back and wondered why I was typing:

	if((m=fn())) {
		...
	}

saying, "what's with the extra parenthesis?"  "Oh, gcc complains
that I should surround assignment values used as a truth statement
and I've just incorporated it by habit to shut it up."

I hadn't even realized I was permitting gcc to define my style.
In essence, by permitting mad optimizations and then having to
do backflips just to keep the compiler from optimizing away
our real intentions, we're doing the same thing.  I hardly see
this as useful.

Cheers,

Sam

Re: [9fans] how to avoid a memset() optimization

[Scott Schwartz]

I, for one, like optimizing compilers.  Sure, sometimes you need fine-
grained control, but mostly I want faster code.  But like rob says, maybe
something other than C is what's called for.

Re: [9fans] how to avoid a memset() optimization

[Boyd Roberts]

I'd rather have slow and right over fast and broken.

Re: [9fans] how to avoid a memset() optimization

[plan9]

On Thu, Nov 14, 2002 at 04:26:08PM +0100, Boyd Roberts wrote:
> I'd rather have slow and right over fast and broken.

You and the other 5% of the world's consumers.

Re: [9fans] how to avoid a memset() optimization

[Sam]

Let's define "slow."  The last time I did a performance
test was on a des module I wrote.  The gcc compiled
-02 ran .2-.4 seconds faster (out of 3-4s).  Further
optlevels were not any better.

Anyone have any numbers showing that, "without optimizations,
this simply wouldn't be tolerable," in the face of well
written code?  In these instances does the compiler
generate crap code from the start, expecting an optimizer
to come clean it up later?

We wrote a C compiler for the language as of about
'73 for a coldfire target and it was a very telling
experience.  It was rather obvious that a simple
peephole optimizer would handle most of the inefficiencies
in the generated assy.  The code ran fast enough for
our purpose, however, so we didn't bother.  Indeed,
the human-time component is the most expensive
resource.  It's a shame 95% of the world doesn't
understand that.

Cheers,

Sam

On Thu, 14 Nov 2002 plan9@sigint.cs.purdue.edu wrote:

> On Thu, Nov 14, 2002 at 04:26:08PM +0100, Boyd Roberts wrote:
> > I'd rather have slow and right over fast and broken.
>
> You and the other 5% of the world's consumers.
>

Re: [9fans] how to avoid a memset() optimization

[Steve Kilbane]

> I'd rather have slow and right over fast and broken.

Others have different opinions. There are several issues here.

1. Some people want near-to-optimal code for the machine they've
chosen (slower code means faster machine needed, means higher price,
means fewer sales), and they want it soon (before their competitors
get all the market share). The economics of those markets mean they
need optimizing compilers. Vendors are happy to fill that need.

2. The language is being used for two different purposes: expressing
an abstract algorithm, and controlling the machine. These conflict.

3. There's a scary number of people out there who don't understand
the language they're using, and define it in terms of "Microsoft
gets it right," or "gcc does it properly", without realising they've
just been lucky. Their code can break from one compiler to another,
without having to optimize it. Optimizers just make it more obvious.

steve

Re: [9fans] how to avoid a memset() optimization

[Douglas A. Gwyn]

Steve's reponse was very nice.  Another way of putting it
is that the "right" behavior is not at all obvious once
you think hard enough about it and examine a wide enough
variety of platforms and application requirements.  One
of the tasks undertaken by the C standards committee was
to negotiate among the conflicting demands and to draw
the line somewhere.  Individuals would very likely draw
the line in other places, depending on their personal
prejudices and values.  If the existing standard
specification is causing significant real problems, there
is a mechanism in place to get it reconsidered and maybe
the official line could be redrawn.  The really important
thing is to understand where the official line *is* and
to observe it (on both sides, programmer and implementor);
that allows all parties to work together even if they all
still want to grumble about some aspect of the work..

Re: [9fans] how to avoid a memset() optimization

[Dan Cross]

I like Proebsting's law.  Compiler optimizations will get you a 2 fold
increase in speed once every 18 years.  That said, I wouldn't give up
the optimizations I have now, but I'm not married to them.

	- Dan C.

Re: [9fans] how to avoid a memset() optimization

[Douglas A. Gwyn]

Dan Cross wrote:
> I like Proebsting's law.  Compiler optimizations will get you a 2
> fold increase in speed once every 18 years.

Do you mean, that optimization technology improves at that rate?
For RISC architectures it is hard to tell optimization apart from
simply doing a good job of allocating registers, pipelines, etc.

Re: [9fans] how to avoid a memset() optimization

[Dan Cross]

> > I like Proebsting's law.  Compiler optimizations will get you a 2
> > fold increase in speed once every 18 years.
>
> Do you mean, that optimization technology improves at that rate?

Yes.  He states it much more succinctly than I did:
http://research.microsoft.com/~toddpro/papers/law.htm

> For RISC architectures it is hard to tell optimization apart from
> simply doing a good job of allocating registers, pipelines, etc.

That's true, but eliminating whole function calls is pretty clearly
an optimization.

	- Dan C.

Re: [9fans] how to avoid a memset() optimization

[Douglas A. Gwyn]

> > Do you really want the compiler to always generate code
> >       MOV     R1,#0
> >       MOV     R2,#0
> >       AND     R2,R1
> >       MOV     R2,X(SP)
Sam wrote:
> Yes, yes, and yes.  Optimizations which intelligently manage
> register allocation are about as far as *I* appreciate.  Do
> precisely what I say, and no less.

I intentionally mimicked the PDP-11 in my example since it supports
nearly a direct mapping from C to instructions.  However, on many
modern machines there is no such direct mapping for many of (old)
C constructs, so trying to control code generation through use of
C source code is fruitless.  And once you accept that principle,
it is hard to tell what constitutes optimization versus simple
code generation.  If you want assembly language you know where to
find it...

Re: [9fans] how to avoid a memset() optimization

[Roman V. Shaposhnick]

On Thu, Nov 14, 2002 at 01:53:04AM -0500, Russ Cox wrote:
> >   He doesn't need to know about volatile -- that's the whole point.
> >   Once "experienced" programmer has set the buffer that way, the
> >   less experienced just gets less chance to screw himself up
>
> to make that stay?  Hmm?  The answer is not more crappy
> qualifiers.  The answer is clearly dumber compilers.

  Or may be the answer is
     #pragma get your hands off my data, your psycho

  ;)

Thanks,
Roman.

Re: [9fans] useful language extension, or no?

[rob pike, esq.]

Saves you, what, 5 keystrokes?  Not too convincing.

-rob

Re: [9fans] useful language extension, or no?

[Sam]

You're right, and the capability to do:

struct type {
	int a;
	int b;
};

struct type2 {
	type;
	int c;
	int d;
};

saves so many more strokes in itself *and must* be more efficient.

Suppose I'm not saying "why," but "why not."  IMO it's cleaner and
quite possibly more efficient (without getting into a usec argument,
please).  Do you disagree?

Sam

On Tue, 16 Jul 2002, rob pike, esq. wrote:

> Saves you, what, 5 keystrokes?  Not too convincing.
>
> -rob
>

Re: [9fans] useful language extension, or no?

[Steve Kilbane]

> Suppose I'm not saying "why," but "why not."  IMO it's cleaner

I disagree. It's considerably more ambiguous. Your loop continuation
condition (i<NELS) may be failed by considerably more cases
than your trailing condition (i==NELS). What happens if your loop
body does "i=NELS+1"? What if your "i++" was actually something
like "i=arr[i]"? What if your continuation condition was
"i<NELS && j<NELS2"?

C's "for" is not like Pascal's FOR.

> and
> quite possibly more efficient

The pros and cons have already been discussed. I'd just like to
note that there's no particularly compelling reason why it would
generate different code from that which used the idiom. A good
optimiser would render them into the same internal form anyway.

"A good optimiser" is a subjective term, and Plan 9's C optimising
has already been discussed recent (Summary: it's good enough that
there are more important/interesting/useful things to work on),
but the point stands.

steve