[dev] utf8 insertion tool

2019-03-26 Thread Calvin Morrison
hi guys,

one thing missing on my setup forever was an easy way to do utf8
insertion on X11. anyway i had a think abouit it and the script turned
out to be easy enough if you borrow /lib/keyboard from 9front and use
dmenu.

I have the below shitty oneliner tagged to Alt-U in my i3 bindings,
then type in what you want and xdotool will insert it for you

calvin@bison:~$ cat ~/bin/utf8
#!/usr/bin/rc

line=`{sed -e 's,\t, ,g' /lib/keyboard | dmenu -l 10 }
code=`{echo $line | awk '{print $1}'}
if(! ~ $code '') {
  xdotool key U$code
}

only thing i don't like is that drw.c doesn't implement anything to
deal with the ^I control character so, i'm using sed in the pipeline
to just turn it into a space, otherwise it renders weird.

Whatever, maybe someone will find it useful. screen shot attached

Calvin


Re: [dev] Learn C

2019-03-26 Thread sylvain . bertrand
On Sun, Mar 24, 2019 at 10:28:35AM +0100, Thuban wrote:
> Hi,
> I want to learn C. I mean, sane C.
> What i read before was based on big IDE such as codeblocks. So, I don't
> know how to write Makefiles from scratch. (just an example).
> As an example, I found gobyexample [1] great. But it's go.
> Any reading advice?


Don't bother with makefiles yet, just use plain simple shell scripts.
sane C = simple C.

C has already a syntax way too rich and flexible. Most of the
linux coding guidelines is nice.

* do not use enum (hard rule)
* do not use typedef (hard rule)
* declare your variables at the beginning of a block (c99 allows declarations a
  bit everywhere, bad). personnally I try to keep my variables declared first, 
then
  the variables with assignment, because it's actually code (presume C
  initializers are code).
* organise your code to _kind of_
   * avoid more than 3 depth levels in a function
   * avoid too many variables in a function
   * keep roughly 80 columns code in order to have several readable columns on
 a "standard screen".
* goto is appropriate in some cases
* I personnaly add a macro #define loop for(;;) and use only 1 loop
  statement (hard rule)
* try to stick to lower case identifiers
* use sized types: u8 u16 i64 float32 etc... you can use the C
  preprocessor to fix that, but in some case, as a good tradeof (for instance in
  "object oriented C code"), add a suffix to your type (u8_t, struct 
my_class_t), then
  for instance you can nest structs, struct base_type_t base_type.
* try to avoid as much as possible dependencies: Keep in mind the "technical
  cost" of your code, an optimizing compiler toolchain is extremely expensive
  (and all are turning into c++ garbage)
* to help you "calibrate", read  the "unix philosophies" out there (cf 
wikipedia).
* complex code is not cool and does not make you smart: "The notion of
  'intricate and beautiful complexities' is almost an oxymoron" (cf all c++
   code and similar)
* as a tradeof to avoid becoming a strong type extremist: view primitive
  variables as CPU hardware registers, so be carefull with your type casting.
* always presume you will have to write a C preprocessor and compiler
* keep your canonical SDK idiotic and simple
* monkey patching is extremely bad (aka "corporate code")

I certainly forget a ton of things, and tradeofs have to be done case by
case. Nothing is set in stone. We all do mistakes.

Keep in mind that we are all different, then we will draw "lines" not in the
same way, but there is an absolute value which is true for all: the "technical
cost" of your code and your deps (SDKs included).

-- 
Sylvain



Re: [dev] Learn C

2019-03-26 Thread Quentin Rameau
> * do not use enum (hard rule)
> * do not use typedef (hard rule)
> * use sized types: u8 u16 i64 float32 etc... you can use the C
>   preprocessor to fix that, but in some case, as a good tradeof (for instance 
> in
>   "object oriented C code"), add a suffix to your type (u8_t, struct 
> my_class_t), then
>   for instance you can nest structs, struct base_type_t base_type.
> * I personnaly add a macro #define loop for(;;) and use only 1 loop
>   statement (hard rule)

:/



Re: [dev] Learn C

2019-03-26 Thread sylvain . bertrand
On Tue, Mar 26, 2019 at 08:37:18PM +0100, Quentin Rameau wrote:
> > * do not use enum (hard rule)
> > * do not use typedef (hard rule)
> > * use sized types: u8 u16 i64 float32 etc... you can use the C
> >   preprocessor to fix that, but in some case, as a good tradeof (for 
> > instance in
> >   "object oriented C code"), add a suffix to your type (u8_t, struct 
> > my_class_t), then
> >   for instance you can nest structs, struct base_type_t base_type.
> > * I personnaly add a macro #define loop for(;;) and use only 1 loop
> >   statement (hard rule)
> 
> :/

Hard thruth



Re: [dev] Learn C

2019-03-26 Thread Kurt Van Dijck
I agree with most of your arguments

> * use sized types: u8 u16 i64 float32 etc... you can use the C
>   preprocessor to fix that, but in some case, as a good tradeof (for instance 
> in
>   "object oriented C code"), add a suffix to your type (u8_t, struct 
> my_class_t), then
>   for instance you can nest structs, struct base_type_t base_type.

Why not use uint8_t etc. from stdint.h?

Kurt



Re: [dev] Learn C

2019-03-26 Thread sylvain . bertrand
On Tue, Mar 26, 2019 at 08:56:07PM +0100, Kurt Van Dijck wrote:
> I agree with most of your arguments
> 
> > * use sized types: u8 u16 i64 float32 etc... you can use the C
> >   preprocessor to fix that, but in some case, as a good tradeof (for 
> > instance in
> >   "object oriented C code"), add a suffix to your type (u8_t, struct 
> > my_class_t), then
> >   for instance you can nest structs, struct base_type_t base_type.
> 
> Why not use uint8_t etc. from stdint.h?

Shorter