Re: [Opensim-dev] proposal: cleanup and break up region modules
Tleiades wrote: >> I'd be much more of a fan of having each module a seperate dll. Files >> are cheap too. :) And that makes it very clear to people what they are >> loading, and what they aren't loading. >> > > (On the fear of talking about performance prematurely) > Won't that cause problems for the JIT'er? > > Normally access to member variables gets optimized away into a direct > memory access rather than invocation of a JSR. If I recall correctly > this optimization does not work for dynamically loaded assemblies. well, if that's the case, then it's not working currently either :-) currently we lump all region modules into one large super DLL and load that dynamically. -- dr dirk husemann virtual worlds research ibm zurich research lab SL: dr scofield drscofi...@xyzzyxyzzy.net http://xyzzyxyzzy.net/ RL: h...@zurich.ibm.com - +41 44 724 8573 - http://www.zurich.ibm.com/~hud/ ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] proposal: cleanup and break up region modules
> I'd be much more of a fan of having each module a seperate dll. Files > are cheap too. :) And that makes it very clear to people what they are > loading, and what they aren't loading. > (On the fear of talking about performance prematurely) Won't that cause problems for the JIT'er? Normally access to member variables gets optimized away into a direct memory access rather than invocation of a JSR. If I recall correctly this optimization does not work for dynamically loaded assemblies. ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
[Opensim-dev] AssetBase and metadata
Hi, In Cable Beach all asset information is split over two datatypes: - the Metadata class[1] - a byte array containing the actual asset data In OpenSim we have the AssetBase class[2] which contains asset metadata and data together. I'd like to modify the AssetBase class in OpenSim so it's composed of one Metadata class. So instead of having: AssetBase ab = new AssetBase(); ab.Name = "some name"; ab.Description = "some description"; I would write: AssetBase ab = new AssetBase(); ab.Metadata.Name = "some name"; ab.Metadata.Description = "some description"; I would define the Metadata class in AssetBase.cs. The serialization and deserialization methods currently in the Metadata class may or may not be included; I see those methods belonging in the Utils class[3], perhaps. The Metadata class itself will immediately be used within the new asset server, and I can see it being useful elsewhere in the future. Should the Metadata class be renamed to AssetMetadata? Any other thoughts? Thanks, Mike [1] http://forge.opensimulator.org/gf/project/assetserver/scmsvn/?action=browse&path=%2Ftrunk%2FAssetServer%2FMetadata.cs&view=markup [2] http://opensimulator.org/cgi-bin/viewcvs.cgi/trunk/OpenSim/Framework/AssetBase.cs?view=markup [3] http://forge.opensimulator.org/gf/project/assetserver/scmsvn/?action=browse&path=%2Ftrunk%2FAssetServer%2FUtils.cs&view=markup ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] proposal: cleanup and break up region modules
Justin Clark-Casey wrote: > Dr Scofield wrote: >> Justin Clark-Casey wrote: >>> Dr Scofield wrote: i've been looking at where region modules live in our source tree --- OpenSim/Region/Modules and OpenSim/Region/Environment/Modules --- and how they get bundled: * modules in OpenSim/Region/Modules get their own private DLL * OpenSim/Region/Environment/Modules get lumped into ONE gigantic DLL off the 3 modules living in OpenSim/Region/Modules 2 might be good candidate for forge project: python and SvnSerializer. the third really belongs to the Terrain region module and seems to contain the default terrain effects. i think it would make sense to * have all region modules living in the same neighborhood (i'd prefer OpenSim/Region/Modules), the current layout is a bit confusing >>> Don't we need to make a distinction between 'service' modules (such as the >>> REST module) and scene/environment modules >>> though? The former are not attached to a scene (and may well never be >>> concerned with scene code) while the latter are >>> very much scene related. >> that would be another step. first i'd like to get the modules settled in the >> same neighborhood. >> * break up the region module super-DLL so that each region module gets a DLL of its own >>> At least on mono, I'm guessing that this would vastly expand build times. >>> Certainly at the moment, each invocation of >>> mono to build a new assembly appears to take far longer than building many >>> files in a single dll. >> vastly? > > Maybe this is a slight exaggeration but I'm anticipating that the build time > would be much longer. I'm happy to be > proved wrong on this point. Maybe this seems a minor thing but long build > times are such a pain in the ass. It may add a bit of time, but I don't think it would be much. If going after build times is a goal, I think that's probably a seperate topic. Nant (like ant) does a lot of dumb things that waste time. >>> I also tend to think of the current modules in >>> OpenSim/Region/Environment/Modules as fairly core modules that one would >>> expect to be packaged together, and which it would be inconvenient to split >>> up. >> hmm...that kind of goes against the idea of them being modules, i'd think :-) >> >> > > Does it? Isn't this just a convenient way of packaging the core modules that > almost everybody is going to need to run > their OpenSim (though I would admit that some of the modules in there > arguably aren't core...) > > I feel that what would be really useful is a core mechanism for > enabling/disabling modules which doesn't rely on the > module itself having that option. This would be simpler and might make the > question of whether there are lots of > modules bundled in a single dll moot (since you can just enable/disable them > with separate config entries - and storage > space for dlls is cheap :-) I'd be much more of a fan of having each module a seperate dll. Files are cheap too. :) And that makes it very clear to people what they are loading, and what they aren't loading. > Which in itself leads me on to the question of splitting up the massive > monolithic config file. I don't know about > other people, but I find it a pain to deal with. I feel that these kinds of > changes would be really valuable whilst > rearranging the module spaces is kind of nice to have but doesn't seem the > most pressing issue right now. But that's > just my opinion :-) I'd be a fan of that as well. More importantly, I think we need to get down to 1 config system and 1 plugin system for the project. Right now I think we're still at 2 or 3 per, which makes it painful all around. -Sean -- Sean Dague / Neas Bade sda...@gmail.com http://dague.net signature.asc Description: OpenPGP digital signature ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
[Opensim-dev] OpenSim 2nd Birthday Tommorrow - Blog About it
OpenSim's 2nd birthday is tommorrow (Jan 29th), and it would be really great if as many people as possible could put up a blog post about OpenSim tomorrow. Tell the world about your experiences with OpenSim, whatever they may be. Screen shots are always appreciated in blog posts. Once you do, please feel free to add a link to that blog post here - http://opensimulator.org/wiki/Second_Birthday in Section 4. That way everyone can see what everyone else is doing with this wonderful technology. Thanks again all for being with us through the last 2 years of amazing growth! -Sean -- Sean Dague / Neas Bade sda...@gmail.com http://dague.net signature.asc Description: OpenPGP digital signature ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Proposal for a cleanup/correction of the region-module system
Homer Horwitz wrote: > Hi all, > > the current system for handling region-modules is slightly broken if > you add/remove regions dynamically (or even for region-restarts). I've > put up some thoughts at > http://opensimulator.org/wiki/New_Region_Modules for discussion. > Please answer on the associated 'discussion' page or here on the list. > Nice proposal Homer. Here's another thought (to add to the pile). Is there really any point having an Initialise method at all? 1) Adam's idea of hanging the config off the scene and not passing it in via Initialise(IConfigSource) both disgusts and excites me. Disgust because it feels a bit wrong to tie Config in to Scene that closely (though maybe that's really just because Scene should be called Region). But exciting because I can imagine that we do want per region config at some point (it would be cool to be in space on one region and on Jupiter in another on the same server). Non-shared modules could still grab their config from the first scene that comes in (though having to do an if condition on the first scene will look less elegant than doing things without conditions in Initialise(). Then one could perhaps get rid of Initialise() completely and just do all initialization when the first region is added. One could almost get rid of Close() in the same way (perform close instead when the last region has been removed). Though in this case I can more easily imagine that one would want to remove all regions before adding more on the same instance (which might unnecessarily incur expensive cpu operations when initialize is called again). I'm probably just trying to be unnecessarily clever here. And I have a feeling these kinds of issues have probably already been addressed in some module system somewhere... :) 2) Is there any point on giving the Scene again in RemoveRegion? Would it be clearer just to give the region UUID instead or are there advantages to passing in Scene again? 3) On the spelling issue, I'm with MW - I think you Americans should just suck it up. I once had to work on an IBM product called WebSphere Product Center so I think that there should be some payback :) (an Init() compromise is fine though, I guess. Bring back the Empire, I say). -- justincc Justin Clark-Casey http://justincc.wordpress.com ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] proposal: cleanup and break up region modules
Dr Scofield wrote: > Justin Clark-Casey wrote: >> Dr Scofield wrote: >>> i've been looking at where region modules live in our source tree --- >>> OpenSim/Region/Modules and OpenSim/Region/Environment/Modules --- and >>> how they get bundled: >>> >>> * modules in OpenSim/Region/Modules get their own private DLL >>> * OpenSim/Region/Environment/Modules get lumped into ONE gigantic DLL >>> >>> off the 3 modules living in OpenSim/Region/Modules 2 might be good >>> candidate for forge project: python and SvnSerializer. the third really >>> belongs to the Terrain region module and seems to contain the default >>> terrain effects. >>> >>> i think it would make sense to >>> >>> * have all region modules living in the same neighborhood (i'd >>> prefer OpenSim/Region/Modules), the current layout is a bit confusing >> Don't we need to make a distinction between 'service' modules (such as the >> REST module) and scene/environment modules >> though? The former are not attached to a scene (and may well never be >> concerned with scene code) while the latter are >> very much scene related. > > that would be another step. first i'd like to get the modules settled in the > same neighborhood. > >>> * break up the region module super-DLL so that each region module >>> gets a DLL of its own >> At least on mono, I'm guessing that this would vastly expand build times. >> Certainly at the moment, each invocation of >> mono to build a new assembly appears to take far longer than building many >> files in a single dll. > > vastly? Maybe this is a slight exaggeration but I'm anticipating that the build time would be much longer. I'm happy to be proved wrong on this point. Maybe this seems a minor thing but long build times are such a pain in the ass. > > >> I also tend to think of the current modules in >> OpenSim/Region/Environment/Modules as fairly core modules that one would >> expect to be packaged together, and which it would be inconvenient to split >> up. > > hmm...that kind of goes against the idea of them being modules, i'd think :-) > > Does it? Isn't this just a convenient way of packaging the core modules that almost everybody is going to need to run their OpenSim (though I would admit that some of the modules in there arguably aren't core...) I feel that what would be really useful is a core mechanism for enabling/disabling modules which doesn't rely on the module itself having that option. This would be simpler and might make the question of whether there are lots of modules bundled in a single dll moot (since you can just enable/disable them with separate config entries - and storage space for dlls is cheap :-) Which in itself leads me on to the question of splitting up the massive monolithic config file. I don't know about other people, but I find it a pain to deal with. I feel that these kinds of changes would be really valuable whilst rearranging the module spaces is kind of nice to have but doesn't seem the most pressing issue right now. But that's just my opinion :-) -- justincc Justin Clark-Casey http://justincc.wordpress.com ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] proposal: cleanup and break up region modules
Justin Clark-Casey wrote: > Dr Scofield wrote: >> i've been looking at where region modules live in our source tree --- >> OpenSim/Region/Modules and OpenSim/Region/Environment/Modules --- and >> how they get bundled: >> >> * modules in OpenSim/Region/Modules get their own private DLL >> * OpenSim/Region/Environment/Modules get lumped into ONE gigantic DLL >> >> off the 3 modules living in OpenSim/Region/Modules 2 might be good >> candidate for forge project: python and SvnSerializer. the third really >> belongs to the Terrain region module and seems to contain the default >> terrain effects. >> >> i think it would make sense to >> >> * have all region modules living in the same neighborhood (i'd >> prefer OpenSim/Region/Modules), the current layout is a bit confusing > > Don't we need to make a distinction between 'service' modules (such as the > REST module) and scene/environment modules > though? The former are not attached to a scene (and may well never be > concerned with scene code) while the latter are > very much scene related. that would be another step. first i'd like to get the modules settled in the same neighborhood. > >> * break up the region module super-DLL so that each region module >> gets a DLL of its own > > At least on mono, I'm guessing that this would vastly expand build times. > Certainly at the moment, each invocation of > mono to build a new assembly appears to take far longer than building many > files in a single dll. vastly? > > I also tend to think of the current modules in > OpenSim/Region/Environment/Modules as fairly core modules that one would > expect to be packaged together, and which it would be inconvenient to split > up. hmm...that kind of goes against the idea of them being modules, i'd think :-) -- dr dirk husemann virtual worlds research ibm zurich research lab SL: dr scofield drscofi...@xyzzyxyzzy.net http://xyzzyxyzzy.net/ RL: h...@zurich.ibm.com - +41 44 724 8573 - http://www.zurich.ibm.com/~hud/ ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] proposal: cleanup and break up region modules
Dr Scofield wrote: > i've been looking at where region modules live in our source tree --- > OpenSim/Region/Modules and OpenSim/Region/Environment/Modules --- and > how they get bundled: > > * modules in OpenSim/Region/Modules get their own private DLL > * OpenSim/Region/Environment/Modules get lumped into ONE gigantic DLL > > off the 3 modules living in OpenSim/Region/Modules 2 might be good > candidate for forge project: python and SvnSerializer. the third really > belongs to the Terrain region module and seems to contain the default > terrain effects. > > i think it would make sense to > > * have all region modules living in the same neighborhood (i'd > prefer OpenSim/Region/Modules), the current layout is a bit confusing Don't we need to make a distinction between 'service' modules (such as the REST module) and scene/environment modules though? The former are not attached to a scene (and may well never be concerned with scene code) while the latter are very much scene related. > * break up the region module super-DLL so that each region module > gets a DLL of its own At least on mono, I'm guessing that this would vastly expand build times. Certainly at the moment, each invocation of mono to build a new assembly appears to take far longer than building many files in a single dll. I also tend to think of the current modules in OpenSim/Region/Environment/Modules as fairly core modules that one would expect to be packaged together, and which it would be inconvenient to split up. > > this would make the whole region module business much more, err, modular > (and, who knows, perhaps we'd even have one day a build system like the > "make menuconfig" one found in the linux kernel tree) > > what is the general opinion on this? i'd be willing to undertake the > refactoring (including tackling the prebuild.xml dragon). > > DrS/dirk > > -- > dr dirk husemann virtual worlds research ibm zurich research lab > SL: dr scofield drscofi...@xyzzyxyzzy.net http://xyzzyxyzzy.net/ > RL: h...@zurich.ibm.com - +41 44 724 8573 - http://www.zurich.ibm.com/~hud/ > > > > > ___ > Opensim-dev mailing list > Opensim-dev@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev -- justincc Justin Clark-Casey http://justincc.wordpress.com ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
[Opensim-dev] proposal: cleanup and break up region modules
i've been looking at where region modules live in our source tree --- OpenSim/Region/Modules and OpenSim/Region/Environment/Modules --- and how they get bundled: modules in OpenSim/Region/Modules get their own private DLL OpenSim/Region/Environment/Modules get lumped into ONE gigantic DLL off the 3 modules living in OpenSim/Region/Modules 2 might be good candidate for forge project: python and SvnSerializer. the third really belongs to the Terrain region module and seems to contain the default terrain effects. i think it would make sense to have all region modules living in the same neighborhood (i'd prefer OpenSim/Region/Modules), the current layout is a bit confusing break up the region module super-DLL so that each region module gets a DLL of its own this would make the whole region module business much more, err, modular (and, who knows, perhaps we'd even have one day a build system like the "make menuconfig" one found in the linux kernel tree) what is the general opinion on this? i'd be willing to undertake the refactoring (including tackling the prebuild.xml dragon). DrS/dirk -- dr dirk husemann virtual worlds research ibm zurich research lab SL: dr scofield drscofi...@xyzzyxyzzy.net http://xyzzyxyzzy.net/ RL: h...@zurich.ibm.com - +41 44 724 8573 - http://www.zurich.ibm.com/~hud/ ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
[Opensim-dev] Fwd: mantis resolved vs. closed
Sorry Mike, this was intended to go to the list, not to your personal email account :) Cheers, James -- Forwarded message -- From: James Stallings II Date: Wed, Jan 28, 2009 at 6:20 AM Subject: Re: [Opensim-dev] mantis resolved vs. closed To: Mike Mazur Good morning I'll take these from the top :) On Wed, Jan 28, 2009 at 12:02 AM, Mike Mazur wrote: > Hi, > > On Tue, 27 Jan 2009 10:47:14 -0600 > James Stallings II wrote: > > > suppose instead of setting the ticket to 'resolved' and closing it, > > we set it to 'resolution pending test' and leave it open > > I don't think there's enough difference between "resolved" and > "resolution pending test". Also I don't think we need to complicate > our workflow any more for a couple reasons: > > First, we don't have a dedicated QA team that will go through all > "resolution pending test" tickets and verify them, and apparently the > originals submitters don't care enough most of the time either. On the contrary - we do have a fairly dedicated team of people sheparding mantis. I'm one of them. I spend a fair time each month first testing and then closing old or ancient mantii. Granted, it's been a month or two since I've done this; new job has been a bit demanding in terms of time and attention. The problem is that 'Resolved' implies a certain degree of finality: 'I've submitted a patch, your issue is fixed, goodbye' is the message I get when I see a patch submitted and a ticket placed in 'Resolved' status. 'Resolved Pending Test' or 'Resolved Pending Feedback' says to me, 'I have made a patch for your issue which i think addresses the problem and the ball is now in your court'. > > > Second, what's so difficult with re-opening an issue that's been > resolved if the problem is not fixed? Since most of the time the > problem *is* fixed, why add this extra policy overhead for the few > cases where it isn't fixed? I beg to differ here; the issue addressed by any given patch tends to remain problematic after the patch about as often as not; if not in the original incarnation, then in some related fashion. If most patches represented a fix, we wouldn't need mantis at all, I think. > > Third, if your issue was "resolved" by a developer who submitted a > patch, or *gasp* even "closed" (if it was Justin, perhaps) without the > issue being fixed, it's not the end of the world. Don't take it > personally. Give the developer the benefit of the doubt, and ask > yourself why the developer felt the issue was fixed. Maybe the > description of the bug was inadequate? Maybe a better test case or > clearer steps to reproduce, expected and actual results would help > everyone understand the issue better? After reviewing the information > in the bug and the proposed fix, you can provide constructive comments > when you reopen the issue. I understand it isnt the end of the world, and I dunno what Justin has to do with this LOL but: We have a feature-rich trouble ticketing system that is capable of tracking an issue with a full set of supporting notes and workflow states through the process of resolution. Unfortunately, we are throwing this functionality out because of a perception that no one follows up on the bug reports. If we aren't going to use the mantis software to track isues, work-in-progress, and solutions, why have it at all? I do in fact test features; I provide the most accurate data surrounding tests as I possibly can; and I do follow up on my tickets as best I can, given the other demands of life and work. As it occurs, I was engaged in just such a process with idb when I returned to the mantis to engage in the next stage of the process to find the ticket closed/resolved. It was a bit like finding a door closed in my face. All I'm really asking is that we use terms that more accurately describe the state of the issue and reserve the closed disposition sufficiently to allow testing of the patch. Otherwise we might as well ditch mantis and keep a list of active issues on the wiki. Cheers James > > > Thanks, > Mike > -- === http://osgrid.org http://del.icio.us/SPQR http://twitter.com/jstallings2 http://www.linkedin.com/pub/5/770/a49 -- === http://osgrid.org http://del.icio.us/SPQR http://twitter.com/jstallings2 http://www.linkedin.com/pub/5/770/a49 ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
[Opensim-dev] New tutorial (Rex/ModRex)
hello For pple interested in rex/modrex, i wrote a tutorial about re-create partialy the Rex 0.4 demo. Good reading... Sacha http://www.rexdeveloper.org/wiki/index.php?title=Tutorial_%22the_Atoll%22_based_on_%22under_the_sea%22 ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
