Are there any libraries/function available in C to pretty print tabular data. I am looking for something like this : http://code.google.com/p/prettytable/
If you really want to implement something as generic-looking as the Python module seems to be, one problem is going to be data storage. It's not so easy to just throw stuff into a list in C, of course. You might want to look at glib's GVariant solution for instance. It would be pretty easy to build a table-formatter handling any reasonable type of value based on that.
Related
I've been taking a look at ReasonML (https://reasonml.github.io/) and in general, as a 'loyal' ;) functional programmer, I like the idea. However, I believe there's a missing part in my reasoning about the project.
In particular I'm a bit confused if it comes what to search for. For example, I'd like to build a simple web server. Shall I use JS-related libraries (express, ...), OCaml technologies, or maybe yet something else ?
What I'm actually missing is a step-by-step guide that presents a way to build a full basic application (in this case: let's say a simple web server with db connection).
Last thing - forgive me imprecise language. As I said: I'm pretty sure there's a gap in my reasoning about ReasonML and I'd like to fill it ;).
If you want to write portable code, you should use the OCaml technologies, so Array.length (from OCaml core) instead of Js.Array.length (Bucklescript JS wrapper).
If you do not care about native code, but just want to target JS (node/browser), then you can use the FFI and leverage your existing knowledge of JS libraries.
IMHO, this FFI is one of the nicer things of reasonML. The resulting code is small and you can inspect the .bs.js files to see what it's doing.
But as said, you lose the ability to generate native code this way.
Here is an example,
https://github.com/wires/reason-ffi
Say I don't have a range function in OCaml or ReasonML and I don't want to write one, but I know ramda has one. Just write some JS,
// range.js
exports.range = require('ramda').range
Then wrap it with types, like
[#bs.module "./range.js"] external range' : (int,int) => array(int) = "range";
let range : (int,int) => list(int) = (a,b) => range'(a,b) |> Array.to_list
I'm not saying this is the ultimate way to use this tool, but I find it a very frictionless way to transition untyped garbage JS to something reasonably maintainable.
And you can leverage your existing JS library knowledge and keep building with reasonML, instead of spending your time writing a boring range function (which is also learning... of course)
I have a legacy C API that I need to add functionality to. Specifically I need to make some of this API's calls thread-safe, because a call like this:
A_DoFoo(HandleA a)
Uses an object shared by all handles of type A.
My first thought is to add a function to the API that looks like this:
A_DoFooEx(HandleA a, HandleB b)
Is this a normal approach?
(I only used the Ex suffix because of years of exposure to the Win32 SDK. Does it make more sense to give a more descriptive name to the function?)
Adding another function under a new name is the standard (and in fact just about the only) way to deal with this problem in straight C (in C++ you could add a new overload and keep the old name). I'm not a big fan of the Ex suffix, because it doesn't tell you what the difference between the old and new APIs is. On the other hand, don't saddle people with something long and heinous like A_DoFoo_ThreadSafe, that hurts readability.
In this case, I'd try to think of a name that indicates what the requirements on HandleB are. If you tell us what this API actually does, we can maybe make more specific suggestions.
I prefer writing wrapper for thread safe code. So I can embedded any thread un safe code and make it thread safe use wrapper.
You should always use a proper naming format.
it will help you easily maintain your code and make it more readable.
I have a code library that makes heavy use of XPathNavigator to parse some specific xml document. The xml document is cross-referenced, meaning that an element can reference another which has not yet been encountered during parsing:
<ElementA ...>
<DependentElementX id="1234">
</ElementA>
<ElementX id="1234" .../>
The document doesn't really look like this, but the point is that 1) there is an xml schema that enforces the overall document structure, 2) elements inside the document can reference each other using some IDs, and 3) there is quite a few such cross references between different elements in the document.
The document is parsed in two phases. In the first pass I walk through the document
XPathDocument doc = ...;
XPathNavigator nav = doc.CreateNavigator();
nav.MoveToRoot();
nav.MoveToFirstChild()...
and occasionally 'bookmark' the current position (element) in the document using XPathNavigator.Clone() method. This gives me a lightweight instance of an XPathNavigator which I can store somewhere and use later to jump back to a particular place (element) in my document.
Once I have enough information collected in the first pass (for example, I have made sure there is indeed an ElementX with an id='1234'), I jump back to saved bookmarks (using those saved XPathNavigators) and complete the parsing.
Well, now I'm about to use this library in Silverlight 3.0 and to my horror the XPathNavigator is not in the System.Xml assembly.
Questions:
1) Am I missing something obvious (i.e. XPathNavigator does exist in some shape or form, for example in a toolkit or a freeware library)?
2) If I do have to make modifications in the code, what would be the best way to go? Ideally, I would like to make minimal changes, not to rewrite 80% of the code just to be able to use something like XLinq.
To resume, in case I have to give up XPathNavigator, all I need is a way to bookmark places in my document and to get back to them so that I can continue to iterate from where I left off.
Thanks in advance for any help/ideas.
You are not missing something obvious, there is no implementation of XPathNavigator or XPathDocument in the Silverlight versions of the libraries.
The "best way to go" is highly subjective and would really depend on how many lines of code are really depending on XPathNavigator. However I see a couple of choices.
Go ahead and re-write the code using XDocument, XElement etc from the System.Xml.Linq namepsace. This may not be as bad a choice as you might think.
Wrap Xml-to-Linq objects in your own implementation of those properties and methods of the XPathNavigator that you are actually using. It shouldn't be too hard re-create most the features of the XPathNavigator against the Xml-to-Linq objects. You can then run your existing code against your own XPathNavigator.
XPath (xdoc.XPathSelectElements) is available in Silverlight 4: here's an online test tool.
There are tons of ways:
How to deal with XML in C#
You can still use Linq to XML just minus the linq syntax and use the Linq Extension methods.
I would like to know if there are any tools that can help me model C applications i.e. Functional programming.
E.g. I'm currently building a shared library.
But to communicate my design visually, I need something like UML. I would like to do this so that the person reviewing my design need not read through 100s of pages of functions, variables and so on.
I have read about UML for C, which I'm considering.
If there is anything better out there, please let me know.
The bottom line is to visualize the design of C applications and modules without reading through 100s of pages of text, because it takes time and is difficult for the reviewers.
Any help in this area from the experts here would be much appreciated.
Thanks.
A well written text documentation brings you a far. Much further than any UML diagram could ever achieve.
You should split this in two parts:
What do you want to say?
What's the best way to saying it?
Whatever formalism you use to answer the second part, you should be sure it's not ambigous.
The good of UML is that a lot of semantic is already defined by the language so you don't have to include a definition of what those boxes, lines and arrows mean in a collaboration diagram.
But most importantly, documenting something means create a path for others to understand the subject you are documenting. A very precise description that offers no clue on how to read it is as good as none. So, use UML, Finite state machines, ER diagrams, plain English, whatever you want but be sure to include a logical path that your "readers" can follow to understand what's going on.
I had a friend that was a fan of "preciseness at all cost" and it would ask us to go through all the details before some sort of meaning would emerge.
I once ask him to do this experiment: on his next trip to an unknown city, he would have to carry the most precise map he could get. Much better, he would have to carry a 1:1 map of the city with every single detail exactly reported in scale. That way he couldn't get lost!
He declined but I would love to see him trying to use that map. Just even folding it! :)
Whatever you like. It's not a standard but many devs use it and understand it. If it does help you to communicate with other people and document your work -> its for you. If it just takes too much time and you think it's not effective, drop it. Also, don't bother with all details, as long as it resembles UML and your team can work with it, it's fine.
It's meant to help you, not waste you time.
I'm working on a basic editor application. It uses an array of varying size that I want to store to disk. This will eventually be in an AIR application, but for now it's just an AS3 project in Flex.
I want to store the array in a file. The application edits the data, so it doesn't need to be human readable. I want it to be in whatever format will be quickest to store and load back into the array when I need that data again.
Any recommendations?
Edit: It strikes me that importing/exporting in such a way that it can be immediately cast as an Array() would probably be the cheapest thing rather than some sort of iterating - if that's possible. Another obvious option is getting the data as a simple comma delineated string and using the String.split() function to get an array. Though again, the question is what would be cheapest - and I'm not quite convinced that's it.
I'll also add that it needs to be in some sort of permanent file, so a shared object - while possibly the fastest, isn't really a long term solution.
I think the fastest and easiest way is to use a shared object. It stores native objects, so there is no serialization / deserialization steps involved. Just assign the value and read it back.
Performance wise, probably the fastest route as well. If you are looking for a large dataset and are sure it's an AIR app, you can use AIR's db, but that will definitely take much more work.
First, take a look at this answer.
As for saving the contents of an Array, consider JSON using the export tools provided by Adobe.