* frysk.proc.{ptrace,corefile} -> frysk.proc.{live,dead} @ 2007-06-13 13:17 Andrew Cagney 2007-06-14 10:11 ` Mark Wielaard 0 siblings, 1 reply; 13+ messages in thread From: Andrew Cagney @ 2007-06-13 13:17 UTC (permalink / raw) To: frysk This picks up an earlier refactoring, where the specific instances of a Host et.al. were moved to sub-packages. As I noted back then, the sub-package names, in hindsite, weren't the best choice - reflecting implementation (using ptrace) rather than properties (live or dead). The intent is to rename frysk.proc.{ptrace,corefile} -> frysk.proc.{live,dead} ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: frysk.proc.{ptrace,corefile} -> frysk.proc.{live,dead} 2007-06-13 13:17 frysk.proc.{ptrace,corefile} -> frysk.proc.{live,dead} Andrew Cagney @ 2007-06-14 10:11 ` Mark Wielaard 2007-06-14 14:08 ` Andrew Cagney 0 siblings, 1 reply; 13+ messages in thread From: Mark Wielaard @ 2007-06-14 10:11 UTC (permalink / raw) To: Andrew Cagney; +Cc: frysk [-- Attachment #1: Type: text/plain, Size: 1339 bytes --] On Wed, 2007-06-13 at 09:12 -0400, Andrew Cagney wrote: > This picks up an earlier refactoring, where the specific instances of a > Host et.al. were moved to sub-packages. As I noted back then, the > sub-package names, in hindsite, weren't the best choice - reflecting > implementation (using ptrace) rather than properties (live or dead). > > The intent is to rename frysk.proc.{ptrace,corefile} -> > frysk.proc.{live,dead} Could you explain a bit more what kind of public interface (differences) you see between these two packages? How would it compare with the public frysk.proc interface for Tasks? My feeling is that it isn't a good idea to just rename the implementation packages ptrace, corefile to these properties you find more appealing. You should layer the properties on top of the implementation techniques. There might be more implementations later like utrace and/or some userspace /proc implementation layered on top of utrace that Chris is working on. But we will still use ptrace for systems that don't support utrace (yet). And with some magic we can probably give the core file implementation some of the live properties by emulating memory, register access and instruction stepping. So multiple implementations might map to different instances of these properties. Cheers, Mark [-- Attachment #2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: frysk.proc.{ptrace,corefile} -> frysk.proc.{live,dead} 2007-06-14 10:11 ` Mark Wielaard @ 2007-06-14 14:08 ` Andrew Cagney 2007-06-15 9:05 ` Mark Wielaard 0 siblings, 1 reply; 13+ messages in thread From: Andrew Cagney @ 2007-06-14 14:08 UTC (permalink / raw) To: Mark Wielaard; +Cc: frysk Mark, Good questions. The key difference is that a dead system has no state (well, ok, only one) where as a live system is statefull and consequently, a dead system has no reason to implement or handle abstract methods such as sendrecContinue et.al where as a live system does. Over time we'll accumulate other "live" hosts - utrace, remote, and then when we've a problem, we'll with new information available, likely review how to better break down the "live" case. This further refinement, and introduction of frysk.proc.live.LiveTask lets us finish the refactoring task I started of separating out specific implementations of a Host (corefile, ptrace) from the abstract model. For instance, those state variables in frysk.proc.Task and corresponding methods can be localized to frysk.proc.live. Andrew Mark Wielaard wrote: > On Wed, 2007-06-13 at 09:12 -0400, Andrew Cagney wrote: > >> This picks up an earlier refactoring, where the specific instances of a >> Host et.al. were moved to sub-packages. As I noted back then, the >> sub-package names, in hindsite, weren't the best choice - reflecting >> implementation (using ptrace) rather than properties (live or dead). >> >> The intent is to rename frysk.proc.{ptrace,corefile} -> >> frysk.proc.{live,dead} >> > > Could you explain a bit more what kind of public interface (differences) > you see between these two packages? How would it compare with the public > frysk.proc interface for Tasks? > > My feeling is that it isn't a good idea to just rename the > implementation packages ptrace, corefile to these properties you find > more appealing. You should layer the properties on top of the > implementation techniques. > > There might be more implementations later like utrace and/or some > userspace /proc implementation layered on top of utrace that Chris is > working on. But we will still use ptrace for systems that don't support > utrace (yet). And with some magic we can probably give the core file > implementation some of the live properties by emulating memory, register > access and instruction stepping. So multiple implementations might map > to different instances of these properties. > > Cheers, > > Mark > ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: frysk.proc.{ptrace,corefile} -> frysk.proc.{live,dead} 2007-06-14 14:08 ` Andrew Cagney @ 2007-06-15 9:05 ` Mark Wielaard 2007-06-15 15:04 ` Andrew Cagney 0 siblings, 1 reply; 13+ messages in thread From: Mark Wielaard @ 2007-06-15 9:05 UTC (permalink / raw) To: Andrew Cagney; +Cc: frysk [-- Attachment #1: Type: text/plain, Size: 2163 bytes --] Hi Andrew, On Thu, 2007-06-14 at 09:59 -0400, Andrew Cagney wrote: > Good questions. The key difference is that a dead system has no state > (well, ok, only one) where as a live system is statefull and > consequently, a dead system has no reason to implement or handle > abstract methods such as sendrecContinue et.al where as a live system > does. Yes, but those are implementation details. Not differences in public interface are they? > Over time we'll accumulate other "live" hosts - utrace, remote, > and then when we've a problem, we'll with new information available, > likely review how to better break down the "live" case. Yes, but my point is more that pre-mature refactoring at this point seems not a good idea. We don't seem to have all the information yet. But maybe you do have a clear picture already. I am trying to get an idea what we would really gain from it at this point. Which api users do you have in mind and what are they doing now through frysk.proc (or directly through frysk.proc.ptrace and frsyk.proc.core) that would be better modeled through the proposed properties-based package abstractions? > This further refinement, and introduction of frysk.proc.live.LiveTask > lets us finish the refactoring task I started of separating out specific > implementations of a Host (corefile, ptrace) from the abstract model. > For instance, those state variables in frysk.proc.Task and corresponding > methods can be localized to frysk.proc.live. Are you sure they are "live"-properties and not just implementation details of the ptrace-implementation? Can you give a list of variables and methods you think aren't just ptrace implementation details, but are properties of a LiveTask? My main concern here is that we are abstracting cases for which there is just one implementation at this point (or rather, just renaming the specific implementations as if they are abstract properties) and that we are better of waiting till we actually have multiple implementations with shared properties to see how a properties based setup based on live or dead looks like. Cheers, Mark [-- Attachment #2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: frysk.proc.{ptrace,corefile} -> frysk.proc.{live,dead} 2007-06-15 9:05 ` Mark Wielaard @ 2007-06-15 15:04 ` Andrew Cagney 2007-06-15 19:44 ` Mark Wielaard 0 siblings, 1 reply; 13+ messages in thread From: Andrew Cagney @ 2007-06-15 15:04 UTC (permalink / raw) To: Mark Wielaard; +Cc: frysk Mark Wielaard wrote: > Yes, but my point is more that pre-mature refactoring at this point > seems not a good idea. We don't seem to have all the information yet. > But maybe you do have a clear picture already. I am trying to get an > idea what we would really gain from it at this point. Which api users do > you have in mind and what are they doing now through frysk.proc (or > directly through frysk.proc.ptrace and frsyk.proc.core) that would be > better modeled through the proposed properties-based package > abstractions? > > The user visible interface is frysk.proc, the rest is internal. We could equally argue that the frysk.proc.ptrace refactoring was pre-mature. For that we discussed, agreed, and then I implemented; the result while a step forward has clear problems; perhaps I could revert it. This next step is along that path. Remember, live processes can change state and so have observers, dead processes do not. Andrew ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: frysk.proc.{ptrace,corefile} -> frysk.proc.{live,dead} 2007-06-15 15:04 ` Andrew Cagney @ 2007-06-15 19:44 ` Mark Wielaard 2007-06-18 18:15 ` Andrew Cagney 0 siblings, 1 reply; 13+ messages in thread From: Mark Wielaard @ 2007-06-15 19:44 UTC (permalink / raw) To: Andrew Cagney; +Cc: frysk [-- Attachment #1: Type: text/plain, Size: 1927 bytes --] On Fri, 2007-06-15 at 10:40 -0400, Andrew Cagney wrote: > Mark Wielaard wrote: > > Yes, but my point is more that pre-mature refactoring at this point > > seems not a good idea. We don't seem to have all the information yet. > > But maybe you do have a clear picture already. I am trying to get an > > idea what we would really gain from it at this point. Which api users do > > you have in mind and what are they doing now through frysk.proc (or > > directly through frysk.proc.ptrace and frsyk.proc.core) that would be > > better modeled through the proposed properties-based package > > abstractions? > > > The user visible interface is frysk.proc, the rest is internal. OK, so you mean that for other parts of frysk there is just Task and Proc to deal with. LiveTask or DeadTask is just an implementation detail and an interface to the rest of the system? Then I am a little confused why you want these renames. If it is all about implementation details then the implementation names ptrace and core are much more appropriate. > We could equally argue that the frysk.proc.ptrace refactoring was > pre-mature. For that we discussed, agreed, and then I implemented; the > result while a step forward has clear problems; perhaps I could revert > it. This next step is along that path. No need to revert that, I do like the split between proc, proc.ptrace and proc.core and I do like to see that separation of public interfaces and implementation details. But I am truly not clear on the precise refactoring you are planning to do. It seems completely unnecessary to do a total rename for the refactoring of some methods into frysk.proc.ptrace and frysk.proc.core for the general frysk.proc classes. Could you give an concrete example that shows what you think needs to be done? Having an api prototype that you are thinking of will help review things for others. Thanks, Mark [-- Attachment #2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: frysk.proc.{ptrace,corefile} -> frysk.proc.{live,dead} 2007-06-15 19:44 ` Mark Wielaard @ 2007-06-18 18:15 ` Andrew Cagney 2007-06-18 19:06 ` Mark Wielaard 0 siblings, 1 reply; 13+ messages in thread From: Andrew Cagney @ 2007-06-18 18:15 UTC (permalink / raw) To: Mark Wielaard; +Cc: frysk Mark, Reading between the lines I suspect your concern here isn't so much about this specific change but about the rate of change in general? Remember Frysk as a project is relatively free flowing when it comes to its code and refactoring. We don't spend days or weeks musing over choices, or trying to design perfection. Instead we design for todays problem and let tomorrows developers re-design for their future. This gives us much flexibility while while ensuring that we are focused on real rather than hypothetical needs. Here I implemented frysk.proc.ptrace, and contrary to what you assert, it is a mess. It forced the exposure of numerous public variables in frysk.proc.Task. By instead re-aligning the sub-packages to focus on "liveness" and refactor all "liveness" variables and code out of frysk.proc and into frysk.proc.live.LiveTask (e.g., implementation of requestAddObserver blah) I can move forward and fix this problem. Can we do that? Andrew Mark Wielaard wrote: > On Fri, 2007-06-15 at 10:40 -0400, Andrew Cagney wrote: > >> Mark Wielaard wrote: >> >>> Yes, but my point is more that pre-mature refactoring at this point >>> seems not a good idea. We don't seem to have all the information yet. >>> But maybe you do have a clear picture already. I am trying to get an >>> idea what we would really gain from it at this point. Which api users do >>> you have in mind and what are they doing now through frysk.proc (or >>> directly through frysk.proc.ptrace and frsyk.proc.core) that would be >>> better modeled through the proposed properties-based package >>> abstractions? >>> >>> >> The user visible interface is frysk.proc, the rest is internal. >> > > OK, so you mean that for other parts of frysk there is just Task and > Proc to deal with. LiveTask or DeadTask is just an implementation detail > and an interface to the rest of the system? Then I am a little confused > why you want these renames. If it is all about implementation details > then the implementation names ptrace and core are much more appropriate. > > >> We could equally argue that the frysk.proc.ptrace refactoring was >> pre-mature. For that we discussed, agreed, and then I implemented; the >> result while a step forward has clear problems; perhaps I could revert >> it. This next step is along that path. >> > > No need to revert that, I do like the split between proc, proc.ptrace > and proc.core and I do like to see that separation of public interfaces > and implementation details. But I am truly not clear on the precise > refactoring you are planning to do. It seems completely unnecessary to > do a total rename for the refactoring of some methods into > frysk.proc.ptrace and frysk.proc.core for the general frysk.proc > classes. Could you give an concrete example that shows what you think > needs to be done? Having an api prototype that you are thinking of will > help review things for others. > > Thanks, > > Mark > ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: frysk.proc.{ptrace,corefile} -> frysk.proc.{live,dead} 2007-06-18 18:15 ` Andrew Cagney @ 2007-06-18 19:06 ` Mark Wielaard 2007-06-18 23:29 ` Andrew Cagney 2007-06-19 8:32 ` Andrew Cagney 0 siblings, 2 replies; 13+ messages in thread From: Mark Wielaard @ 2007-06-18 19:06 UTC (permalink / raw) To: Andrew Cagney; +Cc: frysk On Mon, 2007-06-18 at 14:02 -0400, Andrew Cagney wrote: > Reading between the lines I suspect your concern here isn't so much > about this specific change but about the rate of change in general? No, more the rate of changes I don't really understand the why of. I like to have more design discussion on the list so we all know why and what changes are proposed and being worked on. > Remember Frysk as a project is relatively free flowing when it comes to > its code and refactoring. We don't spend days or weeks musing over > choices, or trying to design perfection. Instead we design for todays > problem and let tomorrows developers re-design for their future. This > gives us much flexibility while while ensuring that we are focused on > real rather than hypothetical needs. That is good. But what I am missing is the actual problem statement. What exactly isn't possible today and what is possible tomorrow after such a change is made. My concern is that some of this is just refactoring for refactorings sake. That is why I ask the why and what questions. > Here I implemented frysk.proc.ptrace, and contrary to what you assert, > it is a mess. It forced the exposure of numerous public variables in > frysk.proc.Task. I don't believe I assert that at all. The split of the proc interface and the proc.ptrace and proc.core implementation refactoring is not complete though if it exposes things in the interfaces that should be in the implementation packages. > By instead re-aligning the sub-packages to focus on > "liveness" and refactor all "liveness" variables and code out of > frysk.proc and into frysk.proc.live.LiveTask (e.g., implementation of > requestAddObserver blah) I can move forward and fix this problem. > > Can we do that? We can certainly refactor the proc interfaces and implementation subpackages. But you are mixing two things in your plan. The renaming of existing packages and classes (which I don't see any benefit of) and exposing flaws in of the refactoring of the proc, proc.ptrace and proc.core code because there is a clear separation between interface and implementation. Cheers, Mark ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: frysk.proc.{ptrace,corefile} -> frysk.proc.{live,dead} 2007-06-18 19:06 ` Mark Wielaard @ 2007-06-18 23:29 ` Andrew Cagney 2007-06-19 8:59 ` Mark Wielaard 2007-06-19 8:32 ` Andrew Cagney 1 sibling, 1 reply; 13+ messages in thread From: Andrew Cagney @ 2007-06-18 23:29 UTC (permalink / raw) To: Mark Wielaard; +Cc: frysk Mark Wielaard wrote: > > > We can certainly refactor the proc interfaces and implementation > subpackages. But you are mixing two things in your plan. The renaming of > existing packages and classes (which I don't see any benefit of) and > exposing flaws in of the refactoring of the proc, proc.ptrace and > proc.core code because there is a clear separation between interface and > implementation. > Sorry, I don't follow, what do you think I am planning, and why do you think it is mixed? Andrew ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: frysk.proc.{ptrace,corefile} -> frysk.proc.{live,dead} 2007-06-18 23:29 ` Andrew Cagney @ 2007-06-19 8:59 ` Mark Wielaard 2007-06-19 22:30 ` Andrew Cagney 0 siblings, 1 reply; 13+ messages in thread From: Mark Wielaard @ 2007-06-19 8:59 UTC (permalink / raw) To: Andrew Cagney; +Cc: frysk On Mon, 2007-06-18 at 19:29 -0400, Andrew Cagney wrote: > > That is good. But what I am missing is the actual problem statement. > > What exactly isn't possible today and what is possible tomorrow after > > such a change is made. My concern is that some of this is just > > refactoring for refactorings sake. That is why I ask the why and what > > questions. > > > Sorry I don't follow, the but. This is good. Try showing that it is good and what the problem it is that it solves with some concrete examples. An simple example of existing code and what it should/could be might make things a lot more concrete and clear for others to see which actual problem this solves. > On Mon, 2007-06-18 at 18:27 -0400, Andrew Cagney wrote: > Mark Wielaard wrote: > > > > We can certainly refactor the proc interfaces and implementation > > subpackages. But you are mixing two things in your plan. The renaming of > > existing packages and classes (which I don't see any benefit of) and > > exposing flaws in of the refactoring of the proc, proc.ptrace and > > proc.core code because there is a clear separation between interface and > > implementation. > > > Sorry, I don't follow, what do you think I am planning, and why do you > think it is mixed? You don't make a clear distinction between on the one hand what exactly you propose to move from the proc interfaces into the ptrace and core implementation packages, and on the other hand the complete renaming of the packages plus introduction of the new live and dead concepts. I believe these new concepts of live and dead aren't really different from the ptrace vs core distinction we have now. And if so then renaming everything doesn't solve any actual problem, but just introduces random change. But your examples don't make this clear to me. My proposal is that you first describe the separation of interface and implementation between proc, ptrace and core, and then if we have a good separation between interface packages and implementation packages then you introduce the live and dead property concepts based on that. Cheers, Mark ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: frysk.proc.{ptrace,corefile} -> frysk.proc.{live,dead} 2007-06-19 8:59 ` Mark Wielaard @ 2007-06-19 22:30 ` Andrew Cagney 2007-06-20 9:21 ` Mark Wielaard 0 siblings, 1 reply; 13+ messages in thread From: Andrew Cagney @ 2007-06-19 22:30 UTC (permalink / raw) To: Mark Wielaard; +Cc: frysk Mark Wielaard wrote: > On Mon, 2007-06-18 at 19:29 -0400, Andrew Cagney wrote: > >>> That is good. But what I am missing is the actual problem statement. >>> What exactly isn't possible today and what is possible tomorrow after >>> such a change is made. My concern is that some of this is just >>> refactoring for refactorings sake. That is why I ask the why and what >>> questions. >>> >>> >> Sorry I don't follow, the but. This is good. >> > > Try showing that it is good and what the problem it is that it solves > with some concrete examples. An simple example of existing code and what > it should/could be might make things a lot more concrete and clear for > others to see which actual problem this solves. > A specific example that I mentioned previously was requestAddBLAH. live processes handle that, dead processes do not. > >> On Mon, 2007-06-18 at 18:27 -0400, Andrew Cagney wrote: >> Mark Wielaard wrote: >> >>> We can certainly refactor the proc interfaces and implementation >>> subpackages. But you are mixing two things in your plan. The renaming of >>> existing packages and classes (which I don't see any benefit of) and >>> exposing flaws in of the refactoring of the proc, proc.ptrace and >>> proc.core code because there is a clear separation between interface and >>> implementation. >>> >>> >> Sorry, I don't follow, what do you think I am planning, and why do you >> think it is mixed? >> > > You don't make a clear distinction between on the one hand what exactly > you propose to move from the proc interfaces into the ptrace and core > implementation packages, and on the other hand the complete renaming of > the packages plus introduction of the new live and dead concepts. > Hardly, we're discussing end-goals. There's no need to describe in detail intermediate steps here. > I believe these new concepts of live and dead aren't really different > from the ptrace vs core distinction we have now. And if so then renaming > everything doesn't solve any actual problem, but just introduces random > change. But your examples don't make this clear to me. > Could there be confusion between a attribute such as liveness with an implementation choice such as ptrace. Not unlike how Collection is the super object, List is a refinement, and ArrayList is a specific implementation choice. > My proposal is that you first describe the separation of interface and > implementation between proc, ptrace and core, and then if we have a good > separation between interface packages and implementation packages then > you introduce the live and dead property concepts based on that. > And the way we do that is with the code. If I don't like the results i'll fix them. Andrew ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: frysk.proc.{ptrace,corefile} -> frysk.proc.{live,dead} 2007-06-19 22:30 ` Andrew Cagney @ 2007-06-20 9:21 ` Mark Wielaard 0 siblings, 0 replies; 13+ messages in thread From: Mark Wielaard @ 2007-06-20 9:21 UTC (permalink / raw) To: Andrew Cagney; +Cc: frysk [-- Attachment #1: Type: text/plain, Size: 5213 bytes --] On Tue, 2007-06-19 at 17:58 -0400, Andrew Cagney wrote: > Mark Wielaard wrote: > > On Mon, 2007-06-18 at 19:29 -0400, Andrew Cagney wrote: > >> Sorry I don't follow, the but. This is good. > >> > > Try showing that it is good and what the problem it is that it solves > > with some concrete examples. An simple example of existing code and what > > it should/could be might make things a lot more concrete and clear for > > others to see which actual problem this solves. > > > A specific example that I mentioned previously was requestAddBLAH. live > processes handle that, dead processes do not. Dead (although I do think that is a silly term, try using Frozen) processes do handle that. It is just that some observers are immediately triggered since the process is always ready and others never since the action that the observer is waiting for will never occur. That might or might not be something that is convenient, or something that can be better modeled otherwise. My question really was where you see an actual problem in the current code and give an example of how to more elegantly solve that issue. > > You don't make a clear distinction between on the one hand what exactly > > you propose to move from the proc interfaces into the ptrace and core > > implementation packages, and on the other hand the complete renaming of > > the packages plus introduction of the new live and dead concepts. > > > Hardly, we're discussing end-goals. There's no need to describe in > detail intermediate steps here. OK, what are the end-goals? > > I believe these new concepts of live and dead aren't really different > > from the ptrace vs core distinction we have now. And if so then renaming > > everything doesn't solve any actual problem, but just introduces random > > change. But your examples don't make this clear to me. > > > Could there be confusion between a attribute such as liveness with an > implementation choice such as ptrace. Not unlike how Collection is the > super object, List is a refinement, and ArrayList is a specific > implementation choice. Yes, I think that is the confusion. You propose to just rename proc.ptrace and proc.core to live and dead, while they are perfectly good implementation choices for your concepts of live and frozen (nee dead). Renaming things doesn't solve problems, it just moves problems and makes things harder for others to follow. So concentrate on the attributes you want to model first instead of randomly renaming specific implementation files. > > My proposal is that you first describe the separation of interface and > > implementation between proc, ptrace and core, and then if we have a good > > separation between interface packages and implementation packages then > > you introduce the live and dead property concepts based on that. > > > And the way we do that is with the code. If I don't like the results > i'll fix them. No. That is not how you work with a group of people on a project. You try to explain the why of changes you do so everybody has a clear vision of the goals, what problems it actually solves and give some examples of actual code that illustrates your goals. Then the group as a whole can help with the results and anticipate where the project is moving. This long thread just started with a suggestion to move around some package names and classes to which I said that I didn't like that, but that I was interested in the concepts behind the idea and would like to know a bit more about the problems you had seen with the current setup and how your suggestion would fix some concrete problems. This isn't about criticizing your work (although I was very unhappy that you just moved things around while we were still discussing whether or not that was a good idea), but about understanding what you actually want to achieve. Which real world problems it solves and how it makes frysk a better platform. We have a large group of diverse people working on frysk all over the planet. I don't have the luxury of being near you and see your hand-waving when you explain things or use osmosis to absorb all your knowledge. And that is true for almost every pairing of frysk hackers. So to raise the collective awareness of the problems we have, the flaws in our current setup that prevent us to solve some things and the solutions we come up with, we have to try and explain things as clearly as we can to each other. That is all I ask. You might leave the project, someone else might join at a later time, people move through the whole frysk codebase to improve and fix things etc. So we need to have these discussions about what, why and how we are solving things with frysk. That way the collective awareness of our group of hackers grows. And more than just one individual knows the why of the design of the different parts of frysk. So please try to share your knowledge with others, even if that means explaining things that are obviously clear to yourself. People do want to learn from you. And you might actually get some nice feedback and ideas for improvements back. Cheers, Mark [-- Attachment #2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: frysk.proc.{ptrace,corefile} -> frysk.proc.{live,dead} 2007-06-18 19:06 ` Mark Wielaard 2007-06-18 23:29 ` Andrew Cagney @ 2007-06-19 8:32 ` Andrew Cagney 1 sibling, 0 replies; 13+ messages in thread From: Andrew Cagney @ 2007-06-19 8:32 UTC (permalink / raw) To: Mark Wielaard; +Cc: frysk Mark, Mark Wielaard wrote: > On Mon, 2007-06-18 at 14:02 -0400, Andrew Cagney wrote: > >> Reading between the lines I suspect your concern here isn't so much >> about this specific change but about the rate of change in general? >> > > No, more the rate of changes I don't really understand the why of. I > like to have more design discussion on the list so we all know why and > what changes are proposed and being worked on. > > >> Remember Frysk as a project is relatively free flowing when it comes to >> its code and refactoring. We don't spend days or weeks musing over >> choices, or trying to design perfection. Instead we design for todays >> problem and let tomorrows developers re-design for their future. This >> gives us much flexibility while while ensuring that we are focused on >> real rather than hypothetical needs. >> > > That is good. But what I am missing is the actual problem statement. > What exactly isn't possible today and what is possible tomorrow after > such a change is made. My concern is that some of this is just > refactoring for refactorings sake. That is why I ask the why and what > questions. > > Sorry I don't follow, the but. This is good. Andrew ^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2007-06-20 8:21 UTC | newest] Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2007-06-13 13:17 frysk.proc.{ptrace,corefile} -> frysk.proc.{live,dead} Andrew Cagney 2007-06-14 10:11 ` Mark Wielaard 2007-06-14 14:08 ` Andrew Cagney 2007-06-15 9:05 ` Mark Wielaard 2007-06-15 15:04 ` Andrew Cagney 2007-06-15 19:44 ` Mark Wielaard 2007-06-18 18:15 ` Andrew Cagney 2007-06-18 19:06 ` Mark Wielaard 2007-06-18 23:29 ` Andrew Cagney 2007-06-19 8:59 ` Mark Wielaard 2007-06-19 22:30 ` Andrew Cagney 2007-06-20 9:21 ` Mark Wielaard 2007-06-19 8:32 ` Andrew Cagney
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).