Does Apportable (beta1) support Toll-free bridging between CF types and NS types just like Apple's implementation? If it's partially supported, how can I get the list of classes which support it?
If it's not yet, is it planned or won't be available?
Yes, we do! We support bridging on most of the classes (CFString->NSString, CFDictionary->NSDictionary, CFArray->NSArray, CFSet->NSSet, CFDate->NSDate, CFNumber->NSNumber, CFStream*->NS*Stream, etc). Some of the lesser known and used ones (mostly those deal with timezones, locales, and ICU), we may not have fully bridged just yet (eg CFTimeZoneRef, CFCalendar).
Related
The motivation for this question is a far-fetched dream I have where a lot of the excellent software available on *nix platforms could be trivially ported to Windows. Microsoft has taken a different approach to open source and openness in general recently, so I'd really like to know how viable such a thing would be if Microsoft were so inclined. Some of the more specific things I'm curious about is if it could be done without breaking backwards compatibility, and perhaps some sort of gauge on the amount of effort that would be involved. If there were any specific technical examples that would highlight particular difficulties in doing such a thing, that would also be greatly appreciated.
Windows has already been such. The NT kernel itself has supported the concept of "personalities" (API layers over the NT layer) since the beginning, to support by design at the very least the Win32 API, the POSIX API and the OS/2 API.
The POSIX layer circulated for a long time in higher end SKUs (typically server-related) with different names (Microsoft POSIX subsystem/SFU/SUA), but it never really caught on for non-specialized use, both because it was not universally available (Microsoft never really pushed it, probably for commercial reasons) and because other solutions became widespread (think Cygwin/MSYS/MinGW).
Notice that, although the "personality API" is an interesting concept (and probably one of the cleanest way to implement a multi-API OS) it suffers a bit from a "deep segregation" problem - i.e., it's true that you can access kernel objects through a POSIX interface, but all services that have been built over the Win32 interface (like Windows, GDI & co.) aren't easily available; besides, however good the interface may be, there are some details (like the format of paths) that cannot be ironed over, so a POSIX application will always look a bit out of place.
I would like to create a set of domain objects in multiple languages, so that I can target different platforms. I have been looking at external DSLs as a way to define a language for my domain, and then potentially writing adapters that generate code for the languages I'm interested in targeting. Is this the best way to solve this problem? Or is it just simpler to maintain multiple versions of the project?
I think that Apache Thrift delivers what you are asking for.
Sorry for late answer, but as you mention C# being your main language, this practically fully supported Visual Studio based technology is exactly what you are looking for.
You have to understand what you want to abstract with your DSLs, but the multiple-platform support is trivial on top of that.
Disclaimer: This is our technology, but it's publicly open and it solves exactly the problem presented in the question.
http://abstraction.codeplex.com/
Note! Mind the very "alpha" stage of the current download, I suggest you skip the zipped download and grab the latest source. I am updating better construct in relatively near future. Check out the "Context" implementation in "Production/Dev/AbstractionTemplate" solution.
It is difficult to be helpful without understanding what you are planning to use your DSL for.
Is portability your main problem here?
To succesfully target these different platforms, you will probably have to maintain plaftorm-specific layers anyway (generated or not).
If you plan to write your whole application in your DSL, then use your own compiler to transform it into runnable code for each platform, well it is most probably a bad idea, too complex and overengineered.
However, if you have a well-defined chunk of platform-independent logic, then a DSL is a good choice. Just write an interpreter for it on each target platform (provided that performance is not critical, this is also simpler and easier than generating code).
What is the best way to create multiple language versions of a domain?
This is (was?) somehow the idea of Model Driven Architecture (MDA). Quoting Model-driven architecture from Wikipedia:
The Model-Driven Architecture approach
defines system functionality using a
platform-independent model (PIM) using
an appropriate domain-specific
language (DSL).
Then, given a platform definition
model (PDM) corresponding to CORBA,
.NET, the Web, etc., the PIM is
translated to one or more
platform-specific models (PSMs) that
computers can run. This requires
mappings and transformations and
should be modeled too.
The PSM may use different Domain
Specific Languages (DSLs), or a
General Purpose Language (GPL) like
Java, C#, PHP, Python, etc. Automated tools generally
perform this translation.
Depending on the complexity of your domain and the availability of a MDA Tool, this might be an option (with a lower implementation cost).
See also
MDA: Nice idea, shame about the ...
Language Workbenches and Model Driven Architecture
UML vs. Domain-Specific Languages
DSL in the context of UML and GPL
UML or DSL: Which Bear Is Best? (be sure to read this one)
The Haskell platform includes two obsolete libraries, old-time and old-locale. For old-time, it also includes the preferred alternative (namely time), but I can't figure out what the recommended alternative for old-locale is.
Is this simply a shortcoming of the Platform as of now (version 2010.1.0.0), or something I've overlooked?
The libraries in the HP are by definition not obsolete. The particular names used though, are up to the maintainers. old-locale remains the preferred mechanism for manipulating locales.
In old-locale-1.0.0.5, the deprecation notice is removed: http://hackage.haskell.org/package/old-locale.
I'm doing a trade study for Ada development on Linux. Do you have any good compiler/OS recommendations?
So far, I've got GNAT from AdaCore running on CentOS 5.4, and I have license requests in for Rational Apex and Aonix ObjectAda.
This is a porting effort. The original codebase is Apex 3.0 on OSF1 4.0d.
Anything else I should be considering? Ideally, it would be a supported environment.
One issue you need to take into consideration is to determine to what degree your system that's being ported utilizes vendor-supplied packages to perform its function. What I've seen with older, large systems, especially Apex ones, is a propensity for the language gurus during its development time to have decided that vanilla Ada just wasn't good enough, and so tie into all these vendor-supplied packages. If that's what your system does right now, it's a strong argument for upgrading within the vendor and sticking with Apex (all other things being mostly equal).
Whenever I've done ports of such systems, if given the opportunity I've done my best to tear out all the vendor-supplied stuff--nine times out of ten replacing the vendor-specific stuff with vanilla Ada implementations worked just as well, and you no longer have to deal with the quirks of a compiler-specific package. Plus, you increase the portability and maintainability of the system, allowing it to better adapt to future changes.
There is always SPARK, but I believe its a specialized/subsetted version of the Ada language. You might want to contact SigAda or the Ada usenet group to see if there are any other ideas.
Honestly though, GNAT is a great tool set. You can use GNATBench, an Eclipse interface, or GPS, a light-weight GTK+ IDE, to interface with the GNAT tools.
Other compilers I am aware of are Green Hills AdaMULTI (for various RTOSes), and DDC-I's SCORE (also for various RTOSes)
Providers of certified compilers that support Linux (in addition to those listed in the question):
Irvine Compiler Corp.
OC Systems
RR Software
Sofcheck
I'm thinking of running an experiment to track DNS values in different ways (like how often they change and whatnot). To do this I will need to be able to make a DNS request directly to a server so that 1) I known what server it came from, 2) I can request responses from several servers and 3) I can avoid the local OS run cache.
Does anyone know of a library (c#, D, C, C++ in that order of preference) that will let me directly query a DNS server? Failing that, does anyone know of a easy to understand description of the DNS protocol that I could implement such a system from?
I have experience only with C, so here is my list:
libresolv is the old, traditional and standard way. It is available on every Unix (type man 3 resolver) and includes routines like
res_query which does more or less what you want. To query a specific name server, you typically update the global variable _res.nsaddr_list (do note that, apparently, it does not work with IPv6).
ldns is the modern and shiny solution. You have good documentation online.
a very common library, but apparently unmaintained, is adns.
For C, I'd go with http://cr.yp.to/djbdns/blurb/library.html (the low-level parts if you need total control, i.e. dns_transmit* and friends) -- for C#, maybe http://www.c-sharpcorner.com/UploadFile/ivxivx/DNSClient12122005234612PM/DNSClient.aspx (can't test that one right now, whence the "maybe"!).
The DNS specification is spread over many RFC (see a nice graph) and I would strongly advise not to implement a stub resolver from scratch. There are many opportunities to get it wrong. The DNS evolved a lot in the last years. If you are brave and crazy, here are the most important RFC:
RFC 1034, concepts
RFC 1035, format
RFC 2181, update to the specification, to fix many errors or ambiguities
RFC 2671, EDNS (mandatory today)
RFC 3597, handling the unknown resource record types
and many others...
libdns (I think it's part of bind). There's a cygwin port which may be useful for windows environments.
http://rpm2html.osmirror.nl/libdns.so.21.html