World: r4wp

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. ;-)

Ability to generate DLL, yes. It is a prerequisite for Android (and 
probably iOS/OSX) support.

That sounds really great.

Having /* */ comments in Red/System would be a very good idea  for 
me. Boron uses /* */ for multilne comments.

I think I should find a web page that compares multiline comment 
syntax for main languages to see if there's any good  alternative 
to the C way.

BTW, for those not following me on Twitter (raise your hand!), I 
just got my first Red/System DLL working on Windows. ;-)

So now, who wants to write R3 extensions in Red/System? ;-)

As Red/System compiler is written in R2, you could imagine a full 
toolchain library for R2 that could integrate Red/System deeply with 
R2, imagine:

>> foo: make-native [a [integer!] return: [integer!]][a + 1]
>> foo 123
== 124


MAKE-NATIVE here would compile the Red/System function, emit a DLL, 
load it and map the function back. ;-)

I don't receive notification emails anymore for the newly added github 
issues...If I activate Settings->Notification->Watching->Email, I 
get them again, but also from all others repo I'm watching...Is there 
a way to only get the notifications by email for the repos I'm owning?

Does this help? https://github.com/blog/1204-notifications-stars

Someone else wrote:

So the 'solution' I found to this was to set up filters for the various 
repository emails by filtering on email list. The list filtering 
is mentioned here on the github blog: https://github.com/blog/967-github-secrets
(scroll down the page a bit).


I would then just forward the emails from selected repositories to 
the "correct" email address.

Thanks for the links James, I'm watching and have starred my Red 
repo, so I should receive those notifications...

R3 extensions in Red/System sound interesting. Does Red/System have 
some easy way to replicate what the R3 extension macros do with unions?

Have you done experiments in JIT compiling yet? R3's extension/command 
model is really easy to use to implement JIT compiled functions.

R3 unions: I'm not familiar with R3 extension macros, got a link?


JIT compilation: not yet, but I guess it could be interesting to 
do it for R3 as an extension (not on my roadmap though).

Not R3 unions, C unions. The arg type for R3 extension commands is 
a union, with the different potential datatypes being alternates.

The macros are defined in the headers that come with the R3 host 
kit.

A Red/System extension kit would need to replicate the functionality 
of the macros, to implement the datatypes involved.

DLL: excellent! Does Windows not need PIC or something?

Unions: I had to match them for the SDL binding. Red/System doesn't 
have them, but I just define STRUCTs for each variety, and then cast 
a particular instance to the right one

PIC is not required for Windows libraries. There's a relocation mechanism 
though, that I haven't implemented yet, to solve libraries loaded 
on overlapping memory areas.