HDTenEightyP/NetNews huggingface dataset:
From: mcastle@cs.umr.edu (Michael R Castle)
Subject: Re: How do you read binary data piped into stdin?
Date: Tue, 26 Jan 1993 17:38:17 GMT
Organization: University of Missouri - Rolla, Rolla, MO
Keywords: stdin, redirection, binary data

In article <N0gRXB1w165w@eastwind.mcds.com> chorn@eastwind.mcds.com writes:
>
>I'm relatively new to C, so still have a lot to learn, so I apologize
>if this is a silly question. I need to read raw binary data from
>stdin (it is being piped in) but it appears stdin operates in text
>mode. The first ascii 26 that comes along triggers end of file, and
>I can't read the rest of the data. Could someone please explain, or
>better yet show me a short peice of code, that could do this? The
>answer is probably obvious, but it eludes me at the moment. Thanks
>a lot!

After reading the followups for this article, I'm surprised no one has 
asked the obvious "What system are you on?"

The only system I've come across where ascii 26 is special is MS-DOS 
(well, ok, OS/2 as well).  

If it is ms-dos, please specify.  Knowing what system you are using 
(especially for very system dependent things such as file i/o), helps
tremendously in helping solve the problem. 

Anyway, if it IS really ms-dos, the following will work for turbo-c
and djgpp (gcc/g++ ported to dos).  I believe it will work with ms-c
as well, but not sure.

#include <fnctl.h>

setmode(fileno(stdin),O_BINARY);

This will change stdin (or any open file) to binary mode.

You can use this to change back and forth between binary/text mode if you
so wish.

Btw, when trying to help a friend port pbmplus to os/2, this solution 
did NOT work because setmode() would not affect a stream (ie, stdin,
stdout, i guess anything opened with fopen()).  T'was more than a bit
annoying (oh, with ibm c-set/2).  

hope this helps.

regards,
mrc
-- 
Mike Castle .-=NEXUS=-.  Life is like a clock:  You can work constantly
  mcastle@cs.umr.edu     and be right all the time, or not work at all
S087891@UMRVMA.UMR.EDU   and be right at least twice a day.  -- mrc
    We are all of us living in the shadow of Manhattan.  -- Watchmen
Newsgroups: comp.lang.c,comp.lang.c++
From: erc@netcom.com (Eric Smith)
Subject: Re: discriminated unions (Re: C/C++ Correctness (was: Re: C/C++ Speed))
Organization: Netcom - Online Communication Services (408 241-9760 guest)
Date: Wed, 27 Jan 1993 08:20:20 GMT

In article <1993Jan26.204305.24612@ucc.su.OZ.AU> maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:
[about the advantages of discriminated unions]


You and Thomas Breuel both make a good case for discriminated unions.
After the standard is published, if it doesn't include such features as
discriminated unions and nested functions, I and others will probably
add them as extensions.
Xref: sparky comp.lang.c:20031 comp.lang.c++:19697
From: jimf@centerline.com (Jim Frost)
Newsgroups: comp.lang.c,comp.lang.c++
Subject: Re: C/C++ Correctness (was: Re: C/C++ Speed)
Date: 21 Jan 1993 20:34:18 GMT
Organization: CenterLine Software, Inc.
NNTP-Posting-Host: 140.239.3.202

erc@netcom.com (Eric Smith) writes:
>In article <1jkismINN3qq@armory.centerline.com> jimf@centerline.com (Jim Frost) writes:
>...
>>It's true that if you use C++ as a C with better type checking there
>>will be few runtime performance penalties.  In fact, C++ inlining
>>alone can overcome many performance drawbacks.
[...]
>Inlining can in fact make C++ faster than C, especially if it's the
>only non-C feature you use in C++.  For many C programmers, inlining
>alone is enough to justify the move to C++.

That's what I was trying to say, thanks for a more eloquent
description.

jim frost
jimf@centerline.com
Xref: sparky comp.lang.c:20032 comp.lang.c++:19702
From: tmb@arolla.idiap.ch (Thomas M. Breuel)
Newsgroups: comp.lang.c,comp.lang.c++
Subject: Re: discriminated unions (Re: C/C++ Correctness (was: Re: C/C++ Speed))
Date: 21 Jan 93 22:24:33
Organization: IDIAP (Institut Dalle Molle d'Intelligence Artificielle
	Perceptive)
	<1993Jan21.004105.1335@ucc.su.OZ.AU> <1993Jan21.075642.6482@netcom.com>
Reply-To: tmb@idiap.ch
NNTP-Posting-Host: arolla.idiap.ch
In-reply-to: erc@netcom.com's message of Thu, 21 Jan 1993 07:56:42 GMT

>>>>> On Thu, 21 Jan 1993 07:56:42 GMT, erc@netcom.com (Eric Smith) said:

> In article <1993Jan21.004105.1335@ucc.su.OZ.AU> maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:
>>	Later I can write a breadth first search.
>>	I dont have to change anything to write the breadth first search.
>>	Its just a global function taking the tree as an argument.
>
> Ok, now I understand.  You want to be able to add functionality to a class
> without changing the class itself nor deriving a new version of it.  Your
> discriminated unions would be helpful toward that goal, but I still don't
> see any overwhelming advantage of that goal.  The only real advantage I can
> see is that you don't have to use a new class name for your new version.
>
> Other than cluttering class name space, are there any disadvantages in
> deriving new classes to add functionality?

You can't add functionality to a class X by writing code for a class Y
(derived from X). That is, your new BFS algorithm for objects of type
Y (derived from X) won't work on objects of type X.

					Thomas.
From: adamsj@gtewd.mtv.gsc.gte.com
Newsgroups: comp.lang.c
Subject: DATA STRUCTURES BOOK RECOMMENDATIONS
Date: 28 Jan 93 13:29:52 -0800
Organization: GTE Govt. Systems, Electronics Def. Div.

I've seen a bit of discussion on data structure books, but no summary or final judgement of what
the top 3 might be...

Sometime just before Christmas, someone posted a summary of data structure books. Can someone 
please send me that message, or tell me what it said, or, provide new opinions on a good 
data structures book (preferably but not necessarily using C examples)???

Thankyou, Jeff Adams
Newsgroups: comp.lang.c
From: schoepp@iiasa.ac.at (Wolfgang  SCHOEPP)
Subject: Re: Borland TC++ 3.0 and Pharlap Dos Extdrs'
Organization: IIASA, Laxenburg, Austria
X-Newsreader: TIN [version 1.1 PL6]
Date: Thu, 21 Jan 1993 10:35:44 GMT

Zeke E. Pez (olw7845@zeus.tamu.edu) wrote:
: Does the combination of Turbo C and Pharlap Dos Extdrs when combined
: allow me to use a pointer that points to a allocated chunk of memory
: that is 2megs or larger?
: 

I has been able to do so in Borland c++ 2.xx. I used farmalloc. See
also the Phar Lap man. "Huge Allocations".

: If so, do I need to use "huge" pointers to break the 64k barrier limit
: of ANSI C?
: 
It is simpler if you use huge keyword. But you must use the -h flag to make
sure that the pointer calculation makes no error with the selector.  Therefor
any item in a huge array, or any operation can just use a length which
breaks with power of 2. (See Phar Lap ma. as well). It is also
possible to make your own pointer calculation then the huge keyword is not
needed.
P.S. the 64K barrier is a DOS and not a ANSI C one.


: If the answer to the first question is yes, Is there alot of B.S. Handwaving
: discreet details in acheiving this pointer allocation?
: 
: Thanks,
: Zeke
: 

I hope this is helpful

Wolfgang Schoepp
Inter. Inst. for
Applied Systems Analysis
AUSTRIA, Laxenburg
Newsgroups: comp.lang.c
From: ciaranst@rossinc.com (ciaran storan)
Subject: selecting a software development environment
Organization: Ross Systems, Inc.
Distribution: usa
Date: Sun, 24 Jan 1993 03:12:31 GMT

How does one create forms management programs that can be ported
from one platform to another with minimal recoding.  Some
of these platforms have Window Managers like Motif, OPENLOOK
and Microsoft Windows and some don't.  There are commercially
available solutions like XVT's Portability Toolkit which are
fabulously expensive for the kind of application that I have in mind.
Any suggestions in this regard would be appreciated.
-- 
<.....................................................................>
<    A Day without laughter, is a day wasted!!. - Charlie Chaplin     >
<.....................................................................>

Newsgroups: comp.lang.c
From: cs4gp6au@maccs.mcmaster.ca (Lockie      RJ)
Subject: c and modula2
Organization: Department of Computer Science, McMaster University
Date: Mon, 25 Jan 1993 18:49:16 GMT

	Ok. I have a question about the difference between C and
Modula-2.
Here's some C code (correct I hope):
struct ex {char word[10};
struct ex test[10];
struct ex *p;
p = &test[0];   /* or p = test */
p ++;
/* p now points to test[1] according to K&R2 pg. 98 */

Here's some Modula-2 code:
TYPE ex = ARRAY[0..10] OF CHAR;
VAR test : ARRAY[0..10] OF ex;
    p : POINTER TO ex;
BEGIN
  p = ADR(test[0]);
  INC( p );
  (* p now points to test[0][1] *)

So, if the above code is correct, the question I have is why does
incrementing a pointer in C point to the next element in the array?
while in Modula-2 it doesn't (the pointer needs to be incremented
by the size of the array element).
How does C do that? Is it the compiler? In Modula-2, to increment to
the next element in the array it would require:
  INC( p, SIZE(ex) );

So is this code correct? And how is this feature of C implemented?

	Bob Lockie: cs4gp6au@maccs.dcss.mcmaster.ca
From: jm59@prism.gatech.EDU (MILLS,JOHN M.)
Newsgroups: comp.lang.c
Subject: Re: Why C over FORTRAN
Date: 28 Jan 93 15:12:14 GMT
Organization: Georgia Institute of Technology

In article <RVILLA.93Jan27211009@navier.ae.utexas.edu> rvilla@navier.ae.utexas.edu (reynaldo villarreal) writes:
>
 >I am interested in the pros and cons of C vs. FORTRAN.(gcc vs f77 on a
 >Sun) I have to write code and have to give an informed choice to my
 >advisor on which to use.

If you want more that religious answers, you should be more specific as
to what you wish to program, and probably cross post to another language
group or two.  I would expect a couple of weeks worth of dogma and flames,
anyhow.  Press, et. al., in their Numerical Recipies series address pros
and cons, but basically as seen by Fortran programmers.  I would consider
the code I _did_not_ have to write, i.e., libraries and toolsets, in making
this decision.

Regards --jmm--

-- 
John M. Mills, SRE; Georgia Tech/GTRI/TSDL, Atlanta, GA 30332
uucp: ...!{decvax,hplabs,ncar,purdue,rutgers}!gatech!prism!jm59
Internet: john.mills@gtri.gatech.edu
C++: "Increment C, then return the old value"  - anon
From: alien@acheron.amigans.gen.nz (Ross Smith)
Newsgroups: comp.lang.c
Subject: Re:  can a pointer cast to a void* be compared to (void*)0 ?
Date: 22 Jan 93 13:53:02 GMT+12
Distribution: world
Organization: Muppet Labs

In article <1993Jan16.015545.26580@thunder.mcrcim.mcgill.edu> mouse@thunder.mcrcim.mcgill.edu (der Mouse) writes:
>In article <C0nzI2.CqM@cs.psu.edu>, andrew@astro.psu.edu (Andrew Wilcox) writes:
>>      char* c = 0;
>>      void* p = (void*) c;
>>      if (p == 0)
>>        printf( "yes\n" );
>
>> Is this program guaranteed to print "yes"?
>
>Ah, this asks more.  You want to know if a null pointer of one type is
>guaranteed to be a null-pointer-to-void when converted.  I don't think
>this is guaranteed.  In the case of char *, the grandfather equivalence
>of char * and void * may mean that it is, but I don't think so.  (The
>equivalence means, I think, that you could memcpy c to p and thereby
>ensure getting a null void *.  Of course, most systems will let it
>work as you've written it, since it will usually require extra effort
>to break it, but I don't think it's guaranteed.)

Sorry, you've got it backwards. (The FAQ explains this in all its gory
detail :-)

A null pointer is required to remain a null pointer when cast to any other
pointer type (except function pointers, which are a special case), and the
integer zero and any null pointer are required to cast to to each other
(except ditto). However, null pointers are *not* required to be actual
bitwise zeros (and null pointers to different types are not required to be
identical), so a memcpy() will *not* (necessarily) work. If a null pointer
is not bitwise equivalent to the integer zero, the compiler must perform
whatever magic is required to make them interchangeable in source code.

In other words, any ANSI compiler is required to treat the following code
fragments as equivalent, *regardless* of what bit patterns are used for
pointers:

   int *iptr = NULL;

   int *iptr = 0;

   int *iptr;
   void *vptr = NULL;
   iptr = (int *)vptr;

But in the last case, memcpy(&iptr, &vptr, sizeof(void *)) would not
necessarily put a null pointer into iptr (in fact, sizeof(void *) and
sizeof(int *) need not be the same).

(All this, of course, assumes that I've correctly understood the FAQ, which
I'd be the first to admit is by no means a foregone conclusion :-)

Now a couple of questions of my own. I know (or think I know) that the
standard does not require pointers to functions to be castable to/from any
other pointer type.

(1) Are pointers to different types of function required to be castable to
each other?

(2) If a compiler does allow casting between "ordinary" pointers and function
pointers, does the rule about null pointers remaining null still apply?

--
...... Ross Smith (Wanganui, NZ) ...... alien@acheron.amigans.gen.nz ......
"I blame you for the moonlit sky and the dream that died with the Eagle's flight
I blame you for the moonlit nights when I wonder why are the seas still dry
Don't blame me, sleeping satellite"                              (Tasmin Archer)
--
Newsgroups: comp.lang.c
From: mcastle@cs.umr.edu (Michael R Castle)
Subject: Re: Help with spawnl() function
Date: Sat, 23 Jan 1993 01:40:06 GMT
Organization: University of Missouri - Rolla, Rolla, MO

In article <TskPXB3w165w@wozzle.linet.org> alane@wozzle.linet.org (J. Alan Eldridge) writes:
>jaf@jaflrn.UUCP (Jon Freivald) writes:
>
>> Why not use remove() or unlink()?  You can't do "system("del file")
>> because del (& erase) are internal commands, although you could do
>> "system("command /c del file")" [a consideration here - what about folks
>> who don't use command.com?  It's no-where on my machine, and which
>> command processor I'm using depends on what mood I'm in..!]
>
>char szCmdbuf[ 130 ];
>char *szComspec=getenv("COMSPEC");
>
>if (!szComspec)
>    szComspec="COMMAND.COM";
>sprintf(szCmdbuf, "%s /C del file", szComspec);
>system(szCmdbuf);

From my turbo-c++ 1.00 manual:

_system_ invokes the DOS COMMAND.COM file to execute a DOS command, batch 
file, or other program named by the string command, from inside an executing 
C program. 

To be located and executed, the program must be in the current directory
or in one of the directories listed in the PATH string in the environment.

The COMSPEC envrionment variable is used to find the COMMAND.COM file, so 
that file need not be in the current directory.

Copyright 1990 by Borland International.  Reprinted without permission.

Now, if borland did it right, it will use whatever is in COMSPEC, be it
4dos, ndos, or whatever.  The problem will then be, does your shell
support that command internally?  If not, is there an executable or 
batch file that does?

regards,
mrc
-- 
Mike Castle .-=NEXUS=-.  Life is like a clock:  You can work constantly
  mcastle@cs.umr.edu     and be right all the time, or not work at all
S087891@UMRVMA.UMR.EDU   and be right at least twice a day.  -- mrc
    We are all of us living in the shadow of Manhattan.  -- Watchmen
Newsgroups: comp.lang.c
From: jvs@jacks.apana.org.au (Jack Strangio)
Subject: Re: Why does curses make my Wyse50 flicker?
Organization: Prospect 5082, AUSTRALIA
Date: Sun, 24 Jan 93 05:33:45 GMT

ktf@bc3.gun.de (Klaus ter Fehn) writes:

> 1. Maybe the terminfo- and/or termcap-entry for the Wyse 50 is not set
>    up properly on your System. In this case other programs will
>    'flicker' too.
 Nope. System is stock-standard AT&T Unix SVr4. Wyse50 works ok normally.

> 2. Maybe the Handshaking Host-Terminal is not set up properly

Possibly. In what way? Please give more details.

> 3. Maybe the program is not well-written (some terminal-dependent
>    codings inside?)
As far as I can tell, I have set up the program to use curses to act
as the sole interface to the various terminals. Therefore it should
work the same no matter what terminal is being used. However, this
may be worth a second look. Thanks.

Thanks.

Jack

-- 
----------------------------------------------------------------------
 Jack Strangio                                 -  Voice +61-8-269 1509
 (jvs@jacks.apana.org.au)                               +61-1-883 3006
                         Data  +61-8-269 6771  -  Fax   +61-8-269 1509
Xref: sparky comp.lang.c:20024 comp.programming:3540
From: darcy@druid.uucp (D'Arcy J.M. Cain)
Newsgroups: comp.lang.c,comp.programming
Subject: Re: Telling if the SHIFT key is down.
Date: 21 Jan 93 13:23:48 GMT
Followup-To: comp.programming
Organization: D'Arcy Cain Consulting

ooprb@Msu.oscs.montana.edu writes:
>REQUEST:
>With Dos 5.0 and Borland 3.0, I would like to tell if the 
>shift key (ignoring all other keys presses) is being held 
>down on the go - not waiting for any key press.

This is really a DOS specific question but I have directed followups
to comp.programming because I want to discuss your general strategy.

>WHAT FOR:
>I'm writting a program that updates numbers by the press
>of a mouse button.  I would like to change the value by
>a different amount if the shift key is being pressed when 
>a mouse button is pressed.

Don't do this.  If you must change the meaning of a mouse button use
another button to do this.  Your method requires your users to have
their hands on two different devices in order to do input.  In fact
why not just make use of the different buttons on the mouse?  You could
for example increment by 1 on the left, 5 on the right and 3 on the
middle.  If your user has a two button mouse it still works but with
less intermediate control.

-- 
D'Arcy J.M. Cain (darcy@druid.com)  |
D'Arcy Cain Consulting              |   There's no government
Toronto, Ontario, Canada            |   like no government!
+1 416 424 2871          DoD#0082   |
Xref: sparky comp.lang.c:20025 comp.lang.fortran:5112
From: swhite@mathcs.emory.edu (Scott White)
Newsgroups: comp.lang.c,comp.lang.fortran
Subject: calling a Fortran subroutine from a C program
Date: 21 Jan 1993 13:35:22 -0500
Organization: Emory University, Dept of Math and CS
Distribution: world
NNTP-Posting-Host: mudhoney.mathcs.emory.edu

Can someone please tell me how to call a Fortran subroutine from a C program?
The environment is sun4, OS 4.1.2.

Also, the called Fortran routine takes variables which are arrays as 
parameters.  And, I looked and saw that the subscripts start at 1, whereas in
C they start at zero.  That's no problem is it (an address is an address):

/* .c file */
	int num[100];
	double zeta[100];

	foo(num, zeta);


/* .f file */
	subroutine foo(number, gamma)
	integer*4 number(100)
	real*8    gamma(100)

	/* program proceeds to manipulate values in the arrays, with subscripts
		1 through 100, not 0 through 99 */


Finally, if the Fortran subroutine changes the values in gamma, the changes
show up when we return to the C program, right?

Your gracious help is deeply appreciated.

Scott White
Emory University Math Dept.

-- 
Scott White
Department of Mathematics and Computer Science
Emory University, Atlanta, GA 
Internet: swhite@mathcs.emory.edu   UUCP: {rutgers,ogicse,gatech}!emory!swhite	
Newsgroups: comp.lang.c
From: pdh@netcom.com (Phil Howard )
Subject: Re: Please help! Integer longer than 32 bits required.
Keywords: help help help!
Organization: Netcom - Online Communication Services  (408 241-9760 guest) 
Date: Thu, 28 Jan 1993 11:11:51 GMT

proctori@p4.cs.man.ac.uk (Dave Proctor) writes:

>a bigger quantity than 32 bits. 64 bits would be wonderful, but C doesn't seem
>to want me to have em....

Your MACHINE does not have em.

The GCC compiler does have type "long long", which will do 64-bit on all
machines, I believe.  It might be even bigger on machines where long is
already 64-bit.  You might give it a try.  Of course it does it via some
instructions to simulate the extra precision, so things will slow down.
-- 
/************************************************************************\
| Phil Howard,  pdh@netcom.com,  KA9WGN    Spell protection?  "1(911)A1" |
| "It's not broken... it's just functionally challenged" --Phil and Pete |
\************************************************************************/
Newsgroups: comp.lang.c
From: gk@dcs.ed.ac.uk (Gavin Kerr)
Subject: Re: ANYONE KNOW HOW TO EXPAND WILDCARDS IN C FOR UNIX?
Reply-To: gk@dcs.ed.ac.uk (Gavin Kerr)
Organization: Laboratory for the Foundations of Computer Science, Edinburgh U
Date: Fri, 22 Jan 1993 02:27:58 GMT

In article <1993Jan20.155417.86@gtewd.mtv.gsc.gte.com> difalcod@gtewd.mtv.gsc.gte.com writes:
>If anyone knows how to expand wildcards (for file names) within C code (for
>UNIX systems), please respond to me preferably via e-mail.
>
>e-mail address = difalco@upse01.mtv.gsc.gte.com

Me too please!


Gav : gk@dcs.ed.ac.uk  gk@castle.ed.ac.uk  gkerr@nyx.cs.du.edu

*******************************************************************************
..  the HIGHWAY is made out of LIME JELLO and my HONDA
 is a barbequeued OYSTER!  Yum!
*******************************************************************************

Newsgroups: comp.lang.c
From: dnh@mfltd.co.uk (Des Herriott)
Subject: Re: Few simple questions
Organization: Micro Focus Ltd., Newbury, UK
Date: Fri, 22 Jan 1993 11:05:01 GMT


In article <TOMSTER.93Jan21220733@bigwpi.WPI.EDU>, tomster@bigwpi.WPI.EDU (Thomas Richard Dibble) writes:
>
> > [ Example of automatic array initialisation ]
> 
> Well, the problem (I am somewhat sure) is your compiler.  If I have
> the story right, this is not in the ANSII standard, and so
> "ANSII-compatible" compilers need not implement it.  The only solution
> I know of is to put it into a function called right off the bat or
> switch compilers.

You're sort of right, but on the wrong track...

Automatic array initialisation is legal in ANSI standard C.  That is, a statement like 
  
  int x[3] = { 1, 2, 3 };

is perfectly OK.  It's not, however, legal in pre-ANSI (Common) C.  The best
way around this is either get an ANSI-C compiler, or if that's not an option,
make the offending aggregate a static variable - that's allowed.

By the way, what's a "function called right off the bat" ?

Des.


-- 
Des Herriott,           /     "...and I hate, and I hate, and I hate,
Micro Focus, Newbury.  /             elevator music..."
+44 (0635) 565354     /
dnh@mfltd.co.uk      /                   -- Tori Amos, Little Earthquakes.
From: imes@cis.ohio-state.edu (jeffrey imes)
Newsgroups: comp.lang.c
Subject: Re: Problem with BC 3.1 vs. Gnu C
Date: 26 Jan 1993 14:03:03 -0500
Organization: The Ohio State University Dept. of Computer and Info. Science
NNTP-Posting-Host: boa.cis.ohio-state.edu

Thanks to everyone who helped me with this problem.  As I said, I'm new to C
and any suggestions help.

Thanks again....
Jeff

Newsgroups: comp.lang.c,comp.lang.fortran
From: ercolessi@uimrl3.mrl.uiuc.edu (furio ercolessi)
Subject: Re: calling a Fortran subroutine from a C program
Reply-To: ercolessi@uimrl3.mrl.uiuc.edu (furio ercolessi)
Organization: MRL - UIUC
Date: Fri, 22 Jan 1993 16:49:59 GMT

In article <1993Jan22.130743.27130@sol.ctr.columbia.edu>, bobp@msi.com (Bob Pitha) writes:
|>Scott White (swhite@mathcs.emory.edu) wrote:
|>: Also, the called Fortran routine takes variables which are arrays as 
|>: parameters.  And, I looked and saw that the subscripts start at 1, whereas in
|>: C they start at zero.  That's no problem is it (an address is an address):
|>
|> No, it's no problem, assuming you remember it everywhere.  It only makes
|>it a bit easier to make one of those annoying off-by-one subscript errors!

Perhaps not everybody is familiar with the fact that you can have the 
indexes matching by declaring, for example,
	real*8 array(0:99)
in the Fortran program.

--
furio ercolessi    <furio@uiuc.edu>*    <furio@sissa.it>+
* materials research lab, uni illinois at urbana-champaign
+ intl school for advanced studies, trieste, italy   

"Change nothing and continue with immaculate consistency"
                                      [ Brian Eno, "Oblique Strategies" ]