World: r3wp

(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

I was going to try using the i686 build (on this machine) of MinGW-64 
in Cygwin as my only Windows x86 compiler. Then I'd only need to 
add the Android ARM and x86 cross compilers to cover what I currently 
need to compile, and be able to make 64bit apps when I get my Win7 
machine rebuilt.

without a 64-bit r3lib, you won't get 64bit builds of r3 any time 
soon :)

Best to be prepared :)

but usually, the x86-64 gcc's happily emit x86-32 just by passing 
-m32

Yup, MinGW-64 has good support for generating 32bit code; I was researching 
the issues involved all of yesterday.

Fixed the warning: deprecated conversion from string constant to 
'wchar_t*'

https://github.com/Oldes/R3A110/commit/aebc8b8334f1396862b7249d2ab993d83c1c11f8

should be probably improved to set different name for non Windows 
builds.

And here is merge with Andreas' changes:

https://github.com/Oldes/R3A110/commit/ed261d8a39b973de6635b9833c32ceffe0780cba

Tested only on Windows.

What is strange is, that exes built using make-gcc/3.1/makefile are 
detected by Norton Sonar as suspicious :-/  not the one built with 
Codeblocks

http://www.symantec.com/connect/forums/sonar-detects-our-protected-application-high-security-risk

this one:

http://securityresponse.symantec.com/security_response/writeup.jsp?docid=2010-090200-2232-99
I will submit it to Norton as false positive.

Using the Cygwin compilers turned out to be unnecessary, so I can 
get away with just the Cygwin base install plus make for the NDK, 
TDD-GCC for the host kit, and Git for Windows for the Git support. 
Only one set of compilers per target platform, but 3 mostly duplicated 
sets of general command line tools.