I am looking for full kademlia DHT Implementation in c++? I have tried bitdht which is not ver well documented and it is not even fully implemented. Also maidsafe-dht is too complex. Can any one refer to any other implementations except for the ones mentioned above?
Do you know about libtorrent? It is an open source lib in C++.
http://www.libtorrent.org/
Related
I use Python, but I don't know how it works in Kotlin. This is an example
example => exec("""print("hello")""") output => hello
exec("""print("hello")""") output => hello
Kotlin supports JSR-223. You can use the jvm scripting engine to eval kts files.
val engine = ScriptEngineManager().getEngineByExtension("kts")
engine.eval("""print("hello")""")
You need JSR-223 library dependency. Refer to example
implementation("org.jetbrains.kotlin:kotlin-scripting-jsr223:$kotlinVersion")
Short answer: this isn't practical in Kotlin.
Technically, there may be ways, but they're likely to be far more trouble than they're worth; you're far better looking for a different approach to your problem.
Unlike a dynamic (‘scripting’) language like Python, Kotlin is statically-compiled. In the case of Kotlin/JVM, you run the Kotlin compiler to generate .class files with Java bytecode, which is then run by a JVM.
So if you really need to convert a string into code and run it, you'd have to find a way to ensure that a Kotlin compiler is available on the platform where your code is running (which it often won't be; compiled bytecode can run on any platform with a JVM, and most of those won't have Kotlin installed too). You'd then have to find a way to run the compiler; this will probably mean writing your source code out to a file, starting up the compiler program as a separate process (as I don't think there's an API for calling it directly), and checking the results. Then you'd have find the resulting bytecode and load into the JVM, which will probably mean setting up a separate classloader instance.
All of which is likely to be slow, fragile, and very awkward.
(See these previous questions which cover some of the same ground.)
(The details will be different for Kotlin/JS and Kotlin/Native, but I think the principles are roughly the same.)
In general, each computer language has its own approach, its own mind-set and ways of doing things, and it's best to try to understand that and accept that patterns and techniques from one language don't always translate well into another. (In the Olden Days™, it used to be said that a determined programmer could write FORTRAN programs in any language — but only in satire.)
Perhaps if you could explain why you want to do this, and what sort of problem you're trying to solve (probably as a separate question), we might be able to suggest more natural solutions in Kotlin.
While looking in the sample code for FunkyOverlayWindow, I just found a pretty interesting declaration:
pascal OSStatus MyHotKeyHandler(
EventHandlerCallRef nextHandler,
EventRef theEvent,
void *userData
);
Here, pascal is highlighted as a keyword (pink in standard Xcode color scheme). But I just found it's a macro, interestingly enough defined in file CarbonCore/ConditionalMacros.h as:
#define pascal
So, what is (or was) it supposed to do? Maybe it had some special use in the past?
While this discussion might not be well suited here, it would be interesting to know why Apple still using Carbon if this relates to the answer. I have no experience in Carbon, but this code appears to set a keyboard event handler which makes me wonder if there are any advantages over the Cocoa approach. Won't Carbon be ever removed completely?
Under the 68k Classic Mac OS runtime (e.g, before PowerPC or x86), C and Pascal used different calling conventions, so C applications had to declare the appropriate convention when calling into libraries using the Pascal conventions (including most of the operating system). The macro was implemented in contemporaneous compilers (e.g, MPW, Metrowerks, Think C).
In all newer runtimes, and in all modern compilers, the keyword is no longer recognized, so the ConditionalMacros.h header defines it away. There are a few comments in that file which may help explain a bit more -- read through it, if you're game.
You have encountered a calling convention.
The pascal calling convention for the x86 is described here.
It is very interesting that it was defined-away-to-nothing, which you notice means that it is not used anymore. It was common in the old days in x86-land, especially in the Microsoft Windows APIs, because of the ability of the processor to remove parameters from the stack at the end of a call with its special RET n instruction. Functions with the pascal calling convention were sometimes advantageous, because the caller wasn't explicity adjusting the stack pointer after each call returned.
If someone with more knowledge of why the macro still exists in the codebase, but is defined away comes along and gives you a better answer, I will happily withdraw this one.
I know this is pretty much a stupid question. I know almost nothing about how compiler really works.
But recently I want find what symbol name does the compiler generate for my ivar, my methods.
Where and how can I know the answer? (I have only used some IDEs. So if the solution is better to be simple . And it would be great help if the instructions you provide is really explicit)
(By the way,is there any reference that i can learn about the things like this?)
PS.I'm IOS developer.And if gcc and LLVM works different answer on this question , I would like to know both.
You can use nm to dump the content of a binary object. Then, each compiler has its own way of mangling. I suggest you have a look at Name mangling for objective C in wikipedia, it will help you understand how mangling works.
Surely GCC and Clang must have compatible name-mangling schemes, since they can use each other's code.
If you are using XCode 3 select a source file and then pick "Show Assembly Code" from the Build menu.
Apparently XCode 4 users do not need assembly code :-(
this is my first post, and it covers something which I've been trying to get working on and off for about a year now.
Essentially it boils down to the following: I have a copy of newlib which I'm trying to get working on an LPC2388 (an ARM7TDMI from NXP). This is on a linux box using arm-elf-gcc
The question I have is that I've been looking at a lot of the tutorials talking about porting newlib, and they all talk about the stubs (like exit, open, read/write, sbrk), and I have a pretty good idea of how to implement all of these functions. But where should I put them?
I have the newlib distribution from sources.redhat.com/pub/newlib/newlib-1.18.0.tar.gz and after poking around I found "syscalls.c" (in newlib-1.18.0/newlib/libc/sys/arm) which contains all of the stubs which I have to update, but they're all filled in with rather finished looking code (which does NOT seem to work without the crt0.S, which itself does not work with my chip).
Should I just be wiping out those functions myself, and re-writing them? Or should I write them somewhere else. Should I make a whole new folder in newlib/libc/sys with the name of my "architecture" and change the target to match?
I'm also curious if there's proper etiquette on distribution of something like this after releasing it as an open source project. I currently have a script which downloads binutils, arm-elf-gcc, newlib, and gdb, and compiles them. If I am modifying files which are in the newlib directory, should I hand a patch which my script auto-applies? Or should I add the modified newlib to the repository?
Thanks for bothering to read! Following this is a more detailed breakdown of what I'm doing.
For those who want/need more info about my setup:
I'm building a ARM videogame console based loosely on the Uzebox project ( http://belogic.com/uzebox/ ).
I've been doing all sorts of things pulling from a lot of different resources as I try and figure it out. You can read about the start of my adventures here (sparkfun forums, no one responds as I figure it out on my own): forum.sparkfun.com/viewtopic.php?f=11&t=22072
I followed all of this by reading through the Stackoverflow questions about porting newlib and saw a few of the different tutorials (like wiki.osdev.org/Porting_Newlib ) but they also suffer from telling me to implements stubs without mentioning where, who, what, when, or how!
But where should I put them?
You can put them where you like, so long as they exist in the final link. You might incorporate them in the libc library itself, or you might keep that generic, and have the syscalls as a separate target specific object file or library.
You may need to create your own target specific crt0.s and assemble and link it for your target.
A good tutorial by Miro Samek of Quantum Leaps on getting GNU/ARM development up and running is available here. The examples are based on an Atmel AT91 part so you will need to know a little about your NXP device to adapt the start-up code.
A ready made Newlib porting layer for LPC2xxx was available here, but the links ot teh files appear to be broken. The same porting layer is used in Martin Thomas' WinARM project. This is a Windows port of GNU ARM GCC, but the examples included in it are target specific not host specific.
You should only need to modify the porting layer on Newlib, and since it is target and application specific, you need not (in fact probably should not) submit your code to the project.
When I was using newlib that is exactly what I did, blew away crt0.s, syscalls.c and libcfunc.c. My personal preference was to link in the replacement for crt0.s and syscalls.c (rolled the few functions in libcfunc into the syscalls.c replacement) based on the embedded application.
I never had an interest in pushing any of that work back into the distro, so cannot help you there.
You are on the right path though, crt0.S and syscalls.c are where you want to work to customize for your target. Personally I was interested in a C library (and printf) and would primarily neuter all of the functions to return 0 or 1 or whatever it took to get the function to just work and not get in the way of linking, periodically making the file I/O functions operate on linked in data in rom/ram. Basically without replacing or modifying any other files in newlib I had a fair amount of success, so you are on the right path.
Sometimes I want to look up the implementations of functions in the stdlib, I've downloaded the sourcecode, but it's quite messy.
Just greping is not really suitable because of the many hits.
Does anyone know a webpage doxygen style that has the documentation.
The same goes for the linux kernel.
Thanks
You should check if your distribution is using the vanilla GLIBC or the EGLIBC fork (Debian and Ubuntu have switched to EGLIBC EDIT: they switched back around 2014).
Anyway, the repository browser for GLIBC is at http://sourceware.org/git/?p=glibc.git
http://code.woboq.org/userspace/glibc/, posted by #guruz below, is a good alternative.
The source is a bit complicated by the presence of multiple versions of the same files.
How about this for libc documentation? And perhaps this for the kernel? There is also Google Code search; here is an example search.
More on Google Code Search You can enter search queries like this: package:linux-2.6 malloc for any references to malloc in the linux-2.6 kernel.
Edit: Google Code search is now shut down. But you can access the git repo at http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git and it has search as well.
You can try http://code.woboq.org/userspace/glibc/
It has nice navigation/hilighting similar to an IDE.
To help navigate the source to glibc, perhaps try something like ctags or cscope?
Note: I get dumber every time I look at the glibc source, so please be careful! :)
If you are using GNU C (glibc), the functions (beyond the GNU extensions) follow the POSIX standard as far as their arguments, implementation, failure and return values. If you want to peek under the hood of static members, you'll have to look at the code.
Every push (that I can remember) to try and adopt something like Doxygen for glibc was rejected for the following reasons:
Redundant, POSIX already documents almost everything thats exposed, as well as man and info pages.
Too much work initially
More work for maintainers
As far as the kernel goes, Linux does use a system very similar to Doxygen called Kerneldoc.
You can also get actual Doxygen-generated docs from http://fossies.org/dox/glibc.