Code reorganization in Webwerkstatt - please check your js files
Locked
12
12
Re: Code reorganization in Webwerkstatt - please check your js files
 
|
Hi Marko,
great to hear from you! On Fri, Oct 28, 2011 at 6:54 AM, Roeder, Marko <[hidden email]> wrote: > 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 :-/. We're not afraid of changes, are we ;). > 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? I maintain a (acually a few) local installations of LK. It's a real pain to keep these in sync with Webwerkstatt if you want to avoid a complete checkout of webwerkstatt. You could check out /lively/, /lib/, .. as separate modules, but not single files. Moving the core parts to a single subfolder allows you to check them out as a submodule and just type "svn up" in a single location. > 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? Webwerkstatt still uses SVN and I think this should be our upstream repository. After all, this is where most of the development happens. If we have mirrors for the core, that's a nice side effect. On the long term, however, I think it's a good idea to have a VCS that allows us to do atomic commits, especially with a growing user base. To me, this is second (besides not being distributed) major drawback of mod_dav_svn with autoversioning. You sure can do atomic commits with SVN if you develop locally and then push everything back using command line svn. And then again, that only works if the core (pretty much the only place where this is REALLY important) is in a single svn module. > 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! It really looks like a lot of people have put a lot of thinking into these things lately, which is good. 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 Fabian ;-) -
Looking at what your problem seems to be and "asking Google", there are two very nice solutions I could find: 1) SVN Sparse Directories (http://svnbook.red-bean.com/en/1.5/svn-book.html#svn.advanced.sparsedirs) To reproduce what is inside the "core" directory right now do: svn checkout http://www.lively-kernel.org/repository/webwerkstatt2011 webwerkstatt-core --depth empty cd webwerkstatt-core svn update --depth infinity PartsBin Tests apps cop lib lively media ometa server users blank.xhtml webwerkstatt.xhtml Now you can work on things without checking everything out and being free to do "svn up" to get the latest core changes! SVN will be smart enough to remember your depth settings for every directory. Note: I have used webwerkstatt2011 only to have the old folder structure ;o). 2) SVN External Definitions I created a "virtual" tag using those external definitions that fetch externals from WebWerkstatt core: You can see the configuration after checking it out and by doing an "svn propget svn:externals". Because it is non-revisioned and virtual it will include all commits to the WebWerkstatt core files. Using this feature we can also have a "stable-LK2" with hand-selected revisions that make the stable version (changeable over time). Note: You will not see anything browsing to this directory (as mod_dav_svn does not show externals). You have to check it out!
I have heard that there is something better coming... (soon) ;-) Cheers, - Marko _______________________________________________ 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
|
|
On Oct 28, 2011, at 18:53 , Roeder, Marko wrote:
Oh, btw. more about SVN External Definitions, see: http://svnbook.red-bean.com/en/1.5/svn.advanced.externals.html _______________________________________________ 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 Roeder, Marko
Hey,
honestly.. I think that especially the last link you posted in the other mail just stresses that SVN is overcomplicated for what it does. We put the things that everybody to an extra folder and we're happy to help everyone fix their modules if needed. And then, as mentioned before, there were (are) a few things in LK that made (make) unnecessary assumptions about the environment they run in (e.g. DocLinkConverter ...). I think this is a great opportunity to fix this. On Fri, Oct 28, 2011 at 9:53 AM, Roeder, Marko <[hidden email]> wrote: > I have heard that there is something better coming... (soon) ;-) I am soooooooo looking forward to CodeDB. [I was writing a lot of text here, but then decided to better open a new thread about CodeDB] Cheers, f _______________________________________________ lively-kernel mailing list [hidden email] http://lists.hpi.uni-potsdam.de/listinfo/lively-kernel |
|
|
Hi Guys,
In my trawling around the "codebase", I flagged up the following files as obsolete or on their way out (in an ideal world). Core.js NewMorphicCompat.js OldModel.js Migration.js NoMoreModels.js bindings.js Can anyone tell me if I am right or wrong in my assessment? thanks Keith _______________________________________________ lively-kernel mailing list [hidden email] http://lists.hpi.uni-potsdam.de/listinfo/lively-kernel |
|
|
I am writing a little utility, it looks for all file paths referenced in the "codebase", and looks to see where those files are now. The plan is to enable re-writing.
A couple of questions arising: I cant find any references to Main.js am I missing something obvious? I assume it is a testing thing because it loads other testing things. Trivial: There is a reference to media/nocursor.gif in the comments of localconfig.js but no file "in" the codebase. Can't seem to find... In: lively/bootstrap.js UNREACHABLE lively/OldBase.js UNREACHABLE lively/scene.js UNREACHABLE lively/Text.js UNREACHABLE lively/Storage.js UNREACHABLE lively/Tools.js UNREACHABLE lively/EmuDom.js UNREACHABLE lively/CanvasExptCoreFixes.js UNREACHABLE lively/CanvasExpt.js UNREACHABLE generated/combinedModules.js In: lively/Main.js UNREACHABLE Tests/FabrikTest.js cheers 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
|
|
Hi Keith -
it is important to notice that LK should still be able to display in different rendering environments. When I started hacking LK, we already had the new HTML-based system. However, HTML canvas and SVG have never been abandoned. Bootstrap.js still checks what a world wants to be rendered on. As for combinedModules, that is only supported in Webwerkstatt and I think that's one of the points where we are still cleaning up (i.e. it should be disabled at the Moment). I think it makes sense to speed up loading. Setup of combinedModules.js is non-trivial, though. There are SVN post-commit hooks in the Webwerkstatt server that regenerate this file every time a standard module has changed. I didn't know that until Robert told me last week, thanks again :). About the other files, I don't know. I understand that most HTML text support now lives in TextCore.js and I'm not sure how that relates to Text.js, for instance. It's valuable that you're looking at these things. Best, Fabian On Sat, Oct 29, 2011 at 1:33 AM, Keith P. Hodges <[hidden email]> wrote: > I am writing a little utility, it looks for all file paths referenced in the "codebase", and looks to see where those files are now. The plan is to enable re-writing. > > A couple of questions arising: > > I cant find any references to Main.js am I missing something obvious? I assume it is a testing thing because it loads other testing things. > > Trivial: There is a reference to media/nocursor.gif in the comments of localconfig.js but no file "in" the codebase. > > Can't seem to find... > > In: lively/bootstrap.js > UNREACHABLE lively/OldBase.js > UNREACHABLE lively/scene.js > UNREACHABLE lively/Text.js > UNREACHABLE lively/Storage.js > UNREACHABLE lively/Tools.js > UNREACHABLE lively/EmuDom.js > UNREACHABLE lively/CanvasExptCoreFixes.js > UNREACHABLE lively/CanvasExpt.js > UNREACHABLE generated/combinedModules.js > In: lively/Main.js > UNREACHABLE Tests/FabrikTest.js > > cheers > > Keith > > > > _______________________________________________ > 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 |
|
|
I started a little project of my own, my first "product" is a utility for scanning the lively codebase (written in ruby)
To download: bzr branch lp:~livelytalkers/lively/codebase-utils/ or there is a zip file available for download at: https://launchpad.net/lively ========== Scans all files below the "target" with the defined objective , [ output in yaml ] modules - looks for module( X ) requires - looks for requires( X, Y , Z ) reqs - looks for reqs = [ X, Y, Z ] fix - loos for // FIX url - looks for urls ========== if anyone has any other suggestions that would be useful just let me know. enjoy Keith Usage eaxmples: = #> ./scan-refs.rb --target ../../webwerkstatt-core/lively --modules --yaml --- ../../webwerkstatt-core/lively/NewMorphicCompat.js: - lively.NewMorphicCompat - lively.morphic ../../webwerkstatt-core/lively/morphic/tests/Morphic2.js: - lively.morphic.tests.Morphic2 ../../webwerkstatt-core/lively/AST/Parser.js: - lively.AST.Parser ../../webwerkstatt-core/lively/bindings/Core.js: - lively.bindings.Core etc etc... ./scan-refs.rb --target ../../webwerkstatt-core/lively --requires --yaml --- ../../webwerkstatt-core/lively/AST/Parser.js: - lively.Ometa - lively.AST.generated.Translator - lively.AST.generated.Nodes - lively.AST.Interpreter - lively.AST.LivelyJSParser ../../webwerkstatt-core/lively/morphic/Rendering.js: - lively.morphic.Core - lively.morphic.TextCore - lively.morphic.Shapes ./scan-refs.rb --target ../../webwerkstatt-core/lively --reqs --yaml --- ../../webwerkstatt-core/lively/NewMorphicCompat.js: - lively.Core ../../webwerkstatt-core/lively/persistence/StandAlonePackaging.js: - lively.PartsBin ../../webwerkstatt-core/lively/ide/VersionTools.js: - lively.Widgets etc etc... _______________________________________________ lively-kernel mailing list [hidden email] http://lists.hpi.uni-potsdam.de/listinfo/lively-kernel |
|
|
FYI scan-ref options
Options: --target, -t <s>: Set target directory (default: .) --files, -f <s>: File match pattern (default: *.js) --paths, -p: Find path strings --modules, -m: Find module( declarations --requires, -r: Find requires( declarations --reqs, -e: Find reqs = declarations --url, -u: Find urls --fix, -i: Find FIX's --comments, -c <s>: Find comments matching --grep, -g <s>: Lines matching --debug, -d: Debug --yaml, -y: output in yaml --help, -h: Show this message _______________________________________________ lively-kernel mailing list [hidden email] http://lists.hpi.uni-potsdam.de/listinfo/lively-kernel |
|
|
In reply to this post by keith1y
Hi Keith -
> I started a little project of my own, my first "product" is a utility for scanning the lively codebase (written in ruby) > > [...] > > if anyone has any other suggestions that would be useful just let me know. Thanks for showing some much interest in Lively! It is great to see some activity going on on this list and I really agree with most of your ideas. Now, regarding your tool: I know that Ruby is a very nice language to write simple and powerful scripts and I think your script is doing a great job ;-). However Javascript is a very nice (script) language too and as the rest of the system is written in Javascript, why not having such a valuable tool written in Javascript/Lively Kernel too? So my suggestion is (re)writing this tool using Javascript - if it has to be a command line script use Node.JS (which is what we use for server-side/command line scripts). But even nicer would be a part for the parts bin that does exactly this! Look at the parts bin category "Wiki" or "Tools", there are already some nice tools like the Commit Counter, the "What did I do" widget or the "Method Finder". Some of those are using our "file api" to access metadata or search inside/browse the source code. So what do you think? Best, - Marko _______________________________________________ lively-kernel mailing list [hidden email] http://lists.hpi.uni-potsdam.de/listinfo/lively-kernel |
|
|
In reply to this post by keith1y
> FYI scan-ref options
> > Options: > --target, -t <s>: Set target directory (default: .) > --files, -f <s>: File match pattern (default: *.js) > --paths, -p: Find path strings > --modules, -m: Find module( declarations > --requires, -r: Find requires( declarations > --reqs, -e: Find reqs = declarations > --url, -u: Find urls > --fix, -i: Find FIX's > --comments, -c <s>: Find comments matching > --grep, -g <s>: Lines matching > --debug, -d: Debug > --yaml, -y: output in yaml > --help, -h: Show this message What about an "--todo" or "--debugger"? ;-) --todo, like --fix, should look for TODO comments while --debugger is looking for debugger-statements that are scattered all over the source code because somebody was debugging something and forgot to remove those statements. - Marko _______________________________________________ lively-kernel mailing list [hidden email] http://lists.hpi.uni-potsdam.de/listinfo/lively-kernel |
|
|
In reply to this post by Roeder, Marko
Hi Marko,
This is a loop I have been through a few times. In the beginning I wrote a build tool for Squeak in ruby. The reason I used ruby was a brilliant little library for accessing and processing files called "Rio". People suggested I try again in squeak, so, no choice but to re-implement Rio in squeak, which I did. It was good fun, especially because some of Squeaks file/directory handling was so horrible. I was very pleased with Rio because it provides the most versatile files interface that squeak has. It "actually" got some users. BUT it was a fair bit of effort. Right now I am at the stage of "Do the simplest thing that would possibly work", an XP principle, getting onto the learning curve, testing the principles. Keith p.s. The plan is to use unix pipes between tools to do something cool. No doubt, using Lively and Connections would be cooler. > Hi Keith - > >> I started a little project of my own, my first "product" is a utility for scanning the lively codebase (written in ruby) >> > >> [...] > >> >> if anyone has any other suggestions that would be useful just let me know. > > Thanks for showing some much interest in Lively! It is great to see some activity going on on this list and I really agree with most of your ideas. > > Now, regarding your tool: > I know that Ruby is a very nice language to write simple and powerful scripts and I think your script is doing a great job ;-). > However Javascript is a very nice (script) language too and as the rest of the system is written in Javascript, why not having such a valuable tool written in Javascript/Lively Kernel too? > So my suggestion is (re)writing this tool using Javascript - if it has to be a command line script use Node.JS (which is what we use for server-side/command line scripts). But even nicer would be a part for the parts bin that does exactly this! > Look at the parts bin category "Wiki" or "Tools", there are already some nice tools like the Commit Counter, the "What did I do" widget or the "Method Finder". Some of those are using our "file api" to access metadata or search inside/browse the source code. So what do you think? > > Best, > > - Marko _______________________________________________ lively-kernel mailing list [hidden email] http://lists.hpi.uni-potsdam.de/listinfo/lively-kernel |
|
|
Don't know how practically useful this is yet. cd repo/codebase ../../utils/reorg/scan --modules | ../../utils/reorg/correct-modules | ../../utils/reorg/apply --global What it does: A: scan the codebase for files with module definitions example portion of output: core/AST/generated/Translator.js: - - "'lively.AST.generated.Translator'" modules/morphic/ObjectMigration.js: - - "'lively.morphic.ObjectMigration'" B: for each module name, check what it thinks the correct module name should be based upon the filename core/AST/generated/Translator.js: - - "'lively.AST.generated.Translator'" - "'core.AST.generated.Translator'" modules/morphic/ObjectMigration.js: - - "'lively.morphic.ObjectMigration'" - "'modules.morphic.ObjectMigration'" C: Apply each of the above as a find/replace globally to the whole codebase. In theory this allows us to do one of two things, either: A, automatically mess up the codebase completely! Or B, to reorganise modules and files at will, using this method to fix things up. Due to class naming conventions I don't think we are at B yet, but we might be getting there. Keith === p.s. in the meantime, it has shown up four modules which appear to be misnamed in webwerkstatt lively/morphic/HTML.js: - - "'apps.Base64'" lively/persistence/Serializer.js: - - "'cop.Layers'" cop/Layers.js: - - "'cop.Flatten'" Tests/testRessources/combinedFooBar.js: - - "'Tests.testRessources.Foo'" - "'Tests.testRessources.combinedFooBar'" - - "'Tests.testRessources.Bar'" apps/DiffMatchPatch.js: - - "'lib.diff_match_patch.diff_match_patch_uncompressed'" ometa/bs-ometa-compiler.js: - - "'ometa/bs-ometa-compiler.js'" - "'ometa.bs-ometa-compiler'" lively/morphic/Widgets.js: - - "'lively.ide'" lively/NewMorphicCompat.js: - - "'lively.morphic'" lively/morphic/Events.js: - - "'lively.morphic.ClickOnLineHack'" - - "'lively.morphic.EventExperiments'" lively/morphic/Connectors.js: - - "'lively.LayerableMorphs'" lib/splitterjsobj/splitter_v1_2_0.js: - - "'splitterjsobj.splitter_v1_2_0'" - "'lib.splitterjsobj.splitter_v1_2_0'" Tests/lively/morphic/video/VideoTest.js: - - "'lively.morphic.video.VideoTest'" - "'Tests.lively.morphic.video.VideoTest'" Tests/ToolsTests.js: - - "'dummySource'" - - "'bla.blupf'" - - "'lively.Examples'" _______________________________________________ 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 -
On Fri, Oct 28, 2011 at 5:52 AM, Jens Lincke <[hidden email]> wrote: > 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". Implemented. Paths can be specified in the Config object of a world (Config.modulePaths). Defaults are users/ and projects/ (to be found in bootstrap.js). That means that modules with names starting with 'users.' or 'projects.' will be found. There's no probing any more, no 404s, just plain loading. Please let me know if anything breaks because of that. Best, 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, Fabian
thanks for implement the paths so that there is no searching any more. Currently you implemented it as a list: Config.modulePaths // [users/, projects/]
but I thought more of it like a mapping: Config.modulePaths // { users: "../users",
projects: "../projects", What do you think? Best, Jens On 02.11.2011, at 23:51, Fabian Bornhofen 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
|
|
That would probably work and make everything related to module lookup
more explicit. Do you have any immediate use cases? (I'm inclined to first fix the SCB regression introduced by the current solution :) ). Best, Fabian On Thu, Nov 3, 2011 at 9:11 AM, Jens Lincke <[hidden email]> wrote: > Hi, Fabian > thanks for implement the paths so that there is no searching any more. > Currently you implemented it as a list: > Config.modulePaths // [users/, projects/] > > but I thought more of it like a mapping: > Config.modulePaths // { > users: "../users", projects: "../projects", > externlsite: "http://externlsite/path/to/repos", codeDB: > "http://couchdb.lively...."} > > What do you think? > Best, > Jens > On 02.11.2011, at 23:51, Fabian Bornhofen wrote: > > Hi Jens - > > On Fri, Oct 28, 2011 at 5:52 AM, Jens Lincke > <[hidden email]> wrote: > > 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". > > Implemented. Paths can be specified in the Config object of a world > (Config.modulePaths). > Defaults are users/ and projects/ (to be found in bootstrap.js). That > means that modules with names starting with 'users.' or 'projects.' > will be found. There's no probing any more, no 404s, just plain > loading. > > Please let me know if anything breaks because of that. > > Best, > 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
|
|
Jens just "deployed" a solution for the SCB that is using the list implementation :-). So it should work now - as long as it is a list (he just told me that it can only work with a list, not an object).
So I guess his question was more a "what do you think" than "go and implement" :-p - Marko On Nov 3, 2011, at 17:27 , Fabian Bornhofen wrote: > That would probably work and make everything related to module lookup > more explicit. > Do you have any immediate use cases? (I'm inclined to first fix the > SCB regression introduced by the current solution :) ). > > Best, > Fabian > > > On Thu, Nov 3, 2011 at 9:11 AM, Jens Lincke > <[hidden email]> wrote: >> Hi, Fabian >> thanks for implement the paths so that there is no searching any more. >> Currently you implemented it as a list: >> Config.modulePaths // [users/, projects/] >> >> but I thought more of it like a mapping: >> Config.modulePaths // { >> users: "../users", projects: "../projects", >> externlsite: "http://externlsite/path/to/repos", codeDB: >> "http://couchdb.lively...."} >> >> What do you think? >> Best, >> Jens >> On 02.11.2011, at 23:51, Fabian Bornhofen wrote: >> >> Hi Jens - >> >> On Fri, Oct 28, 2011 at 5:52 AM, Jens Lincke >> <[hidden email]> wrote: >> >> 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". >> >> Implemented. Paths can be specified in the Config object of a world >> (Config.modulePaths). >> Defaults are users/ and projects/ (to be found in bootstrap.js). That >> means that modules with names starting with 'users.' or 'projects.' >> will be found. There's no probing any more, no 404s, just plain >> loading. >> >> Please let me know if anything breaks because of that. >> >> Best, >> 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 |
Re: Code reorganization in Webwerkstatt - please check your js files
|
|
:p ok first of all, thanks Jens for fixing that.
So there are two ways of thinking about that idea. First, if we do it, we have to be careful that we're not exaggerating the whole configuration thing.. I don't want Lively config to look like apache.conf or some Java stuff. On the other hand, it could be very useful as long as we still need to map (a) module names to files and (b) files to module names. Case (a) is easy, (b) always tends to be a mess. I think Jens' idea would simplify at least that. But then again, the only real solution is to nail files. Oh and about "go and implement"... I like prototyping ;) Cheers, Fabian On Thu, Nov 3, 2011 at 9:39 AM, Roeder, Marko <[hidden email]> wrote: > Jens just "deployed" a solution for the SCB that is using the list implementation :-). So it should work now - as long as it is a list (he just told me that it can only work with a list, not an object). > So I guess his question was more a "what do you think" than "go and implement" :-p > > - Marko > > > On Nov 3, 2011, at 17:27 , Fabian Bornhofen wrote: > >> That would probably work and make everything related to module lookup >> more explicit. >> Do you have any immediate use cases? (I'm inclined to first fix the >> SCB regression introduced by the current solution :) ). >> >> Best, >> Fabian >> >> >> On Thu, Nov 3, 2011 at 9:11 AM, Jens Lincke >> <[hidden email]> wrote: >>> Hi, Fabian >>> thanks for implement the paths so that there is no searching any more. >>> Currently you implemented it as a list: >>> Config.modulePaths // [users/, projects/] >>> >>> but I thought more of it like a mapping: >>> Config.modulePaths // { >>> users: "../users", projects: "../projects", >>> externlsite: "http://externlsite/path/to/repos", codeDB: >>> "http://couchdb.lively...."} >>> >>> What do you think? >>> Best, >>> Jens >>> On 02.11.2011, at 23:51, Fabian Bornhofen wrote: >>> >>> Hi Jens - >>> >>> On Fri, Oct 28, 2011 at 5:52 AM, Jens Lincke >>> <[hidden email]> wrote: >>> >>> 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". >>> >>> Implemented. Paths can be specified in the Config object of a world >>> (Config.modulePaths). >>> Defaults are users/ and projects/ (to be found in bootstrap.js). That >>> means that modules with names starting with 'users.' or 'projects.' >>> will be found. There's no probing any more, no 404s, just plain >>> loading. >>> >>> Please let me know if anything breaks because of that. >>> >>> Best, >>> 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 |
«
Return to Lively Kernel
|
1 view|%1 views
| Free forum by Nabble | Edit this page |