I am trying to play with the sample application 'pcp' to send file between different directory.
The step is as following:
run receiver by /tmp/test1/pcp account#gmail.com
run sender by /tmp/test2/pcp account#gmail.com a.txt account#gmail.com/(full JID):a.txt
I always gets the "bus error:10" in the receiver side when running the sender.
I also tried to run in --verbose option and got more info. as follows:
[173:339] TunnelSessionClientBase::OnSessionCreate: received=1
[173:342] Session:12662708465646360189 Old state:STATE_INIT New state:STATE_RECEIVEDINITIATE Type:http://www.google.com/talk/securetunnel Transport:http://www.google.com/transport/p2p
[173:343] TunnelSession::OnSessionState(Session::STATE_RECEIVEDINITIATE)
IncomingTunnel from theeraphol.wat#gmail.com/pcpC89CFD53: recv:b.txt
[173:343] Session:12662708465646360189 Old state:STATE_RECEIVEDINITIATE New state:STATE_SENTACCEPT Type:http://www.google.com/talk/securetunnel Transport:http://www.google.com/transport/p2p
[173:343] TunnelSession::OnSessionState(Session::STATE_SENTACCEPT)
Bus error: 10
What am I doing wrong?
Related
I get a window ID from the command line, and create an SDL window with it:
Window window_id = from_cli(); // e.g. 0x34000c8
w = SDL_CreateWindowFrom((void*) (Window) window_id);
When my program finishes I try to clean up:
SDL_DestroyWindow(w);
And that is when I got an X11 error:
X Error of failed request: BadWindow (invalid Window parameter)
Major opcode of failed request: 3 (X_GetWindowAttributes)
Resource id in failed request: 0x34000c8
Serial number of failed request: 255
Current serial number in output stream: 256
Obviously, the caller of my program - which I cannot change - has already destroyed the X window I was using.
How should I handle this situation?
SDL_DestroyWindow() can be omitted if the SDL window was created with SDL_CreateWindowFrom()
go for SDL_SysWMinfo, pick up x11.display, create my own X11 error handler, and filter errors for window_id?
Looking at the SDL2-2.0.9 source code, it seems that SDL already sets an error handler, which calls the previous error handler, which is the default one that terminates the program on error. (src/video/x11/SDL_x11video.c::X11_SafetyNetErrHandler())
Internally SDL will override this error handler temporarily, when doing its own stuff. (src/video/x11/SDL_x11video.c::X11_CheckWindowManager())
Thus, I guess 2) is the correct way to go.
EDIT:
When omitting SDL_DestroyWindow(), SDL_Quit() will fail with the same X error.
I also realized that SDL may not anticipate a failed X call, so ignoring the error may not be a good idea, after all.
EDIT2:
I just realized that SetErrorHandler() does not require a display.
Adding an X error handler that ignores X errors regarding this particular X window seems to work, not sure if it creates new problems unseen.
Is there preferred way to handle this problem?
Version:
SDL2-2.0.9
I'm using a Telit UL865-NAD to connect to a webpage to get data from a php file.
The main problem is that the HTTPRCV command hangs.
See code below:
OK
AT#CIMI
#CIMI: 730011235559846
OK
AT+CCID
+CCID: 89560100000992123469
OK
AT+CGMI
Telit
OK
AT+CGMM
UL865-NAD
OK
AT+CGMR
12.00.716
OK
AT+CGDCONT=1,"IP","imovil.entelpcs.cl"
AT+CGDCONT=1,"IP","imovil.entelpcs.cl"
OK
AT#SGACT=1,1
#SGACT: 10.166.148.143
OK
AT#HTTPCFG=0,"www.xxxx-xxxxxx.com",80,0,,,0,120,1
AT#HTTPCFG=0,"www.xxxx-xxxxxx.com",80,0,,,0,120,1
OK
AT#HTTPQRY=0,0,"/Inagrap/"
OK
#HTTPRING: 0,200,"text/html;charset=ISO-8859-1",1136
AT#HTTPRCV=0
The AT#HTTPQRY command, refers to the directory where the php file resides.
A second issue,
If I include the php file:
AT#HTTPQRY=0,0,"/Inagrap/my.php?D1=val1&D2=val2..."
The HTTPRING indicates '0' data
*** Edit Further info
If I test the page through a browser it gives me a response, yet
testing through the modem, HTTPRING indicates '0' data.
The page inserts the data passed in with the GET, to a database.
If I access the page through a browser, data gets inserted into the database.
But run through the modem, nothing happens.
It's strange the modem gives me responses indicating that I connect to the page, it indicates a http status of 200, yet no data is returned and the web code is not executed.
Why?
After the AT#SGACT command, an AT&K0 command is required to turn off flow control.
Two days wracking my brain for this simple omission.
Just starting with noflo, I'm baffled as why I'm not able to get a simple flow working. I started today, installing noflo and core components following the example pages, and the canonical "Hello World" example
Read(filesystem/ReadFile) OUT -> IN Display(core/Output)
'package.json' -> IN Read
works... so far fine, then I wanted to change it slightly adding "noflo-rss" to the mix, and then changing the example to
Read(rss/FetchFeed) OUT -> IN Display(core/Output)
'http://xkcd.com/rss.xml' -> IN Read
Running like this
$ /node_modules/.bin/noflo-nodejs --graph graphs/rss.fbp --batch --register=false --debug
... but no cigar -- there is no output, it just sits there with no output at all
If I stick a console.log into the sourcecode of FetchFeed.coffee
parser.on 'readable', ->
while item = #read()
console.log 'ITEM', item ## Hack the code here
out.send item
then I do see the output and the content of the RSS feed.
Question: Why does out.send in rss/FetchFeed not feed the data to the core/Output for it to print? What dark magic makes the first example work, but not the second?
When running with --batch the process will exit when the network has stopped, as determined by a non-zero number of open connections between nodes.
The problem is that rss/FetchFeed does not open a connection on its outport, so the connection count drops to zero and the process exists.
One workaround is to run without --batch. Another one I just submitted as a pull request (needs review).
I am using yowsup-cli, and it prints the following when I run "yowsup-cli version" ...
yowsup-cli v2.0.13
Using yowsup v2.4
I am trying to perform the registration as specified in the yowsup documentation, as follows. However, it fails.
First, I entered this command, and I indeed got a code back via SMS ...
yowsup-cli registration --requestcode sms --phone 1XXXXXXXXXX --cc 1 --mcc 310 --mnc 260
I then entered this command using the code I got back (shown as "AAA-BBB"), but it failed ...
yowsup-cli registration --register AAA-BBB --phone 1XXXXXXXXXX --cc 1
This is the error message I received ...
status: fail
reason: missing
What I did above is exactly what is described in the yowsup documentation, here: https://github.com/tgalal/yowsup/wiki/yowsup-cli-2.0#yowsup-cli-registration%29 (see the commands listed under "Example:").
Note that I get the same failure when I add the MNC and MCC info to the "--register" command.
Does anyone know why this registration procedure is failing, and what might be "missing" in what I'm doing?
Note that the MCC and MNC I specified are what I found when looking up my cell provider (T-Mobile, USA).
Also, note that I am able to run WhatsApp with no problems from my mobile device, as well as via their web interface.
Thanks for any help and suggestions.
you do not have to put "-" in your otp/code. it will be a plain sms code
yowsup-cli registration --register AAABBB --phone 1XXXXXXXXXX --cc 1
i hope it works
I have a CDash configured to accept posts for automatic builds and tests. However, when any system attempts to post results to the CDash, the following error is produced. The result is that each result gets posted four times (presumably the original posting attempt plus the three retries).
Can anyone give me a hint as to what sets this mysterious build ID? I found some code that seems to produce a similar error, but still no lead on what might be happening.
Build::GetNumberOfErrors(): BuildId not set
Build::GetNumberOfWarnings(): BuildId not set
Submit failed, waiting 5 seconds...
Retry submission: Attempt 1 of 3
Server Response:
The buildid for CDash is computed based on the site name, the build name and the build stamp of the submission. You should have a Build.xml file in a Testing/20110311-* directory in your build tree. Open that up and see if any of those fields (near the top) is empty. If so, you need to set BUILDNAME and SITE with -D args when configuring with CMake. Or, set CTEST_BUILD_NAME and CTEST_SITE in your ctest -S script.
If that's not it, then this is a mystery. I've not seen this error occur before...
I'm having the same issue though Site and Buildname are available in test.xml and are visible on cdash (4 times). I can see the jobs increment by refreshing between retries so it seems that the submission succeeds and reports a timeout.
Update: This seems to have started when I added the -j(nprocs) switch to the ctest command. changing CtestSubmitRetryDelay: 20 (was 5) allowed a server response through that indicates the cdash version may not be able to handle the multi-proc option I'll have to look into that for my issue. Perhaps setting CtestSubmitRetryDelay to a larger number will get you back a server response as it did for me. g'luck!
Out of range value for column 'processorclockfrequency'