[vwnc] Sources files
Locked
 
|
ControlWORKS is a distributed, embedded control system
framework. We have multiple flavors of the CW image geared to meeting specific
needs. Each flavor has its own sources (.sou) file. The differences between the
sources files range from small to great. We deliver images and sources files
(including an empty changes list) to our customers as well as published
code in a Postgres database.
Our customers then build on this to produce their own product.
They have to build upon the various cw*.sou's and produce more .sou's. It would
be nice if we could all merely reference multiple .sou's instead of rebuilding
them. Even better, it would be nice if we could build a single, master sources
library for CW.
So, my questions are:
1) Can the image support more than one
sources file?
and
2) Can an image be re-synd'ed to a sources
file?
From what I know about the technology, my answers would be
'no'. Does anyone have experience in tweaking this part of the system and
achieving features like these? Maybe something from the public
repository?
Regards,
Charles Adams
Adventa Control Technologies, Inc. 3001 E. Plano Parkway, #100 Plano, TX 75074-7422 Office: 972.543.1688 FAX: 972.633.9317 http://www.adventact.com [hidden email] _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
|
|
You seem to be mixing up .sou and .cha files in your description below
(or I am just terribly confused). As I understand it .sou files are already shared. .cha files on the other hand are tighty coupled to their image. For our projects we add an extra layer of .sou files additional to the visual.sou supplied with the product. We use this to keep our .cha files empty after a build, so that only interactive edits appear in them. The code is available in the public repository as 'Store-Source-Extention' (sic) by Olaf Urban, although I don't know if it is up-to date with our internal versions. Email olaf at soops.nl if you need more info. HTH, R - Charles Adams wrote: > ControlWORKS is a distributed, embedded control system framework. We > have multiple flavors of the CW image geared to meeting specific needs. > Each flavor has its own sources (.sou) file. The differences between the > sources files range from small to great. We deliver images and sources > files (including an empty changes list) to our customers as well as > published code in a Postgres database. > > Our customers then build on this to produce their own product. They have > to build upon the various cw*.sou's and produce more .sou's. It would be > nice if we could all merely reference multiple .sou's instead of > rebuilding them. Even better, it would be nice if we could build a > single, master sources library for CW. > > So, my questions are: > > 1) Can the image support more than one sources file? > and > 2) Can an image be re-synd'ed to a sources file? > > From what I know about the technology, my answers would be 'no'. Does > anyone have experience in tweaking this part of the system and achieving > features like these? Maybe something from the public repository? > > Regards, > Charles Adams > Adventa Control Technologies, Inc. > 3001 E. Plano Parkway, #100 > Plano, TX 75074-7422 > Office: 972.543.1688 > FAX: 972.633.9317 > http://www.adventact.com > mailto:[hidden email] > > > ------------------------------------------------------------------------ > > _______________________________________________ > vwnc mailing list > [hidden email] > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
|
|
----- Original Message -----
From: "Reinout Heeck" <[hidden email]> To: <[hidden email]> Sent: Monday, February 25, 2008 9:59 AM Subject: Re: [vwnc] Sources files > You seem to be mixing up .sou and .cha files in your description below > (or I am just terribly confused). > > As I understand it .sou files are already shared. > > .cha files on the other hand are tighty coupled to their image. > > > For our projects we add an extra layer of .sou files additional to the > visual.sou supplied with the product. How do you do that? Can you walk be through what you do precisely? > > We use this to keep our .cha files empty after a build, so that only > interactive edits appear in them. > > The code is available in the public repository as > 'Store-Source-Extention' (sic) by Olaf Urban, although I don't know if > it is up-to date with our internal versions. Email olaf at soops.nl if > you need more info. > > > HTH, > > R > - > > > Charles Adams wrote: >> ControlWORKS is a distributed, embedded control system framework. We >> have multiple flavors of the CW image geared to meeting specific needs. >> Each flavor has its own sources (.sou) file. The differences between the >> sources files range from small to great. We deliver images and sources >> files (including an empty changes list) to our customers as well as >> published code in a Postgres database. >> >> Our customers then build on this to produce their own product. They have >> to build upon the various cw*.sou's and produce more .sou's. It would be >> nice if we could all merely reference multiple .sou's instead of >> rebuilding them. Even better, it would be nice if we could build a >> single, master sources library for CW. >> >> So, my questions are: >> >> 1) Can the image support more than one sources file? >> and >> 2) Can an image be re-synd'ed to a sources file? >> >> From what I know about the technology, my answers would be 'no'. Does >> anyone have experience in tweaking this part of the system and achieving >> features like these? Maybe something from the public repository? >> >> Regards, >> Charles Adams >> Adventa Control Technologies, Inc. >> 3001 E. Plano Parkway, #100 >> Plano, TX 75074-7422 >> Office: 972.543.1688 >> FAX: 972.633.9317 >> http://www.adventact.com >> mailto:[hidden email] >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> vwnc mailing list >> [hidden email] >> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > _______________________________________________ > vwnc mailing list > [hidden email] > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
|
|
Sorry, I'll just read the package comments on Store-Source-Extention.
----- Original Message ----- From: "Charles Adams" <[hidden email]> To: "Reinout Heeck" <[hidden email]>; <[hidden email]> Sent: Monday, February 25, 2008 10:09 AM Subject: Re: [vwnc] Sources files > ----- Original Message ----- > From: "Reinout Heeck" <[hidden email]> > To: <[hidden email]> > Sent: Monday, February 25, 2008 9:59 AM > Subject: Re: [vwnc] Sources files > > >> You seem to be mixing up .sou and .cha files in your description below >> (or I am just terribly confused). >> >> As I understand it .sou files are already shared. >> >> .cha files on the other hand are tighty coupled to their image. >> >> >> For our projects we add an extra layer of .sou files additional to the >> visual.sou supplied with the product. > > How do you do that? Can you walk be through what you do precisely? > >> >> We use this to keep our .cha files empty after a build, so that only >> interactive edits appear in them. >> >> The code is available in the public repository as >> 'Store-Source-Extention' (sic) by Olaf Urban, although I don't know if >> it is up-to date with our internal versions. Email olaf at soops.nl if >> you need more info. >> >> >> HTH, >> >> R >> - >> >> >> Charles Adams wrote: >>> ControlWORKS is a distributed, embedded control system framework. We >>> have multiple flavors of the CW image geared to meeting specific needs. >>> Each flavor has its own sources (.sou) file. The differences between the >>> sources files range from small to great. We deliver images and sources >>> files (including an empty changes list) to our customers as well as >>> published code in a Postgres database. >>> >>> Our customers then build on this to produce their own product. They have >>> to build upon the various cw*.sou's and produce more .sou's. It would be >>> nice if we could all merely reference multiple .sou's instead of >>> rebuilding them. Even better, it would be nice if we could build a >>> single, master sources library for CW. >>> >>> So, my questions are: >>> >>> 1) Can the image support more than one sources file? >>> and >>> 2) Can an image be re-synd'ed to a sources file? >>> >>> From what I know about the technology, my answers would be 'no'. Does >>> anyone have experience in tweaking this part of the system and achieving >>> features like these? Maybe something from the public repository? >>> >>> Regards, >>> Charles Adams >>> Adventa Control Technologies, Inc. >>> 3001 E. Plano Parkway, #100 >>> Plano, TX 75074-7422 >>> Office: 972.543.1688 >>> FAX: 972.633.9317 >>> http://www.adventact.com >>> mailto:[hidden email] >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> vwnc mailing list >>> [hidden email] >>> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc >> _______________________________________________ >> vwnc mailing list >> [hidden email] >> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc >> > > _______________________________________________ > vwnc mailing list > [hidden email] > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
|
|
In reply to this post by Reinout Heeck
----- Original Message ----- From: "Reinout Heeck" <[hidden email]> To: <[hidden email]> Sent: Monday, February 25, 2008 9:59 AM Subject: Re: [vwnc] Sources files > You seem to be mixing up .sou and .cha files in your description below > (or I am just terribly confused). > > As I understand it .sou files are already shared. > > .cha files on the other hand are tighty coupled to their image. That is not my understanding. AFAIK, .sou files are merely read-only changes files. The coupling to the image is the same with .sou files as it is with .cha files. Given this, I don't see how an .sou file could be shared. I hope I'm wrong. > For our projects we add an extra layer of .sou files additional to the > visual.sou supplied with the product. I see that from the tool you mention below. That is one thing I'm after -- to add more sources files instead of piling onto visual.sou. But the tool has to hack on SourceFileManager to get the job done. That is disappointing. > We use this to keep our .cha files empty after a build, so that only > interactive edits appear in them. A worthy goal. > The code is available in the public repository as > 'Store-Source-Extention' (sic) by Olaf Urban, although I don't know if > it is up-to date with our internal versions. Email olaf at soops.nl if > you need more info. Does anyone know if this is still compatible work? > HTH, > > R > - > > > Charles Adams wrote: >> ControlWORKS is a distributed, embedded control system framework. We >> have multiple flavors of the CW image geared to meeting specific needs. >> Each flavor has its own sources (.sou) file. The differences between the >> sources files range from small to great. We deliver images and sources >> files (including an empty changes list) to our customers as well as >> published code in a Postgres database. >> >> Our customers then build on this to produce their own product. They have >> to build upon the various cw*.sou's and produce more .sou's. It would be >> nice if we could all merely reference multiple .sou's instead of >> rebuilding them. Even better, it would be nice if we could build a >> single, master sources library for CW. >> >> So, my questions are: >> >> 1) Can the image support more than one sources file? >> and >> 2) Can an image be re-synd'ed to a sources file? >> >> From what I know about the technology, my answers would be 'no'. Does >> anyone have experience in tweaking this part of the system and achieving >> features like these? Maybe something from the public repository? >> >> Regards, >> Charles Adams >> Adventa Control Technologies, Inc. >> 3001 E. Plano Parkway, #100 >> Plano, TX 75074-7422 >> Office: 972.543.1688 >> FAX: 972.633.9317 >> http://www.adventact.com >> mailto:[hidden email] >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> vwnc mailing list >> [hidden email] >> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > _______________________________________________ > vwnc mailing list > [hidden email] > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
|
|
On Feb 25, 2008, at 6:20 PM, Charles Adams wrote: > AFAIK, .sou files are merely read-only changes files. The coupling > to the image is the same with .sou files as it is with .cha files. > Given this, I don't see how an .sou file could be shared. I hope I'm > wrong. If you use the 'save as' option in VisualWorks a new .cha is created (copied) but the .sou is not copied. HTH, Reinout ------- _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
|
|
I'm not sure what that proves. Yes, in that sense, two images can share a
.sou. The method pointers are still fixed into both files. The images are derivative. The .sou file is unchanged. As soon as you push more changes from one image into the .sou file, you alienate the other image. Is that not true? ----- Original Message ----- From: "Reinout Heeck" <[hidden email]> To: "VWNC List" <[hidden email]> Sent: Monday, February 25, 2008 12:26 PM Subject: Re: [vwnc] Sources files > > On Feb 25, 2008, at 6:20 PM, Charles Adams wrote: > >> AFAIK, .sou files are merely read-only changes files. The coupling >> to the image is the same with .sou files as it is with .cha files. >> Given this, I don't see how an .sou file could be shared. I hope I'm >> wrong. > > If you use the 'save as' option in VisualWorks a new .cha is created > (copied) but the .sou is not copied. > > > HTH, > > Reinout > ------- > > _______________________________________________ > vwnc mailing list > [hidden email] > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
|
|
On Feb 25, 2008, at 7:42 PM, Charles Adams wrote: > I'm not sure what that proves. Yes, in that sense, two images can > share a .sou. The method pointers are still fixed into both files. > The images are derivative. The .sou file is unchanged. As soon as > you push more changes from one image into the .sou file, you > alienate the other image. Is that not true? Errr, yeah - if you change a file that is intended to be read-only because it is shared all bets are off of course. The package I mentioned is intended to plug that hole. Success! Reinout ------- _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
|
|
In reply to this post by Charles Adams
Charles,
This is what I've done to re-sync an image to
source files...
I generate runtime images by script and distribute
the source files with them so that real source can be found while
debugging. The script copies the source files used by the runtime image to a
directory. The runtime image fixes up the source filenames at startup. If source
files are not present then it just forgets about them to avoid source not found
dialogs.
copySourceFilesInto:
dirName
| sources newNameIndex | sources := dirName asFilename. sources exists ifFalse: [sources makeDirectory]. newNameIndex := Dictionary new. self activeSourceFiles do: [:assoc | | newName | newName := (sources / assoc value fileName tail) asLogicalFileSpecification. SourceFileManager default close: assoc key. assoc value fileName copyTo: newName. newNameIndex at: assoc key put: newName]. ^newNameIndex fixupSourceFileReferences
self assertIsRuntime. self preferLocalSourceFileReferencesIn: ObjectMemory imagePrefix asFilename directory / self runtimeSourceDirectoryName. self removeInvalidSourceFileReferences preferLocalSourceFileReferencesIn:
sourcesDir
"This is to prevent our runtime package from getting invalid source file warning messages. We want it to simply decompile if sources are not available." | manager |
self assertIsRuntime. sourcesDir exists ifFalse: [^self]. manager := SourceFileManager default. manager fileIndicesDo: [:index | | potential | potential := sourcesDir / (manager nameStringAt: index) asFilename tail. potential exists ifTrue: [manager file: index name: potential writable: (manager isReadOnly: index) not]] removeInvalidSourceFileReferences
"This is to prevent our runtime package from getting invalid source file warning messages. We want it to simply decompile if sources are not available." | manager |
self assertIsRuntime. manager := SourceFileManager default. manager fileIndicesDo: [:index | (manager nameStringAt: index) asFilename exists ifFalse: [manager removeFileAt: index]] Paul Baumann
From: [hidden email] [mailto:[hidden email]] On Behalf Of Charles Adams Sent: Monday, February 25, 2008 10:42 AM To: [hidden email] Subject: [vwnc] Sources files ControlWORKS is a distributed, embedded control system
framework. We have multiple flavors of the CW image geared to meeting specific
needs. Each flavor has its own sources (.sou) file. The differences between the
sources files range from small to great. We deliver images and sources files
(including an empty changes list) to our customers as well as published
code in a Postgres database.
Our customers then build on this to produce their own product.
They have to build upon the various cw*.sou's and produce more .sou's. It would
be nice if we could all merely reference multiple .sou's instead of rebuilding
them. Even better, it would be nice if we could build a single, master sources
library for CW.
So, my questions are:
1) Can the image support more than one
sources file?
and
2) Can an image be re-synd'ed to a sources
file?
From what I know about the technology, my answers would be
'no'. Does anyone have experience in tweaking this part of the system and
achieving features like these? Maybe something from the public
repository?
Regards,
Charles Adams Adventa Control Technologies, Inc. 3001 E. Plano Parkway, #100 Plano, TX 75074-7422 Office: 972.543.1688 FAX: 972.633.9317 http://www.adventact.com [hidden email] This message may contain confidential information and is intended for specific recipients unless explicitly noted otherwise. If you have reason to believe you are not an intended recipient of this message, please delete it and notify the sender. This message may not represent the opinion of IntercontinentalExchange, Inc. (ICE), its subsidiaries or affiliates, and does not constitute a contract or guarantee. Unencrypted electronic mail is not secure and the recipient of this message is expected to provide safeguards from viruses and pursue alternate means of communication where privacy or a binding message is desired. _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
|
|
Charles,
I should mention that the script launches a clean
visual.im, loads parcels, and executes a method to create the runtime
parcels. Since all the code comes from parcels, and it is a clean image,
there is not .cha file to copy; in fact, this is executed just to make
sure:
SourceFileManager default
removeChangeLogTemporarily.
If you are working with a .cha file then you may have to do
something slightly different. BTW, here is a method I'd
missed:
activeSourceFiles
| manager list
|
manager := SourceFileManager default. list := List new. SourceFileManager default fileIndicesDo: [:index | list addLast: index -> (manager fileAt: index)]. ^list Paul Baumann
From: Paul Baumann Sent: Monday, February 25, 2008 2:29 PM To: 'Charles Adams'; [hidden email] Subject: RE: [vwnc] Sources files Charles,
This is what I've done to re-sync an image to
source files...
I generate runtime images by script and distribute
the source files with them so that real source can be found while
debugging. The script copies the source files used by the runtime image to a
directory. The runtime image fixes up the source filenames at startup. If source
files are not present then it just forgets about them to avoid source not found
dialogs.
copySourceFilesInto:
dirName
| sources newNameIndex | sources := dirName asFilename. sources exists ifFalse: [sources makeDirectory]. newNameIndex := Dictionary new. self activeSourceFiles do: [:assoc | | newName | newName := (sources / assoc value fileName tail) asLogicalFileSpecification. SourceFileManager default close: assoc key. assoc value fileName copyTo: newName. newNameIndex at: assoc key put: newName]. ^newNameIndex fixupSourceFileReferences
self assertIsRuntime. self preferLocalSourceFileReferencesIn: ObjectMemory imagePrefix asFilename directory / self runtimeSourceDirectoryName. self removeInvalidSourceFileReferences preferLocalSourceFileReferencesIn:
sourcesDir
"This is to prevent our runtime package from getting invalid source file warning messages. We want it to simply decompile if sources are not available." | manager |
self assertIsRuntime. sourcesDir exists ifFalse: [^self]. manager := SourceFileManager default. manager fileIndicesDo: [:index | | potential | potential := sourcesDir / (manager nameStringAt: index) asFilename tail. potential exists ifTrue: [manager file: index name: potential writable: (manager isReadOnly: index) not]] removeInvalidSourceFileReferences
"This is to prevent our runtime package from getting invalid source file warning messages. We want it to simply decompile if sources are not available." | manager |
self assertIsRuntime. manager := SourceFileManager default. manager fileIndicesDo: [:index | (manager nameStringAt: index) asFilename exists ifFalse: [manager removeFileAt: index]] Paul Baumann
From: [hidden email] [mailto:[hidden email]] On Behalf Of Charles Adams Sent: Monday, February 25, 2008 10:42 AM To: [hidden email] Subject: [vwnc] Sources files ControlWORKS is a distributed, embedded control system
framework. We have multiple flavors of the CW image geared to meeting specific
needs. Each flavor has its own sources (.sou) file. The differences between the
sources files range from small to great. We deliver images and sources files
(including an empty changes list) to our customers as well as published
code in a Postgres database.
Our customers then build on this to produce their own product.
They have to build upon the various cw*.sou's and produce more .sou's. It would
be nice if we could all merely reference multiple .sou's instead of rebuilding
them. Even better, it would be nice if we could build a single, master sources
library for CW.
So, my questions are:
1) Can the image support more than one
sources file?
and
2) Can an image be re-synd'ed to a sources
file?
From what I know about the technology, my answers would be
'no'. Does anyone have experience in tweaking this part of the system and
achieving features like these? Maybe something from the public
repository?
Regards,
Charles Adams Adventa Control Technologies, Inc. 3001 E. Plano Parkway, #100 Plano, TX 75074-7422 Office: 972.543.1688 FAX: 972.633.9317 http://www.adventact.com [hidden email] This message may contain confidential information and is intended for specific recipients unless explicitly noted otherwise. If you have reason to believe you are not an intended recipient of this message, please delete it and notify the sender. This message may not represent the opinion of IntercontinentalExchange, Inc. (ICE), its subsidiaries or affiliates, and does not constitute a contract or guarantee. Unencrypted electronic mail is not secure and the recipient of this message is expected to provide safeguards from viruses and pursue alternate means of communication where privacy or a binding message is desired. _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
|
|
Thank you Paul, but I'm not sure I'm making my
point.
The SourceFileManager contains a file pointer for a method
into a source file.
I can have another source file with the correct source but at
a different location in the file.
Will your technique cause the SourceFileManager's file pointer
to re-sync to the method definition in the other source file?
After reading your message, I can't quite determine that that
actually happens.
Regards,
Charles Adams
_______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
|
|
A common approach is to publish a base of code for
all flavors and publish variations separate from that base. It
seems like you would like to merge changes for all flavors into a
common base and then fixup code references to find code in more than
one version of the common base. Sounds like you are using .sou files (or
more likely .cha files) to do things most people use StORE to do. The
code I provided was more suited for application parcels generated from code
managed in StORE. I was re-locating source files; you want to
re-sync individual code definitions from multiple sources into multiple
images.
#sourcePointer: can be used to set an instance of a new
subclass of MethodSourceCollection. Your subclass of
MethodSourceCollection would know where/how to resolve the source
pointers you'd record or fixup by some other means. I'm not aware of a tool
(other than loading versions from published sources
like StORE) that would re-sync sourcePointers across images. It seems
like you want your MethodSourceCollection subclass to retain a history of
sources. The #source: setter could be overridden to add-to source history rather
than replace a single source pointer. No practical experience to
share with this technique, it just just looks like the VW code is
designed with a nice amount flexibility that could be used for your purpose. The
challenge for a tool to do this would be the managing of these source
pointers (or use of a unique key generator).
Paul Baumann
From: Charles Adams [mailto:[hidden email]] Sent: Monday, February 25, 2008 3:19 PM To: Paul Baumann; [hidden email] Subject: Re: [vwnc] Sources files Importance: High Thank you Paul, but I'm not sure I'm making my
point.
The SourceFileManager contains a file pointer for a method
into a source file.
I can have another source file with the correct source but at
a different location in the file.
Will your technique cause the SourceFileManager's file pointer
to re-sync to the method definition in the other source file?
After reading your message, I can't quite determine that that
actually happens.
Regards,
Charles Adams
This message may contain confidential information and is intended for specific recipients unless explicitly noted otherwise. If you have reason to believe you are not an intended recipient of this message, please delete it and notify the sender. This message may not represent the opinion of IntercontinentalExchange, Inc. (ICE), its subsidiaries or affiliates, and does not constitute a contract or guarantee. Unencrypted electronic mail is not secure and the recipient of this message is expected to provide safeguards from viruses and pursue alternate means of communication where privacy or a binding message is desired. _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
|
|
Yes, it does sound that way doesn't it? However, it is not my
aim to replace or even supplement Store. My aim was merely to reduce the numbers
of files. Another aim is to distribute the source pointer dependency among
source files -- be able to have source pointers into multiple source files.
Neither sounds easy or practical. But now I know more than I
did.
Regards,
Charles Adams
_______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
|
|
In reply to this post by Charles Adams
On Mon, Feb 25, 2008 at 10:42 AM, Charles Adams <[hidden email]> wrote: I'm not sure what that proves. Yes, in that sense, two images can share a No. Extending a file doesn't invaidate the source pointers within it. Hence the changes file continues to work even as it grows. You'll notice that while the source XML file starts with <?xml version="1.0"?> <st-source> it doesn't end with a </st-source> so that it can be extended. However, if two ssytems try and extend the same source file at the same time there wll likely be corruption at the end of the file. More in a subsequent follow-up.
_______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
|
|
In reply to this post by Charles Adams
On Mon, Feb 25, 2008 at 12:19 PM, Charles Adams <[hidden email]> wrote:
Do you mean file pointer in the sense of a unix file handle or something else? In any case, read the comment on SourceFileManager. A SourceFileManager is a collection of source files, each one given an index. By default/convention visual.sou is at index 1 and the changes file is at index 2. Pointers into source files are in stored in methods in their sourcePointer inst var. Each sourcePointer encodes a file index and a position in an integer. They are somewhat analogous to floating-point numbers. A 2-bit tag in the least significant 2 bits says how many bits the file index takes. The first encoding has room for 16 file indices and hence the position will overflow SmallInteger range at 2^(30 - 2 - 4) = 2^24 = 16Meg. i.e. once your source file is greater than 16Meg source pointers above the 16Meg limit will be LargePositiveIntegers not SmallIntegers. So if you were to concatenate several .sou files into one humongous one and swizzle source pointers in your different versions there would be a per-method space overhead but things would still work. Here's an alternative suggestion. Create a humongous source file simply by concatenating your various source files. Then create and install a subclass of SourceFileManager as SourceFileManager default that maintains an offset for the .sou file (file 1), (or per-file offsets for generality). So to index a source file the subclass adds in the offset when actually reading the file. Then to swizzle an image you need to reparse the relevant portion of the source file to get the pointers right but avoid the overhead of source pointers overflowing to large integers because you set an offset to the start of the part of the source file you're interested in. Note that you can compute the reparse from the source pointers in each of your images whose source files you concatenate. This probably doesn't help :)
or vice verca.
_______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
|
|
Sorry, I used the wrong word. I meant 'source pointer' -- just
as it says in the comments for the class.
We *do* have one, humongous source
file. By virtue of: "SourceFileManager default
condenseChangesOntoSources."
_______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
|
|
In reply to this post by Charles Adams
the sourcePointer is made from an encoding of the file number (1 = sou, 2 = cha, rest = parcel files or ones you contrive by hand) and a source location within that file. I'll discuss first what you want to do (if I understand it), then what I recommend instead. 1) Let's start with just two images. You can close and boss out an image's SourceFileManager. You can also collect the sourcePointer values for a set of selectors (e.g. by creating a subclass of SelectorEnvironment that maps class-selector to sourcePointer) and boss it out as well. Presumably all selectors whose source was in the original .sou or in parcels (unless you have multiple versions between your images) could be ignored (they must be the same) so, before condensing changes, you could collect all selectors whose source was in the .cha and put them in this set, collecting their sourcePointers _after_ condensing. You import these two objects into a second image. If you then present the bossed-in SourceFileManager with a sourcePointer from the bossed-in set, the bossed-in SourceFileManager to consult _its_ files (i.e. the _first_ image's .sou, .cha or parcel files, but by the above argument it will be the .cha that concerns you) and report the appropriate source of the first image. All this works naturally and can the duplicate SourceFileManager can be driven easily from fairly high-level protocol. What follows you must implement yourself (and is theory: I've not attempted it though I've done similar things). You can use the above to detect all cases where a) the source is the same but the pointers differ: apply the first image's sourcePointer to the second image's method b) the source differs: present the second image's source to the first image's SourceFileManager to add it to the first's .cha, then apply the first image's new sourcePointer it retuns to the second image's method, as in case (a) You now switch SourceFileManagers, so the second image is using the first image's files, and condense the .cha you've just populated (consisting entirely of second image additions) onto the sou. Since the first image had already been condensed, you should now have two images sharing a single .sou to which the second image differences have been appended. The machinery you code for doing all this should all be in a parcel so its source file does not affect the above. 2) What I would do instead: create a largest common intersection .sou of all methods that are the same between all your images. (Work out the common subset via Store reconciliation or the approach described in (1) above, then create an image with only this subset and condense it. Its sourcePointers can then be supplied to all the other images, or they can be built from it, whatever is easiest.) Leave all methods that differ in each individual image's .cha. Instead of condensing to a single shared .sou, map each cha to another free index, i.e. as if it were a parcel. You can do this by actually making it one or more parcels or under the covers by direct mapping of the .cha and swizzling its method's pointers to encode the new file index. In effect, you have a .sou, your .cha and the customer's .cha. The customer's sits at index 2 so as far as they are concerned, all works OK. You can skip the creation of the largest common intersection .sou if file size footprint is not a concern: just have the original .sou, your .cha at a free index and the customer's .cha at index 2. This is probably easiest. HTH Yours faithfully Niall Ross Adams wrote:
_______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
|
|
Niall,
Thanks for the detailed explanation and for putting flesh
on some insights I've had about all of this. This sounds too complicated
for me. I'm pretty sure I don't want to be in the position of supporting these
mechanisms.
If there is no native interface for doing what I want, then
I'll just drop it.
As much as I like Store, there are times I miss
Envy.
Regards,
Charles Adams
----- Original Message -----
_______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
«
Return to VisualWorks
|
1 view|%1 views
| Free forum by Nabble | Edit this page |