Code reorganization in Webwerkstatt - please check your js files

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

Code reorganization in Webwerkstatt - please check your js files

Fabian Bornhofen-2
Hi -

as mentioned earlier, we want to simplify code distribution.
As a first step, we are going to reorganize some files in Webwerkstatt and move the core code from /repository/webwerkstatt to /repository/webwerkstatt/kernel.

To keep your worlds running, we will run a script on all xhtml files in Webwerkstatt that changes the path to bootstrap.js. For most worlds, you will not notice any difference. If you have never written a Lively JavaScript module on your own,   then most probably you do not need take any action.

However, if any of your worlds have dependencies on other js files (e.g. js files in your home folder), please check references to these paths. Config.codeBase will be /repository/webwerkstatt/kernel instead of /repository/webwerkstatt. Paths relative to Config.codeBase therefore should be fixed (typically with another '../' at the beginning).

We want to apply and commit our changes to Webwerkstatt on early Thursday morning (Oct 27, 1 a.m. CEST or Oct 26 4 p.m. Pacific Time).

Please contact Lauritz or me if you have any questions or if you need assistance.

Rationale:
We want to create a repository of the minimum set of files that is needed for running the Lively Kernel. This could be hosted on Github, Launchpad, or elsewhere. By centralizing these files in Webwerkstatt (which is effectively our upstream repository right now), it will be possible to check them out as a Subversion submodule that can be kept in sync with other version control systems.

Regards,
Fabian

_______________________________________________
lively-kernel mailing list
[hidden email]
http://lists.hpi.uni-potsdam.de/listinfo/lively-kernel
Reply | Threaded
Open this post in threaded view
|

Re: Code reorganization in Webwerkstatt - please check your js files

Lauritz Thamsen
Hi.

As announced yesterday, we reorganized Webwerkstatt a bit.

Please let us know if you experience any problems regarding loading or saving.

Best,
Lauritz


On Oct 25, 2011, at 5:10 PM, Fabian Bornhofen wrote:

> Hi -
>
> as mentioned earlier, we want to simplify code distribution.
> As a first step, we are going to reorganize some files in Webwerkstatt and move the core code from /repository/webwerkstatt to /repository/webwerkstatt/kernel.
>
> To keep your worlds running, we will run a script on all xhtml files in Webwerkstatt that changes the path to bootstrap.js. For most worlds, you will not notice any difference. If you have never written a Lively JavaScript module on your own,   then most probably you do not need take any action.
>
> However, if any of your worlds have dependencies on other js files (e.g. js files in your home folder), please check references to these paths. Config.codeBase will be /repository/webwerkstatt/kernel instead of /repository/webwerkstatt. Paths relative to Config.codeBase therefore should be fixed (typically with another '../' at the beginning).
>
> We want to apply and commit our changes to Webwerkstatt on early Thursday morning (Oct 27, 1 a.m. CEST or Oct 26 4 p.m. Pacific Time).
>
> Please contact Lauritz or me if you have any questions or if you need assistance.
>
> Rationale:
> We want to create a repository of the minimum set of files that is needed for running the Lively Kernel. This could be hosted on Github, Launchpad, or elsewhere. By centralizing these files in Webwerkstatt (which is effectively our upstream repository right now), it will be possible to check them out as a Subversion submodule that can be kept in sync with other version control systems.
>
> Regards,
> Fabian
> _______________________________________________
> lively-kernel mailing list
> [hidden email]
> http://lists.hpi.uni-potsdam.de/listinfo/lively-kernel

_______________________________________________
lively-kernel mailing list
[hidden email]
http://lists.hpi.uni-potsdam.de/listinfo/lively-kernel
Reply | Threaded
Open this post in threaded view
|

Re: Code reorganization in Webwerkstatt - please check your js files

keith1y
In reply to this post by Fabian Bornhofen-2
So far so good.

Importing in to bzr is seeing some problems. Firstly there are so many revisions (slow to import), and secondly there appears to be an incomplete revisions history, this might be an SVN bug.

Keith
Reply | Threaded
Open this post in threaded view
|

Re: Code reorganization in Webwerkstatt - please check your js files

Lincke, Jens
In reply to this post by Lauritz Thamsen
Hi, Lauritz 

works for most pages. How do we deal with non kernel code additions in the wiki. Code in users or project directories such as

Should we require them differently such as we did with the modules from the CodeDB? In the meantime I will move the modules in question below the kernel/ dir.
Kernel is therefore a bad name, because the kernel is under "lively" and we would not call the rest kernel, or would we?

Best,
Jens

On 27.10.2011, at 07:58, Lauritz Thamsen wrote:

Hi.

As announced yesterday, we reorganized Webwerkstatt a bit.

Please let us know if you experience any problems regarding loading or saving.

Best,
Lauritz


On Oct 25, 2011, at 5:10 PM, Fabian Bornhofen wrote:

Hi -

as mentioned earlier, we want to simplify code distribution.
As a first step, we are going to reorganize some files in Webwerkstatt and move the core code from /repository/webwerkstatt to /repository/webwerkstatt/kernel.

To keep your worlds running, we will run a script on all xhtml files in Webwerkstatt that changes the path to bootstrap.js. For most worlds, you will not notice any difference. If you have never written a Lively JavaScript module on your own,   then most probably you do not need take any action.

However, if any of your worlds have dependencies on other js files (e.g. js files in your home folder), please check references to these paths. Config.codeBase will be /repository/webwerkstatt/kernel instead of /repository/webwerkstatt. Paths relative to Config.codeBase therefore should be fixed (typically with another '../' at the beginning).

We want to apply and commit our changes to Webwerkstatt on early Thursday morning (Oct 27, 1 a.m. CEST or Oct 26 4 p.m. Pacific Time).

Please contact Lauritz or me if you have any questions or if you need assistance.

Rationale:
We want to create a repository of the minimum set of files that is needed for running the Lively Kernel. This could be hosted on Github, Launchpad, or elsewhere. By centralizing these files in Webwerkstatt (which is effectively our upstream repository right now), it will be possible to check them out as a Subversion submodule that can be kept in sync with other version control systems.

Regards,
Fabian
_______________________________________________
lively-kernel mailing list
[hidden email]
http://lists.hpi.uni-potsdam.de/listinfo/lively-kernel

_______________________________________________
lively-kernel mailing list
[hidden email]
http://lists.hpi.uni-potsdam.de/listinfo/lively-kernel


_______________________________________________
lively-kernel mailing list
[hidden email]
http://lists.hpi.uni-potsdam.de/listinfo/lively-kernel
Reply | Threaded
Open this post in threaded view
|

Re: Code reorganization in Webwerkstatt - please check your js files

keith1y

I am a bit confused. Having checked ouf "kernel" (I agree it could use a better name), todays update brings with it a "users" directory, and the PartsBin.
Not what I expect for a "kernel".

The naming convention I have used in the past is.

"kernel" for the absolute minimal common core functionality
        - In a system like lively-kernel it doesn't have to work
        - in a squeak like system, it should be able to run a bootstrap to load core packages, i.e. no UI.

"core" loadable libraries that provide standard functionality on top of "kernel".

"packages" loadable modules to extend base.

"kernel, core and packages" are separate code repositories, where as "base and stable" are assemblies of code from the above repositories.

"release" whatever the developers have thrown at me (in the case of squeak/cuis)

"base" an empty working starting point for building stuff, (is a conceptual or virtual release, i.e. "stable" with unloadable packages taken out.
        - effectively the release of "kernel" + "core"

"stable"  - a release "base" + default "packages" for end users to work with.
        - "stable" = "kernel" + "core" + "packages" x N
        - If "packages" are "unloadable" or "load on demand", then a larger "stable" release gives users more to play with, but does not limit flexibility at all.

To support forking, in launchpad the same naming convention can be used for different products..

lively/kernel
lively/core
lively/base
lively/stable
lively/packages
lively/unstable

So my own product would be

deadly/stable etc.

Keith
_______________________________________________
lively-kernel mailing list
[hidden email]
http://lists.hpi.uni-potsdam.de/listinfo/lively-kernel
Reply | Threaded
Open this post in threaded view
|

Re: Code reorganization in Webwerkstatt - please check your js files

Lauritz Thamsen
In reply to this post by Lincke, Jens
Hi Jens --

Should we require them differently such as we did with the modules from the CodeDB? In the meantime I will move the modules in question below the kernel/ dir.
Kernel is therefore a bad name, because the kernel is under "lively" and we would not call the rest kernel, or would we?
Yes, I agree it shouldn't be 'kernel/', so we will rename it to 'core/' later in the evening (Oct 28, 1 a.m. CEST or Oct 27 4 p.m. Pacific Time). However, I am not sure that "personal modules" should be part of our core distribution. Either such code belongs into apps/, lib/ or into lively/ and should be synched across repositories or it should remain in a user's folder and shouldn't be synched across repositories. What do you think? 

Best,
Lauritz

On Oct 27, 2011, at 2:18 AM, Jens Lincke wrote:

Hi, Lauritz 

works for most pages. How do we deal with non kernel code additions in the wiki. Code in users or project directories such as

Should we require them differently such as we did with the modules from the CodeDB? In the meantime I will move the modules in question below the kernel/ dir.
Kernel is therefore a bad name, because the kernel is under "lively" and we would not call the rest kernel, or would we?

Best,
Jens

On 27.10.2011, at 07:58, Lauritz Thamsen wrote:

Hi.

As announced yesterday, we reorganized Webwerkstatt a bit.

Please let us know if you experience any problems regarding loading or saving.

Best,
Lauritz


On Oct 25, 2011, at 5:10 PM, Fabian Bornhofen wrote:

Hi -

as mentioned earlier, we want to simplify code distribution.
As a first step, we are going to reorganize some files in Webwerkstatt and move the core code from /repository/webwerkstatt to /repository/webwerkstatt/kernel.

To keep your worlds running, we will run a script on all xhtml files in Webwerkstatt that changes the path to bootstrap.js. For most worlds, you will not notice any difference. If you have never written a Lively JavaScript module on your own,   then most probably you do not need take any action.

However, if any of your worlds have dependencies on other js files (e.g. js files in your home folder), please check references to these paths. Config.codeBase will be /repository/webwerkstatt/kernel instead of /repository/webwerkstatt. Paths relative to Config.codeBase therefore should be fixed (typically with another '../' at the beginning).

We want to apply and commit our changes to Webwerkstatt on early Thursday morning (Oct 27, 1 a.m. CEST or Oct 26 4 p.m. Pacific Time).

Please contact Lauritz or me if you have any questions or if you need assistance.

Rationale:
We want to create a repository of the minimum set of files that is needed for running the Lively Kernel. This could be hosted on Github, Launchpad, or elsewhere. By centralizing these files in Webwerkstatt (which is effectively our upstream repository right now), it will be possible to check them out as a Subversion submodule that can be kept in sync with other version control systems.

Regards,
Fabian
_______________________________________________
lively-kernel mailing list
[hidden email]
http://lists.hpi.uni-potsdam.de/listinfo/lively-kernel

_______________________________________________
lively-kernel mailing list
[hidden email]
http://lists.hpi.uni-potsdam.de/listinfo/lively-kernel



_______________________________________________
lively-kernel mailing list
[hidden email]
http://lists.hpi.uni-potsdam.de/listinfo/lively-kernel
Reply | Threaded
Open this post in threaded view
|

Re: Code reorganization in Webwerkstatt - please check your js files

keith1y
In reply to this post by keith1y

What is currently webwerkstatt/kernel could be called this webwerkstatt/base -i.e. "working base" (i.e. equivalent of an unstable branch)

To be released as lively/base (i.e. the equivalent of a stable branch)

this could have:

lively/base/lib
lively/base/kernel (non-optional parts from webwerkstatt/lively)
lively/base/media
lively/base/ometa
lively/base/cop
lively/base/partsBin (optional package that was in webwerkstatt/lively)
lively/base/smalltalk (optional package that was in webwerkstatt/lively)
lively/base/unit-testing (optional package that was in webwerkstatt/lively)
lively/base/ide (optional package that was in webwerkstatt/lively)

Some of the above would be separate projects under scm in their own right so they don't really want to be too deep in the hierarchy as they are at the moment.

Within the  "base" folder "projects", "parts", "users" are disposable folders that probably should not be in there at all and should probably be up a level.

lively/parts  (is bin redundant?)
lively/library (a place for optional packages, e.g. move lively/base/smalltalk to here)
lively/users
lively/projects
lively/server

So... release process might as well distribute all of lively/* and can include at the top level.

lively/start.xhtml

I assume that the lively/start.xhtml defines all the paths as to where everything is.

If I am developing using lively/base I want my code to be in a separate project alongside, so I check out lively.

cd development
bzr checkout --lightweight lp:lively lively-rc4

/development/lively-rc4/* (base/parts/projects/apps/server etc.)

Then I branch my project from my repository.

bzr branch lp:~keithy/deadly

My top file is...

/development/deadly/start.xhtml

And use symbolic links to link the two...

cd deadly
ln -s ../lively-rc4 lively
ln -s ./lively/base base

Thus I can easily share parts bins, or have my own.

ln -s ./lively/parts parts

So now my start.xhtml (a copy of the original lively/start.xhtml) calls up stuff via ./base/kernel/bootstrap.js

I can choose which distribution of lively to use by pointing the symbolic links to the right one.

Users who don't want to use symbolic links (or cannot use them in windows) can wire their start.xhtml directly, with no loss of capability.

=
If at some point you want to switch webwerkstatt to use a stable release, all you have to do is symbolically link webwerkstatt/base to lively/base

regards

Keith





_______________________________________________
lively-kernel mailing list
[hidden email]
http://lists.hpi.uni-potsdam.de/listinfo/lively-kernel
Reply | Threaded
Open this post in threaded view
|

Re: Code reorganization in Webwerkstatt - please check your js files

Lincke, Jens
In reply to this post by Lauritz Thamsen
Hi, Lauritz

I definitely think it should go into the users folder, but since you changed the codebase the users folder are out of reach 
for loading moduless.... so I moved the code into the codebase again.  How should we deal with multiple roots?

Best,
Jens

Am 27.10.2011 um 19:49 schrieb Lauritz Thamsen:

Hi Jens --

Should we require them differently such as we did with the modules from the CodeDB? In the meantime I will move the modules in question below the kernel/ dir.
Kernel is therefore a bad name, because the kernel is under "lively" and we would not call the rest kernel, or would we?
Yes, I agree it shouldn't be 'kernel/', so we will rename it to 'core/' later in the evening (Oct 28, 1 a.m. CEST or Oct 27 4 p.m. Pacific Time). However, I am not sure that "personal modules" should be part of our core distribution. Either such code belongs into apps/, lib/ or into lively/ and should be synched across repositories or it should remain in a user's folder and shouldn't be synched across repositories. What do you think? 

Best,
Lauritz

On Oct 27, 2011, at 2:18 AM, Jens Lincke wrote:

Hi, Lauritz 

works for most pages. How do we deal with non kernel code additions in the wiki. Code in users or project directories such as

Should we require them differently such as we did with the modules from the CodeDB? In the meantime I will move the modules in question below the kernel/ dir.
Kernel is therefore a bad name, because the kernel is under "lively" and we would not call the rest kernel, or would we?

Best,
Jens

On 27.10.2011, at 07:58, Lauritz Thamsen wrote:

Hi.

As announced yesterday, we reorganized Webwerkstatt a bit.

Please let us know if you experience any problems regarding loading or saving.

Best,
Lauritz


On Oct 25, 2011, at 5:10 PM, Fabian Bornhofen wrote:

Hi -

as mentioned earlier, we want to simplify code distribution.
As a first step, we are going to reorganize some files in Webwerkstatt and move the core code from /repository/webwerkstatt to /repository/webwerkstatt/kernel.

To keep your worlds running, we will run a script on all xhtml files in Webwerkstatt that changes the path to bootstrap.js. For most worlds, you will not notice any difference. If you have never written a Lively JavaScript module on your own,   then most probably you do not need take any action.

However, if any of your worlds have dependencies on other js files (e.g. js files in your home folder), please check references to these paths. Config.codeBase will be /repository/webwerkstatt/kernel instead of /repository/webwerkstatt. Paths relative to Config.codeBase therefore should be fixed (typically with another '../' at the beginning).

We want to apply and commit our changes to Webwerkstatt on early Thursday morning (Oct 27, 1 a.m. CEST or Oct 26 4 p.m. Pacific Time).

Please contact Lauritz or me if you have any questions or if you need assistance.

Rationale:
We want to create a repository of the minimum set of files that is needed for running the Lively Kernel. This could be hosted on Github, Launchpad, or elsewhere. By centralizing these files in Webwerkstatt (which is effectively our upstream repository right now), it will be possible to check them out as a Subversion submodule that can be kept in sync with other version control systems.

Regards,
Fabian
_______________________________________________
lively-kernel mailing list
[hidden email]
http://lists.hpi.uni-potsdam.de/listinfo/lively-kernel

_______________________________________________
lively-kernel mailing list
[hidden email]
http://lists.hpi.uni-potsdam.de/listinfo/lively-kernel




_______________________________________________
lively-kernel mailing list
[hidden email]
http://lists.hpi.uni-potsdam.de/listinfo/lively-kernel
Reply | Threaded
Open this post in threaded view
|

Re: Code reorganization in Webwerkstatt - please check your js files

Fabian Bornhofen-2
Hi Jens,

you're right. We are thinking about changing the loader so you can
specify additional module locations. You would have something like

Config.additionalModulePaths[i] = 'users' // path relative to Config.rootPath

and then

module ... .requires('jenslincke.yourPersonalModule') .....

What do you think?
Fabian


On Thu, Oct 27, 2011 at 1:00 PM, Jens Lincke
<[hidden email]> wrote:

> Hi, Lauritz
> I definitely think it should go into the users folder, but since you changed
> the codebase the users folder are out of reach
> for loading moduless.... so I moved the code into the codebase again.  How
> should we deal with multiple roots?
> Best,
> Jens
> Am 27.10.2011 um 19:49 schrieb Lauritz Thamsen:
>
> Hi Jens --
>
> Should we require them differently such as we did with the modules from the
> CodeDB? In the meantime I will move the modules in question below the
> kernel/ dir.
> Kernel is therefore a bad name, because the kernel is under "lively" and we
> would not call the rest kernel, or would we?
>
> Yes, I agree it shouldn't be 'kernel/', so we will rename it to 'core/'
> later in the evening (Oct 28, 1 a.m. CEST or Oct 27 4 p.m. Pacific Time).
> However, I am not sure that "personal modules" should be part of our core
> distribution. Either such code belongs into apps/, lib/ or into lively/ and
> should be synched across repositories or it should remain in a user's folder
> and shouldn't be synched across repositories. What do you think?
> Best,
> Lauritz
> On Oct 27, 2011, at 2:18 AM, Jens Lincke wrote:
>
> Hi, Lauritz
> works for most pages. How do we deal with non kernel code additions in the
> wiki. Code in users or project directories such as
> http://lively-kernel.org/repository/webwerkstatt/projects/BP2012/
> http://lively-kernel.org/repository/webwerkstatt/users/ahold/
> Should we require them differently such as we did with the modules from the
> CodeDB? In the meantime I will move the modules in question below the
> kernel/ dir.
> Kernel is therefore a bad name, because the kernel is under "lively" and we
> would not call the rest kernel, or would we?
> Best,
> Jens
> On 27.10.2011, at 07:58, Lauritz Thamsen wrote:
>
> Hi.
>
> As announced yesterday, we reorganized Webwerkstatt a bit.
>
> Please let us know if you experience any problems regarding loading or
> saving.
>
> Best,
> Lauritz
>
>
> On Oct 25, 2011, at 5:10 PM, Fabian Bornhofen wrote:
>
> Hi -
>
> as mentioned earlier, we want to simplify code distribution.
>
> As a first step, we are going to reorganize some files in Webwerkstatt and
> move the core code from /repository/webwerkstatt to
> /repository/webwerkstatt/kernel.
>
> To keep your worlds running, we will run a script on all xhtml files in
> Webwerkstatt that changes the path to bootstrap.js. For most worlds, you
> will not notice any difference. If you have never written a Lively
> JavaScript module on your own,   then most probably you do not need take any
> action.
>
> However, if any of your worlds have dependencies on other js files (e.g. js
> files in your home folder), please check references to these paths.
> Config.codeBase will be /repository/webwerkstatt/kernel instead of
> /repository/webwerkstatt. Paths relative to Config.codeBase therefore should
> be fixed (typically with another '../' at the beginning).
>
> We want to apply and commit our changes to Webwerkstatt on early Thursday
> morning (Oct 27, 1 a.m. CEST or Oct 26 4 p.m. Pacific Time).
>
> Please contact Lauritz or me if you have any questions or if you need
> assistance.
>
> Rationale:
>
> We want to create a repository of the minimum set of files that is needed
> for running the Lively Kernel. This could be hosted on Github, Launchpad, or
> elsewhere. By centralizing these files in Webwerkstatt (which is effectively
> our upstream repository right now), it will be possible to check them out as
> a Subversion submodule that can be kept in sync with other version control
> systems.
>
> Regards,
>
> Fabian
>
> _______________________________________________
>
> lively-kernel mailing list
>
> [hidden email]
>
> http://lists.hpi.uni-potsdam.de/listinfo/lively-kernel
>
> _______________________________________________
> lively-kernel mailing list
> [hidden email]
> http://lists.hpi.uni-potsdam.de/listinfo/lively-kernel
>
>
>
>
> _______________________________________________
> lively-kernel mailing list
> [hidden email]
> http://lists.hpi.uni-potsdam.de/listinfo/lively-kernel
>
>
_______________________________________________
lively-kernel mailing list
[hidden email]
http://lists.hpi.uni-potsdam.de/listinfo/lively-kernel
Reply | Threaded
Open this post in threaded view
|

Re: Code reorganization in Webwerkstatt - please check your js files

Lincke, Jens
Hi, Fabian --

sounds nice, just like Java classpath, but what about overriding modules? And... the most important of all, how do
we figure out if a module can be loaded in this or that part on the client side? Should we check before every module
load if the module is available under rootA, rootB or rootC? We could use node.js to do it on the server for us...
or another idea:
Don't use additional roots but "link" in other path into our root. We could explicitly register "webwerstatt/users" for the
users prefix... this would also allow us to map non file system based modules from the codeDB into our normal module schema without having to user special chars as codeDB1 did....

Best,
Jens


Am 27.10.2011 um 22:52 schrieb Fabian Bornhofen:

> Hi Jens,
>
> you're right. We are thinking about changing the loader so you can
> specify additional module locations. You would have something like
>
> Config.additionalModulePaths[i] = 'users' // path relative to Config.rootPath
>
> and then
>
> module ... .requires('jenslincke.yourPersonalModule') .....
>
> What do you think?
> Fabian
>
>
> On Thu, Oct 27, 2011 at 1:00 PM, Jens Lincke
> <[hidden email]> wrote:
>> Hi, Lauritz
>> I definitely think it should go into the users folder, but since you changed
>> the codebase the users folder are out of reach
>> for loading moduless.... so I moved the code into the codebase again.  How
>> should we deal with multiple roots?
>> Best,
>> Jens
>> Am 27.10.2011 um 19:49 schrieb Lauritz Thamsen:
>>
>> Hi Jens --
>>
>> Should we require them differently such as we did with the modules from the
>> CodeDB? In the meantime I will move the modules in question below the
>> kernel/ dir.
>> Kernel is therefore a bad name, because the kernel is under "lively" and we
>> would not call the rest kernel, or would we?
>>
>> Yes, I agree it shouldn't be 'kernel/', so we will rename it to 'core/'
>> later in the evening (Oct 28, 1 a.m. CEST or Oct 27 4 p.m. Pacific Time).
>> However, I am not sure that "personal modules" should be part of our core
>> distribution. Either such code belongs into apps/, lib/ or into lively/ and
>> should be synched across repositories or it should remain in a user's folder
>> and shouldn't be synched across repositories. What do you think?
>> Best,
>> Lauritz
>> On Oct 27, 2011, at 2:18 AM, Jens Lincke wrote:
>>
>> Hi, Lauritz
>> works for most pages. How do we deal with non kernel code additions in the
>> wiki. Code in users or project directories such as
>> http://lively-kernel.org/repository/webwerkstatt/projects/BP2012/
>> http://lively-kernel.org/repository/webwerkstatt/users/ahold/
>> Should we require them differently such as we did with the modules from the
>> CodeDB? In the meantime I will move the modules in question below the
>> kernel/ dir.
>> Kernel is therefore a bad name, because the kernel is under "lively" and we
>> would not call the rest kernel, or would we?
>> Best,
>> Jens
>> On 27.10.2011, at 07:58, Lauritz Thamsen wrote:
>>
>> Hi.
>>
>> As announced yesterday, we reorganized Webwerkstatt a bit.
>>
>> Please let us know if you experience any problems regarding loading or
>> saving.
>>
>> Best,
>> Lauritz
>>
>>
>> On Oct 25, 2011, at 5:10 PM, Fabian Bornhofen wrote:
>>
>> Hi -
>>
>> as mentioned earlier, we want to simplify code distribution.
>>
>> As a first step, we are going to reorganize some files in Webwerkstatt and
>> move the core code from /repository/webwerkstatt to
>> /repository/webwerkstatt/kernel.
>>
>> To keep your worlds running, we will run a script on all xhtml files in
>> Webwerkstatt that changes the path to bootstrap.js. For most worlds, you
>> will not notice any difference. If you have never written a Lively
>> JavaScript module on your own,   then most probably you do not need take any
>> action.
>>
>> However, if any of your worlds have dependencies on other js files (e.g. js
>> files in your home folder), please check references to these paths.
>> Config.codeBase will be /repository/webwerkstatt/kernel instead of
>> /repository/webwerkstatt. Paths relative to Config.codeBase therefore should
>> be fixed (typically with another '../' at the beginning).
>>
>> We want to apply and commit our changes to Webwerkstatt on early Thursday
>> morning (Oct 27, 1 a.m. CEST or Oct 26 4 p.m. Pacific Time).
>>
>> Please contact Lauritz or me if you have any questions or if you need
>> assistance.
>>
>> Rationale:
>>
>> We want to create a repository of the minimum set of files that is needed
>> for running the Lively Kernel. This could be hosted on Github, Launchpad, or
>> elsewhere. By centralizing these files in Webwerkstatt (which is effectively
>> our upstream repository right now), it will be possible to check them out as
>> a Subversion submodule that can be kept in sync with other version control
>> systems.
>>
>> Regards,
>>
>> Fabian
>>
>> _______________________________________________
>>
>> lively-kernel mailing list
>>
>> [hidden email]
>>
>> http://lists.hpi.uni-potsdam.de/listinfo/lively-kernel
>>
>> _______________________________________________
>> lively-kernel mailing list
>> [hidden email]
>> http://lists.hpi.uni-potsdam.de/listinfo/lively-kernel
>>
>>
>>
>>
>> _______________________________________________
>> lively-kernel mailing list
>> [hidden email]
>> http://lists.hpi.uni-potsdam.de/listinfo/lively-kernel
>>
>>

_______________________________________________
lively-kernel mailing list
[hidden email]
http://lists.hpi.uni-potsdam.de/listinfo/lively-kernel
Reply | Threaded
Open this post in threaded view
|

Re: Code reorganization in Webwerkstatt - please check your js files

keith1y
It seems ridiculous for me to talk as if I know what I am doing, but I figure you guys will be forgiving...

Its a mad place for me to start learning, reorganising the whole code base as an exercise. From what I have seen so far (which is not a lot)...

I prefer to be able to define an explicit load list, rather than a search path. 
- Search paths can be the source of hard to find bugs. I spent an hour or two yesterday trying to debug an apache conf, when all the time an old file was being picked up in the search path.

I was quite surprised to find that the bootstrap.js was not data driven.

If the bootstrap.js is part of the "corest, kernelist" part of lively, I would expect to see the list of modules would be better pulled out into the start.xhtml somehow. The list could be moved into the Config somewhere. ves sorting out some of decisions that boostrap.js is making i.e. isCanvas. I would even consider putting up two hard coded lists, i.e. CanvasModules and NormalModules. 

I am experimenting with moving the load list call into start.xhtml

Instinctively I am thinking that I would like the load list to be recursive, that modules can specify a list of modules. In which case the top level config would call in the "core" top modules and the "users" top modules. If this was the case, a "canvas" module could only load in submodules if canvas is not present. However, nothing is going to be faster and clearer than an explicit list, so that would be my preference.

regards

Keith



Hi, Fabian --

sounds nice, just like Java classpath, but what about overriding modules? And... the most important of all, how do
we figure out if a module can be loaded in this or that part on the client side? Should we check before every module
load if the module is available under rootA, rootB or rootC? We could use node.js to do it on the server for us...
or another idea:
Don't use additional roots but "link" in other path into our root. We could explicitly register "webwerstatt/users" for the
users prefix... this would also allow us to map non file system based modules from the codeDB into our normal module schema without having to user special chars as codeDB1 did....

Best,
Jens


_______________________________________________
lively-kernel mailing list
[hidden email]
http://lists.hpi.uni-potsdam.de/listinfo/lively-kernel
Reply | Threaded
Open this post in threaded view
|

Re: Code reorganization in Webwerkstatt

keith1y
This is what I came up with so far.


The top level that you are calling "core", I call it "unstable", to become "stable", but is intended to be published as the base release lp:lively

The distribution includes folders with "parts" and "users" (though empty or with a simple examples, a la playgrounds) I also expect to see a "documentation" folder somewhere, though that could be included as a user.

The main codebase, stripped of "parts" and "users", I have called "base".


Within "base", I pulled the config out into "base/config" 

Anything vaguely module like is in "base/modules"  (alt. idea "library")

The main.c startup and core, is in "base/main" (alt. ideas "kernel" - over used now)

Anything looking vaguely as if it is on its way out is in base/OBSOLETE.

In order to enable modules to be distributed as a single directory/checkout

This pattern
ide.js
ide/*.js

is now

ide/+init.js   "the + puts the file nicely at the top of the list"
ide/*.js

And following this style...

Main.js is now ./base/main/+main.js

any thoughts, feedback would be gratefully received... nothing works theres a fair bit of renaming to propagate.

Keith








_______________________________________________
lively-kernel mailing list
[hidden email]
http://lists.hpi.uni-potsdam.de/listinfo/lively-kernel
Reply | Threaded
Open this post in threaded view
|

Re: Code reorganization in Webwerkstatt

keith1y
Darn, kernel disappeared... oops that'll teach me!
Reply | Threaded
Open this post in threaded view
|

Re: Code reorganization in Webwerkstatt

keith1y
And the Lord he doth provide bzr rebase !

> Darn, kernel disappeared... oops that'll teach me!


K.
_______________________________________________
lively-kernel mailing list
[hidden email]
http://lists.hpi.uni-potsdam.de/listinfo/lively-kernel
Reply | Threaded
Open this post in threaded view
|

Re: Code reorganization in Webwerkstatt - please check your js files

Lauritz Thamsen
In reply to this post by Lauritz Thamsen
Yes, I agree it shouldn't be 'kernel/', so we will rename it to 'core/' later in the evening (Oct 28, 1 a.m. CEST or Oct 27 4 p.m. Pacific Time). 

Done.

On Oct 27, 2011, at 10:49 AM, Lauritz Thamsen wrote:

Hi Jens --

Should we require them differently such as we did with the modules from the CodeDB? In the meantime I will move the modules in question below the kernel/ dir.
Kernel is therefore a bad name, because the kernel is under "lively" and we would not call the rest kernel, or would we?
Yes, I agree it shouldn't be 'kernel/', so we will rename it to 'core/' later in the evening (Oct 28, 1 a.m. CEST or Oct 27 4 p.m. Pacific Time). However, I am not sure that "personal modules" should be part of our core distribution. Either such code belongs into apps/, lib/ or into lively/ and should be synched across repositories or it should remain in a user's folder and shouldn't be synched across repositories. What do you think? 

Best,
Lauritz

On Oct 27, 2011, at 2:18 AM, Jens Lincke wrote:

Hi, Lauritz 

works for most pages. How do we deal with non kernel code additions in the wiki. Code in users or project directories such as

Should we require them differently such as we did with the modules from the CodeDB? In the meantime I will move the modules in question below the kernel/ dir.
Kernel is therefore a bad name, because the kernel is under "lively" and we would not call the rest kernel, or would we?

Best,
Jens

On 27.10.2011, at 07:58, Lauritz Thamsen wrote:

Hi.

As announced yesterday, we reorganized Webwerkstatt a bit.

Please let us know if you experience any problems regarding loading or saving.

Best,
Lauritz


On Oct 25, 2011, at 5:10 PM, Fabian Bornhofen wrote:

Hi -

as mentioned earlier, we want to simplify code distribution.
As a first step, we are going to reorganize some files in Webwerkstatt and move the core code from /repository/webwerkstatt to /repository/webwerkstatt/kernel.

To keep your worlds running, we will run a script on all xhtml files in Webwerkstatt that changes the path to bootstrap.js. For most worlds, you will not notice any difference. If you have never written a Lively JavaScript module on your own,   then most probably you do not need take any action.

However, if any of your worlds have dependencies on other js files (e.g. js files in your home folder), please check references to these paths. Config.codeBase will be /repository/webwerkstatt/kernel instead of /repository/webwerkstatt. Paths relative to Config.codeBase therefore should be fixed (typically with another '../' at the beginning).

We want to apply and commit our changes to Webwerkstatt on early Thursday morning (Oct 27, 1 a.m. CEST or Oct 26 4 p.m. Pacific Time).

Please contact Lauritz or me if you have any questions or if you need assistance.

Rationale:
We want to create a repository of the minimum set of files that is needed for running the Lively Kernel. This could be hosted on Github, Launchpad, or elsewhere. By centralizing these files in Webwerkstatt (which is effectively our upstream repository right now), it will be possible to check them out as a Subversion submodule that can be kept in sync with other version control systems.

Regards,
Fabian
_______________________________________________
lively-kernel mailing list
[hidden email]
http://lists.hpi.uni-potsdam.de/listinfo/lively-kernel

_______________________________________________
lively-kernel mailing list
[hidden email]
http://lists.hpi.uni-potsdam.de/listinfo/lively-kernel




_______________________________________________
lively-kernel mailing list
[hidden email]
http://lists.hpi.uni-potsdam.de/listinfo/lively-kernel
Reply | Threaded
Open this post in threaded view
|

Re: Code reorganization in Webwerkstatt - please check your js files

Fabian Bornhofen-2
In reply to this post by Lincke, Jens
Hi Jens,

I just committed a change to the loader. You can now configure
(additional) module paths in bootstrap.js (search for modulePaths). I
admit that there shoule be a nicer way to configure it, though...

Anyway, what happens is that the loader would check if it can get the
module from the core folder. If not, it tries the alternatives. I
added 'users' for Webwerkstatt. You should be able to require user
defined modules with ... require('jenslincke.YourModule'). ...
What you might try to do is create a new module in your users/ folder,
check if that works and if it does, remove the users/ folder from
core/. The only difference is that you need to write
'jenslicke.YourModule' instead of 'users.jenslincke.YourModule'.
Please let us know if there's anything that does not work.

If this is configurable, we might think of alternative load orders, so
you'd be able to have your own Events.js and so on. It'd be cool to
play with that, but it might slow down the loading process (idea:
Config.customModules?).

Keith: What's cool about the recursive load is that in your xhtml
files, you only need to link to bootstrap.js and it takes care of
everything else. If you add references to all core modules to your
worlds, you'd have to manually update these every time we add or
remove a core module. (Well, you should not expect this to happen too
often..) It also makes it easy to build e.g. a facebook app that
displays worlds.
There are a couple of things that eventually should be changed in
bootstrap.js and I like that we're playing with this right now.
That'll help us understand and make the right decisions.

Regards,
Fabian

On Thu, Oct 27, 2011 at 2:00 PM, Jens Lincke
<[hidden email]> wrote:

> Hi, Fabian --
>
> sounds nice, just like Java classpath, but what about overriding modules? And... the most important of all, how do
> we figure out if a module can be loaded in this or that part on the client side? Should we check before every module
> load if the module is available under rootA, rootB or rootC? We could use node.js to do it on the server for us...
> or another idea:
> Don't use additional roots but "link" in other path into our root. We could explicitly register "webwerstatt/users" for the
> users prefix... this would also allow us to map non file system based modules from the codeDB into our normal module schema without having to user special chars as codeDB1 did....
>
> Best,
> Jens
>
>
> Am 27.10.2011 um 22:52 schrieb Fabian Bornhofen:
>
>> Hi Jens,
>>
>> you're right. We are thinking about changing the loader so you can
>> specify additional module locations. You would have something like
>>
>> Config.additionalModulePaths[i] = 'users' // path relative to Config.rootPath
>>
>> and then
>>
>> module ... .requires('jenslincke.yourPersonalModule') .....
>>
>> What do you think?
>> Fabian
>>
>>
>> On Thu, Oct 27, 2011 at 1:00 PM, Jens Lincke
>> <[hidden email]> wrote:
>>> Hi, Lauritz
>>> I definitely think it should go into the users folder, but since you changed
>>> the codebase the users folder are out of reach
>>> for loading moduless.... so I moved the code into the codebase again.  How
>>> should we deal with multiple roots?
>>> Best,
>>> Jens
>>> Am 27.10.2011 um 19:49 schrieb Lauritz Thamsen:
>>>
>>> Hi Jens --
>>>
>>> Should we require them differently such as we did with the modules from the
>>> CodeDB? In the meantime I will move the modules in question below the
>>> kernel/ dir.
>>> Kernel is therefore a bad name, because the kernel is under "lively" and we
>>> would not call the rest kernel, or would we?
>>>
>>> Yes, I agree it shouldn't be 'kernel/', so we will rename it to 'core/'
>>> later in the evening (Oct 28, 1 a.m. CEST or Oct 27 4 p.m. Pacific Time).
>>> However, I am not sure that "personal modules" should be part of our core
>>> distribution. Either such code belongs into apps/, lib/ or into lively/ and
>>> should be synched across repositories or it should remain in a user's folder
>>> and shouldn't be synched across repositories. What do you think?
>>> Best,
>>> Lauritz
>>> On Oct 27, 2011, at 2:18 AM, Jens Lincke wrote:
>>>
>>> Hi, Lauritz
>>> works for most pages. How do we deal with non kernel code additions in the
>>> wiki. Code in users or project directories such as
>>> http://lively-kernel.org/repository/webwerkstatt/projects/BP2012/
>>> http://lively-kernel.org/repository/webwerkstatt/users/ahold/
>>> Should we require them differently such as we did with the modules from the
>>> CodeDB? In the meantime I will move the modules in question below the
>>> kernel/ dir.
>>> Kernel is therefore a bad name, because the kernel is under "lively" and we
>>> would not call the rest kernel, or would we?
>>> Best,
>>> Jens
>>> On 27.10.2011, at 07:58, Lauritz Thamsen wrote:
>>>
>>> Hi.
>>>
>>> As announced yesterday, we reorganized Webwerkstatt a bit.
>>>
>>> Please let us know if you experience any problems regarding loading or
>>> saving.
>>>
>>> Best,
>>> Lauritz
>>>
>>>
>>> On Oct 25, 2011, at 5:10 PM, Fabian Bornhofen wrote:
>>>
>>> Hi -
>>>
>>> as mentioned earlier, we want to simplify code distribution.
>>>
>>> As a first step, we are going to reorganize some files in Webwerkstatt and
>>> move the core code from /repository/webwerkstatt to
>>> /repository/webwerkstatt/kernel.
>>>
>>> To keep your worlds running, we will run a script on all xhtml files in
>>> Webwerkstatt that changes the path to bootstrap.js. For most worlds, you
>>> will not notice any difference. If you have never written a Lively
>>> JavaScript module on your own,   then most probably you do not need take any
>>> action.
>>>
>>> However, if any of your worlds have dependencies on other js files (e.g. js
>>> files in your home folder), please check references to these paths.
>>> Config.codeBase will be /repository/webwerkstatt/kernel instead of
>>> /repository/webwerkstatt. Paths relative to Config.codeBase therefore should
>>> be fixed (typically with another '../' at the beginning).
>>>
>>> We want to apply and commit our changes to Webwerkstatt on early Thursday
>>> morning (Oct 27, 1 a.m. CEST or Oct 26 4 p.m. Pacific Time).
>>>
>>> Please contact Lauritz or me if you have any questions or if you need
>>> assistance.
>>>
>>> Rationale:
>>>
>>> We want to create a repository of the minimum set of files that is needed
>>> for running the Lively Kernel. This could be hosted on Github, Launchpad, or
>>> elsewhere. By centralizing these files in Webwerkstatt (which is effectively
>>> our upstream repository right now), it will be possible to check them out as
>>> a Subversion submodule that can be kept in sync with other version control
>>> systems.
>>>
>>> Regards,
>>>
>>> Fabian
>>>
>>> _______________________________________________
>>>
>>> lively-kernel mailing list
>>>
>>> [hidden email]
>>>
>>> http://lists.hpi.uni-potsdam.de/listinfo/lively-kernel
>>>
>>> _______________________________________________
>>> lively-kernel mailing list
>>> [hidden email]
>>> http://lists.hpi.uni-potsdam.de/listinfo/lively-kernel
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> lively-kernel mailing list
>>> [hidden email]
>>> http://lists.hpi.uni-potsdam.de/listinfo/lively-kernel
>>>
>>>
>
>
_______________________________________________
lively-kernel mailing list
[hidden email]
http://lists.hpi.uni-potsdam.de/listinfo/lively-kernel
Reply | Threaded
Open this post in threaded view
|

Re: Code reorganization in Webwerkstatt - please check your js files

Robert Krahn-4
Hi, Fabian --

you are absolutely right on this, getting rid of specifying manually what code to load had several advantages. On the one hand you can start Lively with little code (=kernel) which allows faster booting. With the combinedModules approach you still only require one request to load the kernel. Even browser caching plays nicely with it (we provide a combinedModuleHash that tells the browser when to reload). This increased the load time of Lively tremendously.

Also the idea of having a more or less continuously running live system works better if you can easily load code on demand and specify requirements. This is exactly what the current module system does.

Best,
Robert


On Oct 27, 2011, at 9:00 PM, Fabian Bornhofen wrote:

> What's cool about the recursive load is that in your xhtml
> files, you only need to link to bootstrap.js and it takes care of
> everything else. If you add references to all core modules to your
> worlds, you'd have to manually update these every time we add or
> remove a core module. (Well, you should not expect this to happen too
> often..) It also makes it easy to build e.g. a facebook app that
> displays worlds.

_______________________________________________
lively-kernel mailing list
[hidden email]
http://lists.hpi.uni-potsdam.de/listinfo/lively-kernel
Reply | Threaded
Open this post in threaded view
|

Re: Code reorganization in Webwerkstatt - please check your js files

Lincke, Jens
In reply to this post by Lauritz Thamsen
Hi, Lauritz

thanks for renaming and moving... why not move it a third time and call it what it is: "CodeBase".
I would also opt for extending this codebase only on a per path basis... e.g. mapping "users.*" to "http://lively-kernel.org/repository/webwerkstatt/users/"
That would make the query if something exists in one codebase or another unnecessary, because we would know before loading where we have to look for everything that begins with "users".

What do you think? What do others think? The possibility to override modules in a wiki and fall back into a base version is also a nice property, but do we need it, since we already have open classes?

Best,
Jens



On 28.10.2011, at 04:51, Thamsen, Lauritz wrote:

Yes, I agree it shouldn't be 'kernel/', so we will rename it to 'core/' later in the evening (Oct 28, 1 a.m. CEST or Oct 27 4 p.m. Pacific Time). 

Done.

On Oct 27, 2011, at 10:49 AM, Lauritz Thamsen wrote:

Hi Jens --

Should we require them differently such as we did with the modules from the CodeDB? In the meantime I will move the modules in question below the kernel/ dir.
Kernel is therefore a bad name, because the kernel is under "lively" and we would not call the rest kernel, or would we?
Yes, I agree it shouldn't be 'kernel/', so we will rename it to 'core/' later in the evening (Oct 28, 1 a.m. CEST or Oct 27 4 p.m. Pacific Time). However, I am not sure that "personal modules" should be part of our core distribution. Either such code belongs into apps/, lib/ or into lively/ and should be synched across repositories or it should remain in a user's folder and shouldn't be synched across repositories. What do you think? 

Best,
Lauritz

On Oct 27, 2011, at 2:18 AM, Jens Lincke wrote:

Hi, Lauritz 

works for most pages. How do we deal with non kernel code additions in the wiki. Code in users or project directories such as

Should we require them differently such as we did with the modules from the CodeDB? In the meantime I will move the modules in question below the kernel/ dir.
Kernel is therefore a bad name, because the kernel is under "lively" and we would not call the rest kernel, or would we?

Best,
Jens

On 27.10.2011, at 07:58, Lauritz Thamsen wrote:

Hi.

As announced yesterday, we reorganized Webwerkstatt a bit.

Please let us know if you experience any problems regarding loading or saving.

Best,
Lauritz


On Oct 25, 2011, at 5:10 PM, Fabian Bornhofen wrote:

Hi -

as mentioned earlier, we want to simplify code distribution.
As a first step, we are going to reorganize some files in Webwerkstatt and move the core code from /repository/webwerkstatt to /repository/webwerkstatt/kernel.

To keep your worlds running, we will run a script on all xhtml files in Webwerkstatt that changes the path to bootstrap.js. For most worlds, you will not notice any difference. If you have never written a Lively JavaScript module on your own,   then most probably you do not need take any action.

However, if any of your worlds have dependencies on other js files (e.g. js files in your home folder), please check references to these paths. Config.codeBase will be /repository/webwerkstatt/kernel instead of /repository/webwerkstatt. Paths relative to Config.codeBase therefore should be fixed (typically with another '../' at the beginning).

We want to apply and commit our changes to Webwerkstatt on early Thursday morning (Oct 27, 1 a.m. CEST or Oct 26 4 p.m. Pacific Time).

Please contact Lauritz or me if you have any questions or if you need assistance.

Rationale:
We want to create a repository of the minimum set of files that is needed for running the Lively Kernel. This could be hosted on Github, Launchpad, or elsewhere. By centralizing these files in Webwerkstatt (which is effectively our upstream repository right now), it will be possible to check them out as a Subversion submodule that can be kept in sync with other version control systems.

Regards,
Fabian
_______________________________________________
lively-kernel mailing list
[hidden email]
http://lists.hpi.uni-potsdam.de/listinfo/lively-kernel

_______________________________________________
lively-kernel mailing list
[hidden email]
http://lists.hpi.uni-potsdam.de/listinfo/lively-kernel



_______________________________________________
lively-kernel mailing list
[hidden email]
http://lists.hpi.uni-potsdam.de/listinfo/lively-kernel


_______________________________________________
lively-kernel mailing list
[hidden email]
http://lists.hpi.uni-potsdam.de/listinfo/lively-kernel
Reply | Threaded
Open this post in threaded view
|

Re: Code reorganization in Webwerkstatt - please check your js files

Roeder, Marko
Hi, all -

To be honest, I liked it the way it was before all of the changes ;-). It seems like we changed a lot in the last couple of days and some of those decisions appear to me as if they only had to be done because previous changes introduced new challenges and problems :-/.

I absolutely agree with Robert's statement, the (old) bootstap.js did/does a good job for loading modules and initializing the kernel. I therefor strongly opt for keeping the bootstap.js the only file that has to be included in the head of a world/xhtml-file and maybe following Keith idea of extracting the files to be load (to the head of the file or somewhere else).

Furthermore I had a problem with moving the "kernel" to kernel/core/CodeBase/... from the beginning because I could see that what the "codebase"/root was before (e.g. .../webwerkstatt/) does not include all the additional folders referencing modules, etc. (e.g. users, projects, ...).
I do not think that it is hard to extract the core files (for a release, a clean installation, a new project, ...) and we have done that preparing release zips, dumps, etc. So why not keep all those files in the (tree) structure we have had so far?
In addition to that I do not (yet) see what all the openness to several VCS will bring for the project, in other words: Why does LK suddenly have to not only "run" with SVN but with GIT, Bazar, and so on? Still the decision to use SVN was not only about the version control system to use but a deep technical decision that influenced a lot of the LK architecture. And to be honest, do you know one (or more) projects that do have/maintain/use more than one VCS?

So, these are my thoughts and I know, we are all working towards a good and practical way to do releases and how we can sync different branches/projects/installations that are based on Lively's "kernel". But maybe we should step back for a moment and look at what we have and what might be a reasonable, small step (or two, or three, ...) to reach this goal!

As always, questions, opinions and feedback are more than welcome...

        - Marko
_______________________________________________
lively-kernel mailing list
[hidden email]
http://lists.hpi.uni-potsdam.de/listinfo/lively-kernel
Reply | Threaded
Open this post in threaded view
|

Re: Code reorganization in Webwerkstatt - please check your js files

keith1y
> Still the decision to use SVN was not only about the version control system to use but a deep technical decision that influenced a lot of the LK architecture. And to be honest, do you know one (or more) projects that do have/maintain/use more than one VCS?

No but their users frequently do.

SVN, centralised,  and because its there, it works very well for the wiki.

GIT, distributed, because its cool.

Bazaar because its what I like to use, even for squeak images, a personal preference really. I have interoperability with both the other options.

There is a lot of interoperability between the three, no one really need to worry about it. I tried all three a year or so ago, imho the weak point of git is github. The strong point of bazaar is launchpad.

As long as the project maintainers, maintain some sanity, forgive the rest of us for going a bit mad.

However I do think the reorganisation needs to take into account the development process. I want to check out the codebase, and keep current with it, and be able to work on my own code in a separate project. If I have that I will be happy.

Keith
_______________________________________________
lively-kernel mailing list
[hidden email]
http://lists.hpi.uni-potsdam.de/listinfo/lively-kernel
12