World: r4wp

Seems to be a WINE limitation. Dunno if it's fixed in newer versions:

fixme:msvcrt:_setmode fd (1) mode (0x00020000) unknown
fixme:msvcrt:_setmode fd (2) mode (0x00020000) unknown

Can it be that the Windows PE backend compiles in a random number 
or otherwise random uninitialised values? Windows builds seem to 
change on every build run without Red having changed. This is inefficient 
for my incremental builds repository and makes it hard to validate 
build correctness

It barely runs under wineconsole 1.2.2 though. [..] Dunno if it's 
fixed in newer versions


Unusable under wine 1.5.20 as well (same setmode fixmes on startup).

Gregg: "Remember, everyone, I'll match donations made by 31-Dec up 
to USD$200."

I just donated 50 eu (68,93 usd) to Doc for the big progress of Red!

OK, just sent another 50 EUR. I also sent 50 EUR on 15.12.2012, dunno 
since when Gregg's doubling applies (should be OK for NickA though) 
....

Doc - console does not seem to support two consecutive expressions? 
E.g. a: 1 print a, crashes ....

The interpreter also seems to be in an empty executable
 Yes, it is part of Red's runtime.

_setmode call is used to properly set the DOS console to UTF-16 (Unicode 
mode).

Can it be that the Windows PE backend compiles in a random number 
or otherwise random uninitialised values?

 No, it shouldn't AFAIR, you can open a ticket on the bugtracker if 
 it's the case.

Pekr: thanks for reporting, will look into it.

That's great Endo! I'm glad Doc's hard work is turning into donations, 
so he can see real support for the project from others. Kaj and Peter 
are doing a lot to help him, and I hope to make time in a few weeks 
to show my support with action as well.

Petr: issue fixed.

Console binary updated

Console binary updated with the added conditionals

it almost seems, like you have to reimplement all the Red functionality 
for console?

Nah, just another wrapper over the existing runtime

I think the interpreter added less than 10 KB to the binary

Pekr: just the natives that are processed as keywords by the compiler 
and that don't needed a runtime counterpart until now. Anyway, as 
you can see from the commits, it's just a thin layer.

didn't need

Console binary updated with the added loops

Thanks Kaj.

Kaj: congrats on the first binding made available to Red! :-)


I've noticed in %examples/do-sql.red the comment for #include:  "FIXME: 
#252". Actually, #252 is for Red/System, Red  implements its own 
#include which behaves differently than the Red/System version. I've 
tried to make it more intuitive, but it still needs some adjustments, 
so feel free to open new tickets about that (with simple concrete 
test cases I can reproduce). 


Also keep in mind that #include at Red level is intended to be a 
temporary feature until we get DO, LOAD and READ working with files. 
I would like an include system that could work both for the interpreter 
and compiler without having to change any code. I'm not sure this 
is achievable, so in worst case, we'll keep #include as fall-back.

Yeah, there's a question mark behind it because I wasn't sure it's 
the same issue, but #252 is the closest

I think SQLite-binging was misplaced in "Red/System contributions" 
Section in Red-lang.org. It's Red not Red/System. ... Good to know 
that SQLite Binding is done. Thanks. Kaj.

Until ten minutes ago it was a Red/System binding. :-) Now it's both 
a Red/System and a Red binding, built on top of the Red/System one

The same will happen with my other bindings

wowo! for the console interpreter and bindings!! awesome

I sent 70eur in from 14.Dec to now (for NickA or Gregg deals / btw 
thanks for that).

Janko: thanks for your donations!

Shouldn't block/rs-head and rs-tail have a /local s ?

Same for string. Perhaps it comes out of string/rs-length? which 
doesn't have s

block/copy seems to need /local s too

Yep, copy/paste bug.

I've implemented the first string marshalling in the SQLite binding, 
of the version identifiers

version: routine [  ; Return SQLite version.
;	return:				[string!]
	/local				version
][
	version: sqlite/version
	SET_RETURN ((string/load version length? version))
]

You should wait for me to add the marshalling and unmarshalling functions 
(that will be used everywhere Red needs to interface with non-Red 
code). In your code example, it should be: 1 + length? version (as 
it needs to account for terminal NUL character). Also, you need to 
get sure that the source c-string! buffer is always available or 
make a copy of it (a pointer to it is stored as a UTF-8 cache, unused 
yet, but intended for speeding up I/O, still experimental, not sure 
it will stay for v1.0).

I was wondering about those things. There's not much I can do then 
to make working bindings currently

I'll try to speed things up.

Don't tremble apart when passing the sound barrier ;-)

:-))

I adapted the console to work on POSIX platforms with the ReadLine 
library, but due to bugs in ROUTINE it's currently impossible to 
keep it integrated with the Windows version

Since Red compiles to Red/system, how can I get the red/system source 
result?

Red is simpler to use but sometimes we want speed so why not let 
red compile to r/s

and then use that source to make a routine! or as a stand-alone program?

You can use the -v options to the compiler, but you'll probably be 
disappointed. What Red generates is completely integrated with its 
runtime, not something you would use standalone or even hack

Marco: it's explained in the README file there: https://github.com/dockimbel/Red

Red compiles to generic Red/System code, there's no optimizer yet. 
Routines allow you to hand-optimize Red/System code and use system 
programming features not available at Red level.

Kaj: have you reported those routine bugs somewhere?

About antivirus false positves (VERY annoing): Red exes give alerts 
while r/s ones not (at least not the demos), isn't it a bit strange?

I'll get around to reporting some issues later tonight

Marco: some antivirus have too aggressive heuristics, there's not 
much we can do for that. From time to time, I send some reports to 
AV vendors for notifying the false positive, most of the time, they 
take it into account.


Doing a quick test on virustotal using the latest console exe, it 
seems that my reports have been successfully processed, I don't have 
the old virus reported anymore (except with Panda): https://www.virustotal.com/file/a8c189ed790fd1d5bce2d86878e85445c21880dafb4220605df4ef2e4d4f4ce5/analysis/1356894544/

What AV are you using?