>>8
It can from Dired-mode, using C-t i or C-t x.
C-t i displays it interally (opens up and image-dired buffer)
C-t x displays it externally (on my computer it does it with imagemagick >>9
If you open it up interally, you can get view the image as text, but AFAIK there is no ASCII art option
Name:
Anonymous2010-05-01 16:26
An OS based on a reflective OO language with an Erlang-like actor model. The default executable format would store bytecode, which would be compiled before execution, and the executables would also double as libraries, that is a paint executable would also expose functions for image manipulation accessible from other executables. And I'd probably end up making the language very Lisp-like.
A shame I know jack shit about OS design or language design :(
>>14 The default executable format would store bytecode, which would be compiled before execution, and the executables would also double as libraries, that is a paint executable would also expose functions for image manipulation accessible from other executables.
Let's see, Java and .NET are bytecode based, and can do JIT or full compilation if needed (results are large, but if you compare it with other full-fledged implementations like SBCL, sizes aren't really that huge on average). Executables can double as libraries on Windows, as long as there's relocations, and if they don't there are ways to make them act like libraries or have them execute code. When it comes to .NET and Java, they ALWAYS can double as assemblies/libraries. So I can load an exe in another exe, if I desire to do so. And I'd probably end up making the language very Lisp-like.
Some CL implementations do actually have extensions which make them very reflective and a few of them allow traditional loadable libraries... (But, almost all have some FASL support, which is similar to per-file compiled modules) An OS based on a reflective OO language with an Erlang-like actor model.
So far, I wonder why would it need to be designed as an OS? Almost everything is buildable on top of modern OSes. Although, if you wanted low overhead, making your own OS may be a good idea.
Name:
Anonymous2010-05-01 17:08
>>15 When it comes to .NET and Java, they ALWAYS can double as assemblies/libraries. So I can load an exe in another exe, if I desire to do so. Oh. I didn't know that, thanks.
So far, I wonder why would it need to be designed as an OS? No real reason, I just thought that it would be more interesting if I were to create a full-fledged system with nice features (but little practical use). This is just an idea I had some time ago, and I didn't develop it any further.
Name:
Anonymous2010-05-01 17:13
No real reason, I just thought that it would be more interesting if I were to create a full-fledged system with nice features (but little practical use). This is just an idea I had some time ago, and I didn't develop it any further.
It would help users understand the entire system better.
or did you mean something of a loli in the bottom-right corner of the page?
Name:
Anonymous2010-05-03 2:28
I approve of this thread. It sent me through a wave of nostalgia as I browsed through all my old (>10 yrs) programming folders. I've written a lot of garbage over the years ;_;
>>28
Interesting idea. I'd also like it if it would have a mode where it can ask if you want to accept some cookies or not, maybe with an option to blacklist or whitelist some domains (would be useful for blocking tracking cookies some advertisers use and whitelisting auth cookies).
>>40
I call bullshit. Even if it's true, XML is hardly more flexible.
Name:
Anonymous2010-05-10 5:45
>>41
Try sending a date as JSON. The only way to do this is to convert it to a string and tell the other guy ``Oh, and by the way, this field is ostensibly a string/list/mapping/number, but you actually need to interpret it in a specific way to get a date.''. Now it may seem that XML has the same problem, but you can use XML schemata to tell the other guy's parser which fields are dates.
YAML probably solves this in a better way with user defined data types, but ONE WORD, THE FORCED INDENTATION OF DATA, THREAD OVER.
>>42
What? Either send a date string, an unix timestamp, or an object with year, month, day. Exactly like XML, only you don't need to support retarded entities and CDATA and EBCDIC encoding and doctypes and namespaces and crap just because.
Name:
Anonymous2010-05-10 6:52
>>43
Is the encoding part of the JSON specification? I don't see why EBCDIC JSON shouldn't be possible, or why JSON parsers shouldn't support it.
Name:
Anonymous2010-05-10 7:41
>>43
I don't want to sent a date string or a timestamp. I want to send a date. I want account.expiry_date to be a date so I can compare it to the current date, show it as a string or check the day of the week.
One thing I absolutely do not want to do is litter my code with json_date_to_real_date(account.expiry_date), because after I parse something, I expect it to be fully parsed. The type of the data should be in the data, not in the code that uses it after `parsing'.
Of course XML has its flaws, but when it's a huge pain to just to send a date in JSON1, you know something's wrong there too.
>>45
So you're in a tizzy because JSON doesn't have an exhaustive list of types? Is that right?
Name:
Anonymous2010-05-10 8:50
>>45
You seem to be using JSON for purposes it wasn't designed for. If you really want disgusting, complicated type support, use XML Schema.
Name:
Anonymous2010-05-10 9:56
>>46
No, I think JSON sucks because there is no standard way to extend it with user-defined types. With Crockford making ridiculous statements like ``JSON is not extensible. It does not need to be.''1 it is no suprise that using JSON often results in trying to put a square peg into a round hole.
>>47
Is {'expiry_date': date('2010-09-09')} or equivalent too much to ask for? You could use the identity function by default.
>>48
At first I thought >>47 was being a bit irrelevant, but now I agree with him. Just use YAML or whatever and get over it. Or continue using XML, really. There's no need to complain about JSON though. You don't find people who use JSON don't complain that XML isn't native code, despite the fact that it is exactly why many of them are using it whether they realize it or not.
If you really want your data to be 'fully parsed', you can just wrap your json parser with a thin layer that converts your user defined types based on a table of keys and types. In other words you just tell it 'expiry_date' and 'creation_date' are both dates, and have it convert them for you. You can write this in ten lines of scheme.
One thing I absolutely do not want to do is litter my code with json_date_to_real_date(account.expiry_date)
Really? You can't do that conversion in the one place where you read the date, in the actual place it belongs? Instead you want to write a gigantic extensible XML parser than you can program your types into? Ah, you must be the J2EE programmer that makes my day job a living hell.
Name:
522010-05-10 15:49
>>45
I just read your link, and it's really, really fucking stupid.
These are both almost acceptable compromises (if everyone agrees on them) but have a fundamental flaw which is that there can be false positives: what if you want to serialize the "1997-07-16T19:20:30.45+01:00" string, as a real string, not as a date?
Context. Jesus fucking christ. What is the point of correctly parsing the data if you have no idea what it is?
JSON text SHALL be encoded in Unicode. The default encoding is
UTF-8.
Since the first two characters of a JSON text will always be ASCII
characters [RFC0020], it is possible to determine whether an octet
stream is UTF-8, UTF-16 (BE or LE), or UTF-32 (BE or LE) by looking
at the pattern of nulls in the first four octets.
00 00 00 xx UTF-32BE
00 xx 00 xx UTF-16BE
xx 00 00 00 UTF-32LE
xx 00 xx 00 UTF-16LE
xx xx xx xx UTF-8
Name:
Anonymous2010-05-10 17:13
>>54
So basically, the spec is ambiguous because the authors don't know what the fuck ``Unicode'' means. Great.
>>55
Not really, no. Basically a JSON file is represented as an Unicode stream, if serialized into a byte stream it will be one of the five listed UTF formats, and in real life it will always be UTF-8.
Name:
Anonymous2010-05-21 17:02
>>1 .txt
No. I write my ideas down with a pen and dead tree format. Like the hackers of old used to do.
An on-line editable (wiki-like) story directed-graph mixed with a state machine.
So basically you get a window with the main vertex, some text based on your current state, and links to other vertices describing what action/choice clicking on that link will do/imply/&c.
Embedded in the text is a simple CPP-like programming language that changes state as you land on vertices and go about your day.
TiddlyWiki-like navigation/editing interface and moderator pages with lists of recent changes, abandoned nodes, &c. (perhaps also "this subtree is X deep and Y wide" after the links, though that would require something clever with back-references (i.e. the graph-part))
>>69
There was a game almost just like that on Madness Temple back when it wasn't a hosting site.
Name:
Anonymous2010-06-22 4:07
>>70
Please, tell me more. Googling "Madness Temple" yielded no results.
Name:
Anonymous2010-06-22 6:15
>>71
I can't find it at all either. All I remember about it is that it also had a few other home-grown games, as well as a music video discussing the differences between `eggplant' and `aubergine.'
It was basically a smaller version of b3ta and 4rthur.
Name:
Anonymous2010-06-22 6:50
* super conversion tool, with pluggable conversion.
eg: one interfact would be a right click context menu, dynamiacally generated to offer releveant targets.
eg right click mp3, show "convert to ogg, convert to flac etc"
eg right click jpg, show "convert to gif, convert to png etc"
plugins would be DLLs that offer conversion to a particular mime type (audio, image, video, text etc)
---------
super color edit. allows you to select a section of code and put in a certain background color. or have auto coloring based on programming language (different to syntax highlighting)