Which comes to the next bit...
I lay all this out as a funny kind of flat file that mimics a pivoting spreadsheet.
Pivots, though, are a funny thing. Sometimes, you can pivot in ways not originally considered. Basically, anywhere the columns have repeating data, you can pivot on that column.
I am forcing a specific set of pivots (about 6 layers deep), but I'm rethinking this. It might make better sense to leave it flat, then pivot this within the browser using d3's 'nest' to do the pivoting for me.
I can then pivot pretty much any way that makes sense for the desired view.
If I do this, though, I'll significantly increase the size of the file I am generating, since so many of these strings will get repeated, instead of conserved.
Ahhh... but if I put all of the strings in a dictionary with an incrementing number as a key, I can then store the numbers instead of the strings, and display the strings instead of the numbers. Then, I'd only have to transfer the strings once, which would save a lot of room at the cost of some additional complexity.
Almost like recreating zip compression, heh. Except I know what strings will repeat, so can store things even more efficiently. Maybe. Sorta. Kinda.
Or I'm delaying the next bit, which might seem a bit mind blowing.
Ultimately, I am building what we're calling a 'report'. This 'report', though, holds a portion of the data we've gathered, and is supposed to let you play around with this data to learn what you need to learn from it.
It's the vague notion of 'what you need to learn' that makes this task interesting and difficult.
I need to provide a way to graph the raw data in several different directions, based on whatever the user needs to see to figure out what they need to figure out. And I need to provide an interface that feels intuitive, yet winds up presenting just the kind of graph they seek. This, out of about six layers of data.
And, weirdly, I feel like I might have a plan for pulling this off, but, it also feels like I'm staring at Mt. Everest.
I've never really looked Go, since it hasn't really come up as
anything needful to getting anything done where I work... despite
Go combines the flexibility of C with the power of C.
From what I can tell, Gotards are more interested in trashing C than they are in writing in Go.
We adopted a little piece of open-source in Go that needed a few lines of patching. Doesn't look like a horribly bad language, and the standard library has some nice features. I do wish it had exception handling, but that's no big deal.
That said, Go has some long-standing issues which, while *I* can adjust to accomodate them, I recognize may be issues in a team-oriented setting. E.g., it has a really sub-optimal dependency management approach baked into the "opinions" behind the language philosophy. It's better than C/C++, but it's all you can say. Compared to even Node.js, it's actually really immature.
The lack of exception handling is OK with me, but I recognize others may hate it with a passion. It has *no* metaprogramming abilities to speak of (short of external tools that run pre-compilation). This implies no macros, and certainly no parametric polymorphism/templates.
Well, I suppose we could all be coding in Amiga E instead.
Surprisingly, that language still exists, and has a Windows variant in PortablE.
Why it isn't ported to Linux, though, I can't say.
I've recently built a kind of report where I store a fair amount of database information in a hash, then screw around with this data in a variety of ways within the browser.
I never noticed a problem with memory doing this. But then, maybe I missed something... as in, perhaps I didn't have as much database information as would cause problems, or something. I did do some things to manage this nicely, so it's possible I've mitigated some of the costs without realizing it (e.g. I use numbers into a hash instead of actual strings, since a lot of the strings are redundant in my structures).
On the one hand, I gave the appeal of Go -- it successfully blends enough high-level benefits and enough low-level benefits to be useful to web-app developers. But, per your message above, you appear to not accept this as even being possible: it's a strictly binary decision for you: either use Python or use C, but never anything in between. Then, it seems like my attempt to help explain the situation looks like prosyletizing, and especially if I were to continue to try and help you understand the value proposition of Go. I'd be labelled a gotard.
This doesn't seem like any resolution on this is possible.
It was back around Go 1.3/1.4, but since then the community has ignored issues that were of reasonable priority (e.g., packaging ecosystem) which other languages have since made significantly further progress on (pretty much everything except Go).
These days, with Python 3's support for optional/incremental typing, Python 3 is back to being my go-to language for business-like things.
GO being portable is an attraction. Python, while still in C (and slowly straying), is the foundation for my understanding of some dying hope of portability. Having a C compiler for some new CPU or architecture was a goto in my book (p.s. my book is of few pages- ha).
The fact that many companies have promoted some language that come on the scene post "written in C / compiled based on C" - and talk a good game about being cross platform (Java/JVM, C sharp / Mono, GO, Powershell) makes me suspect, but then, I don't know what I am talking about. Java seems like it might just escape the Oracle bubble with an open implementation that goes back years - Blackdown / smackdown anyone?
So, I am suspect of less than a single entity based language. A BDFL or other entity that has the interest of the continuation of a language beyond the 3 to 6 month time-frame for the shareholders for pay-off is where I am at currently. Not that Bell Labs did not want to ultimately rule the world, they just did not know what they had until it was too late - i.e. Caldera/SCO (bad example, but usage seems fair for promising a bit, but stifling things later for some perceived gain to shareholders). So, I guess I am ultimately looking for some language that someone will maintain for me for free forever. Godspeed Guido and your future job prospects (and your retirement interests)...
Apart from that, we still have the bastard child named C. All hail C.
Of course, the DISadvantage is that ... I have to do that all by myself.
Still, especially for my fun-time projects, it's a tradeoff I'm willing to make.
Increasingly, it makes sense to use whatever collection of languages you require for the job.
Even if that means having to write your own.
Although, at this point, I think it's silly to write a general-purpose language when so many of these exist. Select one that works close enough for your needs, then use it to help call anything that you need to do outside of that language (in the areas where maybe your general-purpose language doesn't quite have the expressive power).
Not that Bell Labs did not want to ultimately rule the world, they just did not know what they had until it was too late
For all practical purposes, they did rule the world. They had the only credible non-IBM computing environment in existence, and they blew it.
Been experimenting with inode monitoring in Linux.
It feels a little weird.
Firstly, I recognize that I am monitoring the file system's inodes rather than a path, so things are going to be a little strange and unexpected if I think about things from a 'this path does this' sort of perspective.
Secondly, I suppose because it's inodes, some of the operations one does with a file yeilds different kinds of results, I guess, than I might have expected through intuition. For example, I get that you can't detect the creation of a file without monitoring the folder in which you expect the file to show up. But, when you remove the file you're monitoring, it results in an attribute change, rather than the IN_DELETE or IN_DELETE_SELF flag being set for the event. That event takes place if you're monitoring a folder, and a file within the folder is removed (at least for IN_DELETE... dunno about IN_DELETE_SELF).
Interestingly, I got two IN_CREATE events for the one file I created in the folder. Not sure why.
The monitoring seems to have some weird timing-related issues, though, when you do things in a certain order. If I close a file then immediately remove it, the watch doesn't seem to notice that the file was removed (indicating instead that the file was simply modified, not that its attributes changed).
If you're directly monitoring a file, you get three notifications when someone closes it for writing, but only one when monitoring a folder and someone closes a file handle for writing within that folder. That's kind of interesting.
Please forgive me, for I have flirted with GNU coding style.
For my pennance I have executed "indent -kr -i8 -l132 *.c"
I'm feeling better now.
As long as your commits are conflict-free...