Official YURT Design Thread (Development Discussion ONLY)

X-browser means cross-browser. The first step would be to make the html validator like you. Most of those errors aren't too bad - just put quotes around color names and URLs inside tags and most of them go away. Not having a doctype leads to undefined behavior a lot of the time (especially with NS). Add one and I think a lot of problems will go away.

The behavior OSUguy shows in his screenshot is precisely what you've written the HTML for. Here's the code from the beginning of that table:
Code:
<h1>List of Machines Reporting Protein 771</h1>

	<table>
	<tbody><tr align="center" bgcolor="#f5f5dc">
		<td></td></tr>
		<tr><td></td></tr>
		<tr><td></td></tr>
		<tr><td></td></tr>
		<tr><td></td></tr>

		<tr><td></td></tr>
		<tr><td></td></tr>
		<tr><td></td></tr>
		<tr><td></td></tr>
		<tr><td colspan="3"><b>Frames</b></td>
		<td colspan="3"><b>Work Units</b></td>
	</tr>
So there's a row with a background color, and one cell in it, and then a bunch of rows with no special attributes, then a row with "frames" and "work units" in cells. IE is doing the Wrong Thing.

Edit: the easy solution is to replace all those blank rows with a <td colspan="9"/>.

 
unhappy_mage said:
Here's the code from the beginning of that table:
That's curious; what you're showing doesn't match what I see when I look at the page doing a view source, and doesn't match what the ASP source code has.

I can't guess where you got all those extra tags from; whole rows? What would cause that? Is there some translation layer that I'm not taking into account? Here's what I saw:

Code:
<H1>List of Machines Reporting Protein <%=strProteinID%></H1>

	<TABLE>
	<TR align=center bgcolor=#f5f5dc>
		<TD></TR>
		<TD></TR>
		<TD></TR>
		<TD></TR>
		<TD></TR>
		<TD></TR>
		<TD></TR>
		<TD></TR>
		<TD></TR>
		<TD COLSPAN=3><B>Frames</B></TD>
		<TD COLSPAN=3><B>Work Units</B></TD>
	</TR>

That is, I simply had a </TR> closing tag when I meant a </TD> closing tag. (And it's fixed, now; let me know if it ain't working.)

unhappy_mage said:
IE is doing the Wrong Thing.
What's the correct behaviour given <TD></TR>, and the resulting unbalanced cells and rows?

unhappy_mage said:
Edit: the easy solution is to replace all those blank rows with a <td colspan="9"/>.
That renders differently; it puts a big single block over the first nine columns, instead of individual blocks over each column.


unhappy_mage said:
The first step would be to make the html validator like you.
I'll do that when I get the content together and the pages actually working; unless things are actually broken (like in this example), it's hard for me to see why that would be a first step. I'd end up revalidating every single time I make a change , and changes are fast and furious as I'm adding content and getting reports working.
 
it's working for me in Netscape 7.2 as of now...


edit---- hehe, thanks for the title change Atmo/p[H]/DR! definately more explanitory than "I need some help"


Keep on Folding!! For the [H]orde!!

 
mikeblas said:
That's curious; what you're showing doesn't match what I see when I look at the page doing a view source, and doesn't match what the ASP source code has.[/code]
Yes, I was using Firefox's View Selection Source feature; it shows what Firefox has interpreted your HTML as rather than what it literally is. It helps when you're trying to figure out why something is broken, but not in this instance ;)
mikeblas said:
What's the correct behaviour given <TD></TR>, and the resulting unbalanced cells and rows?
Do the Wrong Thing - break, and complain to the user - this is XML, people! But people don't want to see complaints on their Geocities website, they want results, so it's been left up to the browser writers to parse the HTML laxly (huh, that's really a word...). And of course they have different ideas about how to do that.
mikeblas said:
That renders differently; it puts a big single block over the first nine columns, instead of individual blocks over each column.
I wasn't comparing/contrasting with IE when I wrote that. It accomplishes the basic purpose, though - push the headings over the correct set of columns.
mikeblas said:
I'll do that when I get the content together and the pages actually working; unless things are actually broken (like in this example), it's hard for me to see why that would be a first step. I'd end up revalidating every single time I make a change , and changes are fast and furious as I'm adding content and getting reports working.
True, but you wouldn't have gotten this bug if you'd been validating ;)

 
unhappy_mage said:
Do the Wrong Thing - break, and complain to the user - this is XML, people! But people don't want to see complaints on their Geocities website, they want results, so it's been left up to the browser writers to parse the HTML laxly (huh, that's really a word...). And of course they have different ideas about how to do that.
Sure. So is that really "The Wrong Thing"? Maybe for some folks who develop web pages or web apps, but certainly not for the vast majority of browser users.

unhappy_mage said:
True, but you wouldn't have gotten this bug if you'd been validating ;)
Probably not; I wouldn't have been able to get as much code done, and wouldn't have yet coded the page. Heh, heh!

I took a quick pass through, and fixed many of the complains the validator has, though none of the appear to be of any consequence. I still don't know how to pick a DOCTYPE, and I'm leaving the things I think CSS will fix for later, when I implement some style sheets.
 
mikeblas said:
Sure. So is that really "The Wrong Thing"?
For the user, sure. What if, for every page that was incorrectly coded, the browser didn't display anything, but just generated a big red ERROR page? There would be a lot of unhappy users quickly. Sure, it would be nice if all the HTML out there was done correctly, but nobody would want the contract to rewrite all the broken stuff out there. And what about dynamic pages? The validator only works on a single instance of a page, so you'd have to test all the possibilities.
mikeblas said:
I took a quick pass through, and fixed many of the complains the validator has. I still don't know how to pick a DOCTYPE, and I'm leaving the things I think CSS will fix for later, when I implement some style sheets.
A List Apart did an article on DOCTYPEs. The one you're probably best off using is HTML 4.01 Strict:
Code:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
Don't use an XHTML doctype; you have written a good bit of code that makes mostly-complaint html4, and there's no advantage to using XHTML in this case (at the very least).

 
unhappy_mage said:
The one you're probably best off using is HTML 4.01 Strict:
Code:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
Don't use an XHTML doctype; you have written a good bit of code that makes mostly-complaint html4, and there's no advantage to using XHTML in this case (at the very least).
Thanks. And that'll work when I start adding CSS?
 
Yes. The HTML spec is pretty flexible that way.

I may have read your statement about browsers breaking incorrectly; in any case, let me expound a bit. One should write HTML strictly, but parse it laxly - as long as you handle "absolutely correctly written html" right.

 
unhappy_mage said:
Yes. The HTML spec is pretty flexible that way.
Great, thanks again.

unhappy_mage said:
I may have read your statement about browsers breaking incorrectly; in any case, let me expound a bit. One should write HTML strictly, but parse it laxly - as long as you handle "absolutely correctly written html" right.
Sure, and I agree with that. So why do you think IE was doing The Wrong Thing with the busted structure I had on that page? It was just parsing laxly. It got through it and ended up with something quite reasonable.
 
I like the smaller text on the All machines page.... But, I looked in the "Last updated column to see when my PCs last gave you info, and it's more than 24 hours ago for all 3....

I guess that raises another question, which timezone is that? GMT? PST? EST?

I have YURT running on 3 of my 4 PCs at home and I thought it was happily returning results.... from
here it looks like it's updating as some of the proteins have today's date.... maybe it's just not updating on the "all machines" page?


Keep on Folding!! For the [H]orde!!

 
so where do we click to install this bugger? Or is it ready for others to put it on their machines yet?
 
Still in Beta right now....... so far though, it looks as only me, sobe and mikeblas the ones testing it..... on the next version of the beta, I can add you to the beta list if you like?


Keep on Folding!! For the [H]orde!!

 
Sounds good. I can't install it on the p4's

But i have an xp2600, x2 3800, and 3x 1ghz p3's
 
sounds good....... why not on the P4s?


Keep on Folding!! For the [H]orde!!

 
OSUguy98 said:
I like the smaller text on the All machines page.... But, I looked in the "Last updated column to see when my PCs last gave you info, and it's more than 24 hours ago for all 3....

I guess that raises another question, which timezone is that? GMT? PST? EST?
It's UTC, just like the timestamps in the FAHLog.TXT.

The machines page shows the time the machine was registered in that last updated column. If you want to see the last time work was recieved, it's on the machine details page where all the machine's work is talled.

OSUguy98 said:
I have YURT running on 3 of my 4 PCs at home and I thought it was happily returning results.... from
here it looks like it's updating as some of the proteins have today's date.... maybe it's just not updating on the "all machines" page?
I can't tell you if something is wrong or not. You'll have to look at your own FAHLog.TXT file, the YURTMonitor.TXT log (because there might be many items queued to be sent), and figure it out.

Also, remember that the trick I'm using to monitor the FAH directory for changes is rather flakey. There's really nothing I can do about it, but I'm not notified until the data actually hits the disk. Since the folding at home program may or may not flush data when it writes it to the drive, it may or may not trigger the monitor immediately when the lines are added to the file.

Your data gets through eventually, and we try hard not to send it twice. But between the queue, the output buffer, and the notification, it may not be sent immediately.
 
Here is an updated TODO list.

  • Bugs
    • DONE: Can't register a machine that has no processor string. A Pentium III showed me this problem and equal and older machines are going to have the same issue. It's a matter of fixing a script to let the registration happen, then coming up with some way to name and identify such old processors. It's juts not easy, since you have to do a big lookup against at on of data and there's exceptions all over the place because none of the vendors standardized on anything.
    • DONE: Shouldn't be able to run more than one copy of the monitor at a time.
    • DONE: Sometimes, the username has trailing whitespace during registration.
    • The queue fills up every twenty. It would be neat to let the update code freeze the updates, add everything it wants, then unfreeze so all the updates could be sent together. We might send more than 20 items, but we won't send 20 multple times when more is on the way anyhow.
  • DONE: YURTInstaller gets an options dialog box.
    • Offer option in YurtInstaller to pick up previous log file. Just once.
    • DONE: Offer option in YurtInstaller to register without showing full domain name: "burner" instead of "burner.prozac.corp"
    • DONE: Offer option in YurtInstaller to set logging level: thin, thick, debugging.
  • Report changes
    • DONE: Add PPD to protein report.
    • Add sorting to show list of machines.

  • DONE: Stylesheet could use ""<td style="white-space: nowrap;">" to avoid breaking columns up.
  • DONE: Various clarity/prettyness fixes to logging.
  • DONE: Rotate the monitor program log file so it doesn't get big. One day is 800K, at the moment.
  • Add searching by common name, like "Pentium 4". This will help with the older processors.
  • Add searching by family/model/revision.
  • Fix the search page do use client-side script so that searching by common name is exclusive to searching by family/model/revision.
  • DONE: Can't have the monitor log to the same directory it's watching. I can document this for the first beta, but it would be best to make the monitor notice it and quit. It would cause a hang: the monitor would write to the log, the change event would fire, and so the monitor would write to the log, causing the change event to fire, ...
  • Convert the monitor to a service. This is another thing that would make debugging more difficult, so I'm putting it off for the first betas.

Here's things for the group:

  • Moar queries.
  • Artwork for hte website?
 
Is there a max amount of directories that can be monitored. For instance is my xeon system ok. Has 4 directories?

Edit: How does it handle if someone is running 2 directories on a single CPU that has no hyperthreading etc.

This bring me to the question what about if the user sets that they only want F@H to run at 90% in the advanced setup. For instance some of the member on this forum if they have a hyperthreaded machine run 1 instance at 100% and another at 15% with no advmethods and set to timeless. Running at 15% takes advantage of the fact that there is about a 15% boost in speed with running HT and it wont slow down the main work unit. Does YURT look at what percentage they have it set at?
 
MN Scout said:
Is there a max amount of directories that can be monitored. For instance is my xeon system ok. Has 4 directories?
It is sixteen.
 
MN Scout said:
Edit: How does it handle if someone is running 2 directories on a single CPU that has no hyperthreading etc.
It depends. If you set it up to monitor both directories, it will send results from the two directories as they're received.

MN Scout said:
Does YURT look at what percentage they have it set at?
Nope, it doesn't; you're the first to suggest it. I guess I can see why you'd want it to look, but that number is just a suggestion. We have no idea if it's running more or less CPU time than the suggestion.
 
I don't know if this is a bug in the parsing or the displaying, but when I ran the installer from v005, in the "send" report it showed a box after "OwnerName=unhappy_mage". The client.cfg file (that is what you're parsing, right? or is it a registry value?) is in Unix format, with "\n" as line seperator rather than "\r\n"; could that be causing this?

Also, when I ran the monitor, it reported (on the screen, anyways) that frame 0 had taken some number of seconds:
Code:
[2006-03-28 16:22:20.678]    FAHlog.txt was added
[2006-03-28 16:22:20.756] Found protein 2097 on line 199
[2006-03-28 16:22:20.756] Frame 0 took 76732 seconds
[2006-03-28 16:22:20.756] Queued: protein 2097 for time 76732
[2006-03-28 16:22:20.756] Queue has 1 items
[2006-03-28 16:22:20.756]    Skipped 0 lines, read 205 lines in 0.07468 seconds
on a brand new install of FAH. What part of the log would help you figure out why it did this? I assume this is a bug - frame 0 shouldn't get assigned a time until frame 1 finishes. And the difference between the earliest and latest times in the log is only 79 seconds if I'm doing my math right (17:32 until 18:51) so I don't know where 76732 came from.

FAH won't run at more than the percentage you set it to, over periods of more than a second or so (at least that I've noticed ;)) - so it's an upper bound on how much CPU will be used. It'd be a good thing to monitor, at least in theory.

 
unhappy_mage said:
I don't know if this is a bug in the parsing or the displaying, but when I ran the installer from v005, in the "send" report it showed a box after "OwnerName=unhappy_mage". The client.cfg file (that is what you're parsing, right? or is it a registry value?) is in Unix format, with "\n" as line seperator rather than "\r\n"; could that be causing this?
This is a known issue; see the bugs list in the TODO list I posted earlier today. It's already fixed, though I haven't dropped the bits with the fix yet.

unhappy_mage said:
Also, when I ran the monitor, it reported (on the screen, anyways) that frame 0 had taken some number of seconds:
Just send your whole FAHLog.TXT file; I think I know what the problem is, though.

unhappy_mage said:
FAH won't run at more than the percentage you set it to, over periods of more than a second or so (at least that I've noticed ;)) - so it's an upper bound on how much CPU will be used. It'd be a good thing to monitor, at least in theory.
But it might run at less, and is extremely likely to do so.
 
mikeblas said:
This is a known issue; see the bugs list in the TODO list I posted earlier today. It's already fixed, though I haven't dropped the bits with the fix yet.

Just send your whole FAHLog.TXT file; I think I know what the problem is, though.
Okay. I thought it might be a different issue, as I've got one of those boxes Windows makes when it doesn't recognize a character instead of a space. YGEM.

 
This wasn't acknowledged:

"This bring me to the question what about if the user sets that they only want F@H to run at 90% in the advanced setup. For instance some of the member on this forum if they have a hyperthreaded machine run 1 instance at 100% and another at 15% with no advmethods and set to timeless. Running at 15% takes advantage of the fact that there is about a 15% boost in speed with running HT and it wont slow down the main work unit. Does YURT look at what percentage they have it set at?"

This is important because a lot of data could get in that if the percentage wasn't recorded could look really weird.

This could make a neat query: A P4 3.0ghz HT machine running 2 instance of folding at 100% each is compared to the total output of another P4 3.0ghz running 1 instance at 100% and another at 15%. So you'd look at the combined average point per day for the two configurations. Answers the question which is better 1 instance, 2 instance at 100% each, or 1 instance at 100% and another at 15%. This is sort of important if QMDs comeback since there was some talk that ppd could be less if 2QMDs run at the same time, compared to if had 1QMD and 1 other wu.

Would tracking what flags they have setup be good also. Say if they have the advmethods or the no bigwu, timeless? Anyway to get this imformation and include it with the computer information being sent in. Could be fun to look at a comparison of the average ppd of similar speed processors with the advmethods flag on and off, and similarily with the bigWu flag on or off.

I know these questions might be to much too late, but maybe they give you ideas Mike on queries etc.
 
Woohoo! Installed and running. I didn't see any problems with monitoring two directorys for a HT processor running two instances. Is that going to be an issue? I kinda briefed through the manual. This project is coming together well!
 
MN Scout said:
This wasn't acknowledged:
Actually, it was; I responded in post #222.

MN Scout said:
This is important because a lot of data could get in that if the percentage wasn't recorded could look really weird.
Like I said, I understand why you want to have a look at this parameter, but there's far bigger threads to data integrity because there's zero authentication over the data that's accepted.

MN Scout said:
This could make a neat query: A P4 3.0ghz HT machine running 2 instance of folding at 100% each is compared to the total output of another P4 3.0ghz running 1 instance at 100% and another at 15%.

Considering this issue in isolation, we don't know anything about the percentages even if we do read them from the file. The actual time the process sees and uses is only bounded by that value. The user can stop it, start it, pause it, or run other applications.

If we read 100% from the config file, and it turns out the user is playing games all day, causing the process to only get 30% CPU, should we still bin the input with other 100% reports?

MN Scout said:
I know these questions might be to much too late, but maybe they give you ideas Mike on queries etc.
Unfortunately, I can't write queries against data that I don't have. At this instant, we're not even tracking how many clients each machine is running.

If there's a strong case for collecting this and using it, I can write the code to do so, but it'll delay our release further. (Or, be saved for a subsequent release.)

I'd also appreciate a spec of what's to be collected and how it's used in the queries -- I'm a little weary of guessing at what ya'll want, if that's not already apparent.

And how it is collected: what if the user changes the config options? Do we rescan and resubmit? Invalidate that machine? That's not accounted for in the current data model, and I'm not sure we have the server bandwidth to summarize it over historized data even if it was in the model.

That is, say you run at 100% and submit 100 work units. Then, you knock your machine down to 15%. How do we remember that the 100 work units were at 100% and not 15%? We have to add the percentage (which again, is inaccurate anyway) to all the data you've submitted and factor it in to all the reporting we do so that we know your machine has submitted different workrates.

That doesn't fit well with the motnitor, which might be shut down when rate changes. You run 100%, you stop YURTMonitor. You run 10 more WU's at 100%. Then, you throttle down to 15% and do 2 WUs. You start YURTMonitor, when it then notices that you've gone to 15%. Does it have 12 units at 15%? Can it figure out that there were 10 at 100% and 2 at 15%?

For my vote, I'd rather deliver on what we've got right now and see how it goes. That'll teach us what's happening, and give us insight into implementing more bells and whistles in the next version.
 
I see where you are coming from. Thanks for the explanation.

I think the best way is to rely on the averages, and if you ever want to display graphs you could include a shaded region for the standard deviation. I think that we want to hope that a bunch of people can get running this and we'll get a nice base of information to work further from and analyze. We don't want to make things overly complicated and restrictive in deciding what information gets sent in. I think far far more correct results will get sent in then bad results. Most people set up folding and foget it. Not really anything past the first wu or two that someone does would get messed with.

I'll try and think through some queries tomorrow morning and map out, the variables working with what you are collecting now on your website.

Right now you are collecting:
CPU speed, can we get this even on the older processors that you can't get the cpu string?
model
stepping
...pending we can get old machines information somehow, or ever, I guess we need to way this decision.

frame time
protein name
user name
team
computer name

Anything wrong with that list?
 
Do you have the capabilities to do graphs, or are we going to try to stay with table information? It's just a hypothetical question. I don't want to spend time drawing out graph samples if I could be spending my time, figuring out how to represent it with tables in a good way.
 
MN Scout said:
I think far far more correct results will get sent in then bad results.
Yep. But I'd say that you only need one bad apple to ruin it; and that bad apple only has to submit a few dozen datapoints, even.

Some BrandX !!!!!! can submit work time of zero (or one second) for a particular protein, over and over. And it's all like Bladdow!, your average is all wrong.

MN Scout said:
I see where you are coming from. Thanks for the explanation.
Thanks for understanding. I don't want to be working on this forever and ever, though I'm not opposed to working on it now and again as time goes on. That's another reason why I'm behind the idea of getting something out, collecting ideas, and taking another big run at a revision.

MN Scout said:
I'll try and think through some queries tomorrow morning and map out, the variables working with what you are collecting now on your website.

Right now you are collecting:
CPU speed, can we get this even on the older processors that you can't get the cpu

The stock CPU speed isn't availalable. We get the CPU speed from the registry, and the CPU speed from a measurement taken while the user is running YURTInstaller. They're all the same so far, but they can be different for machines that vary their clock speed; while throttling for heat, because of Cool and Quiet, or because of power saving modes in laptops.

But we don't know the stock speed; maybe people are overclocking or underclocking.

We collect all the output of the CPUID instructions, even though it's not fully unpacked yet. Most notably, I don't unpack the cache sizes. And I've got a number of processors, but don't show physical and logical processors seperately. (I'm not positive I can show sockets and physical cores seperately, BTW. I guess I must be able to, but I haven't had the time to research it.)

Frame time and work unit time are, at this instant, sums. That is, we store "protein 35 took a total of 1234 seconds for 10 completions". If you say you complete it again in 15 seconds, we bump that to 1249 and 11. The idea was that we didn't have enough data storage for all the traffic; and that the queries to update the usms might be too expensive. I'm up for reevaluating this, and actually did extra work to leave it flexible in the data model.

Other'n that, I think your list is okay.
 
MN Scout said:
Do you have the capabilities to do graphs, or are we going to try to stay with table information? It's just a hypothetical question. I don't want to spend time drawing out graph samples if I could be spending my time, figuring out how to represent it with tables in a good way.
This question is answered earlier in the thread. The bottom line is that graphing objects are expensive and I can't install random objects on my shared hosting server.

I suppose it's possible that, for a fininte and small number of charts, I write a mechanism that, once a week or once a day:

1) Takes a backup of the online database
2) installs it locally at home
3) Runs the charts, making JPGs
4) updloads them back to the site to be published

but that's obviously a sizable amount of work.
 
MN Scout said:
Is there a max amount of directories that can be monitored. For instance is my xeon system ok. Has 4 directories?
Why not start putting the website to use? If you start here, can you find any Xeon machines with lots of processors? What reports would have made your question easier to answer? What if you suggest those reports to the person who's been asking for suggestions about reports?

Where I work, we call this "dogfooding".
 
Just checking in on the log files/sizes/etc....

right now:

P4 2.4C @ 3.0 is right around 1.75MB (two instances, little over 2 days monitoring)
dually 1700+ is around 1.5MB (two instances, little over 2 days monitoring)
Sempron 2200+ @ 1.67GHz is around 800KB (one instance, little over two days monitoring)

Is the beta a "record everything possible in the log" while future releases will have a peared down log file? or have you, or do you plan to, limit the size of YURTMonitorLog.txt (similar to F@H's 350k limit)?.....


Keep on Folding!!

 
OSUguy98 said:
Is the beta a "record everything possible in the log" while future releases will have a peared down log file? or have you, or do you plan to, limit the size of YURTMonitorLog.txt (similar to F@H's 350k limit)?.....
Please see the current to-do list (at post #217 in this thread) and the previous version, as well, for my notes on the subject. Let me know, after reading those posts, if you have any questions.

ICE_9 said:
I kinda briefed through the manual.
I'd appreciate it if you took the time to read it and offer your suggestions. If you're a beta tester, you've been trusted with testing, critiquing, and reviewing my work. People will rely on that documentation when using the programs, and I'm relying on the input of the testers to make sure it's usable.
 
mikeblas said:
I'd appreciate it if you took the time to read it and offer your suggestions. If you're a beta tester, you've been trusted with testing, critiquing, and reviewing my work. People will rely on that documentation when using the programs, and I'm relying on the input of the testers to make sure it's usable.

To help out with that, can the manual be changed to a Word document or something, until a final ready rev can be published into pdf? I can't cut and paste from it with the sugestions. It would save some time on typing it all back out for examples. If not, no big deal.
 
mikeblas said:
Why not start putting the website to use? If you start here, can you find any Xeon machines with lots of processors? What reports would have made your question easier to answer? What if you suggest those reports to the person who's been asking for suggestions about reports?

Where I work, we call this "dogfooding".

I'm getting you a list of querries and table that could be made out of your current info tomorrow. You'll have it by nightfall. I'm sorry that I'm a little late to the game, I was quite busy the last 2 weeks and this thread was very confusing to read through at the beginning and with my limited time I chose to spend it helping new users with their problems. Now that this project is up and going - very fast - and I have time, I'm going to contribute something. You asked for querries and I'm going to get you some.
 
ICE_9 said:
To help out with that, can the manual be changed to a Word document or something, until a final ready rev can be published into pdf? I can't cut and paste from it with the sugestions. It would save some time on typing it all back out for examples. If not, no big deal.
The PDF isn't protected. If you have Acrobat or Acrobat Pro, you can add comments and annotations directly to the file. If you have Acrobat Reader (whih you should; it's free, and its a very popular format) and Word, you can open the doc in Reader, select all the content, and paste it into Word. The only thing that won't copy is the screenshots. Or, you can select and highlight individual passages. It's 2006; there's really little reason to rekey anything.

I'll loook forward to your input.
 
MN Scout said:
I'm getting you a list of querries and table that could be made out of your current info tomorrow.
Thanks. Of course, I hope it goes without saying that we're looking for interesting queries, not just all the queries that could be made. I don't think anyone wants to correlate PPD to number of letters in usernames, for example.
 
mikeblas said:
I don't think anyone wants to correlate PPD to number of letters in usernames, for example.

awe come on.... that's be interesting!! :D


Keep on Folding!! For the [H]orde!!

 
Back
Top