Expose simple whisper api to C / go #331

arnetheduck · 2019-05-30T09:07:28Z

don't merge, just playing around

nimbus/status_api.c

zah · 2019-05-30T11:28:31Z

nimbus/status_api.nim

+ discard initENode(nodeId, bootnode)
+ bootnodes.add(bootnode)
+
+ asyncCheck node.connectToNetwork(bootnodes, true, true)


Are you sure you don't want to wait here? The peerPool.connectToNode call below seems a bit dangerous, given that node.peerPool.start() is called in a non-immediate way inside connectToNetwork.

Maybe it works by accident now, but the assumptions about the API seem fragile.

oh, we're just playing around, it's totally wrong (copied from stratus).. want to see what it would take to call nim from go (!)

hm, so waiting runs the polling loop I presume?

waitFor here will poll() yes. But should only be used at "top-level", so that it can not end-up in another poll.

@zah, running connectToNode when the peer pool is not started yet should not be an issue no? I did the same in nimbus here: https://github.com/status-im/nimbus/blob/master/nimbus/nimbus.nim#L127

I think that depends a bit of how much of a stateful black box one wants to turn the api into, vs a more lightweight and flexible collection of utilities.. if we block here, we force the caller to run this stuff in a dedicated thread basically - if instead we do more of a callback-based model, they have more control and can integrate it better with whatever they're running, but we lose some control / it becomes slightly easier to mess up.

in either case, it will be somewhat difficult to reconcile the magic that goes on behind our back in the async macro transformations with a flexible C api.. will have to tread carefully here with these features that don't have a good representation in the C world.

But should only be used at "top-level", so that it can not end-up in another poll.

stuff like this is a mess to remember about an API 😞

I think we can provide a callbacks-style API on the C side. Nim will be able to handle this with a more direct usage of future.addCallback instead of await. Maybe it's a bit too early to jump the gun, but it's quite likely that this style will appear elsewhere in the API.

oskarth · 2019-05-31T11:23:28Z

This is more of an integration issue with status-console-client, but when I try to include the above .go file with the generated statically linked library libnimbus_api.a, I get a bunch of 'multiple definition' errors with go-ethereum dependencies.. All of them seem to be related to secp256k1 as far as I can tell.

I assume there's some clever way of wrapping/inling/overwriting to ensure these symbol name conflicts are dealt with, but I'm not sure what that looks like.

Any ideas @cammellos @arnetheduck?

Inside status-console-client make build (GOFLAGS="-mod=vendor" go build -o ./bin/status-term-client .)

/usr/local/go/pkg/tool/linux_amd64/link: running gcc failed: exit status 1
/usr/bin/ld: /home/oskarth/go/src/github.com/status-im/nimbridge/libnimbus_api.a(secp256k1.c.o): in function `secp256k1_context_create':
secp256k1.c:(.text+0xca20): multiple definition of `secp256k1_context_create'; /tmp/go-link-088668558/000010.o:/home/oskarth/go/src/github.com/status-im/status-console-client/vendor/github.com/ethereum/go-ethereum/crypto/secp256k1/./libsecp256k1/src/secp256k1.c:56: first defined here
/usr/bin/ld: /home/oskarth/go/src/github.com/status-im/nimbridge/libnimbus_api.a(secp256k1.c.o): in function `secp256k1_context_clone':
...

GOFLAGS="-mod=vendor" go build --ldflags ' -extldflags "-static"' -o ./bin/status-term-client . gives the same errors as above, and additionally errors like /workdir/go/src/os/user/getgrouplist_unix.go:16: warning: Using 'getgrouplist' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking (more Go specific, presumably)

arnetheduck · 2019-06-03T08:26:08Z

This is more of an integration issue with status-console-client, but when I try to include the above .go file with the generated statically linked library libnimbus_api.a, I get a bunch of 'multiple definition' errors with go-ethereum dependencies.. All of them seem to be related to secp256k1 as far as I can tell.

I assume there's some clever way of wrapping/inling/overwriting to ensure these symbol name conflicts are dealt with, but I'm not sure what that looks like.

Right, both nim and go link stuff statically, and might not be using the same version of these two libraries. sigh.. this could take a bit of tinkering to get right - one would have to figure our the versions in use and make sure they're not conflicting, then select one of them - not sure if this is easier to do on the go or nim side - ie disabling the inclusion of libsecp256k1.. in nim, it would involve adding a special compile flag to here:

https://github.com/status-im/nim-secp256k1/blob/master/secp256k1.nim#L12

when not defined(noCompileSecp):
 {.compile...

then, when compiling status_api.nim, add -d:noCompileSecp to the build flags - this will work iff the go code exposes all the secp symbols that nim needs (which is likely)

oskarth · 2019-06-04T15:52:39Z

Unable to strip secp256k1 symbol names from libnimbus_api.a with above. Not sure if I'm calling it wrong, or if symbols are being included from somewhere else. I can strip symbol names locally on nim-secp256k1 level with the compiler flag.

With the following changes:

> pwd
/home/oskarth/git/nimbus/vendor/nim-secp256k1
> git diff
diff --git a/secp256k1.nim b/secp256k1.nim
index ad1a98d..3c8bd5f 100644
--- a/secp256k1.nim
+++ b/secp256k1.nim
@@ -9,7 +9,11 @@ const wrapperPath = currentSourcePath.rsplit(DirSep, 1)[0] & "/secp256k1_wrapper
 
 const secpSrc = wrapperPath & "/secp256k1/src/secp256k1.c"
 
-{.compile: secpSrc.}
+echo "*** inside secp256k1"
+
+when not defined(noCompileSecp):
+  echo "*** secp dont compile"
+  {.compile: secpSrc.}
 
 {.deadCodeElim: on.}

I see this for local compile:

> nim c -d:noCompileSecp secp256k1.nim
> nm secp256k1| grep secp256k1_context_create # NIL

> nim c secp256k1.nim
> nm secp256k1| grep secp256k1_context_create
000000000000ea00 T secp256k1_context_create

I've also tried deleting {.,vendor/nim-sec256k1}/nimcache.

Adding compiler flag to status api script:

> git diff status_api.nim.cfg
diff --git a/nimbus/status_api.nim.cfg b/nimbus/status_api.nim.cfg
index 551dec3..95682e4 100644
--- a/nimbus/status_api.nim.cfg
+++ b/nimbus/status_api.nim.cfg
@@ -2,3 +2,4 @@ app:staticlib
 o:"libnimbus_api.a"
 noMain
 -d:"chronicles_sinks=textlines"
+-d:noCompileSecp
\ No newline at end of file

Also added to build script:

> git diff status_api.nim.cfg
diff --git a/nimbus/status_api.nim.cfg b/nimbus/status_api.nim.cfg
index 551dec3..95682e4 100644
--- a/nimbus/status_api.nim.cfg
+++ b/nimbus/status_api.nim.cfg
@@ -2,3 +2,4 @@ app:staticlib
 o:"libnimbus_api.a"
 noMain
 -d:"chronicles_sinks=textlines"
+-d:noCompileSecp
\ No newline at end of file
> git diff build_status_api.sh
diff --git a/nimbus/build_status_api.sh b/nimbus/build_status_api.sh
index d4e5735..e674e38 100755
--- a/nimbus/build_status_api.sh
+++ b/nimbus/build_status_api.sh
@@ -1,6 +1,6 @@
 #!/bin/sh
 
-../env.sh nim c --opt:speed --lineTrace:off status_api
+../env.sh nim c --opt:speed --lineTrace:off -d:noCompileSecp status_api
 gcc status_api.c ./libnimbus_api.a -lm -o xx
 
 ./xx

Running ./build_status_api.sh shows:

Hint: operation successful (139250 lines compiled; 4.604 sec total; 341.23MiB peakmem; Debug Build) [SuccessX]        
*** inside secp256k1                                                                                                   ***Inside nim status                                                                                                  
INF 2019-06-04 23:49:34+08:00 RLPx listener up

No "*** secp dont compile" - not sure if it is swallowed or compiler flag is ignored?

> nm libnimbus_api.a |grep secp256k1_context_create
000000000000ca20 T secp256k1_context_create
                 U secp256k1_context_create

Perhaps it is being included elsewhere?

oskarth · 2019-06-04T15:58:49Z

I also notice the following when I remove nimcache:

CC: nimcrypto_rijndael                                                                                                 CC: nimcrypto_pbkdf2                                                                                                   
CC: nimcrypto_sysrand                                                                                                  
CC: eth_keys                                                                                                           
CC: secp256k1_secp256k1                                                                                                
CC: eth_rlp                                                                                                            
CC: eth_types

With:

> ls nimcache/debug/status_api/secp256k1_secp256k1.c*
nimcache/debug/status_api/secp256k1_secp256k1.c  nimcache/debug/status_api/secp256k1_secp256k1.c.o

oskarth · 2019-06-05T15:03:45Z

Debug log: https://gist.github.com/oskarth/3667fe4aca3bbf64352c6a227ecf3a66#file-gistfile1-txt-L390

@stefantalpalaru pointed out that archive file is appending. Doing rm -rf nimcache/; rm -rf nimcache/debug/status_api/*; rm libnimbus_api.a results in symbol files not being included in the archive build. However, this results in (with --verbosity:2):

/usr/bin/ld: ./libnimbus_api.a(eth_keys.c.o): in function `shutdownLibsecp256k1_FcL5g26sxXaaxQ7vMh7v9cg':
eth_keys.c:(.text+0xff): undefined reference to `secp256k1_context_destroy'
/usr/bin/ld: ./libnimbus_api.a(eth_keys.c.o): in function `newEthKeysContext_n9boSNMecC2SqzOw9aC3CSFQ':
eth_keys.c:(.text+0x8bb): undefined reference to `secp256k1_context_create'
/usr/bin/ld: eth_keys.c:(.text+0x8cf): undefined reference to `secp256k1_context_set_illegal_callback'
/usr/bin/ld: eth_keys.c:(.text+0x8e0): undefined reference to `secp256k1_context_set_error_callback'
/usr/bin/ld: ./libnimbus_api.a(eth_keys.c.o): in function `recoverPublicKey_uGJtFt9bs9aznskr43bdWnlw':
eth_keys.c:(.text+0x1ad8): undefined reference to `secp256k1_ec_pubkey_parse'
/usr/bin/ld: ./libnimbus_api.a(eth_keys.c.o): in function `ecdhAgree_87TEwd1N9aUoXWDQRNQ0LXA':
eth_keys.c:(.text+0x1fb1): undefined reference to `secp256k1_ecdh_raw'
/usr/bin/ld: ./libnimbus_api.a(eth_keys.c.o): in function `recoverSignatureKey_4KabydfOLrnGmFTa57Yiqg':
eth_keys.c:(.text+0x2575): undefined reference to `secp256k1_ecdsa_recoverable_signature_parse_compact'
/usr/bin/ld: eth_keys.c:(.text+0x2594): undefined reference to `secp256k1_ecdsa_recover'
/usr/bin/ld: ./libnimbus_api.a(eth_keys.c.o): in function `getPublicKey_fgV717wHMpTjJNe9aWTMXHw':
eth_keys.c:(.text+0x2afb): undefined reference to `secp256k1_ec_pubkey_create'
/usr/bin/ld: ./libnimbus_api.a(eth_keys.c.o): in function `newPrivateKey_NXm10qKppCro9cyQ9blmlJsw':
eth_keys.c:(.text+0x3cce): undefined reference to `secp256k1_ec_seckey_verify'
/usr/bin/ld: ./libnimbus_api.a(eth_keys.c.o): in function `newKeyPair_j2aLFMx7IbNgrSGoHXbBsw':
eth_keys.c:(.text+0x4296): undefined reference to `secp256k1_ec_seckey_verify'
/usr/bin/ld: ./libnimbus_api.a(eth_keys.c.o): in function `getRaw_5TxoqDNub9cUt2jUoNOaZPw':
eth_keys.c:(.text+0x4907): undefined reference to `secp256k1_ec_pubkey_serialize'
/usr/bin/ld: ./libnimbus_api.a(eth_keys.c.o): in function `getRaw_tGBQjCLBokoF3Rw29bRaw8A':
eth_keys.c:(.text+0x5c0f): undefined reference to `secp256k1_ecdsa_recoverable_signature_serialize_compact'
/usr/bin/ld: ./libnimbus_api.a(eth_keys.c.o): in function `signRawMessage_2w1A5YuQILt9aRDm9ci7vZuw':
eth_keys.c:(.text+0x6fa0): undefined reference to `secp256k1_ecdsa_sign_recoverable'
/usr/bin/ld: ./libnimbus_api.a(eth_keys.c.o): in function `initPrivateKey_IKtsSRvygBO8PAyEZnfmxg':
eth_keys.c:(.text+0x7a56): undefined reference to `secp256k1_ec_seckey_verify'
collect2: error: ld returned 1 exit status
./build_status_api.sh: line 6: ./xx: No such file or directory

gcc status_api.c ./libnimbus_api.a -lm -o xx -unresolved-symbols=ignore-all gives the same result. Using -c (gcc: warning: ./libnimbus_api.a: linker input file unused because linking not done) flag leads to an unlinked archive file. Running make build (go build) in status-console-client results in:

# github.com/status-im/status-console-client
/usr/local/go/pkg/tool/linux_amd64/link: running gcc failed: exit status 1
/usr/bin/ld: libnimbus_api.a(eth_keys.c.o): in function `ecdhAgree_87TEwd1N9aUoXWDQRNQ0LXA':
eth_keys.c:(.text+0x1fb1): undefined reference to `secp256k1_ecdh_raw'
collect2: error: ld returned 1 exit status

Running make build in status-console-client master and checking symbols, I notice it has a bunch of secp256k1... ones but: nm bin/status-term-client |grep secp256k1_ecdh_raw # NIL

oskarth · 2019-06-05T15:14:10Z

The two libraries appear to be different, at least partly:

oskarth@localhost ~/g/n/v/n/s/s/include> pwd
/home/oskarth/git/nimbus/vendor/nim-secp256k1/secp256k1_wrapper/secp256k1/include                                                                
oskarth@localhost ~/g/n/v/n/s/s/include> grep "raw" secp256k1_ecdh.h
SECP256K1_API SECP256K1_WARN_UNUSED_RESULT int secp256k1_ecdh_raw(

oskarth@localhost ~/g/s/g/s/s/v/g/e/g/c/s/l/include> pwd
/home/oskarth/go/src/github.com/status-im/status-console-client/vendor/github.com/ethereum/go-ethereum/crypto/secp256k1/libsecp256k1/include     
oskarth@localhost ~/g/s/g/s/s/v/g/e/g/c/s/l/include> grep "raw" secp256k1_ecdh.h

oskarth · 2019-06-05T17:18:55Z

Nimbus is using this function, so can't just comment it out vendor/nim-eth/eth/keys/libsecp256k1.nim: if secp256k1_ecdh_raw(ctx, cast[ptr cuchar](addr res),
Trying to upgrade version of secp256k1 in status-console-client appears to fail: https://gist.github.com/oskarth/3667fe4aca3bbf64352c6a227ecf3a66#gistcomment-2935870
Alternative plans suggested @stefantalpalaru:

Plan B: convince Go to link unused secp256k1 symbols.
Plan C: prefix all symbols in Nim's version of secp256k1.o using objcopy: https://stackoverflow.com/questions/6940384/how-to-deal-with-symbol-collisions-between-statically-linked-libraries?noredirect=1&lq=1

Other options:

Removing secp lib from Go code base :P Results in build github.com/status-im/status-console-client: cannot load github.com/ethereum/go-ethereum/crypto/secp256k1: open /home/oskarth/go/src/github.com/status-im/status-console-client/vendor/github.com/ethereum/go-ethereum/crypto/secp256k1: no such file or directory - might need some more tweaking, but seems like a pretty wonky path to me.
Dynamically linking Nimbus?

oskarth · 2019-06-27T11:29:44Z

Update: shared library resolves the above issue.

Now Nimbus can be run from inside status-console-client. However, as soon as it starts up (right after finding some peers and printing some logs) it gets seg faulted. This happens within a few seconds of startup, and sometimes it gets a bit further than other times. However, it is never enough to actually send through a message through Whisper.

Relevant lib: https://github.com/status-im/status-nim and PR status-im/status-console-client#79

Here's the stacktrace with debug symbols: https://gist.github.com/oskarth/771034417a52927fa9bbc6df415d5714

oskarth · 2019-06-29T02:07:22Z

Tried with naive prelude of setupForeignThreadGc() (not quite sure how it is supposed to be used, teardown etc) and GOMAXPROCS=1. Now it hangs like this: https://gist.github.com/oskarth/c3f4392e84c279c433474d31b3173737 (stuck at L73, sometimes it gets further but not by much. Same if GOMAXPROCS=8 though usually gets quite a bit further)

(Same result if I add teardownForeignThreadGc at end of each function)

oskarth · 2019-06-29T02:40:12Z

Since the secp shared lib thing is resolved we can get a minimally failing version in this PR. Perhaps some Nim/C experts can help reproduce and debug this? Not too familiar with how the threading/GC etc works.

How to reproduce:

./build_status_api.sh
gdb --args env GOMAXPROCS=8 go run main.go  # e.g.

You might need to tweak the LDFLAG in main.go.

Hangs with following stacktrace:

[nim-status] ListenAndPost (post @i==1000) i=  232
[nim-status] ListenAndPost (post @i==1000) i=  233
[nim-status] ListenAndPost (post @i==1000) i=  234
^CNo stack traceback available
SIGINT: Interrupted by Ctrl-C.

Thread 1 "go" received signal SIGINT, Interrupt.
runtime.futex () at /usr/local/go/src/runtime/sys_linux_amd64.s:536
536		MOVL	AX, ret+40(FP)
(gdb) bt
#0  runtime.futex () at /usr/local/go/src/runtime/sys_linux_amd64.s:536
#1  0x000000000042b87b in runtime.futexsleep (addr=0xe4f4e8 <runtime.m0+328>, val=0, ns=-1)
    at /usr/local/go/src/runtime/os_linux.go:46
#2  0x000000000040bd31 in runtime.notesleep (n=0xe4f4e8 <runtime.m0+328>)
    at /usr/local/go/src/runtime/lock_futex.go:151
#3  0x0000000000433581 in runtime.stopm () at /usr/local/go/src/runtime/proc.go:1936
#4  0x00000000004346da in runtime.findrunnable (gp=0xc000045900, inheritTime=false)
    at /usr/local/go/src/runtime/proc.go:2399
#5  0x00000000004352fc in runtime.schedule () at /usr/local/go/src/runtime/proc.go:2525
#6  0x0000000000435611 in runtime.park_m (gp=0xc000410480) at /usr/local/go/src/runtime/proc.go:2605
#7  0x0000000000457e8b in runtime.mcall () at /usr/local/go/src/runtime/asm_amd64.s:299
#8  0x0000000000457da9 in runtime.rt0_go () at /usr/local/go/src/runtime/asm_amd64.s:201
#9  0x0000000000000000 in ?? ()
(gdb)

oskarth · 2019-07-24T03:13:49Z

Using runtime.LockOSThread() on Go side to lock all go procs to single OS thread appears to solve the deadlock and segfault issues. It now works end to end here: status-im/status-console-client#79 and README https://github.com/status-im/status-console-client/pull/79/files?short_path=04c6e90#diff-04c6e90faac2675aa89e2176d2eec7d8

On the Go side, it still needs some hooking up to be used for 1:1/public chats etc, but a bridge has been created! Once v1 is out of the way, I expect we can start to push getting all basic use cases solved and start to (at least be able to) use Nimbus instead of Geth. Step by step.

On the Nim side, what do we need to do to get this PR merged? It's quite hacky code and I'm not sure what policy you guys use, but it'd be good to have it in trunk, especially for future Go dev integration improvements. Is there something that needs to be done to make that happen in terms of isolating changes / hiding them under flags etc? We can also have a fork but seems meh.

The go stuff isn't needed here, but might be good for future enhancements/testing (better threading support?) as it allows isolated end to end testing. It's up to you guys though.

There's also the start of a status-nim lib (more like a Go lib now) here with first issue status-im/nim-status#1, it might make sense to put some Status specific Nim stuff there.

cc @arnetheduck

zah · 2019-07-24T08:15:02Z

We are working on a plan to make the Nim's side of the APIs more thread-safe, so the GO hacks can be removed. Should be ready in the next two weeks, stay tuned.

Otherwise, I think this PR just needs a final round of reviews and it will be ready for merging.

kdeme · 2019-07-24T08:23:08Z

Next to what zah commented, another question I would ask ourselves is to better understand what our end goals are here. Or at least some idea regarding this.

With this Whisper API we actually don't use anything from the Nimbus repo specifically (except its name), so it doesn't necessarily need to be in the Nimbus repository.

However, if we are planning to expose more than just the Whisper part in the future, it could make sense to keep it here. The Nimbus repository could be the general location to expose all this, but it doesn't have to be. Ideas?

zah · 2019-07-24T08:29:22Z

nimbus/build_go.sh

@@ -0,0 +1,2 @@
+#!/bin/sh 
+go build --ldflags '-extldflags "-static"' -o test main.go


I'm sure @stefantalpalaru would like to provide make targets for these build scripts

Go building happens in separate lib, we can remove this script from here if we want to keep it clean. It's more to have a self-contained failing case for debugging thread stuff.

.gitmodules

zah · 2019-07-24T08:37:33Z

nimbus/status_api.nim

+ discard initENode(nodeId, bootnode)
+ bootnodes.add(bootnode)
+
+ asyncCheck node.connectToNetwork(bootnodes, true, true)


I think we can provide a callbacks-style API on the C side. Nim will be able to handle this with a more direct usage of future.addCallback instead of await. Maybe it's a bit too early to jump the gun, but it's quite likely that this style will appear elsewhere in the API.

arnetheduck · 2019-07-24T09:32:28Z

I think we can provide a callbacks-style API on the C side

to truly integrate as a library, we should probably define a set of callbacks and hooks so that the event loop of the calling application can be used. This typically means hooks to register for epoll etc.

Libraries that run their own thread are inherently less flexible because not all environments allow access to threads or loop-running (ie in browser) - a really proper solution would have the hooks etc and maybe a convenience option to run a thread with a loop as well as a polling solution that avoids the events / epolls completely.

all that is long term though.

nimbus/status_api.nim

kdeme · 2019-07-25T13:35:32Z

nimbus/status_api.nim

+var
+ node: EthereumNode
+
+proc subscribeChannel(


would need to return the filter ID if we ever want to unsubscribe

Added as TODO in-line

kdeme · 2019-07-25T13:39:10Z

nimbus/status_api.nim

+
+ subscribeChannel($channel, c_handler)
+
+proc nimbus_post(payload: cstring) {.exportc.} =


Add signing key as parameter.
How would we do key management? In nimbus (like in rpc) or in status go?
How is this done now in status / status cli?

Added as TODO, all good questions but seems out of scope of this spike - let's revist later

nimbus/status_api.nim

kdeme · 2019-07-25T13:42:05Z

nimbus/status_api.nim

+ pow*: float64
+ hash*: Hash
+
+proc nimbus_subscribe(channel: cstring, handler: proc (msg: ptr CReceivedMessage) {.gcsafe, cdecl.}) {.exportc.} =


I think we should rename nimbus_subscribe and nimbus_post to something that explains it is a status public chat post/subscribe?

Added as todo to figure out

kdeme · 2019-07-25T13:43:23Z

nimbus/status_api.nim

+ for i in 0..<4:
+ topic[i] = channelHash.data[i]
+
+ discard node.postMessage(symKey = some(symKey),


Handle error case?

Added as TODO in-line

README.md

oskarth · 2019-07-30T05:28:03Z

Addressed most basic feedback and added some TODOs inline. Also fixed rebase/submodules (was targeting master before, oops).

All the API design questions etc are great and important. However, at this stage I think the main goal should be to save the spike progress somewhere (such as in trunk) and then we can revisit and clean things up, do proper error handling, think about where things should live etc (Nimbus, status-nim, status-console-client, other lib?). Does that sound reasonable to people?

To avoid GC/thread issues causing segmentation fault when running from Go.

pedropombeiro · 2019-11-28T13:27:12Z

Regarding the use of static library, for the time being I'm passing -ldflags="-extldflags=-Wl,--allow-multiple-definition" to go build so that the build doesn't break with the duplicate symbol definitions. The linker will use the first definition it finds. This at least unblocks me to link to status-react until we can test a better solution.

zah reviewed May 30, 2019

View reviewed changes

arnetheduck changed the base branch from master to devel May 30, 2019 13:54

arnetheduck changed the title ~~[WIP] Deploy only to the correct testnet depending on the current branch~~ [WIP] Expose simple whisper api to C / go Jun 4, 2019

oskarth mentioned this pull request Jun 5, 2019

[WIP/ PoC] Nimbus test status-im/status-console-client#79

Merged

oskarth force-pushed the status-c-api branch from 53ac44d to 0504098 Compare July 24, 2019 03:17

zah reviewed Jul 24, 2019

View reviewed changes

kdeme reviewed Jul 25, 2019

View reviewed changes

oskarth force-pushed the status-c-api branch 2 times, most recently from 80e8540 to 194a17f Compare July 30, 2019 05:24

oskarth force-pushed the status-c-api branch from 194a17f to 7b8754b Compare July 30, 2019 05:53

arnetheduck and others added 5 commits July 30, 2019 12:34

dummy c lib

3f92796

go stuffz

99e4343

Compile secp

9296248

Compile as shared library

da7ebad

Build with debug info

4a649b8

oskarth added 5 commits July 30, 2019 12:34

Prelude exposed fns with setupForeignThreadGc() (naive)

1a7a91b

To avoid GC/thread issues causing segmentation fault when running from Go.

Add logging, fix lib path and gomaxprocs to make debuggable

a7b5e2f

lock to os thread

d06add7

Address basic feedback and mark TODOs

c3944db

Use normal secp (shared lib flow now)

fd60da5

arnetheduck force-pushed the status-c-api branch from 7b8754b to fd60da5 Compare July 30, 2019 10:35

api: cleanup, move to api folder

2f42972

arnetheduck changed the title ~~[WIP] Expose simple whisper api to C / go~~ Expose simple whisper api to C / go Jul 31, 2019

kdeme approved these changes Jul 31, 2019

View reviewed changes

arnetheduck merged commit 3c2daa8 into devel Jul 31, 2019

delete-merged-branch bot deleted the status-c-api branch July 31, 2019 08:05

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Expose simple whisper api to C / go #331

Expose simple whisper api to C / go #331

arnetheduck commented May 30, 2019

zah May 30, 2019

arnetheduck May 30, 2019

arnetheduck May 30, 2019

kdeme May 30, 2019

arnetheduck May 30, 2019

arnetheduck May 30, 2019

zah Jul 24, 2019

oskarth commented May 31, 2019 •

edited

Loading

arnetheduck commented Jun 3, 2019 •

edited

Loading

oskarth commented Jun 4, 2019

oskarth commented Jun 4, 2019

oskarth commented Jun 5, 2019

oskarth commented Jun 5, 2019

oskarth commented Jun 5, 2019 •

edited

Loading

oskarth commented Jun 27, 2019

oskarth commented Jun 29, 2019 •

edited

Loading

oskarth commented Jun 29, 2019

oskarth commented Jul 24, 2019 •

edited

Loading

zah commented Jul 24, 2019 •

edited

Loading

kdeme commented Jul 24, 2019 •

edited

Loading

zah Jul 24, 2019 •

edited

Loading

oskarth Jul 30, 2019

zah Jul 24, 2019

arnetheduck commented Jul 24, 2019

kdeme Jul 25, 2019

oskarth Jul 30, 2019

kdeme Jul 25, 2019

oskarth Jul 30, 2019

kdeme Jul 25, 2019

oskarth Jul 30, 2019

kdeme Jul 25, 2019

oskarth Jul 30, 2019

oskarth commented Jul 30, 2019

pedropombeiro commented Nov 28, 2019

		@@ -0,0 +1,2 @@
		#!/bin/sh
		go build --ldflags '-extldflags "-static"' -o test main.go


		subscribeChannel($channel, c_handler)

		proc nimbus_post(payload: cstring) {.exportc.} =

Expose simple whisper api to C / go #331

Expose simple whisper api to C / go #331

Conversation

arnetheduck commented May 30, 2019

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

oskarth commented May 31, 2019 • edited Loading

arnetheduck commented Jun 3, 2019 • edited Loading

oskarth commented Jun 4, 2019

oskarth commented Jun 4, 2019

oskarth commented Jun 5, 2019

oskarth commented Jun 5, 2019

oskarth commented Jun 5, 2019 • edited Loading

oskarth commented Jun 27, 2019

oskarth commented Jun 29, 2019 • edited Loading

oskarth commented Jun 29, 2019

oskarth commented Jul 24, 2019 • edited Loading

zah commented Jul 24, 2019 • edited Loading

kdeme commented Jul 24, 2019 • edited Loading

zah Jul 24, 2019 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

arnetheduck commented Jul 24, 2019

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

oskarth commented Jul 30, 2019

pedropombeiro commented Nov 28, 2019

oskarth commented May 31, 2019 •

edited

Loading

arnetheduck commented Jun 3, 2019 •

edited

Loading

oskarth commented Jun 5, 2019 •

edited

Loading

oskarth commented Jun 29, 2019 •

edited

Loading

oskarth commented Jul 24, 2019 •

edited

Loading

zah commented Jul 24, 2019 •

edited

Loading

kdeme commented Jul 24, 2019 •

edited

Loading

zah Jul 24, 2019 •

edited

Loading