From Ib1VVtrL4@offsh1or.com Fri Dec 5 05:18:24 1997 From: Ib1VVtrL4@offsh1or.com (Ib1VVtrL4@offsh1or.com) Date: 05 Dec 97 5:18:24 PM Subject: [DOC-SIG] Lasers/Optics/Optical Tables - Save! Message-ID: MWK INDUSTRIES SALE! JUST A QUICK LETTER TO SHOW YOU SOME LASERS- OPTICS AND OPTICAL TABLES SURPLUS THAT WE JUST RECEIVED. ITEM TRIMMU12 14 WATT ARGON LASER MADE FOR HEART SURGERY, TRIMEDYNE MODEL 900 TEMOO, POLORIZED,220VAC INPUT , WATER COOLED , FIBER LAUNCH, ALL ON ROLLAROUND CART EXCELENT FOR LAB USE, THE POWER WAS MEASURED AT 13 TO 14 WATTS. PRICE $9500 12 MONTH WARRANTEE. ITEM: COHERENT ARTICULATING ARM FROM A MODEL 451 CO2 MEDICAL LASER. ECCELLENT COND. $200 ITEM CO220A: CO2 LASER MADE BY PFIZER ,1990, FOR SURGERY, TATTOO REMOVAL ECT. 20 WATT OUTPUT , TESTED AND IN EXC. COND. 110 VAC INPUT, COST $40,000 NEW OUR PRICE 4,900. MODEL 20-C ITEM:PDA-1U1 SPECTRA PHYSICS QUANTRA RAY PULSED DYE LASER , GOOD FOR SPARE PARTS MODEL PDA-1 $500 ITEM NEWU1 NEWPORT OPTICAL TABLE 16" BY 36" 4" THICK, 1 " HOLE SPACING, COMES WITH A RUBBER ISOLATED TABLE STAND, NOT AIR SUPPORTED, $750 ITEM: HEPSN1 HELIUM NEON POWER SUPPLY KIT OPERATES UP TO A 15 mW LASER, INCLUDES ALL COMPONENTS AND PRINTED CIRCUIT BOARD, ALL YOU HAVE TO DO IS STUFF AND SOLDER THE CIRCUIT BOARD . 4" BY 3" BY 3", PRICE $75 ITEM HENEU12 1 TO 1.5 MW HE-NE LASER 632.8 nM INCLUDES 12VDC INPUT POWER SUPPLY ALL IN A PLASTIC HOUSING 6.25 IN. BY 1.375IN BY 2.25 IN. TEMOO,RANDOM POL. ,1.7 MR DIVERGENCE. 12 MONTH WARRANTEE , PRICE $45 ITEM MELU12 1 TO 2 mW HE-NE LASER 632.8 NM , PULLS FROM MEDICAL EQUIPMENT .EACH UNIT INCLUDES HE-NE HEAD AND POWER SUPPLY[110VAC INPUT]. ALL YOU NEED TO PROVIDE IS A POWER CORD AND A FUSE TO MAKE THE UNIT OPERATIONAL. THE BEAM IS TEM00, POLORIZED WE WILL COVER EACH UNIT WITH A 12 MONTH UNLIMITED HOUR WARRANTEE, EXCELLENT FOR FOR LAB OR HOME USE. NEW THESE COST APPROX. $350 OUR PRICE $85. DIMENSIONS 9.75 BY 1.25 INCHES, P.S. 4.25 BY 3.25BY 1.25 INCHES. ITEM RAMCNS1: RAMAN CELL OPTICS 308 nm AR/AR 4600 A 0=0 DEGREES 1000 MM FL. 2" DIA. NEW. ORIGINAL PRICE $520 OUR PRICE $175 ITEM TFPOLNS1: POLARIZERS , THIN FILM FOR 532 nm , NEW, ORIGINAL COST $590 EACH OUR PRICE $200 EACH 10 MM DIA. ITEM CO2OCNS1: CO2 HIGH REFECTOR AND OUTPUT COUPLER 10.5 MM DIA, OC =79%R NEW. $200 A SET. ITEM 25MNS1: DIELECTRIC BROADBAND MIRRORS 450 TO 700NM , NEW WITH PLASTIC PROTECTIVE COATINGS , 2 SIZES 25 MM SQ. AND 50 MM SQ. RECOMENDED FOR HIGHER POWER LASERS. 25MM SIZE ITEM 25MNS1 $20 50MM SIZE ITEM 50MNS1 $25 ITEM # BSDNS1: 50/50 DIELECTRIC COATED PLATE BEAM SPLITTER 630 TO 660 NM COMES IN A TRIANGLE SHAPE EACH SIDE APPROX. 1" PRICE $20 ITEM # 45NS1 45 DEGREE RED REFLECTOR , PASSES 488 TO 532NM , CAN BE USED TO COMBINE RED AND GREEN/BLUE LASERS TO CREATE A WHITE LIGHT LASER. 1" SQ. PRICE $15 ITEM# PCINS1 PLANO/CONVEX LENS COATED FOR YAG 1064NM , AR COATED, 10MM DIA. NEW, ORIG. COST $250 OUR PRICE $100 ITEM# INFILTER : INTERFERENCE FILTERS USED FOR PASSING A PARTICULAR SPECTRAL LINE , 11.8 MM DIA. CAREFULLY REMOVED FROM MEDICAL EQUIPMENT AND WRAPPED IN LENSE PAPER. THE FOLLOWING WAVE LENGTHS ARE AVAILABLE. 523.5, 547.4 , 572.1, 512.9, 550.6, 488, 505.7 nm price $20 each. FOR A COMPLETE LINE OF NEW AND USED LASERS - OPTICS -ELECTRO OPTICS- LASER SHOWS ORDER A COMPLETE CATALOG AT MWKINDUSTRIES.COM TO: ORDER GO TO OUR WEB SITE MWKINDUSTRIES.COM {SECURE ORDERING SITE} QUESTIONS OR REMOVAL FROM MAILING LIST EMAIL: MWK@WORLDNET.ATT.NET MWK INDUSTRIES 1269 POMONA RD CORONA CA 91720 PHONE 909-278-0563 FAX 909-278-4887 _______________ DOC-SIG - SIG for the Python Documentation Project send messages to: doc-sig@python.org administrivia to: doc-sig-request@python.org _______________ From kmcdona@watson.wustl.edu Mon Dec 8 19:17:40 1997 From: kmcdona@watson.wustl.edu (Ken McDonald) Date: Mon, 8 Dec 1997 13:17:40 -0600 (CST) Subject: [DOC-SIG] A few thoughts on the docstring standards Message-ID: Was just using the basic format outlined on the SIG special interest page, and it's nice--concise, easy to remember, fast to type. This has likely been discussed before, but I didn't see it in the recent SIG mail traffic, so will just mention a quick couple of points here. 1) Do **bold** and *italic* apply in example code? The format says example code is printed "verbatim", but hopefully this applies only to indenting--it'd be very nice to be able to italicize and bold things in code (**keywords**, *placeholders*, etc.) But then one has to worry about actual * usages in code, including in RE's where there might not be the option setting the asterisk up so it is interpreted as an asterisk. 2) There was a mention of restricting the usage of '--' to avoid confusion between " desc -- a descriptive list element", and other usages (such as a hyphen). For myself, simply saying that -- only has its special meaning if surrounded by whitespace would be fine. 3) Is this effort still going on? The mention of gendoc says the last update was Sept. 96. This isn't a criticism, I'm just wondering if the effort has headed in some other direction. (Don't want to use obsolete standards!) Thanks, Ken ======================================== Kenneth McDonald Genome Sequencing Center Washington University School of Medicine Phone: 314-286-1831 ======================================== _______________ DOC-SIG - SIG for the Python Documentation Project send messages to: doc-sig@python.org administrivia to: doc-sig-request@python.org _______________ From Robin.K.Friedrich@USAHQ.UnitedSpaceAlliance.com Mon Dec 8 21:02:22 1997 From: Robin.K.Friedrich@USAHQ.UnitedSpaceAlliance.com (Friedrich, Robin K) Date: Mon, 8 Dec 1997 15:02:22 -0600 Subject: [DOC-SIG] A few thoughts on the docstring standards Message-ID: >---------- >From: Ken McDonald[SMTP:kmcdona@watson.wustl.edu] >Sent: Monday, December 08, 1997 1:17 PM >To: doc-sig@python.org >Subject: [DOC-SIG] A few thoughts on the docstring standards > >Was just using the basic format outlined on the SIG special interest >page, and it's nice--concise, easy to remember, fast to type. This has >likely been discussed before, but I didn't see it in the recent SIG >mail traffic, so will just mention a quick couple of points here. > >1) Do **bold** and *italic* apply in example code? The format says No. >example code is printed "verbatim", but hopefully this applies only to >indenting--it'd be very nice to be able to italicize and bold things in >code (**keywords**, *placeholders*, etc.) But then one has to worry about >actual * usages in code, including in RE's where there might not be the >option setting the asterisk up so it is interpreted as an asterisk. Yes this is the rub as it complicates the scanning RE greatly. So we just punted saying that it wasn't all that important. > >2) There was a mention of restricting the usage of '--' to avoid >confusion between " desc -- a descriptive list element", and other usages >(such as a hyphen). For myself, simply saying that -- only has its special >meaning if surrounded by whitespace would be fine. OK that's what's done now but how does this help other uses of -- as they are likely to be surrounded by whitespace anyway? > >3) Is this effort still going on? The mention of gendoc says the last >update was Sept. 96. This isn't a criticism, I'm just wondering if the >effort has headed in some other direction. (Don't want to use obsolete >standards!) The motivation for that documentation last year was the active work on gendoc. Gendoc work may be resurrected soon and then we revisit these standards more intensely*. However, I don't see any competing doc string markup standards being seriously proposed, so you are safe in using it. * On this note I'd like to see if anyone really wants to see a project for a comprehensive python source documentation toolkit? By "really wants" I mean is willing to contribute design and coding to such an effort. I'd hate to ask Daniel Larsson to redo his tools again without serious help. I know recent comments seem to indicate that a full remodeling is desired by some. Robin F. _______________ DOC-SIG - SIG for the Python Documentation Project send messages to: doc-sig@python.org administrivia to: doc-sig-request@python.org _______________ From papresco@technologist.com Thu Dec 18 08:09:48 1997 From: papresco@technologist.com (Paul Prescod) Date: Thu, 18 Dec 1997 03:09:48 -0500 Subject: [DOC-SIG] SGML Working Group Message-ID: <3498DA4C.9FC384DE@technologist.com> I have been encouraged to discuss SGML stuff in the doc-sig. This is my first posting there on this topic (well, as part of an actual project...) SGML/XML interested people should join us there for this discussion. (please followup there, not in comp.lang.python) I would like to urge that the first order of business is a mandate for our "working group" and I propose the following one: This working group exists in order to standardize classes, interfaces and software for the processing of SGML documents (including the XML subset). Concrete goals of the first few months should include: * Python version of the World Wide Web Consortium "Document Object Model" SGML-tree API (this should be a straightforward translation of IDL to Python) * Development of Python-specific event based and tree APIs for processing of SGML documents. (perhaps inspired by similar efforts in the Java or C++ worlds and the existing Python SGML processing packages) * Development of a validating XML parser that would serve to make XML competitive in XML processing. * Development of a filter for the output of NSGMLS that generates the events defined in our API. * Tool for converting events from our API into a DOM tree. Other (longer range?) goals might include: * Embedding of Python into James Clark's C++ SP library. * Wrapping of C++ SP and Grove API with our Python-specific APIs. * Development of higher level tools for SGML processing (e.g. a DSSSL-like tool, an "XML-Writer" library, an XML browser for Grail etc.) Comments (in doc-sig) please. Paul Prescod _______________ DOC-SIG - SIG for the Python Documentation Project send messages to: doc-sig@python.org administrivia to: doc-sig-request@python.org _______________ From digitome@iol.ie Fri Dec 19 14:33:03 1997 From: digitome@iol.ie (Sean Mc Grath) Date: Fri, 19 Dec 1997 14:33:03 GMT Subject: [DOC-SIG] SGML Working Group Message-ID: <199712191433.OAA16399@mail.iol.ie> I would like to see basic XML support provided as a portable C extension module. I believe XML will take off and that the XML support in Python will be sufficently useful to go into the standard distribution. 1) XML processing must be fast. Microsoft build but criticise Java XML parsers over speed issues and trumpet Windows specific ActiveX components as a "solution" to the speed issues. Lets not allow the same charge be leveled at Python. 2) I believe the speed difference will be *significant*. I have Python + C implementation of a LoadEsis treebuilding library for Python (the tree building process for XML will be analagous I suspect). The C one is massively faster. At the very least, we could include a C based XML lexer to take care of some of the hairy bits and spit out basic XML tokens. Python layers could site on top of that to do well formedness checks/tree building/validation. James Clark has written such a thing (in Ansi C) and made it freely available. Sean Mc Grath sean at digitome dot com _______________ DOC-SIG - SIG for the Python Documentation Project send messages to: doc-sig@python.org administrivia to: doc-sig-request@python.org _______________ From papresco@technologist.com Fri Dec 19 15:23:23 1997 From: papresco@technologist.com (Paul Prescod) Date: Fri, 19 Dec 1997 10:23:23 -0500 Subject: [DOC-SIG] XML Extension Module? References: <199712191433.OAA16399@mail.iol.ie> Message-ID: <349A916B.E0A904A3@technologist.com> Sean Mc Grath wrote: > > I would like to see basic XML support provided as a portable C extension module. > I believe XML will take off and that the XML support in Python > will be sufficently useful to go into the standard > distribution. Your idea is good. It would be a real coup for Python to be the first scripting language with robust, fast XML support in the standard distribution. But I have two concerns: First, Timing. We're on the verge of releasing Python 1.5. Can we get something in there? If not, how long do we have to wait for an upgrade/update? I'm also not sure about whether the idea will be popular on Unix platforms. Are Python extensions usually linked statically or dynamically on those platforms? In other words, if I'm on a standard site with Python installed, and I use XML in one out of 99 scripts, do the other 99 scripts usually take the binary size hit of having the extension module linked in? I know that theoretically dynamic linking is possible, but I'm not sure about the amount this feature is actually used in the community. I am very interested in feedback on that score. The nice thing about using Python code modules is that you only incur the hit when you use them. And presumably the same holds for binary extensions on Windows. Just for reference, James' module is about 100K binary on Windows, does full well formedness checking and handles Unicode. Without well formedness checking, it seems to be about 80K. -- Paul Prescod -- http://itrc.uwaterloo.ca/~papresco Art is always at peril in universities, where there are so many people, young and old, who love art less than argument, and dote upon a text that provides the nutritious pemmican on which scholars love to chew. -- Robertson Davies in "The Cunning Man" _______________ DOC-SIG - SIG for the Python Documentation Project send messages to: doc-sig@python.org administrivia to: doc-sig-request@python.org _______________ From guido@CNRI.Reston.Va.US Fri Dec 19 15:55:20 1997 From: guido@CNRI.Reston.Va.US (Guido van Rossum) Date: Fri, 19 Dec 1997 10:55:20 -0500 Subject: [DOC-SIG] XML Extension Module? In-Reply-To: Your message of "Fri, 19 Dec 1997 10:23:23 EST." <349A916B.E0A904A3@technologist.com> References: <199712191433.OAA16399@mail.iol.ie> <349A916B.E0A904A3@technologist.com> Message-ID: <199712191555.KAA17108@eric.CNRI.Reston.Va.US> > First, Timing. We're on the verge of releasing Python 1.5. Can we get > something in there? If not, how long do we have to wait for an > upgrade/update? I wouldn't get all hung up about 1.5 being closed for additions (which it is). Lots of stuff is considered "available for Python" that isn't in the core distribution: the Mac port, COM support, NumPy... There's really no reason to be concerned about whether something is part of the core distribution or not. > I'm also not sure about whether the idea will be popular on Unix > platforms. Are Python extensions usually linked statically or > dynamically on those platforms? That's up to the site admin (or owner of the Unix box). However, even if the standard extensions are all linked statically, Python will still accept new dynamically loaded extensions. > In other words, if I'm on a standard site with Python installed, and I > use XML in one out of 99 scripts, do the other 99 scripts usually take > the binary size hit of having the extension module linked in? I know > that theoretically dynamic linking is possible, but I'm not sure about > the amount this feature is actually used in the community. It's used a lot. --Guido van Rossum (home page: http://www.python.org/~guido/) _______________ DOC-SIG - SIG for the Python Documentation Project send messages to: doc-sig@python.org administrivia to: doc-sig-request@python.org _______________ From guido@CNRI.Reston.Va.US Fri Dec 19 15:55:20 1997 From: guido@CNRI.Reston.Va.US (Guido van Rossum) Date: Fri, 19 Dec 1997 10:55:20 -0500 Subject: [DOC-SIG] XML Extension Module? In-Reply-To: Your message of "Fri, 19 Dec 1997 10:23:23 EST." <349A916B.E0A904A3@technologist.com> References: <199712191433.OAA16399@mail.iol.ie> <349A916B.E0A904A3@technologist.com> Message-ID: <199712191555.KAA17108@eric.CNRI.Reston.Va.US> > First, Timing. We're on the verge of releasing Python 1.5. Can we get > something in there? If not, how long do we have to wait for an > upgrade/update? I wouldn't get all hung up about 1.5 being closed for additions (which it is). Lots of stuff is considered "available for Python" that isn't in the core distribution: the Mac port, COM support, NumPy... There's really no reason to be concerned about whether something is part of the core distribution or not. > I'm also not sure about whether the idea will be popular on Unix > platforms. Are Python extensions usually linked statically or > dynamically on those platforms? That's up to the site admin (or owner of the Unix box). However, even if the standard extensions are all linked statically, Python will still accept new dynamically loaded extensions. > In other words, if I'm on a standard site with Python installed, and I > use XML in one out of 99 scripts, do the other 99 scripts usually take > the binary size hit of having the extension module linked in? I know > that theoretically dynamic linking is possible, but I'm not sure about > the amount this feature is actually used in the community. It's used a lot. --Guido van Rossum (home page: http://www.python.org/~guido/) _______________ DOC-SIG - SIG for the Python Documentation Project send messages to: doc-sig@python.org administrivia to: doc-sig-request@python.org _______________ From Fred L. Drake, Jr." References: <199712191433.OAA16399@mail.iol.ie> <349A916B.E0A904A3@technologist.com> Message-ID: <199712191608.LAA28378@weyr.cnri.reston.va.us> Sean Mc Grath wrote: > I would like to see basic XML support provided as a portable C extension module. > I believe XML will take off and that the XML support in Python > will be sufficently useful to go into the standard Paul Prescod writes: > First, Timing. We're on the verge of releasing Python 1.5. Can we get > something in there? If not, how long do we have to wait for an > upgrade/update? Expect the final release this year. Even if the code were written and tested already, it's basically too late to add modules to 1.5. A separate package isn't such a bad thing, though, with the 1.5 Misc/Makefile.pre.in, a package can be built *and installed* into an installed Python very easily. > I'm also not sure about whether the idea will be popular on Unix > platforms. Are Python extensions usually linked statically or > dynamically on those platforms? I think most of the "major" modern UNIXes support dynamic modules, but I don't know how people actually build it. Without uncommenting the *shared* line in Setup, all of the extensions are built statically. The best approach would probably be to move all the most commonly used C modules above the *shared* line (things like strop could certainly be there), and keep the less often used modules below the line (database interfaces, curses, etc.). Support for SGML/XML should be dynamic where that's available. If a module is installed as an extension, it can be built dynamically if the architecture supports it, regardless of the Python configuration. > In other words, if I'm on a standard site with Python installed, and I > use XML in one out of 99 scripts, do the other 99 scripts usually take > the binary size hit of having the extension module linked in? I know > that theoretically dynamic linking is possible, but I'm not sure about > the amount this feature is actually used in the community. The effect of a statically linked module that isn't used is very system dependent. Some systems (Linux I know) won't even allocate swap space for the unused pages from the executable, so it's pretty cheap. Some platforms probably copy all the pages into the VM space before starting the process, but I expect this is changing somewhat. Some require static linking and full loading, and that's just a nasty can of worms. (It also suggests that extensions should be avoided if unnecessary.) > I am very interested in feedback on that score. The nice thing about > using Python code modules is that you only incur the hit when you use > them. And presumably the same holds for binary extensions on Windows. That is correct. > Just for reference, James' module is about 100K binary on Windows, does > full well formedness checking and handles Unicode. Without well > formedness checking, it seems to be about 80K. I am presuming we're talking about material in xmltok.zip? This still appears to be pretty preliminary (which might be why I found it in the test directory at ftp.jclark.com). Just running a simple make on Solaris/SPARC gives me an xmltok.o of about 100K, with the additional .o files in the xmlwf/ directory, about 116K. Add to this Python extension code, and I'll guess it's under 125K. -Fred -- Fred L. Drake, Jr. fdrake@cnri.reston.va.us Corporation for National Research Initiatives 1895 Preston White Drive Reston, VA 20191-5434 _______________ DOC-SIG - SIG for the Python Documentation Project send messages to: doc-sig@python.org administrivia to: doc-sig-request@python.org _______________ From papresco@technologist.com Fri Dec 19 16:59:18 1997 From: papresco@technologist.com (Paul Prescod) Date: Fri, 19 Dec 1997 11:59:18 -0500 Subject: [DOC-SIG] XML Extension Module? References: <199712191433.OAA16399@mail.iol.ie> <349A916B.E0A904A3@technologist.com> <199712191608.LAA28378@weyr.cnri.reston.va.us> Message-ID: <349AA7E6.D55CC41F@technologist.com> Well, the concensus seems to be in favour of Sean's idea, which is great with me. If we intend to build on top of James' code, then the important concern shifts back to APIs. The Java folks are just working out an API and if we wait for them to finish that (early January) then we will have a good starting point for our own development efforts. We might even decide to just use their API as it stands. Once we define an API, and build wrappers for James Clark's xmltok, the existing xmllib and for the various Java XML parsers (for JPython). Anyone who wants to contribute to the development of that API should join the xml-dev mailing list. http://www.lists.ic.ac.uk/hypermail/xml-dev/index.html Fred L. Drake wrote: > > I am presuming we're talking about material in xmltok.zip? This > still appears to be pretty preliminary (which might be why I found it > in the test directory at ftp.jclark.com). xmltok is preliminary, but so is XML. It could still change between its move from a proposed recommendation to a W3C recommendation. But Sean's idea suggests that we should NOT start building our own, but just wait for James to complete his implementation (which is quite likely to be soon after XML is finalized). We should also wait for the APIs to shake out. James might implement the Java guys' APIs or emulate his own SP generic interface or he might do something else altogether. -- Paul Prescod -- http://itrc.uwaterloo.ca/~papresco Art is always at peril in universities, where there are so many people, young and old, who love art less than argument, and dote upon a text that provides the nutritious pemmican on which scholars love to chew. -- Robertson Davies in "The Cunning Man" _______________ DOC-SIG - SIG for the Python Documentation Project send messages to: doc-sig@python.org administrivia to: doc-sig-request@python.org _______________ From fermigie@math.jussieu.fr Fri Dec 19 20:28:00 1997 From: fermigie@math.jussieu.fr (Stefane Fermigier) Date: Fri, 19 Dec 1997 21:28:00 +0100 (MET) Subject: [DOC-SIG] XML extension module. Message-ID: <199712192028.VAA08081@riemann.math.jussieu.fr> Forwarded message: >> From: Sean Mc Grath >> >> I would like to see basic XML support provided as a portable C extension module. >> I believe XML will take off and that the XML support in Python >> will be sufficently useful to go into the standard >> distribution. >> >> 1) XML processing must be fast. Microsoft build but criticise Java XML parsers >> over speed issues and trumpet Windows specific ActiveX components as >> a "solution" to the speed issues. Lets not allow the same charge be leveled >> at Python. >> >> 2) I believe the speed difference will be *significant*. I have Python + C >> implementation of a LoadEsis treebuilding library for Python (the tree building >> process for XML will be analagous I suspect). The C one is massively faster. >> >> At the very least, we could include a C based XML lexer to take care of >> some of the hairy bits and spit out basic XML tokens. Python layers could >> site on top of that to do well formedness checks/tree building/validation. >> James Clark has >> written such a thing (in Ansi C) and made it freely available. Another option would be to use Marc-Andre Lemburg fast tag engine, which is made of a kernel written in C (kind of enhanced Finite State Automaton) and already has an HTML parser written (if you don't know about it, it's on his page on starship I guess). My own opinion is that we should strive to write a modular system where several parsers can be used to the same effect: slow but portable parsers written in Python, parsers built on sgmls ESIS output or fast parser written as C modules. Cheers, S. _______________ DOC-SIG - SIG for the Python Documentation Project send messages to: doc-sig@python.org administrivia to: doc-sig-request@python.org _______________ From lemburg@uni-duesseldorf.de Fri Dec 19 20:54:46 1997 From: lemburg@uni-duesseldorf.de (M.-A. Lemburg) Date: Fri, 19 Dec 1997 21:54:46 +0100 Subject: [DOC-SIG] XML extension module. References: <199712192028.VAA08081@riemann.math.jussieu.fr> Message-ID: <349ADF16.7A4A8CDE@uni-duesseldorf.de> Stefane Fermigier wrote: > > Another option would be to use Marc-Andre Lemburg fast tag engine, which > is made of a kernel written in C (kind of enhanced Finite State Automaton) > and already has an HTML parser written (if you don't know about it, it's on > his page on starship I guess). You could do that, but you probably don't want to unless you automate the tag table creation in some way :-) Let me know if you're interested, since the version on my (much too outdated) webpages is not the most up-to-date one. Also note, that the engine is something like a combined lexer+parser. BTW: It's not a HTML parser in the sense that it uses a strict grammar which you probably have in mind here. -- Marc-Andre Lemburg _______________ DOC-SIG - SIG for the Python Documentation Project send messages to: doc-sig@python.org administrivia to: doc-sig-request@python.org _______________ From Jack.Jansen@cwi.nl Tue Dec 23 12:14:04 1997 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Tue, 23 Dec 1997 13:14:04 +0100 Subject: [DOC-SIG] XML parser extension module Message-ID: Has anyone looked at the following package? I downloaded it and glanced at it for a few minutes and it seems like it would be fairly straightforward to put a Python wrapper around it, but I haven't looked at it too carefully yet. Also, I haven't played around with it and the author calls it alpha software, so I have no idea how good it is. > From: Richard Tobin > > - The complexity of the XML syntax doesn't matter, because you can > > use a generic XML parser > > but I couldn't find a C library > ftp://ftp.cogsci.ed.ac.uk/pub/richard/rxp.tar.gz > It's an alpha test version. Please report bugs to me. > -- Richard -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@cwi.nl | ++++ if you agree copy these lines to your sig ++++ http://www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm _______________ DOC-SIG - SIG for the Python Documentation Project send messages to: doc-sig@python.org administrivia to: doc-sig-request@python.org _______________ From robert@directed.edu Wed Dec 24 17:47:16 1997 From: robert@directed.edu (robert@directed.edu) Date: Wed, 24 Dec 1997 12:47:16 -0500 Subject: [DOC-SIG] P R E S S R E L E A S E Message-ID: DirectED - The New Way to Learn! DirectED is a distance education school that will revolutionize the way people will think about education in the future. Students can now study in the comfort of their own home to earn their diploma. What is unique about DirectED is that it is completely Internet based. Students attend classes in a virtual campus that has an employment center, library, cafeteria, computer lab, book store, faculty lounge, business office, student residence, and virtual classrooms. You can visit the campus at http://www.directed.edu. All DirectED Students will receive: Acer Multimedia Computer Lexmark Color Printer Windows 95 Office 97 Professional Books Prepaid Internet Connection for 1 Year Access to DirectED Web Site Toll Free Support for 1 Year DirectED programs are certified and registered with Department of Training and Advanced Education. DirectED is a member of the Better Business Bureau. DirectED partners include the Toronto Dominion Bank, MTS Sympatico, Acer, Course Technology, Microsoft, and Computer Associates. To find out more about THE NEW WAY TO LEARN please visit DirectED's business office at http://www.directed.edu/bus.html _______________ DOC-SIG - SIG for the Python Documentation Project send messages to: doc-sig@python.org administrivia to: doc-sig-request@python.org _______________