I wish a DITA editing tool could be as convenient to write with as Evernote.
Monday, September 21, 2015
Sunday, September 20, 2015
Introducing GRANITENET and the FELDSPAR Platform Agnostic Object System.
As the author of this article being someone who has developed a distinct sense of interest about the logic and the existing body of work in regards to concepts of operating systems design -- moreover, a sense of interest as with regards to the effects of specific design choices in operating systems design, as of design choices ultimately resulting in discrete effects with regards to operating system applications, in any single common domain of computing, including software development, and effects in regards to application system maintenance -- the author of this article, though for some time familiar with the Debian GNU/Linux operating system, the author of this article has lately become more a fan of the FreeBSD operating system. It is this author's candid opinion that FreeBSD presents a markedly less cluttered development environment than the GNU environment of GNU/Linux systems. Not as though to meanly criticize either the Free Software Foundation (FSF) or its supporters, the author of this article is aware that operating system distributions such as Debian GNU/Linux are systems that have evolved, over time, initially from relatively small-scale origins. Considering a conceptual paradigm in which GNU tools are developed as to be modular, moreover portable with other GNU tools, moreover in which the Linux kernel itself and applications of the Linux kernel have been shaped with developments in operating system standardization -- broadly, under a heading of a colloquial definition of UNIX systems, more specifically as under the headings of international standards such as the versions of POSIX and specifications published by the Open Group and later X/Open company, moreover as with regards to standards published by the Internet Engineering Task Force (IETF) -- the author of this article is aware that it may entail no manner of a trivial work, to develop any single, working computer system out of so many individual software components and software systems standards. Perhaps there has been a certain degree of centrally managed organization, in the development of the FreeBSD operating system -- if not, moreover, a greater degree of flexibility as with regards to distinctions of the BSD licenses, juxtaposed to the GNU Public License (GPL) or derivatives of the GPL -- such that may result in an impression -- as to the author's opinion -- that FreeBSD is a really well organized, really uncluttered operating system, moreover very easy to apply in begining software and systems development. Certainly, such an impression is aided with the availability of so many centrally managed reference documents about FreeBSD, as in regards to the FreeBSD base system and the FreeBSD kernel.
The author would not wish to abridge any introduction about FreeBSD. This article, presently, is developed not insomuch as to make an in depth study of the FreeBSD operating system, but rather to begin to develop a set of concepts that the author has found occurring to the author's own sense of consideration, during applications of the FreeBSD operating system. The author has been operating a local area network (LAN) with FreeBSD on the the LAN gateway host, on the software build host, and on the author's primary notebook laptop, on the LAN, for a small number of months. The author has begun to develop a concrete concept of the configuration of the same LAN, referring to it then as GraniteLAN. In an architectural sense, GraniteLAN may be integrated moreover with hosts configured of software defined networking (SDN) services -- there under the heading GraniteSDN -- as to develop an overall systems development network -- with the full network under the heading, GRANITENET. Presently, the author does not wish to develop any length sidebar about the architecture of the GRANITENET design, or the design philosophy of the same. It's basically a concept for a scalable DevOps network, and a small office/home office (SOHO) network, such that may be utilized not only from GRAITELAN, but moreover that may be utilized from a mobile appliance not immediately connected to but configured for connection to GRANITESDN. In its architecture, GRANITENET would apply a distinct number of common UNIX networking services, such as LDAP, NFS, NIS, Kerberos, and -- furthermore -- RADIUS. Though it may seem relatively easy to write about, as such, but -- in order to develop a manageable framework of so many network services, as such, and for it to be relevant in regards to applications on contemporary operating system architectures -- it may not ultimately be as easy to "Glue together," in application of so many software components. At least, it may be easy to "Put together" the concept of GRANITENET's design -- initially, as it representing a manner of a paper machine, as to apply an older phrase to the matter -- as it entailing a design of an effectively multi-homed application of the FreeBSD operating system.
In regards to the manageability of the design and applications of GRANITENET, of course there must be a manner of a design incentive thought to exist. The author might not believe that every reader would share the author's sense of appreciation about the logical design of each of Common Lisp the Language, 2nd Edition, and CORBA systems, furthermore the Object Management Group's concepts of Object Management Architecture and Model Driven Architecture -- moreover, the portability of systems developed onto CORBA and, separately, the portability of applications developed onto the Common Language Infrastruture (CLI), the latter as popularized of the Microsoft Dot-NET and the Xamarin and Mono platforms, furthermore as standardized onto ECMA-335.
Insofar as it representing a concept of a paper machine, the author has certainly expended some paper and graphite, in putting together a number of offline notes about the design of GRANITENET, moreover the design of a system the author denotes as FELDSPAR. FELDSPAR would represent an application of Common Lisp, CORBA, and the Common Lisp Interface Manager, as to create a bundled application development kit of free/open source software for applications of the same software and systems components. In that regards, perhaps it might seem like overmuch of an aspiring goal -- as to apply GRANITENET in developing the FELDSPAR framework, while GRANITENET is not even completely constructed, in itself, as yet. However, in retaining a sense of focus about the logical qualities of the design of each of GRANITENET and the FELDSPAR framework, it therefore remains a manageable set of concepts, at least to the author's own sense of consideration.
In beginning to describe these discrete concepts to the Internet audience, it must naturally entail a development of a literal body of documentation. Thus -- in focusing about the Darwin Information Typing Architecture (DITA) -- there is a sense of a topic repository model developed in the FELDSPAR systems design, insofar as of the present paper machine edition of the FELDSPAR systems design. The topic repository model -- in some regards, semantically -- it might resemble something of a concept like of a Wiki. Though a FELDSPAR topic repository would be published to the Web, but -- in it utilizing DITA,l in its content source model -- it would not be immediately managed "on the web". The FELDSPAR Topic Repository model would allow for managing the body of content of a topic repository, as in application of so many DITA editing tools, multimedia content development tools, and changeset management tool such as Git -- without HTTP interverning between the editor and the filesystem. As such, perhaps it may not seem to be an immediately enterprise friendly framework, but perhaps it may be scalable outwards from its initial SOHO friendly design.
In beginning to document this design, in a digital format of text, the author of this article wishes to make reference -- immediately -- reference to MARTE, specifically MARTE 1.1, furthermore to make reference to the DOAP RDF schema. Surely, it may be possible to develop a great amount of semantic sugar, in application of such normative specifications. Presently, the author wishes to recommend a concept of software platform, in an abstract sense, as may be extended to subsume concepts both of operating system platform and of toolchain architecture, furthermore as to provide a sense of structure about application components commonly referred to as libraries -- then to include the DOAP RDF schema, as to develop a documentation framework with which software developers may be able to make consistent, ostensibly convenient reference to all points of upstream software distribution, for any single software component.
Towards developing an initial usage case to this sense of structure in software and systems: The author of this article has begun to write a small series of notes, in the author's own Evernote notebook, as to begin to develop some normative documentation towards an application of the Enlightenment Foundation Libraries (EFL) and the EFL WebKit integration, namely towards developing an EFL port for the Common Lisp Interface Manager (CLIM) as well as extensions for CLIM, in regards to web appliations, such that would be developed as for application at least onto FreeBSD, Linux Desktop, Android Mobile, and Microsoft Windows Desktop operating system platforms. Perhaps it aspires as towards a comprehensive design, to be thorough in regards to development and support of operating system applications.
Though the author is furthermore interested about some concepts of microcontroller design, reprogrammable computing, and the history of the infamous Lisp Machine, but perhaps it may turn out to be a manner of a fortuitous effort, to begin with regards to applications of existing microprocessor achitectures and existing operating systems, specifically beginning at the manner of a colloquial UNIX-like framework developed of the FreeBSD Project -- furthermore, as FreeBSD being extended in a small number of by-in-large domain-special FreeBSD distributions.
So, that would be towards an unabridged introduction.
In focusing immediately towards applications of the EFL toolkit, there is immediately a concern that occurs as with regards to illustrating the toolkit's software components and software component depencencies, as towards any single distribution of the EFL toolkit -- in a sense, as towards any single distribution of a bundled set of EFL toolkit components, whether immediately with or without the EFL WebKit integration, and finally in a distribution to any single operating system platform, in application of any single toolchain architecture. This would be essentially orthogonal to -- but, in a sense, essential to -- the development of a CLIM port for EFL.
The author proposes to develop a model for each of the following concepts, in extending the MARTE 1.1 Profile for the UML metamodel:
That being so, then how may the author propose to publish a UML profile model, in any vendor-compatible regards? The author proposes to apply Modelio, and to publish the UML profile models finally as serialized XMI. The author furthermore proposes to apply the respective UML profile models, in development of a manner of a component metadata database, there integrating the DOAP RDF schema and some manner of a web publishing model for presenting the metadata database, in any managed manner, online. The DOAP RDF integration, in itself, may entail a development of an extensional RDF schema, moreover an application of some existing tools for RDF graph modeling in Common Lisp.
Of course, there is a sort of a boostrapping dilemma, in such design. The author proposes to address the bootstrapping dilemma, in -- albeit, perhaps in something of a expressly nolinear sense -- but in an overall iterative sense, however. In such a sense, the author does not propose to specify that the design of the RDF application would wait on the design of the project-oriented management information system (Project MIS). The RDF application must wait, however, for the design of the final component metadata schema.
Towards such an application of RDF, the author wishes to comment towards a sense of applying Common Lisp as a data system feature, within a data programming system, there closely and comprehensively integratred with the underlying operating system. The author proposes to limit this specific design to the FreeBSD operating system, moreover to focus about a small number of individual, concrete components such as already developed as and for individual Common Lisp implementations. The goal of this aspect of the design, to the author's opinion, the goal is to support software systems development with software systems development and documentation. In such a regards, perhaps it might seem like a manner of a DevOps concept, however developed of a popularly unconventional framework
The RDF application, specifically, it may be developed as to extend of an XML Schema Datatypes implementation. As in a manner across the XML Schema Datatypes Implementation, it may be integrated onto a data persistence model for RDF, there to apply a HypersonicSQL service as a data storage service.
If there may be a rhetorical question, such as, "Where to begin, next?" the author prpoposes to continue with the development of the UML profile models, as denoted herein.
The author would not wish to abridge any introduction about FreeBSD. This article, presently, is developed not insomuch as to make an in depth study of the FreeBSD operating system, but rather to begin to develop a set of concepts that the author has found occurring to the author's own sense of consideration, during applications of the FreeBSD operating system. The author has been operating a local area network (LAN) with FreeBSD on the the LAN gateway host, on the software build host, and on the author's primary notebook laptop, on the LAN, for a small number of months. The author has begun to develop a concrete concept of the configuration of the same LAN, referring to it then as GraniteLAN. In an architectural sense, GraniteLAN may be integrated moreover with hosts configured of software defined networking (SDN) services -- there under the heading GraniteSDN -- as to develop an overall systems development network -- with the full network under the heading, GRANITENET. Presently, the author does not wish to develop any length sidebar about the architecture of the GRANITENET design, or the design philosophy of the same. It's basically a concept for a scalable DevOps network, and a small office/home office (SOHO) network, such that may be utilized not only from GRAITELAN, but moreover that may be utilized from a mobile appliance not immediately connected to but configured for connection to GRANITESDN. In its architecture, GRANITENET would apply a distinct number of common UNIX networking services, such as LDAP, NFS, NIS, Kerberos, and -- furthermore -- RADIUS. Though it may seem relatively easy to write about, as such, but -- in order to develop a manageable framework of so many network services, as such, and for it to be relevant in regards to applications on contemporary operating system architectures -- it may not ultimately be as easy to "Glue together," in application of so many software components. At least, it may be easy to "Put together" the concept of GRANITENET's design -- initially, as it representing a manner of a paper machine, as to apply an older phrase to the matter -- as it entailing a design of an effectively multi-homed application of the FreeBSD operating system.
In regards to the manageability of the design and applications of GRANITENET, of course there must be a manner of a design incentive thought to exist. The author might not believe that every reader would share the author's sense of appreciation about the logical design of each of Common Lisp the Language, 2nd Edition, and CORBA systems, furthermore the Object Management Group's concepts of Object Management Architecture and Model Driven Architecture -- moreover, the portability of systems developed onto CORBA and, separately, the portability of applications developed onto the Common Language Infrastruture (CLI), the latter as popularized of the Microsoft Dot-NET and the Xamarin and Mono platforms, furthermore as standardized onto ECMA-335.
Insofar as it representing a concept of a paper machine, the author has certainly expended some paper and graphite, in putting together a number of offline notes about the design of GRANITENET, moreover the design of a system the author denotes as FELDSPAR. FELDSPAR would represent an application of Common Lisp, CORBA, and the Common Lisp Interface Manager, as to create a bundled application development kit of free/open source software for applications of the same software and systems components. In that regards, perhaps it might seem like overmuch of an aspiring goal -- as to apply GRANITENET in developing the FELDSPAR framework, while GRANITENET is not even completely constructed, in itself, as yet. However, in retaining a sense of focus about the logical qualities of the design of each of GRANITENET and the FELDSPAR framework, it therefore remains a manageable set of concepts, at least to the author's own sense of consideration.
In beginning to describe these discrete concepts to the Internet audience, it must naturally entail a development of a literal body of documentation. Thus -- in focusing about the Darwin Information Typing Architecture (DITA) -- there is a sense of a topic repository model developed in the FELDSPAR systems design, insofar as of the present paper machine edition of the FELDSPAR systems design. The topic repository model -- in some regards, semantically -- it might resemble something of a concept like of a Wiki. Though a FELDSPAR topic repository would be published to the Web, but -- in it utilizing DITA,l in its content source model -- it would not be immediately managed "on the web". The FELDSPAR Topic Repository model would allow for managing the body of content of a topic repository, as in application of so many DITA editing tools, multimedia content development tools, and changeset management tool such as Git -- without HTTP interverning between the editor and the filesystem. As such, perhaps it may not seem to be an immediately enterprise friendly framework, but perhaps it may be scalable outwards from its initial SOHO friendly design.
In beginning to document this design, in a digital format of text, the author of this article wishes to make reference -- immediately -- reference to MARTE, specifically MARTE 1.1, furthermore to make reference to the DOAP RDF schema. Surely, it may be possible to develop a great amount of semantic sugar, in application of such normative specifications. Presently, the author wishes to recommend a concept of software platform, in an abstract sense, as may be extended to subsume concepts both of operating system platform and of toolchain architecture, furthermore as to provide a sense of structure about application components commonly referred to as libraries -- then to include the DOAP RDF schema, as to develop a documentation framework with which software developers may be able to make consistent, ostensibly convenient reference to all points of upstream software distribution, for any single software component.
Towards developing an initial usage case to this sense of structure in software and systems: The author of this article has begun to write a small series of notes, in the author's own Evernote notebook, as to begin to develop some normative documentation towards an application of the Enlightenment Foundation Libraries (EFL) and the EFL WebKit integration, namely towards developing an EFL port for the Common Lisp Interface Manager (CLIM) as well as extensions for CLIM, in regards to web appliations, such that would be developed as for application at least onto FreeBSD, Linux Desktop, Android Mobile, and Microsoft Windows Desktop operating system platforms. Perhaps it aspires as towards a comprehensive design, to be thorough in regards to development and support of operating system applications.
Though the author is furthermore interested about some concepts of microcontroller design, reprogrammable computing, and the history of the infamous Lisp Machine, but perhaps it may turn out to be a manner of a fortuitous effort, to begin with regards to applications of existing microprocessor achitectures and existing operating systems, specifically beginning at the manner of a colloquial UNIX-like framework developed of the FreeBSD Project -- furthermore, as FreeBSD being extended in a small number of by-in-large domain-special FreeBSD distributions.
So, that would be towards an unabridged introduction.
In focusing immediately towards applications of the EFL toolkit, there is immediately a concern that occurs as with regards to illustrating the toolkit's software components and software component depencencies, as towards any single distribution of the EFL toolkit -- in a sense, as towards any single distribution of a bundled set of EFL toolkit components, whether immediately with or without the EFL WebKit integration, and finally in a distribution to any single operating system platform, in application of any single toolchain architecture. This would be essentially orthogonal to -- but, in a sense, essential to -- the development of a CLIM port for EFL.
The author proposes to develop a model for each of the following concepts, in extending the MARTE 1.1 Profile for the UML metamodel:
- Concrete Computer Machine Architecture -- immediately, perhaps extending of the Detailed Resource Model defined in MARTE 1.1
- e.g. as in reference to:
- The FreeBSD sysctl property, `hw.model`
- Compiler optimizations as may be specified in FreeBSD /etc/make.conf and/or FreeBSD /etc/src.conf
- Machine architectures in Debian GNU/Linux
- Machine architectures in the GNU Compiler Collection
- Abstract Software Platform -- likewise, perhaps extending of the Detailed Resource Model defined in MARTE 1.1
- Concrete Operating System Platform
- Concrette Toolchain arhitecture
- e.g. MINGW
- Subsumes: MINGW x86-64
- Abstract Software Application and correspondingly, Abstract Software Distribution, in a noun sense of the latter term
- Software Distribution/Application model on a FreeBSD operating system
- Software Distribution/Application on a Linux operating system
- Software Distribution/Application on a Debian or Ubuntu GNU/Linux operating system
- Software Distribution/Application on an Android Operating System
- Software Distribution/Application on a Microsoft Windows operating system
That being so, then how may the author propose to publish a UML profile model, in any vendor-compatible regards? The author proposes to apply Modelio, and to publish the UML profile models finally as serialized XMI. The author furthermore proposes to apply the respective UML profile models, in development of a manner of a component metadata database, there integrating the DOAP RDF schema and some manner of a web publishing model for presenting the metadata database, in any managed manner, online. The DOAP RDF integration, in itself, may entail a development of an extensional RDF schema, moreover an application of some existing tools for RDF graph modeling in Common Lisp.
Of course, there is a sort of a boostrapping dilemma, in such design. The author proposes to address the bootstrapping dilemma, in -- albeit, perhaps in something of a expressly nolinear sense -- but in an overall iterative sense, however. In such a sense, the author does not propose to specify that the design of the RDF application would wait on the design of the project-oriented management information system (Project MIS). The RDF application must wait, however, for the design of the final component metadata schema.
Towards such an application of RDF, the author wishes to comment towards a sense of applying Common Lisp as a data system feature, within a data programming system, there closely and comprehensively integratred with the underlying operating system. The author proposes to limit this specific design to the FreeBSD operating system, moreover to focus about a small number of individual, concrete components such as already developed as and for individual Common Lisp implementations. The goal of this aspect of the design, to the author's opinion, the goal is to support software systems development with software systems development and documentation. In such a regards, perhaps it might seem like a manner of a DevOps concept, however developed of a popularly unconventional framework
The RDF application, specifically, it may be developed as to extend of an XML Schema Datatypes implementation. As in a manner across the XML Schema Datatypes Implementation, it may be integrated onto a data persistence model for RDF, there to apply a HypersonicSQL service as a data storage service.
If there may be a rhetorical question, such as, "Where to begin, next?" the author prpoposes to continue with the development of the UML profile models, as denoted herein.
Saturday, September 19, 2015
Considering Bibliography and Filesystems
While Git clones EFL WebKit onto my GraniteLAN, there is a short while as to develop a thought towards a concept of bibliography: That in the known universe, there exists a book about SysML, and there exists an article towards a mathematical perspective of UML. A mathematical perspective of such a topic, perhaps, may be presented as towards something of a literary discussion about a sense of a philosophical and practical relevance of the Metaobject Famework (MOF), and the corresponding metamodels of UML and SysML as dialects of systems modeling, such as may be applied moreover towards a systems design.
I'll try to develop a logical model of a concept, presently, as towards developing a logical model of software components, abstractly, and of components bundled materially in the EFL WebKit changeset repository – a changeset repository stored and accessible with Git.
Preliminary to developing a UML modeling profile for software source code components, I would firstly like to share a set of notes that I've collected as with regards to bibliography. I'm afraid that it cannot be a trivial effort, however, as to begin a thesis about bibliography, forthwith. Presently, there is a matter of the bibliography for any thesis about bibliography.
The article – as towards a mathematical perspective of UML, in the known universe – the article, in a PDF edition of its presently unnamed publication, it is presently located in a private Git repository on my notebook laptop. I had moved the file to there – effectively, relocating the file from its initial on-LAN location, then stored on the internal filesystem of my own academic dashboard of a tablet computer, moving it then to the FreeBSD UFS filesystem on my Notebook – that procedure, as when I was trying out git-annex as a file synchronization tool. Not to short git-annex of attention, I don't believe a Git repository may be an ideal resource for a mobile filesystem. The 'dot-git' metadata directory of a source tree managed with Git, that may seem to present something of a waste of limited mobile storage space, as it is for storage of data that may not be immediately accesed by a Git user, outside of each individual changeset registrstion.
Since the time of making an initial study about git-annex, approximately one week ago, I've read a small amount of literature about SparkleShare. I wonder, now, as SparkleShare implements a manner of a virtual filesystem, may it be approached as to develop a manner of a CORBA filesystem service framework? SpakleShare is available as free/open source software, juxtaposed to Dropbox, Box.net, or similar closed source, web-oriented Cloud Storage services.
This morning, while developing an outline about networked filesystems available on FreeBSD, I'd read some little about GlusterFS, and some little more about network services available to a model of classical UNIX networking. Though, personally, I am not immediately decided about applying either GlusterFS or NFS on my GraniteLAN, this afternoon, however I'm considering both of those networked filesystem models – as towards a manner of a DevOps regards – for application in integration testing and continuous availability i.e software distribution, but on a local area network (LAN) only, of a custom compiled FreeBSD 10.2 kernel and FreeBSD 10.2 base system on GraniteLAN.
So. There's to a service oriented view of filesystem services – as in a manner, a view corresponding with a generic concept of "File", howwver applied as onto a concept of a "Private network." There are the GlusferFS and NFS network filesystems, and alternately, SparkleShare as a centralized virtual filesystem.
Three types of filesystem – it might be enough as with which one may develop a manner of an outline of a thesis article. There might be a concept of mathematical topology, correspondingly developed – perhaps, towards an abstraction about data and computation, and a conept about illustrating a graph of data.
[Draft nr. 5]
Some notes about Bibliography, focusing on bibliographical tools
I'll try to develop a logical model of a concept, presently, as towards developing a logical model of software components, abstractly, and of components bundled materially in the EFL WebKit changeset repository – a changeset repository stored and accessible with Git.
Preliminary to developing a UML modeling profile for software source code components, I would firstly like to share a set of notes that I've collected as with regards to bibliography. I'm afraid that it cannot be a trivial effort, however, as to begin a thesis about bibliography, forthwith. Presently, there is a matter of the bibliography for any thesis about bibliography.
The article – as towards a mathematical perspective of UML, in the known universe – the article, in a PDF edition of its presently unnamed publication, it is presently located in a private Git repository on my notebook laptop. I had moved the file to there – effectively, relocating the file from its initial on-LAN location, then stored on the internal filesystem of my own academic dashboard of a tablet computer, moving it then to the FreeBSD UFS filesystem on my Notebook – that procedure, as when I was trying out git-annex as a file synchronization tool. Not to short git-annex of attention, I don't believe a Git repository may be an ideal resource for a mobile filesystem. The 'dot-git' metadata directory of a source tree managed with Git, that may seem to present something of a waste of limited mobile storage space, as it is for storage of data that may not be immediately accesed by a Git user, outside of each individual changeset registrstion.
Since the time of making an initial study about git-annex, approximately one week ago, I've read a small amount of literature about SparkleShare. I wonder, now, as SparkleShare implements a manner of a virtual filesystem, may it be approached as to develop a manner of a CORBA filesystem service framework? SpakleShare is available as free/open source software, juxtaposed to Dropbox, Box.net, or similar closed source, web-oriented Cloud Storage services.
This morning, while developing an outline about networked filesystems available on FreeBSD, I'd read some little about GlusterFS, and some little more about network services available to a model of classical UNIX networking. Though, personally, I am not immediately decided about applying either GlusterFS or NFS on my GraniteLAN, this afternoon, however I'm considering both of those networked filesystem models – as towards a manner of a DevOps regards – for application in integration testing and continuous availability i.e software distribution, but on a local area network (LAN) only, of a custom compiled FreeBSD 10.2 kernel and FreeBSD 10.2 base system on GraniteLAN.
So. There's to a service oriented view of filesystem services – as in a manner, a view corresponding with a generic concept of "File", howwver applied as onto a concept of a "Private network." There are the GlusferFS and NFS network filesystems, and alternately, SparkleShare as a centralized virtual filesystem.
Three types of filesystem – it might be enough as with which one may develop a manner of an outline of a thesis article. There might be a concept of mathematical topology, correspondingly developed – perhaps, towards an abstraction about data and computation, and a conept about illustrating a graph of data.
[Draft nr. 5]
Some notes about Bibliography, focusing on bibliographical tools
- Mendeley Desktop (Microsoft Windows, version 1.14)
- When importing a BibTeX file, in regards to attachments (files), Mendeley Desktop does not parse relative filenames as expected.
- If an attachment is referenced in the BibTeX file with a relative pathname -- such as when the BibTeX file is generated with Eratosthenes, then as when attaching a document to a BibTeX entry -- the attachment will not be added to the user's Mendeley files, as expected. Mendeley, instead, will report as if the file does not exist.
- A workaround exists for this unexpected software behavior: To remove the "Not found" attachment's entry, in each Mendeley bibliography entry, then to attach each file manually
- When saving the user's bibliographies in BibTeX format:
- Effectively, the files are saved in read-only format. Changes to the files will be overwritten by Mendeley Desktop
- For a set of bibliography files saved by Mendeley Desktop into a directory 'bibsync', the BibTeX *.bib files saved within 'bibsync' will change in unexpected ways, over time
- Mendeley Desktop does not always save the set of BibTeX entries in the same order of entry, within each file, at each time of synchronization
- If the 'bibsync' directory is managed within an SCCM repository, this will result in file changes, though the BibTeX entries themselves may not have changed, in any single one.
- If the user has configured Mendeley Desktop to organize the user's bibliography attachments, as to save the files within a directory 'bibsync/files', then in each entry in 'bibsync/*.bib', every attached file within 'bibsync/files'will be referenced with an absolute pathname as would be generated on the filesystem or origin.
- This may seem to present a minor challenge, as in regards to utilizing the generated BibTeX files with services not including Mendeley Desktop -- such as when the bibliography files are synchronized into an SCCM repository, or if the bibliography files would be posted to any single web service
- Eratosthenes (Android)
- Eratosthenes Wiki [Bitbucket]
- Eratosthenes Issue Tracker [Bitbucket]
- Not open source
- Not uncommon, on Andoid
- Supports bibliography formats generated with JabRef, BibDesk, and Eratosthenes
- Great UI
- May be difficult to synchronize between tablet and desktop
- Tried: Synchronizing bibliography metadata and files, using git-annex
- Though git-annex has its applications, but in considering the limited filesystem storage capacity available of thin client mobile appliances, the dot-git repository of a git-annex repository consumes storage space to no great effect. This is more pronounced, perhaps, for storage of binary formatted files, such as of documents in the Adobe PDF format
- Unavailable, presently: GlusterFS on Android
- See also: CynaogenMod
- Available, but with reservations: Dropbox
- A user's Dropbox storage is manageable via the central DropBox web site, or on filesystems with the user's central/cloud DropBox storage completely synchronized to the filesystem
- Synchronization not obviously available for Android
- Synchronization not manageable by the LAN administrator
- Unavailable, presently: Sparkleshare on Android
On Cloning EFL WebKit
EFL WebKit is certainly not a small toolkit to Git clone, in its full Git changeset repository.
At 37% of changeset data transmitted, the repository data amounts to so much of 3.41 GB, in a quantitative measure.
I'm certain there's something that can be applied to simplify its source tree, but it might need a sketch or two in UML format -- moreover, a UML profile for illustrating inter-component dependencies onto a SysML block diagram.
Presently, it has thoroughly bogged down my network uplink, thus making this web log entry a little more difficult to edit. So, there won't be much to show here, in this article's draft nr. 1.
Update: On review of the ewebkit/webkit repository at GitHub, juxtaposed to the WebKit SVN repository (e.g. Source/WebKit2/efl/) it seems that there's a certain lack of synchronization with the repository a GitHub. Furtthermore, the SVN repository would be the more up-to-date source code repository, assuming a sense of trust about the "Last update" timestamps on the files.
It may seem peculiar that the EFL WebKit developers would not keep the repository up-to-date at GitHub. Regardless, the baseline WebKit SVN repository may be preferred, or the baseline WebKit Git repository -- at which point, the WebKit 'checkout' documentation may be relevant. As a further alternative, a Git repository may be developed as manner of a changeset proxy onto the SVN repository, using 'git-svn'.
At 37% of changeset data transmitted, the repository data amounts to so much of 3.41 GB, in a quantitative measure.
 |
| Cloning the EFL WebKit source repository - 3.4 GB at 37% |
Presently, it has thoroughly bogged down my network uplink, thus making this web log entry a little more difficult to edit. So, there won't be much to show here, in this article's draft nr. 1.
Update: On review of the ewebkit/webkit repository at GitHub, juxtaposed to the WebKit SVN repository (e.g. Source/WebKit2/efl/) it seems that there's a certain lack of synchronization with the repository a GitHub. Furtthermore, the SVN repository would be the more up-to-date source code repository, assuming a sense of trust about the "Last update" timestamps on the files.
It may seem peculiar that the EFL WebKit developers would not keep the repository up-to-date at GitHub. Regardless, the baseline WebKit SVN repository may be preferred, or the baseline WebKit Git repository -- at which point, the WebKit 'checkout' documentation may be relevant. As a further alternative, a Git repository may be developed as manner of a changeset proxy onto the SVN repository, using 'git-svn'.
Friday, September 18, 2015
FreeBSD Base System Upgrade - How To - and a question, DITA and FreeBSD ?
The FreeBSD Handbook is a really helpful resource. It contains a lot of really well organized information -- certainly, information that may be useful for FreeBSD system developers and system maintainers -- clearly, in a format of documentation written by authentic experts about the FreeBSD Kernel and broader FreeBSD Base System -- no imitations about UNIX expertise, in the FreeBSD handbook.
Towards rebuilding a FreeBSD operating system on a local area network -- such as for compiler optimizations, viz a viz /etc/make.conf, and for upgrading the operating system to a newer version, as for instance in upgrading from FreeBSD 10.1-RELEASE to 10.2-RELEASE -- there are a few references that would be useful, in the FreeBSD handbook.
As to augment the existing documentation, I'd like to add a few small annotations -- to highlight a small number of concepts addressed in the conceptual topic repository of the FreeBSD handbook, and in an annotations sense, to add some augmentative information -- as follows
Orthogonally: Though I cannot believe I'll ever be able to sell the FreeBSD project about using DITA, but it's "A thought," though.
The FreeBSD Handbook, by in large, already serves as a topically focused -- and very usefully detailed -- reference manual about the FreeBSD operating system. As a knowledge resource, the FreeBSD handbook very much "Holds its own," as furthermore a manner of a reference manual.
The Handbook is published in a format like of a set of thesis documents about individual components of FreeBSD. In a DITA format, each article-like section in the FreeBSD handbook could be rendered as a DITA Topic. That, in itself, might not exactly serve towards further development of the FreeBSD handbook. However, perhaps it might serve as an aid to users and developers, as towards a manner of extensibility about the FreeBSD handbook -- at least, then, to authors whom would be both familiar with the DITA format, and familiar with the "Internals" of FreeBSD.
The overlap, in that proverbial set -- perhaps it might not seem to be any very broad kind of an overlap, at least outside of an ideal estimate, as of a hypothetical universe in which DITA is something anyone would voluntarily learn, beyond the small community of technical documentation geeks, and those of us somewhere in orbital space to the same.
The FreeBSD Handbook, in its original format, is developed onto the DocBook toolchain -- a long tried and trusted toolchain for technical documents. The DocBook toolchain is comprised, essentially, of the DocBook Schema -- in any single format, such as of a Document Type Definition (DTD) or a RELAX-NG schema -- and the DocBook modular stylesheets. The DocBook stylesheets, in turn, are available in both of DSSSL format -- for application onto SGML DocBook documents -- and in XSL format, for application on to XML DocBook documents.
Though there is a mapping -- as commonly available of the DITA Open Toolkit (DITA OT) -- for transforming DITA documents onto DocBook, but presently, there might not be an inverse mapping for DocBook onto DITA. It might be a fairly trivial matter, to semantically invert any much of the DITA-to-DocBook transformation module, from DITA OT, in defining a DocBook-to-DITA transformation. However, the question of whether and how that may be pragmatically worth it might remain to be addressed.
There's a topic that the author of this article is not willing to venture to address, in any offhand regards, at the FreeBSD forums: "Anyone else wants to use DITA to document FreeBSD?" Though the author of this article might fancy himself to be sufficiently familiar with SGML, XML, DocBook, and DITA formats, sufficient to be able to manage such a project by himself, but the social incentive of such a matter might seem to be fairly much "In doubt," as it may seem to be fairly much "Non-trivial," as a prospective effort, in numerous independent points of view.
In a manner of a rhetorical question: How would a "Proof of concept" be regarded, for a DITA transform of the DocBook format of the original FreeBSD Handbook?
It might seem to need some kind of a "Run-up time," such a project, if it could ever be a project that might be any furthermore adopted by the FreeBSD developer community. Though the author of this article, in particular, fancies DITA to be as simple as push-button editing -- except for all of the visible markup of it -- but not everyone might quite agree.
In a further juxtaposition of DITA to DocBook: In DITA, there are also the matters of content inclusion and seperately, of linking, each of which such concepts does not occur exactly in such a manner, in DocBook, not in exactly as it occurs in the syntax and semantics of DITA. Furthermore, in DITA, there is the topic 'class' attribute -- probably a very much interesting features, to those of us whom may be, furthermore, object oriented programming (OOP) geeks.
Ed. Note: ...and then there's something about "How to avoid arbitrary topics," as towards, orthogonally, towards a manner of a Wiki model for DITA or -- contrarily -- towards a centrally edited topic repository model for DITA
It would definitely be a project applying the Java(R) programming language, to document FreeBSD with DITA. DITA OT uses ASF* Ant, for instance, in DITA OT's own build automation framework. ASF Ant is a tool developed in Java(R). Whether or not all persons editing DITA documents may prefer to use editor platforms also developed in Java(r) -- such as the commercially licensed Oxygen XML product -- and the author of this article would rather prefer to use Emacs and PSGML, candidly -- but for so much as building the finally formatted documentation, it would definitely need to use Java(R), such a project. It may be at least a convenient thing, then, that FreeBSD is really good at running Java(R) applications.**
Is that enough of an incentive, in itself? Most probably, it is not. DITA is not the hottest kewlness online, and -- candidly -- all of this amounts to anything very much unlike a hot rod sports car view of FreeBSD. It doesn't exactly become easily to a metaphor about Minetest, either -- not to game around about operating systems design. This article describes some concepts of documentation, as in or towards a manner of a developer's view.
* ASF: The Apache Software Foundation.
** It could seem almost like a kind of Digital Magic -- the efficiency at which FreeBSD runs Java(R) applications, even on the desktop. Perhaps it's rather a matter of the operating system design in FreeBSD.
Towards rebuilding a FreeBSD operating system on a local area network -- such as for compiler optimizations, viz a viz /etc/make.conf, and for upgrading the operating system to a newer version, as for instance in upgrading from FreeBSD 10.1-RELEASE to 10.2-RELEASE -- there are a few references that would be useful, in the FreeBSD handbook.
As to augment the existing documentation, I'd like to add a few small annotations -- to highlight a small number of concepts addressed in the conceptual topic repository of the FreeBSD handbook, and in an annotations sense, to add some augmentative information -- as follows
- Building and Installing a Custom Kernel
- Concept: Kernel configuration
- See also
- Shell command: `sysctl -n kern.conftxt`
- Manual page config(5)
- Ed. Notes - Misc
- TBD: Cross-compiling the FreeBSD kernel (see documentation)
- TBD: HOWTO FreeBSD Kernel Configuration GUI
- See also: GNU/Linux kernel - `make menuconfig`, `make xconfig`, ...
- TO DO: Produce an index of all kernel configuration parameters noted in the FreeBSD handbook
- Rebuilding World
- Concept: FreeBSD Base System
- Ed. Notes - Misc.
- See also: Previous link, as with regards to FreeBSD kernel configuration
- TBD: Configurable parameters of the FreeBSD base system build
- TBD: FreeBSD Base System Configuration GUI
- See also: Poudriere; Augeas
- Note: Licensing terms of FreeBSD base system components
- Note: Concepts, Licensing and Software Distribution
- TBD: Cross-compiling the FreeBSD base system
- TBD: Issue tracker integration
- See also: Debian `reportbug`
- Tracking for Multiple Machines
- Concept: Build set
- Common features:
- make.conf
- src.conf
- networked filesystem configuration (e.g. NFS)
- Recommended feature:
- Test machine
- Application: Integration testing for compiled base system and kernel
- Optional feature:
- Change management shared files
- NIS/YP - see following notets
- Concept: Toolchains
- Ed. Notes - FreeBSD Toolchain
- See also: Following notes about make.conf, src.conf
- Concept: Networked filesystems
- Ed. Notes - Networked Filesystems
- Juxtapose to: Block-level filesystems; Virtual filesystems
- See also: Network File System Service
- Bill Swiggle "Network File System (NFS)". ed. FreeBSD Handbook
- mount_nfs(8). Manual page
- See also: Network Information Service (a.k.a YP)
- "Network Information System (NIS)". FreeBSD Handbook
- Hal Stern, Ricardo Labiaga, Mike Eisler. Managing NFS and NIS, 2nd Edition. O'Reilly (2001)
- See also: LDAP Directory Service
- Dag-Erling Smørgrav. Pluggable Authentication Modules
- Toby Burress. LDAP Authentication
- See also: Certificate Authority Service
- Setting-up a Simple CA Using the strongSwan PKI Tool. strongSwan documentation
- strongSwan 5: How to create your own private VPN. Zeitgeist. web log
- See also: Wireless Networking Services and WPA2-Enterprise Wireless Authentication Services
- "Wireless Networking". FreeBSD Handbook
- HOWTO: WPA2-Enterprise with FreeRadius. FreeBSD Forums
- "FAQ." FreeRADIUS Guide
- See also: "Dynamic Host Configuration Protocol (DHCP)". FreeBSD Handbook
- Advice: For each network client configured to obtain its IP address via DHCP, the DHCP server may be configured so as to reserve a specific IP address for each network client, as per the MAC address published of the connecting client's network interface. Each such reserved IP address may then be applied in the NFS configuration, on each NFS server and/or the NFS client.
- Alternately, if a network is configured with static IP addressing, each IP address, network mask, and router address may be entered manually at each respective client machine.
- See also: Histories of UNIX(R)
- See also: Andrew Filesytem (AFS)
- See also: Zettabyte Filesystem (ZFS)
- See also: Filesystem in Userspace
- FUSE: FIlesystem in Userspace. web site
- FUSE Module. FreeBSD Project Wiki
- See also: GlusterFS
- GlusterFS. FreeBSD Project Wiki
- Coyle, James. ZFS and GlusterFS network storage
- Gluster. web site
- Installing GlusterFS - a Quick Start Guide
- Ed. Notes (add'l)
- TBD: Handbook-wise documentation about files /etc/make.conf and /etc/src.conf
- Concept: Toolchains
- Concept: Machine-specific optimizations
- e.g utilizing SSE machine instructions on later Intel architectures
- See also:
- LLVM
- Manual pages
- make.conf(5)
- Context: all system builds, including ports, kernel, and base system
- src.conf(5)
- Context: kernel and base system (?)
- /usr/share/examples/etc/make.conf
- /usr/src/share/mk/bsd.cpu.mk
Orthogonally: Though I cannot believe I'll ever be able to sell the FreeBSD project about using DITA, but it's "A thought," though.
The FreeBSD Handbook, by in large, already serves as a topically focused -- and very usefully detailed -- reference manual about the FreeBSD operating system. As a knowledge resource, the FreeBSD handbook very much "Holds its own," as furthermore a manner of a reference manual.
The Handbook is published in a format like of a set of thesis documents about individual components of FreeBSD. In a DITA format, each article-like section in the FreeBSD handbook could be rendered as a DITA Topic. That, in itself, might not exactly serve towards further development of the FreeBSD handbook. However, perhaps it might serve as an aid to users and developers, as towards a manner of extensibility about the FreeBSD handbook -- at least, then, to authors whom would be both familiar with the DITA format, and familiar with the "Internals" of FreeBSD.
The overlap, in that proverbial set -- perhaps it might not seem to be any very broad kind of an overlap, at least outside of an ideal estimate, as of a hypothetical universe in which DITA is something anyone would voluntarily learn, beyond the small community of technical documentation geeks, and those of us somewhere in orbital space to the same.
The FreeBSD Handbook, in its original format, is developed onto the DocBook toolchain -- a long tried and trusted toolchain for technical documents. The DocBook toolchain is comprised, essentially, of the DocBook Schema -- in any single format, such as of a Document Type Definition (DTD) or a RELAX-NG schema -- and the DocBook modular stylesheets. The DocBook stylesheets, in turn, are available in both of DSSSL format -- for application onto SGML DocBook documents -- and in XSL format, for application on to XML DocBook documents.
Though there is a mapping -- as commonly available of the DITA Open Toolkit (DITA OT) -- for transforming DITA documents onto DocBook, but presently, there might not be an inverse mapping for DocBook onto DITA. It might be a fairly trivial matter, to semantically invert any much of the DITA-to-DocBook transformation module, from DITA OT, in defining a DocBook-to-DITA transformation. However, the question of whether and how that may be pragmatically worth it might remain to be addressed.
There's a topic that the author of this article is not willing to venture to address, in any offhand regards, at the FreeBSD forums: "Anyone else wants to use DITA to document FreeBSD?" Though the author of this article might fancy himself to be sufficiently familiar with SGML, XML, DocBook, and DITA formats, sufficient to be able to manage such a project by himself, but the social incentive of such a matter might seem to be fairly much "In doubt," as it may seem to be fairly much "Non-trivial," as a prospective effort, in numerous independent points of view.
In a manner of a rhetorical question: How would a "Proof of concept" be regarded, for a DITA transform of the DocBook format of the original FreeBSD Handbook?
It might seem to need some kind of a "Run-up time," such a project, if it could ever be a project that might be any furthermore adopted by the FreeBSD developer community. Though the author of this article, in particular, fancies DITA to be as simple as push-button editing -- except for all of the visible markup of it -- but not everyone might quite agree.
In a further juxtaposition of DITA to DocBook: In DITA, there are also the matters of content inclusion and seperately, of linking, each of which such concepts does not occur exactly in such a manner, in DocBook, not in exactly as it occurs in the syntax and semantics of DITA. Furthermore, in DITA, there is the topic 'class' attribute -- probably a very much interesting features, to those of us whom may be, furthermore, object oriented programming (OOP) geeks.
Ed. Note: ...and then there's something about "How to avoid arbitrary topics," as towards, orthogonally, towards a manner of a Wiki model for DITA or -- contrarily -- towards a centrally edited topic repository model for DITA
It would definitely be a project applying the Java(R) programming language, to document FreeBSD with DITA. DITA OT uses ASF* Ant, for instance, in DITA OT's own build automation framework. ASF Ant is a tool developed in Java(R). Whether or not all persons editing DITA documents may prefer to use editor platforms also developed in Java(r) -- such as the commercially licensed Oxygen XML product -- and the author of this article would rather prefer to use Emacs and PSGML, candidly -- but for so much as building the finally formatted documentation, it would definitely need to use Java(R), such a project. It may be at least a convenient thing, then, that FreeBSD is really good at running Java(R) applications.**
Is that enough of an incentive, in itself? Most probably, it is not. DITA is not the hottest kewlness online, and -- candidly -- all of this amounts to anything very much unlike a hot rod sports car view of FreeBSD. It doesn't exactly become easily to a metaphor about Minetest, either -- not to game around about operating systems design. This article describes some concepts of documentation, as in or towards a manner of a developer's view.
* ASF: The Apache Software Foundation.
** It could seem almost like a kind of Digital Magic -- the efficiency at which FreeBSD runs Java(R) applications, even on the desktop. Perhaps it's rather a matter of the operating system design in FreeBSD.
Thursday, September 17, 2015
On Assembling "Own Porridge"
As a status update written at an exo-Twitter[1] dimension: Aside to beginning a small adventure[2] with Minetest* as -- so to speak -- in a voxel-blocks meta-universe -- to a fun and simple study of video games, multiplayer online game environments, and such that I refer to as Maker Universe game styles -- this week, I've also begun reading about the ECMA standardization of the Microsoft dot-net platform, as codified in ECMA-4356445, ECMA TR-xyzzq, and TR-3A2 -- rather, ECMA documents: ECMA-335, TR/84, and TR/89. Ostensibly, all of those documents are as exactly as the titles would seem to indicate.
The second part of this week's adventure -- presently, in presenting it like an adventure through CLI Land -- it begins as a lark, in a sense, as with regards to the Unity framework, Xamarin's work in software and systems development, Mono, and ostensibly, Common Lisp.
Hypothetically, a complete implementation of the "Dot Net" framework can be developed in Common Lisp, if anyone would set about to develop such a work and to complete the work, as such. Materially, although such a hypothesis may be difficult to disprove -- and it may not be any easier to materially prove, as in completely and with a proof of concept in software programming -- it may seem that there are some elements with which anyone may invent a "Golden ticket for Lisp," again, commercially.
So, aside to all the facets of a plain adventure, presently the author of this article has arrived at PDF page 139 (document p. 113) of ECMA-335, in which there is a convenient list of software directives as defined in the high-level assembly language of ILAsm, in the whole C#/CLI/CLR/dot-Net porridge.
Porridge -- a metaphor of a fantastic social fairytale and the webs, furthermore a breakfast food of a starchy kind.
Before the author of this article looses one's place of study in the same porridge, some further notes:
Footnotes
[1] In the Twitter media, all status updates are encoded at 140 or fewer Unicode Characters, with a shortened encoding for URL references
[2] An adventure much in a manner as to extend of the heritage of Adventure, Colossal Caves, and Zork, without overmuch of mature themes -- aside to a shout out for the early years of Linden Labs' Second Life (SL) universe. In such a sense, it may be rather difficult for the game universe to become polluted of excessively mature themes -- as in some "Adult only" locales in Second Life. Elsewhere, in some other voxel universes online, there are themes of simple art, crafting, and -- aside to the materials of voxel universes -- coding.
Sadly, much of the art has disappeared from SL -- Virtual Tibet included. It might not seem like overmuch a quandary, however, to a mature perspective. It would be difficult for anyone to corrupt** the block-oriented maker universes -- not to challenge anyone who might even consider to. There's not likely to be so much as an illusion of incentive for anyone to corrupt -- for instance -- the non-dollar-oriented Minecraft, though one might not underestimate the depths of the imaginations of anyone whom might even consider to.
* Update: After reviewing a book about the fantastic Secondlife universe, moreover considering the unlikelihood of block-oriented video games ever becoming any more popular than already, I'll probably not be continuing with any further studies about multiplayer online game universes. It sure was neat to write about such a positive idea, for a short time, however.
** That's exactly the word I mean, there, if there may be any sense of ambiguity about that.
The second part of this week's adventure -- presently, in presenting it like an adventure through CLI Land -- it begins as a lark, in a sense, as with regards to the Unity framework, Xamarin's work in software and systems development, Mono, and ostensibly, Common Lisp.
Hypothetically, a complete implementation of the "Dot Net" framework can be developed in Common Lisp, if anyone would set about to develop such a work and to complete the work, as such. Materially, although such a hypothesis may be difficult to disprove -- and it may not be any easier to materially prove, as in completely and with a proof of concept in software programming -- it may seem that there are some elements with which anyone may invent a "Golden ticket for Lisp," again, commercially.
So, aside to all the facets of a plain adventure, presently the author of this article has arrived at PDF page 139 (document p. 113) of ECMA-335, in which there is a convenient list of software directives as defined in the high-level assembly language of ILAsm, in the whole C#/CLI/CLR/dot-Net porridge.
Porridge -- a metaphor of a fantastic social fairytale and the webs, furthermore a breakfast food of a starchy kind.
Before the author of this article looses one's place of study in the same porridge, some further notes:
- The definition of ILAsm as a high-level assembler
- ECMA-335 Common Type System
- Juxtapose[d] to: CORBA IDL bindings
- See also: ECMA-335 Generics
- See also: ECMA-335 section II.11 Semantics of Classes, as specifically for each type of effective meta-class
- Interface
- Value Type
- Special Type
- ECMA-335 Virtual Execution System
- Juxtapose[d] to: Operations of a CORBA Portable Object Adapter (POA) in application for providing any single CORBA object service
- Dot-net
- C#
- Unity Framework
- Enligthenment Foundation Libraries (EFL)
- Tizen
- ...
Footnotes
[1] In the Twitter media, all status updates are encoded at 140 or fewer Unicode Characters, with a shortened encoding for URL references
[2] An adventure much in a manner as to extend of the heritage of Adventure, Colossal Caves, and Zork, without overmuch of mature themes -- aside to a shout out for the early years of Linden Labs' Second Life (SL) universe. In such a sense, it may be rather difficult for the game universe to become polluted of excessively mature themes -- as in some "Adult only" locales in Second Life. Elsewhere, in some other voxel universes online, there are themes of simple art, crafting, and -- aside to the materials of voxel universes -- coding.
Sadly, much of the art has disappeared from SL -- Virtual Tibet included. It might not seem like overmuch a quandary, however, to a mature perspective. It would be difficult for anyone to corrupt** the block-oriented maker universes -- not to challenge anyone who might even consider to. There's not likely to be so much as an illusion of incentive for anyone to corrupt -- for instance -- the non-dollar-oriented Minecraft, though one might not underestimate the depths of the imaginations of anyone whom might even consider to.
* Update: After reviewing a book about the fantastic Secondlife universe, moreover considering the unlikelihood of block-oriented video games ever becoming any more popular than already, I'll probably not be continuing with any further studies about multiplayer online game universes. It sure was neat to write about such a positive idea, for a short time, however.
** That's exactly the word I mean, there, if there may be any sense of ambiguity about that.
Wednesday, August 5, 2015
Custom Build for SBCL 1.2 with Multithreading on FreeBSD 10
After installing SBCL 1.2.9 from the standard baseline package for FreeBSD 10.1-RELEASE, the *features* value is as follows:
In a a custom build, SBCL 1.2.14.32-ce739b6
Without
#YMMV
Ed. Note: This has since been addressed to a comment in the FreeBSD Bugzilla database, at Issue nr. 199055
(:ALIEN-CALLBACKS :ANSI-CL :ASH-RIGHT-VOPS :BSD :C-STACK-IS-CONTROL-STACK
:COMMON-LISP :COMPARE-AND-SWAP-VOPS :COMPLEX-FLOAT-VOPS :CYCLE-COUNTER :ELF
:FLOAT-EQL-VOPS :FREEBSD :GCC-TLS :GENCGC :IEEE-FLOATING-POINT
:INLINE-CONSTANTS :INTEGER-EQL-VOP :INTERLEAVED-RAW-SLOTS :LINKAGE-TABLE
:LITTLE-ENDIAN :MEMORY-BARRIER-VOPS :MULTIPLY-HIGH-VOPS :OS-PROVIDES-BLKSIZE-T
:OS-PROVIDES-DLADDR :OS-PROVIDES-DLOPEN :OS-PROVIDES-GETPROTOBY-R
:OS-PROVIDES-POLL :OS-PROVIDES-PUTWC :OS-PROVIDES-SUSECONDS-T
:PACKAGE-LOCAL-NICKNAMES :PRECISE-ARG-COUNT-ERROR :RAW-INSTANCE-INIT-VOPS
:SB-CORE-COMPRESSION :SB-DOC :SB-EVAL :SB-LDB :SB-PACKAGE-LOCKS :SB-QSHOW
:SB-SIMD-PACK :SB-SOURCE-LOCATIONS :SB-TEST :SB-UNICODE :SBCL
:STACK-ALLOCATABLE-CLOSURES :STACK-ALLOCATABLE-FIXED-OBJECTS
:STACK-ALLOCATABLE-LISTS :STACK-ALLOCATABLE-VECTORS
:STACK-GROWS-DOWNWARD-NOT-UPWARD :SYMBOL-INFO-VOPS :UNIX
:UNWIND-TO-FRAME-AND-CALL-VOP :X86-64)
In a a custom build, SBCL 1.2.14.32-ce739b6
(:ALIEN-CALLBACKS :ANSI-CL :ASH-RIGHT-VOPS :BSD :C-STACK-IS-CONTROL-STACK
:COMMON-LISP :COMPARE-AND-SWAP-VOPS :COMPLEX-FLOAT-VOPS :CYCLE-COUNTER :ELF
:FLOAT-EQL-VOPS :FP-AND-PC-STANDARD-SAVE :FREEBSD :GCC-TLS :GENCGC
:IEEE-FLOATING-POINT :INLINE-CONSTANTS :INTEGER-EQL-VOP :INTERLEAVED-RAW-SLOTS
:LINKAGE-TABLE :LITTLE-ENDIAN :MEMORY-BARRIER-VOPS :MULTIPLY-HIGH-VOPS
:OS-PROVIDES-BLKSIZE-T :OS-PROVIDES-DLADDR :OS-PROVIDES-DLOPEN
:OS-PROVIDES-GETPROTOBY-R :OS-PROVIDES-POLL :OS-PROVIDES-PUTWC
:OS-PROVIDES-SUSECONDS-T :PACKAGE-LOCAL-NICKNAMES :PRECISE-ARG-COUNT-ERROR
:RAW-INSTANCE-INIT-VOPS :SB-DOC :SB-EVAL :SB-FUTEX :SB-LDB :SB-PACKAGE-LOCKS
:SB-SAFEPOINT :SB-SIMD-PACK :SB-SOURCE-LOCATIONS :SB-TEST :SB-THREAD
:SB-THRUPTION :SB-UNICODE :SB-WTIMER :SB-XREF-FOR-INTERNALS :SBCL
:STACK-ALLOCATABLE-CLOSURES :STACK-ALLOCATABLE-FIXED-OBJECTS
:STACK-ALLOCATABLE-LISTS :STACK-ALLOCATABLE-VECTORS
:STACK-GROWS-DOWNWARD-NOT-UPWARD :SYMBOL-INFO-VOPS :UNIX
:UNWIND-TO-FRAME-AND-CALL-VOP :X86-64)
Difference:
(:SB-XREF-FOR-INTERNALS :SB-WTIMER :SB-THRUPTION :SB-THREAD :SB-SAFEPOINT
:SB-FUTEX :FP-AND-PC-STANDARD-SAVE)
In the custom build, I'd enabled the :SB-XREF-FOR-INTERNALS
feature for purpose of debugging, the :SB-WTIMER, :SB-THRUPTION, and SB-SAFEPOINT features for purpose of testing, and initially just :SB-THREAD for multithreading. The build did not complete.Without
:SB-FUTEX enabled, the build might fail/loop/freeze during the build's integrated testing. When the :SB-FUTEX feature is enabled along with :SB-THREAD, then SBCL compiles successfully on FreeBSD 10.1. #YMMV
Ed. Note: This has since been addressed to a comment in the FreeBSD Bugzilla database, at Issue nr. 199055
Subscribe to:
Posts (Atom)