I'm trying to understand this code:
315 let existingIndex = this._editors.indexOf(editableNode.editor);
316 if (existingIndex == -1) {
317 let x = this._editors.length;
318 this._editors[x] = editableNode.editor;
319 this._stateListeners[x] = this._createStateListener();
320 this._editors[x].addEditActionListener(this);
321 this._editors[x].addDocumentStateListener(this._stateListeners[x]);
322 }
http://mxr.mozilla.org/mozilla-release/source/toolkit/modules/Finder.jsm#320
Especially addEditActionListener(this); what is this? MDN docs say it should be nsIEditActionListener but I can't find what this listener is comprised of MDN docs takes to broken page.
nsIEditor - MDN
this is the Finder object; it implements the nsIEditActionListener interface (http://mxr.mozilla.org/mozilla-release/source/toolkit/modules/Finder.jsm#395)
That interface is defined here: http://mxr.mozilla.org/mozilla-release/source/editor/idl/nsIEditActionListener.idl
So the code essentially attaches the Finder object to the editor, presumably so it can be notified of changes made in the editor at a later point.
Related
When printing list of references with ptr_refs, it gives somewhat vague results (at least in iOS). For example I have a sample app with this tiny ViewController class and exactly one outlet reference to a UILabel instance:
import UIKit
class ViewController: UIViewController {
#IBOutlet var label: UILabel!
override func viewDidAppear(_ animated: Bool) {
super.viewDidAppear(animated)
print(label)
}
}
And here is the listing I get when printing references to the label:
(lldb) ptr_refs 0x102914810
0x0000000281b04630: malloc( 16) -> 0x281b04630
0x0000000283d09f18: malloc( 96) -> 0x283d09ec0 + 88
0x0000000280c18d60: malloc( 64) -> 0x280c18d40 + 32 CFXNotificationNameWildcardObjectRegistration0 bytes after CFXNotificationNameWildcardObjectRegistration
0x000000028192b408: malloc( 32) -> 0x28192b400 + 8 _UILabelStringContent._UILabelContent._defaultAttributesProvider
0x0000000283a3d2f0: malloc( 80) -> 0x283a3d2c0 + 48 CFXNotificationObjcObserverRegistration8 bytes after CFXNotificationObjcObserverRegistration
0x0000000283a3d2f8: malloc( 80) -> 0x283a3d2c0 + 56 CFXNotificationObjcObserverRegistration16 bytes after CFXNotificationObjcObserverRegistration
0x000000010290c070: malloc( 864) -> 0x10290bd20 + 848 TtC13ThreadChecker14ViewController216 bytes after TtC13ThreadChecker14ViewController
0x0000000102d058c0: malloc( 304) -> 0x102d05850 + 112
If this was not just a sample app and it had rather 10-15 outlet references, I would have a hard time trying to figure out which exact reference in my code this line is at - 0x000000010290c070: malloc( 864) -> 0x10290bd20 + 848 TtC13ThreadChecker14ViewController216 bytes after TtC13ThreadChecker14ViewControllerThe.
I also tried the -s option with MallocStackLogging enabled, but when it comes to outlet references, this information is not very helpful.
Provided I have only the address of an object and the listing given by ptr_refs, is there a way to find out which exact variable/field in my code corresponds to the reference in the listing?
Firstly, the names on the right give us some clues, from which you could guess that TtC13ThreadChecker14ViewController is associated with your ViewController class.
_Tt is for target; C is for class; 13 is the length of the "ThreadChecker" string, and your project name is ThreadChecker; 14 is the length of the "ViewController" string, and that is the class. Your ViewController starts at 0x10290bd20.
Secondly, the malloc is at 0x000000010290c070. Notice that 0x000000010290c070 - 0x10290bd20 = 0x350 which is 848 in decimal, so that's why it puts the offset as 848 from the start of "ViewController", i.e., 0x10290bd20 + 848. So this offset, 848, is an important piece of the puzzle.
Thirdly, the next thing to do is figure out what line in the source code is at offset 848. For this, we begin by doing
(lldb) image list
[ 0] 4EB96CD6-42E0-34D8-AB5B-2418F5C55678 0x000000010252c000 /Users/daniel.wong/Library/Developer/Xcode/DerivedData/testLLDB-eqmuowhdphumqdhcyvcydgrybiue/Build/Products/Debug-iphonesimulator/testLLDB.app/testLLDB
Even in this simple example, there might be 200-300 libraries loaded with the app. For the present investigation of your own source code, you can ignore the libraries, only look at the [ 0] (first element in the list).
(in my example, the app is called testLLDB; in yours, you might see ThreadChecker instead of testLLDB).
An important point to note is that image list gives the so-called file address where the addresses you got from Xcode that you used for ptr_refs might be quite different (actual addresses in the simulator or iPhone memory during an actual run when it gets loaded into a part of the RAM), e.g., 0x102914810 in your example. The file address refers to a virtual address as defined by each object file. For the purpose of finding the source code line number with the offset 848, you can work with these file addresses and you now just need one more piece of information, i.e., where is the start of the code for ViewController, so you can take offset 848 from there.
Fourthly, to find the start of the code for ViewController, you can use
(lldb) image dump sections /Users/daniel.wong/Library/Developer/Xcode/DerivedData/testLLDB-eqmuowhdphumqdhcyvcydgrybiue/Build/Products/Debug-iphonesimulator/testLLDB.app/testLLDB
where we specified only the image of the testLLDB app that we got as the first element of the image list, and not the 100s of libraries after that.
lldb will then give you something like:
Sections for '/Users/daniel.wong/Library/Developer/Xcode/DerivedData/testLLDB-eqmuowhdphumqdhcyvcydgrybiue/Build/Products/Debug-iphonesimulator/testLLDB.app/testLLDB' (x86_64):
SectID Type Load Address Perm File Off. File Size Flags Section Name
---------- ---------------- --------------------------------------- ---- ---------- ---------- ---------- ----------------------------
0x00000100 container [0x0000000000000000-0x0000000100000000)* --- 0x00000000 0x00000000 0x00000000 testLLDB.__PAGEZERO
0x00000200 container [0x000000010252c000-0x0000000102532000) r-x 0x00000000 0x00006000 0x00000000 testLLDB.__TEXT
0x00000001 code [0x000000010252d260-0x000000010252fa80) r-x 0x00001260 0x00002820 0x80000400 testLLDB.__TEXT.__text
0x00000002 code [0x000000010252fa80-0x000000010252fb5e) r-x 0x00003a80 0x000000de 0x80000408 testLLDB.__TEXT.__stubs
0x00000003 code [0x000000010252fb60-0x000000010252fce2) r-x 0x00003b60 0x00000182 0x80000400 testLLDB.__TEXT.__stub_helper
0x00000004 data-cstr [0x000000010252fce2-0x00000001025309bf) r-x 0x00003ce2 0x00000cdd 0x00000002 testLLDB.__TEXT.__objc_methname
0x00000005 data-cstr [0x00000001025309c0-0x0000000102531817) r-x 0x000049c0 0x00000e57 0x00000002 testLLDB.__TEXT.__cstring
0x00000006 regular [0x0000000102531820-0x0000000102531b50) r-x 0x00005820 0x00000330 0x00000000 testLLDB.__TEXT.__const
...
There's more, but for this simple ViewController, these first few sections are enough for our purpose. Look at the first code section, where its range is [0x000000010252d260-0x000000010252fa80). So it is starting from 0x000000010252d260. Here is where we add the offset 848. But we add in hex, so we add 0x350 to 0x000000010252d260 to get 0x000000010252d5b0.
Fifthly and finally, we can see which part of our source code was referencing the label, by:
(lldb) image lookup -a 0x000000010252d5b0 --verbose
Address: testLLDB[0x00000001000015b0] (testLLDB.__TEXT.__text + 848)
Summary: testLLDB`key path getter for testLLDB.ViewController.label : Swift.Optional<__C.UILabel> : testLLDB.ViewController + 80 at <compiler-generated>
Module: file = "/Users/daniel.wong/Library/Developer/Xcode/DerivedData/testLLDB-eqmuowhdphumqdhcyvcydgrybiue/Build/Products/Debug-iphonesimulator/testLLDB.app/testLLDB", arch = "x86_64"
CompileUnit: id = {0x00000000}, file = "/Users/daniel.wong/OneDrive - V-Key Pte Ltd/ios/testLLDB/testLLDB/testLLDB/ViewController.swift", language = "swift"
Function: id = {0x10000032e}, name = "key path getter for testLLDB.ViewController.label : Swift.Optional<__C.UILabel> : testLLDB.ViewController", mangled = "$s8testLLDB14ViewControllerC5labelSo7UILabelCSgvpACTK", range = [0x000000010252d560-0x000000010252d5bf)
FuncType: id = {0x10000032e}, byte-size = 8, compiler_type = "() -> ()
"
Blocks: id = {0x10000032e}, range = [0x10252d560-0x10252d5bf)
LineEntry: [0x000000010252d560-0x000000010252d5c0): /Users/daniel.wong/OneDrive - V-Key Pte Ltd/ios/testLLDB/testLLDB/<compiler-generated>
Symbol: id = {0x000000a4}, range = [0x000000010252d560-0x000000010252d5c0), name="key path getter for testLLDB.ViewController.label : Swift.Optional<__C.UILabel> : testLLDB.ViewController", mangled="$s8testLLDB14ViewControllerC5labelSo7UILabelCSgvpACTK"
Variable: id = {0x100000345}, name = "label", type = "testLLDB.ViewController", location = DW_OP_fbreg(-16), decl = ViewController.swift:18
So we see it is "key path getter for testLLDB.ViewController.label : Swift.Optional<__C.UILabel> : testLLDB.ViewController" at ViewController.swift:18, which is what you were looking for. (ok, for my test view controller, the label is in line 18, as I also had a viewDidLoad that took a few lines; for yours, you should get the appropriate line number for your ViewController).
This post is already too long, but just to add one more little piece of info: those references to your label from CFXNotificationObjcObserverRegistration, that is part of CoreFoundation, so we see that not at references are from our own source code. Many references would often be from system frameworks like CoreFoundation, etc.; if you put your view with the label in a storyboard and add auto layout constraints, for example, the ptr_refs command will additionally give you a number of other references that are related to auto layout, e.g.,
NSContentSizeLayoutConstraint.NSLayoutConstraint._container
0x000060000049ce48: malloc( 96) -> 0x60000049ce40 + 8 NSContentSizeLayoutConstraint.NSLayoutConstraint._container
0x00006000035db208: malloc( 64) -> 0x6000035db200 + 8 NSLayoutDimension.NSLayoutAnchor._referenceItem
0x00006000035db3c8: malloc( 64) -> 0x6000035db3c0 + 8 NSLayoutDimension.NSLayoutAnchor._referenceItem
0x00006000035e9560: malloc( 64) -> 0x6000035e9540 + 32
I'm attempting to implement RFC 5219: A More Loss-Tolerant RTP Payload Format for MP3 Audio.
I understand that, for a given MP3 frame, you can identify where the corresponding ADU starts by parsing out the "main_data_begin" backpointer and reading from the "bit reservoir" (i.e. the audio data in the previous few frames).
However, I cannot understand how, for a given MP3 frame, you know when an ADU finishes?
For example, consider the following 2 MP3 frames:
Frame1 has a main_data_begin = 0.
Frame2 has a main_data_begin = 20
Therefore, ADU1's length is
Frame1.Length - Frame1.HeaderLength - 20 bytes
But how can I know that? Am I able to generate ADU1 from Frame1, or must I read in Frame2 before I can determine that Frame1 is complete and generate ADU1?
Note that there is a sample algorithm in RFC 5219 Appendex A.1 which contains the following pseudo-code:
do
{
// read a frame
}
while (totalDataSizeBefore < newFrame.backpointer ||
totalDataSizeAfter < newFrame.aduDataSize);
but nowhere does it define "aduDataSize" or how it's calculated, so it's not super helpful...
The only other clue I have is a vague suggestion I can read the part_2_3_length from the Side Information and that will tell me how long the ADU is - however, I can't find a really effective source for how to actually parse the part_2_3_length - I just know it's a 12/24-bit structure which would give me a value far too high to be a frame-size.
Eventually we found the answer in the Live555 source code (specifically MP3Internals.cpp).
Basically, you need to read the part_2_3_lengths for each granule in each channel, and then maths them.
Roughly:
uint numBits = 0;
for (int channelIdx = 0; channelIdx < isMono ? 1 : 2; channelIdx ++)
{
for (int granuleIdx = 0; granuleIdx < 2; granuleIdx ++)
{
numBits += SideInfoGranules[channelIdx][granuleIdx].Part_2_3_Length;
}
}
// Now maths this number. I don't know where the magic constants 7 and 8 come from though.
var aduDataSize = (numBits + 7) / 8;
The parsing of the part_2_3_length is a bit too involved to explain here, but is well explained in the getSideInfo1 and getSideInfo2 methods of MP3Internals.cpp (for example, here);
Stack of Plates: Imagine a (literal) stack of plates. If the stack gets too high, it might topple.
Therefore, in real life, we would likely start a new stack when the previous stack exceeds some threshold. Implement a data structure SetOfStacks that mimics this. SetOfStacks should be composed of several stacks and should create a new stack once the previous one exceeds capacity.
SetOfStacks. push () and SetOfStacks. pop() should behave identically to a single stack (that is, pop ( ) should return the same values as it would if there were just a single stack).
FOLLOW UP
Implement a function popAt (int index) which performs a pop operation on a specific substack.
The book solution for pop at index:
public int popAt(int index) {
21 return leftShift (index, true);
22 }
23
24 public int leftShift(int index, boolean removeTop) {
25 Stack stack = stacks.get(index);
26 int removed_item;
27 if (removeTop) removed_item = stack.pop();
28 else removed_item = stack.removeBottom( );
29 if (stack.isEmpty(» {
30 stacks.remove(index);
31 } else if (stacks.size() > index + 1) {
32 int v = leftShift(index + 1, false);
33 stack . push(v);
34 }
35 return removed_item;
36 }
the explanation of line 32 i nt v = leftShift(index + 1, false); is missing. Can anyone please help me with that?
Well, the leftShift function's objective is to pop from the stack given in the "index" input. After this, it does the adjustment between the other stacks.
So, in line 27 pops the element from the specified stack.
After this, in line 32, it calls itself recursively, giving this time as a first argument the index of the next stack, and as a second false. The first argument indicates that in the next recursive call, it will use the next stack. The second argument, being set as false, means that the required action (pop) has been done, and now only the adjustment is left.
The function when the flag removeTop is set as false does the adjustment as I referred above. The difference, in this case, is that instead of the top element it removes the bottom one from each of the following stacks. This way the needed adjustment is done.
With the term adjustment, I mean the elements that need to be moved from the next stacks to the previous ones each time so as to fill any empty spaces.
I hope it helps.
I've been working on a Flash Register but I keep getting an error that says Line 170 and Line 174 Left side of assignment operator must be variable or property.
Here are the functions
function nextView()
{
this.__set__currentViewIndex(++this.__get__currentViewIndex()); //Line 170
}
function prevView()
{
this.__set__currentViewIndex(--this.__get__currentViewIndex()); //Line 174
}
Nvm I fixed it. this.__set__currentViewIndex(this.__get__currentViewIndex()+ 1); was the fix
i have a custom image for facebook, that when the user click, it will share something, however, developers.facebook provide element that will automatically generate share button with the below code
<div class="fb-share-button" data-href="https://developers.facebook.com/docs/plugins/" data-layout="button"></div>
I want to use my custom image to use the code generated to popup the share page, is there a way?
%a.link.facebook{href: "some_url_here"}
I already search the net, still I'm stuck,
Thanks for your help , im still a beginner, :)
Many suggestion are useful, thanks to all of them, but i find this method more simple, I want to share it to you guys.
Javascript (put it in header or footer)--
<script>
function fbShare(url, title, descr, image, winWidth, winHeight) {
var winTop = (screen.height / 2) - (winHeight / 2);
var winLeft = (screen.width / 2) - (winWidth / 2);
window.open('http://www.facebook.com/sharer.php?s=100&p[title]=' + title + '&p[summary]=' + descr + '&p[url]=' + url + '&p[images][0]=' + image, 'sharer', 'top=' + winTop + ',left=' + winLeft + ',toolbar=0,status=0,width=' + winWidth + ',height=' + winHeight);
}
</script>
to your link or image
Share
http://jsfiddle.net/stichoza/eyxtj/