What do we mean by XPG6 in limits.h file?
XPG was the X/Open Portability Guide, a pre-POSIX consortium to promote interoperability between different UNIX vendors. XPG6 is "X/Open Portability Guide, Issue 6".
Related
Does anybody heard of or has an idea about possibility of integration some scripting engine (like tcl, perl, python etc.) into U-boot?
The reason is that U-boot is major tool used during board bring-up and it's programming possibilities are quite limited and more abilities are wanted.
Thanks.
No, this is usually handled off-device. Historically the most common way to do this was with expect and more recently in mainline U-Boot we now have test/py/test.py that works with both sandbox and real hardware.
Many shell developers spend much effort in developing portable code, avoiding for example Bashisms, and I wonder how much this increased effort really contributes to compliance with software requirements.
I wonder if it is possible to give a simple checklist of conditions requiring portable code. Let us assume
that using shell instead of $BETTER_LANGUAGE actually makes sense,
that each shell has the same version on all target systems (i.e. shell version differences are not part of portability),
that readability/changeability is not considered for the moment (portable code may be easier to read / understand than e.g. the newest Bash RegEx feature).
This is what has come to my mind so far:
Code is actually (or probably in the future) and intentionally executed in different shells (e.g. because the target platforms are limited to different shells, or because the code may have to be executed in a faster shell like dash in the future) and providing different implementations is not feasible.
Code is part of a framework that aims to be portable itself
Code is part of a source package that must be buildable on a variety of platforms
The software is distributed as a package for a variety of target systems and the developer does not want to introduce a dependency on a specific shell
Are there any obvious conditions that I haven't thought of, or could they be expressed more generally? Would POSIX compliance require a different checklist than general portability? Is there any literature or other source that you would recommend?
I wonder how much this increased effort really contributes to compliance with software requirements.
This - "this increased effort" - suggests that choice of the shell as programming language was wrong in the first place. Shell is the language of plumbing: you do NOT implement tools in it - you control other tools with it. If a shell script takes long time to develop, if you run into limitations of the POSIX shell, then the shell is very likely the wrong language.
The only exception to that, and something missing from your checklist, is the environment of a bare, as if freshly installed, commercial UNIX system (and probably some of the *BSD systems). If you develop software for such systems, then you would probably have to use the POSIX shell, simply because there might be literally nothing (as in literally "literally nothing") else installed on the system.
In the end, all software comes with the list of dependencies and prerequisites. If you include the bash as dependency, it would bother no *NIX admin: bash is often the first 3rd party package installed on such systems anyway. Also, compared to other 3rd party software, the bash (as other popular shells, e.g. csh, tcsh, ksh) is literally free of the installation and dependency problems.
Would POSIX compliance require a different checklist than general portability?
There is no such thing as "general portability". Portability is always particular.
Software portability, broadly defined, is a ability of the software to run on two or more different operating systems. POSIX is an operating system standard, defining a part of the OS interfaces to users and software developers. It is a platform foundation, not a platform of its own.
POSIX compliance requirement I have seen only in some niche markets. Often for sole reason that it is the only operating system ISO standard in existence.
For the software which doesn't have the hard requirement of the "POSIX compliance", generally it is recommended to target specific platforms. Common denominator might still be the POSIX standard, but the OS specific features, customizations and handling simply make the software better for the users of the particular platform.
In the end, users do not care about the POSIX. The POSIX is the tool for the developers. Developers use it to reduce the costs of developing and maintaining the software for multiple platform. Thus the requirement, as it comes from the users, is the support of a particular platform, not "POSIX compliance".
What is the meaning of *nix, and what is its relation with Ruby?
Just saw that in an interview question... I think there is something to do with UNIX distros, but I am not sure.
Could not find it here or in the Wikipedia, so I am asking.
What is the meaning ?
And what is its relation with Ruby ? because the question was about Ruby.
*nix just means operating systems that are like the old workhorse Unix. Some examples include Linux, FreeBSD, and Mac OS X (its kernel, Darwin, is based on BSD).
The main relation between *nix and Ruby is just a pragmatic one; most Ruby developers seem to prefer to work on Unix-like OSes (typically Linux or Mac OS X). There's no official relationship, and it's quite possible to work with Ruby on non-*nix OSes like Windows.
*nix means UNIX-like; it is an operating system that behaves in a manner similar to that of a UNIX operating system without necessarily conforming to the Single UNIX Specification.
Wikipedia:*nix actually redirects to Wikipedia:Unix-like.
As for Ruby's connection to *nix, Ruby was developed mostly on GNU/Linux by the open-source community, so it may be something to do with Ruby running better on *nix systems or Ruby developers preferring to work on *nix systems.
It's an abbreviation for UNIX-like operating systems, including LINUX.
See also the UNIX-like Wikipedia page.
*nix is a general term to refer to the whole family of Unices, to the operating systems that follow the POSIX1 standard.
Ruby is a programming language, there's no general relationship between the two.
1: Portable Operating System Interface [for Unix]
It means the unix-like family of OSes. No relation to Ruby.
"*nix" refers to the Unix family of operating systems and its FOSS variants (Linux, FreeBSD, etc.). They have a different API than Windows, so any programming or scripting language that runs on them will have slightly different behavior and capabilities than on Windows.
A Unix-like (sometimes referred to as UN*X or *nix) operating system is one that behaves in a manner similar to a Unix system, while not necessarily conforming to or being certified to any version of the Single UNIX Specification. A Unix-like application is one that behaves like the corresponding Unix command or shell. There is no standard for defining the term, and some difference of opinion is possible as to the degree to which a given operating system or application is "Unix-like".
As a port, I'd think it'd be hard to keep it completely up to speed with GCC. Is it, or are there any differences with regards to standards compliance or features?
On a version to version, basis, yes, as far as is possible. In other words 4.4.1 on Windows should be as c++ Standard compliant as 4.4.1 on Linux (for example). But there are, as far as I know, no guarantees of this.
OTOH, will the two implementations work in the same way? Almost certainly not - we've had a couple of examples of differences posted here recently. But can you use the implementations to port between Windows and Linux - yes, I do this routinely.
There are a bunch of different Scheme interpreters available for the Mac:
http://www.dmoz.org/Computers/Programming/Languages/Lisp/Scheme/Implementations/
Which one is generally supported the best? I'm also interested in 64-bit support and multi-core/processor support.
I don't know which ones are supported the best, but I've used Larceny, DrScheme and Bigloo.
I believe that Larceny is widely believed to be the fastest open source scheme compiler available. It follows the unix tools based philosophy (no IDE). I don't believe it has 64 bit support yet. I haven't used it for a while, but the web site claims R6RS support. If I was to use scheme in anger, this is probably the system I would choose.
DrScheme is the one I use the most, because it's easier to use :) It has an IDE that understands the language as well as a profiler. It fits what I want from scheme quite well (ie playing around with things to find out how they work). It's performance has improved considerably since I started using it. Large set of libraries. R6RS support (mostly). 64 bit support for Linux.
Bigloo is interesting in that it targets several back ends, including JVM, .NET and native code.
All seem to have reasonable community support, but I see DrScheme mentioned the most.
DrScheme isn't actually a Scheme dialect - it's an editor, part of the PLT Scheme distribution:
http://www.plt-scheme.org/
(The actual Scheme interpreter command is 'mzscheme', but I have no idea of the origins.)
I use PLT Scheme for web-development under OSX, and it is extremely good, with excellent library support. DrScheme is my editor of choice - most regular editors don't have S-expression indentation engines.
Gambit (R5RS) threads, 64-bit, Termite (shared nothing parallelism)
Chicken (R5RS) threads, 64-bit
Ikarus (R6RS) 64-bit
Ypsilon (R6RS) 32-bit
I'd also encourage you to try (my personal favorite) Petite Chez Scheme which comes in 32-bit/64-bit and threaded/non-threaded versions for all popular platforms.
Go for DrScheme now called Racket; it is the best. I always recommend it for beginners because of its hassle-free installation. Mit-Scheme is the most widely used but MacOsXLion may give you headaches in installation.