Language:

en_US

switch to room list switch to menu My folders
Go to page: First ... 31 32 33 34 [35] 36 37 38 39 ... Last
[#] Wed Jun 20 2018 12:05:57 UTC from fleeb <>

[Reply] [ReplyQuoted] [Headers] [Print]


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.

[#] Thu Jun 21 2018 14:43:40 UTC from IGnatius T Foobar

[Reply] [ReplyQuoted] [Headers] [Print]

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.

[#] Mon Jun 25 2018 13:34:18 UTC from LoanShark <>

[Reply] [ReplyQuoted] [Headers] [Print]


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.

[#] Tue Jun 26 2018 21:50:07 UTC from kc5tja

[Reply] [ReplyQuoted] [Headers] [Print]

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.

[#] Wed Jun 27 2018 00:35:01 UTC from IGnatius T Foobar

[Reply] [ReplyQuoted] [Headers] [Print]

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.

[#] Wed Jun 27 2018 10:08:09 UTC from fleeb <>

[Reply] [ReplyQuoted] [Headers] [Print]


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/

[#] Fri Jun 29 2018 18:16:06 UTC from kc5tja

[Reply] [ReplyQuoted] [Headers] [Print]

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.

[#] Mon Jul 02 2018 14:29:53 UTC from IGnatius T Foobar

[Reply] [ReplyQuoted] [Headers] [Print]

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

[#] Mon Jul 02 2018 15:08:45 UTC from fleeb <>

[Reply] [ReplyQuoted] [Headers] [Print]


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

[#] Mon Jul 02 2018 17:52:21 UTC from kc5tja

[Reply] [ReplyQuoted] [Headers] [Print]

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.

[#] Tue Jul 03 2018 19:20:22 UTC from IGnatius T Foobar

[Reply] [ReplyQuoted] [Headers] [Print]

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

[#] Thu Jul 05 2018 18:48:58 UTC from kc5tja

[Reply] [ReplyQuoted] [Headers] [Print]

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.

[#] Thu Jul 05 2018 19:07:20 UTC from kc5tja

[Reply] [ReplyQuoted] [Headers] [Print]

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.

[#] Fri Jul 06 2018 06:19:46 UTC from ax25

[Reply] [ReplyQuoted] [Headers] [Print]

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.



[#] Fri Jul 06 2018 21:22:09 UTC from kc5tja

[Reply] [ReplyQuoted] [Headers] [Print]

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.

[#] Mon Jul 09 2018 09:58:10 UTC from fleeb <>

[Reply] [ReplyQuoted] [Headers] [Print]


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

[#] Mon Jul 09 2018 14:00:50 UTC from IGnatius T Foobar

[Reply] [ReplyQuoted] [Headers] [Print]

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.



[#] Thu Jul 12 2018 13:17:56 UTC from fleeb <>

[Reply] [ReplyQuoted] [Headers] [Print]


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.

[#] Fri Jul 27 2018 17:08:21 UTC from IGnatius T Foobar

[Reply] [ReplyQuoted] [Headers] [Print]


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.

[#] Mon Jul 30 2018 14:39:27 UTC from LoanShark <>

[Reply] [ReplyQuoted] [Headers] [Print]


As long as your commits are conflict-free...

Go to page: First ... 31 32 33 34 [35] 36 37 38 39 ... Last