You are viewing a plain text version of this content. The canonical link for it is here.
Posted to proton@qpid.apache.org by Ernest Allen <ea...@redhat.com> on 2014/08/22 20:34:58 UTC
proton javascript binding problem/question
I may have discovered a problem with the javascript bindings for proton that I got from: git+ssh://git.app.eng.bos.redhat.com/srv/git/rh-qpid-proton.git branch origin/fadams-javascript-binding
After the build, I got an error when running the examples. Specifically, this is what I got:
node spout.js
module.js:340
throw err;
^
Error: Cannot find module 'qpid-proton'
at Function.Module._resolveFilename (module.js:338:15)
at Function.Module._load (module.js:280:25)
at Module.require (module.js:364:17)
at require (module.js:380:17)
at Object.<anonymous> (/home/ernie/jsbindings/rh-qpid-proton/examples/messenger/javascript/spout.js:24:14)
at Module._compile (module.js:456:26)
at Object.Module._extensions..js (module.js:474:10)
at Module.load (module.js:356:32)
at Function.Module._load (module.js:312:12)
at Function.Module.runMain (module.js:497:10)
After verifying my environment, I finally tracked it down to the node_modules/qpid-proton directory. The build creates a file named lib in that directory. It should create a directory named lib that contains a file named proton.js in it.
When I renamed the lib file to proton.js, created a lib directory and moved the file under it, all was well.
I did not do a make install, so I was just running the examples from my git checkout directory.
I'm not familiar enough with the cmake files to track this down any further, so I'm hoping someone here can provide the fix.
-Ernie Allen
Re: proton javascript binding problem/question
Posted by Fraser Adams <fr...@blueyonder.co.uk>.
On 11/09/14 15:25, Dominic Evans wrote:
> fadams wrote
>> What do you think of the approach that I've taken? My rationale for
>> compiling proton-c to JavaScript and using a thin (ish) binding layer
>> rather than doing a ground-up "native" JavaScript rewrite was primarily
>> about support. I figured that there was a lot of effort being put into
>> maintaining proton-c and that was what might be considered the
>> "canonical" or reference implementation, so tracking improvements would
>> end up being a pain with a separate code-base, whereas the binding to a
>> compiled library just needs to cover the public API and ultimately I
>> should pick up improvements to the core code "transparently". If you
>> look at what I've done you'll hopefully see a startling similarity with
>> the SWIG bindings particularly the Python one.
> Hi Fraser,
>
> For the first version of our Node.js client, we ended up writing our light
> C++ module to access the bits of proton-c that we needed and bridge to
> Javascript. At the time I wasn't aware of your javascript branch, else we
> would have looked at using that first.
>
> However, I did recently also notice that SWIG-3.0.1 has now added a
> Javascript module for generating Node.js and Javascript bindings in the same
> way as is currently done for Python, Ruby etc. I wonder how that would
> compare to your emscripten approach?
>
> http://www.swig.org/Release/RELEASENOTES
>
> Cheers,
> Dom
>
Hi Dominic,
Yeah I noticed the SWIG thing too recently, though can't recall where -
ISTR it was done as part of Google Summer of Code or something.
I can't say for sure, but my "guess" is that the approach is a bit
different.
At a guess (and I've not really looked at it yet much less played) the
SWIG bindings are about being able to integrate/bind with native C/C++
to JavaScript - pretty much analogous to how similar things work with
say Python/Perl etc. I suspect that the result is that the JavaScript
will only be functional from a node.js environment and not a browser.
With the emscripten based approach I'm essentially cross-compiling (or
transpiling or whatever you might want to call it) to pure JavaScript,
in practice to a subset of JavaScript called asm.js that is optimised
for ahead of time compilation in the execution engine (recent versions
of Firefox and I think V8 have optimisations for asm.js).
There are relative pros and cons to each.
I think using SWIG will be closer to the approach that you've already
taken - though it's not free and it'll need a wrapper somewhat similar
to what I've done in order to make it "friendly" JavaScript. The
advantages are
1 - it'll *probably* perform better because it's a thin wrapper to
native code, though by how much I couldn't say yet, with the most recent
JavaScript engines the margin likely erodes but I'd suspect it'd perform
better whatever.
2 - you are wrapping the C library and you'll be using TCP sockets (The
emscripten version is pure JavaScript and uses WebSockets by default,
though on my TODO list is to look at configurably using the node net
library to use native TCP sockets).
Conversely
The emscripten based approach is pure JavaScript so runs happily in a
browser or node.js. It supports WebSockets and WebRTC (though I've not
tried the latter yet) though not (currently) TCP Sockets (though I've
written a simple WS->TCP proxy that works pretty well).
I've still got a bit of tinkering and tidying up of the emscripten based
JavaScript binding, but I'd quite like to get it moved to proton trunk
before too long. Once it's settled then I'll move on to my TODO list.
FWIW I'm not averse to looking at the SWIG binding too, as I say unless
my interpretation is wrong there are relative pros and cons to each and
I suspect that they are complementary and not competing approaches.
As I say I suspect that the SWIG approach would need Binding code
similar to what I've done with emscripten in order to be any fun to use
and if a complementary SWIG based binding was contemplated I'd really
want to be using the same patterns/API as for the emscripten based one.
I'd hope that this wouldn't end up being a whole duplicate as that would
be a bit tedious, so I'd expect some relatively non-trivial refactoring
to try and have as much shared as possible (take a look at the
binding.js, none of it's necessarily rocket science but there was a lot
of effort in the proton.Data part to try and make things as nicely
idiomatically JavaScript as possible).
What I discovered was that compiling the C to JavaScript using
emscripten was easy and took me a few weekends of hacking, doing all the
binding stuff has taken the best part of a year of spare time (OK not
solid effort, but you get the picture)
Does that answer your question?
Are you the same Dominic Evans who's just filled up my in-box with Jira
messages? I got home from work and opened my emails and OMG!!!! :-D
Cheers, and thanks for taking an interest in the JavaScript bindings.
Frase
Re: proton javascript binding problem/question
Posted by Dominic Evans <do...@uk.ibm.com>.
fadams wrote
> What do you think of the approach that I've taken? My rationale for
> compiling proton-c to JavaScript and using a thin (ish) binding layer
> rather than doing a ground-up "native" JavaScript rewrite was primarily
> about support. I figured that there was a lot of effort being put into
> maintaining proton-c and that was what might be considered the
> "canonical" or reference implementation, so tracking improvements would
> end up being a pain with a separate code-base, whereas the binding to a
> compiled library just needs to cover the public API and ultimately I
> should pick up improvements to the core code "transparently". If you
> look at what I've done you'll hopefully see a startling similarity with
> the SWIG bindings particularly the Python one.
Hi Fraser,
For the first version of our Node.js client, we ended up writing our light
C++ module to access the bits of proton-c that we needed and bridge to
Javascript. At the time I wasn't aware of your javascript branch, else we
would have looked at using that first.
However, I did recently also notice that SWIG-3.0.1 has now added a
Javascript module for generating Node.js and Javascript bindings in the same
way as is currently done for Python, Ruby etc. I wonder how that would
compare to your emscripten approach?
http://www.swig.org/Release/RELEASENOTES
Cheers,
Dom
--
View this message in context: http://qpid.2158936.n2.nabble.com/proton-javascript-binding-problem-question-tp7612394p7613505.html
Sent from the Apache Qpid Proton mailing list archive at Nabble.com.
Re: proton javascript binding problem/question
Posted by Ernest Allen <ea...@redhat.com>.
> > Unfortunately, just changing the CMakeFiles.txt to
> > ${PROJECT_SOURCE_DIR}/node_modules/qpid-proton/lib/
> > doesn't work. I get an error since the directory doesn't exist.
> Shame it doesn't work, though I guess not surprising. I'm torn between
> having the trailing slash or not, though you say that with it you get an
> error. Perhaps getting an error is preferable? In your case you had a
> silent issue originally, would an error have helped you track things
> down more quickly?
It probably would have. I would have seen that the build didn't complete instead of looking into possible environment problems with NODE_PATH. However, once I found the file package.json and saw that it referenced "./lib/proton.js", the work-around was clear. However, this isn't really the class of problem that you'd normally guard against.
>
> >
> > When I create the "lib" dir before the build, everything works as expected.
> > The real solution is to create the empty "lib" dir in the Red Hat
> > repository. I'll look into doing that.
> > When I pull the source from the public svn link, everything builds just
> > fine.
> I'm glad that the public svn link works, yay!!
>
> >
> > Thanks for looking into this.
> > -Ernie Allen
> >
> No probs, it's been my personal little baby for a while now, so it's a
> good thing that others are starting to take a peek. I think that quality
> wise it's pretty decent and pretty well commented and I think that the
> functional behaviour is largely all in place, but I haven't really
> looked at optimisation/profiling yet.
>
> What do you think of the approach that I've taken? My rationale for
> compiling proton-c to JavaScript and using a thin (ish) binding layer
> rather than doing a ground-up "native" JavaScript rewrite was primarily
> about support. I figured that there was a lot of effort being put into
> maintaining proton-c and that was what might be considered the
> "canonical" or reference implementation, so tracking improvements would
> end up being a pain with a separate code-base, whereas the binding to a
> compiled library just needs to cover the public API and ultimately I
> should pick up improvements to the core code "transparently". If you
> look at what I've done you'll hopefully see a startling similarity with
> the SWIG bindings particularly the Python one. I spent some effort
> contributing to emscripten too, putting things in place so that proton-c
> compiles cleanly (if you look in
> fadams-javascript-binding/bld/proton-c/bindings/javascript/examples you
> will see recv-async.js and send-async.js, which are actually the results
> of directly compiling recv-async.c and send-async.c. Those were the
> first things I got working before I started on the binding stuff - I
> figured that JavaScript programmers probably wouldn't enjoy using a C
> API ;->)
IANAOPS (I am not an official Proton spokesperson) but I personally agree with your approach. I doubt there is much of a downside to using a binding as opposed to a "native" JavaScript implementation. And the upside is huge, especially for bug fixes and enhancements.
>
> I did a bit of work on the qpid-config port yesterday and it now does
> everything the python one does (well except the xml binding support at
> the moment as that loads a file). I'm currently trying to get it to work
> with the Java Broker (see my Java Broker AMQP 1.0 support - is it by
> default? post to the users list).
You've done some very impressive work here. I'm looking forward to trying it out.
-Ernie
Re: proton javascript binding problem/question
Posted by Fraser Adams <fr...@blueyonder.co.uk>.
Hi Ernie
> . In that repository the
> fadams-javascript-binding/proton-c/bindings/javascript/qpid-proton does NOT contain a "lib" directory. It only contains the files: LICENSE package.json README.md
Yeah that's likely to be the root of your problem, without that lib
directory being in place the copy command will indeed copy proton.js to
a file called lib
>
> My guess is that since "lib" is an empty directory, it got lost when our internal repository was created.
:-)
>
> Unfortunately, just changing the CMakeFiles.txt to
> ${PROJECT_SOURCE_DIR}/node_modules/qpid-proton/lib/
> doesn't work. I get an error since the directory doesn't exist.
Shame it doesn't work, though I guess not surprising. I'm torn between
having the trailing slash or not, though you say that with it you get an
error. Perhaps getting an error is preferable? In your case you had a
silent issue originally, would an error have helped you track things
down more quickly?
>
> When I create the "lib" dir before the build, everything works as expected.
> The real solution is to create the empty "lib" dir in the Red Hat repository. I'll look into doing that.
> When I pull the source from the public svn link, everything builds just fine.
I'm glad that the public svn link works, yay!!
>
> Thanks for looking into this.
> -Ernie Allen
>
No probs, it's been my personal little baby for a while now, so it's a
good thing that others are starting to take a peek. I think that quality
wise it's pretty decent and pretty well commented and I think that the
functional behaviour is largely all in place, but I haven't really
looked at optimisation/profiling yet.
What do you think of the approach that I've taken? My rationale for
compiling proton-c to JavaScript and using a thin (ish) binding layer
rather than doing a ground-up "native" JavaScript rewrite was primarily
about support. I figured that there was a lot of effort being put into
maintaining proton-c and that was what might be considered the
"canonical" or reference implementation, so tracking improvements would
end up being a pain with a separate code-base, whereas the binding to a
compiled library just needs to cover the public API and ultimately I
should pick up improvements to the core code "transparently". If you
look at what I've done you'll hopefully see a startling similarity with
the SWIG bindings particularly the Python one. I spent some effort
contributing to emscripten too, putting things in place so that proton-c
compiles cleanly (if you look in
fadams-javascript-binding/bld/proton-c/bindings/javascript/examples you
will see recv-async.js and send-async.js, which are actually the results
of directly compiling recv-async.c and send-async.c. Those were the
first things I got working before I started on the binding stuff - I
figured that JavaScript programmers probably wouldn't enjoy using a C
API ;->)
I did a bit of work on the qpid-config port yesterday and it now does
everything the python one does (well except the xml binding support at
the moment as that loads a file). I'm currently trying to get it to work
with the Java Broker (see my Java Broker AMQP 1.0 support - is it by
default? post to the users list).
Cheers,
Frase
Re: proton javascript binding problem/question
Posted by Ernest Allen <ea...@redhat.com>.
Hi Fraser. Sorry for the delay.
I'm using linux (Fedora 20), but I think the discrepancy is in the repository. I was using the internal Red Hat git repository (which I inadvertently listed in the email and have been chastised for). In that repository the
fadams-javascript-binding/proton-c/bindings/javascript/qpid-proton does NOT contain a "lib" directory. It only contains the files: LICENSE package.json README.md
My guess is that since "lib" is an empty directory, it got lost when our internal repository was created.
Unfortunately, just changing the CMakeFiles.txt to
${PROJECT_SOURCE_DIR}/node_modules/qpid-proton/lib/
doesn't work. I get an error since the directory doesn't exist.
When I create the "lib" dir before the build, everything works as expected.
The real solution is to create the empty "lib" dir in the Red Hat repository. I'll look into doing that.
When I pull the source from the public svn link, everything builds just fine.
Thanks for looking into this.
-Ernie Allen
----- Original Message -----
From: "Fraser Adams" <fr...@blueyonder.co.uk>
To: proton@qpid.apache.org
Sent: Sunday, August 24, 2014 5:28:32 AM
Subject: Re: proton javascript binding problem/question
Hi again Ernie,
I've not heard back from you so I'm wondering how you are getting on?
I've still no idea what environment you are running.
One thought that I had though..
As I mentioned in my previous mail the place that copies proton.js is in
fadams-javascript-binding/proton-c/bindings/javascript/CMakeLists.txt
the relevant bit is (line 244):
COMMAND ${CMAKE_COMMAND}
-E copy
${CMAKE_CURRENT_BINARY_DIR}/proton.js
${PROJECT_SOURCE_DIR}/node_modules/qpid-proton/lib
I *wonder* if changing line 244 to
${PROJECT_SOURCE_DIR}/node_modules/qpid-proton/lib/
i.e. adding a slash at the end will sort things out for you.
On my Linux box I don't need that, but it may be that other OSes do?
Could you give that a try and let me know?
Frase
On 23/08/14 17:11, Fraser Adams wrote:
> Hi Ernie,
> Firstly bear in mind that it's still a bit of a work in progress :-)
> though it's getting pretty close to something I'd want to put onto the
> main branch, mostly just tidying stuff up now and adding a few more
> tests and examples.
>
>
> That said it was working fine for me when I made the last commit a
> couple of weeks ago (r1583389 I think)
>
> I've just done a make from scratch
> cd fadams-javascript-binding
> mkdir bld
> cd bld
> cmake ..
> make
>
> in my fadams-javascript-binding directory I have a node_modules and in
> that a qpid-proton directory.
>
> However in my qpid-proton directory I have
> a *directory* named lib and three files named LICENCE, package.json
> and README.md
>
> in the lib directory I have a file named proton.js
>
> which is I think exactly what I'd expect to see.
>
> I have no idea why you are seeing a *file* named lib in qpid-proton :-(
>
>
> I'm using Linux, I don't suppose that you are using some other OS by
> any chance? At a guess it's something different between how CMake
> works between Linux and Windows, but that's just a guess and if you
> are using Linux then it's really weird.
>
> What the make ends up doing is copying the qpid-proton directory and
> contents from fadams-javascript-binding/proton-c/bindings/javascript
> to the node_modules under fadams-javascript-binding then copying the
> proton.js built by the maike into the relevant subdirectory. The
> relevant bit from the CMakeLists.txt under
> fadams-javascript-binding/proton-c/bindings/javascript is:
>
> # This command packages up the compiled proton.js into a node.js
> package called
> # qpid-proton and copies it to the <proton>/node_modules directory.
> This allows
> # the node.js test and example programs to do proton =
> require("qpid-proton");
> add_custom_command(
> TARGET proton.js
> COMMAND ${CMAKE_COMMAND}
> -E copy_directory
> ${CMAKE_CURRENT_SOURCE_DIR}/qpid-proton
> ${PROJECT_SOURCE_DIR}/node_modules/qpid-proton
> COMMAND ${CMAKE_COMMAND}
> -E copy
> ${CMAKE_CURRENT_BINARY_DIR}/proton.js
> ${PROJECT_SOURCE_DIR}/node_modules/qpid-proton/lib
> COMMENT "Building qpid-proton package for node.js"
> )
>
>
> I'm no sort of CMake expert I'm afraid I mostly wing it with help from
> Mr Google, but as I say above that *should* copy the directory
> qpid-proton and its contents from
> fadams-javascript-binding/proton-c/bindings/javascript to
> fadams-javascript-binding then copy proton.js to
> fadams-javascript-binding/node_modules/qpid-proton/lib
>
> Out of curiosity what do you see in
> fadams-javascript-binding/proton-c/bindings/javascript/qpid-proton
> (i.e. the directory that is being copied to nod_modules) is the lib
> you are seeing there a file or a directory?
>
> I'm seeing a directory there too and when I look in subversion at
> http://svn.apache.org/repos/asf/qpid/proton/branches/fadams-javascript-binding/proton-c/bindings/javascript/qpid-proton/
>
>
> I'm seeing a directory called lib too, if you are seeing a file there
> then I wonder if it's something weird with the git->svn bridge, but
> I'm clutching at straws.
>
>
> Hmmm re-reading your mail you say "When I renamed the lib file to
> proton.js, created a lib directory and moved the file under it, all
> was well. " that's suggesting that proton.js got copied to a file
> called lib rather than into the directory called lib, so that second
> CMake COMMAND:
> "
> COMMAND ${CMAKE_COMMAND}
> -E copy
> ${CMAKE_CURRENT_BINARY_DIR}/proton.js
> ${PROJECT_SOURCE_DIR}/node_modules/qpid-proton/lib
> "
>
> certainly copies proton.js into node_modules/qpid-proton/lib for me on
> my Linux box, but that is the most likely place for things behaving
> differently between us...
>
>
>
> BTW:
> 1. You shouldn't need to do a make install, just doing make should
> copy this stuff I wanted to make sure a top level node_modules was in
> place so that the tests and demos work without too much fuss (clearly
> I was delusional :-D)
>
> 2. The spout.js and drain.js are currently *very* hacky (they just
> print "spout not implemented yet" and exit ;->) the send.js and
> recv.js and client.js and server.js should work pretty much as per the
> normal proton examples of the same name and qpid-config.js is pretty
> much complete (just the *generic* list mechanism to list AMQP 1.0 QMF
> objects still to do).
>
> 3. One thing to bear in mind is that this stuff uses a *websocket*
> transport, hopefully that's fairly obvious as it's JavaScript, but
> perhaps not. I've tried it against the Java Broker's websocket
> transport (though not for a couple of months and I've not tried
> qpid-config.js with the QMF plugin yet either). If you want to talk to
> the C++ broker I've included a simple node.js based WebSocket->TCP
> proxy (proxy.js). On my TODO list is to put some more work into the
> emscripten network library so that it's possible to configurably
> choose websockets or TCP sockets (using the standard node net library)
>
> Hopefully this gives you a few pointers, do let me know how you get
> on, though I'm not getting a lot of computer time at the moment as I'm
> digging loads of holes for fence posts :-(
>
> Frase
>
>
> On 22/08/14 19:34, Ernest Allen wrote:
>> I may have discovered a problem with the javascript bindings for
>> proton that I got from:
>> git+ssh://git.app.eng.bos.redhat.com/srv/git/rh-qpid-proton.git
>> branch origin/fadams-javascript-binding
>>
>> After the build, I got an error when running the examples.
>> Specifically, this is what I got:
>> node spout.js
>>
>> module.js:340
>> throw err;
>> ^
>> Error: Cannot find module 'qpid-proton'
>> at Function.Module._resolveFilename (module.js:338:15)
>> at Function.Module._load (module.js:280:25)
>> at Module.require (module.js:364:17)
>> at require (module.js:380:17)
>> at Object.<anonymous>
>> (/home/ernie/jsbindings/rh-qpid-proton/examples/messenger/javascript/spout.js:24:14)
>> at Module._compile (module.js:456:26)
>> at Object.Module._extensions..js (module.js:474:10)
>> at Module.load (module.js:356:32)
>> at Function.Module._load (module.js:312:12)
>> at Function.Module.runMain (module.js:497:10)
>>
>> After verifying my environment, I finally tracked it down to the
>> node_modules/qpid-proton directory. The build creates a file named
>> lib in that directory. It should create a directory named lib that
>> contains a file named proton.js in it.
>> When I renamed the lib file to proton.js, created a lib directory and
>> moved the file under it, all was well.
>>
>> I did not do a make install, so I was just running the examples from
>> my git checkout directory.
>>
>> I'm not familiar enough with the cmake files to track this down any
>> further, so I'm hoping someone here can provide the fix.
>>
>> -Ernie Allen
>>
>
Re: proton javascript binding problem/question
Posted by Robbie Gemmell <ro...@gmail.com>.
The directory doesnt exist for Ernie because he used a Git repo. While
there is an empty dir in the source svn repo, anyone using Git will not get
the dir because git only versions files, and so effectively 'doesnt see'
the empty dir precisely because there is nothing in it.
The general solutions here are to avoid the need for the empty dir to be
there up front or to actually put something in it that makes git create it,
typically an unused .gitignore file, which I have just added to svn:
http://svn.apache.org/r1620859
Now that it has worked through the Git mirrors you can see the lib dir on
GitHub, which you couldnt before:
https://github.com/apache/qpid-proton/tree/fadams-javascript-binding/proton-c/bindings/javascript/qpid-proton
On 24 August 2014 10:28, Fraser Adams <fr...@blueyonder.co.uk> wrote:
> Hi again Ernie,
> I've not heard back from you so I'm wondering how you are getting on? I've
> still no idea what environment you are running.
>
> One thought that I had though..
>
> As I mentioned in my previous mail the place that copies proton.js is in
> fadams-javascript-binding/proton-c/bindings/javascript/CMakeLists.txt
>
> the relevant bit is (line 244):
>
>
> COMMAND ${CMAKE_COMMAND}
> -E copy
> ${CMAKE_CURRENT_BINARY_DIR}/proton.js
> ${PROJECT_SOURCE_DIR}/node_modules/qpid-proton/lib
>
>
> I *wonder* if changing line 244 to
> ${PROJECT_SOURCE_DIR}/node_modules/qpid-proton/lib/
>
> i.e. adding a slash at the end will sort things out for you.
>
> On my Linux box I don't need that, but it may be that other OSes do?
>
> Could you give that a try and let me know?
>
> Frase
>
>
>
> On 23/08/14 17:11, Fraser Adams wrote:
>
>> Hi Ernie,
>> Firstly bear in mind that it's still a bit of a work in progress :-)
>> though it's getting pretty close to something I'd want to put onto the main
>> branch, mostly just tidying stuff up now and adding a few more tests and
>> examples.
>>
>>
>> That said it was working fine for me when I made the last commit a couple
>> of weeks ago (r1583389 I think)
>>
>> I've just done a make from scratch
>> cd fadams-javascript-binding
>> mkdir bld
>> cd bld
>> cmake ..
>> make
>>
>> in my fadams-javascript-binding directory I have a node_modules and in
>> that a qpid-proton directory.
>>
>> However in my qpid-proton directory I have
>> a *directory* named lib and three files named LICENCE, package.json and
>> README.md
>>
>> in the lib directory I have a file named proton.js
>>
>> which is I think exactly what I'd expect to see.
>>
>> I have no idea why you are seeing a *file* named lib in qpid-proton :-(
>>
>>
>> I'm using Linux, I don't suppose that you are using some other OS by any
>> chance? At a guess it's something different between how CMake works between
>> Linux and Windows, but that's just a guess and if you are using Linux then
>> it's really weird.
>>
>> What the make ends up doing is copying the qpid-proton directory and
>> contents from fadams-javascript-binding/proton-c/bindings/javascript to
>> the node_modules under fadams-javascript-binding then copying the proton.js
>> built by the maike into the relevant subdirectory. The relevant bit from
>> the CMakeLists.txt under fadams-javascript-binding/proton-c/bindings/javascript
>> is:
>>
>> # This command packages up the compiled proton.js into a node.js package
>> called
>> # qpid-proton and copies it to the <proton>/node_modules directory. This
>> allows
>> # the node.js test and example programs to do proton =
>> require("qpid-proton");
>> add_custom_command(
>> TARGET proton.js
>> COMMAND ${CMAKE_COMMAND}
>> -E copy_directory
>> ${CMAKE_CURRENT_SOURCE_DIR}/qpid-proton
>> ${PROJECT_SOURCE_DIR}/node_modules/qpid-proton
>> COMMAND ${CMAKE_COMMAND}
>> -E copy
>> ${CMAKE_CURRENT_BINARY_DIR}/proton.js
>> ${PROJECT_SOURCE_DIR}/node_modules/qpid-proton/lib
>> COMMENT "Building qpid-proton package for node.js"
>> )
>>
>>
>> I'm no sort of CMake expert I'm afraid I mostly wing it with help from Mr
>> Google, but as I say above that *should* copy the directory qpid-proton and
>> its contents from fadams-javascript-binding/proton-c/bindings/javascript
>> to fadams-javascript-binding then copy proton.js to
>> fadams-javascript-binding/node_modules/qpid-proton/lib
>>
>> Out of curiosity what do you see in fadams-javascript-binding/
>> proton-c/bindings/javascript/qpid-proton (i.e. the directory that is
>> being copied to nod_modules) is the lib you are seeing there a file or a
>> directory?
>>
>> I'm seeing a directory there too and when I look in subversion at
>> http://svn.apache.org/repos/asf/qpid/proton/branches/
>> fadams-javascript-binding/proton-c/bindings/javascript/qpid-proton/
>>
>> I'm seeing a directory called lib too, if you are seeing a file there
>> then I wonder if it's something weird with the git->svn bridge, but I'm
>> clutching at straws.
>>
>>
>> Hmmm re-reading your mail you say "When I renamed the lib file to
>> proton.js, created a lib directory and moved the file under it, all was
>> well. " that's suggesting that proton.js got copied to a file called lib
>> rather than into the directory called lib, so that second CMake COMMAND:
>> "
>> COMMAND ${CMAKE_COMMAND}
>> -E copy
>> ${CMAKE_CURRENT_BINARY_DIR}/proton.js
>> ${PROJECT_SOURCE_DIR}/node_modules/qpid-proton/lib
>> "
>>
>> certainly copies proton.js into node_modules/qpid-proton/lib for me on my
>> Linux box, but that is the most likely place for things behaving
>> differently between us...
>>
>>
>>
>> BTW:
>> 1. You shouldn't need to do a make install, just doing make should copy
>> this stuff I wanted to make sure a top level node_modules was in place so
>> that the tests and demos work without too much fuss (clearly I was
>> delusional :-D)
>>
>> 2. The spout.js and drain.js are currently *very* hacky (they just print
>> "spout not implemented yet" and exit ;->) the send.js and recv.js and
>> client.js and server.js should work pretty much as per the normal proton
>> examples of the same name and qpid-config.js is pretty much complete (just
>> the *generic* list mechanism to list AMQP 1.0 QMF objects still to do).
>>
>> 3. One thing to bear in mind is that this stuff uses a *websocket*
>> transport, hopefully that's fairly obvious as it's JavaScript, but perhaps
>> not. I've tried it against the Java Broker's websocket transport (though
>> not for a couple of months and I've not tried qpid-config.js with the QMF
>> plugin yet either). If you want to talk to the C++ broker I've included a
>> simple node.js based WebSocket->TCP proxy (proxy.js). On my TODO list is to
>> put some more work into the emscripten network library so that it's
>> possible to configurably choose websockets or TCP sockets (using the
>> standard node net library)
>>
>> Hopefully this gives you a few pointers, do let me know how you get on,
>> though I'm not getting a lot of computer time at the moment as I'm digging
>> loads of holes for fence posts :-(
>>
>> Frase
>>
>>
>> On 22/08/14 19:34, Ernest Allen wrote:
>>
>>> I may have discovered a problem with the javascript bindings for proton
>>> that I got from: git+ssh://git.app.eng.bos.redhat.com/srv/git/rh-qpid-
>>> proton.git branch origin/fadams-javascript-binding
>>>
>>> After the build, I got an error when running the examples. Specifically,
>>> this is what I got:
>>> node spout.js
>>>
>>> module.js:340
>>> throw err;
>>> ^
>>> Error: Cannot find module 'qpid-proton'
>>> at Function.Module._resolveFilename (module.js:338:15)
>>> at Function.Module._load (module.js:280:25)
>>> at Module.require (module.js:364:17)
>>> at require (module.js:380:17)
>>> at Object.<anonymous> (/home/ernie/jsbindings/rh-
>>> qpid-proton/examples/messenger/javascript/spout.js:24:14)
>>> at Module._compile (module.js:456:26)
>>> at Object.Module._extensions..js (module.js:474:10)
>>> at Module.load (module.js:356:32)
>>> at Function.Module._load (module.js:312:12)
>>> at Function.Module.runMain (module.js:497:10)
>>>
>>> After verifying my environment, I finally tracked it down to the
>>> node_modules/qpid-proton directory. The build creates a file named lib in
>>> that directory. It should create a directory named lib that contains a file
>>> named proton.js in it.
>>> When I renamed the lib file to proton.js, created a lib directory and
>>> moved the file under it, all was well.
>>>
>>> I did not do a make install, so I was just running the examples from my
>>> git checkout directory.
>>>
>>> I'm not familiar enough with the cmake files to track this down any
>>> further, so I'm hoping someone here can provide the fix.
>>>
>>> -Ernie Allen
>>>
>>>
>>
>
Re: proton javascript binding problem/question
Posted by Fraser Adams <fr...@blueyonder.co.uk>.
Hi again Ernie,
I've not heard back from you so I'm wondering how you are getting on?
I've still no idea what environment you are running.
One thought that I had though..
As I mentioned in my previous mail the place that copies proton.js is in
fadams-javascript-binding/proton-c/bindings/javascript/CMakeLists.txt
the relevant bit is (line 244):
COMMAND ${CMAKE_COMMAND}
-E copy
${CMAKE_CURRENT_BINARY_DIR}/proton.js
${PROJECT_SOURCE_DIR}/node_modules/qpid-proton/lib
I *wonder* if changing line 244 to
${PROJECT_SOURCE_DIR}/node_modules/qpid-proton/lib/
i.e. adding a slash at the end will sort things out for you.
On my Linux box I don't need that, but it may be that other OSes do?
Could you give that a try and let me know?
Frase
On 23/08/14 17:11, Fraser Adams wrote:
> Hi Ernie,
> Firstly bear in mind that it's still a bit of a work in progress :-)
> though it's getting pretty close to something I'd want to put onto the
> main branch, mostly just tidying stuff up now and adding a few more
> tests and examples.
>
>
> That said it was working fine for me when I made the last commit a
> couple of weeks ago (r1583389 I think)
>
> I've just done a make from scratch
> cd fadams-javascript-binding
> mkdir bld
> cd bld
> cmake ..
> make
>
> in my fadams-javascript-binding directory I have a node_modules and in
> that a qpid-proton directory.
>
> However in my qpid-proton directory I have
> a *directory* named lib and three files named LICENCE, package.json
> and README.md
>
> in the lib directory I have a file named proton.js
>
> which is I think exactly what I'd expect to see.
>
> I have no idea why you are seeing a *file* named lib in qpid-proton :-(
>
>
> I'm using Linux, I don't suppose that you are using some other OS by
> any chance? At a guess it's something different between how CMake
> works between Linux and Windows, but that's just a guess and if you
> are using Linux then it's really weird.
>
> What the make ends up doing is copying the qpid-proton directory and
> contents from fadams-javascript-binding/proton-c/bindings/javascript
> to the node_modules under fadams-javascript-binding then copying the
> proton.js built by the maike into the relevant subdirectory. The
> relevant bit from the CMakeLists.txt under
> fadams-javascript-binding/proton-c/bindings/javascript is:
>
> # This command packages up the compiled proton.js into a node.js
> package called
> # qpid-proton and copies it to the <proton>/node_modules directory.
> This allows
> # the node.js test and example programs to do proton =
> require("qpid-proton");
> add_custom_command(
> TARGET proton.js
> COMMAND ${CMAKE_COMMAND}
> -E copy_directory
> ${CMAKE_CURRENT_SOURCE_DIR}/qpid-proton
> ${PROJECT_SOURCE_DIR}/node_modules/qpid-proton
> COMMAND ${CMAKE_COMMAND}
> -E copy
> ${CMAKE_CURRENT_BINARY_DIR}/proton.js
> ${PROJECT_SOURCE_DIR}/node_modules/qpid-proton/lib
> COMMENT "Building qpid-proton package for node.js"
> )
>
>
> I'm no sort of CMake expert I'm afraid I mostly wing it with help from
> Mr Google, but as I say above that *should* copy the directory
> qpid-proton and its contents from
> fadams-javascript-binding/proton-c/bindings/javascript to
> fadams-javascript-binding then copy proton.js to
> fadams-javascript-binding/node_modules/qpid-proton/lib
>
> Out of curiosity what do you see in
> fadams-javascript-binding/proton-c/bindings/javascript/qpid-proton
> (i.e. the directory that is being copied to nod_modules) is the lib
> you are seeing there a file or a directory?
>
> I'm seeing a directory there too and when I look in subversion at
> http://svn.apache.org/repos/asf/qpid/proton/branches/fadams-javascript-binding/proton-c/bindings/javascript/qpid-proton/
>
>
> I'm seeing a directory called lib too, if you are seeing a file there
> then I wonder if it's something weird with the git->svn bridge, but
> I'm clutching at straws.
>
>
> Hmmm re-reading your mail you say "When I renamed the lib file to
> proton.js, created a lib directory and moved the file under it, all
> was well. " that's suggesting that proton.js got copied to a file
> called lib rather than into the directory called lib, so that second
> CMake COMMAND:
> "
> COMMAND ${CMAKE_COMMAND}
> -E copy
> ${CMAKE_CURRENT_BINARY_DIR}/proton.js
> ${PROJECT_SOURCE_DIR}/node_modules/qpid-proton/lib
> "
>
> certainly copies proton.js into node_modules/qpid-proton/lib for me on
> my Linux box, but that is the most likely place for things behaving
> differently between us...
>
>
>
> BTW:
> 1. You shouldn't need to do a make install, just doing make should
> copy this stuff I wanted to make sure a top level node_modules was in
> place so that the tests and demos work without too much fuss (clearly
> I was delusional :-D)
>
> 2. The spout.js and drain.js are currently *very* hacky (they just
> print "spout not implemented yet" and exit ;->) the send.js and
> recv.js and client.js and server.js should work pretty much as per the
> normal proton examples of the same name and qpid-config.js is pretty
> much complete (just the *generic* list mechanism to list AMQP 1.0 QMF
> objects still to do).
>
> 3. One thing to bear in mind is that this stuff uses a *websocket*
> transport, hopefully that's fairly obvious as it's JavaScript, but
> perhaps not. I've tried it against the Java Broker's websocket
> transport (though not for a couple of months and I've not tried
> qpid-config.js with the QMF plugin yet either). If you want to talk to
> the C++ broker I've included a simple node.js based WebSocket->TCP
> proxy (proxy.js). On my TODO list is to put some more work into the
> emscripten network library so that it's possible to configurably
> choose websockets or TCP sockets (using the standard node net library)
>
> Hopefully this gives you a few pointers, do let me know how you get
> on, though I'm not getting a lot of computer time at the moment as I'm
> digging loads of holes for fence posts :-(
>
> Frase
>
>
> On 22/08/14 19:34, Ernest Allen wrote:
>> I may have discovered a problem with the javascript bindings for
>> proton that I got from:
>> git+ssh://git.app.eng.bos.redhat.com/srv/git/rh-qpid-proton.git
>> branch origin/fadams-javascript-binding
>>
>> After the build, I got an error when running the examples.
>> Specifically, this is what I got:
>> node spout.js
>>
>> module.js:340
>> throw err;
>> ^
>> Error: Cannot find module 'qpid-proton'
>> at Function.Module._resolveFilename (module.js:338:15)
>> at Function.Module._load (module.js:280:25)
>> at Module.require (module.js:364:17)
>> at require (module.js:380:17)
>> at Object.<anonymous>
>> (/home/ernie/jsbindings/rh-qpid-proton/examples/messenger/javascript/spout.js:24:14)
>> at Module._compile (module.js:456:26)
>> at Object.Module._extensions..js (module.js:474:10)
>> at Module.load (module.js:356:32)
>> at Function.Module._load (module.js:312:12)
>> at Function.Module.runMain (module.js:497:10)
>>
>> After verifying my environment, I finally tracked it down to the
>> node_modules/qpid-proton directory. The build creates a file named
>> lib in that directory. It should create a directory named lib that
>> contains a file named proton.js in it.
>> When I renamed the lib file to proton.js, created a lib directory and
>> moved the file under it, all was well.
>>
>> I did not do a make install, so I was just running the examples from
>> my git checkout directory.
>>
>> I'm not familiar enough with the cmake files to track this down any
>> further, so I'm hoping someone here can provide the fix.
>>
>> -Ernie Allen
>>
>
Re: proton javascript binding problem/question
Posted by Fraser Adams <fr...@blueyonder.co.uk>.
Hi Ernie,
Firstly bear in mind that it's still a bit of a work in progress :-)
though it's getting pretty close to something I'd want to put onto the
main branch, mostly just tidying stuff up now and adding a few more
tests and examples.
That said it was working fine for me when I made the last commit a
couple of weeks ago (r1583389 I think)
I've just done a make from scratch
cd fadams-javascript-binding
mkdir bld
cd bld
cmake ..
make
in my fadams-javascript-binding directory I have a node_modules and in
that a qpid-proton directory.
However in my qpid-proton directory I have
a *directory* named lib and three files named LICENCE, package.json and
README.md
in the lib directory I have a file named proton.js
which is I think exactly what I'd expect to see.
I have no idea why you are seeing a *file* named lib in qpid-proton :-(
I'm using Linux, I don't suppose that you are using some other OS by any
chance? At a guess it's something different between how CMake works
between Linux and Windows, but that's just a guess and if you are using
Linux then it's really weird.
What the make ends up doing is copying the qpid-proton directory and
contents from fadams-javascript-binding/proton-c/bindings/javascript to
the node_modules under fadams-javascript-binding then copying the
proton.js built by the maike into the relevant subdirectory. The
relevant bit from the CMakeLists.txt under
fadams-javascript-binding/proton-c/bindings/javascript is:
# This command packages up the compiled proton.js into a node.js package
called
# qpid-proton and copies it to the <proton>/node_modules directory. This
allows
# the node.js test and example programs to do proton =
require("qpid-proton");
add_custom_command(
TARGET proton.js
COMMAND ${CMAKE_COMMAND}
-E copy_directory
${CMAKE_CURRENT_SOURCE_DIR}/qpid-proton
${PROJECT_SOURCE_DIR}/node_modules/qpid-proton
COMMAND ${CMAKE_COMMAND}
-E copy
${CMAKE_CURRENT_BINARY_DIR}/proton.js
${PROJECT_SOURCE_DIR}/node_modules/qpid-proton/lib
COMMENT "Building qpid-proton package for node.js"
)
I'm no sort of CMake expert I'm afraid I mostly wing it with help from
Mr Google, but as I say above that *should* copy the directory
qpid-proton and its contents from
fadams-javascript-binding/proton-c/bindings/javascript to
fadams-javascript-binding then copy proton.js to
fadams-javascript-binding/node_modules/qpid-proton/lib
Out of curiosity what do you see in
fadams-javascript-binding/proton-c/bindings/javascript/qpid-proton (i.e.
the directory that is being copied to nod_modules) is the lib you are
seeing there a file or a directory?
I'm seeing a directory there too and when I look in subversion at
http://svn.apache.org/repos/asf/qpid/proton/branches/fadams-javascript-binding/proton-c/bindings/javascript/qpid-proton/
I'm seeing a directory called lib too, if you are seeing a file there
then I wonder if it's something weird with the git->svn bridge, but I'm
clutching at straws.
Hmmm re-reading your mail you say "When I renamed the lib file to
proton.js, created a lib directory and moved the file under it, all was
well. " that's suggesting that proton.js got copied to a file called lib
rather than into the directory called lib, so that second CMake COMMAND:
"
COMMAND ${CMAKE_COMMAND}
-E copy
${CMAKE_CURRENT_BINARY_DIR}/proton.js
${PROJECT_SOURCE_DIR}/node_modules/qpid-proton/lib
"
certainly copies proton.js into node_modules/qpid-proton/lib for me on
my Linux box, but that is the most likely place for things behaving
differently between us...
BTW:
1. You shouldn't need to do a make install, just doing make should copy
this stuff I wanted to make sure a top level node_modules was in place
so that the tests and demos work without too much fuss (clearly I was
delusional :-D)
2. The spout.js and drain.js are currently *very* hacky (they just print
"spout not implemented yet" and exit ;->) the send.js and recv.js and
client.js and server.js should work pretty much as per the normal proton
examples of the same name and qpid-config.js is pretty much complete
(just the *generic* list mechanism to list AMQP 1.0 QMF objects still to
do).
3. One thing to bear in mind is that this stuff uses a *websocket*
transport, hopefully that's fairly obvious as it's JavaScript, but
perhaps not. I've tried it against the Java Broker's websocket transport
(though not for a couple of months and I've not tried qpid-config.js
with the QMF plugin yet either). If you want to talk to the C++ broker
I've included a simple node.js based WebSocket->TCP proxy (proxy.js). On
my TODO list is to put some more work into the emscripten network
library so that it's possible to configurably choose websockets or TCP
sockets (using the standard node net library)
Hopefully this gives you a few pointers, do let me know how you get on,
though I'm not getting a lot of computer time at the moment as I'm
digging loads of holes for fence posts :-(
Frase
On 22/08/14 19:34, Ernest Allen wrote:
> I may have discovered a problem with the javascript bindings for proton that I got from: git+ssh://git.app.eng.bos.redhat.com/srv/git/rh-qpid-proton.git branch origin/fadams-javascript-binding
>
> After the build, I got an error when running the examples. Specifically, this is what I got:
> node spout.js
>
> module.js:340
> throw err;
> ^
> Error: Cannot find module 'qpid-proton'
> at Function.Module._resolveFilename (module.js:338:15)
> at Function.Module._load (module.js:280:25)
> at Module.require (module.js:364:17)
> at require (module.js:380:17)
> at Object.<anonymous> (/home/ernie/jsbindings/rh-qpid-proton/examples/messenger/javascript/spout.js:24:14)
> at Module._compile (module.js:456:26)
> at Object.Module._extensions..js (module.js:474:10)
> at Module.load (module.js:356:32)
> at Function.Module._load (module.js:312:12)
> at Function.Module.runMain (module.js:497:10)
>
> After verifying my environment, I finally tracked it down to the node_modules/qpid-proton directory. The build creates a file named lib in that directory. It should create a directory named lib that contains a file named proton.js in it.
> When I renamed the lib file to proton.js, created a lib directory and moved the file under it, all was well.
>
> I did not do a make install, so I was just running the examples from my git checkout directory.
>
> I'm not familiar enough with the cmake files to track this down any further, so I'm hoping someone here can provide the fix.
>
> -Ernie Allen
>