HDTenEightyP/NetNews huggingface dataset:
From: jbickers@templar.actrix.gen.nz (John Bickers)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: Sharing Library bases (Was: Re: Multithreaded code using CreateTask())
Date: 13 Oct 92 14:07:44 PST
Organization: TAP

Quoted from <1992Oct12.124254.20103@rz.uni-karlsruhe.de> by ry53@rz.uni-karlsruhe.de (Angela Schmidt):

> Nice idea to be compatible by not sharing library bases - but how
> should I realize this in practice?

    Not sure what you mean by being "compatible", but I think you
    shouldn't worry about it. If enough people ignore this sort of
    thing, then the writers of libraries will avoid such crankpot
    schemes.

    The other solution with DICE is to re-write your glue so that
    instead of assuming the existence of FooBase, you give the routine
    the library base as a parameter, as in:

        Draw(GfxBase,rp,x,y);

    This means you have to write your own glue routines, which is a
    pain.

>     00 &=-          Angela 
--
*** John Bickers, TAP.                   jbickers@templar.actrix.gen.nz ***
***    "Radioactivity - It's in the air, for you and me" - Kraftwerk    ***
From: xnybpf01@serss0 (Brian P Feeny)
Newsgroups: comp.sys.amiga.programmer
Subject: IDCMP
Date: 9 Oct 92 04:20:21 GMT
Organization: Florida International University, Miami


	I have a question that I hope someone can help me with.  I need to 
write a routine that basically waits for a disk to be inserted.  This routine
will run in the background at all times.  I do NOT wish for this routine to
open a window.  So how do I get IDCMP messages when I dont have a MsgPort
connected to a window?  I would like this program to be ran, and then you can
just get on with your work, when a disk is inserted, the progm will hear
about this, yet be quiet that it knows.  Some direction in C please.

						Brian
-- 
Brian Feeny - Systems Programmer - UNIX System Security Specialist
   __
__///          Internet: signal@phantom.com       "Grep me no patterns and
\XX/ AMIGA!              xnybpf01@serss0.fiu.edu   I'll tell you no lines"
From: paulk@terapin.com (Paul Kienitz)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: AztecC 5.2 and system()
Date: 7 Oct 92 12:23:03 PST
Organization: BBS

> system() doesn't work. Those fexe calls are messy. They are nasty
> hacks inside.
 
The Aztec fexec-type calls are basically primitive versions of
RunCommand(), but they mangle the argument line in uncontrollable
ways and they are unable to run resident programs.  They also bloat
up your program.  AVOID them.
 
> If you're under 2.0, you should go for SystemTagList().
 
Absolutely.  In fact, even if you need 1.3 compatibility you should
test whether you are under 2.0 and use SystemTagList() if so.
 
> With 1.3 Execute might be enough, but you depend on C:RUN then.
 
There is no dependency on C:Run if you have the SetPatch from 1.3.2
or 1.3.3 -- only 1.3.0 and older need C:Run.
Newsgroups: comp.sys.amiga.programmer
From: wild@nessie.cs.id.ethz.ch (Markus Wild)
Subject: Re: Sharing include files btw gcc and SAS/C 6.0
Organization: Swiss Federal Institute of Technology (ETH), Zurich, CH
Date: Fri, 9 Oct 1992 02:29:57 GMT

In article <1992Oct8.174248.17197@u.washington.edu> jedlow@milton.u.washington.edu (Alan Jedlow) writes:
>I used to just copy the SAS/C header files to the gcc os-include directory.

Hm, make sure to only copy the amiga-related header files, not for example
stdio.h from SAS, or you might get into troubles with gcc.

>Now, I'm trying to avoid duplicate directories to save space.  A similar 
>situation exists btw emacs' info directory and gcc's info directory.

with info it's simpler, there's an environment variable that tells infoview/
emacs where to look for info files. I think it's called INFOPATH, but check
with the manpage, I'm not sure.

>I thought of forcing directory hard links, but keep reading this is 
>"dangerous".

Although the official comment on them is "not yet supported", I prefer symlinks
to hardlinks. So you might as well consider directory symlinks, which are not
at all dangerous (contrary to hard links...). All that can happen to you
with symlinks is that a disk-repair tool might not recognise the special
fileheader type, and thus skip it. With hardlinks, weird internal linkage
between the `original' file and its links, and links of links are included
partly in otherwise unused fields of fileheaders. I'd rate the changes are
there that disk repair tools not explicitly aware of hardlinks might do evil
things to partitions using them... This might be paranoia, but I don't like
hard links;-)

-Markus


-- 
Markus M. Wild    -  wild@nessie.cs.id.ethz.ch  |  wild@amiga.physik.unizh.ch 
Vital papers will demonstrate their vitality by spontaneously moving
from where you left them to where you can't find them.
From: olsen@sourcery.mxm.sub.org (Olaf Barthel)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: How to drop DTR
Distribution: world
X-NewsSoftware: GRn 1.16e (7/4/92) by Mike Schwartz & Michael B. Smith
Date: 6 Oct 92 19:14:48 CET
Organization: MXM Barthel & Paesler

In article <1992Oct5.030431.24887@msuinfo.cl.msu.edu> griffin@eecae.msu.edu (Dan Griffin) writes:
> I have been looking through the RKM: Devices manual and I do not see
> a way to drop DTR.  If someone would tell me how this is accomplished,
> or possibly point me in the right direction, I'd appreciate it.

   As far as I know there is no officially-endorsed method to drop the
DTR line using the serial.device or a similar driver. However, I have
noticed that a great number of devices will drop the DTR line as soon
as they are closed.

> Dan Griffin                     Abort the whales with a nuclear handgun.
> griffin@egr.msu.edu             

-- 
Olaf Barthel       | Internet: olsen@sourcery.mxm.sub.org
Brabeckstrasse 35  |           o.barthel@a-link-h.comlink.de
D-3000 Hannover 71 |           cbmvax.commodore.com!cbmehq!sourcery!olsen
MXM, ECG127        |   Z-Netz: O.BARTHEL@A-LINK-H
-------------------------------------------------------------------------
                        Ceci n'est pas une pipe.
Newsgroups: comp.sys.amiga.programmer
From: knurlin@spf.trw.com (Scott Karlin)
Subject: Re: Standard ML On The Amiga
Organization: TRW Sensor Data Processing Center, Redondo Beach, CA
Date: Fri, 16 Oct 92 16:41:07 GMT

In article <cheungc.719161405@p4.cs.man.ac.uk> cheungc@p4.cs.man.ac.uk (Carson Cheung) writes:
>Does anyone know if there is a version of
>Standard ML available for the Amiga and where I can
>get it from.
>
>Replies by e-mail please
>
>Thanks in advance
>
>Carson Cheung

Please e-mail to me too!  I'm intersted as well.


-- Scott Karlin           
-- TRW Data Systems Center   Internet: knurlin@spf.trw.com
-- One Space Park, R2-2162      Phone: (310) 812-7335
-- Redondo Beach, CA 90278        FAX: (310) 812-8800
From: heinz@edohwg.adsp.sub.org (Heinz Wrobel)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: AztecC 5.2 and system()
Date: 6 Oct 92 19:18:17 GMT
Organization: Edotronik GmbH

In article <DAVIDM.92Oct4223707@consilium.com> davidm@consilium.com (David S. Masterson) writes:
>not documented in my Aztec C documentation.  Does anyone know if the call is
>supposed to work under Aztec C and what its limitations are?

system() doesn't work. Those fexe calls are messy. They are nasty hacks
inside. If you're under 2.0, you should go for SystemTagList(). With 1.3
Execute might be enough, but you depend on C:RUN then. If you only need
to run in a CLI environment >=1.3, I have a System0() source for you that's
a lot cleaner than the fexec stuff. And it still runs SW that uses fexec
which isn't that easy. ;^)

Email me if you need it.

>David Masterson					Consilium, Inc.

--
Heinz Wrobel, Edotronik GmbH (ECG018)
FAX +49 89 850 51 25 / TEL +49 89 850 25 20 (HOME!&VOICE, sometimes...)
From: mcuddy@fensende.Rational.COM (Mike Cuddy)
Subject: Re: Wolf3D -- programming aspects
Organization: Rational
Date: Mon, 12 Oct 1992 23:38:35 GMT

u894776@bruny.cc.utas.edu.au (James McCoull) writes:
>>chrisg@cbmvax.commodore.com (Chris Green) writes:
>>[some cool ideas... which start to break around here...]

>	The way I see it... if you are writing a game you have to provide
>a version for the A500/KS1.2/KS1.3 class of computers - otherwise you don't
>have a market.  This means you have to write two versions of every program -

Actually in my game, it's going to require 2.x.  It's also going to require
an 020  or greater.  Why?  1) It's shareware, 2) I've got an 040,  3) It's going
to be so cool that folks will upgrade just to have it ;-) ;-)

>one which hits the ECS hardware so hard and direct it almost fries, and one
>which lives nicely under KS3.x/AGA.  Of course if you are using an object
>oriented framework for your game, it is pretty trivial to set up a runtime
>link-loader which will resolve statically the actual rendering methods/code.

It turns out that WritePixelArray8() is not fast enough... It could probably
be optimized to be faster if the generic rastport manipulation stuff was
ripped out (and just a blind write-to-a-known-block-of-video-memory was done).

I plan to support 16, 32, EHB, and AGA.  along with (hopefully) Dale Luck's 
(GfxBase) graphics card.  and maybe a few others.  I'm going to handle the
graphics with a shared library... standard amiga modes in one, AGA in another,
and third party boards in yet another. The graphics will all be drawn with a 
12/24 bit palette/ 256 colors, and my graphics routines will use lookup tables
to get the colors down to the 'right number'. (obv. this will look best on 
AGA w/8 bits, but EHB shouldn't be too bad).

		-- Mike
Newsgroups: comp.sys.amiga.programmer
From: sdm@uk.cray.com (Stuart Mitchell)
Subject: OK, how _do_ I get mathieeesingbas.library ??
Originator: sdm@hemlock
Organization: Cray Research, Inc.
Date: 8 Oct 92 05:36:10 CDT


As you might guess from the subject, I've been trying to obtain a copy of the
mathieeesingbas and mathieeesingtran libraries (for a 1.3 system), here in the
UK. But my local CBM authorised dealer says they can't get 'em, and CBM
head office (in the UK) isn't too helpful either.

Anybody got any advice about what else I could try ??

stuart
-- 
    ___________ _            Mitchell's Law of Committees:  (fortune cookie)
   (_        / ) )               Any simple problem can be made insolvable
_____)tuart / / /itchell__       if enough meetings are held to discuss it.
     (sdm@uk.cray.com)
Newsgroups: comp.sys.amiga.programmer
From: comeau@csanta.attmail.com (Greg Comeau)
Subject: Re:  Comeau C++ extras?
Originator: comeau@well.sf.ca.us
Reply-To: comeau@csanta.attmail.com (Greg Comeau)
Organization: Comeau Computing
Date: Thu, 8 Oct 1992 02:40:10 GMT

In article <heinz.03q6@edohwg.adsp.sub.org> heinz@edohwg.adsp.sub.org (Heinz Wrobel) writes:
>In article <Bv62wp.2oD@well.sf.ca.us> comeau@csanta.attmail.com (Greg Comeau) writes:
>>Yes, in fact the ANSI C++ base document is *literally* derived from
>>our reference manual.
>
>You mean the ANSI C++ base document was written based on _your_ reference
>manual? I'm impressed!

Yes, that is correct.  However, don't go too deep in interpreting 'your'.
Although I have written for many mags and such, I personally am not the
author of the document.  Bjarne Stroustrup is.  However, as we are licensees
of AT&T USL C++, the document that was accepted by X3J16 as its base document
at its start was 99.99% the same verbiage as the Comeau C++ manual.

- Greg
-- 
         Comeau Computing, 91-34 120th Street, Richmond Hill, NY, 11418
                   Producers of Comeau C++ 3.0 With Templates
          Here:attmail.com!csanta!comeau / BIX:comeau / CIS:72331,3421
	    Voice:718-945-0009 / Fax:718-441-2310 / Prodigy: tshp50a
Newsgroups: comp.sys.amiga.programmer
From: saidji@eig.unige.ch
Subject: assembleur routines
Organization: University of Geneva, Switzerland
Date: Wed, 14 Oct 1992 08:08:29 GMT

Je suis a la recherche de routines pour assembleur MASTER SEKA(68000)
Routine pour affichage d'images,edition d'un son,etc...
Je cherche aussi des sites FTP possedant des routines assembleur.
Merci a vous.

I am looking for 68000 procedures running on MASTER SEKA.
Please send them to me !!
I am looking  for FTP sites.

here is my E-Mail adresse: saidji@eig.unige.ch

Thank you.

"Il y a plus de plaisir a donner qu'a recevoir."           Auteur inconnu
From: heinz@edohwg.adsp.sub.org (Heinz Wrobel)
Newsgroups: comp.sys.amiga.programmer
Subject: Re:   Multithreaded code using CreateTask()
Date: 9 Oct 92 20:17:23 GMT
Organization: Edotronik GmbH

In article <1992Oct8.212329.13048@samba.oit.unc.edu> Todd_Lewis@unc.edu (Todd M. Lewis) writes:
>and imxulRestoreTaskVectors().  OpenLibrary() isn't documented
>as having side effects on tasks and processes like having their

The point is: OpenLibrary() _doesn't_ have side effects. The library might
have some. The _system_ call doesn't.

>I guess what really steams me about all this is that the Amiga has a
>really clean software architecture.  You start letting little

With _clean_ architecture you probably mean that each thing is well defined
and separate things are separate things. Different processes are different
library users then and different library users each need an OpenLibrary()
call ;^)

But seriously: Of course it would break most programs if e.g.
graphics.library suddenly needs to be reopened by different tasks. So I'm
pretty sure _this_ won't happen. But there is no restriction whatsoever for
a _new_ library to say: _Each_ user needs to open me.
And I don't see anything bad in that because each process should "know"
what belogns to it and what it needs. Maybe "data encapsulation" and
"black box" are keywords here. Data sharing is to me like global data in a
program. Yuck! I can't really control this in a big project if _anybody_
starts sharing things.

Another point of thought: Just because something has always worked it
doesn't mean it's good or legal.

>    Todd M. Lewis / Todd_Lewis@unc.edu / utoddl@guitar.oit.unc.edu

--
Heinz Wrobel, Edotronik GmbH (ECG018)
FAX +49 89 850 51 25 / TEL +49 89 850 25 20 (HOME!&VOICE, sometimes...)
From: kopnicky@great-gray.owlnet.rice.edu (Lyle Warren Kopnicky)
Subject: Re: gcc 2.2.2 requirements
Organization: Rice University, Houston, Texas
	<1992Oct5.155934.27044@bernina.ethz.ch>
	<KOPNICKY.92Oct5233918@great-gray.owlnet.rice.edu>
	<1992Oct6.111145.23102@bernina.ethz.ch>
Date: Thu, 8 Oct 1992 01:27:01 GMT

> Yes and no... the preprocessor loads all files into memory, and does the
> macro expansion stuff. Then the resulting file is piped/fed into the main
> compiler. You're going to have problems tokenizing at the point of 
> preprocessing, the proprocessor isn't supposed to do such things...

Yes, but can't the compiler tokenize it as soon as it gets it?
Perhaps I'm missing something here....  Are both the preprocessor and
the compiler running simultaneously through the whole compilation?

--
+----------------------------Ren & Stimpy--------------------------------+
| "Psst. Hey Guido. It's all so clear to me now. I'm the keeper of the   |
| cheese. And you're the lemon merchant. Get it? And he knows it. That's |
| why he's gonna kill us. So we gotta beat it. Yeah. Before he lets      |
| loose the marmosets on us! Don't worry, little missy! I'll save you!"  |
+--------------- Quantum Seep -- kopnicky@owlnet.rice.edu ---------------+
Newsgroups: comp.sys.amiga.programmer
Subject: Re: CATS address
From: fheitkamp@desire.wright.edu
Date: 10 Oct 92 18:38:38 EST
Organization: Wright State University 

In article <1769@lysator.liu.se>, boberg@lysator.liu.se (Stefan Boberg) writes:
> fheitkamp@desire.wright.edu writes:
> 
>>In article <BvnMuM.K9C@unx.sas.com>, jamie@cdevil.unx.sas.com (James Cooper) writes:
>>	How about the 3.0 includes?  Are they available? 
> 
>   To registered developers, yes. (All levels) But since KickStart 3.0 is
> not available to the general public (it's currently only for developers 
> and A4000 users) I seriously doubt that they are available to "anybody".
> 
	Does anyone know the P/N for the 3.0 includes?

>>> CATS doesn't sell direct, Department C does:
>>> 
>>>         Commodore Business Machines, Inc.
>>>         Department C
>>>         1200 Wilson Drive
>>>         West Chester, PA  19380
>
> --
> Stefan Boberg - AP & EE student at Linkoping Institute of Technology, Sweden
>  Author of LhA, ArjA and LhArcA. Co-author of Alien Breed, Project X ...
>   EMail: boberg@lysator.liu.se, lha@augs.se           FIDO: 2:204/404.7
>     UUCP:  {uunet|pyramid|rutgers}!cbmvax!cbmehq!cbmswe!team17!boberg
Fred Heitkamp,  ** Not an organization.  My opinions only **  
Newsgroups: comp.sys.amiga.programmer
From: jamie@cdevil.unx.sas.com (James Cooper)
Subject: Re: compiler errors
Originator: jamie@cdevil.unx.sas.com
Date: Mon, 12 Oct 1992 14:53:45 GMT
Distribution: comp
Organization: SAS Institute Inc.


In article <1992Oct12.003155.24917@ariel.ec.usf.edu>, stelmack@incubus.csee.usf.edu (Gregory M. Stelmack) writes:
>In article <1992Oct11.4249.17402@dosgate>,
>robert.buonincontro@canrem.com (robert buonincontro) writes:
>|>
>|>    I have recently been using Lattice 6.0, and have found a compiler
>
>#include <proto/intuition.h>
>
>There are also ones for just about every library. Look in INCLUDE:proto to
>find them all.

Umm... and there is no such thing as "Lattice 6.0," unless you are
talking about the old IBM PC version of their compiler.  The last
compiler version Lattice put out for the Amiga was V5.05...

-- 
---------------
Jim Cooper
(jamie@unx.sas.com)                             bix: jcooper

Any opinions expressed herein are mine (Mine, all mine!  Ha, ha, ha!),
and not necessarily those of my employer.
Newsgroups: comp.sys.amiga.programmer
From: comeau@csanta.attmail.com (Greg Comeau)
Subject: C++ and Amiga shared libs (was: Re:  Obj-C vs. C++)
Originator: comeau@well.sf.ca.us
Reply-To: comeau@csanta.attmail.com (Greg Comeau)
Organization: Comeau Computing
Date: Wed, 14 Oct 1992 17:41:04 GMT

In article <67684@cup.portal.com> Lee_Robert_Willis@cup.portal.com writes:
>Greg:  Has anyone looked at how to write C++ classes that will use
>Amiga shared libraries?  i.e. I come up with a great class collection.
>I want to make a shared lib out of it.  Can this even be done?

I have heard of none, but in some cases I am the last to hear.
Anybody else heard?

- Greg
-- 
         Comeau Computing, 91-34 120th Street, Richmond Hill, NY, 11418
                   Producers of Comeau C++ 3.0 With Templates
          Here:attmail.com!csanta!comeau / BIX:comeau / CIS:72331,3421
	    Voice:718-945-0009 / Fax:718-441-2310 / Prodigy: tshp50a
From: mks@cbmvax.commodore.com (Michael Sinz)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: HDMem vs GigaMem for virtual memory on Amigas?
Date: 7 Oct 92 14:20:56 GMT
Article-I.D.: cbmvax.35633
Reply-To: mks@cbmvax.commodore.com (Michael Sinz)
Organization: Commodore, West Chester, PA

markus@techfak.uni-bielefeld.de (Markus Illenseer) writes:
>
[stuff about the MMU deleted]
>
> Peter, i am just wondering... The german manual of the A4000 states that the
> A4000 has an 040EC build in (ok, i must admit: it's mentioned 'probably'),
> and there is a full-featured hand-book about how to upgrade the 040EC to
> a real 040 (remove 040EC, insert 040).
> Now, how long have you been working on the manual ? Seems that the 040
> was a last-minute choice ?
> BTW, Cpu (and SetCpu) both state a 040 on the A4000 i tested, i also wonder
> if they can actually detect an 040EC, as they can't set the FastRom
> MMU table correctly (yet).

The english manual also has this section.  It was written when it was
thought that it may be useful to sell two versions of the A4000, one
with the high-cost full 68040 and one with the low-cost (relative to
the real one) 68EC040.  The same manual would be used in both cases.
Because of this the manual contains information on how to upgrade the
CPU.  This does not mean you need to.  There are other cases in various
manuals where it may talk about upgrading your memory (like on the A3000)
but if you get the A3000-25/100 you already have the 4meg type of memory.
It is invalid to assume that because we tell how to do something that it
is something you need to do.

/----------------------------------------------------------------------\
|      /// Michael Sinz  -  Senior Amiga Systems Engineer              |
|     ///                   Operating System Development Group         |
|    ///   BIX:  msinz      UUNET:  mks@cbmvax.commodore.com           |
|\\\///    By doing the impossible one just proves the point           |
| \XX/     that one can not do the impossible.                         |
\----------------------------------------------------------------------/
From: csg019@cck.coventry.ac.uk (-~=Zaphod=~-)
Newsgroups: comp.sys.amiga.programmer
Subject: 68000 source.
Date: 8 Oct 92 10:02:10 GMT
Organization: Coventry University

When i was first starting out trying to program the amiga in assembly language
the hardest thing in the world is to find some example code. Having had
about 5 years on the amiga writting for various demo groups, i have sold my
amiga. 

This has left me with some source code for various projects i had going
these include:

A demo i did for a Pan-European demo group including bobs, lines, scrollers,
coppers, stars etc.

Part of a game including dual playfield scrolls, sprites etc.

Zdir, the world fastest disk directory program for amiga floppy disks.


All the code is low level stuff (but safe) not your lame library stuff that
people do 'cause they cant be bothered to do it properly.

I'm not responsible for some of the programming methods (i can tell you now
that some of it is baaaddd.)

Email me if you want any of the above.
















-- 
******************************************************************************
*        ///  O O   A member of S.H.I.T. (Super High Intelegence Team)  ///  *
*       ///    u    Fight, defeat and kill organized laming.           ///   *
*  \\\ ///    \-/          csg019@uk.ac.cov.cck ok?		  \\\ ///    *
Newsgroups: comp.sys.amiga.programmer
From: breese@imada.ou.dk (Bjoern Reese)
Subject: Re: Need RELIABLE assembly blitter routine
Organization: Dept. of Math. & Computer Science, Odense University, Denmark
Date: Fri, 16 Oct 1992 13:39:30 GMT

wille@june.cs.washington.edu (Robert Wille) writes:

>In article <OAHVENLA.92Oct15204351@lk-hp-12.hut.fi>, oahvenla@snakemail.hut.fi (Osma Ahvenlampi) writes:
[... stuff deleted...]
>|> BTW: If you're already poking blitter registers, it could be useful to use
>|> btst #14,DMACONR instead of WaitBlit().. Saves time, if you're low on it.

>This is one of the most frequent lies spread by the network.  
>btst #14,DMACONR is NOT equivalent to calling WaitBlit().  In fact, it
>isn't even a valid instruction.  The assembler is translating that instruction
>for you to one that is valid.

Absolutely true!

For those who wonder why ``btst #14,DMACONR'' works, I want to explain.
The ``btst #data,addr'' instruction can only handle a 3 bit wide value
for ``data'', which leaves us with the values 0 - 7. ALSO the instruction
is byte sized (only accessing a single byte at a time.) Why does ``btst
#14,DMACONR'' work then? Well, the assembler takes the ``data'' value and
cuts it down, using a modulo 8. The end-result is a ``btst.b #6,DMACONR''
(14 MOD 8 = 6), which happen to be equal to the desired ``btst.w #14,
DMACONR'' (which of course is invalid.) So far we were lucky, but try
a ``btst #2,DMACONR'' as a way to access bit #2 in the word-sized
DMACONR register. This does not work, because the machine tests bit #2
in the upper-byte of the DMACONR register, which of course is bit #10
(2 + 8 = 10). So to solve this, you will have to use ``btst #2,DMACONR+1''.

I hope to have set some things straight with this posting, as the
``btst #data,addr'' problem is a very common one and it is hard to
spot.

--

Bjoern Reese                   |     Email: breese@imada.ou.dk
Odense University, Denmark     |     Voice: +45 65 932 182 (private)