Hi John, We've been using vList to save lists and image data without running into memory problems (but none of our images have been over 1MB or so). If you needed to deal with a lot of very large images you could always export them separately and then use binaryIO to concatenate them, copying the data to your new file in smaller chunks.
I haven't used vList to store pointers to #media, but I do know that the #image pointers in vLIst really are pointers (this can cause problems if you're trying to change or erase image data while vLIst is writing to disk). Maybe the anomalies you're seeing are caused (as you suggest) by the watcher itself. HTH Tim > -----Original Message----- > From: John Aquilina (JMW) [mailto:[EMAIL PROTECTED]] > Sent: Saturday, 7 September 2002 1:43 am > To: [EMAIL PROTECTED] > Subject: <lingo-l> vList vs save castlib > > > Hi > > I want to be able to save out (from a projector) changes made > at runtime > (lists & media). I have looked at the vList xtra and also at > saving an > external linked .cst using castLib.save(). For ease-of-management & > distribution I wanted to put everything into one file. > > My first impression of vList because is very positive because > I don't need > to reconstruct my lists when I read it in, and the > compression & encryption > functions available in the Full version could be very useful > in the future > (not needed for this project). It's a fairly simple matter > to repopulate my > cast from the media in the vList file. > > My worry however is that, if I understand things correctly, > using vList > means that ALL of my media must fit into RAM, I can't only > load media as > required, whereas the castlib approach would allow members to > be loaded & > unloaded as required using Director's built-in memory management. > > Is this a correct assessment. Anyone have > thoughts/experiences about vList > in low memory situations. > > Also on vList - when I run the following code: > ( straight from the vList docs) > > aList = [ ] > append aList, member(1).media > append aList, member(1).media > append aList, member(1).media > put aList > > I get something like this: > -- [(media 135ea974), (media 136e7424), (media 135ea960)] > > Which are all pointers to different memory addresses, and the > size of the > list/memory hit goes up accordingly each time. The docs > state that the list > should contain the same pointer for each list item and the > list should not > multiply in size. > > It seems that for member.media & member.picture, the > reference changes every > time it is queried (put member(1).media into the Watcher). > What do you > think about that Herr Heisenberg? I get this on a MacOS9.2 > D7//8/85. How > did vList/updateStage achieve their results? > > thanks in advance > > johnAq > > [To remove yourself from this list, or to change to digest > mode, go to http://www.penworks.com/lingo-l.cgi To post > messages to the list, email [EMAIL PROTECTED] (Problems, > email [EMAIL PROTECTED]). Lingo-L is for learning and > helping with programming Lingo. Thanks!] > [To remove yourself from this list, or to change to digest mode, go to http://www.penworks.com/lingo-l.cgi To post messages to the list, email [EMAIL PROTECTED] (Problems, email [EMAIL PROTECTED]). Lingo-L is for learning and helping with programming Lingo. Thanks!]
