Menu
▾
▴
tcl-core
|
From: Andreas K. <a.k...@we...> - 2000-09-10 02:46:51
Attachments:
P.tgz
|
> Although I am not on the core team, I would like to propose to them > that a RFC/PEP system be put in place soon to allow RFC/PEP type > proposals and discussions to begin. > I thought the core team was ready to start recieving these messages, > but Mark Harrison said in the news group that you are not: Unfortunately true. > (snipped from comp.lang.tcl): > To start recieving RFCs I don't think there is too > much work that needs to be done. > The process used by Perl and Python is almost identical. > You can read about them at: > > http://dev.perl.org/ > > and > > http://python.sourceforge.net/peps/ > > (please note that the first link in the list of > PEPs is the PEP that describes what a pep is and > how it works) > > I would also like to suggest some type of semi-regular > status update from the development team/core team to > the community to keep them up to date, similar to this > one in python: > > http://starship.python.net/crew/amk/python/dev/ > > I would be willing to do the work to get a web > archiving system in place similar to the ones used > for the PEP/RFC sites used by perl and python > (both pages are pretty simple) if the core > team is ready for this to be setup. Something like in the attachement ? (Both 'expand' and TclHttpd should be able to use the code, despite it being originally written for expand). > It seems like this is needed in the near term > so that the development for 8.4 can continue > as there are several proposals that currently > are ready to be discussed. Correct. And others ready to be worked on (like the SDK/Sumo). > Thanks, > --Dan -- So long, Andreas Kupries <a.k...@we...> <http://www.purl.org/NET/akupries/> ------------------------------------------------------------------------------- |
|
From: Andreas K. <a.k...@we...> - 2000-09-09 17:46:54
Attachments:
P.tgz
|
> Although I am not on the core team, I would like to propose to them > that a RFC/PEP system be put in place soon to allow RFC/PEP type > proposals and discussions to begin. > I thought the core team was ready to start recieving these messages, > but Mark Harrison said in the news group that you are not: Unfortunately true. > (snipped from comp.lang.tcl): > To start recieving RFCs I don't think there is too > much work that needs to be done. > The process used by Perl and Python is almost identical. > You can read about them at: > > http://dev.perl.org/ > > and > > http://python.sourceforge.net/peps/ > > (please note that the first link in the list of > PEPs is the PEP that describes what a pep is and > how it works) > > I would also like to suggest some type of semi-regular > status update from the development team/core team to > the community to keep them up to date, similar to this > one in python: > > http://starship.python.net/crew/amk/python/dev/ > > I would be willing to do the work to get a web > archiving system in place similar to the ones used > for the PEP/RFC sites used by perl and python > (both pages are pretty simple) if the core > team is ready for this to be setup. Something like in the attachement ? (Both 'expand' and TclHttpd should be able to use the code, despite it being originally written for expand). > It seems like this is needed in the near term > so that the development for 8.4 can continue > as there are several proposals that currently > are ready to be discussed. Correct. And others ready to be worked on (like the SDK/Sumo). > Thanks, > --Dan -- So long, Andreas Kupries <a.k...@we...> <http://www.purl.org/NET/akupries/> ------------------------------------------------------------------------------- |
|
From: Andreas K. <a.k...@we...> - 2000-09-13 01:43:01
Attachments:
comment4.tgz
|
> Andreas Kupries <a.k...@we...> > [ in reply to Dan Kuchler ] > >> I would be willing to do the work to get a web > >> archiving system in place similar to the ones used > >> for the PEP/RFC sites used by perl and python > >> (both pages are pretty simple) if the core > >> team is ready for this to be setup. > > > > Something like in the attachement ? (Both 'expand' and TclHttpd > > should be able to use the code, despite it being originally written > > for expand). > > I've been experimenting with that, and I've got a version that formats > the *.exp files you supplied on-the-fly: > > http://www.cs.man.ac.uk/fellowsd-bin/tct/0 > http://www.cs.man.ac.uk/fellowsd-bin/tct/1 > > The source to the formatter (which is very much a work in progress) is > available at: > > http://www.cs.man.ac.uk/~fellowsd/tcl/tct-formatter.tcl Interesting. Thanks. Enclosed the most uptodate versions of the *rules .tcl files and some _drafts_ I am working on. With respect to these drafts I would really like to get feedback from the people which did the TclBlast CD (TclBurn Team) and the Tclish installer. From everyone else too. -- So long, Andreas Kupries <a.k...@we...> <http://www.purl.org/NET/akupries/> ------------------------------------------------------------------------------- |
|
From: Donal K. F. <fel...@cs...> - 2000-09-13 21:54:40
|
Andreas Kupries <a.k...@we...> > Interesting. Thanks. It's been fun. Thanks for giving me an excuse! I'm trying to generate a useful sidebar quick-index too; the JDK1.2 documentation tree is actually quite usable except for a few minor niggles (like the way that most stuff simply doesn't fit in the frames!) so I try to generate HTML to be a bit like that. Let me know what you think... > Enclosed the most uptodate versions of the *rules .tcl files and some > _drafts_ I am working on. Do you have a document specifying the format of a TCT or is it simply what you happen to have implemented? :^) > With respect to these drafts I would really like to get feedback > from the people which did the TclBlast CD (TclBurn Team) and the > Tclish installer. From everyone else too. * I believe that the Tcl/Tk documentation is in HTML on Macs. * It'd be nice if there was a TMML browser written in Tcl/Tk. Sure an HTML browser would be nice too, but being able to host our own documentation would be a definite plus. :^) * It might be nice too if there were several different SDK releases. I have in mind a version which is just a user-level one (i.e. one for people not doing heavy development, with only precompiled and pure Tcl extensions) and a version which is a developer-level one (with all the user-level stuff *plus* other tools which require the use of a compiler to work properly - SWIG and maybe tcl2c would be things to ship in this category.) I suppose one is a collection of resources, and the other a full SDK... Donal. -- Donal K. Fellows, Department of Computer Science, University of Manchester, UK. (work) fel...@cs... Tel: +44-161-275-6137 (preferred email addr.) (home) do...@ug... Tel: +44-1274-401017 Mobile: +44-7957-298955 http://www.cs.man.ac.uk/~fellowsd/ (Don't quote my .sig; I've seen it before!) |
|
From: Brent W. <we...@aj...> - 2000-09-13 15:49:33
|
>>>"Donal K. Fellows" said: > Andreas Kupries <a.k...@we...> > Do you have a document specifying the format of a TCT or is it simply > what you happen to have implemented? :^) > > > With respect to these drafts I would really like to get feedback > > from the people which did the TclBlast CD (TclBurn Team) and the > > Tclish installer. From everyone else too. > > * I believe that the Tcl/Tk documentation is in HTML on Macs. The tcl "tools" directory has a Makefile that generates the HTML for the Tcl and Tk man pages. > * It'd be nice if there was a TMML browser written in Tcl/Tk. Sure an > HTML browser would be nice too, but being able to host our own > documentation would be a definite plus. :^) The "Uhler HTML parser" is easily modified to understand different tags. It is all table driven, and augmented with per-tag Tcl procs to do special rendering. > * It might be nice too if there were several different SDK releases. > I have in mind a version which is just a user-level one (i.e. one > for people not doing heavy development, with only precompiled and > pure Tcl extensions) and a version which is a developer-level one > (with all the user-level stuff *plus* other tools which require the > use of a compiler to work properly - SWIG and maybe tcl2c would be > things to ship in this category.) I suppose one is a collection of > resources, and the other a full SDK... Right - having lived through the latest TclPro release, in which I was mostly a build engineer (we moved all of Tcl Pro into TEA for the first time for TclPro 1.4) it isn't all that bad to have different suites of things that get installed. We did things in four steps: 1) make install Do this for all the packages, and have a master dependency order between modules so you build Tcl first, etc. TclPro builds are complicated by building static, dynamic, debug, non-debug for many modules because TclPro wrapper needs static libraries. For our purposes we could just do a single build (in most cases) which is dynamically linked without symbols. I could also see a "threaded build" that just has Tcl + Thread + whatever other extensions are thread-safe. 2) make dist This is not fully supported by all modules, so we ended up creating a master "parts list file" that drove this process. This copies stuff from the area created by "make install" into a clean distribution area. You can also reorganize things a bit during this step. Especially if you are doing a cross-product of debug, non-debug, static and dynamic you need this step to trim out junk you don't need. If you only do a single build in step 1) then the results of make install may be sufficient. 3) make installers This is also driven by our parts list, which indicates which files are in which sub-packages so you can have one installer but the user can pick and choose what they want. Especially if you do binary releases you can have a bunch of platform independent files, and then slices for each architecture you've build for. Again, in a simplified form, you might be able to just take everything produced by step 1 into a single, no choices distribution. 4) Installation. Here we do some patching of binary files to eradicate traces of our build file system and make sure that TCL_LIBRARY etc. is set appropriately. It is awkward to get the -R path patched (this is the equivalent of the LD_LIBRARY_PATH environment variable that gets compiled into a binary so it knows where to find dynamic libraries.) We could perhaps legislate the patching problem out of existence by fixing the installation location, but I don't think that's very good. I also patched the tclConfig.sh files so there was some hope of being able to compile extensions against the installation - but we all know that isn't fool proof because your compiler environment may differ. -- Brent Welch <we...@aj...> http://www.ajubasolutions.com Scriptics changes to Ajuba Solutions scriptics.com => ajubasolutions.com -- The TclCore mailing list is sponsored by Ajuba Solutions To unsubscribe: email tcl...@aj... with the word UNSUBSCRIBE as the subject. |
|
From: Andreas K. <a.k...@we...> - 2000-09-14 03:44:25
Attachments:
tear.tgz
|
> Andreas Kupries <a.k...@we...> > > Interesting. Thanks. > > It's been fun. Thanks for giving me an excuse! No problem at all. > I'm trying to generate a useful sidebar quick-index too; the JDK1.2 > documentation tree is actually quite usable except for a few minor > niggles (like the way that most stuff simply doesn't fit in the > frames!) so I try to generate HTML to be a bit like that. Let me > know what you think... I haven't seen the JDK1.2 docs yet. Some url available I can go to ? > > Enclosed the most uptodate versions of the *rules .tcl files and some > > _drafts_ I am working on. > > Do you have a document specifying the format of a TCT or is it simply > what you happen to have implemented? :^) As of now it is what I 'happen to have implemented', with all the incongruencies that come from such an approach (TCT- prefix, and not, ...). But when working on an adaption of 'http://python.sourceforge.net/peps/pep-0001.html' for our needs the section 'PEP Style' brought it home that I should (start to) do this. Any ideas for the normalization and/or optimization of the commands ? This documententation could be TCTD 3 (Number 2 should be the adapted PEP 1). Ne TCTD, this is a shortcut of 'Tcl Core Team Document'. My current name for this type of document. I had no desire to use RFC or TEP (Tcl Enhancement Proposal). Other names ? > > With respect to these drafts I would really like to get feedback > > from the people which did the TclBlast CD (TclBurn Team) and the > > Tclish installer. From everyone else too. > > * I believe that the Tcl/Tk documentation is in HTML on Macs. Ok, so this is one we could generate from the XML. > * It'd be nice if there was a TMML browser written in Tcl/Tk. Sure an > HTML browser would be nice too, but being able to host our own > documentation would be a definite plus. :^) Larry recommended to me that we should start out with TkMan and then extend it to handle XML, HTML, ... > * It might be nice too if there were several different SDK releases. > I have in mind a version which is just a user-level one (i.e. one > for people not doing heavy development, with only precompiled and > pure Tcl extensions) and a version which is a developer-level one > (with all the user-level stuff *plus* other tools which require the > use of a compiler to work properly - SWIG and maybe tcl2c would be > things to ship in this category.) I suppose one is a collection of > resources, and the other a full SDK... For now I am thinking about a source based SDK. Binary distributions with all their 'niceties' like hardcoded paths (or env. vars.) et al. come later. See also the enclosed archive containing some thoughts about archives and distributions I wrote up some months ago, ... oh around may/june. And I was in a bad mood when I decided upon the title. We could convert that into several TCTDs, like a glossary + discussion of package descriptions and distributions in general. :) -- So long, Andreas Kupries <a.k...@we...> <http://www.purl.org/NET/akupries/> ------------------------------------------------------------------------------- |
|
From: Donal K. F. <fel...@cs...> - 2000-09-14 18:24:26
|
Andreas Kupries <a.k...@we...> > Donal K. Fellows <fel...@cs...> >> Andreas Kupries <a.k...@we...> >> I'm trying to generate a useful sidebar quick-index too; the JDK1.2 >> documentation tree is actually quite usable except for a few minor >> niggles (like the way that most stuff simply doesn't fit in the >> frames!) so I try to generate HTML to be a bit like that. Let me >> know what you think... > > I haven't seen the JDK1.2 docs yet. Some url available I can go to ? Hmm. (Rummages around bookmarks...) Try: http://java.sun.com/j2se/1.3/docs/api/ You could also have a look at: http://athene.cs.man.ac.uk:8000/ which was produced with the same tool (javadoc) though on a different source tree (and its served up by a nifty little Java webserver that lives in the same archive file as the documentation web.) It would be very nice indeed if some kind soul developed a similar sort of tool for Tcl. (Handling C functions written to follow the _Tcl/Tk Engineering Manual_ would be a wonderful bonus.) This sort of thing is, in my experience, extremely useful in large software projects... >>> Enclosed the most uptodate versions of the *rules .tcl files and some >>> _drafts_ I am working on. >> >> Do you have a document specifying the format of a TCT or is it simply >> what you happen to have implemented? :^) > > As of now it is what I 'happen to have implemented', with all the > incongruencies that come from such an approach (TCT- prefix, and not, > ...). But when working on an adaption of > 'http://python.sourceforge.net/peps/pep-0001.html' for our needs the > section 'PEP Style' brought it home that I should (start to) do > this. Any ideas for the normalization and/or optimization of the > commands ? Not yet. Except perhaps that braces should not be used when passing arguments to formatting directives... :^) I might say more later on this. > This documententation could be TCTD 3 (Number 2 should be the adapted > PEP 1). Ne TCTD, this is a shortcut of 'Tcl Core Team Document'. My > current name for this type of document. I had no desire to use RFC or > TEP (Tcl Enhancement Proposal). Other names ? Well, I've been calling them TCTs, but that's easily changeable. My main concern is that we should have a format that is easy to read, write (with a standard text editor) and convert into whatever other formats we want (definitely HTML, but nroff, LaTeX, XML, etc. would be good too.) Doing this all on the fly just makes things even better, as it means that the exported view is always in sync with the repository. I think I'll put my current rendering code up on sourceforge in the near future. Once they get back to me with the URL to confirm my account... Donal. -- Donal K. Fellows, Department of Computer Science, University of Manchester, UK. (work) fel...@cs... Tel: +44-161-275-6137 (preferred email addr.) (home) do...@ug... Tel: +44-1274-401017 Mobile: +44-7957-298955 http://www.cs.man.ac.uk/~fellowsd/ (Don't quote my .sig; I've seen it before!) |
|
From: Andreas K. <a.k...@we...> - 2000-09-14 07:25:15
Attachments:
reg.tgz
|
> > > Enclosed the most uptodate versions of the *rules .tcl files and some > > > _drafts_ I am working on. > > > > Do you have a document specifying the format of a TCT or is it simply > > what you happen to have implemented? :^) > > As of now it is what I 'happen to have implemented', with all the > incongruencies that come from such an approach (TCT- prefix, and not, > ...). But when working on an adaption of > 'http://python.sourceforge.net/peps/pep-0001.html' for our needs the > section 'PEP Style' brought it home that I should (start to) do > this. Any ideas for the normalization and/or optimization of the > commands ? Well, I played with the commands a bit, tried to make them more regular, remove redundancies, etc. The result enclosed. The file 'commands' contains a list of the commands as they could be, although without much description. Also contains ultra-short consideration of alternate syntax for some commands. foo.ex - Rewrote 0 to 2 to conform to the new commands. fooalt.ex - Same as above, but using some of the alternate commands. IMHO the alternate sources seem to be more readable. > This documententation could be TCTD 3 (Number 2 should be the adapted > PEP 1). Ne TCTD, this is a shortcut of 'Tcl Core Team Document'. My > current name for this type of document. I had no desire to use RFC or > TEP (Tcl Enhancement Proposal). Other names ? -- So long, Andreas Kupries <a.k...@we...> <http://www.purl.org/NET/akupries/> ------------------------------------------------------------------------------- |
|
From: Andreas K. <a.k...@we...> - 2000-09-15 00:59:40
|
> Andreas Kupries <a.k...@we...> Note, I am on the tclcore list. > > Donal K. Fellows <fel...@cs...> > >> Andreas Kupries <a.k...@we...> > > >> I'm trying to generate a useful sidebar quick-index too; the JDK1.2 > >> documentation tree is actually quite usable except for a few minor > >> niggles (like the way that most stuff simply doesn't fit in the > >> frames!) so I try to generate HTML to be a bit like that. Let me > >> know what you think... > > > > I haven't seen the JDK1.2 docs yet. Some url available I can go to ? > > Hmm. (Rummages around bookmarks...) Try: > http://java.sun.com/j2se/1.3/docs/api/ > > You could also have a look at: > http://athene.cs.man.ac.uk:8000/ Thanks. > which was produced with the same tool (javadoc) though on a different > source tree (and its served up by a nifty little Java webserver that > lives in the same archive file as the documentation web.) It would be > very nice indeed if some kind soul developed a similar sort of tool > for Tcl. (Handling C functions written to follow the _Tcl/Tk > Engineering Manual_ would be a wonderful bonus.) This sort of thing > is, in my experience, extremely useful in large software projects... I think I will spend some more time on my autodoc to support this notation too [*]. In the future we should move to add this capability to Source Navigator, IMHO. We'll see. [*] See http://www.purl.org/NET/akupries/soft/autodoc/ for current output (it looks even nicer if your browser does CSS, thanks to Sebastien Barre for the stylesheet). > >>> Enclosed the most uptodate versions of the *rules .tcl files and some > >>> _drafts_ I am working on. > >> > >> Do you have a document specifying the format of a TCT or is it simply > >> what you happen to have implemented? :^) > > > > As of now it is what I 'happen to have implemented', with all the > > incongruencies that come from such an approach (TCT- prefix, and not, > > ...). But when working on an adaption of > > 'http://python.sourceforge.net/peps/pep-0001.html' for our needs the > > section 'PEP Style' brought it home that I should (start to) do > > this. Any ideas for the normalization and/or optimization of the > > commands ? > > Not yet. Except perhaps that braces should not be used when passing > arguments to formatting directives... :^) > I might say more later on this. I've removed this [x] in the latest command set I am playing with. See my post to tclcore Date: Thu, 14 Sep 2000 00:25:15 +0200 Subject: [TCLCORE] Re: RFC/PEP format which had that enclosed. [x] IOW, I changed [p {........}] to [p] ........ > > This documententation could be TCTD 3 (Number 2 should be the adapted > > PEP 1). Ne TCTD, this is a shortcut of 'Tcl Core Team Document'. My > > current name for this type of document. I had no desire to use RFC or > > TEP (Tcl Enhancement Proposal). Other names ? > > Well, I've been calling them TCTs, but that's easily changeable. > My main concern is that we should have a format that is easy to > read, write (with a standard text editor) and convert into whatever > other formats we want (definitely HTML, but nroff, LaTeX, XML, > etc. would be good too.) Doing this all on the fly just makes > things even better, as it means that the exported view is always in > sync with the repository. Again right. > I think I'll put my current rendering code up on sourceforge in the > near future. Once they get back to me with the URL to confirm my > account... Today I saw that Donald Porter is now on SF as well. -- So long, Andreas Kupries <a.k...@we...> <http://www.purl.org/NET/akupries/> ------------------------------------------------------------------------------- -- The TclCore mailing list is sponsored by Ajuba Solutions To unsubscribe: email tcl...@aj... with the word UNSUBSCRIBE as the subject. |
|
From: Donald G P. <dg...@ca...> - 2000-09-14 20:33:32
|
> Today I saw that Donald Porter is now on SF as well. Yes. I signed up yesterday, and Jeff put me on the admin list for the Tcl/Tk project. Should I have announced that here? Thanks, Jeff! No luck yet logging into and checking out from the read-write CVS repository at pop.ajubasolutions.com. Also no word yet on an SSH account on dev.ajubasolutions.com. I think Brent's been busy with stuff for work. I'm out of town yet again, starting this evening through Sunday, so I would not be able to use either account until Monday, anyway. DGP -- The TclCore mailing list is sponsored by Ajuba Solutions To unsubscribe: email tcl...@aj... with the word UNSUBSCRIBE as the subject. |
|
From: Jeffrey H. <jef...@aj...> - 2000-09-14 17:49:20
|
> From: Donald G Porter [mailto:dg...@ca...] > > Today I saw that Donald Porter is now on SF as well. > > Yes. I signed up yesterday, and Jeff put me on the admin list for the > Tcl/Tk project. Should I have announced that here? Thanks, Jeff! > > No luck yet logging into and checking out from the read-write CVS > repository at pop.ajubasolutions.com. Also no word yet on an SSH > account on dev.ajubasolutions.com. I think Brent's been busy with > stuff for work. You should now have full access to the core sources on pop. Brent has been dragged back into his day job (an unfortunate circumstance that I'm sure everyone on the TCT feels now and then), so the other part may take a bit longer. Jeff -- The TclCore mailing list is sponsored by Ajuba Solutions To unsubscribe: email tcl...@aj... with the word UNSUBSCRIBE as the subject. |
|
From: Donal K. F. <fel...@cs...> - 2000-09-12 19:18:12
|
Andreas Kupries <a.k...@we...> [ in reply to Dan Kuchler ] >> I would be willing to do the work to get a web >> archiving system in place similar to the ones used >> for the PEP/RFC sites used by perl and python >> (both pages are pretty simple) if the core >> team is ready for this to be setup. > > Something like in the attachement ? (Both 'expand' and TclHttpd > should be able to use the code, despite it being originally written > for expand). I've been experimenting with that, and I've got a version that formats the *.exp files you supplied on-the-fly: http://www.cs.man.ac.uk/fellowsd-bin/tct/0 http://www.cs.man.ac.uk/fellowsd-bin/tct/1 The source to the formatter (which is very much a work in progress) is available at: http://www.cs.man.ac.uk/~fellowsd/tcl/tct-formatter.tcl Donal. -- Donal K. Fellows, Department of Computer Science, University of Manchester, UK. (work) fel...@cs... Tel: +44-161-275-6137 (preferred email addr.) (home) do...@ug... Tel: +44-1274-401017 Mobile: +44-7957-298955 http://www.cs.man.ac.uk/~fellowsd/ (Don't quote my .sig; I've seen it before!) -- The TclCore mailing list is sponsored by Ajuba Solutions To unsubscribe: email tcl...@aj... with the word UNSUBSCRIBE as the subject. |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X