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.

Go is a great language, but it does require a bit of a mental shift to get used to. Some cannot adapt; regrettably, those are often extremely vocal opponents of the language.

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.

I have a bigger problem with the fact that it exists at all. Once you've moved away from your basic system-level C language type stuff, you might as well be writing Python or Javascript. Most interpreted languages have compilers available and they are more mature.

Well, I suppose we could all be coding in Amiga E instead.

*grin*

Surprisingly, that language still exists, and has a Windows variant in PortablE.
Why it isn't ported to Linux, though, I can't say.

http://strlen.com/amiga-e/

The problem is that Python and Javascript copy memory so much that it measurably impacts software performance in high-load applications. Go is designed specifically to avoid that (this is why it exposes pointers as a distinct type), and succeeds spectacularly at avoiding copying objects. It has a reduced memory footprint versus these other languages as well, which makes Go substantially better suited for cloud deployment than Python or JS.

That sounds like an argument in favor of C, not Go.

That's interesting about JavaScript.

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).

The problem with C is that affords none of the high-level programming benefits that you get with Python or Javascript, which defeats the purpose. They want their cake and they want to eat it too.

That's kind of the point. To get the high level benefits of Python or Javascript, you use Python or Javascript. To get the close-to-the-metal performance benefits of C, you use C. I'm not sold on the value of Go, and furthermore am turned off by the proselytization of its fans (which, from my observation so far, seems to be largely composed of trash-talking C) (which is why I call them Gotards).

So, I'm not sure how to help here, then.

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.

For the record, my feelings on Go is that I can adapt to it, but it's not (anymore) my overall preferred language.

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.

This is partly why Forth appeals to me. I don't have to depend on anyone else to port it, or support it. I can do that all by myself.

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).

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...