[vwnc] Sources files

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|

[vwnc] Sources files

Charles Adams
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
Reply | Threaded
Open this post in threaded view
|

Re: [vwnc] Sources files

Reinout Heeck
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
Reply | Threaded
Open this post in threaded view
|

Re: [vwnc] Sources files

Charles Adams
----- 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
Reply | Threaded
Open this post in threaded view
|

Re: [vwnc] Sources files

Charles Adams
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
Reply | Threaded
Open this post in threaded view
|

Re: [vwnc] Sources files

Charles Adams
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
Reply | Threaded
Open this post in threaded view
|

Re: [vwnc] Sources files

Reinout Heeck

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
Reply | Threaded
Open this post in threaded view
|

Re: [vwnc] Sources files

Charles Adams
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
Reply | Threaded
Open this post in threaded view
|

Re: [vwnc] Sources files

Reinout Heeck

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
Reply | Threaded
Open this post in threaded view
|

Re: [vwnc] Sources files

Paul Baumann
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
Reply | Threaded
Open this post in threaded view
|

Re: [vwnc] Sources files

Paul Baumann
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
Reply | Threaded
Open this post in threaded view
|

Re: [vwnc] Sources files

Charles Adams
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
----- Original Message -----
Sent: Monday, February 25, 2008 1:57 PM
Subject: RE: [vwnc] Sources files

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
Reply | Threaded
Open this post in threaded view
|

Re: [vwnc] Sources files

Paul Baumann
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
----- Original Message -----
Sent: Monday, February 25, 2008 1:57 PM
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.
 
...
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
Reply | Threaded
Open this post in threaded view
|

Re: [vwnc] Sources files

Charles Adams
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
 
 
----- Original Message -----
Sent: Monday, February 25, 2008 4:23 PM
Subject: RE: [vwnc] Sources files

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
----- Original Message -----
Sent: Monday, February 25, 2008 1:57 PM
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.
 
...
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
Reply | Threaded
Open this post in threaded view
|

Re: [vwnc] Sources files

Eliot Miranda-2
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
.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?

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.



----- 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


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: [vwnc] Sources files

Eliot Miranda-2
In reply to this post by Charles Adams


On Mon, Feb 25, 2008 at 12:19 PM, Charles Adams <[hidden email]> wrote:
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.

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 :)

I can have another source file with the correct source but at a different location in the file.

or vice verca.
 
 
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
----- Original Message -----
Sent: Monday, February 25, 2008 1:57 PM
Subject: RE: [vwnc] Sources files

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



_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: [vwnc] Sources files

Charles Adams
 
----- Original Message -----
Sent: Tuesday, February 26, 2008 2:00 PM
Subject: Re: [vwnc] Sources files



On Mon, Feb 25, 2008 at 12:19 PM, Charles Adams <[hidden email]> wrote:
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.

Do you mean file pointer in the sense of a unix file handle or something else? 
 
Sorry, I used the wrong word. I meant 'source pointer' -- just as it says in the comments for the class.
 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.
 
We *do* have one, humongous source file. By virtue of: "SourceFileManager default condenseChangesOntoSources."


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 :)

I can have another source file with the correct source but at a different location in the file.

or vice verca.
 
 
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
----- Original Message -----
Sent: Monday, February 25, 2008 1:57 PM
Subject: RE: [vwnc] Sources files

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



_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: [vwnc] Sources files

Niall Ross
In reply to this post by Charles Adams
Dear Charles,
    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:
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


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: [vwnc] Sources files

Charles Adams
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 -----
Sent: Sunday, March 02, 2008 1:05 PM
Subject: Re: [vwnc] Sources files

Dear Charles,
    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:
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


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc