[Splashy-devel] Splashy time. when time resurrects

Luis M Luis M <lemsx1@gmail.com>
Fri, 27 May 2005 01:03:51 -0400


On 5/24/05, Vincenzo Ampolo <vincenzo.ampolo@gmail.com> wrote:
> On Tue, 2005-05-24 at 12:40 -0400, Luis M wrote:
> > take into account that the C implementation is somewhat more complete
> > than the C++ version right now, with the minor difference that the C++
> > version reads vcs1 buffer (in RAM), which doesn't really add much time
> > to the boot process (this is done in miliseconds).
> >
> > What makes the C version "slower" than C++ right now is the sleep
> > calls either in C or in rc init scripts. I'll be removing this in the
> > next few days so that you can redo your tests.
>=20
> It depends to what we consider for complete...
> Complete is when a program, a service or etc, works without any visible
> error.

agree

splashy (c version) works perfectly fine in my system. no errors. no
anything. i believe it works the same way for otavio and others in
#splashy. does this mean that the program is perfect? i'm sure it
isn't and i'm sure bugs will be found as we go along. eventually
splashy will be complete. we will just keep releasing versions fast
until we reach a steady level of stability.

> Look to our programs:
> C version have about 2*number_of_the_lines_of_c++_code and it does not
> recognize errors (that as you know could be found only by looking on
> vcs1 because we cannot and don't want to modify /etc/rc) and it have a
> problem in the shutdown: more people say that see one seconds the boot
> messages before X is running.

you know that doesn't make any sense. take libdirectfb ++dfb and all
the other libraries you use for the c++ version, count the number of
lines, then add the number of lines to the source code of splashy c++.
now for the C version all you need to do is add libdirectfb source
code, plus glib, plus splashy itself. in the end, i'm sure splashy (c)
has a lot less lines of code. lines of code doesn't mean anything
anyway. for the C++ version to work you needed to pass strings from
the initrc and then read them in memory to set the progressbar. the C
version does the same using a fifo (named pipe) which is a lot more
efficient. the c version also forks properly to handle keyboard
events, fifo events and as of today, it handles errors from the vcs1
buffer as well. read below...

> In the other hand, C++ version is there, it just work with few lines of
> code, C code has not all the features of C++ code (error searching) and
> for now it works better.
>=20

i did the error searching code in 20 min using regexec(). which means
that i go through the buffer once to fine 3 or more strings. don't
take my word for it since i don't know exactly what engine the POSIX
regexec() calls use (DFA, NFA or POSIX NFA), all of which have their
advantanges and disadvantages. but i'm sure the code will continue to
evolve and become faster and faster until we hit some limit.

> About handling text, we know that if is not a work that will be done in
> milliseconds, operations on strings need time. And remember we need
> mainly a text reader since we wanna implement the verbose mode.
>=20

i have already done this. as i said before, i use regular expressions
to search for a subset of patters. I'll add some beauty to splashy so
that hitting F2/ESC toggles the verbose mode and back to splashy... i
didn't want to code it all today just because i wanted to get the text
parser for the vcs1 vt done. however, that's in my plans.

> Don't think this is an attack to your and my work. I'll wait until
> sleep() are dropped, i can't modify source since my account is still
> unavailable and yes, i've mailed the alioth admin.
>=20

i look through the code and read the man pages for usleep(). there
were no more sleep() calls anywhere and the init rc's don't have any
sleep calls either. i noticed the usleep() is a deprecated function as
it doesn't handle posix schedules correctly. so, i switch it to
nanosleep(). i'll experiment with SCHED_FIFO calls (at least on Linux)
which causes FIFO events to preempt the kernel and give priority to
the process running under this special scheduling.

for now, run your tests again against the version of splashy in
http://splashy.alioth.debian.org/debian and let us know what happened.


> ON 28 i'll switch, in the meantime i'm working on animations on the C++
> code, i tried to do the text parser in c but i've a lot of difficulties.

As we discussed in IRC, i talked to the alioth people to have your
account fixed. I'm not sure if they have done that yet, but at least
we now know who to talk with. (confirmed. your account $HOME has been
created in alitoh/haydn/costa).

You seem not convince by the splashy C version, even though you know
that the number of dependencies needed to run the C++ version doesn't
make sense for what the program should be doing. Look at blotch and
you will see what I mean. If i could drop the XML parser and switch
the config file to .ini, we could probably get rid of glib as a
dependencie to splashy. But, glib is so elegant and makes life so much
simpler, I don't see a need. Note that the C++ version also depends on
glib (c++ wrapper) (glib::ustring is needed by ++dfb). which means
that in order to run the C++ version you need:
=20
* glib and glib C++ bindings
* libdirectfb and ++dfb (which is the C++ bindings for libdirectfb)
* xmlpp ? (don't recall the correct name)
* etc...

The C version of splashy needs:

* glib
* libdirectfb

and that's it.

--=20
----)(-----=20
Luis M
System Administrator
Kiskeyix.org=20

"We think basically you watch television to turn your brain off, and
you work on your computer when you want to turn your brain on" --
Steve Jobs in an interview for MacWorld Magazine 2004-Feb

No .doc: http://www.fsf.org/philosophy/no-word-attachments.es.html