Talk:Executable library

History

This task came from discussions Here. I was nervous about just deleting all the code for that task so decided to create this, mark the other for maybe future deletion, and see how things go. --Paddy3118 23:44, 14 March 2011 (UTC)

Tcl problem

Oh no, after all the confusion of Scripted main the Tcl example shows a design pattern that is central to the method, but doesn't follow the task description in a way that I had thought a secondary feature of the task - the two separate files. I won't make any changes just yet, (maybe the Tcl author would like to comment)? But I am aware that although I like what this sets out to do, the explanation might need further clarification. --Paddy3118 06:13, 16 March 2011 (UTC)

I must've been distracted when I wrote it. Corrected. –Donal Fellows 11:28, 16 March 2011 (UTC)

Thanks Donal. --Paddy3118 12:34, 16 March 2011 (UTC)

executable Shared Objects?

Is there a way to build Shared Objects to make them valid executables? --Oenone 08:41, 19 April 2011 (UTC)

Presumably you mean Shared Objects and not Shared Objects? --Rdm 12:19, 19 April 2011 (UTC)

I know it's doable in the former case on Windows. I don't know enough about ELF to know if it's doable there. --Michael Mol 12:24, 19 April 2011 (UTC)

Yes, I was talking about ELF Shared Objects. I don't know any way to make it both, a shared object and an executable. So for Unix the task is not solvable. --Oenone 12:35, 19 April 2011 (UTC)

ELF != Unix -- you just need a different file format (and, thus, a different "interpreter"). But the problem with elf is e_type where 2 is "executable file" and 3 is "shared object" http://linux.die.net/man/5/elf --Rdm 13:07, 19 April 2011 (UTC)

There are other problems with ELF shared objects. With systems like OpenBSD, an executable needs some special code to initialize certain variables (like environ and __progname), to call main() and to call exit() with the return value from main. A shared object misses this special code, so you cannot start a shared object as an executable. --Kernigh 17:11, 19 April 2011 (UTC)

I think I am missing something here. Why can't an elf shared object be made to contain this code? --Rdm 18:18, 19 April 2011 (UTC)

I don't know know much of anything about ELF, but you mentioned e_type...I'm guessing that's a header field which identifies the role of the binary? Perhaps there's no spec for how to execute that glue code if e_type isn't 2? (It's arguable that not all of that glue code is strictly necessary, though; the task is satisfiable without referencing environment varss, so environ might not be necessary) --Michael Mol 18:49, 19 April 2011 (UTC)

Sure, ok... I suppose my point was that, if e_type had been defined as a bitfield instead of an enum, this kind of issue could have been solved already. Not that I can see a use for a core dump which is also a shared object and and also an executable... And I suppose ELF could be extended to support a "shared object that is also an executable", though I am not sure who could get away with defining such an extension. (On Linux it would be whoever owns /etc/ld-linux.so but for ELF as a whole it's probably some standards body that would take 10 years before they could get around to considering the issue.) --Rdm 19:03, 19 April 2011 (UTC)

So, most compiled languages will have to be omitted, since most operating systems don't provide anything to make this possible. Using GCC you could produce relocatable object code, which can be converted into an executable or a library, but this was excluded in the task description. --Oenone 11:51, 10 May 2011 (UTC)

Most likely. It should be possible in several dynamic languages, and is heavily endorsed by Python.--Paddy3118 18:48, 10 May 2011 (UTC)

Alternatively: currently the task does not require the library be a single file -- it could easily be a directory or more properly a set of files within a directory. (And if it were changed to be required to be implemented as a single flat file it might be possible to do something by wrapping the necessary pieces in a manner something like a self extracting archive, which when used normally is an executable but can be told to extract the needed library elements at compile time, with an invocation that would need to go in the makefile or msbuild file or whatever. (Though, of course, the task could also be changed to prohibit the generation of object code at compile time, but I think most compilers generate intermediate object files as a normal part of the compilation process..)) --Rdm 20:07, 10 May 2011 (UTC)

The idea is for the library/shared object/module/... to be what is normally thought of as such for the language, accessed in the normal way for that language. Similarly when used as an executable it should be done in the normal way an executable is run in that language and accessing the same source. I want to allow a language the ability to mess with the content of their library-cum-program, (and maybe with the options used when invoking it in either mode?). For a compiled language, running the compiler as part of 'running' the library is not normal. The only way I could currently see a compiled language being able to do this is if their is some trick which allows a shared object when run to act like an executable, and when used as a library, e.g. left on LD_LIBRARY_PATH in Unix, to act as shared object library.

It's a bit hard to say what "the normal way" would be I have used plenty of programs which have required installers because they had so many moving parts. But, also -- in the case of compiled languages -- we are speaking of operating system distinctions here, and not language distinctions. (For example, consider the possibility of a program using 9p to present entirely different images for the same file, depending on context. The protocol itself is language independent, but support for it is not operating system independent.) --Rdm 05:29, 11 May 2011 (UTC)

You don't normally require the presence of the compiler at run time so I would expect any solution to not need a compiler as part of the solution.

What might be possible - although I am at one of the many boundaries to my knowledge - is maybe to use the neccessary presence of a byte-code interpreter for languages that normally require the use of a byte-code interpreter when run.

Some languages are released with compilers and interpreters. If they can fashion an example that is constrained to using their interpreters only then they should state that prominently and give their solution. I think Haskel has an interpreter. Their are much lesser known interpreters for what are normally thought of as static languages, such as C. A solution for those might best be put under the actual name of the interpreter as their may be so much distance between the two. --Paddy3118 02:06, 11 May 2011 (UTC)

C debug help request

Hi guys, I was impressed with the C example enough to try it out but I can't get it to compile on Ubuntu?

My efforts so far:

<snipped/>

--Paddy3118 12:22, 16 June 2011 (UTC)

missing #i from #include ? --Oenone 12:28, 16 June 2011 (UTC)

Thanks! that was indeed the problem. --Paddy3118 12:42, 16 June 2011 (UTC)

Now that I have the C code working for me, I am impressed yet again. --Paddy3118 12:43, 16 June 2011 (UTC)

Too complicated

This whole thing is getting too complicated. The purpose of ScriptedMain is to list code in as many languages as possible that does this: http://docs.python.org/library/__main__.html For lack of a better name, it can be called "scripted main". It reinforces the idea that such a function runs when the script is run on its own, not when the module is imported by other code. --User:Mcandre

Not quite. The point is more like you can have a useful library for other programs to access as well as a useful program in its own right from the same file.

Your suggested name isn't descriptive. It is hard to put a name on something using just two words, but I think "Executable library" has the advantage of being more descriptive.

This tasks was written to allow languages to give a concrete example of an executable library where they can focus on the executable library part of the task but using part of a more simpler task as the basis of the library, that already has many examples - the extra work would be mostly on turning it into an executable library that could be demonstrated to work, and comparable in how the language gets things to work, in both aspects of the task: as a library and as an executable.

Too complicated? I don't think the task is overly complex for what it attempts to describe, as the task might well be foreign to the RC audience and so programmers need guidance in trying to nail things down, remember, executable libraries might be popular, (such as being mentioned in official documentation), in maybe only Python. It's certainly not a popular technique in C :-)

--Paddy3118 02:24, 6 August 2011 (UTC)

Ah, I get it now. The hailstone example serves two purposes: borrow from another RC article, avoiding duplication; and present a useful example of API/CLI bundling. My ScriptedMain examples do not offer a practical reason for their existence. However, I think that the hailstone sequence is a bit much for coders who just want the Executable library behavior. Maybe use Hello World instead? I see now that it's hard to strike a balance between simplicity and usefulness. Do you have more suggestions for RC-ifying my submissions? --User:Mcandre

Pike problem

"to use the library as a class, save it as HailStone.pike to use it as a module, save it as Hailstone.pmod " is not what the task is after. Make it one file and your on! --Paddy3118 07:34, 7 November 2011 (UTC)