Skip to main content

Cerca

Elementi taggati con: C


 
El castellano

Por qu algunos hispanohablantes pronuncian de manera diferente la c-z y la s y otros no las distinguen?


Sobre el seseo, el ceceo y la distincin. Sobre su origen, su distribucin geogrfica...

http://www.rtve.es/alacarta/videos/la-aventura-del-saber/aventuralola/3830621/

#lengua #lenguaje #lenguas #idiomas #espaol #castellano #lingstica #hispanidad #Amrica #Espaa #Hispanoamrica #Latinoamrica #PennsulaIbrica #Pennsula-Ibrica #Canarias #ConoSur #Cono-Sur #variantes #dialectos #Andaluca #pronunciacin #s #c #z #TVE

 
#vim #emacs #codeblocks #c #netbeans #visualstudio

A vim user's story


=== PREFACE

There is lot to say about this and I'm not going to dig deeply into it. I want to say some words about the two most versatile editors/development-environments I have ever seen.

There's no big deal, but why would I prefer a huge, slow and maybe bloated IDE when all I need is just a te.. ahem, buffer editor?

=== IDEs VS EDITORS

To be precise: IDEs are not bad software. But they are very often too much for a user to eventually even considering learning all of the features, and Visual Studio makes no exception: though being quite user-friendly, almost perfect for a developer, and having a nice documentation, it lacks of readiness, speed, and very often intuitiveness when it comes to environment settings. On the other side, Code::Blocks is not very friendly and maybe quite ugly and old-looking, but it really does everything one would need: it has the best GDB integration I have ever seen, though it could do better with GUI design (where Visual Studio just dominates with its Blend) and customization. NetBeans instead is kind of an in-between. It's very nice, though it suffers from being based on Java (which isn't really an issue itself, but may lead to issue) and being somewhat unresponsive sometimes with packages and customizations (at least I noticed that there is something wrong loading custom themes and packages) which may be unpleasant when you realize the reason your project doesn't compile because of some weird java exceptions (uncommon, but happened).

=== GUI VS UX

Although the history told us mice are more user-friendly, there's to say that the fact that it is useful is a misconception. The reason is that we as #programmers just don't use it when programming. Well, unless for copy-pasting StackOverflow answers (nope really), which is anyway a bad practice. We should #RTFM, as they always say. And it's true. The reason is simple: the keyboard is immediate and the mouse needs first pointing then clicking. That's slower for us. We don't need to click on a green triangle button to run the app, we should CTRL+F5.

=== (Dis)Advantages of Text Editors

Obviously, I'll not consider notepad.exe. It's just wrong for programming. I'll compare Notepad++ with, say, Atom and Sublime. Let's start with Notepad++. It's kinda basic and looks wrong/ugly. It actually can do lots of things and could be compared to something like UEStudio: it just has everything... except speed. The issue with Notepad++ is that it is awesome as it is: filling it up with plugins will slow it down very easily. Though, it is nice because it has debugger integration (using plugins; could be better but works), file map, code folding, nice theming features (just for the editor though), folder browsing, FTP support (plugins), etc. I think you're getting the main idea: it is light and nice but man he needs to fed up to be nicer. And often it costs very much (from glitches due to unsupported postscript fonts to slowness), as it gets heavier... and heavier... and basically defeats its original purpose of being a text editor (its defaults actually do a lot more, like macroes, python scripting - though buggy, autocompletion - though dictionary-based, ...). Let's check Atom/Brackets. It's actually a bit bett... no. It's just ok. 6/10. Actually, 6-. That minus stands for "hell why". The reason is this: it has a quite nice GUI and generally I like the Squirrel system. But, to achieve this result, it went to the "dark side" and everything is bound to NodeJS. It wouldn't be a problem if it was just for the API/extensions. But they based Electron on Node, which means it's not a very fast environment.

Damn it, I say, why? Why do I need WPF or Node/Webkit to draw beautiful GUIs? Why is GTK+/CSS so painful?!

Well, that's where Sublime wins. If I'm not wrong, most of it was written in C++ and Python. It is anyway an in-between. It's extensible yeah, customizable and... "light" (actually mid, but still) ...and shareware. Damn it. It would have been perfect.

=== The Terminal VS The Window(s)

My ideal post would be a large desk with three monitors: code to the left, debugger/web-inspector on the right and the product on the center of the screen. Though, when reading code, our eyes actually scroll top to bottom and not left to right. That's just the way you write programs.

It would be nice as well to have anything working like that. We should not have "an IDE" that emulates what we already have. In fact, though simpler to install/use, IDEs often come with a bunchful of apps and libs or even custom building tools (nuget, tdm gcc, ...) that we would probably never use or even have the time to learn/configure. We just want our program to build & run. The best IDE is your own Operating System. Every operating system comes with a nice documentation with APIs (99% of the times in C) and tools we often don't really know about because they're hidden by the GUI. That's why the Terminal exists. It allows you to directly input the instructions. Wouldn't it be just faster to use them without installing 2GB of apps that so it for us?

On Windows you actually just need a C compiler to program for Windows in C and not the entire Visual Studio.

On GNU/Linux, you actually don't even have to install a compiler because 99% is already there.

So, I can create my C app with a text editor, then execute the commands. Both are the lightest and simplest steps to take. It is almost as simple as:
$ gcc hello.c -o hello
$ ./hello

Now, you might wonder how is that faster than clicking a button. The answer is: IDEs usually use their project management system to efficiently edit files and may bloat the source tree by adding efficient way to handle big projects (for example Code::Blocks sets up a Makefile). But, do we really need a Makefile or a complex project manager?

As a C programmer, I'm pretty sure I need two things: an algorithm and an editor to write the program that follows it.

This means that if I don't care about GUI (in which case light solutions like Glade do exist) I don't just need any of that bloatware.

I just need a text editor. Maybe with autocompletions to be faster, maybe with an integrated cli for running programs, maybe with macroes... but it has to be the faster medium between me and the terminal.

=== VIM

There are two widely known editors in this field that always are recommended: Vim and Emacs.

Before trying them I was a Windows user and mostly programmed with VS, Atom or Notepad++ (Notepadqq, Mouspad and Kate on GNU/Linux) so I was not getting why CTRL+S did not work on those editors as I expectes. Also I did not get why were those "weird" keybindings considered useful. Now have much more experience and I know where I was wrong: it was not a bad thing to program with GUI apps, but it was time-consuming, more than needed.

So I started to learn VIM and finally I got why I couldn't even insert text into the file buffer. Working with VIM I realized how simple it was to configure my environment efficiently: small programs, fast .vimrc edits the way I like it, even cli commands using a simple keys combination. I hated emacs. Oh, if I did. I hated it because I had found it very confusing, much more than vim did: how can a cli text editor occupy like 500MB ?! So I continued my vim way and customized themes, fonts, learnt commands and installed plugins... then I realized something.

I was turning a text editor into an IDE. I found myself searching google for "how to debug C program from inside vim" when I could really just :! gdb without issues.

The problem is that programmers are both lazy and crazy.

I mean, you can't feed up vim/neovim with plugins because it gets slow (in particular with python) and it's also not a very nice option when dealing with big projects (no, NERDTree doesn't help here).

But... how can I satisfy both laziness and craziness?!

You actually can.

=== GNU/EMACS

HEH.

There's much to be said. I could summarize it this way: EMACS is surely less responsive than VIM but hell if it works good. I was too lazy to read the tutorial, that's why I hated it! Now that I know how emacs works I feel like I can do anything. Its LISP environment is awesome, its plugins are awesome, its keybidnings are intuitive and not as painful as I thought (still I think I can do better with VIM, even if EMACS's windows management is just better) and also, I would have never thought it's so easy to manage.

I did this setup, which works both in the gui and the tty/terminal, in like 10 minutes:




Though being so nice, I admit that there's a problem related to the way it's designed: it only makes sense in a GNU environment. It just doesn't on Windows, and the reason is that it is designed to be the total commander of GNU: everything under control, everything ready to be used.

I'm not surprised anymore some poeple wants to run it as pid 0 on GNU/Linux systems.

Also it has the best documentation I have ever seen.

=== Conclusion

Emacs is just perfect, but I think VIM fits best for fast edits and small projects.

I can be way very efficient now that I'm aware of the power of the GNU.

 
#vim #emacs #codeblocks #c #netbeans #visualstudio

A vim user's story


=== PREFACE

There is lot to say about this and I'm not going to dig deeply into it. I want to say some words about the two most versatile editors/development-environments I have ever seen.

There's no big deal, but why would I prefer a huge, slow and maybe bloated IDE when all I need is just a te.. ahem, buffer editor?

=== IDEs VS EDITORS

To be precise: IDEs are not bad software. But they are very often too much for a user to eventually even considering learning all of the features, and Visual Studio makes no exception: though being quite user-friendly, almost perfect for a developer, and having a nice documentation, it lacks of readiness, speed, and very often intuitiveness when it comes to environment settings. On the other side, Code::Blocks is not very friendly and maybe quite ugly and old-looking, but it really does everything one would need: it has the best GDB integration I have ever seen, though it could do better with GUI design (where Visual Studio just dominates with its Blend) and customization. NetBeans instead is kind of an in-between. It's very nice, though it suffers from being based on Java (which isn't really an issue itself, but may lead to issue) and being somewhat unresponsive sometimes with packages and customizations (at least I noticed that there is something wrong loading custom themes and packages) which may be unpleasant when you realize the reason your project doesn't compile because of some weird java exceptions (uncommon, but happened).

=== GUI VS UX

Although the history told us mice are more user-friendly, there's to say that the fact that it is useful is a misconception. The reason is that we as #programmers just don't use it when programming. Well, unless for copy-pasting StackOverflow answers (nope really), which is anyway a bad practice. We should #RTFM, as they always say. And it's true. The reason is simple: the keyboard is immediate and the mouse needs first pointing then clicking. That's slower for us. We don't need to click on a green triangle button to run the app, we should CTRL+F5.

=== (Dis)Advantages of Text Editors

Obviously, I'll not consider notepad.exe. It's just wrong for programming. I'll compare Notepad++ with, say, Atom and Sublime. Let's start with Notepad++. It's kinda basic and looks wrong/ugly. It actually can do lots of things and could be compared to something like UEStudio: it just has everything... except speed. The issue with Notepad++ is that it is awesome as it is: filling it up with plugins will slow it down very easily. Though, it is nice because it has debugger integration (using plugins; could be better but works), file map, code folding, nice theming features (just for the editor though), folder browsing, FTP support (plugins), etc. I think you're getting the main idea: it is light and nice but man he needs to fed up to be nicer. And often it costs very much (from glitches due to unsupported postscript fonts to slowness), as it gets heavier... and heavier... and basically defeats its original purpose of being a text editor (its defaults actually do a lot more, like macroes, python scripting - though buggy, autocompletion - though dictionary-based, ...). Let's check Atom/Brackets. It's actually a bit bett... no. It's just ok. 6/10. Actually, 6-. That minus stands for "hell why". The reason is this: it has a quite nice GUI and generally I like the Squirrel system. But, to achieve this result, it went to the "dark side" and everything is bound to NodeJS. It wouldn't be a problem if it was just for the API/extensions. But they based Electron on Node, which means it's not a very fast environment.

Damn it, I say, why? Why do I need WPF or Node/Webkit to draw beautiful GUIs? Why is GTK+/CSS so painful?!

Well, that's where Sublime wins. If I'm not wrong, most of it was written in C++ and Python. It is anyway an in-between. It's extensible yeah, customizable and... "light" (actually mid, but still) ...and shareware. Damn it. It would have been perfect.

=== The Terminal VS The Window(s)

My ideal post would be a large desk with three monitors: code to the left, debugger/web-inspector on the right and the product on the center of the screen. Though, when reading code, our eyes actually scroll top to bottom and not left to right. That's just the way you write programs.

It would be nice as well to have anything working like that. We should not have "an IDE" that emulates what we already have. In fact, though simpler to install/use, IDEs often come with a bunchful of apps and libs or even custom building tools (nuget, tdm gcc, ...) that we would probably never use or even have the time to learn/configure. We just want our program to build & run. The best IDE is your own Operating System. Every operating system comes with a nice documentation with APIs (99% of the times in C) and tools we often don't really know about because they're hidden by the GUI. That's why the Terminal exists. It allows you to directly input the instructions. Wouldn't it be just faster to use them without installing 2GB of apps that so it for us?

On Windows you actually just need a C compiler to program for Windows in C and not the entire Visual Studio.

On GNU/Linux, you actually don't even have to install a compiler because 99% is already there.

So, I can create my C app with a text editor, then execute the commands. Both are the lightest and simplest steps to take. It is almost as simple as:
$ gcc hello.c -o hello
$ ./hello

Now, you might wonder how is that faster than clicking a button. The answer is: IDEs usually use their project management system to efficiently edit files and may bloat the source tree by adding efficient way to handle big projects (for example Code::Blocks sets up a Makefile). But, do we really need a Makefile or a complex project manager?

As a C programmer, I'm pretty sure I need two things: an algorithm and an editor to write the program that follows it.

This means that if I don't care about GUI (in which case light solutions like Glade do exist) I don't just need any of that bloatware.

I just need a text editor. Maybe with autocompletions to be faster, maybe with an integrated cli for running programs, maybe with macroes... but it has to be the faster medium between me and the terminal.

=== VIM

There are two widely known editors in this field that always are recommended: Vim and Emacs.

Before trying them I was a Windows user and mostly programmed with VS, Atom or Notepad++ (Notepadqq, Mouspad and Kate on GNU/Linux) so I was not getting why CTRL+S did not work on those editors as I expectes. Also I did not get why were those "weird" keybindings considered useful. Now have much more experience and I know where I was wrong: it was not a bad thing to program with GUI apps, but it was time-consuming, more than needed.

So I started to learn VIM and finally I got why I couldn't even insert text into the file buffer. Working with VIM I realized how simple it was to configure my environment efficiently: small programs, fast .vimrc edits the way I like it, even cli commands using a simple keys combination. I hated emacs. Oh, if I did. I hated it because I had found it very confusing, much more than vim did: how can a cli text editor occupy like 500MB ?! So I continued my vim way and customized themes, fonts, learnt commands and installed plugins... then I realized something.

I was turning a text editor into an IDE. I found myself searching google for "how to debug C program from inside vim" when I could really just :! gdb without issues.

The problem is that programmers are both lazy and crazy.

I mean, you can't feed up vim/neovim with plugins because it gets slow (in particular with python) and it's also not a very nice option when dealing with big projects (no, NERDTree doesn't help here).

But... how can I satisfy both laziness and craziness?!

You actually can.

=== GNU/EMACS

HEH.

There's much to be said. I could summarize it this way: EMACS is surely less responsive than VIM but hell if it works good. I was too lazy to read the tutorial, that's why I hated it! Now that I know how emacs works I feel like I can do anything. Its LISP environment is awesome, its plugins are awesome, its keybidnings are intuitive and not as painful as I thought (still I think I can do better with VIM, even if EMACS's windows management is just better) and also, I would have never thought it's so easy to manage.

I did this setup, which works both in the gui and the tty/terminal, in like 10 minutes:




Though being so nice, I admit that there's a problem related to the way it's designed: it only makes sense in a GNU environment. It just doesn't on Windows, and the reason is that it is designed to be the total commander of GNU: everything under control, everything ready to be used.

I'm not surprised anymore some poeple wants to run it as pid 0 on GNU/Linux systems.

Also it has the best documentation I have ever seen.

=== Conclusion

Emacs is just perfect, but I think VIM fits best for fast edits and small projects.

I can be way very efficient now that I'm aware of the power of the GNU.

 
In summary, it is possible to make C code run quickly but only by spending thousands of person-years building a sufficiently smart compiler—and even then, only if you violate some of the language rules. Compiler writers let C programmers pretend that they are writing code that is "close to the metal" but must then generate machine code that has very different behavior if they want C programmers to keep believing that they are using a fast language.
https://queue.acm.org/detail.cfm?id=3212479

A really interesting piece from AcmQueue. The headline first had me thinking "what nonsense is this?" But the article raises some very valid points and observations about the mismatch between the clean and simple abstract machine that C presents compared to how moderns hardware actually runs your code. Definitely a good read!

\#programming #c

 
So one thing seems to be clear: yes, it’s possible to write a non-trivial amount of C code that does something useful without going mad (and it’s even quite enjoyable I might add).
https://floooh.github.io/2018/06/02/one-year-of-c.html

Interesting writeup.

\#programming #c #c++

 
A Repository with 44 Years of Unix Evolution
The evolution of the Unix operating system is made available as a version-control repository, covering the period from its inception in 1972 as a five thousand line kernel, to 2015 as a widely-used 26 million line system.

http://www.dmst.aueb.gr/dds/pubs/conf/2015-MSR-Unix-History/html/Spi15c.html
https://github.com/dspinellis/unix-history-repo

#Unix #Operating-System #OS #University #California #Berkeley #BSD #FreeBSD #Bell-Labs #kernighan #ritchie #git #C #Caldera

 
A Repository with 44 Years of Unix Evolution
The evolution of the Unix operating system is made available as a version-control repository, covering the period from its inception in 1972 as a five thousand line kernel, to 2015 as a widely-used 26 million line system.

http://www.dmst.aueb.gr/dds/pubs/conf/2015-MSR-Unix-History/html/Spi15c.html
https://github.com/dspinellis/unix-history-repo

#Unix #Operating-System #OS #University #California #Berkeley #BSD #FreeBSD #Bell-Labs #kernighan #ritchie #git #C #Caldera

 
Brian Kernighan tell the story of the birth of grep (and mentions many interesting things along the way).
So very very limited computer resources. That meant that a lot of the software that was in the early days of Unix tended to be fairly simple and straightforward, and that reflected not only the relative "wimpiness" of the hardware, but also the personal taste of the people doing the work, primarily Ken Thompson and Dennis Ritchie.


#unix #c
#unix #c

 
@Gruppo Linux Como
♲ moeeee@f2.der.moe:
Friclicli: Friendica CLI client
@Friendica Developers

I started to work on a CLI client for Friendica named friclicli. At the moment I'm working on the foundation of the client: A C library (called libfriclient) with functions representing Friendica API routes (one function per route). The client will use a curses interface (probably ncurses). To make requests to the Friendica API the libcurl library will be used. JSON data will be processed using the cJSON library.

The source code repository is here: https://gitlab.com/ncc1988/friclicli

The client will be programmed in C and licensed under the GPLv3+.

#Friendica #Client #CLI #C
[l]

 
@Gruppo Linux Como
Friclicli: Friendica CLI client
@Friendica Developers

I started to work on a CLI client for Friendica named friclicli. At the moment I'm working on the foundation of the client: A C library (called libfriclient) with functions representing Friendica API routes (one function per route). The client will use a curses interface (probably ncurses). To make requests to the Friendica API the libcurl library will be used. JSON data will be processed using the cJSON library.

The source code repository is here: https://gitlab.com/ncc1988/friclicli

The client will be programmed in C and licensed under the GPLv3+.

#Friendica #Client #CLI #C

 

Programmer en C



#mooc #c #programming #fun

 
So you think you know C?
A lot of programmers claim they know C. Well, it has the most famous syntax, it has been there for 44 years, and it’s not cluttered with obscure features. It’s easy!

Or so you thought...

#programming #c

 
Dennis Ritchie Day

...was obviously yesterday, but still a nice read and tribute to a man that has helped shape a lot of the things that made the internet possible; The C programming language, and the UNIX operating system.

https://www.oreilly.com/ideas/dennis-ritchie-day

#programming #c #unix #DennisRichieDay