February 22, 2012
"H. S. Teoh" <hsteoh@quickfur.ath.cx> wrote in message news:mailman.860.1329924869.20196.digitalmars-d@puremagic.com...
> On Wed, Feb 22, 2012 at 08:53:06AM +0100, Paulo Pinto wrote: [...]
>> This has been changing in the last years since Microsoft introduced Powershell and due to market pressure created headless versions of Windows.
>
> Wow. Headless Windows? Can it even be called Windows anymore? :)
>

Microsoft Drywall :)


February 22, 2012
On Wed, Feb 22, 2012 at 11:08:41AM -0500, Nick Sabalausky wrote:
> "H. S. Teoh" <hsteoh@quickfur.ath.cx> wrote in message news:mailman.860.1329924869.20196.digitalmars-d@puremagic.com...
> > On Wed, Feb 22, 2012 at 08:53:06AM +0100, Paulo Pinto wrote: [...]
> >> This has been changing in the last years since Microsoft introduced Powershell and due to market pressure created headless versions of Windows.
> >
> > Wow. Headless Windows? Can it even be called Windows anymore? :)
> >
> 
> Microsoft Drywall :)
[...]

LOL

On a more serious note, this is perhaps a proof that it's not a good idea to conflate the OS with the GUI. :) But then I'm just being pedantic.


T

-- 
If you think you are too small to make a difference, try sleeping in a closed room with a mosquito. -- Jan van Steenbergen
February 22, 2012
"H. S. Teoh" <hsteoh@quickfur.ath.cx> wrote in message news:mailman.865.1329932055.20196.digitalmars-d@puremagic.com...
> On Wed, Feb 22, 2012 at 11:08:41AM -0500, Nick Sabalausky wrote:
>> "H. S. Teoh" <hsteoh@quickfur.ath.cx> wrote in message news:mailman.860.1329924869.20196.digitalmars-d@puremagic.com...
>> > On Wed, Feb 22, 2012 at 08:53:06AM +0100, Paulo Pinto wrote: [...]
>> >> This has been changing in the last years since Microsoft introduced Powershell and due to market pressure created headless versions of Windows.
>> >
>> > Wow. Headless Windows? Can it even be called Windows anymore? :)
>> >
>>
>> Microsoft Drywall :)
> [...]
>
> LOL
>
> On a more serious note, this is perhaps a proof that it's not a good idea to conflate the OS with the GUI. :) But then I'm just being pedantic.
>

I've thought about that, and always been conflicted on it. User-choice and configurability is great, but OTOH there's something to be said about being able to assume one GUI system and not worry about a program or a set of instructions working on KDE *and* GNOME *and* xfce *and* lxde *and* blackbox *and* afterstep (is that still in use?) *and* etc... It'd be great if we could just have one GUI that's flexible/customizable/efficient enough for everyone. But then, problem is half the GUIs out there are *all* trying to be that "one and only" GUI. Oh well.

> If you think you are too small to make a difference, try sleeping in a closed room with a mosquito. -- Jan van Steenbergen

Heh, you've got some good quotes. I also really liked that one about "Why didn't he append 'I think' to 'wiser people are so full of doubts'?"


February 22, 2012
On Wednesday, 22 February 2012 at 17:34:16 UTC, H. S. Teoh wrote:
> On a more serious note, this is perhaps a proof that it's not a good
> idea to conflate the OS with the GUI. :) But then I'm just being
> pedantic.

Do you wanna say modern hardware still can't run GUI system?
February 22, 2012
On Wed, Feb 22, 2012 at 07:36:24PM +0100, Kagamin wrote:
> On Wednesday, 22 February 2012 at 17:34:16 UTC, H. S. Teoh wrote:
> >On a more serious note, this is perhaps a proof that it's not a good idea to conflate the OS with the GUI. :) But then I'm just being pedantic.
> 
> Do you wanna say modern hardware still can't run GUI system?

That's not what I mean. When your OS is running on a dedicated remote server, it makes no sense to have a GUI running on it, since all administration is done remotely anyway. A GUI on a server is just a waste of resources.


T

-- 
Almost all proofs have bugs, but almost all theorems are true. -- Paul Pedersen
February 23, 2012
On Wed, Feb 22, 2012 at 01:14:46PM -0500, Nick Sabalausky wrote:
> "H. S. Teoh" <hsteoh@quickfur.ath.cx> wrote in message
[...]
> > On a more serious note, this is perhaps a proof that it's not a good idea to conflate the OS with the GUI. :) But then I'm just being pedantic.
> >
> 
> I've thought about that, and always been conflicted on it. User-choice and configurability is great, but OTOH there's something to be said about being able to assume one GUI system and not worry about a program or a set of instructions working on KDE *and* GNOME *and* xfce *and* lxde *and* blackbox *and* afterstep (is that still in use?) *and* etc... It'd be great if we could just have one GUI that's flexible/customizable/efficient enough for everyone.

I thought that was called X11?  Oh wait... ;-)

The problem with X11 is that it was designed almost 30 years ago, and as a result its API is, by today's standard, rather baroque. It was also from a time before the dominance of the so-called desktop metaphor, which means many contemporary programs require a lot more infrastructure than it provides. Which is why KDE and GNOME exist.

I've always been a stickler for configurability. But I can see the value of having a consistent set of instructions for a newbie to follow when she encounters problems with your app. If everyone has a different setup then tech support is a veritable waking nightmare.

Perhaps the solution is to have a single *default* desktop, and then power users can configure it to their hearts' content, with the caveat that if things go wrong, they're on their own. Power users ought to know how to translate instructions intended for the default desktop to their own environment anyway.

For example, I don't think *anyone* could give me sane instructions that would work on my "desktop"... which is more like a glorified console than a real desktop. :P  But if you said something like "go to applications -> browsers, click on Firefox", then I'd just smile and nod and type "firefox&" at the shell prompt. :)


> But then, problem is half the GUIs out there are *all* trying to be that "one and only" GUI. Oh well.

To me, one GUI has already won, and it's called rxvt. ;-)


> > If you think you are too small to make a difference, try sleeping in a closed room with a mosquito. -- Jan van Steenbergen
> 
> Heh, you've got some good quotes. I also really liked that one about "Why didn't he append 'I think' to 'wiser people are so full of doubts'?"
[...]

Here's one of my all-time favorites:


T

-- 
There is no gravity. The earth sucks.
February 23, 2012
I started the dshell just to waste a little time:

http://arsdnet.net/dcode/dshell.d

        dmd dshell.d -L-lreadline -L-lncurses

It doesn't do much here, but there's a few things I think
are cool:

1) D reflection rox. You can write D functions with simple
arguments and it works basically. I want to detect bitfield
enums to automatically do -flags too.

2) Your functions can return whatever, and it is wrapped in
a runtime polymorphic range.

If you just want strings, you can do ProgramDataByLine(input).

If you want something fancier, you can use originalProgramData!Type
to fetch out the original input range.


The syntax is so far just the basics... calling functions
and pipes.



but hey its kinda cool already.
February 23, 2012
On 23 February 2012 15:56, Adam D. Ruppe <destructionator@gmail.com> wrote:
> I started the dshell just to waste a little time:
>
> http://arsdnet.net/dcode/dshell.d
>
>        dmd dshell.d -L-lreadline -L-lncurses
>
> It doesn't do much here, but there's a few things I think are cool:
>
> 1) D reflection rox. You can write D functions with simple arguments and it works basically. I want to detect bitfield enums to automatically do -flags too.
>
> 2) Your functions can return whatever, and it is wrapped in a runtime polymorphic range.
>
> If you just want strings, you can do ProgramDataByLine(input).
>
> If you want something fancier, you can use originalProgramData!Type to fetch out the original input range.
>
>
> The syntax is so far just the basics... calling functions and pipes.
>
>
>
> but hey its kinda cool already.

And I've been playing with trying to write my own terminal emulator. I actually kinda have one working, in C. I just need to wrap all the C code in functions and do all the interesting stuff in D.

The terminal doesn't support most (any) terminal codes, in either direction it also doesn't do any scrolling, so if you hit the end of the window, you're kinda screwed... Its more a proof-of-concept than anything actually usable.

But I have plans for it, including some cool graphical stuff. I'm using clutter to render everything, so I can do all sorts of things with it, but to start with, I'd like to be able to display pictures inline, so you can do `cat my_pic.jpg` and rather throwing masses of garbage at you, it renders the picture, I might have to write my own cat to do so however...

--
James Miller
February 23, 2012
On Thu, Feb 23, 2012 at 06:02:30PM +1300, James Miller wrote: [...]
> And I've been playing with trying to write my own terminal emulator. I actually kinda have one working, in C. I just need to wrap all the C code in functions and do all the interesting stuff in D.
[...]
> But I have plans for it, including some cool graphical stuff. I'm using clutter to render everything, so I can do all sorts of things with it, but to start with, I'd like to be able to display pictures inline, so you can do `cat my_pic.jpg` and rather throwing masses of garbage at you, it renders the picture, I might have to write my own cat to do so however...
[...]

Now *that* is an excellent idea!

Perhaps there's a way of detecting JPEG or PNG output, say some kind of magic number detection ala /usr/bin/file. Buffer the first few bytes at output at the start of new lines, and if it looks like a JPEG file, buffer the rest of the output instead of displaying it immediately, and if after reading more input it does appear to be a valid JPEG file, then display it as an image.  Otherwise flush the buffer and display it as text.

To prevent problems with false positives causing output not to appear, you could use a timer: if the data type can't be determined within, say, 1/20 of a second, then skip the detection and display the output as text. Presumably if you do cat my_pic.jpg more than just the first few bytes will come out in the first 1/20 of a second, so it will pretty much reliably detect image data.

Or you can do it the easy way by having a dedicated escape sequence that switches to image mode, and write a wrapper for cat that outputs this sequence when it detects image data in its output. The danger though is that you might get stuck in image mode if cat crashes before the image data is completely spooled, in that case it'll be like the ole DOS days when you got stuck in VGA mode when it has dropped back to the DOS prompt, and typing only produces line noise on the screen. :P


T

-- 
This is a tpyo.
February 23, 2012
On Thu, Feb 23, 2012 at 03:56:49AM +0100, Adam D. Ruppe wrote:
> I started the dshell just to waste a little time:
> 
> http://arsdnet.net/dcode/dshell.d
> 
>         dmd dshell.d -L-lreadline -L-lncurses
> 
> It doesn't do much here, but there's a few things I think are cool:
> 
> 1) D reflection rox. You can write D functions with simple arguments and it works basically. I want to detect bitfield enums to automatically do -flags too.

Nice!!! So you can write the same code for both the "shell library" and the actual shell itself.


> 2) Your functions can return whatever, and it is wrapped in a runtime polymorphic range.

Cool, this is better than just plaintext stdin/stdout. :)


> If you just want strings, you can do ProgramDataByLine(input).
> 
> If you want something fancier, you can use originalProgramData!Type to fetch out the original input range.

Nice.


> The syntax is so far just the basics... calling functions and pipes.

The echo command has a bug, it's not supposed to output 'echo' as part of its output. :)


> but hey its kinda cool already.

It's extremely cool. Definitely orders of magnitude better than writing the equivalent thing in C. Can you imagine the amount of code duplication & ugliness that you'd need in an equivalent C implementation?  Without reflection, you'd either need hand-coded tables all over the place or insanely complex nested macros that nobody can understand.


T

-- 
GEEK = Gatherer of Extremely Enlightening Knowledge