I was curious as to whether or not anybody was aware of a built-in Netlogo or Netlogo extension primitive that allows you to determine the operating system that the user is currently running? I wish to alter directory separators according to the user's operating system and being able to determine this information would be incredibly useful.
If there isn't any such thing, I'll get to building it!
No built-in primitive exists.
It would probably be possible to hack something kludgy together in pure NetLogo by using file-exists? to test for the presence or absence of certain OS-specific files, for example /etc/passwd.txt on Unix-like systems (including Mac OS X). As for the best files to use for this, I don't know, but it wouldn't surprise me if there was already an SO answer on this (since it isn't a NetLogo-specific question).
I thought maybe https://github.com/NetLogo/Shell-Extension/ had it. But I see now that it although it has primitives for reading and setting environment variables, it doesn't have similar primitives for Java system properties, which is what you need here (System.getProperty("os.name")). It would make a nice addition to the extension, I think.
re: "alter directory separators according to the user's operating system" specifically:
If you need to deal with paths that are coming from the operating system, then yeah, you need to be prepared to deal with platform-specific separators.
If you're only sending paths to the operating system, you may not need to worry about it. I haven't used Windows in a long time, but iirc it might just work to use forward slash.
If you're doing pathname manipulation, you'll probably want to check out Charles Staelin's pathdir extension, https://github.com/cstaelin/Pathdir-Extension. It includes a pathdir:get-separator primitive, as well as lots of other useful-looking stuff.
Related
ctags is a simple source code tagging system, also integrated in vi (and its flavours nvi, vim, etc.). AFAIK, it builds a plain text file where all the elements (functions, macros, ...) of the source code are indexed. But this file may become too large and unmanageable when the source code tree is extremely huge: this is the case of a kernel (Linux, *BSD, or similar).
Is still ctags or exuberant-ctags suitable for a complex source tree like a kernel?
If not, what tools (with the same integration in vi as ctags) can replace it? This may become subjective, so if possible provide a list of suggested tools: any comments, and references to a guide with the keyboard shortcuts in vi, are welcome.
Supported languages should be at least C, C++, assembly. The tool should be usable through CLI. I would principally like to jump to the definition of functions, macros, struct and similar objects (with ctags, pressing Ctrl+] with the cursor over the item name), to their manpages if possible, and back to the code.
The only alternative tool I know so far is GNU global, with a pretty complex vi integration, which seems to be possible only through Perl (and I can't find the equivalent of Ctrl+]).
The answer to your first point is a resounding yes.
You can use ctags to generate a tags file for different subtrees, thus keeping the size of the generated file to a minimum. At this point, you need to have a mechanism in place for searching for these multiple tags files. Vim provides this, of course.
I have given some advice here, so you may want to check that out.
Of course, I use exuberant-ctags there, so keep that in mind.
For instance, lets say hypothetically that we have access to the Windows source code.
Now can we modify the source code to operate entirely on ext4 file system, instead of NTFS, just by changing the code modules that depend on the exact file system being used? Or will major changes in the way the kernel works be needed?
To what extent does the file system being used affect the kernel design?
(Note: You can switch the above example with the case of ReactOS, which is an open source clone of Windows 2000 and supports only FAT file system, and ext4.
Moreover, I know that Windows source code is not available to public so a definitive opinion cannot be given. I'm asking based on whatever is known about Windows internals, for my given example, and as per general principles of Kernel design.)
Generally, the OS kernel is not dependent upon file systems. Most operating systems support multiple file systems.
Is there a good cross-platform method for determining the number of processors a machine has in elisp? I'm trying to make my config auto detect some build options, and would like to have it automatically use the number of processors + 1. Grepping /proc/cpuinfo isn't a solution for me because it won't work on Windows.
Emacs 24.3 Lisp doesn't have access to that information. Your options would seem to include:
writing an Elisp library which uses the value of SYSTEM-TYPE to choose a system-specific method for getting the processor count;
modifying the Emacs C source and rebuilding it so that it can, for each potentially multiprocessor platform on which Emacs builds, expose the processor count at the Lisp level.
At least, that was true four hours ago, when I first started writing this answer. But then I got interested in the problem, and now you have a third option:
downloading my system-cores.el library, which implements the first of the two options above, and calling (system-cores :physical) to get the number of physical processors, (system-cores :logical) to get the number of logical cores, or just plain (system-cores) to get an alist containing both.
Caveats include:
This library relies strongly on the PROCESS-LINES function. If that function can't do anything sensible in the context where you need to call SYSTEM-CORES, then SYSTEM-CORES can't either. (For example, if you're on Darwin and (getenv "PATH") doesn't contain /usr/sbin, PROCESS-LINES will bomb out with "Searching for program: no such file or directory, system_profiler".)
The systems currently known to be supported are GNU/Linux (anything with /proc/cpuinfo, more or less), Windows NT (and its derivatives, including 2000, XP, and all subsequent versions), and Darwin (OS X, at least 10.8, theoretically as far back as 10.2). Not coincidentally, these are also the systems to which I have access.
I've also included a delegate which should work properly on at least some flavors of BSD, but I don't have a BSD box on which to test it, so there's no telling whether or not it'll really work -- at the very least, you'll almost certainly need to modify the list of sysctls examined by the SYSTEM-CORES-SYSCTL delegate.
If you're using a modern variety of Linux, Windows, or OS X, great! You should be good to go, right out of the box. If not, and if your platform includes a command-line utility which provides the requisite information in its results, then it shouldn't be hard to write a delegate for your system. Or, if you don't want to write a delegate yourself, then email me all of:
the proper invocation for the command-line utility in question
a sample of the output it produces on your system
the output of M-: system-type in Emacs
the output of M-: system-configuration in Emacs
and I'll be able to write a delegate myself and add it to the library.
Edit: The :cores and :processors keywords have been replaced with :physical and :logical, respectively; I couldn't keep them straight, and I don't see why I should expect anyone else to, either.
Edit: Per #lunaryorn, replaced (split-string (shell-command-to-string ...)) with (process-lines ...). This saves invoking a shell, which might make the library more reliable, and certainly makes its code easier to read.
Lisp syntax represents AST as far as I know, but in high level format to allow human to easily read and modify, at the same time make it easy for the machine to process the source code as well.
For this reason, in Lisp, it is said that code is data and data is code, since code (s-epxression) is just AST, in essence. We can plug in more ASTs (which is our data, which is just lisp code) into other ASTs (lisp code) or independently to extend its functionality and manipulate it on the fly (runtime) without having to recompile the whole OS to integrate new code.In other languages, we have to recompile from to turn the human-language source code into valid AST before it is compiled into code.
Is this the reason for Lisp syntax to be designed like it is (represent an AST but is human readable, to satisfy both human and the machine) in the first place? To enable stronger (on the fly - runtime) as well as simpler (no recompile, faster) communication between man-machine?
I heard that the Lisp machine only has a single address space which holds all data. In operating system like Linux, the programmers only have virtual address space and pretend it to be the real physical address space and can do whatever they want. Data and code in Linux are separated regions, because effectively, data is data and data is code. In normal OS written in C (or C like language), it would be very messy if we only operate a single address space for the whole system and mixing data with code would be very messy.
In Lisp Machine, since code is data and data is code, is this the reason for this to have only a single address space (without the virtual layer)? Since we have GC and no pointer, should it be safe to operate on physical memory without breaking it (since having only 1 single space is a lot less complicated)?
EDIT: I ask this because it is said that one of the advantage of Lisp is single address space:
A safe language means a reliable environment without the need to
separate tasks out into their own separate memory spaces.
The "clearly separated process" model characteristic of Unix has
potent merits when dealing with software that might be unreliable to
the point of being unsafe, as is the case with code written in C or
C++ , where an invalid pointer access can "take down the system."
MS-DOS and its heirs are very unreliable in that sense, where just
about any program bug can take the whole system down; "Blue Screen of
Death" and the likes.
If the whole system is constructed and coded in Lisp, the system is as
reliable as the Lisp environment. Typically this is quite safe, as
once you get to the standards-compliant layers, they are quite
reliable, and don't offer direct pointer access that would allow the
system to self-destruct.
Third Law of Sane Personal Computing
Volatile storage devices (i.e. RAM) shall serve exclusively as
read/write cache for non-volatile storage devices. From the
perspective of all software except for the operating system, the
machine must present a single address space which can be considered
non-volatile. No computer system obeys this law which takes longer to
fully recover its state from a disruption of its power source than an
electric lamp would.
Single address space, as it is stated, holds all the running processes in the same memory space. I am just curious why people insist that single address space is better. I relate it to the AST like syntax of Lisp, to try to explain how it fits the single space model.
Your question doesn't reflect reality very accurately, especially in the part about code/data separation in Linux and other OS'es. Actually, this separation is enforced not at the OS level, but by the compiler/program loader. At the OS level there are just memory pages that can have different protection bits set (like executable, read-only etc), and above this level different executable formats exist (like ELF in Linux) that specify restrictions on different parts of program memory.
Returning to Lisp, as far as I know, historically, the S-expression format was used by Lisp creators, because they wanted to concentrate on the semantics of the language, putting syntax aside for some time. There was a plan to eventually create some syntax for Lisp (see M-expressions), and there were some Lisp-based languages which had some more syntax, like Dylan. But, overall, the Lisp community had come to the consensus, that the benefits of S-expressions outweight their cons, so they had stuck.
Regarding code as data, this is not strictly bound to S-expressions, as other code can as well be treated as data. This whole approach is called meta-programming and is supported at different levels and with different mechanisms by many languages. Every language, that supports eval (Perl, JavaScript, Python) allows to treat code as data, just the representation is almost always a string, while in Lisp it is a tree, which is much much more convenient and facilitates advanced stuff, like macros.
I know all about the history of different OSes having different path formats, but at this point in time there seems to be a general agreement (with one sorta irrelevant holdout*) about how paths work. I find the whole File::Spec route of path management to be clunky and a useless pain.
Is it really worth having this baroque set of functions to manipulate paths? Please convince me I am being shortsighted.
* Irrelevant because even MS Windows allows forward slashes in paths, which means the only funky thing is the volume at the start and that has never really been a problem for me.
Two major systems have volumes. What's the parent of C:? In unix, it's C:/... In Windows, it's C:... (Unfortunately, most people misuse File::Spec to the point of breaking this.)
There are three different set of path separators in the major systems. The fact that Windows supports "/" could simplify building paths, but it doesn't help in parsing them or to canonising them.
File::Spec also provides useful functions that make it useful even if every system did use the same style of paths, such as the one that turns a path into a relative path.
That said, I never use File::Spec. I use Path::Class instead. Without sacrificing any usability or usefulness, Path::Class provides a much better interface. And it doesn't let users mishandle volumes.
For usual file management inside Perl, No, File::Spec is not necessary and using forward slahes everywhere makes much less pain and works on Win32 anyways.
cpanminus is a good example used by lots of people and have been proved work great on win32 platform. it doesn't use File::Spec for most file path manipulation and just uses forward slashes - that was even suggested so by the experienced Perl-Win32 developers.
The only place I had to use File::Spec's catfile in cpanm, though, is where I extract file paths from a perl error message (Can't locate File\Path.pm blah blah) and create a file path to pass to the command line (i.e. cmd.exe).
Meanwhile File::Spec provides useful functions such as canonical and rel2abs - that's not "necessary" per se but really useful.
Yes absolutely.
Golden rule of programming, never hard code string literals.
Edit: One of the best ways to avoid porting issues is to avoid OS specific constants especially in the form of inline literals.
i.e e.g drive + ":/" + path + "/" + filename
It is bad practice yet We all commit these attrocities in the haste of the moment or because it doesn't matter for that piece of code. File::Spec is there for when a programmer is adhering to gospel programming.
In addition it provides the values of special and often used system directories e.g tmp or devnull which can vary from one distribution/OS to another.
If anything it could probably do with some other members added to it like user to point to the users home directory
makepp (makepp.sourceforge.net) has a makefile variable $/ which is either / or \ (on non-Cygwin Win). The reason is that Win accepts / in filenames, but not in command names (where it starts an option).
From http://perldoc.perl.org/File/Spec.html:
catdir
Concatenate two or more directory names to form a complete path ending with a directory. But remove the trailing slash from the resulting string, because it doesn't look good, isn't necessary and confuses OS/2. Of course, if this is the root directory, don't cut off the trailing slash :-)
So for example in this example I wouldn't need the regex to remove the trailing slash if I would use catdir.