SDK Documentation #15
Comments
|
The plan is to add a living documentation in markdown probably bootstraped by transforming the old existing plain text docs. Any help is very welcome in this regard. |
|
Well, assuming you have the rights to redistribute them, would there be any objection to checking in the existing docs, until such time as the MD based docs are created? I could do so, having downloaded the mentioned docs which breadbox published, but without the rights to redistribute, I am loath to do so. Presumably you already have said docs, and could immediately check in the text based versions? |
|
I have a copy of the 1994 GEOS 2.0 SDK, and am quite happy to send you a pull request with all the documentation in it, if you want... |
|
I'm not sure if the rights on Geos include the SDK documentation. I think only Falk can answer that. |
|
Ah, that's a plausible explanation why it hasn't already been checked in. It'd be good to know for sure, though: the docs are good, and the GEOS learning curve so steep they're also kinda mandatory... |
|
Hey, I'm sorry this took me so long! I double checked the written agreements and all documentations of PC/GEOS are covered. I assume this was not part of the Breadbox source code branch because there was no plan to produce an SDK out of this that time. So please, yes, you are very welcome to add those and send a pull request so we can add them to the repo. As said above I would like to see to transform this to a living documentation in the repo using markdown or similar one day. Thank you for supporting PC/GEOS! |
|
Here you go! #48 Crawling the net I also found this: https://lahosken.san-francisco.ca.us/manual/geos/index.htm It's an HTML-ified version of a subset the docs, which is pretty nice. It references some books the old 2.0 SDK didn't have (like Kernel), but doesn't have them. Any ideas where these came from? They reference the Nokia 9000. If they're official (generated from the Adobe Framemaker source), then it's probably possible to track a full copy down from somewhere. |
|
I'd suggest splitting this in to two PRs, one for the text files, one for the binary (postscript and pdf). That way the binaries can eventually be pruned from the repo. As to contents, I have something slightly different, including HTML docs, plain text, and PDFs, but no postscript files. That comes from this zip file: With the following contents for docs: So do any of those warrant a distinct PR? |
|
Maybe rather than merging the PDFs in to the source repro, they could be added as additional binary files to a tagged release - which github allows for. |
|
That definitely looks like a more recent release. It'd be interesting to know what's changed --- merge my ASCII and then your ASCII so we can look at the diffs? We have different filenames, though (mine are all lower case). Let me know what you want to do. I've found a version number in the Concepts book. My Postscript and ASCII says Version Beta 1.10 GEOS SDK 0.9, my PDF says Version 2.0 GEOS SDK 2.0, so I reckon someone messed up there... I was hoping to find a generation timestamp in the Postscript, but there's nothing; the PDFs claim to have been generated on 1 January 1970, which may not be accurate. I reckon that your HTML is way more useful than my Postscript/PDF in real life, and I'm quite happy with sidelining them --- but I do think they should be archived somewhere for posterity. |
|
I've pushed the commit to the sdk-docs branch on my repo, and created a PR (#49); but it probably not worth merging it yet. I've grabbed a copy of your commit locally, and will have a look later. We should see if we can do some sensible renaming; as I mention in my commit the html tree will need renaming for use on a case sensitive file system. I'll probably not have time to look at this until the weekend. |
|
My ascii concepts (Documentation/ascii/Concepts/confront.txt) says Version Beta 2.0. |
|
Just checked, the PDF files are the same, except that you have one additional file (zoomer.pdf), and the text file giving an overview. |
|
I did some more checking, my text stuff simply seems to be additions: So I'll combine the two commits in to a series, starting with your commit, but with the directory names from mine. So expect my PR to be revised by the end of Sunday, probably with three commits:
I'll see if I can also generate a tagged release against my sdk-docs branch, such that I can attach the PDF files as an additional ZIP file, extracted from the PDFs in your commit. |
|
Hi, so is there any plan how to proceed here with further consolidation? |
|
Just me running short of spare time. Hopefully I can find the time to do it this weekend. |
|
Status update. I've got the two stacked commits I proposed. I'm just amending the second one so as to correct the path names in the HTML. The ZIP file was created with all uppercase names, the HTML extracts to have internal references in studdyCaps style of mixed case. When viewed on a case sensitive filesystem, this results in in broken links. So I'm correcting those by renaming the files to the expected format. This is somewhat automated, but with a lot of manual checks and manual name picking. |
|
My PR has now been updated. It has the two commits as I outlines. |
|
Oh - and it turns out that what I thought were added ASCII files, were simply renamed versions of the files in Dave's import; changing fileX-Y to fileX_Y, so I dropped them from my PR. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Since this is effectively the source for the system, and its SDK what about the SDK documentation which used to be available? I note that it was available in PDF files, HTML files, and plain text.
Will these be added to the repo (possibly only on a side branch)? I note that it is possible to find old versions of the SDK which were published to all and sundry, so one could locally extract those documents, however it would seem more sensible to publish them as part of the source code.
The text was updated successfully, but these errors were encountered: