Using native code

[jmarks-joshua]

It says in the docs that it fully supports native modules, but I cannot figure out how to use ffi at all as soon as I import it i get an except that 'TypeError: exists is not a function(…)' and after a little digging it just looks like thats because the node modules that ffi relies on have not been loaded specifically fs (from which it extracts the 'exists' function). Am i being stupid, is that not what was meant by native modules or is this a specific issue with loading ffi (i think its actually bindings which is needed by ffi)?

Thanks,

[wojtkowiak]

Hey,

I have never done anything with ffi - are you sure it is compatible with node 6.5 that is used in Electron?
Could you provide a reproduction repository so it would be easier for me to check and reproduce it?

[jmarks-joshua]

Hey

Yeah it is, there are 100s of 1000s of apps/packages that use ffi, I think technically it's part of Node, it certainly started out that way. I've made a very simple reproduction here

[jmarks-joshua]

To add to this, i also can't require('electron') from my client code either for the same reason really. I feel like I'm fundamentally missing something and that this is probably easy to fix, but i could be wrong. Do i have to do these sorts of things in modules perhaps?

[wojtkowiak]

Sorry for the delay. I have finally checked it out.
Basically because electron's node integration conflicts with Meteor it is turned off (nodeIntegration pref of window is false). So you can not import anything desktop related from meteor project's code.
Also you should not add npm packages to packages json. Instead add ffi to dependencies in settings.json and use it in a module or directly in desktop.js. The code that lives in .desktop is your desktop related part of your application and you can communicate with it through an IPC api.

Here is an example of declaring IPC method which can be called from your meteor client with Desktop.fetch('example','testEvent', 1);

https://github.com/wojtkowiak/meteor-desktop/blob/master/scaffold/modules/example/index.js#L51

Let me know if will have any more problems with it as I did not have enough time to check if there actually would be any problems with ffi.

[jmarks-joshua]

I thought it must be a meteor/electron mismatch somewhere. I had a look at modules but I couldn't figure out how they worked or how to use them. After spending the morning figuring it out i finally have it working. Thank you so much for your help, it's really awesome work you're doing. It looks like ffi works exactly as expected so It looks like it's all good from here.

[ericvrp]

@crippledjosh Please let others know what you did to have it working.
@wojtkowiak Desktop.fetch works for me not with the syntax you give here but only when inserting a timeout parameter after 'testevent'. Is this a documentation issue or am I doing something wrong?

[jmarks-joshua]

@ericvrp I did exactly what you said, as it happens I posted what you just said to a different thread, but forgot to post it here. Yeah seems to be a documentation issue.

[wojtkowiak]

@crippledjosh @ericvrp thanks for pointing that out.
Forgot to update dosc after #54.

Fetch is now:
fetch(module, event, timeout = 2000, ...args)

[ericvrp]

When I run
var _timeout = 2000; Desktop.fetch('example', 'testEvent', _timeout, 0).then(result => console.log('0)', result));
I get the expected result '0) false'.

But when I run
var _timeout = 2000; Desktop.fetch('example', 'testEvent', _timeout, 0).then(result => console.log('0)', result)); Desktop.fetch('example', 'testEvent', _timeout, 1).then(result => console.log('1)', result))
I get this:
0) false
desktop:1 Uncaught (in promise) timeout

Running both fetches on seperate lines of the developer console gives the expected "1) true". Any idea why this is happening?

[jmarks-joshua]

Ahhh i have actually had this issue, but I wasn't certain what it was. My theory is that there is an issue with the queue and fetchId. I think if you ran your fetch requests with some sort of time delay on the second one it would work, which is why it works in the console, because obviously you're not asking them within milliseconds of each other anymore.

If I'm correct it's gonna be a bitch to debug, because as soon as you stop for the debug the issue will stop.

[ericvrp]

When I run this from my Meteor client side.

When I do a console.log(fetchId) in the testEvent handler I see the fetchId increment so at least we know that.

Desktop.fetch('example', 'testEvent', timeout, 0).then(result => console.log('0)', result)) Desktop.fetch('example', 'testEvent', timeout, 1).then(result => console.log('1)', result)) Desktop.fetch('example', 'testEvent', timeout, 2).then(result => console.log('2)', result))

EDIT: But on the console I only see the first result followed by two timeouts

[wojtkowiak]

For me this seems like a serious bug. Will investigate it asap.

[ericvrp]

Thank you and yes I agree this bug would make it very hard to use meteor-desktop at the moment

[ericvrp]

Sorry, one more thing to help you track down the problem. I added another desktop module, this time with two event handlers. As long as I try to call Meteor.fetch on either of the three handlers things work but a second time causes a timeout. So with handler1,handler2,handler3,handler1 only the last handler1 fetch causes a timeout.

[wojtkowiak]

Thanks @ericvrp for your time. This will be fixed in 0.7.1 - release time within 24h.

[ericvrp]

Great! And thank you for your time developing this package! When 0.7.1 arrives I will give it a shake and report here.

[jmarks-joshua]

@wojtkowiak Out of curiosity what was the issue? I was having a dig around in the code to see if I could help out at all, and didn't get very far, I wasn't looking very long, but still I'm interested.

[wojtkowiak]

@crippledjosh Well I have changed the conception in the middle while writing the wrapper and decided I will handle on and once handlers myself. As as result I kinda missed the case when two or more Desktop.fetches are waiting for the response from the same event.
f2e0df9#diff-aa040ff5ddc081a152ae0ec08dfdd780L104 - I was clearing the array of all handlers every time single response arrived, meaning that any consecutive responses simply were not processed.

What I wanted to do originally is to check whether the handler did process the event (handler checks if the fetchId is the one it waits for) and only then remove it (as it is once handler). This case was not implemented by a mistake. Sorry guys that you've had to struggle with it.

Now I simply added the fetchId into the event name which makes the response event unique - this is a much simpler solution than adding the additional logic I've planned in the first place: f2e0df9#diff-aa040ff5ddc081a152ae0ec08dfdd780R200

[jmarks-joshua]

Ahhh ok cool. I was pretty close with my guess on what was going on then, thats nice 👍 . No worries, what you've got is awesome and I'm really grateful for all the work you do.

[ericvrp]

All fine now in 0.7.1

[wojtkowiak]

Great, can this be closed?

[ericvrp]

yes it can