|
|
| Author |
Message |
|
| joe |
 Posted: Thu Jul 06, 2006 9:41 am |
 |
|
|
User
Joined: 28 Feb 2005
Posts: 93
|
Some thoughts on CEAN
How can we make CEAN? (Comprehensive Erlang Archive Network)
I want to address the following problem?
How can be keep multiple versions of code in the same
namespace in a consistent manner?
Here's a proposal.
Rule 1
======
Versions are named like this AppName-Vsn
Vsn is of no significance it is just a "distinguished string"
<< It might be like this:
myAPP-2.3.4
myAPP-1
myApp-gold
myApp-beta2
>>
Rule 2
======
We have One source code tree:
Root/foo-1.2.3/Dependencies
/src/
/ebin
/xsrc
/foo-gold/Dependencies
/src
/ebin
/xsrc
/yaws-super-fast/Dependencies
/src
/ebin
/xsrc
Same as the OTP tree - with two additions
1) A file called Dependencies
2) A new directory called xsrc
(short for transformed source)
Rule 3
======
All applications are named with the "usual" module naming convention.
ie. The application foo-Vsn has a "main module" foo.erl
and a number of sub-modules foo_xxxxxx.erl.
External applications MUST only call exported routines from foo.erl and
NOT foo_xxxxx.erl
Rule 4
======
xsrc is derived from src using the information in the file
"Dependencies".
Let's assume that the file
foo-2.3.4/Dependencies
Contains the following:
bar-7.0 boo-gold
This means that foo-2.3.4 depends upon bar-7.0 and boo-gold.
Now we transform the code as follows:
all module names
foo foo_XXXX are transformed to foo_2.3.4 foo_XXXX_2.3.4
bar bar_XXXX are transformed to bar_7.0 and bar_XXXX_7.0
boo boo_XXXX are transformed to boo_gold and boo_XXXX_gold
apply(M,F,A) is transformed to
foo_2.3.4:apply_xform(M, F, A)
were foo:apply_x is a local function which
dynamically transforms inter-module calls to the correct namespace
- o O o -
Rule 5
======
The /ebin directory contains compiled code from /xsrc
Comments:
1) I have shown how to provide multiple namespaces with
code transformation - the same think can be achieved internally
by tinkering with the loader and run-time system
2) Dubugging function names may not look so nice
So while debugging once might wish to run with
no name translation
3) <<Challenge to Refactorers>>
There seems to be great opportunities for code refactoring here
The way I work is to work with some version of a program
App-2.3
Then when it works make a snapshot and copy everything to App-2.4
When App-2.4 works and I start with App-2.5 I would like to ask
"what are the changes between App-2.3 and App-2.4" -
Can knowledge of the changes be used in compilation to minimise
the object code size if I want to run both versions in the same
namespace (using some kind of transformation strategy)
Indeed if I take multiple versions of an application and
transform them how can I minimise the total size of the
application, while having the same external interface.
Here we would transform a tree like
foo-1.2.3/src/...
foo-beta3/src/...
boo-8/src/
So that after the transformation the only visible modules would be
foo_1.2.3.erl
foo_beta3.erl
boo_8.erl
And all the "internal" modules would have been merged/consolidated
into
a minimal set.
4) Question to those who know
(ie Richard)
Can igor, and the module namespaces do this already????
Cheers
/Joe
Post recived frommailinglist |
|
|
| Back to top |
 
|
| Thomas Lindgren |
| Posted: Thu Jul 06, 2006 10:50 am |
|
|
|
User
Joined: 09 Mar 2005
Posts: 284
|
--- "Joe Armstrong (AL/EAB)"
<joe.armstrong@ericsson.com> wrote:
> Now we transform the code as follows:
>
> all module names
>
> foo foo_XXXX are transformed to foo_2.3.4
> foo_XXXX_2.3.4
>
> bar bar_XXXX are transformed to bar_7.0 and
> bar_XXXX_7.0
>
> boo boo_XXXX are transformed to boo_gold and
> boo_XXXX_gold
>
> apply(M,F,A) is transformed to
>
> foo_2.3.4:apply_xform(M, F, A)
>
> were foo:apply_x is a local function which
>
> dynamically transforms inter-module calls to the
> correct namespace
This is basically the approach taken by my Erlang
optimizer, as described in EUC 2001 -- though there it
was used to specialize, merge, split, and optimize
modules.
Note that you will have to handle a couple of corner
cases:
1. Apply of apply apply(erlang, apply, [M, F, As])
and so on.
2. The approach is 'insecure' in that someone can
build a module name on their own and invoke a 'hidden'
module with a raw apply. I'm agnostic whether this is
a good or bad thing. (The safe approach is to never
provide external access to the 'actual' apply.)
Regarding dead code after module merging: yes, this is
often present. However, do note that you will have to
be a bit careful not to accidentally delete live
functions 
Furthermore, if you merge modules, you will have to be
clever about changing/patching/hot-loading individual
modules inside a merged entity. Otherwise, you can
inadvertently hang on to a great deal of now-dead
code. This may be okay, of course.
Best,
Thomas
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Post recived frommailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Thu Jul 06, 2006 11:41 am |
|
|
|
Guest
|
|
| Back to top |
|
| Guest |
| Posted: Fri Jul 07, 2006 2:05 am |
|
|
|
Guest
|
"Joe Armstrong \(AL/EAB\)" <joe.armstrong@ericsson.com> wrote:
Versions are named like this AppName-Vsn
Vsn is of no significance it is just a "distinguished string"
It would be really REALLY nice if Vsn terms could be compared
so that one could tell whether rabbit-ping was more recent than
rabbit-pong without having to fossick around in some possibly
remote and possibly inaccessible data base.
Post recived frommailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Fri Jul 07, 2006 6:30 pm |
|
|
|
Guest
|
Richard A. O'Keefe wrote:
> "Joe Armstrong \(AL/EAB\)" <joe.armstrong@ericsson.com> wrote:
> Versions are named like this AppName-Vsn
>
> Vsn is of no significance it is just a "distinguished string"
>
> It would be really REALLY nice if Vsn terms could be compared
> so that one could tell whether rabbit-ping was more recent than
> rabbit-pong without having to fossick around in some possibly
> remote and possibly inaccessible data base.
Recency of package versions is a partial ordering, not a total ordering.
--
David Hopwood <david.nospam.hopwood@blueyonder.co.uk>
Post recived frommailinglist |
|
|
| Back to top |
|
|
|
All times are GMT
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You cannot download files in this forum
|
|
|
Digg It
Del.icio.us
Reddit
Facebook
Stumble Upon
Technorati
