Comments for axelio

Comment on Easy acronyms generation by vincenzo

vincenzo — Fri, 06 Feb 2009 20:20:55 +0000

This is ok for old documents,
for the new ones, I suggest to use the acronym latex
package while writing.

Comment on Screen Sharing with Mac OS X and GNU/Linux by GerdH

GerdH — Sat, 20 Dec 2008 21:35:24 +0000

Thanks for posting this! Once I set “VNC viewers may control screen with password”, I can use both UltraVNC and TightVNC to connect to Leopard from a Windows XP machine.

Without this setting:

TightVNC returned “Server did not offer supported security type”
UltraVNC returned “Incompatible Versions”
____
Gerd

Comment on Screen Sharing with Mac OS X and GNU/Linux by grant

grant — Tue, 28 Oct 2008 12:01:57 +0000

thanks for this, gonna set it up now

Comment on Screen Sharing with Mac OS X and GNU/Linux by Miquel

Miquel — Tue, 14 Oct 2008 23:25:47 +0000

Matt… there is a way to solve that.

I had the same problem trying to use tightvnc on my ubuntu’s box.

Use OSXVnc (you can find it here) http://sourceforge.net/projects/osxvnc/ it works as a vnc server in a different port (you can define it, starting at 5901) and you’re not going to have any issues, if you try to connect to it using different OSes.

Kind regards.

Miquel

Comment on Screen Sharing with Mac OS X and GNU/Linux by savaged

savaged — Thu, 04 Sep 2008 22:35:59 +0000

Great article, thanks for posting your findings. I got this working first time on Ubuntu Hardy Heron and Mac Leopard, following the above. Thanks again.

Comment on Screen Sharing with Mac OS X and GNU/Linux by Matt

Matt — Thu, 21 Aug 2008 21:48:59 +0000

This doesn’t seem to work with OSX 10.5. I get this message, using TightVnc 1.3.9:

$ ./vncviewer
Connected to RFB server, using protocol version 3.8
Server did not offer supported security type

Comment on Helper macros for Check by Olmo Maldonado

Olmo Maldonado — Wed, 19 Mar 2008 06:55:37 +0000

Excellent article. You’ve covered two topics I was interested in reading about: Unit Testing and variadic macros.

Comment on Code size optimizations by Lluís

Lluís — Fri, 28 Sep 2007 19:50:08 +0000

Another best practice to reduce size is implement the code with a best compromise in the procedural abstraction with code motion. Implement a hard procedural abstraction has penalitzation in size with unnecessary procedure calls. This issue can be solved apply another algorithm, inlining the functions ( judiciously , of course ) or applying code motion techniques for example.

In another side, in embedded systems where, as you explain, size is to critical, the parameterization code technique could be useful. That is, if we have these two code fragments :

// … //
for (int i = 0; i < 10; ++i)
{
v[i] = 0;
}

and
for (int j = 0; j < 200; ++j)
{
a[j] = 0xFF;
}

then, we can replace it with a new procedure where variants are the parameters :

void
loop (int *vector, int size, int value)
{
for (int i = 0; i < size; ++j)
{
vector[j] = value;
}
}

This is a trivial example, but basically the strategy is to use code motion to generate code-blocks with the same semantic and after, apply parameterization.

Comment on Code size optimizations by aleix

aleix — Fri, 28 Sep 2007 10:10:57 +0000

Wow! This might be something really scary to look at.

Thanks!

Comment on Code size optimizations by bi

bi — Fri, 28 Sep 2007 09:53:10 +0000

Re splitting along functions: dev86’s libc uses this weird trick where a .c file contains several functions, but each function is surrounded with an #ifdef…#endif, and several separate .o files are compiled from this single .c file by selectively turning on each of the macros referenced in the .c file.