home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / lang / tcl / 1800 < prev    next >
Encoding:
Text File  |  1992-11-11  |  2.0 KB  |  43 lines
  1. Newsgroups: comp.lang.tcl
  2. Path: sparky!uunet!charon.amdahl.com!pacbell.com!sgiblab!zaphod.mps.ohio-state.edu!sample.eng.ohio-state.edu!purdue!yuma!csn!stortek!v043332
  3. From: v043332@gandalf.stortek.com (Keith Amann)
  4. Subject: Dumping/Restoring Interpreter Memory
  5. Message-ID: <1992Nov11.163524.12633@stortek.com>
  6. Followup-To: comp.lang.tcl
  7. Originator: v043332@gandalf.stortek.com
  8. Keywords: dump restore tcl interpreter
  9. Sender: usenet@stortek.com
  10. Nntp-Posting-Host: gandalf.stortek.com
  11. Organization: Storage Technology Corporation
  12. Distribution: usa
  13. Date: Wed, 11 Nov 1992 16:35:24 GMT
  14. Lines: 27
  15.  
  16.  
  17. This may sound like an odd request, but I was wondering if anyone has devised
  18. a method for dumping interpreter memory to a file, the restoring this file
  19. back into an interpreter and continuing processing right where the dump
  20. left off.  Basically, the application I am looking at is a sort of "backup"
  21. facility that would allow the state of the interpreter to be restored exactly
  22. as it was at the time that the "backup" occurred.
  23.  
  24. I have noted that the tclTest program has a function call to
  25. Tcl_DumpActiveMemory, but can't seem to locate this function (John, is this
  26. not included in the regular distribution?).  I believe that this is part of
  27. what I am looking for, and I could probably derive the "restore" given this
  28. piece of it.
  29.  
  30. I understand that the process simply involves tracing through pointers and
  31. dumping the required info into the file, I guess I just don't have a solid
  32. enough grasp on how the "pointer tree" is constructed in TCL.
  33.  
  34. Any helpful hints or suggestions would be greatly appreciated.  Also, I would
  35. prefer something that DOES NOT utilize Extended TCL (no offense intended, I
  36. just happen to like to stick to the original).
  37.  
  38. -- 
  39. Keith Amann, StorageTek                | My views/opinions belong to me, the 
  40.  <Insert some snappy comment here!>    | company isn't responsible for them.
  41. -------------------------------------------------------------------------------
  42. Internet: v043332@stortek.com  VoiceNet: (303)673-4038  FAX-Net: (303)673-5019
  43.