IRC Log Viewer » #firebreath » 2015-03-17

IRC Nick Time (GMT-7) Message
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.