On 2013-05-19 20:07, Sampsa Laine wrote:
On 19 May 2013, at 20:03, Cory Smelosky <b4 at gewt.net> wrote:
On Sun, 19 May 2013, Sampsa Laine wrote:
On 19 May 2013, at 19:58, Cory Smelosky <b4 at gewt.net> wrote:
#6 is a provlem I've noticed with INFO.TXT. There's no order.
When me and Steve Davidson originally thought of adding parseable info to INFO.TXT we had the idea that the file itself would be free-form text with a machine parseable block at the end, with delimiters.
If you look at http://rhesus.sampsa.com/cgi-bin/hecnetinfo/hecnetinfo.com?q=chimpy you'll see what I mean, there's a clearly defined block of machine readable CSV at the end.
How many people followed that though?
No idea - I don't think anyone ever wrote a parser.
But here's a brief outline of how I think this should work:
1. Someone (=me) defines the CSV format formally in a document
2. This document is passed around and corrected until majority is happy with it
3. Someone (=brian) writes a parser
4. People nominate boxes from where their INFO.TXTs should be pulled (one can cover a whole area or even more)
5. This is integrated into the DB using the parser from 3 periodically.
My biggest issues already mentioned earlier are no nearer a solution here, so I'm not sure I really see any wins for my pet project in doing this.
I have an issue about data content consistency. OS, machine and location information can vary so wildly it is pretty much useless in a distributed solution as suggested here, except for people to try and ready and skim through for fun. It will not even be easy for humans to search through to find something specific. And locations are totally wild.
Also, this do in no way ensure that data is valid or up to date. In fact, as things stands now, it has less odds of getting it right than my stupid solution of just entering the data myself, as people in general do report when they add a new machine to HECnet, if they want anyone else to know about the nodename. Collecting extra information at that stage is not a big problem.
This also do not ensure that data gets updated when people move, but moving don't happen frequently, and also even having any data in there is voluntary to start with, so I guess it's as good as I can expect it to get.
Basically, what you are advocating is the already existing solution of the INFO.TXT files, which I already have stated that I personally don't feel fits my needs. I don't mind trying to update my own INFO.TXT file whenever, but I'm sure the format is wrong, and I definitely do not put all machines in there (and I don't think I've seen many others doing either), and I definitely do not remember to update that information.
But, like I said a number of times now, it's just that I went off on a tangent on a pet project of mine, and asked people to volunteer information for it. I'm trying to make it useful, but mostly just for my own amusement to see what I can accomplish. (Hey, give me a chance to do something under RSX, and I will...)
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
On 2013-05-19 18:47, Ian McLaughlin wrote:
On 2013-05-19, at 9:34 AM, Johnny Billquist <bqt at softjar.se> wrote:
I honestly don't know what I think on that subject. Or, actually, I do. I think it would be even better to just have key-value pairs. Why overcomplicate things?
Any unknown key is just ignored. We could expand with new keys without having the code synced. And then the values can hold any character except newline.
You mean just like a Windows .ini file? (ducks)
I have no clue about windows .ini files...
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
On 2013-05-19 18:45, Robert Jarratt wrote:
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-
hecnet at Update.UU.SE] On Behalf Of Johnny Billquist
Sent: 19 May 2013 17:34
To: hecnet at Update.UU.SE
Cc: Brian Hechinger
Subject: Re: [HECnet] CSV Proposal
On 2013-05-19 18:14, Brian Hechinger wrote:
On Sun, May 19, 2013 at 05:02:18PM +0100, Robert Jarratt wrote:
Well, if the separator is | then it isn't a CSV file :-)
While I do understand the origins of the term CSV, the C really doesn
stand for character. Tabs are used quite commonly as well as commas.
Any character is valid, so long as it's accepted by all consumers of
said file.
The C standing for comma is antiquated and outdated and should be
changed. In my not so humble opinion, anyway. :)
He says, to a crowd of people running antiquated and outdated software and
hardware... :-D
Anyway, while I think I agree that technically, C stands for comma, I also
think
| is a better separator in this case.
Feel free to call it anything. The acronym for the format is less
important. We
could call it BSV then.
I didn't want to start a big debate about this, it was just a little joke. I
would be more than happy to use the pipe symbol as the separator.
Didn't think you intended to either. I just could not resist carrying it on as a joke a little further. :-)
I have no issue with this except that allowing the columns to appear
in any order, while nice and flexible, makes it harder to write the
software. It does not seem worth the effort to have that flexibility
given the low enthusiasm for writing this software, so a
simplification would be to fix the column order.
It really isn't that hard to write. I've implemented such a thing in
many languages (including very stupid ones) and it is *always* worth the
effort.
It wouldn't be a big effort for me on the platforms I write for today. It
would be harder for me on platforms I programmed a long time ago (or even
never in the case of RSX) and never having programmed for Datatrieve, but
that is precisely why I would like to do it, although I am not at all sure
about the RSX hurdle.
RSX is easy. I wouldn't care about doing it in assembler. Either C or BASIC would be my choice in this case. RSX is no special deal in this case, except for the possible memory constraints.
Is there a language on VAX that would make it easier to port it to RSX? Or
can Datatrieve be accessed over DECnet so the scraper code runs on VAX and
populates Datatrieve on RSX?
Yes, to all of the questions above. :-)
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
On 05/19/2013 06:15 PM, Brian Schenkenberger, VAXman- wrote:
It may be related to distrust of the Suits at Big Companies.
In this case, size doesn't matter. Suits are never to be trusted!
100% with you on that. I still wince every time I sit down.
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
On Sun, 19 May 2013, Brian Schenkenberger, VAXman- wrote:
"Cory Smelosky" <b4 at gewt.net> writes:
It may be related to distrust of the Suits at Big Companies.
In this case, size doesn't matter. Suits are never to be trusted!
True!
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG
Well I speak to machines with the voice of humanity.
--
Cory Smelosky
http://gewt.net/ Personal stuff
http://gimme-sympathy.org Experiments
On Sun, 19 May 2013, Brian Schenkenberger, VAXman- wrote:
Dave McGuire <mcguire at neurotica.com> writes:
On 05/19/2013 08:51 PM, h vlems wrote:
When HP pulls the plug on the hobbyist scheme, or VMS, I hope you will be
able to help us out!
Have there been any indications of that happening?
Like I just said, the negativity in this space never ceases to amaze me.
It may be related to distrust of the Suits at Big Companies.
Besides, PAK generators have been floating around since the dawn of time.
You don't even need that. The LMF is surprisingly simple to circumvent. I
was able to disable it within about 5 mins. of first booting VMS V5.0 here.
That's amusing.
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG
Well I speak to machines with the voice of humanity.
--
Cory Smelosky
http://gewt.net/ Personal stuff
http://gimme-sympathy.org Experiments
Dave McGuire <mcguire at neurotica.com> writes:
On 05/19/2013 08:51 PM, h vlems wrote:
When HP pulls the plug on the hobbyist scheme, or VMS, I hope you will be
able to help us out!
Have there been any indications of that happening?
Like I just said, the negativity in this space never ceases to amaze me.
Besides, PAK generators have been floating around since the dawn of time.
You don't even need that. The LMF is surprisingly simple to circumvent. I
was able to disable it within about 5 mins. of first booting VMS V5.0 here.
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG
Well I speak to machines with the voice of humanity.
On Sun, 19 May 2013, Dave McGuire wrote:
On 05/19/2013 04:41 PM, Brian Schenkenberger, VAXman- wrote:
Despite your the disdain for LMF, there are plenty of good reason to run
the newest(er) release(s). And, even with the LMF, it is easy to circum-
vent it. ;)
Agreed, and agreed!
It's easy to circumvent on Tru64 and Ultrix, too. ;)
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
--
Cory Smelosky
http://gewt.net/ Personal stuff
http://gimme-sympathy.org Experiments
On 05/19/2013 08:51 PM, h vlems wrote:
When HP pulls the plug on the hobbyist scheme, or VMS, I hope you will be
able to help us out!
Have there been any indications of that happening?
Besides, PAK generators have been floating around since the dawn of time.
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
On 05/19/2013 04:41 PM, Brian Schenkenberger, VAXman- wrote:
Despite your the disdain for LMF, there are plenty of good reason to run
the newest(er) release(s). And, even with the LMF, it is easy to circum-
vent it. ;)
Agreed, and agreed!
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
