Code reorganization in Webwerkstatt - please check your js files
Locked
12
12
Code reorganization in Webwerkstatt - please check your js files
 
|
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 |
Re: Code reorganization in Webwerkstatt - please check your js files
|
|
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 |
|
|
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 |
Re: Code reorganization in Webwerkstatt - please check your js files
|
|
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:
_______________________________________________ lively-kernel mailing list [hidden email] http://lists.hpi.uni-potsdam.de/listinfo/lively-kernel |
|
|
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 |
Re: Code reorganization in Webwerkstatt - please check your js files
|
|
In reply to this post by Lincke, Jens
Hi Jens --
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:
_______________________________________________ lively-kernel mailing list [hidden email] http://lists.hpi.uni-potsdam.de/listinfo/lively-kernel |
|
|
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 |
Re: Code reorganization in Webwerkstatt - please check your js files
|
|
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:
_______________________________________________ lively-kernel mailing list [hidden email] http://lists.hpi.uni-potsdam.de/listinfo/lively-kernel |
Re: Code reorganization in Webwerkstatt - please check your js files
|
|
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 |
Re: Code reorganization in Webwerkstatt - please check your js files
|
|
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 |
|
|
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
_______________________________________________ lively-kernel mailing list [hidden email] http://lists.hpi.uni-potsdam.de/listinfo/lively-kernel |
|
|
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 |
|
|
Darn, kernel disappeared... oops that'll teach me!
|
|
|
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 |
Re: Code reorganization in Webwerkstatt - please check your js files
|
|
In reply to this post by Lauritz Thamsen
Done. On Oct 27, 2011, at 10:49 AM, Lauritz Thamsen wrote:
_______________________________________________ lively-kernel mailing list [hidden email] http://lists.hpi.uni-potsdam.de/listinfo/lively-kernel |
Re: Code reorganization in Webwerkstatt - please check your js files
|
|
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 |
Re: Code reorganization in Webwerkstatt - please check your js files
|
|
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 |
Re: Code reorganization in Webwerkstatt - please check your js files
|
|
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:
_______________________________________________ lively-kernel mailing list [hidden email] http://lists.hpi.uni-potsdam.de/listinfo/lively-kernel |
Re: Code reorganization in Webwerkstatt - please check your js files
|
|
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 |
|
|
> 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 |
«
Return to Lively Kernel
|
1 view|%1 views
| Free forum by Nabble | Edit this page |