World: r3wp

in case of 'text selection' you can call SHOW only when the selection 
really changes..this is not for every mouse event

Pekr, I hope you are just joking with your speculation that MS WORD 
is using always one big chunk of the whole text and redraws the whole 
window for every  text processing event ;)

jo, je to detail...  jak se spravne pouziva ten caret-to-offset, 
aby to nehodilo error, kdyz kliknes mimo text?

ech :/

Oldes, of course Rebol comunity will invite any good optimization 
of the hostkit code that will lead at least for a few percent of 
speedup. You can be useful here.

Cyphre - what was the result of your acceleration experiment (not 
talking JITTer here)? I do remember it provided some further speed-up 
to some folks here (not to me on intel chipset). Will it  be added 
to hostkit by default, if it works under all Windows versions?

There are no plans for the accerated graphics yet. It's early concept 
but it is highly portable and will work on all platforms that has 
OpenGL support.

nice ... even some xy percent speed-up is worth it :-) What I am 
interested in is the smooth, not CPU hungry scrolling, not sure if 
OGL can help here though :-)

Also there is significant amount of testing/work that needs to be 
done and my time is limited. But I personally plan to get back to 
it during this year but have no high priority for that unless R3 
will be ported to some other interesting devices (game consoles, 
smartphones, tablets etc.).

CPU are dead in they actual from ... the futur is APU and it would 
be crazy not to adapt VID to feet that new specication especially 
for small devices (smart phones, tablets, notebooks etc ..).being 
AMD being APPLE being Intel or ARM they all look to reduce latency 
in their device by integrating high level GPU into their CPUs.

Integrating gfx into CPU is just that - integration of gfx into CPU 
- it has nothing in common with the proach to create SW, no? :-)

hum pekr so why IE and other MS software like powerpoint now integrate 
a Hardware acceleration capabilities properly brough by sandybridge 
and fusion APU.

Powerpoint integrate acceleration for ages ....

not that kind

http://www.youtube.com/watch?v=qsfwx5Tv4fo

in this video Pekr as a matter of  fact powerpoint 2010 has hardware 
acceleration and not the 2007 ...

whatever - but it is not related to APU, as you tried to suggest. 
It is just that now most of PC configs out-there, even with Intel 
gfx chipsets, will be hw accelerated ... which is a good thing ... 
except the REBOL not supporting hw acceleration :-)

Hardware acceleration of graphics is a good idea. The APU thing cuts 
down on the posibilities of that because the graphics processors 
tend to be on the scale of integrated graphics, due to the size, 
but that won't be the case for long, and graphics acceleration is 
still a good idea.

BrianH thank you :) ... As a side note GDI is deprecated and abandonned 
massively on hardware level... but Gfx libs like Cairo support directX 
rendering hardware accelaration or OpenGL depending the plateform 
... I'm not quite the super exper on the topic. But i know that's 
a tendency to move back graphical content to the GPU  and not only 
when it comes to 3D rendering ...

(This should be in the !REBOL3 Graphics group, where it will b e 
useful)

If you give an index to RL_GET_STRING on a series of single bytes, 
it will return an address computed as if the items are double bytes

I'd guess RL_GET_STRING is currently hardcoded to always count in 
double bytes

RL_GET_STRING returns number > 0 if the source is unicode and < 0 
if ascii

at least on windows

Yes, that's not the issue. I'm inversing the length because the series 
is always a BINARY

The issue is that it computes it as items of double bytes instead 
of one byte

The address, that is. The length is correct

So that's why I didn't notice the corruption, because all the length 
calculations are correct, but the wrong data is passed

Pushed a few of my straight-forward A110 patches, mostly about mildly 
re-structuring the build. to https://github.com/earl/R3A110.

Here's a chronological list of commit summaries:

8ed0b68 Rename about.txt to README
45bf64d Temporarily remove unmaintained build projects
f7237b4 Move libs to platform-specific subdirectories
f8eb7e6 Move makefile to platform-specific subdirectory
5072f47 Remove reb-to.h and pass TO_<target> as compiler flag
2401c40 Minor makefile cleanups
333edad Linux: fix bug#1658: link binaries against libdl
3f1fd7d Linux: improve linkage to libr3
635f228 Win32: add makefile

4f57323 Win32: raise the stack size limit in the resulting binaries
048678b OSX: add makefile for osx-intel (untested)

For more details, see the full commit messages, or just ask me :)

Hasn't Carl supposed to have build A111 ?

Many of those may already be superfluous with the upcoming A111, 
but we'll see :) I intend to forward port whatever makes sense.

All of those changes where discussed (mostly in the "R3 Source Control" 
group) back in November before Carl went incommunicado in this AltME 
world.

Carl's disappearance also made me forget about those changes. But 
as he writes in his most recent R3 blog post "If I can find any other 
changes this weekend, I will merge them.", maybe they still are of 
any use.

Otherwise we'll see after the A111 release :)

a blog???

http://www.rebol.net/r3blogs/0351.html

he's alive!

Has anyone tried compiling the hostkit for MinGW with the Cygwin 
compiler set? I'm trying to minimize the number of GCC installations 
on my Windows machine, and the Android NDK requires Cygwin to do 
its build process.

should be possible (and rather unproblematic) but give you something 
very different

mingw-compiled .exe's are native win32 exes, cygwin-compiled stuff 
depends on the cygwin runtime

so cygwin gcc really != mingw gcc, just as linux-x86 gcc != linux-arm 
gcc

(at least last time i looked at cygwin, which was years ago. but 
i doubt things have changed much)

Cygwin can compile MinGW exes, Linux exes, Android ARM exes, etc. 
I am more concerned with the makefiles and settings involved.

heh, it's not cygwin which does the compiling :)

The MinGW compilers were originally hosted on Cygwin, and that has 
been supported all along.

if you can compile arm and mingw binaries in cygwin, you already 
have two sets of compilers installed

and if you have the mingw cross-compiler installed within cygwin, 
that will do just fine with the current host kit

just be sure to use the correct gcc

I am OK with more than one set of (cross) compilers but I don't want 
to duplicate the rest of the infrastructure. I'm having enough trouble 
with Git installing its own copy of MSys instead of using the already-installed 
copy; I don't want to compound the issue by having to install MinGW 
and Cygwin both.

you'll probably have to use a different gcc (i686-pc-mingw32-gcc 
or something) or pass -mno-cygwin to the default gcc

btw, you don't need msys to compile the host kit. mingw alone is 
sufficient