Re: [Opensim-dev] .NET / Mono lock(obj) statement
Hi Diva,
On Wed, Jan 14, 2009 at 5:57 AM, Diva Canto wrote:
> Here's a simplified version of the problem:
>
> lock (a)
> {
> foo();
> }
>
> void foo()
> {
> lock (a)
> {
>...
> }
> }
I just tried that with Mono 2.0.1, and it works correctly (i.e. it
doesn't deadlock). I used an instance variable object a = new object()
for the lock.
> (the real situation is a bit more complicated; foo() involves a
> delegate; but ignore that)
Is this maybe necessary to get the (wrong) result? Or did you use
another Mono version?
Cheers,
Homer
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
[Opensim-dev] Proposal for a cleanup/correction of the region-module system
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. Cheers, Homer ___ 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
On Sun, Jan 25, 2009 at 3:33 AM, Jeff Ames wrote: >... > For a non-shared module, is there a functional difference between > Initialise and AddRegion? Likewise with RemoveRegion and Close. Registration happens in Initialise, so when the AddRegion call happens, all the modules are available already. Same for RemoveRegion and Close: During RemoveRegion, all the modules are still available. During Close, some might have been closed before your module is closed. On Sun, Jan 25, 2009 at 8:39 AM, Frisby, Adam wrote: > >> For shared modules, is there some technical reason or use case that >> requires a PostInitialise after Initialise? The only case I can think >> of is interdependent region modules that need each other to be >> initialized before they can add regions. > > [Frisby, Adam] > > Close - it's more so you can start 'doing things' after every region has been > registered. Prior to PostInitialise you cannot be sure that everything has > been constructed yet, and/or other modules have registered their interfaces. Actually, in the new one PostInitialise happens after every *Initialise* has been run, not after every *AddRegion* has been run. You just can't execute a method once after all regions has been registered, as I can add regions on the fly (that's one of the problems I see with the old version as stated in the Wiki article): You'll either end up calling it more than once for some regions (if you call it after every AddRegion), or not at all for some regions (if you call it only once). But for the intended new semantics: good point, Jedd, I added that just because it is in the current system. In PostInitialise, all the (shared) modules have been registered already. On the other hand, it's the same in AddRegion, and I'd find it more consistent to the non-shared modules to not depend on PostInitialise in the shared ones (in AddRegion, the non-shared modules are available, too). If you have to do something that should happen after all the shared modules are initiali(z|s)ed, it might make sense to postpone it a bit further and do it when the first region is added. So, +1 for making the interface a bit smaller and removing PostInitialise. Cheers, Homer ___ 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
As this thread has been thoroughly hijacked, I guess there aren't any further relevant (um, I meant technical) problems with the proposal? Cheers, Homer ___ 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
On Sun, Jan 25, 2009 at 6:13 PM, Justin Clark-Casey wrote: > Could you wait a couple more days on this? I don't really have the > opportunity to give this the attention that it > deserves today (Sunday) and I may not be around at all tomorrow but I should > have some think time on Tuesday. > > Perhaps having a standard timeframe of something like a week for responses to > proposals would be a good idea. Yes, I planned to do that anyway, I just wanted to try to get the thread back on topic. I'll wait 'til next weekend (won't have much time before that anyway). Cheers, Homer ___ 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
Ok, I'll try to summarize a bit: Sean had the great idea to use a dialect-independent way of naming our methods: I'll use Init and PostInit :-) Justin wondered whether we need an Init* method at all or if we just could init on first region-add. The benefit of a separate Init + PostInit method is, that you can do things before any region has been added, but after all the (shared) modules have been initialized. I don't know whether that's necessary, but on the other hand, it doesn't hurt to have that possibility. It doesn't cost anything, after all. I could add some abstract base classes with default implementations, so you don't have to add an empty Init-method if you don't need it, but that's more or less syntactic sugar... About the configuration: I don't like the idea of getting the config from the scene much, because (at least currently), configuration is owned by the server, not by one of its regions/scenes. While I understand that some modules won't need a configuration, having to add the Nini reference for a fresh region-module doesn't seem too difficult to me (the currently available ones already have that reference, so no change there). Even if we change that and will have region-specific parts of the configuration, the config as a whole will still be in the responsibility of the server, not the region, in my opinion. We need a possibility to disable modules (preferably without first loading them) without removing the *.dll; and there were some wishes about the loader, pro and contra Mono.Addins. I think I'll have a look at Mono.Addins (including the IPlugin interface and the disable-by-config); it's the one we use already, and I agree that we should use only one loader, if possible without having to use too many workarounds. If not, ExtensionLoader might win ;-) "what happens to avatars that are in a region that you want to restart then? are they kicked out first? should they stay?" As the region goes down, they can't stay. So, either they will be moved away (TP home, maybe?) or they will be kicked out. Kicking them out might be the easier thing (and consistent with the SL behavior, too); TP home might be difficult if it is the home-region that is restarted. I plan to do the move in an as compatible way as possible; if everything works as intended, the "old" modules will continue to work for a time. The move will happen in several steps - Implementation of the new module system (while keeping the old one functional) - Marking the old one as deprecated - Moving over all the available core region modules to the new system - Removing the old region module system Especially the third part will take some time (not because it is hard, I don't think it is, but because we have quite a few modules)... Thanks for all the contributions :-) Any last comments? Cheers, Homer ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Accessing textures via HTTP [bayes]
Hi, JPEG2000 isn't quite that unsupported; for details, have a look at http://www.jpeg.org/jpeg2000/ As the textures are stored as j2k streams in the server, and you can't use the jpeg-formatted images in the client directly either, even if you would get them (as for rendering you'll probably need some uncompressed texture-format), re-coding the images from j2k to jpeg (on the server or on the client), and then decoding them in the client again will only add processing time and decrease image-quality. A much better way (regarding performance and quality) would be to take what you get and decode that directly. With OpenJpeg, there is a free implementation that handles j2k processing (which we use in the server, too), so I don't see a (technical) reason for not doing this, either. Cheers, Homer On Wed, Mar 18, 2009 at 12:43 AM, Mike Mazur wrote: > Hi, > > On Tue, 17 Mar 2009 21:44:12 +0200 > Tommi Laukkanen wrote: > > > I noticed that all our HTTP asset providers serve textures as j2k but > > I need jpegs or other well supported image formats for MXP. > > Alternatively you could write a j2k->jpeg converter in your client. > > Mike > ___ > Opensim-dev mailing list > Opensim-dev@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Couple questions on scripts
One application to inspect/decompile assemblies is http://www.red-gate.com/products/reflector/ Cheers, Homer On Fri, Mar 20, 2009 at 5:35 AM, Skidz Tweak wrote: > ... > And are there apps out in the wild that can decompile the CIL, or any > reports of anyone really do this? > ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Supplying IScene instead of Scene for the future region modules mechanism
Hi Justin, On Tue, Apr 14, 2009 at 7:02 PM, Justin Clark-Casey wrote: > ... > Instead of passing Scene itself to region modules, could we create an > interface so that we better control the amount of > innards that we expose to region modules? It's convenient-ish to give the > original Scene class to modules now, but it > will cause us problems down the road. The "old" IScene wasn't powerful enough, as I found out when I started with it, and as the old RegionModules took a Scene, I just went along with it. But you are right, of course, having an interface instead would allow decoupling the different components. So, +1 from me. Cheers, Homer ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] OAuth as authentication and authorisation (capability) specification
> As you can see from the wiki front page for example google offers > standard oauth api. I would like to use my google identity in OpenSim > as soon as possible :). Maybe you should still wait a bit: http://oauth.net/advisories/2009-1 If I interpret this correctly, the current OAuth specification will have to be changed to address this issue. Cheers, Homer ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
[Opensim-dev] [INFO] Slight IClientAPI change: SendDialog
Just for info: With r9571, I changed IClientAPI.SendDialog (fix for Mantis #3661). No breakage expected, but people with client-adapters outside of core might need to adapt them. Cheers, Homer ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Minimum OpenSim mono version now 2.4? (was Re: [Opensim-commits] r10113 - trunk)
On Tue, Aug 4, 2009 at 7:33 PM, Justin Clark-Casey wrote: > I just gave current master a try under mono 2.0.1 and I get the following on > startup > ... > At least for Ubuntu, the next release (9.10) will upgrade the mono packages. Or, for jaunty (9.04), you probably can install them from https://launchpad.net/~directhex/+archive/monoxide Cheers, Homer ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] No change author recorded in git! (was Re: [Opensim-commits] [OpenSim Git Master Repository] master branch updated. r/11319)
Teravus Ovares wrote: > Just a note, git keeps track of who pushed the commit. You can see > this information in viewgit. I'm sure native git has a way of > pulling this information up.. but I don't know it :D You can show author and committer via command line with git log --pretty=full (or even --pretty=fuller) gitk shows it, too. Cheers, Homer ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
