Name: Oleg Verych
Member since: 2005-06-05 16:07:03
Last Login: 2008-05-19 19:56:13



  I've found twisted HTMLizing more user friendly here:
(yes, my homepage is ftp, nntp+smtp+ftp actually)
  Hope this is not a BottinLOG for you and the Internet.
  Kudos to Jeremy!
  Now i see, what open source and free software is. Let me
share my thought and experience. I sure must bump my
certification level here.
  FYI, 5 years of Linux as only running PC OS, last year
without X(graphic interface).

[first Note]
  It's almost unreal ... to have so many people next to you,
who you know only by software, they wrote. Hi, people ! How
are you doing !?  

Recent blog entries by olecom

User-Agent: jed (x86_64-pc-linux-glibc-debian)

Value of syntax highlighting for programming in text editors is hard to overestimate. I recall one my buddy, a keen school olympic competitor on programming, who said, that move from Borland Pascal 5 to 6 and 7 was a great thing because of highlighting.

Many syntax and logic errors just popped up right before one's eyes. Monotony strains. OTOH, Reading the book isn't like programming. Programming requires great thinking efforts and no distractions. Those LISP coders also track those parenthesis and think this is a cool thing.

So, i didn't see something quite comprehensive even in the great Emacs. Unreadable regexs, reinventing parsing, small efficiency wrt CPU burning. Not saying about *no* highlighting of regexs themselves, non stupid highlight of `sh` scripts, `sed`, etc.

Maybe in 70x, where all "modern UNIX/Linux userspace software" stuck, there was no computation and brain power, money and programmer's imagination to implement that in a rational way.

The Right Thing(R) IMHO is to have any parser `sh`, `sed`, `awk`, `gcc` etc. (yea, stupid XML!) implementing interface for highlighting of the input. Isn't that those parsers know and do all their syntax handling?

Yet more than decade x86 clones in terminal emulators are waiting infinite microseconds between user's key presses...

sed 'sed && sh + olecom = love' << ''
 #oo'L O
<___=E M
5 Apr 2008 (updated 7 Apr 2008 at 21:29 UTC) »

From: Oleg Verych <!gmane?>
Subject: Back to text and graphic terminals.
Organization: Palacky University in Olomouc, experimental
physics department.
Mail-Copies-To: never
User-Agent: slrn + jed (x86_64-pc-linux-glibc-debian)
Keywords: text-mode, graphics, video, ethernet

Hallo. I'd like to ask about a graphical device set for simple
PC usage (tell me, please, if this place is wrong).

My PC is a laptop 95% of the time for nearly 3 years.

pure text mode (Linux):
 * gmane news reading, all those mailing lists one place (slrn)
 * programming (emacs)
 * web browsing (lynx)
 * watching video

graphic mode (MS Windows mostly, because X sucks):
 * pictures
 * pdf (while partially i can screen it by `pdf2text` + some
 * djvu (so many books appeared)
 * web browser (with lot more useless traffic, flash  and

In the text-mode i realized, that it can be much more
interesting and productive:

 * more colors
 * more char. attributes
 * character "shaders" (hardware and software)
 * hardware windowing system with enough memory

Framebuffer text console in Linux is known to be very slow and unpleasant. Text terminal emulator in Linux and in X11 as well are just deep in 70s, but with transparency. Particular in Linux kernel vt102-like emulator wasn't developed or optimized for quite some time.

I believe, i have latency problems (music playing) when i page or output text in ssh remote console (i.e. network can send so much text quickly to process byte by byte in kernel's terminal emulator, that kernel gets unresponsive).

Software compatibility and legacy aside, proprietary UNIX zoo is dead, open source is yet to see something like Turbo Vision kind of look and feel.

So, i'd like to see a device (or set) with features:

* text terminal-like interface in text mode, i.e. stream of characters to the graphics hardware, but improved and with windowing system support

* framebuffer (graphics: dynamic video, static pictures) is switched on only on demand (saving power, less EMI noise).

* text/graphic processor/uC + small OS (text windowing, buffering, smart to do stupid job, etc.) is inside of display.

* interface to PC is Ethernet (or equivalent).

Thanks for you attention.

sed 'sed && sh + olecom = love' << ''
 #oo'L O
<___=E M

A view: linux RAW net, raw sockets.
A fast communication for small devices without overhead of
IP, TCP, UDP. ______
1 Apr 2008 (updated 2 Apr 2008 at 22:15 UTC) »

sed 'sed, shell and Oleg'  <<  ''
the most selfish and cool sed script

sed 'sed, sh and Verych Oleg' << '' the most selfish and cool sed scrip2
sed 'sed + olecom = love' << '' the most selfish and cool sed scrip3
sed 'selfish and cool sed script by Oleg' << '' -- -o--=O`C #oo'L O <___=E M

More about text processing in open source programming:
It includes heavy
`shell` and `sed` stuff.

About stupid ttys and ergonomic user interface later.

3 Feb 2008 (updated 6 Feb 2008 at 05:20 UTC) »

| [1]

Viewing this in the browser window can scare anybody. That's why noone so far read whole links in prev. post. But let's put away the fact, that open source browser doesn't support syntax highlighting of the most basic thing -- shell language and UNIX tools, available for 20-30 years.


Here is the main point of the kernel developmnet: understanding, knowledge, ways of debugging. Starting point is assembly.

Text-processing assembly language is sed. Userspace assembly is shell (mainly POSIX, but not ksh or bash). Both are in very-very upsetting state.

|[3] 3492 bytes
|[4] 5132 bytes
|I've came up with this one:
Looking on 1024 bytes of this one, it is clear how syntax highlighting is important in understanding and developing of BRE+sed+shell tools.

So, what is the progress?

First, shell language is very complicated in terms of parsing. I don't know if any academia compliler theory professors have actually looked at this one. Kenneth Almquist, who wrote ash, was from EDU domain, but he have done a practical implementation.

I must edit this post, to say: "What an utter crap!" An Introduction to ANTLR: A parser toolkit for problems large and small

Recursive nesting of subshells in ``,$(), quoting are main features. Even using them is not such trivial thing at all. But i saw trivial scripting isn't that easy for some kernel developers(script in

#!/bin/sh -e

# usage: mkmsg [branch] [output text file]

test "$1" && BRANCH=$1 || { echo "Empty BRANCH,
exit 1; }

  if test  "$2"
then exec >"$2"
else : "Print to stdout"

# should work much better than 2 fork()s

echo "Please pull from '$BRANCH' branch of$REPO.git

to receive the following updates:
git diff -M --stat --summary master..$BRANCH
git log --no-merges master..$BRANCH | git shortlog
git diff master..$BRANCH

So, with this one it is even possible to use script interactively and/or in the pipe chain to mail stdout directly, as addition to better, i.e. efficient, usage of the system and the kernel...

Second. While trying to implement highlighting i've discovered, that kernel doesn't apply background attribute to the tab symbol. I.e. tabs are always black, no matter what background color is there. This led me to more deep understanding of the tty processing, mainly tabstops (theory can be found in UNIX Power Tools).

Problem can be solved by converting tabs to spaces. But knowing, what tabstops are, it's not such trivial thing to do. In i've used `expand` UNIX tool. Now i wanted to do it in sed.

Andreas Schwab is making very interesting, mostly one-line comments in LKML (i even checked old archives of 90s). Once he pointed out, that i wrongly explained "\{\}" BRE construction. While i knew what it means, i really didn't used them at all. But after that occasion i sat down and did read+exercise. This helped me to do my version of `expand`.

Funny, that this[0] turned to be even more efficient, that one from recognised sed guru Greg Ubben[1].


4 ("3 basic" + "1 speed optimization") op-lines, 2 numbers, no loops


6 (5 + 1) op-lines, 2 numbers, loop

@(#)14apr89/31aug01 expand.sed by Greg Ubben

means, that in more than 10 years there was no better solution, heh. Also coloring is a bit broken: openning "\(" and closing "\)" do not match.

I hope, i have no errors there. Checking is left to the reader.

Thus, progress on such basic thing is kind of unexpected. After understanding of achievement, i was depressed. More depression followed, when i've discovered original ash/atty sources.

-- comming next --
shell, tty, text user interface
 #oo'L O
<___=E M

4 older entries...


olecom certified others as follows:

  • olecom certified olecom as Apprentice
  • olecom certified raph as Master
  • olecom certified freetype as Master
  • olecom certified cinamod as Master

Others have certified olecom as follows:

  • olecom certified olecom as Apprentice
  • fzort certified olecom as Apprentice
  • wingo certified olecom as Apprentice

[ Certification disabled because you're not logged in. ]

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!

Share this page