Menu
▾
▴
multiplatform-devel — Main list for developing Multiplatform
You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(33) |
Oct
(1) |
Nov
(5) |
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
|
Feb
|
Mar
(3) |
Apr
|
May
(1) |
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Stefan M. <sm...@oe...> - 2004-06-06 18:40:02
|
-----BEGIN PGP SIGNED MESSAGE----- Hi! 2 months (68 days) ago Stefan Merten wrote: > Obviously this project has come to a stand-still. I have no time for > doing anything more for Multiplatform so I would really like to give > up maintainership. Anyone who wants to take this over? I posted the following news to the project page: Project dormant The Multiplatform is no longer maintained and has no active developer any more. Therefore there is no support for this project apart from the source code. If you want to pick up the project please drop a note on the mailing list. At least the source code is available. Mit Freien Grüßen Stefan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.7 <http://mailcrypt.sourceforge.net/> iQCVAwUBQMNmYAnTZgC3zSk5AQEQ6QP6A5jnnc78gBGU7upHcq7vCgMZhxIoruvh eCRzA1q73jtxkYMXQw3dFyWJ5CgvSOIOJR75Sab+rCo3jEXTlN3W0CionXA2ydqw SFYhTRAMVcIXvoqyrR2Q7MjNLoNV7VMEatCXI/6d5ZeOs/7Gfcgg0ZSW3TEC9aXL DcZMN101k4E= =lZO7 -----END PGP SIGNATURE----- |
|
From: <ben...@id...> - 2004-05-25 10:43:25
|
Dear Open Source developer I am doing a research project on "Fun and Software Development" in which I kindly invite you to participate. You will find the online survey under http://fasd.ethz.ch/qsf/. The questionnaire consists of 53 questions and you will need about 15 minutes to complete it. With the FASD project (Fun and Software Development) we want to define the motivational significance of fun when software developers decide to engage in Open Source projects. What is special about our research project is that a similar survey is planned with software developers in commercial firms. This procedure allows the immediate comparison between the involved individuals and the conditions of production of these two development models. Thus we hope to obtain substantial new insights to the phenomenon of Open Source Development. With many thanks for your participation, Benno Luthiger PS: The results of the survey will be published under http://www.isu.unizh.ch/fuehrung/blprojects/FASD/. We have set up the mailing list fa...@we... for this study. Please see http://fasd.ethz.ch/qsf/mailinglist_en.html for registration to this mailing list. _______________________________________________________________________ Benno Luthiger Swiss Federal Institute of Technology Zurich 8092 Zurich Mail: benno.luthiger(at)id.ethz.ch _______________________________________________________________________ |
|
From: <tho...@ph...> - 2004-03-31 06:32:27
|
Hi, I've no time either. Ciao, Thomas ___________________________________________ Dr. Thomas Portele Tho...@ph... Senior Scientist Home Dialogue Systems Philips Research Laboratories Aachen Weisshausstrasse 2, D-52066 Aachen, Germany Phone: +49 241 6003-712 Fax.: +49 241 6003-518 |
|
From: Stefan M. <sm...@oe...> - 2004-03-30 19:36:48
|
-----BEGIN PGP SIGNED MESSAGE----- Hi! Obviously this project has come to a stand-still. I have no time for doing anything more for Multiplatform so I would really like to give up maintainership. Anyone who wants to take this over? There is also some interest from an external institution. Grüße Stefan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.7 <http://mailcrypt.sourceforge.net/> iQCVAwUBQGnMaAnTZgC3zSk5AQHP0gP/frugK0de50X4tMA53pm8KDFrhzdH+MJC rSHUGsprkt45fGP2q2CmbMtTe95wA6PvCEq7wF8ALE3hul3twb/89g/+11alPxoE 40f2r1JYs+Mlz8ufpkJqRCxalMf9z6GfJBWvEHkhg2oDNdm7R1wKlzQOxDVuwawX I0R839TvoXc= =Ygag -----END PGP SIGNATURE----- |
|
From: Sander C. <S.V...@uv...> - 2004-03-30 14:27:23
|
Dear all, In the IMIX project (www.nwo.nl/imix), which is in its start-up phase, we consider using the multiplatform system for integration purposes. However, our experience with multiplatform so far have led to some doubts with respect to adopting it for our project. For example, it appears that the system can only be built with the 2.x versions of gcc. For some participants this will be problematic, since their own software may require gcc 3.x in the near future. In general, the fact that multiplatform has not been updated to succesfully work with new versions of gcc, and the lack of any visible activity on the sourceforge site make us wonder whether there still is any support for the system at all. I would appreciate if someone on this list could comment on these issues, so that we can make a well-thought-out decision in favour or against the use of multiplatform. Best regards, Sander Canisius |
|
From: Stefan M. <me...@df...> - 2003-11-11 14:14:56
|
-----BEGIN PGP SIGNED MESSAGE----- Hi! Yesterday Stefan Merten wrote: > Peter finally got around to hand me his Comic distribution. I sorted > out what changes he made. I also added or changed the copyright > notices where appropriate. I.e. I massaged the sources as I did > before checking in the `smartkom' branch. >=20 > I imported these packages >=20 > lib/config > lib/moduleManager > lib/pooldefs > lib/pool2file > mod/gui > opt/base > opt/commentator > opt/logTools >=20 > As I said the new vendor tag is `comic' and lives on branch 1.1.3. >=20 > The remaining modules do not differ from their SmartKom version on > vendor branch `smartkom'. Therefore I did not import them explicitly. > However, I don't know whether this is good because this way >=20 > lcvs -d sm...@cv...:/cvsroot/multiplatform checkout -r= comic source >=20 > results in only the packages with `comic' branches. The remaining > packages are missing. This is not intended. I'll think about it. I changed that by importing the current versions from the `smartkom' branch for all the other packages. Now all packages are included and it should be possible to create the Comic source packages, `make all' them and `make install' them. Gr=FC=DFe Stefan -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQCVAgUBP7Du9wnTZgC3zSk5AQF/LwP+M7AxpCBIKjwV57dUejzQb0FqRAIXKvRn Rfusa8zq8v1bieguv+vLFdnCK7TQcEUYXjoDOT0+E6R/8bb/jQ1gtLCKZiAQDf5w rat/GZi5S0vshsqWqUGqJ6DaGsSyRH4RoekKTlA+JCESXcSoQFcWqdAEeFEbllEb BhUn5rNteRw=3D =3DyFfw -----END PGP SIGNATURE----- |
|
From: Stefan M. <me...@df...> - 2003-11-10 17:42:37
|
-----BEGIN PGP SIGNED MESSAGE----- Hi! Peter finally got around to hand me his Comic distribution. I sorted out what changes he made. I also added or changed the copyright notices where appropriate. I.e. I massaged the sources as I did before checking in the `smartkom' branch. I imported these packages lib/config lib/moduleManager lib/pooldefs lib/pool2file mod/gui opt/base opt/commentator opt/logTools As I said the new vendor tag is `comic' and lives on branch 1.1.3. The remaining modules do not differ from their SmartKom version on vendor branch `smartkom'. Therefore I did not import them explicitly. However, I don't know whether this is good because this way lcvs -d sm...@cv...:/cvsroot/multiplatform checkout -r c= omic source results in only the packages with `comic' branches. The remaining packages are missing. This is not intended. I'll think about it. Gr=FC=DFe Stefan -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQCVAgUBP6/OIwnTZgC3zSk5AQGE8QP/VzKd76royNG++8fzVOqXbrSXTV2gLZB8 KC8B/iqnxrFoKDzXfAwBqTEE51u71tT3E6cH8zGX63Akzhq8jfmnROANwQYU7S3W JRYnyjAyMVZnTPC4AW4MJvoR87AWwSsZVfd+eXd/t3Hdq1YXGNH1LbE81mIXyqX2 Bw03CNP+9sw=3D =3DPzxe -----END PGP SIGNATURE----- |
|
From: Stefan M. <me...@df...> - 2003-11-07 12:19:29
|
-----BEGIN PGP SIGNED MESSAGE----- Hi Mary and all! Yesterday Mary Ellen Foster wrote: > I'm still working on the local firewall issues; thanks for your help in > sorting that out! But now I've got a completely different mu-P question, > about sending messages from threads. If you guys aren't the right ones to > answer this question Heinz is the right one for these questions. I included him in `Cc:'. Also I included the Multiplatform developer list for the reasons mentioned below. I hope you won't mind. > I know that the mu-P classes themselves are not thread-safe. From looking > at other modules' source code, it appears that the thread-safe way to send > messages when threads are involved is to add the messages to an output > queue within the handlers, and to send those messages when the > waitForEvents() method. In pseudocode: > > while( ! stopProcessing ) > waitForEvents( timeout ) > // within the event handler, we add messages to a queue > // of outgoing messages > while( queue is not empty ) > send the next message on the queue, and dequeue it If you are talking about Java this *might* be a correct solution. As far as I can see things work if done in the same thread. In our experience the problem with Java is that threads are created in rather unexpected ways. > Also, from my testing it seems that waitForEvents returns *either* when it > gets an event *or* when its timeout expires, whichever comes first. Is > that correct? It depends. As documented a handler may return 0 or 1 to indicate whether `waitForEvents' should be interrupted (1) or keep going (0). May be this is even the answer to your question. > Anyway, here's how I've been trying to write the pool-event handlers. > > // Event handler > handleMessage() > Create and start one or more threads in response to the message > Return immediately > > // Within each thread > run() > Do some (possibly lengthy) processing > Create one or more mu-P messages to be sent out, > and add them to the queue The problem with this approach is that the execution context handling the message is left soon - in particular independent of whether the desired result has been accomplished or not. Of course this is good for quick response time and introduces a nice asynchronuous behavior of the module but unfortunately this asynchronuous behavior is difficult to cope with. The message queue you mentioned seems one possible solution though it has its drawbacks. In particular you may end up in deadlocks which are broken only by the timeouts. > Now, if I use the structure I defined above, it might be that the messages > created within a thread don't actually get sent until the next time the > waitForEvents() method times out, if there are no other events received in > the meantime. Yes. > It would be nice if there were some thread-safe way to get > the messages created in the threads to be sent "right away", without > having to use an extremely short timeout in waitForEvents(). Sure. May be Heinz can tell more here. > Is this something that can be done within the architecture? Maybe by > interrupting the waitForEvents() method before its defined timeout, or > something like that? The problem is that the underlying PVM does not handle threads. It uses global message buffers (aargh!) and the like. We thought more than once about introducing thread safety in the module manager but never did it. In general there are two possibilites to do this: * A global lock for the whole module manager which forces the calls from threads into a FIFO sequence * Fine grained locks at the places which really need locking The last seemed too complicated and the first too dumb. However, the first solution would be dumb but one can expect a manageable effort. Meanwhile there is multiplatform.sourceforge.net where such patches could be added (for Comic that is when Peter gets around to check in his Comic version of Multiplatform). Since this question comes up again and again it's sure worth a try. > Thanks very much! Hope this helps Stefan -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQCVAgUBP6uN5QnTZgC3zSk5AQEXYwP/VeT/+mg3BzI4KsGc0cTGZV9vuBlUE8n/ EvxLTg2DcHmHUxS8n2qnjT80aJdqfxNe0wd2Q0tuFDWzoDSN8LQpUZNQMxl05gh6 wVrqtL/3I/prKGTwU58vWCwnzow8nydRYXiYOV0hyGGiQ1jMCe6l1i+rTGUCIcRc KTw+Fs3mnko= =s+0l -----END PGP SIGNATURE----- |
|
From: Stefan M. <me...@df...> - 2003-11-06 16:13:08
|
-----BEGIN PGP SIGNED MESSAGE----- Hi! I just added some documentation to https://sourceforge.net/docman/index.php?group_id=3D89988 In particular I started a document giving a general overview over Multiplatform: https://sourceforge.net/docman/display_doc.php?docid=3D19863&group_id=3D= 89988 Please read this document and give * hints about what is missing, * errors on my side, * points which need more explanation or a reference to existing documentation, * and anything else. At the moment I'm planning to describe the countless debugging tools briefly in this document so you need not mention them as missing. Gr=FC=DFe Stefan -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQCVAgUBP6pzKgnTZgC3zSk5AQFyMAP/ff/GGUlCsLlFBI9vQ36trLjM8E9qK+Cd aQLV8mt7MHcp9rrJxe5LSkP4orX86qM6QWyDFjom8tVVRv4++dZzSEyuhwUwdnAK aYvAZWRjW0rP0XY4VTghA+1+LzzOWwyTXB2gjsngu8yvD7Hkg9SoF+c7VJdNX+zS vu1vKYrKpbw=3D =3Dyw4c -----END PGP SIGNATURE----- |
|
From: Stefan M. <me...@df...> - 2003-11-05 14:37:00
|
-----BEGIN PGP SIGNED MESSAGE----- Hi all! Last month (43 days ago) Stefan Merten wrote: > I thought about it and noticed that `lcvs' needs a change (I said that > here already - right?). In the brand new version 1.5.5 I now added a > feature which allows import to a new vendor branch. I did not need > this before. Please download from >=20 > http://www.merten-home.de/FreeSoftware/lcvs/ >=20 > I played around with importing to various vendor branches and found we > need to have explicit branch revision numbers for the various vendor > branches. They must be given to the `-b' option. >=20 > At the moment we are expecting one branch for Comic so I suggest this > is >=20 > 1.1.2 >=20 > while we expect at least one branch from Philips. So I suggest using >=20 > 1.1.3 >=20 > (and upward) for the Philips vendor branches. I re-read the CVS documentation about this and think vendor branches should be always constructed from odd last numbers. Even numbers seem to be used for non-vendor branches. Therefore I suggest using 1.1.3 for the Comic branch and 1.1.5 for the Philips branches. Sorry for the confusion. Also I'm not absoultely sure but the CVS manual seems to suggest this interpretation. Gr=FC=DFe Stefan -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQCVAgUBP6kLHQnTZgC3zSk5AQGD6wP+KLC0BWVWxmzCOtJDQiknghKfiHGfKa+1 dG+SVUPomMuAfpa1E68/cU4Begvzndx+FJyh3brONktI9WX/i+1Pf/zlz6zCLlVd jjR0CrlY5uxwsQwUQ1qDx/dpeDEv79vJPefHoRmlYNoIKQF0E3uuFMBV2Dp+ikoY VUpqMO64hWY=3D =3DNBu2 -----END PGP SIGNATURE----- |
|
From: Stefan M. <me...@df...> - 2003-10-31 12:08:27
|
-----BEGIN PGP SIGNED MESSAGE----- Hi! I finally added all source packages from the last SmartKom source distribution which were not specific to the module interface. I.e. * lib/m3l * opt/whgvis * opt/visualizer * opt/testsuiteTools * opt/visualizationWidgets are missing. For `lib/m3l' I moved the API to an own package `lib/m3lApi' so it is available. IMHO the remaining stuff named above makes little sense because it all depends more or less on the specific SmartKom Schemas. Actually I did not plan to include the Schemas because a lot of copyright issues would needed to be clarified before that. After all the Schemas were not done by the system group alone but in cooperation with many partners. What do you think? These CVS modules are available as of now: base source/opt/base pooldefs source/lib/pooldefs pca source/lib/pca pool2file source/lib/pool2file moduleManager source/lib/moduleManager config source/lib/config tbm source/mod/tbm gui source/mod/gui top source/opt/top perl5 source/lib/perl5 pvm source/lib/pvm xerces source/lib/xerces perlPoolslogLib source/opt/perlPoolslogLib m3lApi source/lib/m3lApi adts source/lib/adts adtPrimitive source/lib/adtPrimitive adtList source/lib/adtList adtTime source/lib/adtTime adtGlobal source/lib/adtGlobal sicstus source/lib/sicstus logTools source/opt/logTools xml source/opt/xml xalan source/lib/xalan commentator source/opt/commentator kirchmann source/opt/kirchmann I divided the `adt' stuff into single modules because this is much easier to maintain because of the dependencies between the ADTs. I made one error in putting `xml' to `lib' instead of `opt' (already corrected above). I'll ask the SourceForge stuff for moving this in the repository. Also there is `source/opt/top'. There is an `INSTALL.sdf' which describes the installation. I added a `sk2mp.pl' script there which I developed during the addition of the source packages. It is pretty good in changing all relevant `sk' / `SmartKom' to `mp' / `Multiplatform'. I guess it can be used equally well for modules which shall run in a Multiplatform environment. Any comments? It would be good if the branches for Comic and Philips could be added now. Gr=FC=DFe Stefan -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQCVAgUBP6JQ0AnTZgC3zSk5AQFidwP/cVC3FTS3LE50tTsdbu1q16fFO3wB8MMU ptCRELncn/WFvsdZ6ZlGumdF+o1QepmTzwzW06xa1UxtCdsuxnXzp8LqDB5YnrPa VAfQOGHeDtP1tB8TdpYe1f2xvIWoxwb4hIt6TnsG4e3VjQrRcU9EqYwU4Q5HlZaD sD69BD54N6o=3D =3D7vz0 -----END PGP SIGNATURE----- |
|
From: Stefan M. <me...@df...> - 2003-09-30 10:21:04
|
-----BEGIN PGP SIGNED MESSAGE----- Hi again! The Java pakages have been located in de.dfki.smartkom until now. For instance `de.dfki.smartkom.lib.adts'. I'll change the prefix to org.multiplatform BTW: I'm hacking together a Perl script filtering SmartKom strings to Multiplatform strings. I guess this will be interesting for everyone who wants to follow this change. Gr=FC=DFe Stefan -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQCVAgUBP3lZEAnTZgC3zSk5AQHUwAP9G7J9cwQjvx7zCm20N7Qa4B14+FBU9g4X wBDPZhhVUYfJli+SbSgjo3p539HGNH05o7GHyGJI1OZCU1SH/k9CdFnyNk9w2o83 cyY5F78VLce9RbI1bjjyj1/qD9grttD3TlfND9R//hLVYSX4S8ltwkxQ+lGPdcpu YzHh9ftpLsE=3D =3DMfdB -----END PGP SIGNATURE----- |
|
From: Stefan M. <me...@df...> - 2003-09-30 09:58:40
|
-----BEGIN PGP SIGNED MESSAGE----- Hi! While changing `sk' to `mp' I just ran into another question. Should I change all the `Sk's in the names of variables defined by the MakeIncludes? I'm asking because IMHO the MakeIncludes need to be substituted by a more powerful and yet more understandable solution anyway so to me it makes little sense to change things here and it causes some more trouble for existing projects. In less hectic hours I already laid the foundations for such a solution. If you are interested take a look at https://savannah.nongnu.org/projects/mamo/ I for one am planning to create (at least) a branch in Multiplatform CVS which replaces the MakeIncludes-`Makefile's by Mamo-`Makefile's. This is useful for both projects because Multiplatform is a typical target for Mamo and Mamo has a big project to sort bugs and quirks. Any comments? Gr=FC=DFe Stefan -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQCVAgUBP3lT0gnTZgC3zSk5AQED2QP+Kuc4Km6aMuIcDigwv4/WhQrIyya6H236 yPl6ql0ryYpz8491WNopElXzpOa1zBBafzNQqLnuYnfyrGLvqPc1k9fBIUaV+RGs fhWuv2Q80KMEu6h6AkEL3PAxiXn6kr/ofirjyqP+4O2Z5qSd+2O5DmFGPwELLtvr wJKDo+/VVJY=3D =3DjTWI -----END PGP SIGNATURE----- |
|
From: Stefan M. <me...@df...> - 2003-09-30 09:23:15
|
-----BEGIN PGP SIGNED MESSAGE----- Hi Thomas! Yesterday thomas portele wrote: > I have some general trouble with the rich tree. If I want to use sever= al different applications > using one system tree, Why? I think it useful to understand your reasons. Indeed the system tree is not made for this. > the tree is a mixture of application dependant info (e.g. SmartKom.ptp= ) > which our Philips start scripts are always overwriting, system librari= es, and other stuff. True. > Although probably a major task, I would argue to divide the tree in= to 'static' stuff like > scripts and libraries, and dynamic configuration infos (e.g. the DTD= ). Actually Multiplatform can be divided in a "static" part and an application specific part. For some parts this division is obvious. For instance `lib/pca' is not application specific. On the other hand the DTD / Schemas used for the interfaces are clearly application specific. I already noticed this is a problem so I agree with you. Unfortunately in some cases both is closely intermixed - at least in the way things are done at the moment. Yes, I think we need to look into this some time. Until then it might be possible to use symbolic links for the static parts. > Unfortunately I have neither solved my access problems, :-( > nor will I have much time till > the end of the year as I am dividing my time between several > projects. As far as I can foresee the near future I can focus on Multiplatform for the next two months. At the moment I think in December I'll take my remaining holiday and what the next year brings is yet very unclear... > So I will not > be of much help for some time, except raising issues like above :-( But this is a help :-) . After all you are experienced the problems others will have, too. What we really need it that you contribute the Philips version to the CVS tree. Then everybody can work with it. Gr=FC=DFe Stefan -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQCVAgUBP3lLhwnTZgC3zSk5AQEkrwP/WnRRnCmTQ6XUIO64HPFA+FpXcA6y7RPK JiyhCbGFVP7q5hjwxqW+ty0Npgoxv2bmq4HBmVxFU4+8hlUb8M1sksFaD90KQ+uf QYXN4h/fyx0AK9fWDhYoUVPqh26iq26v48eQGflDfaZ8w45fx/g8EmwskBRg+dZf /+eALTJogg0=3D =3Dys9y -----END PGP SIGNATURE----- |
|
From: <tho...@ph...> - 2003-09-29 12:45:10
|
Hi Stefan, I have some general trouble with the rich tree. If I want to use sever= al different applications using one system tree, the tree is a mixture of application dependant= info (e.g. SmartKom.ptp) which our Philips start scripts are always overwriting, system librari= es, and other stuff. Although probably a major task, I would argue to divide the tree in= to 'static' stuff like scripts and libraries, and dynamic configuration infos (e.g. the DTD= ). Unfortunately I have neither solved my access problems, nor will I h= ave much time till the end of the year as I am dividing my time between several proje= cts. So I will not be of much help for some time, except raising issues like above :-( Ciao, Thomas Dr. Thomas Portele Thomas.Portele@philip= s.com Philips Research Laboratories Man-Machine Interfaces Weisshausstrasse 2 52066 Aachen, Germany Phone: +49 241 6003-712 Fax.: +49 241 6003-518 = = =20 = = =20 T= o: mul...@li... = =20 c= c: Stefan Merten <me...@df...> = =20 = (bcc: Thomas Portele/ACN/RESEARCH/PHILIPS) = =20 S= ubject: Re: [MP-d] Alternative to `SK_HOME' = =20 Stefan Merten <me...@df...> = = =20 C= lassification: = =20 Sent by: = = =20 mul...@li...urceforge = = =20 .net = = =20 = = =20 09/29/2003 11:58 AM = = =20 Please respond to multiplatform-devel = = =20 = = =20 = = =20 -----BEGIN PGP SIGNED MESSAGE----- Hi! 3 days ago Stefan Merten wrote: > I'm wondering about a good alernative to `SK_HOME'. ... My final conclusion was to have an uniform method consisting of two steps: * In general the pointer to the root of the system tree is a parameter to the `SmartKom' / `Multiplatform' script. This parameter would be given by an option. I think `-h'/`--home' is a good idea. * The `SmartKom' / `Multiplatform' script sets environment variable `MP_HOME' so all subsequent processes inherit this value treating it as a constant pointing to the rich structure system tree. Any process needing access to the system tree can obtain it by the environment variable then. This needs no changes in existing software (beyond `SK'/`MP' changes). Of course the environment is modified by `SmartKom' / `Multiplatform' according to `local/SmartKom.env' / `local/Multiplatform.env' as usual. As an alternative `MP_HOME' might be set in the environment. However, I think a warning suggesting use of the respective option is a good idea. This allows for things like alias SmartKom 'Multiplatform --home $SK_HOME' > Also we need to know which operations are actually affected by > `SK_HOME'. Of course running a Multiplatform based system is strongly= > affected by `SK_HOME'. The other main operation which comes to mind i= s > running `make'. Are there any more? Ah - debugging is an additional > case. Some of the debugging tools need to run in the (correct) > Multiplatform environment. Anything else? Does anything else come to mind? In particular: Does any operation come to mind where the concept outlined above may not work? What about Windows? I'll start changing `SK'/`MP' `smartkom'/`multiplatform' now in all existing packages. = Gr=FC=DFe = Stefan -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQCVAgUBP3gCLwnTZgC3zSk5AQGb4gP6AjvzkahxcFnxIhzdh0xqQ6t3lHPU1sLd os/BIhvKQlbSglSc3oxxWr3zKqUmY72YRByrrsU2oNNyiWU5seswdtyhXyaq19fl TGctodEhj1kdf5EHf7FE18XaIM5j+BwuHDgvWxgg1mjcTZHjFsG+JWf79wsFTO8q 3cx6XhsAKKc=3D =3DDNIt -----END PGP SIGNATURE----- ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ multiplatform-devel mailing list mul...@li... https://lists.sourceforge.net/lists/listinfo/multiplatform-devel = |
|
From: Reichel, K. <re...@me...> - 2003-09-29 12:07:53
|
Hallo, Steffan wrote: >My final conclusion ......... The method suggested by Stefan is ok.=20 With the conversion of SK... to MP... also inconsistencies by the integration can be found. In the next time I have to work order development. I try to find however something time for multiplatform-level. Mit freundlichen Gr=FC=DFen Kerstin Reichel Entwicklungsingenieur MediaInterface Dresden GmbH Sprach- und Dialogsysteme Washingtonstr. 16/16a D-01139 Dresden Tel. +49 (0) 351/5 63 69-27 Fax +49 (0) 351/5 63 69-19 mailto:re...@me... http://www.mediainterface.de |
|
From: Stefan M. <me...@df...> - 2003-09-29 10:23:38
|
-----BEGIN PGP SIGNED MESSAGE----- Hi! 3 days ago Stefan Merten wrote: > I'm wondering about a good alernative to `SK_HOME'. ... My final conclusion was to have an uniform method consisting of two steps: * In general the pointer to the root of the system tree is a parameter to the `SmartKom' / `Multiplatform' script. This parameter would be given by an option. I think `-h'/`--home' is a good idea. * The `SmartKom' / `Multiplatform' script sets environment variable `MP_HOME' so all subsequent processes inherit this value treating it as a constant pointing to the rich structure system tree. Any process needing access to the system tree can obtain it by the environment variable then. This needs no changes in existing software (beyond `SK'/`MP' changes). Of course the environment is modified by `SmartKom' / `Multiplatform' according to `local/SmartKom.env' / `local/Multiplatform.env' as usual. As an alternative `MP_HOME' might be set in the environment. However, I think a warning suggesting use of the respective option is a good idea. This allows for things like alias SmartKom 'Multiplatform --home $SK_HOME' > Also we need to know which operations are actually affected by > `SK_HOME'. Of course running a Multiplatform based system is strongly > affected by `SK_HOME'. The other main operation which comes to mind is > running `make'. Are there any more? Ah - debugging is an additional > case. Some of the debugging tools need to run in the (correct) > Multiplatform environment. Anything else? Does anything else come to mind? In particular: Does any operation come to mind where the concept outlined above may not work? What about Windows? I'll start changing `SK'/`MP' `smartkom'/`multiplatform' now in all existing packages. Gr=FC=DFe Stefan -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQCVAgUBP3gCLwnTZgC3zSk5AQGb4gP6AjvzkahxcFnxIhzdh0xqQ6t3lHPU1sLd os/BIhvKQlbSglSc3oxxWr3zKqUmY72YRByrrsU2oNNyiWU5seswdtyhXyaq19fl TGctodEhj1kdf5EHf7FE18XaIM5j+BwuHDgvWxgg1mjcTZHjFsG+JWf79wsFTO8q 3cx6XhsAKKc=3D =3DDNIt -----END PGP SIGNATURE----- |
|
From: Stefan M. <me...@df...> - 2003-09-29 10:14:55
|
-----BEGIN PGP SIGNED MESSAGE----- Hi Peter! 11 minutes ago Stefan Merten wrote: > as far as I understood the information and suggestions given by Stefan = about > opening Comic-specific things, e.g. opening a branch: I agree. Good. > One thing: I'm currently busy with building up a new Comic testbed for = the > next demonstrator integration (by "merging" the most recent SmartKom te= stbed > 5.1 and the Comic specific things). My delivery deadline is October, > 2. Therefore I'd like to postpone all comic-specific multiplatform acti= vities > after my deadline. Is that ok for everybody or are there any objections= ? Take your time. One of the nice things of CVS is that you can do anything at any time. Gr=FC=DFe Stefan -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQCVAgUBP3gGIgnTZgC3zSk5AQH0eAP/Y8qaAhlprmASf+voacnjFt9eE605oi/O 9mVh9o6s8OPmsxDZCxjgUgEKLE+0RL2J1Q+Fh4w1bmwmmwS/soFcNzZt/FbaSeL3 ZyvEb/IGgLJO5kk2kkqjPl0khWiYlkgYJ5k5UjrygpKV3m7U/wvqen8K2JkVbic6 my6lmbCBsRA=3D =3DYY+f -----END PGP SIGNATURE----- |
|
From: Stefan M. <me...@df...> - 2003-09-29 10:03:00
|
-----BEGIN PGP SIGNED MESSAGE----- Hi! Peter wrote a mail to me personally stating the following mail does not geht through to this list. He tried several times without any effect :-( . I'm forwarding it here so it is at least known. If this problem persists I think I need to contact the SourceForge staff. I checked the settings for the mailing list and I can's see a reason for this behaviour on this side. Gr=FC=DFe Stefan - ------- Forwarded Message Hi together, as far as I understood the information and suggestions given by Stefan ab= out opening Comic-specific things, e.g. opening a branch: I agree. One thing: I'm currently busy with building up a new Comic testbed for th= e next demonstrator integration (by "merging" the most recent SmartKom test= bed 5.1 and the Comic specific things). My delivery deadline is October, 2. Therefore I'd like to postpone all comic-specific multiplatform activi= ties after my deadline. Is that ok for everybody or are there any objections ? Best, Peter Stefan Merten writes: > -----BEGIN PGP SIGNED MESSAGE----- >=20 > Hi all! >=20 > 4 days ago Stefan Merten wrote: > ... > > * Import your sources to your branch. > >=20 > > Ahm - I need to think about how to do that. This is a critical > > operation and it can make the repository quite ugly if done wrong. > >=20 > > I'll experiment a bit here and tell you about what I think is > > useful. >=20 > I thought about it and noticed that `lcvs' needs a change (I said that > here already - right?). In the brand new version 1.5.5 I now added a > feature which allows import to a new vendor branch. I did not need > this before. Please download from >=20 > http://www.merten-home.de/FreeSoftware/lcvs/ >=20 > I played around with importing to various vendor branches and found we > need to have explicit branch revision numbers for the various vendor > branches. They must be given to the `-b' option. >=20 > At the moment we are expecting one branch for Comic so I suggest this > is >=20 > 1.1.2 >=20 > while we expect at least one branch from Philips. So I suggest using >=20 > 1.1.3 >=20 > (and upward) for the Philips vendor branches. >=20 > Ok. So now we have laid the foundations for the imports. >=20 > Now it is time to tell you something about the module system I > employed (and `lcvs' needs). The basic idea is that each package gets > an own (CVS) module name in the repository. I.e. it has an entry in > `CVSROOT/modules'. You don't need to care about creating this entry > because it is already there and `lcvs' is caring about it anyway. >=20 > The adavantage of these modules is that all packages are independent > from each other. You can check out one module and work with that > without needing the whole source tree for Multiplatform. >=20 > You may check which modules exist currently by >=20 > lcvs -d AC...@cv...:/cvsroot/multiplatform checkout -= c >=20 > The left column shows the module name while the right column shows the > location of the module in the CVS repository. You'll notice that the > module names are just the basenames of the respective directories. One > should not make things more complicated than necessary - but also not > less ;-) . >=20 > If you import your version of the sources you should do this on a > module by module basis. For example Peter may start with >=20 > cd source/opt/base > lcvs -d pp...@cv...:/cvsroot/multiplatform -m 'Import= ed from Comic.' -b 1.1.2 source/opt/base comic base >=20 > Again please double check that this does not introduce unwanted files > as I tried to explain in my last mail. If you are in doubt I am ready > to help in any thinkable way. >=20 > BTW: Once you get an checked out version of the sources you don't need > `-d AC...@cv...:/cvsroot/multiplatform' any more > because this is recorded in the local CVS administrative files then. >=20 > BTW: You don't need to worry about the module named `top'. I added > that to hold some files which should be in the top level directory of > the source tree. >=20 > Ok. I think this is it. Let's hope that Thomas gets his `ssh' through > to SourceForge. Please tell me of any progress. >=20 > Ah, one more thought. It is possible to employ means to get noticed > when the repository is changed. I did not employ anything yet. I'll > think about that. >=20 >=20 > Gr=FC=DFe >=20 > Stefan >=20 > -----BEGIN PGP SIGNATURE----- > Version: 2.6.2 > Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface >=20 > iQCVAgUBP3BvZQnTZgC3zSk5AQFLZAQAgSuLiCJPR6AHkqlrW1ERBOgYzblP7tRA > VihyMdH4g5aACbzwCFH6A7fDd4fenfSrwREhhlyiOs5Kjm3R6ExkqjgATTxC45q7 > 7I9stCrOFSg9dkjoLUrxPbvYijl7FwBz64UWaT9lHXtVK37U98K3KyXqktjTQT+T > QUqsrVyLSjs=3D > =3Dvgcs > -----END PGP SIGNATURE----- >=20 >=20 > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > multiplatform-devel mailing list > mul...@li... > https://lists.sourceforge.net/lists/listinfo/multiplatform-devel >=20 - ------- End of Forwarded Message -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQCVAgUBP3gDLQnTZgC3zSk5AQE/BAP9G55CBb+Q+7GA59FeRIsOhWmU4DKzAt6V 4Z4GFCJJChzxOvNTbYd7hzL7YvfCfhEfW8APCGJ0FIB9FgVVlfBoXcuD6NCDsh9+ 7s3tA1XbwOzh2C7BNxNYGxXJEHCdWjPMDoUMX9JHBwlf4w6QB2sPbuBxsjNiKQHb UlRjQW+aTEY=3D =3DwKMI -----END PGP SIGNATURE----- |
|
From: Stefan M. <me...@df...> - 2003-09-26 14:13:26
|
-----BEGIN PGP SIGNED MESSAGE----- Hi! I'm wondering about a good alernative to `SK_HOME'. The immediate answer is probably `MP_HOME' but there is one drawback: If you have more than one instantiation of Multiplatform - say SmartKom and Comic - - you have to switch an environment variable to point to the right directory. To me this sounds like a bad idea because this is a rather error-prone solution (as all those know who had to work with two different SmartKom system trees at one time). We talked about this problems in the system group some weeks ago but had no convincing idea. Do you have an idea how to deal with this problem? Because `SK_HOME' is at the very base of Multiplatform I think we need a robust solution here. Hmm... while I'm at it I can try to ramble a bit about the problem. What is the real problem anyway? I'd say it can be described like this: There are a number of different operations you want to execute in a certain environment - namely `make' or running the Multiplatform based system. Until now this environment was defined by the value of the environment variable `SK_HOME'. The value of this environment variable pointed to the system tree which held all the definitions and resources those operations could possibly want. So `SK_HOME' worked as a pointer to a rich structure. The advantage - and drawback - of an environment variable is that it is a process global variable you don't need to care about. Once set it is available without needing further action. In this case it acts even as a global constant. This was ok as long as there was only one software system which could be a possible target. A constant is nice for this type of problems. But as I noted above even then it was a pain to work with two slightly different system trees - say a current and an older version. Hmm... So if this global variable / constant is a problem now this pointer should become a parameter to the operations mentioned above in some way then. The problem is: Where should the parameter be set and where should it be stored so it can be retrieved as easy as an environment variable? Also we need to know which operations are actually affected by `SK_HOME'. Of course running a Multiplatform based system is strongly affected by `SK_HOME'. The other main operation which comes to mind is running `make'. Are there any more? Ah - debugging is an additional case. Some of the debugging tools need to run in the (correct) Multiplatform environment. Anything else? For running the system the solution is pretty simple: Give it the value of `SK_HOME' as a parameter instead of using an environment variable. For their convenience people can create aliases then and it is clear whether they run `SmartKom' or `Comic'. The same is true for the debugging phase. Many of the debug tools needed to be run by `SmartKom' anyway so it is just straightforward to put the parameter there. `SmartKom' - or `Multiplatform' then - can put this parameter to an environment variable - say `MP_HOME' - and it is available to all children then. I.e. for existing calling schemes there need not be changed anything. No module need to get an additional option or something. The value is constant for all sub-proceses while it is a parameter for the one who runs it. The situation is different, however, for the `make' operation. For instance the `Makefile's refer to `SK_HOME' to find the MakeIncludes. `SK_HOME' is used in many places to refer to the environment. `make' can be given parameters using `SK_HOME=3D...'. This gives the pointer to the rich environment. `make' could be started by `Multiplatform' just as any other operation. This would have the advantage that this is a uniform concept then applying to all types of operation: To execute an operation related to a Multiplatform based system one need to start things using the `Multiplatform' startup script. This script sets up all the environment possibly necessary. It is given a pointer to the root of the system tree by a parameter. If this parameter is optional in simple cases - i.e. exactly one Multiplatform based system - one could even set the environment variable her/himself and s/he's done. In addition such a solution would be easy to implement because it needs no changes in existing modules (beyond referring to `MP_HOME' instead of `SK_HOME'). For the `SmartKom' / `Multiplatform' startup script it is also a simple change: Just use one option to set the environment variable instead of expecting it in the environment. Hmm... the longer I think about it the more find it a good solution. Where am I thinking wrong? Other comments? Gr=FC=DFe Stefan -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQCVAgUBP3RJhgnTZgC3zSk5AQHZRgP/U2mk/7i+6bEtBLZ2wH1OQb5U7J+oGb8B u2r4HNcKX2sNEv1/DlKa91KlGL932VeZmEUS5aPxMxFU32G679yE2B3u/gZ9TQd2 ZDuyx2eLLQZ7TxPPjWJ3RzFBYtlV+Y/PzH7Z+UBU/sSMOVDfXnmtrCFaaNTrdzJV 9q7nuopNtFs=3D =3DcXxP -----END PGP SIGNATURE----- |
|
From: Stefan M. <me...@df...> - 2003-09-25 11:37:12
|
-----BEGIN PGP SIGNED MESSAGE----- Hi Heinz! Heinz just joined the team. Now we have the other very seasoned Multiplatform developer with us :-) . 3 days ago Stefan Merten wrote: > 4 days ago Stefan Merten wrote: >> Yesterday Stefan Merten wrote: >>> Hi Thomas! >>>=20 >>> Welcome as a Multiplatform developer :-) . Nice to have you here :-) . >>> I gave you next to all permissions SourceForge has in the different >>> project areas. >>=20 >> The same is true for you, Peter. >=20 > And the same for you, Kerstin. And for you, Heinz. In addition to the normal permissions I gave you administrative permissions. Just in case I'm not available for any reason. >>> I subscribed you to this mailing list because at the moment this is >>> the main means of communication. I used your Philips account. If you >>> don't like that please change it by using the Mailman web frontend. >>=20 >> The same is true for you, Peter, however, for your DFKI account. >=20 > Again I subscribed you to this list. This time I with your > Mediainterface account. Heinz is on the list for a few days already. >>> For a start please check the mailing list archive at >>>=20 >>> http://sourceforge.net/mailarchive/forum.php?forum=3Dmultiplatform-d= evel >>>=20 >>> and comment on this. In particular check my thoughts on having >>> multiple branches for the multiple derivations of Multiplatform. >>>=20 >>> If you have any questions feel free to ask here so others may obtain >>> typical questions and answers from the mailing list archive. >>=20 >> Again, this applies to you, too. >=20 > True for you, too. Though you have the opportunity to ask me personally I'd recommend putting more important questions here so others may get the answers even before they can think of the question. Gr=FC=DFe Stefan -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQCVAgUBP3LTaQnTZgC3zSk5AQEbgAP/TRHUe4VNNXKDLfUKpoi90wMoVP7Z3jUW cFt6tWbtg7EffvdNzdD8i6xHtXvW2tY9WKfnivbjJy+AYtyQTe5TFhc8DzDVBLQJ KZMyl20lrpYthN/07XpEzyDj5dr1bhiv2ro0vLWgjuPJZKguBJ4r9qbQ+Yag8PzK E/aG8SNb22E=3D =3DkX2o -----END PGP SIGNATURE----- |
|
From: Stefan M. <me...@df...> - 2003-09-25 11:03:44
|
-----BEGIN PGP SIGNED MESSAGE----- Hi! Yesterday I created a new mailing multiplatform-cvs with its homepage at https://lists.sourceforge.net/lists/listinfo/multiplatform-cvs This mailing list is for mailing commit messages to all interested people. You may subscribe if you are interested in this information. Right now nothing is put there, however. I thought about how to generate such mail, checked the existing options and found them all a bit ugly. Particularly I find it makes no sense to send a mail for *each* changed file. The whole idea of `lcvs' is to make commits module-oriented. I think I will add another feature to `lcvs' which providing this functionality. Another note about mail performance. Currently mail performance on SourceForge seems awfully bad. As Peter just noted it sometimes takes hours until a mail gets through to the list. I hope this will be resolved soon. Gr=FC=DFe Stefan -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQCVAgUBP3LLkAnTZgC3zSk5AQFLPwP9EjGDiHmzBCww+DzW8NQEOYrCA+WH8Tc1 6DMp1UhVt8G0zfaa8qs8L7uARB3kDmJnjK3vptS2Q0uyQhO0H+WE7WQWo0Idro4O t4FPEN9wk9UL+OMduhN9hpRs/SIvzpii+Wfk2qwO0BCllAbI5kVS/PuLiyvMdvd0 Mp/pFtqoVus=3D =3Dirhb -----END PGP SIGNATURE----- |
|
From: Stefan M. <me...@df...> - 2003-09-24 12:01:04
|
-----BEGIN PGP SIGNED MESSAGE----- Hi Thomas! Yesterday thomas portele wrote: > we are not allowed to have outbound traffic save using our proxie= s. Sourceforge indicates other > ports (e.g. 80) are supported, and it's easy to set that in ssh, but = I have no idea how to tell ssh to > use our proxy (btw I use openssh, I'll have a closer look if time allo= ws it). I think you already discovered https://sourceforge.net/docman/display_doc.php?docid=3D768&group_id=3D1#= firewall I played around a bit with this and for me the following worked: $ setenv CVS_RSH "lcvs" $ setenv LCVS_RSH "ssh1 -x -v -P -p 80" $ lcvs -d sm...@cv...:/cvsroot/multiplatform checko= ut -c I guess it'll work with OpenSSH as well. May be you actually need to use `lcvs' here because `CVS_RSH' does not allow for options as far as I can see. However, this still doesn't use a proxy for outgoing traffic :-( . In OpenSSH manual page there is listed a configuration option `ProxyCommand' which sounds like it could be useful. Perhaps it could be used to login to your proxy? Ah - if you can login to the proxy do things work from that machine? > If that remains difficult I will use my home account. Good. Gr=FC=DFe Stefan -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQCVAgUBP3FbgAnTZgC3zSk5AQHWSwQApzSinTi62sMLS+w2vhbYEd1K+OWOADK7 JGIDUipA2Kp04i6Ec7zWTex8sv9rJs3M+p6GJmgV/WFM1//DOLsTgTjyWYo1WIMK J+7wbrW9ZvjtaNgDINBGD+Yp7VrO3DhmVVU9+ZOUvAN50Y0ldm8mQUHzh8stCrbL /T901sOA6pg=3D =3D+LwY -----END PGP SIGNATURE----- |
|
From: Stefan M. <me...@df...> - 2003-09-23 16:06:07
|
-----BEGIN PGP SIGNED MESSAGE----- Hi all! 4 days ago Stefan Merten wrote: ... > * Import your sources to your branch. >=20 > Ahm - I need to think about how to do that. This is a critical > operation and it can make the repository quite ugly if done wrong. >=20 > I'll experiment a bit here and tell you about what I think is > useful. I thought about it and noticed that `lcvs' needs a change (I said that here already - right?). In the brand new version 1.5.5 I now added a feature which allows import to a new vendor branch. I did not need this before. Please download from http://www.merten-home.de/FreeSoftware/lcvs/ I played around with importing to various vendor branches and found we need to have explicit branch revision numbers for the various vendor branches. They must be given to the `-b' option. At the moment we are expecting one branch for Comic so I suggest this is 1.1.2 while we expect at least one branch from Philips. So I suggest using 1.1.3 (and upward) for the Philips vendor branches. Ok. So now we have laid the foundations for the imports. Now it is time to tell you something about the module system I employed (and `lcvs' needs). The basic idea is that each package gets an own (CVS) module name in the repository. I.e. it has an entry in `CVSROOT/modules'. You don't need to care about creating this entry because it is already there and `lcvs' is caring about it anyway. The adavantage of these modules is that all packages are independent from each other. You can check out one module and work with that without needing the whole source tree for Multiplatform. You may check which modules exist currently by lcvs -d AC...@cv...:/cvsroot/multiplatform checkout -c The left column shows the module name while the right column shows the location of the module in the CVS repository. You'll notice that the module names are just the basenames of the respective directories. One should not make things more complicated than necessary - but also not less ;-) . If you import your version of the sources you should do this on a module by module basis. For example Peter may start with cd source/opt/base lcvs -d pp...@cv...:/cvsroot/multiplatform -m 'Imported = from Comic.' -b 1.1.2 source/opt/base comic base Again please double check that this does not introduce unwanted files as I tried to explain in my last mail. If you are in doubt I am ready to help in any thinkable way. BTW: Once you get an checked out version of the sources you don't need `-d AC...@cv...:/cvsroot/multiplatform' any more because this is recorded in the local CVS administrative files then. BTW: You don't need to worry about the module named `top'. I added that to hold some files which should be in the top level directory of the source tree. Ok. I think this is it. Let's hope that Thomas gets his `ssh' through to SourceForge. Please tell me of any progress. Ah, one more thought. It is possible to employ means to get noticed when the repository is changed. I did not employ anything yet. I'll think about that. Gr=FC=DFe Stefan -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQCVAgUBP3BvZQnTZgC3zSk5AQFLZAQAgSuLiCJPR6AHkqlrW1ERBOgYzblP7tRA VihyMdH4g5aACbzwCFH6A7fDd4fenfSrwREhhlyiOs5Kjm3R6ExkqjgATTxC45q7 7I9stCrOFSg9dkjoLUrxPbvYijl7FwBz64UWaT9lHXtVK37U98K3KyXqktjTQT+T QUqsrVyLSjs=3D =3Dvgcs -----END PGP SIGNATURE----- |
|
From: <tho...@ph...> - 2003-09-23 15:13:18
|
Hi,
we are not allowed to have outbound traffic save using our proxies. Sourceforge indicates other
ports (e.g. 80) are supported, and it's easy to set that in ssh, but I have no idea how to tell ssh to
use our proxy (btw I use openssh, I'll have a closer look if time allows it).
If that remains difficult I will use my home account.
Ciao,
Thomas
Dr. Thomas Portele Tho...@ph...
Philips Research Laboratories Man-Machine Interfaces
Weisshausstrasse 2 52066 Aachen, Germany
Phone: +49 241 6003-712 Fax.: +49 241 6003-518
To: mul...@li...
cc: Stefan Merten <me...@df...>
(bcc: Thomas Portele/ACN/RESEARCH/PHILIPS)
Subject: Re: [MP-d] Re: Parallel branches for existing derivations
Stefan Merten <me...@df...>
Classification:
Sent by:
mul...@li...urceforge
.net
09/23/2003 10:54 AM
Please respond to multiplatform-devel
-----BEGIN PGP SIGNED MESSAGE-----
Hi Thomas!
1 hours ago thomas portele wrote:
> it seems I am having problems with our firewall.
:-(
I have a firewall / address translation configuration at home which
works without any problems. However, this firewall does not prevent
outbound connections.
> I.e. ssh to sourceforge does not work.
This is a prerequisite for playing an active role as far as I can see
:-( .
> One possibility is using another port (e.g. 80) but I have not yet figured out how
> to tell ssh to use our HTTP proxy for the connection.
So it seems the access to the outbound port is blocked. That's bad.
Why does someone want to block outbound traffic for port 22? Anyway.
A useful general tip with all these problems is the `-v' flag of
`ssh'.
Another useful information is which version of `ssh' you are using. To
my knowledge there are three main streams out there: `ssh1' and `ssh2'
by SSH Corp. and `ssh' by OpenSSH which combines version 1 and version
2 functionality. Just a few days ago I checked the current state of
affairs and learned that OpenSSH is the best choice because it is most
interoperable and has a number of options.
In OpenSSH there are some options for ports:
-p port
Port to connect to on the remote host. This can be specified on
a per-host basis in the configuration file.
-P Use a non-privileged port for outgoing connections. This can be
used if your firewall does not permit connections from privileged
ports. Note that this option turns off RhostsAuthentication and
RhostsRSAAuthentication for older servers.
May be `-P' might help you. After all using privileged ports I could
imagine to be a reason for blocking.
Hope this helps
Stefan
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface
iQCVAgUBP3AKVgnTZgC3zSk5AQHYjAP+O/bn/WKdYH49+i/nJQ2Z+XHABF5J9j5g
rz6syQVtKPFTqjWnTrg6S2LS+c1FJ2AweRZnghkDF1nkT9mNY/zuTt5PT+KVn8ts
nZuWYTj2bwkWzjkJRuJRgcyBPsluRT9Ow/+Pg3vq5RXJNEy7yqwZMFsMyB330Sc3
EwVY/Jp6NCY=
=MLt6
-----END PGP SIGNATURE-----
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
multiplatform-devel mailing list
mul...@li...
https://lists.sourceforge.net/lists/listinfo/multiplatform-devel
|
1 message has been excluded from this view by a project administrator.
