Mercurial > pylearn
changeset 1245:808e38dce8d6
Replied to YB's comment on JB's system
author | Olivier Delalleau <delallea@iro> |
---|---|
date | Thu, 23 Sep 2010 12:18:39 -0400 |
parents | 6d97f32c3fdf |
children | 14444845989a b9d0a326e3e7 |
files | doc/v2_planning/arch_src/plugin_JB_comments_YB.txt |
diffstat | 1 files changed, 10 insertions(+), 0 deletions(-) [+] |
line wrap: on
line diff
--- a/doc/v2_planning/arch_src/plugin_JB_comments_YB.txt Thu Sep 23 12:11:44 2010 -0400 +++ b/doc/v2_planning/arch_src/plugin_JB_comments_YB.txt Thu Sep 23 12:18:39 2010 -0400 @@ -45,3 +45,13 @@ I think the advantage of making the program aware where in its own execution flow it is and what is its execution flow can be quite useful for automating some of the things we want. + +OD comments: I agree with Yoshua. I actually thought (by watching at the +discussions in these files from a rather high-level point-of-view) the main +goal of this machinery was to help with parallelization. If that is the case, +it may prove useful in some places, but it is not something that one would +want to use everywhere. As far as serialization is concerned, I think this +should be do-able without such a system (provided we all agree that we do not +necessarily require the ability to serialize / restart at any point). About +the ability to move / substitute things, you could probably achieve the same +goal with proper code factorization / conventions.