World: r4wp

And if we want to keep the "nice" exe names (which would be my guess), 
what to do if the target file already exists?

Most developer friendly (imo): just overwrite it.

Automatic name guessing: yes, we want to keep that and overwrite 
it if exists already.

Ok, should be an easy change, but I guess the test runners will need 
adapting (if we want the new behaviour to be the default).

Yes, we'll need to adapt all our tests scripts. That's why I've tagged 
the last commit for the release, to avoid further delays.

Added floating point support to the SQLite binding

Nice!

It was mostly uncommenting some prepared lines :-)

Andreas: if you know how to improve working dir handling in %rsc.r, 
feel free to do so when you want. We'll adapt the test scripts accordingly.

I'm trying to move the SQLite binding into a CONTEXT, but I've hit 
a bug

Nenad" "Peter: the lib-test file is crashing here on my OS X 10.6.2 
image with following error:"


Did you install Xcode including the Unix libs?  I wrote the tests 
under OS X 10.6 but am now running on 10.7.

What we want is ability to call %rsc.r from anywhere, compiling a 
program from working dir (or relative to working dir) and producing 
the binary in the working dir.


Please can we also supply a second argument to rsc.r for the output 
dir/file name (the gcc -o option with improvements).


If the second argument is a dir then the executable is written to 
that dir instead of the current working dir.


If the second argument is a file then the executable is saved with 
that name.

(That would really help with quick-test).

I just checked on my old machine, I did re-wrtie the lib tests on 
OS X 10.6 but on OS X 10.7.

I meant that I re-wrote the lib tests on OS X 10.7 not 10.6.

Did you install Xcode including the Unix libs?

 I have Xcode installed, but don't know if it includes Unix libs or 
 not...how can I check that?

The -o command-line option for %rsc.r is already there (and since 
a while). ;-)

I was reviewing my old iMagick.reds binding for a while and found 
that it the current version I cannot write something like:
		DrawComment: "DrawComment" [
			;== Adds a comment to a vector output stream
			;-- void DrawComment(DrawingWand *wand,const char *comment)
			wand          [DrawingWand!] ;the drawing wand.
			comment   [c-string!] ;comment text
		]
It throws:
*** Loading Error: invalid comment string


Do we really need to have 'comment word such an important? I'm pretty 
sure I would never use it in declarations (as a comment).

It should be allowed imported functions spec block.

*allowed in

I don't like it:/ Could it be at least used only with string after 
comment word?

There are some issues with context which I found..
1.
WITH is not able to find enums defined in CONTEXT

c: context [
	#enum SomeEnum! [FooFalse FooTrue]
	test: does [
		print FooTrue
	]
]
with c [
	test ;prints 1

 ;; print FooTrue ;<-- *** Compilation Error: undefined symbol: FooTrue
]

Yes, we currently lack some tests for covering combination of WITH 
and all namespace-aware type of elements.

2.

#enum fooEnum! [x y: x z] ;<-- possible
c: context [

 #enum SomeEnum! [foo boo: foo] ;<-- *** Compilation Error: cannot 
 resolve literal enum value for: c/boo 
]

Could it be at least used only with string after comment word?
 I'm not sure what you mean?

limmit comment only on strings... but right, one would not see an 
error while used with block and expecting comment and not just some 
definition.

Personaly I use only:   comment {something}   never:   comment [something]

And as I'm recently coding not just in REBOL, I like shorter multine 
comments used in other languages /*  */

comment in REBOL is just native function which takes one argument 
and does nothing.

>> comment (x: 2 + 2) x
== 4

So in Red/System it should not be handled in loader

(but I know it's just a sugar and I can rename 'comment into 'text 
in the declaration above).. The problem is, that I don't write these 
manually.

Issue 1. fixed.

Issue 2. fixed.

Comment: you're right, it should work more like in REBOL. Resolving 
it in loader was an attempt at reducing compiler overhead on processing 
it.

After checking loader's code, it was just checking comment's syntax, 
not processing it.

In the current implementation, 'comment can only be used at root 
level (so not nested in IF, EITHER, ... body blocks). So, it's not 
true multiline comment support.

The SQLite binding now works on OS X, thanks to Peter

Good news!

Oldes: I've changed the 'comment implementation to be more like REBOL, 
so it consumes the next expression, but does not generate code for 
it (so you're above example with 'x won't work in Red/System). Also, 
it cannot be used in functions spec blocks anymore, so we still don't 
have a true multiline comment support. Suggestions about that are 
welcome.

Doc, I see you have recently updated quite a few things (on http://www.red-lang.org) 
. Good job.

James: thanks! More interesting stuff is coming soon. ;-)

ohhh!

Lookinf forward to whatever progress is made :-)

Glad about COMMENT :-)

I'm also glad it doesn't have side effects

We still lack a proper multiline comment solution that works everywhere, 
though.

Pekr: expect a firework of new features and progress until christmas. 
;-)

No side projects? Well, we will have to keep you alive via some donation 
from time to time then :-)

dynamic/shared libraries support? Ability to generate a DLL? Is it 
e.g. any prerequisite to come to Android, or just useful generally?

I have a short-term customer project, but it's a week or so of work 
and I can work part-time on it.


I also have another webapp (cheyenne-based) project that I work on 
from time to time, I'll publish it when it will be fully functional, 
I'm pretty sure you'll like it. Currently only Kaj knows what it 
is about, as I started it last time I've visited him. ;-)