Skip to main content.

Wednesday, April 03, 2013




Too precious not to incorporate it...

Saturday, March 26, 2011

Decent programmers and good programmers are different in the way they are able to communicate their ideas. Either to others, to themselves and lastly to the machine they are working with.

I found this article enlightening on the topic, and it doesn't just "explain" the fact. It also gives a nice, nifty suggestion.

A must read for any programmer. And not just for them.

Wednesday, February 23, 2011

To find a string in the files under a directory:


for file in `find . `; do if [ -n "`grep "mysql" $file`" ]; then echo $file; fi; done


Tuesday, November 17, 2009

This comments in an intricate code I am in charge to check really saved my day


TopicLock itLT = LockTopic (Tpc); // lock topic
LockCache(); // lock cache


... in the sense that I am gonna laugh for the rest of the day.

Wednesday, October 14, 2009


For a programmer, tomorrow is the next time you turn on your PC.

Saturday, July 25, 2009

I just discovered that Sun Studio has a strange idea of "optimization" when it comes to copying structures by value.

Thursday, July 09, 2009


--- What's the sound of a computer being shut down in a desert office?


Saturday, July 04, 2009

GD2 is a very cute library, and a must have for site developers (very used in PHP and perl....). As it is a very clean C library, with a very object-oriented spirit (despite it's plain C), It's the first target for the new Falcon automatic binding generator. The only problem is that it uses ANSI C FILE* streams to read and save images. It has actually also the ability to load from buffers, but providing a direct mapping is definitely a plus.

On Unices, that's not a problem. dup() + fdopen() provide a direct way to form an ANSI C FILE stream out of the system stream ID which I use in Falcon::Streams. On windows, I use System HANDLE (CreateHandle &c) to drive the Falcon::Streams.

But I found this snippet:


#include
#include
#include

HANDLE hFile = CreateFile(...);
int handle = _open_osfhandle((LONG)hFile, _mode);
FILE* f = fdopen(handle, szMode);


With this, I can virtualize a function down in the Stream falcon class returning an integer system stream or raising an error if the stream isn't mapping a system file (i.e. streams can be net-bound or memory bound). The GD binding will have to wait the next version of falcon to use Stream oriented load/save functions, but I should release that next version quite soon.

Friday, June 19, 2009

Falcon 0.9.2 is ready to be released, so I am exploring what to do next. Our plan was that of starting optimization since the first official release of Falcon, and we can really get big improvements in that area.

With this in mind, I started to search for a portable way to perform atomic operations.
I found some very interesting resources. With just this information and good inline wrappers, it is possible for Falcon engine to expose a cross platform atomic API which can be extremely good for multithreading. Many MT-sensible operations, as the GC block allocation and scan loops, has been designed with atomic operations in mind (in the sense that although implemented with mutexes, they are based on structures that are thought for atomic operations), and so using atomic operations there can be both simple and rewarding.

Some resources we'll be using:
A nice article on using GCC 4.1 portable atomic primitives.
GCC Docs on that.
MacOSX multithreading guide, with native CAS support operations.
MS-Windows Interlocked SDK
On SUN, there's a mysterious __rwstd::Interlocked* function set that I will investigate more.
Also, Sun C++ supports __thread keyword as gcc, which is much more efficient than functions accessing the thread local stack as TlsSetValue or posix_set_specific.

Sunday, May 24, 2009

In the end, hoping to have it out by this week-end was a bit optimistic.

I still need to finish the new faldoc to produce the new source-level documentation, and also to find a decent ramping function for the default GC algorithm.

However, I am quite positive. The RC seems quite stable, and is working blissfully in our production environment. I just found a couple of glitches while working with faldoc (something was wrong with error detection and extra message of raised errors), so the thing must be investigated a bit.

On the bright side, this is giving us the time to complete a full code check round (just nailed a very idiotic problem in string.find()), and to polish a couple of uncovered details. For example, I just added a glamorous "brigade" function, working similarly to cascade and meant to put common functional code at work through cooperation sequences.

Saturday, November 15, 2008

Look at this code:

GarbageString *str = new GarbageString( vm, (const wchar_t *) Sys::dynlib_voidp_call( fa->m_fAddress, bufpos, bufsize ), -1 );
vm->retval( str );

It sounds equivalent to this:

const wchar_t *ws = (const wchar_t *) Sys::dynlib_voidp_call( fa->m_fAddress, bufpos, bufsize )
GarbageString *str = new GarbageString( vm, ws, -1 );
vm->retval( str );

But for Visual C 2005 it's not so equivalent. In release build the second one crashes; the reason is in the fact that dynlib_voidp_call() mangles with some registers via assembly, apparently, but a wise compiler should not rely on register persistence across foreign function calls. Also, the problem is in the ws variable. It seems its value gets lost between the return from dynlib_voidp_call and the call on the next line. Be warned...

Wednesday, November 05, 2008

From today's chat in Blastwave.org (Sun OS distro) official channel.

<evocallaghan> World is d00med !
<jonnymind> Or maybe, world is unrealized.
<jonnymind> Ya know, Unreal is more popular here in Europe.
<cypromis> witcher
<cypromis> the world is witcherised
<cypromis> lol
<cypromis> and everybody is moving to second life anyway
<cypromis> Life 2.0
<cypromis> and that before Life 1.0 even reached alpha stage

Sunday, September 09, 2007

Ubuntu Feisty Fawn and the related Kubuntu (Ubuntu + KDE) works neatly with UIM, which is superior to SCIM and SKIM in many aspects. However, a couple of configuration problems gave me some headache. The problem is present also in the new upcoming Gupsy. As I need Japanese (and possibly Chinese and Korean) input system for my work, here's how I did.

Saturday, September 01, 2007

I've been searching for days for a way to create RPM packages without the need of being root (that is, system administrator).
Normally, RPM builds packages by searching source files and unpacking them in the /usr tree; to put source files there, you have to be administrator, and that was the problem.

I wanted to have all the RPM build system in another place, like i.e. /home/myself/rpm/..., but tutorials and directions on the net on how to do that was sloppy, or outdated, or not working, or the three of them. I understood that there was the need to change the _topdir variable that is defined in the RPM system. I tried to set it to my preferred directory in the spec, but it didn't work; also, using personalized rpmrc file (in /etc, in my home as .rpmrc, as a custom file using command line switches to load it) but I kept having errors (something about _topdir used as an invalid token).

Finally, I found the little code that does the magic in a RedHat mailing list archive:

$ export RPM_TOP_DIR=/your/preferred/directory
$ rpmbuild --define "_topdir $RPM_TOP_DIR" -ba <specfile>

This works great. As a side note, this small code can create the tree that rpmbuild will use:

mkdir -p \
$RPM_TOP_DIR/BUILD\
$RPM_TOP_DIR/RPMS\
$RPM_TOP_DIR/i386\
$RPM_TOP_DIR/SOURCES\
$RPM_TOP_DIR/SPECS\
$RPM_TOP_DIR/SRPMS

Wednesday, July 18, 2007

My site, as well as some fellow sites as .i.e. Falcon has been more down than up this days. This due to the pasttime of a cute cracker that thought that was quite funny to get down an harmless server.

And the worst thing is that I know quite a bit about Linux, servers, security and stuff like that.

The point is that I have a relatively cheap virtual hosting, and the software up there was a bit... uhm... outdated. Fedora Core 2, to start with. Also, my host didn't want ppl on his virtual servers to mangle with kernels, distros and so on. Long story short, all the ppl in this hosting is living on a piece of crap with software that was already easy to break 2 years ago.

I put up a bit of dutch tape here and there, i.e. writing little scripts that would restore services that were killed with a DoS, and that recorded via ngrep the remote attacker IP and the timestamp. That worked, and kept idiots at bay for some time (and also caused a couple of them to be thrown out of the net by theirs provider), but it couldn't last for long. When someone has found that we were running a kernel version 2.6.9/11, that could be DoSsed EVEN with a well malformed CPIP packet, the machine was hung for good.

So I decided to lure my ISP by with gentle words and I upgraded the system to something barely decent.

Figure what? --- they was probably happy someone tried it on their virtual servers, so they can apply some security patch around.