The new edition of Effective C# just arrived in the mail. The ‘effective’ series have been consistently helpful with advice beyond the basics of language syntax. As I’m currently spending significant amounts of quality time with C# for work and also for some sandbox coding at home, this is a welcome item.
Looking forward to seeing what is in this new edition and seeing what it has to say about version six of the language. I’ll try to write up comments on it when I’ve had time to read through this one.
I’ve mostly got the pieces of SQL DDL together that I need to define the tables for my sandbox project to manage file archiving. Hit this weekend after a tiring week and let myself get distracted.
I had bought an Intel NUC 6i5 to replace my ‘test target’ machine that has been randomly hanging and rebooting lately. The NUC setup and OS install went well except for the NIC driver. Wireless worked perfectly but the driver for the gigabit NIC either wouldn’t see the controller (Intel driver install packages) or saw the controller but then timed out before completing. As this was on a clean Windows install with nothing present except for the Intel driver packages I’m getting a replacement from Amazon. Should arrive today…hoping all goes smoothly as the NUCs are very nice little machines.
I let myself get distracted by some articles on Clojure and then wandered down into Scheme and Common Lisp. The various lisp dialects have always had a bit of allure to them as hugely expressive languages with very simple syntax. Nothing that I’m likely to every use professionally (though you never know) but cool toys to play with.
Clojure seems to be the closest to mainstream relevance with its JVM hosting and functional programming focus. Not sure I’ll do much more than poke at these but who knows.
Trying to get aimed back at DDL for the tables I need and then start piecing together C# code and native PInvoke stuff to get me where I need to go. Would be nice to be able to thumbnail canon raw files and PDFs (even better to get at metadata) but that will come later. Expecting that to involve serious native code execution as most of the SDKs for such things are in C or C++.
The things you run into as you’re getting serious with sandbox coding in a new language… I was setting up some pieces for the toy program I’m building (semi-smart de-dup tool with MySQL back end for archive management). After reinstalling Visual Studio 2015 to clear up an issue with creating native DLLs I’ve started framing out the pieces.
I was intending to build this as a console executable with a managed DLL for the bulk of the operational code and a native DLL for things that need interop (currently mostly VSN access for optical media and external drives). As I was laying out the projects I noticed that there was no option for static library creation in the (long) list of project types.
This surprised me a bit as I’ve found it helpful to be able to package code in static libraries while binding the resultant code as a single unit (dll or exe) for distribution. From what I’ve been able to determine with a little google searching it looks as if the managed world only supports dynamic library binding. Makes a bit of sense as the metadata issues could become complex with the same code bound into multiple assemblies.
It is funny that the common suggested solution for cases where code needed to be bound into multiple dlls or exes was to revert back to the really bad old days and just copy the source (or link to source in other projects which seems problematic in a real environment). Seems as if the managed environment assumes that non-trivial projects will consist of a relatively large number of dlls that all get copied from place to place during installs. I’ll probably poke around to see if there’s a .NET equivalent to jar/war packaging…I’d think there ought to be to simplify deployment.
Slightly frustrating moment…but working through it.
Starting to put together some sandbox code to do file de-duplication scans and some archive management. Found that the visual studio install on my main dev machine here won’t run the wizard that creates native Win32 dll projects. This works as expected on another machine so I’m running a repair to see what happens. Worst case I guess I just reinstall visual studio. Frustrating as this should be one of the simpler things that VS does.
Looking at interop (PInvoke currently) and finding that I have my very old .NET and COM Interoperability book by Nathan and a few notes in more general volumes that are much newer. Particularly disappointing as the APress book on C# 6.0 doesn’t seem to touch interop at all. Not a big deal but a bit disappointing…I’m guessing that interop has evolved somewhat since 2002…
It has been a while since my last post here. Mostly busy with work things and home stuff. Still digging into JavaScript, WebGL and a bit of node along the way.
I recently ran into a chunk of JSON data that kept being rejected by JSON.parse but worked as expected if I used eval (nasty, but this is local data so livable-ish).
I had looked at the raw data and saw nothing out of the ordinary. At first I suspected the quickly tossed together code I was working with. When I finally pasted the document into a JSON validator it immediately pointer to the ‘//’ comments that someone had inserted. Continue reading JSON doesn’t support comments…→
I just went through some contortions trying to recover one of my 128 GB flash drives. I use these with my Pixel-C android tablet to load files to the device.
It appears that android (at least stock android) only understands FAT32 and windows refuses to format a flash drive of this size with anything by exFAT or NTFS.
After cancelling a format operation on windows (and thus invalidating the format on the drive) I found that the Pixel-C would format it to FAT32 itself. Not sure why the conflict, but it was certainly frustrating.
I still can’t find an SD card reader that will work with the Pixel-C. I now have a couple with USB-C connectors and then work through an adapter to my older devices. None show up on the Pixel in any way. I’m not sure whether the device that work have extended driver support (they’re Samsung devices) or whether the Pixel-C intentionally defeats access to external media readers.
Engineering execution and creativity mixed for the best results…
Looking forward to seeing what is in this new edition and seeing what it has to say about version six of the language. I’ll try to write up comments on it when I’ve had time to read through this one.
