World: r3wp

I guess I could include a "comment {" to comment out the whole section, 
but I'd prefer something else!

Hmm.  Are comments stripped out in the encapped binary?

Yes.

So, in that case I could include a conditional comment to remove 
large chunks of source code ...

In the case of #do the result of the expression will be placed in 
the output file. For example:
    version: #do [1.2.3 + 0.0.1]
will create the output:
    version: 1.2.4

? .. is that a non-sequitur

The #if and #either commands will put the results of their blocks 
into the output file. For example:
    version: #if [new-version] [2.3.4] [1.2.3]
will result in:
    version: 2.3.4

I see.

I'll give that a go :)

don't those commands evaluate the expressions .. I just want to include 
the source

Now if you put your code dafely in a lot of [] and evaluate that?

dafely->safely

Getting too complicated ..

Perhaps I need to ask for this feature in prerebol

try something like:

code: [executable code]
#if [condition] compose [(code)]

Graham, I don't understand your question.

#if [condition] [
    ; this part is included only if condition is true
    your code here
]
non conditional code here

Gabriele, I think I just misunderstood the documentation.

Couldn't SDK be redone in different way? I really don't want to miss 
rebcode for SDK. That is not good, given the frequency SDK gets updated 
;-) It lags behind usefull stuff for so long! It would be good, if 
the new release plan would count on SDK updates to come more often, 
or somehow magically Encap could use different kernels - you would 
pass it as a parameter:-)

dunno if technicall solvable, but basically such Encap would be kind 
of launcher, which would "boot" rebol - it would unpack it from executable 
into memory. But dunno if technically solvable :-)

you mean the sdk could use any rebol binary to encap with ?

yes

sounds like a good solution.

but not sure if technically doable?

would it also work cross platform?

Carl can do anything given sufficient reason/time

but imo such executable boots rebol anyway ...

So, I could create cross platform binaries

that would save RT from feeding us new SDKs just because new kernels 
were released ....

not sure - such loader/booter, would be platform dependant anyway, 
no?

not sure if I am not mistakenly inspired by some solution posted 
to ml few weeks ago? IIRC someone did self-extracting executable 
(archive), where there was rebol and scripts .... I just don't remember, 
if when you create such archive, you can instruct it to start some 
app ...

http://www.rebol.org/cgi-bin/cgiwrap/rebol/ml-display-thread.r?m=rmlKQTC

I don't think this would be a good idea as the SDK lets you choose 
what mezz code you wish to include, and things like console help 
and desktop are excluded by default.

Unless Carl has a way of stripping out rebol/base from the binaries 
...

Difficult, as trying to map:


 "I'll take base and not include any of the networking mezz source"

to:


 "Encap using latest rebview but exclude all the graphics and networking 
 code *I* know I'm not going to need"

doesn't sound too easy to me.

Ashley - as Graham said - use Base/Face ... include your mezzanines. 
Most of the time they will be compatible

But ask yourself, how often do you need to remove some specific code 
from your app? How mcuh will you save? Rebol is not resources savy 
anyway, at least not in the runtime, for most embedded apps to work 
with ...

Most of the GUI work I do does not use VID or networking, so enface 
without any of the view-* or prot-* scripts is what I want. I do 
not want to use a loader front-end based on rebview that includes 
all this code. The cost in executable size may be small (less than 
100Kb), but it's the start-up time and memory cost that I like to 
get as lean as possible. This will become more of an issue if and 
when REBOL is ported to small memory footprint devices.

Petr: one thing is official SDK releases, which need to be stable 
and secure (Rebcode is not secure yet); another thing is beta/alpha 
releases for developers brave enough to play with features like Rebcode. 
I guess the latter can be done as often as View betas. we should 
probably talk to Carl about this.

OK, if that is doable, then yes, Gabriele. I just fear (judging according 
to my past experience), that SDK will lag. And it feels pretty arcane 
to "throw away" rebcode now in its current state ... just my feeling.

I can understand security issues, if those are not solved yet, but 
....

Its the sdk, so security maybe is not such an issue? Runs only your 
own code, not rebsites. But Gabrieles suggestion would be best: when 
releasing alphas, build /base /face etc too.

would be at least more secure then switching to c instead.

Volker - that is not enough - you need Encap also ....

Forgot to mention that ;) If Carl sets up such a build-tool, it should 
be able to build the encaps too.

Well.. a new sdk has been finally released!  And that includes Command. 
 Thank you RT!!!!

underway!

How is it now about sourcecode? Its included, the link is public..

Look at the license.

That was in the last beta too and Gregg said no. And i am not sure 
about "with any REBOL Technologies products". Gregg said no, but 
IMHO if anyone can download, makes that sense?