| Tim |
09:03 |
taxilian
Where should we start today?
|
| taxilian |
09:03 |
Tim hey, sorry I'm back to my desk now
run "file /buildex/projects/FBTestPlugin/RelWithDebInfo/FBTestPlugin.plugin/Contents/MacOS/FBTestPlugin"
|
| Tim |
09:03 |
Correction on the binary name. It's npFBTestPlugin
Correction on the binary name. It's npFBTestPlugin
|
| taxilian |
09:03 |
that makes quite a big difference
that makes quite a big difference
are you sure you're on the latest version of FireBreath from master?
are you sure you're on the latest version of FireBreath from master?
|
| Tim |
09:03 |
Nevermind, I was working in the wrong directory.
|
| taxilian |
09:03 |
because mine is FBTestPlugin, because it has a bug fix that was recently pushed (a month or so ago)
because mine is FBTestPlugin, because it has a bug fix that was recently pushed (a month or so ago)
|
| Tim |
09:03 |
Let me try again in the right directory.
Let me try again in the right directory.
|
| taxilian |
09:03 |
=]
=]
my naming scheme for the new FireBreath 2 plugin interface is getting out of hand
... and I've decided that I'm okay with that
I just created an AlienLarvae class which will be passed around a bit and used to create an AlienWyrmling
because where I need to package it up I don't yet know enough to create the AlienWyrmling
AlienWyrmling came out of the idea that the FireWyrm type that encapsulates a JSAPI object is a Wyrmling, so then I had LocalWyrmlings and AlienWyrmlings, depending on where they originated (the browser or the plugin)
... definitely getting out of hand
but quite entertaining
but quite entertaining
|
| Tim |
09:03 |
Just tried to execute it and it failed with a message "cannot execute binary file"
|
| taxilian |
09:03 |
don't execute it, run "file" on it
don't execute it, run "file" on it
[richard:~/code … _build/projects/FBTestPlugin/Debug/FBTestPlugin.plugin/Contents/MacOS] $ file FBTestPlugin
[richard:~/code … _build/projects/FBTestPlugin/Debug/FBTestPlugin.plugin/Contents/MacOS] $ file FBTestPlugin
FBTestPlugin: Mach-O universal binary with 2 architectures
FBTestPlugin: Mach-O universal binary with 2 architectures
FBTestPlugin (for architecture i386): Mach-O bundle i386
FBTestPlugin (for architecture x86_64): Mach-O 64-bit bundle x86_64
|
| Tim |
09:03 |
Sorry about that. Yes, I got those output after running file on it.
|
| taxilian |
09:03 |
okay
how did you install it?
and to be clear, it had both i386 and x86_64 listed?
|
| Tim |
09:03 |
Yes, it has both i386 and x86_64 listed.
|
| taxilian |
09:03 |
ok
|
| Tim |
09:03 |
I haven't installed it.
I did try copying it to ~/Library/Internet Plug-Ins directory.
|
| taxilian |
09:03 |
that would be one method of installing it
check the directory to make sure it's the correct version (filename is correct)
|
| Tim |
10:03 |
The filename is correct. What is the version and where do I check for it?
|
| taxilian |
10:03 |
when I say version, I mean make sure you got it from the correct directory
and didn't get the np one =]
which browser are you trying it on?
|
| Tim |
10:03 |
Got it on the version. It's not the np naming.
Got it on the version. It's not the np naming.
Open the test page with Safari.
Open the test page with Safari.
|
| taxilian |
10:03 |
and still doesn't work?
|
| Tim |
10:03 |
Nevermind. Got it to load.
|
| taxilian |
10:03 |
oh good
that's progress
|
| Tim |
10:03 |
It working on OSX 10.9 which is the same platform that it's built on.
|
| taxilian |
10:03 |
to be honest, I haven't tried building on 10.9 or 10.10 then running an older version; I think our build server is running 10.8
and targeting 10.6
|
| Tim |
10:03 |
Clicked on "Click me!" link and got feedback from it. As for the other 2 links, I didn't see any kind of response.
|
| taxilian |
10:03 |
are you using FBControl or test.html?
|
| Tim |
10:03 |
FBControl
|
| taxilian |
10:03 |
okay; that's not much of a test page, generally recommend you open the console and interact with it directly to check functionality
okay; that's not much of a test page, generally recommend you open the console and interact with it directly to check functionality
or open test.html
or open test.html
|
| Tim |
10:03 |
I not able to find test.html file. Please provide info on how interact with it directly to check functionality via the console.
|
| taxilian |
10:03 |
it's in examples/FBTestPlugin/
it's in examples/FBTestPlugin/
but rather than tell you what to do, I'm going to suggest that you go into FBTestPluginAPI.cpp and look around to see what methods are exposed and then try them
because you'll be far better off if you figure out this part yourself
|
| Tim |
10:03 |
Seeing the test being run.
It all looks good.
|
| taxilian |
10:03 |
sounds like things are working, then
|
| Tim |
10:03 |
I'll try it out on an older OSX version.
I'll try it out on an older OSX version.
Unless this example uses the newer API from the latest SDK, it's unlikely that I'll run into the same issue that I have with my app when running on an older version of OSX which contains the older SDK.
|
| taxilian |
10:03 |
entirely possible; however, it's always helpful to make sure the basics are in place before you move on
your actual issue isn't so much a FireBreath issue as it is a cmake issue, I suspect
so if you've been searching for firebreath specific resources you're far less likely to find them than if you look for a solution to the problem from other people using cmake
since we've established that FireBreath itself is working correctly
|
| Tim |
10:03 |
Install FBTestPlugin on an OSX 10.8.5. The test page ran successfully on it.
Install FBTestPlugin on an OSX 10.8.5. The test page ran successfully on it.
|
| taxilian |
10:03 |
cool
cool
so your issue is very specific to that particular library
so your issue is very specific to that particular library
at this point I'd take one of two approaches: 1) go back to your plugin and try now that you know what does work, or 2) try adding a call to the library to FBTestPlugin, thus helping you track down exactly what is introducing the issue
|
| Tim |
10:03 |
Yes.
OK. Based on the loading error, it's the sincos API in the libSystem library.
|
| taxilian |
10:03 |
and what was the specific error agin?
|
| Tim |
11:03 |
Error loading /Library/Internet Plug-Ins/SPlayer.plugin/Contents/MacOS/SPlayer: dlopen(/Library/Internet Plug-Ins/SPlayer.plugin/Contents/MacOS/SPlayer, 262): Symbol not found: ___sincos_stret Referenced from: /Library/Internet Plug-Ins/SPlayer.plugin/Contents/MacOS/SPlayer Expected in: /usr/lib/libSystem.B.dylib in /Library/Internet Plug-Ins/SPlayer.plugin/Contents/MacOS/SPla
|
| taxilian |
11:03 |
hmm. so this looks related: http://stackoverflow.com/questions/19015780/sincos-stret-undefined-symbol-when-linking
but just for more info, not a solution
but just for more info, not a solution
hmm. it looks to me like the only way you're going to solve that is to either set the deployment target to 10.9 or to use the 10.8 sdk; did you say you found a way to solve it if you edit things directly in xcode?
|
| Tim |
11:03 |
I have a different xcode project that creates an app. It links to the same libraries as the my plugin project. That xcode project for the app was create manually with xcode.
|
| Tim |
11:03 |
I've already tried deployment target of 10.9. Issue still persist.
Can't use 10.8 SDK because one of our library requires the 10.9 SDK since it using the new APIs in the newer SDK (i.e. sincos).
Can't use 10.8 SDK because one of our library requires the 10.9 SDK since it using the new APIs in the newer SDK (i.e. sincos).
|
| taxilian |
11:03 |
Tim: if you can figure out what that project does differently when it calls either the compile or link step then I might be able to help you
Tim: if you can figure out what that project does differently when it calls either the compile or link step then I might be able to help you
with cmake that's often the key
xcode is actually calling the compiler to do the compilation, so you should be able to look at the link step and figure out what is done differently
that will be your key to fixing the issue
kylehuff: I just got the C++ side of FireWyrm in the FireBreath2 project to build; I'm sure I'm missing something but I think for the most part it should be ready for me to create the native messaging implementation for it
kylehuff: I just got the C++ side of FireWyrm in the FireBreath2 project to build; I'm sure I'm missing something but I think for the most part it should be ready for me to create the native messaging implementation for it
|
| taxilian |
13:03 |
kylehuff whenever you're around I'm getting into the part that would definitely benefit from your active involvement =]
|
| kylehuff |
14:03 |
taxilian: I probably won't have any time today (I have several school assignments due), but I should be getting off work around noon (EST) tomorrow with no known plans.
|
| taxilian |
14:03 |
well, if you have some time tomorrow I'd love your help
I'm writing the native messaging host shim now...
kylehuff will you be around today at all if I have quick questions?
|
| kylehuff |
14:03 |
taxilian: yeah, I'll be around. just give me a shout
taxilian: yeah, I'll be around. just give me a shout
|
| taxilian |
14:03 |
do you by chance have 5-10 minutes you could give me a brief rundown on how the stdin/stdout stuff works via phone or skype?
kylehuff ^
if not no prob, I'll probably figure it out; it would just save me some time and guesswork
|
| kylehuff |
14:03 |
by phone I'm available. I'm likely not going to have the CPU power for video at the moment tho
|
| taxilian |
14:03 |
that's fine; pm me a number (or I can pm you, whichever)
|
| taxilian |
15:03 |
kylehuff so does native messaging allow binary data or not? looks like there is no reason for it not to...
|
| kylehuff |
15:03 |
taxilian: the native messaging API only accepts (valid) JSON formatted strings of text.
|
| taxilian |
15:03 |
... huh
that's weird
|
| kylehuff |
15:03 |
well, let me do some checking, because that used to be true, maybe that isn't the case anymore
|
| taxilian |
15:03 |
it's just that the way this protocol works it doesn't make sense why that would be the case
|
| kylehuff |
15:03 |
"Chrome starts each native messaging host in a separate process and communicates with it using standard input (stdin) and standard output (stdout). The same format is used to send messages in both directions: each message is serialized using JSON, UTF-8 encoded and is preceded with 32-bit message length in native byte order."
https://developer.chrome.com/extensions/nativeMessaging#native-messaging-host-protocol
|
| taxilian |
15:03 |
yeah, just found that
was about to paste it and my phone rang :-P
very interesting
very interesting
|
| kylehuff |
15:03 |
well, I was saved by the bell... literally.
well, I was saved by the bell... literally.
|
| taxilian |
15:03 |
hehe
|
| kylehuff |
15:03 |
also, it mentions in the same blurb about the 1MB response limit. although, it supports sending a message TO the host with a size of 4GB... whoa nelly..
|
| taxilian |
15:03 |
the frustrating thing is that I want to pass a string into FireBreath... but I'm going to need to pull a certain amount of data from the string
on the browser side do we serialize it ourselves or does Chrome do that?
on the browser side do we serialize it ourselves or does Chrome do that?
|
| kylehuff |
15:03 |
let me check, IIRC, it wants a valid JSON string
taxilian: it accepts just a simple string
*also accepts
|
| taxilian |
15:03 |
interesting
but does it expect that string to be json?
|
| kylehuff |
15:03 |
I was able to send it merely a quoted string "testing", and it was sent to the native messaging binary, and the binary returned. I believe the same is true for return data.
|
| taxilian |
15:03 |
and it sent it as a quoted string, I assume? e.g. it send "testing" not testing
and it sent it as a quoted string, I assume? e.g. it send "testing" not testing
|
| kylehuff |
15:03 |
I believe yes, I could verify, but I wouldn't be able to do it today.
|