comp-hist-devel — This list is for discussion regarding development of the comp-hist project.

[Comp-hist-devel] VRML plans

[Kurt R. <ku...@ra...>]

I've been doing some research on the current state of VRML, and it seems like we could be able to generate a parser that would let the user 'fly through' the tree.  I've found a page at:
http://www.webdeveloper.com/vrml/vrml_managing_network_webview.html
which provides a semi-relevant intro to VRML, and we could probably adapt  some of what it describes to creating a 3D directed graph of the tree.  If anyone wants to work on a parser for VRML, that'd be great, but that isn't a necessity.

-Kurt

Re: [Comp-hist-devel] XML plans

[Kurt R. <ku...@ra...>]

Well, I've got a basic DTD built and checked in now.  It's in parser/xml/dtd, or http://comp-hist.sourceforge.net/comp-hist.dtd if you don't have CVS access.  I'd appreciate comments on it, so let me know what you like and what you think needs changing.

-Kurt 
On Tue, Sep 19, 2000 at 03:07:08PM -0400, Kurt Raschke wrote:
> I'm working on a DTD for the project, which will mimic the syntax of our already-built language, except it will be viewable in any XML-capable browser.  I should have a copy checked into cvs soon.
> 
> -Kurt
> On Mon, Sep 18, 2000 at 08:54:41PM -0400, Scott Fenton wrote:
> > OK, here's where we are. I've just gotten my debian box revived, so I can get back to working on this project. What I'm going to be working on next is toxml. What I need from you guys is suggestions on what you'd like to see in our XML system. Any ideas?
> > 
> > -Scott
> > 
> > -- 
> > pub  1024D/B5A525FA 2000-08-26 Scott Fenton <sj...@ra...>
> > sub  1024g/A41E2502 2000-08-26 
> > _______________________________________________
> > Comp-hist-devel mailing list
> > Com...@li...  
> > http://lists.sourceforge.net/mailman/listinfo/comp-hist-devel

Re: [Comp-hist-devel] XML plans

[Kurt R. <ku...@ra...>]

I'm working on a DTD for the project, which will mimic the syntax of our already-built language, except it will be viewable in any XML-capable browser.  I should have a copy checked into cvs soon.

-Kurt
On Mon, Sep 18, 2000 at 08:54:41PM -0400, Scott Fenton wrote:
> OK, here's where we are. I've just gotten my debian box revived, so I can get back to working on this project. What I'm going to be working on next is toxml. What I need from you guys is suggestions on what you'd like to see in our XML system. Any ideas?
> 
> -Scott
> 
> -- 
> pub  1024D/B5A525FA 2000-08-26 Scott Fenton <sj...@ra...>
> sub  1024g/A41E2502 2000-08-26 
> _______________________________________________
> Comp-hist-devel mailing list
> Com...@li...  
> http://lists.sourceforge.net/mailman/listinfo/comp-hist-devel

Re: [Comp-hist-devel] 1.0

[<chr...@en...>]

On Wed, 13 Sep 2000, Hans B Pufal wrote:

> > > > > I would also repeat a suggestion I made some time ago - a facility for
> > > > > anyone to be able to provide input simply. I see this as being an edit
> > > > > link on each displayed node, a form pops up with that node's data and
> > > > > the user can edit/add information. When the form is submitted, it is
> > > > > saved in an edit file which is immediatley visible to subsequent users
> > > > > but allows us to moderate what goes into the definitive database.
> > > > >
> > > >
> > > > Sounds like an interesting compromise. I'll have to see.
> > > I think my web form already /sort of/ provides for this, doesn't it?
> 
> Sort of, but it needs linking to a view of our data. The effort needed
> to actually look at our data is way too high, download, make, eidt etc.
> We MUST have a web based viewing system with an easy forma based
> mechanism for the casual (though informed) user to provide input.
>

Concerning this problem, I think we could use php/mysql (or whichever
database you want). With the C parser, we can easily enter all the data
we've got into a database and then, easily browse it with php.
We could provide the opportunity to list all the nodes, to search for a
particular node and edit them. Then, we can add a link to allow the user
to modify the data. I'll start to work on it.

	Christophe
 
> 
>   -- Hans
> _______________________________________________
> Comp-hist-devel mailing list
> Com...@li...  
> http://lists.sourceforge.net/mailman/listinfo/comp-hist-devel
> 

[Comp-hist-devel] XML plans

[Scott F. <sj...@ra...>]

OK, here's where we are. I've just gotten my debian box revived, so I can get back to working on this project. What I'm going to be working on next is toxml. What I need from you guys is suggestions on what you'd like to see in our XML system. Any ideas?

-Scott

-- 
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.0.2 (GNU/Linux)
Comment: For info see http://www.gnupg.org

mQGiBDmoHL8RBACt7yc65iKzR4IW2kKF0wjfZlRVwcwEws6HueM9uKF6HCzyFtyM
XJiHz8f3LI2NY/GedfF+XTFc2zQlPummiOrHfAx9Y2hV4ajEpxNgqm36BT21vLuI
iTB6roHHm+EiK9dRINyc+kB4v5QV5S9BGxPuygm/3yLZLmGH6RUmSxis1wCgvGnX
n3qhbP7Yf/mLO1Du3oEJhR8EAI+TFhyxg3y2xv++xCxKOL9ofF+wPA4EkXPCAokW
10hDmeGY246wOMPWC0Hou1QJqqRN82n5BbJAzUnE/Iht82SEJgM1vhIbp0uShUdS
jzKPnBBUTzLQFPbAG9hDaU/98JklsyDIbacavCuCtky6Xs/wmPjESUJsIl6FiHRv
Uz9jA/96nxsDQ8YMEr51F3sHubn7BwrYqGOZLT5btLMG1i9OnWyy0npQ5wKvM2bT
t2i6QPcHydTAkX+DLXQv8UeJE+Qpq+duoofMpxdFOKgqW3x0kKWGP14UoOqSQFGL
K4fStiwR7fCtExrMFKUHaP5Sij7v8VoyBtyK+w45LoWFFXsPeLQhU2NvdHQgRmVu
dG9uIDxzajEyZm5AcmFzY2hrZS5uZXQ+iFYEExECABYFAjmoHL8ECwoEAwMVAwID
FgIBAheAAAoJEGtrXbm1pSX6WZoAnRzHUYn+/MSVAsmK7bLJrAfmn8Y+AJ4uzZEX
OxVuc0sGg/J0AqlYNpMcqrkBDQQ5qBzcEAQAhJgZzAKBjuKwS0owgknuN+5kSu9U
tk75ZKRpBMTFfW1Js2E5v96M3Z4XAvyJFhQYaXWZn0QQY4PkrbbfKib4X3Onn/Gx
M1mdtWKAXxb1+JuEH/dpVemt2EDLn6b2VVI5iE6U0HcrJjkvt7DLKsvQFRnnqd6M
SHdN3XmxhY+VakcAAwUD/iTTv+fpM+Nn2izo7z0BmRu/+GwQgvOF8Qc+8YA6JgaA
UUrD7nO3xUpkoK6gr1se2Wu98BFv2GSKRZZF9QljXn2vGNreYRRI9ZhWpKm3zflz
uC7lz63QaiZdAPup37yWYXyaAvUvYufORC4hS9mZUgKbbOC+O6xdzkLBerBk/FK+
iEYEGBECAAYFAjmoHNwACgkQa2tdubWlJfqAvQCfWMWnlCab4pUJEvE4gjSFJ+EV
5LsAn2yeJT+7MWYKIQpPmGMMjeGkykK1
=tjOP
-----END PGP PUBLIC KEY BLOCK-----

Re: [Comp-hist-devel] 1.0

[Hans B P. <ha...@di...>]

Scott Fenton wrote:

> > > An XML database sounds like an interesting idea. I'll look into it.
> > If we develop a decent DTD for it, then all someone would need would be an XML capable browser, if all they wanted to do was view it in a text format.
> 
> Or however the browser happens to render XML.

II really think XML is the way to go. There are lost of tools out there
for editing and displaying XML, we should be concentrating on getting
the information into a usable form not developing tools!

> > > > I would also repeat a suggestion I made some time ago - a facility for
> > > > anyone to be able to provide input simply. I see this as being an edit
> > > > link on each displayed node, a form pops up with that node's data and
> > > > the user can edit/add information. When the form is submitted, it is
> > > > saved in an edit file which is immediatley visible to subsequent users
> > > > but allows us to moderate what goes into the definitive database.
> > > >
> > >
> > > Sounds like an interesting compromise. I'll have to see.
> > I think my web form already /sort of/ provides for this, doesn't it?

Sort of, but it needs linking to a view of our data. The effort needed
to actually look at our data is way too high, download, make, eidt etc.
We MUST have a web based viewing system with an easy forma based
mechanism for the casual (though informed) user to provide input.

> > With regard to visualization, how about VRML?  That way, importance sould be shown by depth, as in the closer to you, the more important.  We'd probably also wnat to include Scott's idea of being able to collapse the tree by file, so that each file could be collapsed into one node.  For providing access to additional information, we could set things up so that clicking on a node takes you into a VRML "subworld" where we could add whatever information is appropriate.

This sounds interetsing! Where is VRML today I haven't heard much about
it recently!


  -- Hans

Re: [Comp-hist-devel] 1.0

[Scott F. <sj...@ra...>]

On Tue, Sep 12, 2000 at 08:51:02PM -0400, the keyboard of Kurt Raschke wrote:
> Below are my thoughts on this subject:
> On Tue, Sep 12, 2000 at 06:51:11AM -0400, Scott Fenton wrote:
> > On Tue, Sep 12, 2000 at 07:36:33AM +0100, the keyboard of Hans B Pufal wrote:
> > > Christophe Fergeau wrote:
> > >  
> > > > I think we are not ready to release 1.0 We've got a lot of data about a lot
> > > > of different OSes and computers and ... but we don't have any convenient
> > > > means to display it. We've got our parsers to graphvidz and vcg but we've
> > > > got far too much information to display so it is not usable. As I already
> > > > wrote, we've got to sort all the data we've got with respect to its
> > > > importance if we want to simplify the display.
> > > 
> > > I completely agree, we need to sort out the data and provide a better
> > > display facility, based on html/xml.
> > 
> > An XML database sounds like an interesting idea. I'll look into it.
> If we develop a decent DTD for it, then all someone would need would be an XML capable browser, if all they wanted to do was view it in a text format.

Or however the browser happens to render XML.

> > > 
> > > I would also repeat a suggestion I made some time ago - a facility for
> > > anyone to be able to provide input simply. I see this as being an edit
> > > link on each displayed node, a form pops up with that node's data and
> > > the user can edit/add information. When the form is submitted, it is
> > > saved in an edit file which is immediatley visible to subsequent users
> > > but allows us to moderate what goes into the definitive database.
> > > 
> > 
> > Sounds like an interesting compromise. I'll have to see.
> I think my web form already /sort of/ provides for this, doesn't it?

Yes it does, but what I think would be even more useful would be if you could do a file in CVS or on the website with all the data, so it starts off by being /in the tree/.

> > > The problem I see at this point is that in order for anyone to provide
> > > real input they need to download, make and manually search the database,
> > > many very knowledgable folks with valuable input will not be willing to
> > > do that.
> > > 
> > > > We'll also have to write a visualization library which suits our needs (and
> > > > maybe we'll use our c parser which currently is not really useful). Indeed,
> > > > with all the data we've got, we should provide an easy way to visualise it
> > > > and to browse through it. If we decide to write a visualization library, I'm
> > > > not sure whether we should integrate it in 1.0 or not. We also have to find
> > > > what is the most appropriate means of displaying our database.
> > > 
> > > Take a look at the CCC search page for a simple way of
> > > searching/displaying.
> > > 
> (I've snipped a bit here.)
> With regard to visualization, how about VRML?  That way, importance sould be shown by depth, as in the closer to you, the more important.  We'd probably also wnat to include Scott's idea of being able to collapse the tree by file, so that each file could be collapsed into one node.  For providing access to additional information, we could set things up so that clicking on a node takes you into a VRML "subworld" where we could add whatever information is appropriate.
>

All this neat stuff will be easier in day or two. Right now I'm working on a perl parser something like the C library. Once that's done, we'll be down to two real "parsers" and as many output formats as we want.

-Scott

-- 
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.0.2 (GNU/Linux)
Comment: For info see http://www.gnupg.org

mQGiBDmoHL8RBACt7yc65iKzR4IW2kKF0wjfZlRVwcwEws6HueM9uKF6HCzyFtyM
XJiHz8f3LI2NY/GedfF+XTFc2zQlPummiOrHfAx9Y2hV4ajEpxNgqm36BT21vLuI
iTB6roHHm+EiK9dRINyc+kB4v5QV5S9BGxPuygm/3yLZLmGH6RUmSxis1wCgvGnX
n3qhbP7Yf/mLO1Du3oEJhR8EAI+TFhyxg3y2xv++xCxKOL9ofF+wPA4EkXPCAokW
10hDmeGY246wOMPWC0Hou1QJqqRN82n5BbJAzUnE/Iht82SEJgM1vhIbp0uShUdS
jzKPnBBUTzLQFPbAG9hDaU/98JklsyDIbacavCuCtky6Xs/wmPjESUJsIl6FiHRv
Uz9jA/96nxsDQ8YMEr51F3sHubn7BwrYqGOZLT5btLMG1i9OnWyy0npQ5wKvM2bT
t2i6QPcHydTAkX+DLXQv8UeJE+Qpq+duoofMpxdFOKgqW3x0kKWGP14UoOqSQFGL
K4fStiwR7fCtExrMFKUHaP5Sij7v8VoyBtyK+w45LoWFFXsPeLQhU2NvdHQgRmVu
dG9uIDxzajEyZm5AcmFzY2hrZS5uZXQ+iFYEExECABYFAjmoHL8ECwoEAwMVAwID
FgIBAheAAAoJEGtrXbm1pSX6WZoAnRzHUYn+/MSVAsmK7bLJrAfmn8Y+AJ4uzZEX
OxVuc0sGg/J0AqlYNpMcqrkBDQQ5qBzcEAQAhJgZzAKBjuKwS0owgknuN+5kSu9U
tk75ZKRpBMTFfW1Js2E5v96M3Z4XAvyJFhQYaXWZn0QQY4PkrbbfKib4X3Onn/Gx
M1mdtWKAXxb1+JuEH/dpVemt2EDLn6b2VVI5iE6U0HcrJjkvt7DLKsvQFRnnqd6M
SHdN3XmxhY+VakcAAwUD/iTTv+fpM+Nn2izo7z0BmRu/+GwQgvOF8Qc+8YA6JgaA
UUrD7nO3xUpkoK6gr1se2Wu98BFv2GSKRZZF9QljXn2vGNreYRRI9ZhWpKm3zflz
uC7lz63QaiZdAPup37yWYXyaAvUvYufORC4hS9mZUgKbbOC+O6xdzkLBerBk/FK+
iEYEGBECAAYFAjmoHNwACgkQa2tdubWlJfqAvQCfWMWnlCab4pUJEvE4gjSFJ+EV
5LsAn2yeJT+7MWYKIQpPmGMMjeGkykK1
=tjOP
-----END PGP PUBLIC KEY BLOCK-----

Re: [Comp-hist-devel] 1.0

[Kurt R. <ku...@ra...>]

Below are my thoughts on this subject:
On Tue, Sep 12, 2000 at 06:51:11AM -0400, Scott Fenton wrote:
> On Tue, Sep 12, 2000 at 07:36:33AM +0100, the keyboard of Hans B Pufal wrote:
> > Christophe Fergeau wrote:
> >  
> > > I think we are not ready to release 1.0 We've got a lot of data about a lot
> > > of different OSes and computers and ... but we don't have any convenient
> > > means to display it. We've got our parsers to graphvidz and vcg but we've
> > > got far too much information to display so it is not usable. As I already
> > > wrote, we've got to sort all the data we've got with respect to its
> > > importance if we want to simplify the display.
> > 
> > I completely agree, we need to sort out the data and provide a better
> > display facility, based on html/xml.
> 
> An XML database sounds like an interesting idea. I'll look into it.
If we develop a decent DTD for it, then all someone would need would be an XML capable browser, if all they wanted to do was view it in a text format.
> > 
> > I would also repeat a suggestion I made some time ago - a facility for
> > anyone to be able to provide input simply. I see this as being an edit
> > link on each displayed node, a form pops up with that node's data and
> > the user can edit/add information. When the form is submitted, it is
> > saved in an edit file which is immediatley visible to subsequent users
> > but allows us to moderate what goes into the definitive database.
> > 
> 
> Sounds like an interesting compromise. I'll have to see.
I think my web form already /sort of/ provides for this, doesn't it?
> > The problem I see at this point is that in order for anyone to provide
> > real input they need to download, make and manually search the database,
> > many very knowledgable folks with valuable input will not be willing to
> > do that.
> > 
> > > We'll also have to write a visualization library which suits our needs (and
> > > maybe we'll use our c parser which currently is not really useful). Indeed,
> > > with all the data we've got, we should provide an easy way to visualise it
> > > and to browse through it. If we decide to write a visualization library, I'm
> > > not sure whether we should integrate it in 1.0 or not. We also have to find
> > > what is the most appropriate means of displaying our database.
> > 
> > Take a look at the CCC search page for a simple way of
> > searching/displaying.
> > 
(I've snipped a bit here.)
With regard to visualization, how about VRML?  That way, importance sould be shown by depth, as in the closer to you, the more important.  We'd probably also wnat to include Scott's idea of being able to collapse the tree by file, so that each file could be collapsed into one node.  For providing access to additional information, we could set things up so that clicking on a node takes you into a VRML "subworld" where we could add whatever information is appropriate.

-Kurt

Re: [Comp-hist-devel] 1.0

[Scott F. <sj...@ra...>]

On Tue, Sep 12, 2000 at 07:36:33AM +0100, the keyboard of Hans B Pufal wrote:
> Christophe Fergeau wrote:
>  
> > I think we are not ready to release 1.0 We've got a lot of data about a lot
> > of different OSes and computers and ... but we don't have any convenient
> > means to display it. We've got our parsers to graphvidz and vcg but we've
> > got far too much information to display so it is not usable. As I already
> > wrote, we've got to sort all the data we've got with respect to its
> > importance if we want to simplify the display.
> 
> I completely agree, we need to sort out the data and provide a better
> display facility, based on html/xml.

An XML database sounds like an interesting idea. I'll look into it.

> 
> I would also repeat a suggestion I made some time ago - a facility for
> anyone to be able to provide input simply. I see this as being an edit
> link on each displayed node, a form pops up with that node's data and
> the user can edit/add information. When the form is submitted, it is
> saved in an edit file which is immediatley visible to subsequent users
> but allows us to moderate what goes into the definitive database.
> 

Sounds like an interesting compromise. I'll have to see.

> The problem I see at this point is that in order for anyone to provide
> real input they need to download, make and manually search the database,
> many very knowledgable folks with valuable input will not be willing to
> do that.
> 
> > We'll also have to write a visualization library which suits our needs (and
> > maybe we'll use our c parser which currently is not really useful). Indeed,
> > with all the data we've got, we should provide an easy way to visualise it
> > and to browse through it. If we decide to write a visualization library, I'm
> > not sure whether we should integrate it in 1.0 or not. We also have to find
> > what is the most appropriate means of displaying our database.
> 
> Take a look at the CCC search page for a simple way of
> searching/displaying.
> 
> > Summary : we should wait to release 1.0 because we've got a lot of
> > information but nearly nothing to use it easily
> 
> I agree, quite a bit more work before we can really say it's 1.0
> 
>  -- Hans
> _______________________________________________
> Comp-hist-devel mailing list
> Com...@li...  
> http://lists.sourceforge.net/mailman/listinfo/comp-hist-devel

-- 
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.0.2 (GNU/Linux)
Comment: For info see http://www.gnupg.org

mQGiBDmoHL8RBACt7yc65iKzR4IW2kKF0wjfZlRVwcwEws6HueM9uKF6HCzyFtyM
XJiHz8f3LI2NY/GedfF+XTFc2zQlPummiOrHfAx9Y2hV4ajEpxNgqm36BT21vLuI
iTB6roHHm+EiK9dRINyc+kB4v5QV5S9BGxPuygm/3yLZLmGH6RUmSxis1wCgvGnX
n3qhbP7Yf/mLO1Du3oEJhR8EAI+TFhyxg3y2xv++xCxKOL9ofF+wPA4EkXPCAokW
10hDmeGY246wOMPWC0Hou1QJqqRN82n5BbJAzUnE/Iht82SEJgM1vhIbp0uShUdS
jzKPnBBUTzLQFPbAG9hDaU/98JklsyDIbacavCuCtky6Xs/wmPjESUJsIl6FiHRv
Uz9jA/96nxsDQ8YMEr51F3sHubn7BwrYqGOZLT5btLMG1i9OnWyy0npQ5wKvM2bT
t2i6QPcHydTAkX+DLXQv8UeJE+Qpq+duoofMpxdFOKgqW3x0kKWGP14UoOqSQFGL
K4fStiwR7fCtExrMFKUHaP5Sij7v8VoyBtyK+w45LoWFFXsPeLQhU2NvdHQgRmVu
dG9uIDxzajEyZm5AcmFzY2hrZS5uZXQ+iFYEExECABYFAjmoHL8ECwoEAwMVAwID
FgIBAheAAAoJEGtrXbm1pSX6WZoAnRzHUYn+/MSVAsmK7bLJrAfmn8Y+AJ4uzZEX
OxVuc0sGg/J0AqlYNpMcqrkBDQQ5qBzcEAQAhJgZzAKBjuKwS0owgknuN+5kSu9U
tk75ZKRpBMTFfW1Js2E5v96M3Z4XAvyJFhQYaXWZn0QQY4PkrbbfKib4X3Onn/Gx
M1mdtWKAXxb1+JuEH/dpVemt2EDLn6b2VVI5iE6U0HcrJjkvt7DLKsvQFRnnqd6M
SHdN3XmxhY+VakcAAwUD/iTTv+fpM+Nn2izo7z0BmRu/+GwQgvOF8Qc+8YA6JgaA
UUrD7nO3xUpkoK6gr1se2Wu98BFv2GSKRZZF9QljXn2vGNreYRRI9ZhWpKm3zflz
uC7lz63QaiZdAPup37yWYXyaAvUvYufORC4hS9mZUgKbbOC+O6xdzkLBerBk/FK+
iEYEGBECAAYFAjmoHNwACgkQa2tdubWlJfqAvQCfWMWnlCab4pUJEvE4gjSFJ+EV
5LsAn2yeJT+7MWYKIQpPmGMMjeGkykK1
=tjOP
-----END PGP PUBLIC KEY BLOCK-----

Re: [Comp-hist-devel] 1.0

[Hans B P. <ha...@di...>]

Christophe Fergeau wrote:
 
> I think we are not ready to release 1.0 We've got a lot of data about a lot
> of different OSes and computers and ... but we don't have any convenient
> means to display it. We've got our parsers to graphvidz and vcg but we've
> got far too much information to display so it is not usable. As I already
> wrote, we've got to sort all the data we've got with respect to its
> importance if we want to simplify the display.

I completely agree, we need to sort out the data and provide a better
display facility, based on html/xml.

I would also repeat a suggestion I made some time ago - a facility for
anyone to be able to provide input simply. I see this as being an edit
link on each displayed node, a form pops up with that node's data and
the user can edit/add information. When the form is submitted, it is
saved in an edit file which is immediatley visible to subsequent users
but allows us to moderate what goes into the definitive database.

The problem I see at this point is that in order for anyone to provide
real input they need to download, make and manually search the database,
many very knowledgable folks with valuable input will not be willing to
do that.

> We'll also have to write a visualization library which suits our needs (and
> maybe we'll use our c parser which currently is not really useful). Indeed,
> with all the data we've got, we should provide an easy way to visualise it
> and to browse through it. If we decide to write a visualization library, I'm
> not sure whether we should integrate it in 1.0 or not. We also have to find
> what is the most appropriate means of displaying our database.

Take a look at the CCC search page for a simple way of
searching/displaying.

> Summary : we should wait to release 1.0 because we've got a lot of
> information but nearly nothing to use it easily

I agree, quite a bit more work before we can really say it's 1.0

 -- Hans

Re: [Comp-hist-devel] 1.0

[Christophe F. <Chr...@fn...>]

I think we are not ready to release 1.0 We've got a lot of data about a lot
of different OSes and computers and ... but we don't have any convenient
means to display it. We've got our parsers to graphvidz and vcg but we've
got far too much information to display so it is not usable. As I already
wrote, we've got to sort all the data we've got with respect to its
importance if we want to simplify the display.
We'll also have to write a visualization library which suits our needs (and
maybe we'll use our c parser which currently is not really useful). Indeed,
with all the data we've got, we should provide an easy way to visualise it
and to browse through it. If we decide to write a visualization library, I'm
not sure whether we should integrate it in 1.0 or not. We also have to find
what is the most appropriate means of displaying our database.

Summary : we should wait to release 1.0 because we've got a lot of
information but nearly nothing to use it easily

        Christophe

----- Original Message -----
From: Kurt Raschke <ku...@ra...>
To: <com...@li...>
Sent: Saturday, September 09, 2000 12:48 AM
Subject: Re: [Comp-hist-devel] 1.0


> I'd rather put 0.6 out first, and see what happens.  We should then do
some sort of code freeze, get the bugs out, and finally put out 1.0
> -Kurt
> On Wed, Sep 06, 2000 at 06:02:24PM -0400, Scott Fenton wrote:
> > OK, now that that website is up (thanks) and we have that unix tree
merged in (thank me), what do you people think should be let until we put
1.0 out? Just a thought for you to discuss. Please do.
> >
> > -Scott
> >
> > --
> > pub  1024D/B5A525FA 2000-08-26 Scott Fenton <sj...@ra...>
> > sub  1024g/A41E2502 2000-08-26
> > _______________________________________________
> > Comp-hist-devel mailing list
> > Com...@li...
> > http://lists.sourceforge.net/mailman/listinfo/comp-hist-devel
> _______________________________________________
> Comp-hist-devel mailing list
> Com...@li...
> http://lists.sourceforge.net/mailman/listinfo/comp-hist-devel

Re: [Comp-hist-devel] 1.0

[Kurt R. <ku...@ra...>]

I'd rather put 0.6 out first, and see what happens.  We should then do some sort of code freeze, get the bugs out, and finally put out 1.0
-Kurt
On Wed, Sep 06, 2000 at 06:02:24PM -0400, Scott Fenton wrote:
> OK, now that that website is up (thanks) and we have that unix tree merged in (thank me), what do you people think should be let until we put 1.0 out? Just a thought for you to discuss. Please do.
> 
> -Scott
> 
> -- 
> pub  1024D/B5A525FA 2000-08-26 Scott Fenton <sj...@ra...>
> sub  1024g/A41E2502 2000-08-26 
> _______________________________________________
> Comp-hist-devel mailing list
> Com...@li...  
> http://lists.sourceforge.net/mailman/listinfo/comp-hist-devel

Re: [Comp-hist-devel] C parser

[Christophe F. <Chr...@fn...>]

----- Original Message -----
From: Hans B Pufal <ha...@di...>
To: <com...@li...>
Sent: Thursday, September 07, 2000 10:09 PM
Subject: Re: [Comp-hist-devel] C parser


> Christophe Fergeau wrote:
>
> I do not have a problem making it an option. But how often do we run the
> parser?
> Until the parser becomes part of a CGI script at which point speed would
> be an issue I do not see the necessity of making it super fast.
>
> How does your B-tree time compare with the time when duplicate checking
> is disabled?
>
The difference is not significant when I loop 32 times (it drops from 7s to
6s
but I use a watch to measure time so it is not accurate at all).  Moreover,
when modifying the parser, I realized that we call seek_node when we update
the links so we can call it one more time, it does not really matter if our
search function is not too slow.

> > I hope I didn't break anything in parser.c. I did not look at html.c so
it
> > should not work anymore
>
> What you are doing is internal to the parser, it should nt affect HTML
> which simply traverses the linked list produced by parser.

The parser no longer returns a list : it returns a tree instead. I modified
html.c to deal with this, there were very few things to modify (just have a
look at the files I joined)

        Christophe

Re: [Comp-hist-devel] C parser

[Hans B P. <ha...@di...>]

Christophe Fergeau wrote:

> > Yes I agree that seek_node is not very fast, especially when the number
> > of nodes increases! I think it would be better to find a better search
> > algorithm though, the check for a duplicate node is important since we
> > could lose information if a duplicate node occurs.
> >
> I think this search should only be done in a debug mode to ensure we don't
> lose information but I think it should be disabled by default : in a
> 'normal' use, we can assume the data files are error free and disable this
> check.

I do not have a problem making it an option. But how often do we run the
parser?
Until the parser becomes part of a CGI script at which point speed would
be an issue I do not see the necessity of making it super fast.

> > I think it was your idea to use b-trees to improve search time.
> 
> I modified your code to use bst. It is noticeably faster when I parse
> dump1.txt several times : it only takes 7 seconds to parse it 32 times (it
> took at least 20s with a list). It could be even more efficient if the tree
> was balanced but it is quite painful to implement. Currently, since the node
> ids are often sorted, the tree we get is probably poorly balanced. Maybe we
> should have a look at glib (from gtk) which implements balanced search
> trees.

How does your B-tree time compare with the time when duplicate checking
is disabled?

> I hope I didn't break anything in parser.c. I did not look at html.c so it
> should not work anymore

What you are doing is internal to the parser, it should nt affect HTML
which simply traverses the linked list produced by parser.

> Also, I don't really see the point of preserving the order of the file in
> the list we create for multiple fields specifications. It would be easier
> and faster to reverse the order of the file and, in my opinion, it wouldn't
> change anything. However, if we want to preserve the order of the file and
> to be more efficient (if the list has many elements), we should create the
> lists in reverse order and then, mirror them just before creating a new
> node. Currently, it does not matter because the lists have at most 3
> elements but it may be useful one day.

Where we talk about links I agree but this feature can also be used for
simple string fields where order may be improtatnt, e.g instead of using
one long text string for Info:, we could use multiple Info: records
making it easier to edit and read.

> I also found a typo in dump1.txt : in the QL node, we have an Ingo node
> instead of an Info

Ah, yes the parser is set to not complain about unknown field names
since there would be many. Can you go into the QL source file and fix it
- should be in the sinclair file.

  -- Hans

Re: [Comp-hist-devel] C parser

[Christophe F. <Chr...@fn...>]

----- Original Message -----
From: Hans B Pufal <ha...@di...>
To: <com...@li...>
Sent: Thursday, September 07, 2000 2:14 AM
Subject: Re: [Comp-hist-devel] C parser


> Yes I agree that seek_node is not very fast, especially when the number
> of nodes increases! I think it would be better to find a better search
> algorithm though, the check for a duplicate node is important since we
> could lose information if a duplicate node occurs.
>
I think this search should only be done in a debug mode to ensure we don't
lose information but I think it should be disabled by default : in a
'normal' use, we can assume the data files are error free and disable this
check.

> I think it was your idea to use b-trees to improve search time.

I modified your code to use bst. It is noticeably faster when I parse
dump1.txt several times : it only takes 7 seconds to parse it 32 times (it
took at least 20s with a list). It could be even more efficient if the tree
was balanced but it is quite painful to implement. Currently, since the node
ids are often sorted, the tree we get is probably poorly balanced. Maybe we
should have a look at glib (from gtk) which implements balanced search
trees.

I hope I didn't break anything in parser.c. I did not look at html.c so it
should not work anymore

> >         in parse_files, when the parser processes LINK fields and
> > turns the strings in struct Nodelink *, it now frees the memory which
> > was occupied by the string
>
> No! The string was not malloc'd, so freeing it is an error. All memory
> allocation is done as blocks so as to minimize the calls on malloc and
> to better use memeory (fewer calls to malloc = lower block allocation
> overhead).
>
Indeed it is a mistake. When we the LINK fields could only cope with one
link per node, it was possible to use this free but I forgot you modify the
memory allocation since then.

Also, I don't really see the point of preserving the order of the file in
the list we create for multiple fields specifications. It would be easier
and faster to reverse the order of the file and, in my opinion, it wouldn't
change anything. However, if we want to preserve the order of the file and
to be more efficient (if the list has many elements), we should create the
lists in reverse order and then, mirror them just before creating a new
node. Currently, it does not matter because the lists have at most 3
elements but it may be useful one day.

I also found a typo in dump1.txt : in the QL node, we have an Ingo node
instead of an Info

    Christophe
>
>  -- Hans
> _______________________________________________
> Comp-hist-devel mailing list
> Com...@li...
> http://lists.sourceforge.net/mailman/listinfo/comp-hist-devel

Re: [Comp-hist-devel] C parser

[Hans B P. <ha...@di...>]

> Christophe Fergeau wrote:
 
> I just had a look at your new parser. I played a little with it and
> modified two small things in parser.c :

>         in add_new_node, if you suppress (which is not necessary if we
> are careful)
> 
>            if (seek_node (list, tmp->id))
>                     error (0, NULL, "Duplicate node id");
> 
>         the parsing is faster (on my machine, when I parse dump1.txt
> 32 times, it is             twice as fast). If you define SPEED when
> compiling, this check is ignored.

Yes I agree that seek_node is not very fast, especially when the number
of nodes increases! I think it would be better to find a better search
algorithm though, the check for a duplicate node is important since we
could lose information if a duplicate node occurs.

I think it was your idea to use b-trees to improve search time.

>         in parse_files, when the parser processes LINK fields and
> turns the strings in struct Nodelink *, it now frees the memory which
> was occupied by the string

No! The string was not malloc'd, so freeing it is an error. All memory
allocation is done as blocks so as to minimize the calls on malloc and
to better use memeory (fewer calls to malloc = lower block allocation
overhead).


 -- Hans

[Comp-hist-devel] 1.0

[Scott F. <sj...@ra...>]

OK, now that that website is up (thanks) and we have that unix tree merged in (thank me), what do you people think should be let until we put 1.0 out? Just a thought for you to discuss. Please do.

-Scott

-- 
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.0.2 (GNU/Linux)
Comment: For info see http://www.gnupg.org

mQGiBDmoHL8RBACt7yc65iKzR4IW2kKF0wjfZlRVwcwEws6HueM9uKF6HCzyFtyM
XJiHz8f3LI2NY/GedfF+XTFc2zQlPummiOrHfAx9Y2hV4ajEpxNgqm36BT21vLuI
iTB6roHHm+EiK9dRINyc+kB4v5QV5S9BGxPuygm/3yLZLmGH6RUmSxis1wCgvGnX
n3qhbP7Yf/mLO1Du3oEJhR8EAI+TFhyxg3y2xv++xCxKOL9ofF+wPA4EkXPCAokW
10hDmeGY246wOMPWC0Hou1QJqqRN82n5BbJAzUnE/Iht82SEJgM1vhIbp0uShUdS
jzKPnBBUTzLQFPbAG9hDaU/98JklsyDIbacavCuCtky6Xs/wmPjESUJsIl6FiHRv
Uz9jA/96nxsDQ8YMEr51F3sHubn7BwrYqGOZLT5btLMG1i9OnWyy0npQ5wKvM2bT
t2i6QPcHydTAkX+DLXQv8UeJE+Qpq+duoofMpxdFOKgqW3x0kKWGP14UoOqSQFGL
K4fStiwR7fCtExrMFKUHaP5Sij7v8VoyBtyK+w45LoWFFXsPeLQhU2NvdHQgRmVu
dG9uIDxzajEyZm5AcmFzY2hrZS5uZXQ+iFYEExECABYFAjmoHL8ECwoEAwMVAwID
FgIBAheAAAoJEGtrXbm1pSX6WZoAnRzHUYn+/MSVAsmK7bLJrAfmn8Y+AJ4uzZEX
OxVuc0sGg/J0AqlYNpMcqrkBDQQ5qBzcEAQAhJgZzAKBjuKwS0owgknuN+5kSu9U
tk75ZKRpBMTFfW1Js2E5v96M3Z4XAvyJFhQYaXWZn0QQY4PkrbbfKib4X3Onn/Gx
M1mdtWKAXxb1+JuEH/dpVemt2EDLn6b2VVI5iE6U0HcrJjkvt7DLKsvQFRnnqd6M
SHdN3XmxhY+VakcAAwUD/iTTv+fpM+Nn2izo7z0BmRu/+GwQgvOF8Qc+8YA6JgaA
UUrD7nO3xUpkoK6gr1se2Wu98BFv2GSKRZZF9QljXn2vGNreYRRI9ZhWpKm3zflz
uC7lz63QaiZdAPup37yWYXyaAvUvYufORC4hS9mZUgKbbOC+O6xdzkLBerBk/FK+
iEYEGBECAAYFAjmoHNwACgkQa2tdubWlJfqAvQCfWMWnlCab4pUJEvE4gjSFJ+EV
5LsAn2yeJT+7MWYKIQpPmGMMjeGkykK1
=tjOP
-----END PGP PUBLIC KEY BLOCK-----

[Comp-hist-devel] The whole enchilada

[Hans B P. <ha...@di...>]

I generated an HTML file from all the data we currently have on-line. It
took a little editing and I will upload the necessary files later on.

Its a 2Mb file ! available at <http://www.aconit.org/dd.html>

All internal links should work fine, external links as always are
subject to verification.


Enjoy,

  -- Hans

[Comp-hist-devel] Web Form Submission

[<mu...@ru...>]

Below is the result of your feedback form.  It was submitted by
Richard Shetron (mu...@ru...) on Tuesday, September 5, 2000 at 08:17:00
---------------------------------------------------------------------------

type: comment

othersubj: Multics OS

nodes: not sure

message: If you look at www.multicians.org and alt.os.multics you'll an idea of how
primitive Unix is compared to its parent Multics.  I worked as a Multics
Analyst for over a year back in the 70's and nothing I've seen since then
has come anywhere near working as well and efficiently and easily as Multics.
Multics had the first commercial relational database system.
From the first boot back in 1969, the OS would snif out the devices and dynamically link
in the device drivers during every boot, no prebuilt kernels.
Dynamic linking was the default for everything and all 'files' where automatically mapped into
virtual memory

---------------------------------------------------------------------------

REMOTE_ADDR: 199.181.141.18
HTTP_USER_AGENT: Mozilla/4.75 [en] (Win98; U)

[Comp-hist-devel] Fixes for motorola/68xxx and changes to html.c

[Hans B P. <ha...@di...>]

I have uploaded to <ftp://aconit.org/pub/sep5.tgz> two files:

   motorola/68xxx

	Added date for 6809 and reference where I got the date (GMPP)
   
        Commented out 88100, with a comment as to why: 88000 is a
chipset
        comprising a processor the 88100 and an MMU the 88200, so we do
not
        need to cite both 88000 and 88100.

with this file changed, the C parser reports no errors - Yeah!

   scripts/new/html.c

         For references which begin with "http:" I make them real web
links
         so you can follow those linkes. 
         Todo: recognize other web addresses like ftp://, mailto: etc


 -- Hans

[Comp-hist-devel] Web Form Submission

[<da...@th...>]

Below is the result of your feedback form.  It was submitted by
Dan Reif (da...@th...) on Monday, September 4, 2000 at 07:43:16
---------------------------------------------------------------------------

type: add

nodes: (prior to integrated circuit, Mark I, and the rest, after Babbage)

message: http://www.cranfield.ac.uk/ccc/bpark/
and
http://www.bletchleypark.org.uk/
(the academic and public websites, respectively)

Bletchley Park was site of British code breaking during the second world war. It is where Alan Turing and a cast of thousands broke the Enigma cypher and where Tommy Flowers set up what some people call the world's first programmable electronic computer, Colossus. The future of the site and the musuem that is there (run by volunteers) is uncertain.

---------------------------------------------------------------------------

REMOTE_ADDR: 216.222.78.50
HTTP_USER_AGENT: Mozilla/4.0 (compatible; MSIE 5.0; Windows 95; DigExt)

Re: [Comp-hist-devel] Re: Troubles with the C parser

[Hans B P. <ha...@di...>]

Kurt Raschke wrote:
 
> I agree that the primary solution is to fix the fields that don't work, and then go back and fix whatver is causing the parser to coredump.  However, with the exception of the date fields, a lot of the errors that were flagged run fine on other parsers, so it may be a matter of both cleaning up the code a bit and loosening up the parser's strictness.

Actually none of the errors you see are fatal, e.g for the date errors,
I simply flag the error and continue, ditto for the link errors.

I have changed the parser a little to loosen up date handling and space
sin node links (though not yet in node ids) are suppressed.

Can you send me by private e-mail a copy of the data file, I still don't
have all the necessary components in place to run the make. 

My biggest worry in the core duump so if I can have the data file I can
work on that...

Regards

 -- Hans

Re: [Comp-hist-devel] Re: Troubles with the C parser

[Kurt R. <ku...@ra...>]

I agree that the primary solution is to fix the fields that don't work, and then go back and fix whatver is causing the parser to coredump.  However, with the exception of the date fields, a lot of the errors that were flagged run fine on other parsers, so it may be a matter of both cleaning up the code a bit and loosening up the parser's strictness.

-Kurt
On Sun, Sep 03, 2000 at 10:27:45AM +0100, Hans B Pufal wrote:
> (removed program output) 
> Well mostly, the parser is doing its job of validating the input. There
> are a lot of invalid datae fields, some Type fields with unsupported
> values and node links which don't!
> 
> What do you suggest? I can relax the parser checking, but I think the
> better solution is to fix the bad fields. I am more than open to
> adjusting the parser checks in appropriate ways, eg making the type
> field case insensitive would fix one or two issues.
> 
> Let me know.
> 
> -- Hans
> _______________________________________________
> Comp-hist-devel mailing list
> Com...@li...  
> http://lists.sourceforge.net/mailman/listinfo/comp-hist-devel

Re: [Comp-hist-devel] Re: Troubles with the C parser

[Hans B P. <ha...@di...>]

Kurt Raschke wrote:
> 
> Well, when I try to run all of comp-hist (in other words the output of 'make dump') through the html parser, look what happens:
> 
>  Date: TBD       ^
> ../../dump[560] Year out of range

Well, that date is not correct!

>  Date: 1992-8-34                ^
> ../../dump[1736] Day out of range

Yes, day number must be < 31

 ...  snip snip ...  more of the same



>  Type: announcemnet       ^
> ../../dump[6110] Invalid field value - using default

Missspelt 


>  Type: Os       ^
> ../../dump[6360] Invalid field value - using default

Accespt os or OS only

>  Name: Apple Computer, Inc.
>       ^
> ../../dump[9145] Duplicate field

Presumably there is already a Name: defined for this node


> Node fortran66, required field Name: not specified

No name specified for fortran66

> be : Cannot find Code taken from  node 'apple'
> next : Cannot find Code taken from  node 'apple'

The node apple is not found

> Node rt11, required field Name: not specified

rt11 has no name node

  ... snip snip ..

> 2.8bsd : Cannot find Successor to  node '2.79bsd 1000'
> 2.79bsd : Cannot find Successor to  node '2bsd 1000'
> 2bsd : Cannot find Successor to  node '1bsd 1000'

Most of the above are nodeids which cannot be found, is it a spacing 
issue? e.g should the last one read "lbsd1000"

> Segmentation fault (core dumped)

Hmm, this one worries me!


Well mostly, the parser is doing its job of validating the input. There
are a lot of invalid datae fields, some Type fields with unsupported
values and node links which don't!

What do you suggest? I can relax the parser checking, but I think the
better solution is to fix the bad fields. I am more than open to
adjusting the parser checks in appropriate ways, eg making the type
field case insensitive would fix one or two issues.

Let me know.

-- Hans

Re: [Comp-hist-devel] Re: Troubles with the C parser

[Kurt R. <ku...@ra...>]

Well, when I try to run all of comp-hist (in other words the output of 'make dump') through the html parser, look what happens:

 Date: TBD       ^
../../dump[560] Year out of range

 Date: 1992-8-34                ^
../../dump[1736] Day out of range

 Date: 1994-12-40                 ^
../../dump[2930] Day out of range

 Type: announcemnet       ^
../../dump[6110] Invalid field value - using default

 Type: Os       ^
../../dump[6360] Invalid field value - using default

 Date: ?       ^
../../dump[6867] Year out of range

 Date: when was IRIX announced?       ^
../../dump[6969] Year out of range

 Type: Os       ^
../../dump[6999] Invalid field value - using default

 Date: ?       ^
../../dump[7101] Year out of range

 Date: ?       ^
../../dump[7108] Year out of range

 Date: ?       ^
../../dump[7115] Year out of range

 Type: Os       ^
../../dump[7565] Invalid field value - using default

 Name: Apple Computer, Inc.
      ^
../../dump[9145] Duplicate field

 Type: company
      ^
../../dump[9147] Duplicate field

 Name: Computing-Tabulating-Recording Company
      ^
../../dump[10029] Duplicate field

 Date: 1911
      ^
../../dump[10030] Duplicate field

 Type: company
      ^
../../dump[10032] Duplicate field

 Type: other       ^
../../dump[10787] Invalid field value - using default

 Type: other       ^
../../dump[10795] Invalid field value - using default

 Type: other       ^
../../dump[10801] Invalid field value - using default

 Date: would be nice       ^
../../dump[10815] Year out of range

 Date: needed       ^
../../dump[10864] Year out of range

 Type: companyhp       ^
../../dump[11597] Invalid field value - using default

 Name: Hewlett-Packard
      ^
../../dump[11598] Duplicate field

 Date: 1939
      ^
../../dump[11599] Duplicate field

 Type: company#########################
      ^
../../dump[11601] Duplicate field
Node fortran66, required field Name: not specified
be : Cannot find Code taken from  node 'apple'
next : Cannot find Code taken from  node 'apple'
Node rt11, required field Name: not specified
ibm : Cannot find Successor to  node 'ctr'
1410 : Cannot find Successor to  node '303ctr'
macos9.0.4 : Cannot find Successor to  node 'macos9apple'
macos9.0.4 : Cannot find Code taken from  node 'hp'
Node windows98sp1, using default value for required field Type:
irix6.2 : Cannot find Successor to  node 'irix 5.3'
sysVr4 : Cannot find Successor to  node 'sysVr3.2 10000'
sysVr3 : Cannot find Successor to  node 'sysVr2 1000'
sysVr2 : Cannot find Successor to  node 'sysV 1000'
sysV : Cannot find Successor to  node 'sysIV 1000'
unixsystem3 : Cannot find Code taken from  node 'ts3.0.1 1000'
v10 : Cannot find Successor to  node 'v9 100'
v9 : Cannot find Successor to  node 'v8 1000'
v7 : Cannot find Successor to  node 'v6 1000'
v6 : Cannot find Successor to  node 'v5 100'
v5 : Cannot find Successor to  node 'v4 100'
v4 : Cannot find Successor to  node 'v3 100'
v3 : Cannot find Successor to  node 'v2 100'
v2 : Cannot find Successor to  node 'v1 100'
v1 : Cannot find Successor to  node 'updp7 100'
netbsd1.4.2 : Cannot find Successor to  node 'netbsd1.4.1 1000'
netbsd1.4.1 : Cannot find Successor to  node 'netbsd1.4 1000'
netbsd1.4 : Cannot find Successor to  node 'netbsd1.3 2000'
netbsd1.3.3 : Cannot find Successor to  node 'netbsd1.3.2 1000'
netbsd1.3.2 : Cannot find Successor to  node 'netbsd1.3.1 1000'
netbsd1.3.1 : Cannot find Successor to  node 'netbsd1.3 1'
netbsd1.3 : Cannot find Successor to  node 'netbsd1.2.1 1000'
netbsd1.2.1 : Cannot find Successor to  node 'netbsd1.2 1000'
netbsd1.2 : Cannot find Successor to  node 'netbsd1.1 1000'
netbsd1.1 : Cannot find Successor to  node 'netbsd1.0 1000'
freebsd5.0 : Cannot find Successor to  node 'freebsd4.0 1000'
freebsd4.0 : Cannot find Successor to  node 'freebsd3.0 1000'
freebsd3.5 : Cannot find Successor to  node 'freebsd3.4 1000'
freebsd3.4 : Cannot find Successor to  node 'freebsd3.3 1000'
freebsd3.3 : Cannot find Successor to  node 'freebsd3.2 1000'
freebsd3.2 : Cannot find Successor to  node 'freebsd3.1 1000'
freebsd3.0 : Cannot find Successor to  node 'freebsd2.2 1000'
freebsd2.2.8 : Cannot find Successor to  node 'freebsd2.2.7 1000'
freebsd2.2.7 : Cannot find Successor to  node 'freebsd2.2.6 1000'
freebsd2.2.6 : Cannot find Successor to  node 'freebsd2.2.5 1000'
freebsd2.2.5 : Cannot find Successor to  node 'freebsd2.2.2 1000'
freebsd2.2.2 : Cannot find Successor to  node 'freebsd2.2.1 1000'
freebsd2.2 : Cannot find Successor to  node 'freebsd2.1 1000'
freebsd2.1.7 : Cannot find Successor to  node 'freebsd2.1.6 1000'
freebsd2.1.6 : Cannot find Successor to  node 'freebsd2.1.5 1000'
freebsd2.1 : Cannot find Successor to  node 'freebsd2.0.5 1000'
freebsd2.0.5 : Cannot find Successor to  node 'freebsd2.0 1000'
freebsd2.0 : Cannot find Successor to  node 'freebsd1.1.5.1 1000'
freebsd1.1.5.1 : Cannot find Successor to  node 'freebsd1.1 1000'
freebsd1.1 : Cannot find Successor to  node 'freebsd1.0 1000'
4.4lite2 : Cannot find Successor to  node '4.4lite 1000'
4.4lite : Cannot find Successor to  node '4.4bsd 1000'
4.4bsd : Cannot find Successor to  node '4.4alpha 1000'
4.4alpha : Cannot find Successor to  node '4.3reno 1000'
4.3reno : Cannot find Successor to  node '4.3tahoe 1000'
4.3bsd : Cannot find Successor to  node '4.2bsd 1000'
4.1cbsd : Cannot find Successor to  node '4.1bbsd 1000'
4.1bbsd : Cannot find Successor to  node '4.1absd 1000'
4.1absd : Cannot find Successor to  node '4.1bsd 1000'
4.1bsd : Cannot find Successor to  node '4bsd 1000'
4bsd : Cannot find Successor to  node '3bsd 1000'
2.11pl400 : Cannot find Successor to  node '2.11pl335 1000'
2.11pl335 : Cannot find Successor to  node '2.11pl300 1000'
2.11pl300 : Cannot find Successor to  node '2.11pl200 1000'
2.11pl200 : Cannot find Successor to  node '2.11pl100 1000'
2.11pl100 : Cannot find Successor to  node '2.11bsd 1000'
2.11bsd : Cannot find Successor to  node '2.10.1bsd 1000'
2.10.1bsd : Cannot find Successor to  node '2.10bsd 1000'
2.10bsd : Cannot find Successor to  node '2.9seismo 1000'
2.9seismo : Cannot find Successor to  node '2.9.1bsd 1000'
2.9.1bsd : Cannot find Successor to  node '2.9bsd 1000'
2.9bsd : Cannot find Successor to  node '2.8.2bsd 1000'
2.8.2bsd : Cannot find Successor to  node '2.8.1bsd 1000'
2.8.1bsd : Cannot find Successor to  node '2.8bsd 1000'
2.8bsd : Cannot find Successor to  node '2.79bsd 1000'
2.79bsd : Cannot find Successor to  node '2bsd 1000'
2bsd : Cannot find Successor to  node '1bsd 1000'
Segmentation fault (core dumped)

On Sat, Sep 02, 2000 at 09:05:04PM +0100, Hans B Pufal wrote:
> 
> Kurt Raschke wrote:
> > 
> > The C parser in CVS fails to compile:
> 
> This problem is fixed - it was a currupted upload.
> 
> 
> >  [kurt@linux new]$ make html
> >  cc -o html html.c
> 
> This one you need to link with parser so cc should read
> 
>    cc -o html html.c parser.c
> 
> 
> New files available as <ftp://aconit.org/pub/files.tgz>
> I downloaded the file, expanded it and built and tested the sources on
> my Mandrake 70 system, all seemed OK.
> 
> Regards
> 
>   -- Hans B Pufal
> _______________________________________________
> Comp-hist-devel mailing list
> Com...@li...  
> http://lists.sourceforge.net/mailman/listinfo/comp-hist-devel