I understand vma->fault() will take two arguments which are vma and vmf. But I am not sure what vma->fault() will do inside of itself because I cannot find the code or document that talks about the initialization of this field in vm_area_struct->vm_ops->fault().
If I understand correctly, you are looking for implementation vma->fault(), which is being executed in mm/memory.c in __do_fault() function:
ret = vma->vm_ops->fault(vma, &vmf);
TL;DR
Short answer: special_mapping_fault() function set up as .fault callback.
Long story
When trying to find thing like this, one shouldn't underestimate power of simple Unix tools, like grep. Knowing that .fault callback belongs to memory management, we know that we should look into mm/ directory. So here is the answer:
$ grep -sIrHn '\.fault = ' mm/*
And the output is next:
mm/hugetlb.c:2594: .fault = hugetlb_vm_op_fault,
mm/mmap.c:3001: .fault = special_mapping_fault,
mm/mmap.c:3007: .fault = special_mapping_fault,
Investigating further we can figure out that mm/hugetlb.c is part of HugeTLB FS implemetation, hence has nothing to do with your case.
For both other cases you can see that special_mapping_fault() function is using as .fault callback.
Related
I would like to know if there is a message I can override in Pharo so that my custom classes display more descriptive information in the inspector/debuger much like simple variable types do, like Integers or Strings. For instance:
Instead of that, I would like it to show a more custom and informative description consisting of its internal variales so as to have a tighter/tidier view of the variables instead of having to click on it and open another chart (therefore losing sight of the information on the previous chart). I know you can increase the amount of charts shown below, but that is not the point of the question. I would like to achieve something like this:
I have browsed the pharo forums and found nothing, I have also tried overriding over 30 methods hoping that one of them changed the output. Only the class message seemed to change the output, but I could only return an instance of Metaclass and besides messing with this message would break a lot of stuff. Finally I tried to reverse engineer the debugger and then the inspector to see at which point is the table constructed and what values are used or which messages are sent to build said values, but it was just too much for me, the callstack kept growing and I couldn't even scratch the surface.
Luckily, doing this in any Smalltalk is very easy. Types inherited from Object are expected to answer to the message printString, and ultimately printOn: aStream. Those messages are expected to give a description of the object. So, you should just override printOn: in your class (printString uses printOn:) and all the browsers and inspectors will automatically use it. There other possibilities in Pharo, if you want to provide more complex information in different tabs, but I think printOn: will suffice for you.
An example would be:
MyPoint>>printOn: aStream
aStream nextPut: ${.
x printOn: aStream.
aStream nextPutAll: ', '
y printOn: aStream.
aStream nextPut: $}
In Smalltalk, every time you observe something you don't like or understand, you ask the question: Which message is doing this?
In your case, the question would be: Which message creates the string a MyPoint that I see everywhere?
Next, to answer your question you need to find a good place for inserting a halt and then debug from there until you find the culprit. To do this just find the simplest expression that would reproduce the issue and debug it. In your case the right-click command in the Playground will do. So,
Write and select (MyPoint on: 14 and: -5) halt in a Playground.
Right-click and issue the Print it command (I'm assuming you already checked that this command produces the string 'a MyPoint').
Debug
Go over the evaluation of #DoIt, which answers the result
Continue this way alternating between Into and Over to make sure you follow the result to where it's being taken
Eventually you will reach the implementation of Object >> #printString. Bingo!
Now you can open a System Browser and take a look at this method, study how it's been implemented in different classes, etc. Your investigation should show you that the most basic message for printing is #printOn:. You may also want to take a look at other implementors so to better understand what people usually do. (Bear in mind that writing good #printOn:s is a minimalist art)
Overriding printOn: will work for simple cases where you want to just change description.
Pharo allows a lot more than that!
Due the extensible (moldable) nature of our inspector, you do not need to override a method to get your own visualisation of the object.
For example, look this array visualisation:
This is obtained adding this method to Collection:
gtInspectorItemsIn: composite
<gtInspectorPresentationOrder: 0>
^ composite fastList
title: 'Items';
display: [ self asOrderedCollection ];
beMultiple;
format: [ :each | GTObjectPrinter asTruncatedTextFrom: each ];
send: [ :result |
result
ifNil: [ nil ]
ifNotNil: [ result size = 1
ifTrue: [ result anyOne ]
ifFalse: [ self species withAll: result ]
]
]
if you browse for senders of gtInspectorPresentationOrder: you will see there are already a lot of special visualisations in the image.
You can take those as an example on how to create your own, adapted exactly to what you need :)
My problem is the same as the one mentioned in this answer. I've been trying to understand the code and this is what I learned:
It is failing in the file parse_xml.cgi, tries to get messages (return $message{$name}) from a file named messages (located in the html_en directory).
The $messages value comes from the method GetMessageHash in file adminprotocol-lib.pl:
sub GetMessageHash
{
return $ENV{"QTSSADMINSERVER_EN_MESSAGEHASH"}
}
The $ENV{"QTSSADMINSERVER_EN_MESSAGEHASH"} is set in the file streamingadminserver.pl:
$ENV{"QTSSADMINSERVER_EN_MESSAGEHASH"} = $messages{"en"}
I dont know anything about Perl so I have no idea of what the problem can be, for what I saw $messages{"en"} has the correct value (if I do print($messages{"en"}{'SunStr'} I get the value "Sun")).
However, if I try to do print($ENV{"QTSSADMINSERVER_EN_MESSAGEHASH"}{'SunStr'} I get nothing. Seems like $ENV{"QTSSADMINSERVER_EN_MESSAGEHASH"} is not set
I tried this simple example and it worked fine:
$ENV{"HELLO"} = "hello";
print($ENV{"HELLO"});
and it works fine, prints "hello".
Any idea of what the problem can be?
Looks like $messages{"en"} is a HashRef: A pointer to some memory address holding a key-value-store. You could even print the associated memory address:
perl -le 'my $hashref = {}; print $hashref;'
HASH(0x1548e78)
0x1548e78 is the address, but it's only valid within the same running process. Re-run the sample command and you'll get different addresses each time.
HASH(0x1548e78) is also just a human-readable representation of the real stored value. Setting $hashref2="HASH(0x1548e78)"; won't create a real reference, just a copy of the human-readable string.
You could easily proof this theory using print $ENV{"QTSSADMINSERVER_EN_MESSAGEHASH"} in both script.
Data::Dumper is typically used to show the contents of the referenced hash (memory location):
use Data::Dumper;
print Dumper($messages{"en"});
# or
print Dumper($ENV{"QTSSADMINSERVER_EN_MESSAGEHASH"});
This will also show if the pointer/reference could be dereferenced in both scripts.
The solution for your problem is probably passing the value instead of the HashRef:
$ENV{"QTSSADMINSERVER_EN_SUN"} = $messages{"en"}->{SunStr};
Best Practice is using a -> between both keys. The " or ' quotes for the key also optional if the key is a plain word.
But passing everything through environment variables feels wrong. They might not be able to hold references on OSX (I don't know). You might want to extract the string storage to a include file and load it via require.
See http://www.perlmaven.com/ or http://learn.perl.org for more about Perl.
fix code:
$$ENV{"QTSSADMINSERVER_EN_MESSAGEHASH"} = $messages{"en"};
sub GetMessageHash
{
return $$ENV{"QTSSADMINSERVER_EN_MESSAGEHASH"};
}
ref:
https://github.com/guangbin79/dss6.0.3-linux-patch
I have a piece of Lua code that generate an error and I don't understand how to solve it.
.............................
local last_num = 0
local channelTable={}
for num in channels.each_number() do -- channels.each_number() returns 1.number in each call
channelTable[last_num] =num;
last_num = last_num +1;
end
table.sort(channelTable);
based on lua documentation I can use the function sort to sort the saved numbers in channelTable. the error that I get is:
attempt to index global 'table'
Any idea how can I solve this, or should implement bubble sort?
thanks for any hint!
Either you haven't loaded the table library or you have overwritten it by accident.
The error message seems truncated: it should say why indexing failed.
The error you are seeing indicates that the table library is not available. It's unlikely that this core library isn't part of your Lua environment, so it's likely you have assigned something to table elsewhere in your code.
I think the issue may be that you are expecting channels.each_number() to be called in each iteration of the loop. If I'm not mistaken, I think it only gets called the first time the program goes through the loop. Whatever you use in thefor..in loop needs to be a table, I believe. So I guess the problem is that your table isn't being generated as you want it to. Try doing this:
print('number of items in channelTable = ' .. #channelTable)
If it comes out to 0, then what I said is probably the problem.
i am new to matlab. While working through the Matlab GUI, i faced a problem which is as follows..i want to have 2 figure files, with one figure file calling the other. i know that just by calling the name of the 2nd fig file from the first fig file, we can call the 2nd figure. however, i also wish to send some parameters from one fig file to another.here i need to send the arguments and also obtain these parameters so as to do further processing.i havent been able to find a solution to this problem. i would be glad if someone helps me out with this problem. thanking you in advance
There are three ways I found to do this:
Method 1: Use setappdata and getappdata like so:
setappdata(0,'some_var',value)
some_other_var = getappdata(0,'some_var')
You would use setappdata() in the m-file for fig1 to store whatever data you wanted to pass around, and then call getappdata() in another m-file to retrieve it. The argument 0 to the two functions specifies the MATLAB root workspace, which is accessible by your program everywhere (i.e. it is global). As such, when you close your figures that data will still be available. You may want to use rmappdata to remove them.
Method 2: Use guidata:
Assuming you created your GUI with GUIDE, then you have access to a structure called handles which is passed around everywhere and which you can edit, and so you can do this in a GUI callback:
handles.some_var = some_value
guidata(hObject,handles)
Then you can access handles.some_var elsewhere in some other callback (because handles is automatically passed into it for you) in your other m-file:
some_other_var = get(handles.some_var)
Method 3: Use UserData:
Store the variable you want from your first figure:
set(name_of_fig, 'UserData', some_var)
Then to get it from your other one:
some_other_var = get(name_of_fig, 'UserData')
(Disclaimer: My actual knowledge of MATLAB is not all that great, but it helps to be able to find good resources like this and this, and even this from the official docs. What I've written here may be wrong, so you should definitely consult the docs for more help.)
I would do like this (assuming you're using the GUI builder GUIDE).
Let's say that your figures/m-files are named firstFigure.fig/m and secondFigure.fig/m. In the code of firstFigure, just call secondFigure and pass your parameters as arguments:
someNumber = 1;
someText = 'test';
aMatrix = rand(3);
secondFigure(someNumber, someText, aMatrix);
The arguments will be available to secondFigure as a variable varargin in the callback functions
function varargout = secondFigure(varargin)
and
function secondFigure_OpeningFcn(hObject, eventdata, handles, varargin)
varagin is a cell structure; use cell2mat and char to convert it back:
theNumber = cell2mat(varargin(1));
theText = char(varargin(2));
theTextAgain = cell2mat(varargin(2));
theMatrix = cell2mat(varargin(3));
This may help:
http://www.mathworks.ch/matlabcentral/newsreader/view_thread/171989
The easiest method is to wrap the parameters in a cell array and send them directly to the GUI constructor. A call with two parameters might look like:
figure2({param1, param2})
Then you can unpack the arguments in the opening function (figure2_OpeningFcn) with code like:
handles.par1 = varargin{1}{1};
handles.par2 = varargin{1}{2};
These lines must be placed somewhere before the line that says guidata(hObject, handles);. Then you can access handles.par1 and handles.par2 directly in all the other callbacks.
I assume you are using GUIDE to generate your GUI. You can find figure2_OpeningFcn in figure2.m which will be located in the same directory as figure2.fig.
Note: you can also return values from a figure, returnvalue = my_figure({my_input}). If you'd like instructions on that too, leave a comment and I'll extend my answer.
When an error occurs in a function, I'd like to know the sequence of events that lead up to it, especially when that function is called from a dozen different places. Is there any way to retrieve the call stack in VB6, or do I have to do it the hard way (e.g., log entries in every function and error handler, etc.)?
You do have to do it the hard way, but it's not really all that hard... Seriously, once you've written the template once, it's a quick copy/paste/modify to match the function name in the Err.Raise statement to the actual function name.
Private Function DoSomething(ByVal Arg as String)
On Error GoTo Handler
Dim ThisVar as String
Dim ThatVar as Long
' Code here to implement DoSomething...
Exit Function
Handler:
Err.Raise Err.Number, , "MiscFunctions.DoSomething: " & Err.Description
End Function
When you have nested calls, this unwinds as each routine hits its Handler and adds its name to the error description. At the top level function, you get a "call stack" showing the list of routines that were called, and the error number and description of the error that actually occurred. It's not perfect, in that you don't get line numbers, but I've found that you don't usually need them to find your way to the problem. (And if you really want line numbers, you can put them in the function and reference them in the Err.Raise statement using the Erl variable. Without line numbers, that just returns 0.)
Also, note that within the function itself, you can raise your own errors with the values of interesting variables in the message like so:
Err.Raise PCLOADLETTER_ERRNUM, , "PC Load Letter error on Printer """ & PrinterName & """"
(The syntax highlighting looks wonky in the preview... I wonder how will it look when posted?)
I'm pretty sure you have to do it the hard way. At a previous job of mine, we had a very elegant error handling process for VB6 with DCOM components. However, it was a lot redundant code that had to be added to every method, so much that we had home-grown tools to insert it all for you.
I can't provide too much insight on its implementation (both because I've forgotten most of it and there's a chance they may consider it a trade secret). One thing that does stand out was that the method name couldn't be derived at run-time so it was added as a string variable (some developers would copy-paste instead of using the tool and it would lead to error stacks that lied...).
HTH
The hard, manual way is pretty much the only way. If you check out this question, someone suggested a tool called MZTools that will do much of the grunt work for you.
As other people said (years ago, I see... but there's so many people still using VB6! :) ), I think it's not possible to programmatically retrieve the Call Stack, unless you use some 3rd-party tool.
But if you need to do that for debugging purposes, you can consider of adding to the called routine an Optional input string variable, were you'll put the caller's name.
Sub MyRoutine
(...) ' Your code here
call DoSomething (Var1, Var2, Var3, "MyRoutine")
' ^
' Present routine's name -----------+
(...) ' Your code here
End Sub
Public DoSomething (DoVar1, DoVar2, DoVar3, Optional Caller as string = "[unknown]")
Debug.Print " DoSomething Routine Called. Caller = " & Caller
... ' (your code here)
End Sub
Not so elegant, maybe, but it worked for me.
Regards,
Max - Italy
Compuware (or was it Numega at the time) DevStudio for Visual Basic 6 used to do this. The way was by adding adding instrumenation to every call that called a very small snippet that added to the code stack. On any error it dumped out that callstack, and then did things like mail or post to a webserver all the debuging information. Adding and removing the instrumentation was a potentially lethal operation (especially back then, when we were using VSS as our source control), but if it worked, it work well.
As Darrel pointed out, you could add something very simlar by using MZTools and setting up a template. It's a lot of working, and is probably more effeort than the reward would be but if you have very difficult to track down bugs, it might help).