Initial revision

5 files changed, 247 insertions, 0 deletions

diff --git a/docs/dev/BUGS b/docs/dev/BUGS
new file mode 100644
index 0000000..181ec3d
--- /dev/null
+++ b/docs/dev/BUGS
@@ -0,0 +1,2 @@
+None reported up-to-now ;
+
diff --git a/docs/dev/TODO b/docs/dev/TODO
new file mode 100644
index 0000000..0ef6a7f
--- /dev/null
+++ b/docs/dev/TODO
@@ -0,0 +1,32 @@
+evolutions du mode de fabrication de la librairie ivycpy.so :
+clarifier avec Martin les besoins en macro m4 ;
+
+
+préparer une version 0.4 ayant ces caractéristiques :
+------------------------------------------------------------
+o0 : ajouter les dépendances d'outils de fabrication
+install
+swig
+ivy    test include 
+python test include 
+
+les dépendances de header (include) 
+
+o1 : faciliter le cablage adhoc avec les librairies "dépendances"
+(dont ivycpy dépend):
+- libivy.so , libtclivy.so
+- _tkinter.so (et donc python)
+- libtcl
+
+o2 : faciliter la realisation à la fois :
+- installation adhoc (a partir des sources) avec une target
+- paquet debian
+
+o3 : nettoyer le paquet des anciens modes de travail
+
+o4 : ajouter bindirect dans l'interface et ds les exemples;
+
+o5 : faire une version 0.4 source et debian ;
+
+préparer une version beta 0.5 indépendante de python
+------------------------------------------------------------
\ No newline at end of file
diff --git a/docs/dev/TODO_SITEIVY b/docs/dev/TODO_SITEIVY
new file mode 100644
index 0000000..6622824
--- /dev/null
+++ b/docs/dev/TODO_SITEIVY
@@ -0,0 +1,80 @@
+From: Marcellin Buisson <buisson@cena.fr>, 
+To: François-Régis Colin <fcolin@cena.fr>,
+	Yannick Jestin <jestin@cena.fr>,
+	Christophe Mertz <mertz@intuilab.com>,
+	Didier PAVET <didier.pavet@ath.cena.fr>,
+	pascal.brisset@recherche.enac.fr,
+	Stéphane Chatty <chatty@intuilab.com>,
+	Sébastien Maury <smaury@apple.com>,
+	alexandre bustico <alexandre.bustico@cena.fr>,
+	Philippe Truillet <truillet@irit.fr>,
+	Alexandre Lemort <lemort@intuilab.com>, Eric Blond <blond@cena.fr>, 
+Cc: Marcellin Buisson <buisson@cena.fr>,
+	Gwenael BOTHOREL <bothorel@cena.fr>, 
+Subject: Ivy, web, sources, binaires et compagnie...., 
+Date: Mon, 14 Jun 2004 18:17:28 +0200, 
+Mcnf-Status: ok
+Mcnf-Date: Mon Jun 14 18:19:40 2004
+Mcnf-Att: "/pcnfs/usagers/pavet/.amcnf/msg-1622-1.txt"
+
+	Bonjour à tous,
+
+	C'est en tant qu'auteurs ou empaqueteurs usuels des différentes 
+portages ivy que je sollicite votre aide et vous offre la lecture qui 
+suit :o)
+
+	Comme vous avez pu le constater par vous même (ou comme vous le voyez 
+en vous rendant sur 
+http://www.tls.cena.fr/products/ivy/download/index.html), les sources 
+et les binaires des différents portages d'ivy qui sont distribuées sur 
+le site web datent un peu..ou sont incomplets.. bref c'est un peu le 
+bazar...
+
+	En tant que mainteneur du site web ivy (et donc responsable de 
+l'obsolescence du code mis en ligne) , je me trouve confronté à 
+plusieurs problèmes :
+	
+	- quand mettre à jour les sources d'un portage ?
+	(notion de version d'ivy par exemple, pour environ 10 langages 
+supportés différents, à des états d'avancement différents )
+	
+	- comment gérer les différents empaquetages ?
+	(pour 5 ou 6 architectures, et quelques unes exotiques)
+
+	- comment respecter la LGPL dans notre distribution ?
+	(actuellement par exemple le texte de la LGPL, ou une reference à 
+celle-ci n'est pas présent dans tous les sources disponibles : 
+http://www.gnu.org/copyleft/lesser.txt)
+
+	En l'absence pour le moment d'un espace de collaboration en ligne type 
+wiki, d'un accès anonyme la la base CVS  ivy du CENA, ainsi que de 
+méthodes éprouvées pour *livrer* une version d'ivy, je vous propose la 
+chose suivante (si vous voyez une autre façon de faire, n'hésitez pas à 
+la proposer ! ) :
+
+	Pour le source non disponible actuellement sur la base cvs du CENA 
+(c'est-à-dire tout sauf ivy-ada, ivy-c, ivy-c++, ivy-java, ivy-perl), 
+les auteurs des différents ports pourraient-ils m'envoyer une version 
+actualisée et respectant la LGPL du source (tar.gz par exemple) 
+estampillée "ivy-port-juin-2004" et que vous m'autoriseriez à mettre 
+dans la base cvs du CENA ? (je pense notamment à ivy-csharp, 
+ivy-python, ivy-metacard, ivy-caml, ivy-flash, ivy-com)
+	
+	Pour le source déjà disponible dans la base cvs, pourriez-vous m'aider 
+à inclure les fichiers de licences corrects et à vérifier qu'il est en 
+état (c'est à dire compile par exemple, avec des makefile corrects)
+
+	Ce sera une première étape.
+
+	La seconde étape, c'est de livrer un certain nombre de paquets 
+correspondants à cette livraison de sources. J'aurais alors besoin de 
+votre aide pour empaqueter sous windows, Mandrake 10.0, debian woody et 
+sarge, ipaq, macos X etc etc). Ce qui devrait me permettre ensuite de 
+mettre à jour les pages web ivy et donc de contribuer à son 
+rayonnement, son expansion..sa  prolifération et ainsi de suite...
+	
+	J'attends vos idées, réactions, et surtout votre aide !!
+
+Viva ivy et bonne soirée,
+
+Marcellin.
diff --git a/docs/dev/how2build.html b/docs/dev/how2build.html
new file mode 100644
index 0000000..738bf8e
--- /dev/null
+++ b/docs/dev/how2build.html
@@ -0,0 +1,29 @@
+<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
+<html> <head>
+<title>Ivycpy - buiding instructions</title>
+</head>
+
+<body>
+<H2><A NAME=PURPOSE>Ivycpy - buiding instructions</A></H2>
+<p>First of all ivycpy is building process is managed by autoconf.</p>
+<p>You should have to do the following actions:
+<ul>
+  <li>say to configure where is ivy-c lib and include files (LD_LIBRARY_PATH , CPPFAGS)
+  <li>say to configure where is your version of Python (LD_LIBRARY_PATH ,
+CPPFAGS) (Note: a specific version is required exporting some MACRO def)
+  <li>launching configure with the suited location of tcl/tk configuration file tclConfig.sh and your target
+	  destination:<br>
+	  <em>./configure --prefix=/opt/ivycpy-dp --with-tcl=/opt/tcltk-8.4.5/lib/</em><br>
+	  verify that every test is ok; normally if all is ok, you should be capable to compile and install
+	  without any problems.
+  <li><em>make</em>
+  <li><em>make install </em>
+</ul>
+</p>
+
+
+<hr>
+<!-- hhmts start -->
+Last modified: Mon May 24 16:43:51 CEST 2004
+<!-- hhmts end -->
+</body> </html>
diff --git a/docs/dev/maintainer_notes.txt b/docs/dev/maintainer_notes.txt
new file mode 100644
index 0000000..54a6147
--- /dev/null
+++ b/docs/dev/maintainer_notes.txt
@@ -0,0 +1,104 @@
+Echanges avec Martin Loewis concerant les évolutions de Python et Tkinter
+liés au wrapper python <-> ivy 
+
+
+
+Date: Sun, 13 Jul 2003 18:49:35 +0200
+From: =?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?= <martin@v.loewis.de>
+User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de-AT; rv:1.4) Gecko/20030624
+X-Accept-Language: de, en-us, en
+To: Didier PAVET <pavet@ath.cena.fr>
+Subject: Re: a request / tkinter (ENTER_TCL ENTER_PYTHON macro)
+In-Reply-To: <200307100715.JAA18790@basilic.dev.ath.cena.fr>
+Content-Type: text/plain; charset=us-ascii; format=flowed
+X-Seen: false
+X-ID: rfGYOMZcgeZyNlhDQlB5laNXLu1X06U3wOOZDJ0mi2oMCVtqUb+aQc@t-dialin.net
+
+Didier PAVET wrote:
+
+> Have you allready heard some request in that sens  ?
+
+Dear Didier,
+
+Yes, this is a SourceForge feature request, see
+
+http://python.org/sf/539907
+
+> Does it stand sensible that this patch could be integrated in Python/Tkinter 
+> distribution and are you the right man to do that ? 
+
+In some form, yes, certainly. Merely copying the macros into a header 
+file is not sufficient though: the code has been become much more 
+complex since 2.1, as we now also need to support multi-threaded Tcl 
+installations.
+
+Also, in general, you cannot access C variables across different
+Python extension modules. Instead, you need to expose a CObject of some
+kind. Instead of having that C object refer to the Tcl lock, I'd rather
+provide access to some higher-level function pointers which can take 
+into account the various Tcl installations.
+
+I'd encourage you to work on this for Python 2.4. Please make either 
+Python 2.3 or the Python CVS your starting point, and please submit
+unified diffs to sf.net/projects/python when you are done.
+
+If you have any questions about this approach, don#t hesitate to ask.
+
+Regards,
+Martin
+
+
+Date: 10 Jul 2003 09:07:08 +0200
+From: Didier PAVET <pavet@ath.cena.fr>
+To: martin@v.loewis.de
+Subject: a request / tkinter (ENTER_TCL ENTER_PYTHON macro)
+ 
+Martin,
+
+First of all, thank you for the job to maintain and upgrade python's stuff. 
+My organisation (french R&D center for air navigation) currently benefits from
+python , tkinter material to build prototype, mock-up and so all.
+
+I have a request concerning _tkinter.h and _tkinter.c . In fact, in order to
+build a python wrapper to an in-house middleware library built in C, I have
+faced a problem with macro which aim at protecting interaction between tcl/tk
+mainloop, thread and so on . I mean these macro ;
+ENTER_TCL
+LEAVE_TCL
+ENTER_PYTHON 
+LEAVE_PYTHON
+
+For the moment, these macros are private to _tkinter module and so defined in
+_tkinter.c. My need is to be capable from an external python module (in fact
+my wrapper) to use (and so to share the data) these macros.
+
+I have allready carried out a solution patching Python 2.1.3 distribution and
+packing my library to verify that it works . The solution is to externalize
+and put the macros definition in the header _tkinter.h and allow external
+access to lock as tcl_lock, tcl_state .
+
+2 requests :
+
+Have you allready heard some request in that sens  ?
+Does it stand sensible that this patch could be integrated in Python/Tkinter 
+distribution and are you the right man to do that ? 
+
+Many thanks in advance for your help; it is clear for me that a positive
+answer would avoid me to deliver my wrapper with a patched version of
+Tkinter (solution which is pretty not handy).
+
+I just attached as a tar file my version of _tkinter.h and _tkinter.c derived
+from Python 2.1.3 (debian woody stable version).
+
+Didier
+-- 
+Didier PAVET  Centre d'Etudes de La Navigation Aerienne / (Chef division ICS) 
+Office location 	Phone: (33 1) 69 57 68 89 - Fax: (33 1) 69 57 68 52
+B1608 b025          	   ou 01  69 57 68 89        ou 01  69 57 68 52
+E-mail: pavet@ath.cena.fr WWW: http://www.ath.cena.fr/~pavet
+
+Note : the middleware, target of my wrapper is Ivy;
+have a look at 
+http://www.tls.cena.fr/products/ivy/ or
+http://freshmeat.net/projects/ivy/
+