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]> 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]> 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 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]> 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]> 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
