«

On 02/08/2012 11:42 AM, Jorgen Grahn wrote:
....
> {{Unix bigot mode|
> Unix in general makes it easier to write programs which are small and
> have a simple interface, yet are useful. I haven't tried it, but I
> imagine the threshold is much higher on Windows.}}

If you haven't tried doing it on Windows yet, what is it you're
comparing Unix against when you say it's "easier"? I know there's things
other than Unix and Windows, but the significance of your statement
would be easier to evaluate if we knew what you were comparing Unix with.

On Feb 8, 4:42*pm, Jorgen Grahn <grahn+n...@snipabacken.se> wrote:
> On Sat, 2012-02-04, Malcolm McLean wrote:
> > On Feb 3, 5:24*pm, Sleepy Duke <josh.izz...@gmail.com> wrote:

> >> What are the best methods you all have found for teaching yourselves >>> how to code proficiently in C?

[...]

> > [...] get graphics working as fast as you
> > can. It's harder now than it was to get a simple character-based
> > raster that can be used for moving space invaders round the screen.
>
> It's still easy on Unix, where you have the curses library.
>
> {{Unix bigot mode|
> Unix in general makes it easier to write programs which are small and
> have a simple interface, yet are useful. I haven't tried it, but I
> imagine the threshold is much higher on Windows.}}

simple filters that work in Unix work fine in windows. You may even be
able to run the same code.

Nowadays simple GUI/graphics stuff is probably about evens. But when
it was X-Window verses Win32 I humbly submit Windows was streets
ahead!

On Feb 8, 10:31*am, Rui Maciel <rui.mac...@gmail.com> wrote:
> Nick Keighley wrote:

[best way to learn C- beginner programmer]

> > write lots of code.
>
> > the best way I found was already knowing anothe couple of programming
> > languages, but this probably doesn't help...
>
> I would also add participating in public forums dedicated to the
> programming language, such as comp.lang.c, and also forums dedicated to >specific platforms, such as comp.unix.programmer. *Getting our hands
> dirty may be the best learning experience that we can have, but being
> exposed to the experiences that others had/are having will also
> contributes greatly to our own progress.

good point. by this time I know what a program should look like so
even in a new language. I want my programs to work (lots of tests) and
exhibit a certain... spareness- no repeated code, no wodges of boiler
plate, no pages of woffle, each component should do one thing well.
Oh, and it should be idiomatic as well (you can write FORTRAN in any
language).

> Plus, when we stumble on a problem we might benefit from having a
> community willing to help us out on it. *Conversely, we may help others> with their problems, and in the process learn a bit more from it.
>
> In short, we may do all our learning alone, but being a part of a
> community dedicated to a specific subject also helps a lot.

yes, this group, C++, scheme, Microsoft, Unix have all helped me lots.
Oddly I've never really used a perl newgroups. Which might explain my
perl!

On Feb 7, 2:05*pm, r...@zedat.fu-berlin.de (Stefan Ram) wrote:
> Sleepy Duke <josh.izz...@gmail.com> writes:
> >What are the best methods you all have found for teaching
> >yourselves how to code proficiently in C?
>
> * Reading C books (including the C specification), Reading
> * books on software engineering (not C specific),

reading about the design of other stuff. I'm in a minority here I
know...

> Reading and
> * porting code (e.g., C code from other systems to the Amiga
> * or from other languages to C), writing C code, talking with
> * friends about C, Reading the C source code of a computer
> * game while playing it to find the tricks (how to play and
> * win), and giving C classes (my next C class starts this
> * thursday [the day after tomorrow] in Berlin; it's a real
> * C class [not a C++ class]).
>

On Feb 7, 6:07*pm, notbob <not...@nothome.com> wrote:
> On 2012-02-07, Stefan Ram <r...@zedat.fu-berlin.de> wrote:

> > * Some omissions are necessary in teaching, mistakes are not.
>
> .....and of course, in the interest of "teaching", you are going to
> omit what those "necessary" omissions might be and why.
>
> Balderdash!

you shouldn't teach things that are actually wrong. It takes ages
(sometimes never) for people to shake off things like "pointers are
faster than arrays"

On Feb 9, 8:42*am, Nick Keighley <nick_keighley_nos...@hotmail.com>
wrote:
>
> Nowadays simple GUI/graphics stuff is probably about evens. But when
> it was X-Window verses Win32 I humbly submit Windows was streets
> ahead!
>
X is fundamentally misdesigned, because the idea is that the "client",
which means sever, sends a stream of bytes over a network to the "X
sever", which means client. However virtually no systems work like
that, and in fact it's hard to get interactivity if the client is
remote. But that consideration dominates the interface.
Then it's stupidly hard to get up a wondow because you've got to mess
about with defining colormaps.

I did try to solve these problems with BabyX, which was going to be a
simple interface to X. But I never finished it, and there were some
difficulties. It worked on one system, but not when I tried it on
another.


--
MiniBasic - how to write a script interpreter
http://www.malcolmmclean.site11.com/www

Malcolm McLean wrote:

> X is fundamentally misdesigned, because the idea is that the "client",
> which means sever, sends a stream of bytes over a network to the "X
> sever", which means client. However virtually no systems work like
> that, and in fact it's hard to get interactivity if the client is
> remote.

If I'm not mistaken, the X window system was developed with remote clients
in mind and in a time where remote clients were the norm. So, with that in
mind, I don't agree that X was fundamentally misdesigned.

Fast-forward 30 years, nowadays we have clients sending and receiving
streams of bytes over a network to/from a server in order to provide a
graphical user interface, but instead of the X window system we have the
world wide web. So, although it's a slightly different abstraction level,
it's essentially the same thing.

But on the same abstraction level there is the Wayland display server
protocol, and it appears their developers haven't moved away from the same
type of design adopted for X.


> But that consideration dominates the interface.
> Then it's stupidly hard to get up a wondow because you've got to mess
> about with defining colormaps.

Maybe a better way to put it is that, since then, things got to be a whole
lot simpler. The technical limitations at the time didn't made it possible
to get away with some tricks that are employed today. After all, a
considerable number of GUI toolkits which are widely used today basically
provide an abstraction layer over X, and they work quite well.



Rui Maciel

On Feb 9, 1:31*pm, Rui Maciel <rui.mac...@gmail.com> wrote:
> Malcolm McLean wrote:
> > X is fundamentally misdesigned, because the idea is that the "client",
> > which means sever, sends a stream of bytes over a network to the "X
> > sever", which means client. However virtually no systems work like
> > that, and in fact it's hard to get interactivity if the client is
> > remote.
>
> If I'm not mistaken, the X window system was developed with remote clients
> in mind and in a time where remote clients were the norm. *So, with that in
> mind, I don't agree that X was fundamentally misdesigned.
>
> Fast-forward 30 years, nowadays we have clients sending and receiving
> streams of bytes over a network to/from a server in order to provide a
> graphical user interface, but instead of the X window system we have the
> world wide web. *So, although it's a slightly different abstraction level,
> it's essentially the same thing.
>
> But on the same abstraction level there is the Wayland display server
> protocol, and it appears their developers haven't moved away from the same
> type of design adopted for X.
>
> > But that consideration dominates the interface.
> > Then it's stupidly hard to get up a wondow because you've got to mess
> > about with defining colormaps.
>
> Maybe a better way to put it is that, since then, things got to be a whole
> lot simpler. *The technical limitations at the time didn't made it possible
> to get away with some tricks that are employed today. *After all, a
> considerable number of GUI toolkits which are widely used today basically
> provide an abstraction layer over X, and they work quite well.

that's why I said they were about evens. You program in some
abstraction and tweak it for particular implementations. probably not
good enough for serious games but for a learner ok.

On Feb 9, 1:31*pm, Rui Maciel <rui.mac...@gmail.com> wrote:
> Malcolm McLean wrote:
> > X is fundamentally misdesigned, because the idea is that the "client",
> > which means sever, sends a stream of bytes over a network to the "X
> > sever", which means client. However virtually no systems work like
> > that, and in fact it's hard to get interactivity if the client is
> > remote.
>
> If I'm not mistaken, the X window system was developed with remote clients
> in mind and in a time where remote clients were the norm. *So, with that in
> mind, I don't agree that X was fundamentally misdesigned.
>
> Fast-forward 30 years, nowadays we have clients sending and receiving
> streams of bytes over a network to/from a server in order to provide a
> graphical user interface, but instead of the X window system we have the
> world wide web. *So, although it's a slightly different abstraction level,
> it's essentially the same thing.
>
The problem is that the messages were wrong. In X the server sends a
message "A key was pressed" and the client has to send back a mesage
"please draw the letter X in such and such a font in that window". So
of course the poor user would hammer the key again, then get a row of
xes, then press delete several times, delete the lot, then tap the x
key once, deliberately and smartly, and go for a coffee until he could
type in the next character.
With the web interface the server says "put up an edit box". The
client then allows the user to enter text. It then tells the server
"the user has finished putting text into the boxes you told me to put
up, and here's what he wrote".
--
Visit my webiste. Lots of C programming material
http://www.malcolmmclean.site11.com/www

Malcolm McLean <> writes:

> The problem is that the messages were wrong. In X the server sends a
> message "A key was pressed" and the client has to send back a mesage
> "please draw the letter X in such and such a font in that window". So
> of course the poor user would hammer the key again, then get a row of
> xes, then press delete several times, delete the lot, then tap the x
> key once, deliberately and smartly, and go for a coffee until he could
> type in the next character.

I've seen people do that, but I've never understood why. If
you're going to type "xerxes", type "xerxes". Don't type "x" and
wait for it to appear, then type "e" and wait for it for appear.
It's a great way to waste your own time.
--
char a[]="\n .CJacehknorstu";int putchar(int);int main(void){unsigned long b[]
={0x67dffdff,0x9aa9aa6a,0xa77ffda9,0x7da6aa6a,0xa6 7f6aaa,0xaa9aa9f6,0x11f6},*p
=b,i=24;for(;p+=!*p;*p/=4)switch(0[p]&3)case 0:{return 0;for(p--;i--;i--)case+
2:{i++;if(i)break;else default:continue;if(0)case 1utchar(a[i&15]);break;}}}