On Jul 11, 8:45 am, "Edward K. Ream" <[EMAIL PROTECTED]> wrote:
> I have begun the final phase of the project, the integration of the > mod_shadow plugin code directly into Leo's core. > > This is an excellent opportunity to use the principles of extreme > programming. Yes indeed. Unit tests are driving every aspect of @shadow's development. Creating the 'x.File utils' has proven to be a smart move. The logic involved in computing the shadow file and shadow directory for a file is complex. Doing it in more than one place would have been horrid. I just fixed a major bug in x.shadowDirName. Almost all the ancillary code in mod_shadow.py has been rewritten. The new code is in at.readOneAtShadowNode and at.writeOneAtShadowNode. This makes @shadow nodes official parts of Leo, and allows access to the normal atFile logic. For example, the code should handles @path directives correctly, though unit tests to that effect are required. The write logic now apparently works and passes all of its unit tests. The read logic also passes all its unit tests, though more tests may be needed. As usual, reading is inherently more difficult than writing. Anyway, we are very close to being able to do real-world @shadow tests. It may happen today. Edward P.S. In the course of doing writeOneAtShadowNode I discovered a major stupidity in Leo atFile.write logic. All the write code writes to a temp file, then uses at.replaceTargetFileIfDifferent to replace the target file with the temp file if there have been no errors. But all the write methods support writing to a string. It makes much more sense to write the string directly to the intended target. That should be safe: the target won't be changed if it can't be opened for writing. So writeOneAtShadowNode calls replaceFileWithString instead of replaceTargetFileIfDifferent. I'm not going to change the rest of Leo's atFile write logic to follow this pattern, but it probably should happen someday. I said earlier that much of the ancillary code has been replaced. For example, the new code no longer uses x.copy_file_removing_sentinels. Instead the write code simply writes the public file without sentinels. In this case, however, there is a subtle difference, as explained by this present comment: ### It may be better to compute the public file by removing sentinels from at.private_s ### by calling x.copy_file_removing_sentinels. This would ensure that the (dubious!!) ### x.isSentinel logic is used consistently by the @shadow read/write logic. ### OTOH, Leo's write logic should actually dominate x.isSentinel. I'm going to go with the "more correct" code and see what happens... EKR --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "leo-editor" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en -~----------~----~----~----~------~----~------~--~---
