"ASCII"
-
@pie_flavor said in "ASCII":
In 10 years, given everyone's apparent obsession with using old stupid things instead of new fancy things (see: editors over IDEs, git over being sane, etc.), we'll be right back to using ASCII.
Other than my web browser, most software I use is 2 or 3 versions "out of date". New is not always better. Old is not always bad.
Filed Under: ASCII no questions and I will tell you no lies.
-
I mean there's fossil, but I've never met anybody actually using that.
Oh yes, you have.
-
@cvi I'd restrict them to the codepoints where it makes sense.
Great. Another table of stuff to lug around and keep updated when "parsing" Unicode. ;-)
Not sure why RGB would that much harder compared to a few discrete colours. In the attempts at rendering unicode I've seen (which are rather basic ones TBF), if there's support for per-glyph colors, there's basically already support for full RGB. But YMMV. (Colorizing just a part of the glyph, as seen in e.g. the apples and in some of the emojis with skin tone, seems much more invasive.)
I'd say it depends on what exactly you mean by "arbitrary RGB". The usual 3×8 bits RGB requires 24 bits, which means it could not be encoded in a single codepoint (since only 20.1 bits are supported). So either one needs multiple combining "color channel+value" codepoints, or we'd have to restrict colors to a smaller subset (3×2 bits for example, is already more than the classic CGA palette, and more than an Amstrad CPC's full palette).
Anything that can be expressed as printable text can be expressed as non-printable tags. All they'd need is a uniform syntax.
-
I mean there's fossil, but I've never met anybody actually using that.
Oh yes, you have.
I'm pretty sure the guy that makes Sqlite uses it too.
-
I mean there's fossil, but I've never met anybody actually using that.
Oh yes, you have.
I'm pretty sure the guy that makes Sqlite uses it too.
Ok, two people use it. However, @cvi said
I've never met anybody actually using that [emphasis added]
I've never met @dkf or the guy that makes Sqlite. @cvi probably hasn't, either.
-
@HardwareGeek , this is @dkf.
@dkf, @HardwareGeek.
@cvi, meet @dkf and @HardwareGeek .
@cvi, everyone.
-
*tries to shake hands with the monitor*
-
-
*tries to shake hands with the monitor*
Shaking hands with monitor lizards can be a bit difficult.
-
@pie_flavor said in "ASCII":
Shaking hands with monitor lizards can be a bit difficult.
-
@pie_flavor said in "ASCII":
Shaking hands with monitor lizards can be a bit difficult.
Mmmm
-
@hardwaregeek said in "ASCII":
I've never met @dkf or the guy that makes Sqlite. @cvi probably hasn't, either.
Well, I've met the guy that makes SQLite. Quite a few times. He's one of those programmers who says “how hard can it be?” and proceeds to actually do the nearly impossible while discovering that it can be really quite incredibly difficult. OTOH, I've had people accuse me of being a bit the same.
I like fossil a lot. I also use git (for work) and I don't like it anything like so much. There are things that you can get extra by using a service like github, and they're sometimes better and sometimes worse than fossil, but pure git is really quite annoying in many ways. Occasionally it lets you do things that nobody else supports and then it is invaluable, but that's very much not the commonplace case; after all, you shouldn't be doing major history rewriting as an everyday thing. (Also, Eclipse's git support makes it a lot easier than the baseline command line tool is.)
-
@dkf I do actually think that fossil is relatively neat. I like that it's a stand-alone self-contained executable. The integrated features for notes/bug tracking etc are nice too.
The main hurdle is that most people already know git or svn. They probably even have a github account these days.
I've been toying with the idea of switching over one of my personal projects, mostly for the wiki. One problem is svn externals/submodules. The other problem is that I have to setup a place I can push to (and I'm lazy).
-
The main hurdle is that most people already know git or svn. They probably even have a github account these days.
Command-line wise, I find fossil to be like a mix of much of the best of cvs, svn and git. I very much like having the distributed issue DB, and
fossil uiis very useful for most advanced manipulations.If you need a service to support you, http://chiselapp.com/ works well. (I don't know if they do private hosting; I've not needed that sort of thing.)
-
@dkf I have a server somewhere, so it's mostly down to the 30 minutes I need to remember the commands to setup a fresh LXC instance, make it talk to the rest of the world, and figure out how to run a fossil server that doesn't give all the hackers access to my container. OTOH, I already have a SVN server instance, so...
I tried it once and had a look at the web interface, that was actually kinda nice.
I currently use git to check out from a svn (via git svn). If fossil had a similar way to occasionally push a set of changes to SVN, I'd probably give it another shot sooner.
-
one of those programmers who says “how hard can it be?” and proceeds to actually do the nearly impossible while discovering that it can be really quite incredibly difficult. OTOH, I've had people accuse me of being a bit the same.
Of saying “how hard can it be?” or of actually doing the nearly impossible? I know I can be guilty of the former but — in my opinion anyway — not the latter.
Also: who thinks
looks like someone laughing? To me it looks like a very angry smiley.
-
Also: who thinks
looks like someone laughing? To me it looks like a very angry smiley.That's got to be laughing; the mouseover text says so!
-
I currently use git to check out from a svn (via git svn). If fossil had a similar way to occasionally push a set of changes to SVN, I'd probably give it another shot sooner.
The usual way of migrating a SVN repo to fossil is via git (which has a reasonably well tested integration). But migrating isn't the same as repeatedly synchronising.
The migrations I've been involved with were from CVS, and they were rather hacky due to the lack of repo-level versions. Also the original repository was actually outright broken (it happened long ago so I don't know/remember why) which meant that manual fixing was needed. Going to git would have been just as bad too; the challenge was turning the garbage input into something that left at least most of the repo usable.
-
Well, I've met the guy that makes SQLite. Quite a few times. He's one of those programmers who says “how hard can it be?” and proceeds to actually do the nearly impossible while discovering that it can be really quite incredibly difficult. OTOH, I've had people accuse me of being a bit the same.
-
Also: who thinks
looks like someone laughing? To me it looks like a very angry smiley.It looks like laughing to me, like the
XDtext emote. Maybe a cultural difference?
-
-
who thinks looks like someone laughing?
I do.
Does seeing it in its original size help you?
-
like the XD text emote.
It was years after I first saw that that I realised it was meant to be an emoticon not jut ecks dee
-
@gurth said in "ASCII":
Does seeing it in its original size help you?
Nope, sorry. It still reminds me mainly of someone shouting angrily.
-
To me it looks like someone laughing, but of the "laughing at you" sort, not the "laughing with you". It's the eyes, they're a bit too aggressive.
-
-
@gurth said in "ASCII":
Does seeing it in its original size help you?
Nope, sorry. It still reminds me mainly of someone shouting angrily.
Depends on whether you're mainly looking at the eyes, or mainly at the mouth.
The shape of the mouth is what makes it look like it's laughing.
-
-
@anotherusername said in "ASCII":
Depends on whether you're mainly looking at the eyes, or mainly at the mouth.
The shape of the mouth is what makes it look like it's laughing.
Yeah, I think that’s the problem: I mainly see the eyes, and so think “angry with an open mouth.” The eyeless one in your post, I would say is laughing.
-
“angry with an open mouth.”
I see "laughing so hard eyes are about to start tearing"
-
Keep in mind that's just the results for people saying "Dwarf Fortress ASCII" with no words in between.
For the record, Dwarf Fortress uses IBM code page 437. Yes, even in the log files.
-
@ben_lubar said in "ASCII":
For the record, Dwarf Fortress uses IBM code page 437. Yes, even in the log files.
Yuck
-
@ben_lubar said in "ASCII":
For the record, Dwarf Fortress uses IBM code page 437. Yes, even in the log files.
On the one hand, yuck. On the other hand, it's precisely defined so it isn't a real problem. It's mixed encodings that get my nausea really going.
-
@khudzlin @dkf I don't get the hate for CP437; it's the default code page for text mode under DOS, and reproduced in the Windows console app used for DOS mode. It was good enough for me in 1995; what's the big deal now?
Sure, UTF-8 would be better for log compatibility, but if you're dealing with a console application on Windows it's still a good bet that you'll be dealing with CP437. (Does the log even actually contain any extended ASCII characters? 7-bit ASCII is directly compatible with UTF-8 with no conversion.)
-
@anotherusername said in "ASCII":
what's the big deal now?
I use more symbols than it has characters for. ;)
-
@dkf not when you're running Dwarf Fortress... it has all of the ones that you need: #*(@^$&!@#^
-
@anotherusername said in "ASCII":
it has all of the ones that you need: #*(@^$&!@#^
I was fixing someone's Perl script yesterday, so no, that's not enough…
-
-
@anotherusername said in "ASCII":
@khudzlin @dkf I don't get the hate for CP437; it's the default code page for text mode under DOS, and reproduced in the Windows console app used for DOS mode. It was good enough for me in 1995; what's the big deal now?
Sure, UTF-8 would be better for log compatibility, but if you're dealing with a console application on Windows it's still a good bet that you'll be dealing with CP437. (Does the log even actually contain any extended ASCII characters? 7-bit ASCII is directly compatible with UTF-8 with no conversion.)
Maybe people hear IBM and think it's an EBCDIC variant?
-
@anotherusername said in "ASCII":
@khudzlin @dkf I don't get the hate for CP437; it's the default code page for text mode under DOS, and reproduced in the Windows console app used for DOS mode. It was good enough for me in 1995; what's the big deal now?
Sure, UTF-8 would be better for log compatibility, but if you're dealing with a console application on Windows it's still a good bet that you'll be dealing with CP437. (Does the log even actually contain any extended ASCII characters? 7-bit ASCII is directly compatible with UTF-8 with no conversion.)
Actually, the code page for the Windows console app is language-dependant (or maybe locale-dependant). I've seen characters in mine that don't appear in CP437.
-
@khudzlin it was language dependent under DOS also... that's why it's called a "code page". CP437 is also referred to as "OEM-US" or "DOS Latin US"... that default code page could be swapped out for another code page, to support other languages.
-
@ben_lubar said in "ASCII":
For the record, Dwarf Fortress uses IBM code page 437. Yes, even in the log files.
On the one hand, yuck. On the other hand, it's precisely defined so it isn't a real problem. It's mixed encodings that get my nausea really going.
Does the encoding have all the symbols you need? For DF, apparently yes.
Do you know what encoding it is?
So for DF, it's good enough (ignoring the
of using "good" and "DF" in the same sentence).
Tags (Unicode block) - Wikipedia
