How can I make a own repository entry or fork which doesn't disturb someone on GitHub. I think this should be a good place. But I've downloaded the Mercurial version, can I upload it without problems, or should I upload the Mercurial clone everywhere else?
Am 14.01.2014 22:18, schrieb Till Schneidereit: > You could also publish your Mercurial clone somewhere, or do a fork of > the gecko-dev repository on github[1] and push your changes there. > > One of these options is probably easiest, depending on what you're > comfortable with. Uploading patches to bugzilla isn't all that bad > either, though. > > In any case, without being able to look at (and apply) a patch, it's > hard to tell what's going on. > > [1]: https://github.com/mozilla/gecko-dev > > > On Tue, Jan 14, 2014 at 9:23 PM, Andreas Schlegel > <[email protected] <mailto:[email protected]>> wrote: > > Ok the code output is ok and better than email but I have > everytime to upload the file(s) on each change because I've no > possibility to checkin my code. > > I think I will create a thread. Can you tell me if and where I can > create one without disturbing someone? > > --- > > I've also found the problem with the comparism failure of proxies > in a global var....I must implement the same trap for the > CrossCompartmentWrapper I think (because I've created the function > and run into with the debugger)...but at the moment I've the > following error with my code: > > Assertion failure: cx->compartment() == > lazy->function()->compartment(), at > > /home/fedora/workspace/mozilla/mozilla-central/js/src/frontend/BytecodeCompiler.cpp:408 > > > Code: > bool > CrossCompartmentWrapper::isTransparent(JSContext *cx, HandleObject > wrapper, bool *bp) > { > // step 1 > RootedObject handler(cx, > GetDirectProxyHandlerObject(wrappedObject(wrapper))); > > // step 2 > JSString* propStr = JS_InternString(cx, "isTransparent"); > JSAtom& atom = propStr->asAtom(); > RootedValue trap(cx); > if (!JSObject::getProperty(cx, handler, handler, > atom.asPropertyName(), &trap)) > return false; > > // step 3 > if (trap.isUndefined()) > { > *bp = false; > return true; > } > > // step 4 > Value argv[] = { > // ObjectOrNullValue(target), > // value > }; > RootedValue trapResult(cx); > if (!Invoke(cx, ObjectValue(*handler), trap, 0, argv, > &trapResult)) > return false; > > // step 5 > bool success = ToBoolean(trapResult); > > // step 6 > *bp = success; > return true; > } > The error occurs during the call of Invoke. How can I solve this? > > Thanks a lot > > > Am 14.01.2014 20:27, schrieb Till Schneidereit: >> On Tue, Jan 14, 2014 at 8:17 PM, Andreas Schlegel >> <[email protected] <mailto:[email protected]>> >> wrote: >> >> It would be nice to attach the code but I'm not sure if >> bugzilla is a good place, because I've got a lot of >> discussion about "why would I do this thematic?" and I don't >> think that anybody want that I make a thread which could be >> handled as a bug :-) >> For me it's a little bit difficult to survey this amount of >> code of spidermonkey and where should I place the code or >> which handler/wrapper can/have I to change that my changes work. >> >> Which advantage has bugzilla? >> >> >> The advantage of having built-in tools to look at your patches. >> (Those tools aren't fantastic, but certainly good enough for >> getting specific feedback on your changes.) If you explicitly >> state that this is an experiment, I don't expect much negative >> feedback there. Most people who watch js-engine bugs also read >> this mailing list. >> >> >> >> I was in the IRC channel but at most I get no answer, >> therefore I leave the channel. >> >> >> Yeah, that happens sometimes. :( Try pinging individual people >> who might be able to help you. Who that might be for a specific >> area can be found out by looking at who's made changes to the >> code you're touching, too. >> >> >> >> Am 14.01.2014 19:59, schrieb Till Schneidereit: >>> I would at this point very much recommend putting your >>> patches somewhere they can be looked at by others (ideally >>> attached to a bugzilla.mozilla.org >>> <http://bugzilla.mozilla.org> bug), and then joining the >>> #jsapi channel on IRC. It's much, much easier and quicker >>> that way. >>> >>> >>> On Tue, Jan 14, 2014 at 7:56 PM, Andreas Schlegel >>> <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> I see the wrapper class is a child of the >>> DirectProxyHandler, which I haven't changed until now. >>> Should I change only this class or the underlying wrapper? >>> >>> Am 14.01.2014 19:52, schrieb Andreas Schlegel: >>>> Hello Till, >>>> >>>> I think the first answer of my question could be in an >>>> other direction. >>>> I found the CrossCompartmentWrapper, you're speaking from. >>>> I think I must insert the code there also. >>>> There are also other wrapper child classes and the >>>> wrapper class must I insert the method there if I >>>> change the CrossCompartmentWrapper? >>>> >>>> Am 14.01.2014 19:46, schrieb Till Schneidereit: >>>>> On Tue, Jan 14, 2014 at 7:35 PM, Andreas Schlegel >>>>> <[email protected] >>>>> <mailto:[email protected]>> wrote: >>>>> >>>>> My Questions are: >>>>> >>>>> Why is the proxy within the global not handled by >>>>> a ScriptedDirectProxyHandler and which handler is >>>>> used for? >>>>> Why are the JSContext and JSRuntime identical, >>>>> although the two objects should use two different >>>>> Runtimes? >>>>> >>>>> >>>>> I don't know the answer to the first question, sorry. >>>>> >>>>> As for the second: you can have arbitrarily many >>>>> global objects in the same runtime. To have two >>>>> different runtimes, you'd have to create them >>>>> specifically. I don't know if that's even possible in >>>>> the shell. >>>>> >>>>> The thing that's different for the two globals is the >>>>> JSCompartment, which every global has its own of. >>>> >>> >>> >> >> > > _______________________________________________ dev-tech-js-engine-internals mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
