AltME groups: search

REBOL []

do %../library-dialect/lib-dialect.r

make-routines [
    lib %kernel32.dll
    def-rtn-type long
    ; returns available drive flags as a bitset (in a long)
    get-logical-drives "GetLogicalDrives"
    get-logical-drive-strings "GetLogicalDriveStringsA" [
        buff-len [integer!]
        buffer   [string!]
    ]
    get-drive-type [drive [string!]] "GetDriveTypeA"
]


drive-types: [
    Unknown     ; 0 We don't know what kind of drive it is
    NoRootDir   ; 1 Probably not a valid drive if there's no
                ;   root directory
    Removable   ; 2 It's a removable drive
    Fixed       ; 3 It's a fixed disk
    Remote      ; 4 It's out there on the network somewhere
    CDROM       ; 5 It's a CD ROM drive
    RAMDisk     ; 6 It's not a real drive, but a RAM drive.
]

drive-type?: func [drive /word /local res] [
    res: get-drive-type join first trim/with form drive "/" ":"
    either word [pick drive-types add res 1] [res]
]

get-drive-strings: func [
    /trim "Return only the drive letters, no extra chars"
    /local len buff res
][

    ; Call it once, with 0, to find out how much space we need in our 
    buffer
    len: get-logical-drive-strings 0 "^@"
    ; Init our buffer to the required length
    buff: head insert/dup copy "" #"^@" len
    ; Make the call for real, to get the data
    len: get-logical-drive-strings length? buff buff
    res: parse/all copy/part buff len "^@"
    if trim [foreach item res [clear at item 2]]
    res
]

;print enbase/base to binary! get-logical-drives 2
foreach id [a b "C" 'c "D" d: %E %F %/F] [
    print [mold :id tab drive-type? :id tab drive-type?/word :id]
]
print mold get-drive-strings
print mold get-drive-strings/trim
print read %/

>> debase/base to-hex 512 16
== #{00000200}

We can do that now. Base is ~270K.

with the recent change of issue  to word base type, this becomes 
even more usefull.

Time will tell. Like it or not, REBOL is primarily built around mutating 
functions, except for functions that work on immutable values like 
integers. Most of the non-mutating functions we have are either built 
on their mutating counterparts in mezzanine, or are options of those 
functions. In a language with mutable values, mutating functions 
are the base. Functional-language fans tend to not like this (and 
when we start really implementing task-safe code they can say "I 
told you so!"). However, mutability can have advantages too, mostly 
in memory usage and performance, so it's a tradeoff.

It's a good question, and regarding that, I noted that many of the 
solutions to Code Golf problems utilize base-64.

Although this bunch is in flux, I tried making [^ foo] map to [to-string 
debase foo].  This means S^"badfjakshdg--" (or whatever) will give 
you the un-base-64'd string.

Maxim, once you have 1-based indexing (which we are stuck with for 
historical reasons), then having 0 be negative *is* the best for 
math calculations. That way you can count on offset = index - base.

So, you're asking if the plugin model will still follow the initial 
stated base requirements for a plugin model? :)

The problem is that the R2 DLL interface sucked. One of the base 
requirements of the R3 plugin model wass that it be powerful enough 
that you cold write a generic wrapper dialect as a plugin, and then 
use that dialect to specify the API a DLL.

As for other blog - Objects as a base type ... is there any implication 
what it means for object semantics? IIRC you expected some changes 
in object semantics, but Carl states, that other types as ports, 
tasks, etc. share the implementation, so I wonder if you can really 
expect any change here?

Objects as a base type blog = documentation of the way things have 
always been, not a sign of things to come. It was probably in response 
to bug#838 and my reply to it.

oldes i'm doing irc client with colot text support that's fun i tool 
your irc-core as base

oldes i'm doing irc client with color text support that's fun i took 
your irc-core as base

Pekr, the reason for R3/Plus is so we don't have to say no to people's 
requests for new functions, but don't want to bloat REBOL. With modules 
we don't have to make everything monolithic anymore. We have a new 
situation with R3.

The main advantages to having functions built into REBOL:
- REBOL itself can use them.
- You can count on them being there.

- They will be tested and reworked by the best of the community (the 
REBOL optimizer).

The main disadvantages to building functions into REBOL:

- Increases overhead, both in startup time and memory overhead. Compare 
R2 /Base to /Core to see what I mean.
- Predefines more words.

- These might not do what you want, so you'll end up redefining them 
anyways.


Building a community is a balancing act. Once we started taking requests 
for new features to make REBOL better, the floodgates opened. Even 
after filtering out the impossible or otherwise bad ideas, there 
was a lot of good stuff in there. But we don't want to bloat REBOL 
into Perl.


Fortunately, we had added modules to R3 to help organize the code 
and deal with the last two disadvantages to building in functions. 
And we have DevBase to accept community contributions. These are 
all the infrastructure we needed to create a standard library, tentatively 
called R3/Plus.


So now we don't have to worry about accepting requests for new features, 
because we know how ruthless we are going to be about our mezzanine 
cuts. If REBOL itself uses the function, it either stays as a mezzanine, 
or in some cases goes native. If the value of the function for users 
is high, the overhead is low, and there is consensus, it may get 
to stay too. Otherwise they become library functions. FUNCTOR wasn't 
the first cut, and it won't be the last.


Keep in mind that with plugins, library functions can be native too. 
And the REBOL optimizer still applies. And with modules you can declare 
your dependencies. There's very little downside to having R3/Plus.

>> call "cmd dir"
== none

>> Microsoft Windows [Verze 6.0.6001]

Copyright (c) 2006 Microsoft Corporation. Všechna práva vyhrazena.

c:\!rebol\altme\worlds\r3-gui\files\rebdev>dir
** Script error: dir has no value


>> dir
 Svazek v jednotce C nemá žádnou jmenovku.
 Sériové èíslo svazku je 0054-60D0.

 Výpis adresáøe c:\!rebol\altme\worlds\r3-gui\files\rebdev

13.08.2009  12:12    <DIR>          .
13.08.2009  12:12    <DIR>          ..
02.07.2009  15:38    <DIR>          base

As for your other question, look at this:

>> call "cmd.exe /c dir"
== none

>>  Volume in drive E is APPS
 Volume Serial Number is 7845-7730

 Directory of E:\REBOL\2.100

01/14/2009  03:17 PM    <DIR>          .
01/14/2009  03:17 PM    <DIR>          ..
01/14/2009  03:24 PM    <DIR>          base
01/15/2009  12:17 PM    <DIR>          updates
07/12/2009  03:08 PM                56 blah.txt
02/25/2009  08:09 PM               492 user.r
03/02/2009  10:22 PM    <DIR>          work
04/09/2009  08:41 PM                66 test.r
06/13/2009  12:09 AM                28 mod1.r
06/13/2009  12:09 AM                28 mod2.r
06/13/2009  12:10 AM                47 mod.r
08/10/2009  08:39 PM    <DIR>          plugin
08/13/2009  03:35 PM           613,376 r3.exe
08/13/2009  07:08 PM    <DIR>          extension
08/13/2009  08:46 PM            20,480 ext-test.dll
               8 File(s)        634,573 bytes
               7 Dir(s)   4,893,769,728 bytes free
1 + 1
== 2


I did that 1 + 1 to show that I didn't have to hit enter to get back 
to REBOL. You only have to hit enter to see the prompt. The extra 
>> above the dir outpt is the result prompt that you aren't seeing 
below. This is because CALL on Windows returns immediately, rather 
than waiting for the called process to finish its work, including 
its console output.

not sure it is good idea at all. But product packaging strategy was 
never explained for R3. Will there be Core, Command, View, Base like 
products? I am not sure, that technologically, R3 is done in such 
a way, so that such separation is possible (= all View internals 
can be placed outside R3 as a module). Also - having it optional 
as a module can lead to split of efforts once again.

He is my advanced and totally robust tuple incrementor.


you can set base for tuple fields and can even increment larger than 
the base safely.

it auto-detects the size of the tuple for you, or you can set the 
increment precision, if you need.


;-----------------
;-    tuple++()
;-----------------
tuple++: func [

 {Increments tuple fields from their Least Significant Field, carrying 
 over when any Field hits base.

Note that you can use tuples as BIGNUMs if you want, using this function 
to add them together.

in Base 256, this means you can store a number up to 1.2E+24 safely.}
	value [tuple!]

 /at precision [integer!] "LSF (Least significant field) the increment 
 occurs on."
	/step amount "Add this amount to LSF at each increment"

 /base n "Each field carries over when this value is met.  Overflow 
 error raised, if MSF field tries to go beyond base(range 1-255, default 
 255) "
	/local carry
][
	precision: any [precision length? value]

 if none? value/(precision) [value: value + make tuple! head insert/dup 
 copy [] 0 precision]
	
	carry: 0
	n: any [
		max 2 min 256 any [n 256]
	]
	amount: any [amount 1]
	
	until [
		if carry >= n [
			amount: 0
			; we looped due to carry-over
			value/(precision): to-integer (remainder carry n) 
			carry: to-integer (carry / n)
			precision: precision - 1
			if precision = 0 [
				to-error "tupple increment overflow"
			]
		]
		
		value/(precision): value/(precision) + carry + amount
		carry: value/(precision); + amount
		any [
			carry < n
		]
	]
	value
]

ex: 

>> addr: 0.0.0.5
== 0.0.0.5

>> loop 10 [ probe addr: tuple++/base/step addr 10 12  ]
0.0.1.7
0.0.2.9
0.0.4.1
0.0.5.3
0.0.6.5
0.0.7.7
0.0.8.9
0.1.0.1
0.1.1.3
0.1.2.5

My original idea was having something like a tuple where you could 
set a different base per number.

just being able to set tuples to any base as a whole (up to 64 unsigned 
bits) would be a great feature... something I will always miss for 
graphics, since many professional apps go up to 64 bits per channel

Pekr can we still keep win32 15 years old kid as base for VID  on 
windows plateform on a middle term  (5 more years) won"t it be better 
to start right now to support winfx enhancement and use part of the 
hardware acceleration in rendering?

pekr why using net sockets when you have even faster better ways 
to access the data in you base

what is the base of the frustrations?

but yes I would say R2 lasted too long ... carl was glued in endlessly 
bug correction and few where the real improvements... the major addition 
in R2  was the AGG/draw dialect which since then have not evolved 
a bit... look at the number of tickets in old rambo. So yes starting 
with a ew base and bring alot of enhancement was a certain thing 
the problem is along the process we lost alot of people mainly interrested 
in rebol but not seeing it evolving fast anough and that how do you 
solve it ?

sorry for alignment, but here it is:

Parse input: |
Parse match: block!
Parse input: |

1: make-text-style : function! [font-name font-parent spec /local 
proto style nam
2: to-word : function! [value]
3: name : base:
--> to-word
    1: to : action! [type spec]
    2: word! : word!
    3: :value : base:
    --> to
    <-- to == base
    <-- to-word == base

    4: parent : [      font: [          color: black          size
     **: error : Script expect-arg
     **: error : Script expect-arg
     **: error : Script expect-arg
 1: trace/back
 2: 10
    --> trace

For BASE font style there is no parent, and we have a new rule that 
says that SET does not set a new value, if the  value shouldn't be 
set.

>> parse [base: [specs]] [set-word! set c opt word! block!]
== true

>> c
== [specs]

It looks to me like some GUI functions like 'handle-events and 'base-handler 
that belong inside View are also available in the main context and 
are also listed in the docs. I assume those functions will disappear, 
once the GUI goes into a module.

The difficult question is base-64 vs true binary.

It can be easier to read if you have:
   system/options/binary-base: 16

 bits: make bitset! "abc"
== make bitset! #{00000000000000000000000070}

I think people are still thinking of R3 based on the situation with 
R2. With R2 if something wasn't "delivered by RT", you couldn't do 
it at all in some (lower-level) cases. This is simply not true with 
R3. R3 is not a black box, and SSL in particular would be easy to 
retrofit even if the base distribution doesn't include it. Plus, 
the pace of development of R3 is pretty fast, and any release that 
doesn't have the feature you want could be followed pretty quickly 
with a release that includes it. The only limitation is time, effort, 
and money (to buy the other two). If people don't contribute, it 
doesn't get done, period. If you want the feature, add it yourself 
or pay someone to write it. Adding it yourself will be easy in this 
case - we'll see about how easy the other method will be.

Geomol, that inaccuracy is built into the standard, and floating 
point hardware tends to follow that standard. It's a side effect 
of the fact that IEEE754 floating point numbers are internally base 
2, and in base 2 the decimal value 0.1 is an infinite number just 
like 1/3 is in base 10.

yes, but in the above case both "real" and "float" are actually of 
the "same information value" for an expert - not knowing from the 
name neither how many bits they use, nor what is the base (2 or 10)

More like:

	dehex: use [hx ch][
		hx: charset [#"0" - #"9" #"a" - #"f" #"A" - #"F"]
		func [text][
			parse/all text: to-binary text [
				any [
					to #"%" remove [#"%" copy ch 2 hx] ; change <> remove insert
					(ch: debase/base ch 16) insert ch
				] to end
			]
			to-string text
		]
	]

oops, didn't notice how far back the scroll bar was...  "this one" 
being the post re decimal! with base 2 conversion precision.   this 
line in particular.    for i 4.0 6.0 0.1 [print i if i = 6.0 [print 
[i "= 6.0"]]]f

btiffin, did you notice, that the i = 7.0 test in my other example 
fails? Try:

for i 4.0 7.0 0.1 [print i if i = 7.0 [print [i "= 7.0"]]]


The problem is, that you can make examples, where the "nearness" 
works. So the small business owner/hobbyist will come to think, the 
language actually handle those base-2 precision problems, but it 
doesn't. The only way, as I see it, to really handle this problem 
is by using true decimal arithmetic (e.g. some kind of binary-coded 
decimal as in money!). I believe, the current behaviour will only 
lead to more confusion.

Do or do not... there is no try.

REBOL try to solve the base-2 precision problem.

Maxim: "what's the best way to convert a hex string to a decimal 
value in R3?" - Try this:
>> pi
== 3.14159265358979
>> enbase/base to-binary pi 16
== "400921FB54442D18"
>> to-decimal debase/base "400921FB54442D18" 16
== 3.14159265358979
>> to-decimal debase/base enbase/base to-binary pi 16 16
== 3.14159265358979


You asked for the best way: No method that uses the issue! type for 
binary conversions could be considered the best way.

if it's for storing usage, then restoring, perhaps the base 64 format 
is enough.

>> enbase to-binary pi
== "QAkh+1RELRg="

>> to-decimal debase enbase to-binary pi
== 3.14159265358979

Graham is corrrect.  We need to finalize a base context for networking.

Anyway, ... we need some decisions made about the base context, network 
tracing etc

So Carl, have you come back with some proposals on the network base 
context ?

win-get-dns: has [base local-ip out v][
		local-ip: mold read join dns:// read dns://
		
		either value? 'get-reg [

   base: "System\CurrentControlSet\Services\Tcpip\Parameters\Interfaces"
			foreach adapter list-reg/hklm base [

    if local-ip = get-reg/hklm rejoin [base #"\" adapter] "IPAddress" 
    [
					v: get-reg/hklm rejoin [base #"\" adapter] "NameServer"
					v: parse v ","
					forall v [change v attempt [to-tuple trim v/1]]
					return head v
				]
			]
		][
			; just use opendns
			208.67.222.222
		]
	]

well... the main call to remark is ... compile   hehehe...  I do 
plan on making an XML document model eventually.  basically, it would 
convert XML elements into your current Remark document models, so 
you can leverage the same code base but with another data model as 
input.


optionally you could build direct XML document models for a bit more 
speed.


all that needs to be done to make it easy for you guys is to build 
a few simple base XML tags which allow you to build the dialect based 
on xml element names.

Start by providing the __attribute__ for thread-locals, assuming 
that the .so supports that.  If not, we'll need to move the thread 
local vars into a struct, and allocate it dynamically.  However, 
we'll still need at least one thread-local from the host kit side, 
to provide the base pointer for each thread.

Btw, to clarify also other things, "switching to R3" by porting Cheyenne 
(which by itself would took weeks), would put me in difficult position 
where I would have to maintain 2 versions of Cheyenne (R3 version 
and R2 for all my installed personal and business webapps). Making 
a full switch (porting all my web and native apps to R3), would require 
*months* of work. I currently have around 12h a week (7 days) of 
free time for non-business projects. So, "switching" to R3, would 
mean stopping all evolutions on all my products during months, maybe 
a year until I can port everything to R3. This is not an option for 
me.


So, only a "R2 feature-complete" R3 version could make that doable 
in an acceptable time frame (and with much less risks of regressions). 


And all this huge work for what gain? Well, without threading, almost 
none (to be fair, maybe a little bit lighter source code base).

Extensions are better than /Library

  True, Extension are more powerfull, but for simple DLL mappings needs, 
  it's overkill and too costly in maintenance (you have to code and 
  maintain C code for each platform instead of a unique REBOL code 
  base). Again, I can't understant why /Library code cannot be ported 
  to R3 and why we're loosing a valuable feature.

That's why "critical mass" is important to reach. If, for example, 
1% of a user base is skilled enough and willing to contribute to 
an open source project, you need to get at least, a thousand users 
to expect significant contributions.

The situation with REBOL language is very different: it's our base 
programming tool, so it's extremely important for us to get it working 
right and keep on improving it. We are also lucky because the % of 
rebolers with good enough C skills and CS understanding is quite 
high for such a small community, so, (getting to the conclusion), 
if R2 was fully open sourced (real OSS, I mean BSD or GPL, not RLA), 
you can bet on it becoming the faster growing project of all times 
in the REBOL world! I think the main issue in that case would be 
to properly organize all the contributions.

Just an observation that the developer base shrinks as time progresses 
...and I doubt anything apart from open sourcing r3 will help

Kaj: "Cheyenne doesn't seem to load its MIME definitions from the 
standard location on Unix systems, %/etc/mime.types, loading an internal 
list %misc/mime.types instead"


Yes, it was done that way to ensure a common base of mime-types across 
all OSes. Anyway, I have in my todo list an entry for such a feature. 
I'm not yet sure if it should be by default, or controled by an explicit 
option.

So, we could use this to send email instead of RSP script?  Just 
have to upload attachements base 64 encoded still I guess as it is 
still a text protocol

I distribute encapped versions only when making new releases. If 
you need a intermediary revision encapped, just let me know the OS 
and encap kernel and I'll make you one. Also, I think I should release 
a new version now, the current SVN code base seems stable enough 
now.

from a client app (phone app) to my server with my data base.  like 
a json call in js

can anyone get a login for the cheyenne wiki?


I'd really like to put down my trials and errors of building my own 
cheyenne mod (with handler), so that others may benefit of knowing 
the few little caveats which can make the whole thing fail .... 
maybe do something like a step by step tutorial to begin with.


I'd also like to document all the phases of each internal layer of 
cheyenne (there are many), so that we can more easily navigate the 
code, knowing what we are doing and what other phase is part of each 
type of mod,extension, service, etc.   often, we see just one or 
two parts of a system implemented per module and its hard to get 
the whole picture.   


ironically, looking at the base objects is also hard to do, since 
there is so much "internal" code that it gets REALLY hard to understand 
what is internal, what is "interface" and what is provided as helper 
funcs for your own systems to use.  Add the fact that there are many 
layers sitting over each other, some layers which aren't actually 
layers of code, but layers in the "chain of command" and various 
phases.


now that I've made sense of a *portion* of this, I think I'm well 
placed to start documenting this.   I think that having a complete 
api reference for cheyenne would be really good for adoptance.


It would allow many of us to simply create integrated tools which 
just drop into cheyenne.  (like remark)

I wonder if someone actually has a real preference to base our vote 
for the site upon? As for me, I don't, because I don't know, what 
the requirements are going to be ....

Point of Information;  The user.r 2009 roty vote code.

vote: func [name] [

    enbase/base encloak head change head insert/dup copy "" " " 16 form 
    name "roty" 64
]


Please use that function, capture the output and post your vote to 
    user.r Chat


Due to encryption issues please use   'doc, 'brianh, 'henrik, for 
Nenad Rakocevic , Brian Hawley and Henrik Mikael Kristensen.

Thanks Doc.    P.S. I re-ran an install of CureCode today and it 
is failing on the sql file (build-db.sql)  used to define the data 
base and tables.  I found it and moved it but now I am failing on 
webapp setup.

The other thing that gets something bumped up in priority at this 
point is whether it is an easy fix, for great user benefit, and applies 
to functions or code that we are going over for other reasons now 
anyways. Your DELINE bug is one of those, Kaj. There are more severe 
bugs in that function that have already put it on the priority list, 
your reported bug should be easy to fix too, it affects a real current 
user base in a significant way, and it hints at the possibility of 
a worse hidden problem. These combined make #1794 a near-term priority.

for my 3D engine, this base line test was neccessary.  I need to 
squeze every hz out of rebol... its nice to see how some exit conditions 
are 10-15% faster in some equivalebt tests...  who would have tought 
that 'PICK was faster than NOT TAIL  ?  :-/

Anyway, I agree with this as a priority because it allows greater 
concurrent contribution to R3 base code.

The writeable options like binary-base are supposed to be moved to 
on-the-spot function options.

I think we should factor them .. and remove the redundant 'Base ...

As parse rules go, it wouldn't be difficult. Try this:
>> hex: charset [#"0" - #"9" #"a" - #"f" #"A" - #"F"]
== make bitset! #{000000000000FFC07E0000007E}

>> parse a: "paul%40tretbase.com" [any [to "%" [b: skip copy x 2 
hex (b: change/part b to-char first debase/base x 16 3) :b | skip]]] 
a
== "[paul-:-tretbase-:-com]"

Now that is a modifying method, but it should be easy to adapt that 
to a copying method.

With the full change rule it would be this:

>> parse a: "paul%40tretbase.com" [any [to "%" [change [skip copy 
x 2 hex] (to-char first debase/base x 16) | skip]]] a

From what I can tell above, we just need a way to represent numbers 
properly in any base.

Hmm, because I can't do shift on binary, enbase/base is giving me 
following result (understandable, as to-binary creates 64 bit binary)

>> enbase/base to-binary shift to-integer (copy l) -8 2

== {0000000000000000000000000000000000000000000000000000000010000011}

whereas:
>> enbase/base 2#{11110000} and 2#{10110000} 2
== "10110000"


Correct too? So when using shift, I need to use different scenarios, 
if I want bits represenation (copy/part)?

I know guys will not like it, but now I have "safe" way to OR/AND 
binaries the way I want :-) ... just not sure the way I find out 
the integer size is a good method ...

pad-bin: funct [bin [binary!]][
   bit-base: 8 * length? to-binary -1
   switch bit-base [
     64 [return join #{000000000000} bin]
   ]
]
  
>> (to-binary 1022) or pad-bin #{8000}
== #{00000000000083FE}

>> ; R2 code converting integer -1 to 32-bit binary
>> debase/base to-hex -1 16
== #{FFFFFFFF}
; R3 code converting the said binary to integer
>> to integer! #{FFFFFFFF}
== 4294967295


As far as I am concerned, it looks incompatible to me, and I would 
prefer -1 to be the result of the conversion in R3

But back on topic, we all know that Ladislav and Maxim have been 
using functions named INCLUDE to write their own code organizing 
or module systems over the years. But R3 has a standard module system 
already. We want to encourage people to use *that* module system, 
or to improve it if it isn't good enough for them. Code written for 
incompatible module systems is incompatible because of that, and 
thus can't easily be integrated or reused. This leads to fragmentation 
of the community code base, which we definitely *don't* want. Especially 
since the proposed standard library of community-provided R3 modules 
is supposed to be compatible with R3's module system, and each other.


So we definitely don't want to reserve the word "include" for use 
by alternative module systems, because we don't want people to *make* 
alternative module systems for R3 unless they are compatible supersets 
of R3's module system, which uses IMPORT instead (different concept 
too).


R2 is a different matter: We're already stuck with different module 
systems and incompatible code bases, and they have to keep working. 
Even if a R3-style module system gets backported to R2 (and it will 
be) it will have to be an optional addon. And if INCLUDE gets added 
to R3 as the opposite of EXCLUDE, there would be downsides to adding 
it to R2. We wouldn't be able to use it in any mezzanine code because 
the function would be overriden by Maxim's module system or Ladislav's 
non-modular code organization system. So INCLUDE probably wouldn't 
be backported.

Max, tell AND show us how you do the callbacks. IMO if you have found 
a way to do it now, we all should know it. It would speed-up R3 extension 
development a lot. And a good base of extensions is mandatory for 
R3 success. So every day we are faster helps us all.

but I think that the integration between the editor base and the 
lexer is too weak

I've never played around with it... last time I looked, I was daunted 
by the sheer size of the code base.

maybe i wasn't clear. Sorry i readed my post and some things appears 
not to be clear anough... 


1) Rebol runtime environement already exists that's the VM you install 
on your computer when you want to run scripts 

But a) it's not called a runtime environement  b) it's need disappears 
when you use REBO/SDK to "hide" your industrial secrets or when you 
don't want on purpose the client to install or know that  it's rebol 
behind.


2) by speudo compiling (byte code compilation) you allow people that 
need it to be a step closer to the hardware but keeping the portability 
effect so a rebol VM in my opinion should be able to  run both  a 
speudo binary file or a text script rebol file. Of course  like in 
java people would feel the need to share their software with embeded 
 Rebol Runtime Environement.


3) Having a runtime environement is the best modular way ...  core 
will be the base then you have View and lot of othe modules that 
wil clip to rebol. for example if i  put  import  "oracle" at the 
begining of my script then rebol runtime environement knows that 
he need the oracle package and goes to rebol.com to retrieve it and 
install it to the proper rebol runtime place in order for the vm 
to find it. Something close to what apt-get is to debian. REbol Environement 
doesn't comes with the whole thing but if the script tells it he 
can expend it selves in the fastest way. Well this runtime organisaton 
in  fact already exists but it's not pushed to it's extend, you know 
the point where the good idea become the best idea. the rebol/view 
2 implies a /desktop which implies a local scrit library (like a 
cache) to store the rebol script see the idea is there but once again 
it's not pushed to it's limits. Only rebgui used this system to store 
an extension to rebol.


4) by being closer to what people extend as an output you make them 
interessted in your input . To be more explicite by giving to peope 
what they are used to get in the end of their creation process then 
you allow them to be confident in your solution and to be more interressted 
on the way you propose to build your software.


5) i took java and .net as main example but if you look closely this 
is an expending tendency. For example Adobe Flash do that.


6) the other interrest in the compiled way is to merge the source 
code and the related resourcies at the same place (1.exe  file for 
example) and then forbiding the people to change their contents ... 
and this leaded then to the skining my application modo. Wich is 
just the we don't merge in the resulting binary the resourcies . 
In rebol we can already easyly build a script merger with data to 
output a .r file containing both but then people can still extract 
the ressourcies and change them etc...

Since you haven't been participating as much, you don't know how 
far along we are, so you don't understand how incredibly dumb it 
would be to scrap the code base and start over. We are only working 
on one VM. If someone else wants to start another project, fine, 
but they should have a good case for allocating the resources, and 
not do anything to preclude others from helping them.

ok so we have a rebol base in a language that means alot of work 
to have it on windows / linux/ macOSX  and some mobile thingies

Silverlight and Moonlight are good. If you want to make a REBOL browser 
plugin, they are the thing to beat. Flash is not as good, and not 
really competition if it weren't for the installed base.

Check the other !REBOL3 groups before you make any suggestions to 
throw out a code base that is already being used for commercial development.

R3 handles events on a timer base. So there is at least a way to 
do cooperative multitasking.

Just reading new roadmap - http://www.rebol.com/roadmap.html... 
what I don't understand is all the fuss about R3+. From the very 
beginning, I don't like the idea of putting some usefull stuff into 
additional module. E.g. - why some usefull mezzanines or protocols 
be part of the plus package? What I fear is - anything, that is optional, 
will not be a standard. I can understand that we can't include 100 
protocols probably, but talking about + package, where the only protocol 
we have is http, and even that is not fully functional, is a bit 
preliminary :-)


Interesting note about R3 DB - what is R3 DB port? Is Rebin, RIF, 
finally coming? Or did we decide to select one DB, e.g. SQLite engine, 
and include it into R3?


As for tasking - "Experiment: how far does the current R3 multitasking 
base take us?" - no experiments, please :-) Tasking/IPC is the last 
missing stone before we can claim R3 being a beta - it needs solid 
work, and I expect 1-2 months, and the same kind of impact, as Unicode 
transition, or Extension, Callbacks had :-)

It's a plus for a lot of platforms to be able to build on a minimal 
base. For instance, I would have loved /Base on WinCE.

The question is what tradeoffs are best? I have to say, even with 
Base available, I like having everything just work out of the box. 
How much does each exclusion save us? This is a tough call. Of course 
I want things lean and mean, but I also don't want every script I 
write to have 5 or 10 lines of import statements for what we've come 
to expect as standard functionality.


Do we have any kind of cross reference or dependency list? That is, 
do we know exactly what we're talking about?

The same goes for the 'sys boot level argument - it is also imo not 
accurate. Boot level arguments don't directly link its meaning to 
system contexts and hierarchy. They are more like packages of functionality 
to boot. 'sys should be imo definitely replaced by 'base, which we 
are used to for all those years ...

Maxim, you made a couple of wrong statements:

it obfuscates the meaning of what that context is...
 (about changing 'exports to 'lib):

Actually, if you read the boot levels blog post, you might notice 
that the R3 module system is now optional at the base boot level, 
and to a certain extent at the sys boot level too. The new role of 
the 'lib context is to be a runtime library - it is not dependent 
on the module system anymore, nor does it necessarily contain any 
exports from anything.

it also makes 'LIB a reserved word in general

Nope, you can override 'lib or 'sys locally in any module or script 
you need to. It might not be a good idea to do so, but that doesn't 
mean that it is not trivially possible. On the other hand, in top-level 
module code the words 'export and 'hidden *are* reserved keywords, 
so watch out.

Carl used -'base name, for some thing, which is almost useless, apart 
from few gurus. But I understand why such mode is needed. It just 
should be called 'debug or so. I thought that boot-level is about 
"packages of functionality", and for all long years, by 'base we 
refer to minimal runnable rebol environemnt ...

All I needed to know in the past is, that for CGI I need fast system, 
which will not load unnecessary code, e.g. help, etc. Hence I used 
/base executable. Now:


base - initialize only the lower levels. This option is for special 
purpose testing only because it provides no way to load external 
code. (No schemes, such as file access, nor load or do functions.) 
If your host-kit build is crashing on startup, you can use this option 
to confirm that the exe image is loadable and runable.


sys - initialize up to and including the basic runtime lib and sys 
contexts. This option allows you to run a very "lean" system (minimal 
memory and boot time) where your code will be supplying all other 
run-time functions and modules. Provides a basic load function but 
with very limited special options (no import, needs, versions, or 
related features.)


mods - initialize up to and including lower-level resident modules. 
In addition to boot-sys, this level adds high-priority resident modules, 
but not mezz plus (higher level mezzanines).

The 'base boot level *is* the minimal running REBOL environment. 
It's just that R3 can run in a *much* more minimal environment than 
R2 can, so the base is smaller. At least Paul should be happy, as 
he has been requesting this for R2.

If you want something as high-level as R2's /Base, use -b 'mods.

OK, but in base, you don't have any load or do - it is practically 
useless, no?

I want to understand the stuff. So - if 'base does not allow load 
or do, I can't execute any code? I can not load additional stuff, 
etc?

No, 'base is not useless, it's just useful in more rare circumstances. 
Users like Maxim will likely want to replace all of that stuff anyways.

I like the SDK aproach - you get your base, and then you include 
any mezz funcs/packages you want. This all now sounds so cryptic 
...

Here's a low-level function to parse and process script headers, 
which shows how many features are built into the base script model 
in R3:

load-script: funct [
	"Decode a script into [header-obj script-ref body-ref]"

 source [binary! string!] "Source code (string will be UTF-8 encoded)"
	/header "Return the header object only, no script processing"

 ;/check "Calculate checksum and assign it to the header checksum 
 field"
	/original "Use original source for Content header if possible"
] compose [
	data: either string? source [to-binary source] [
		unless find [0 8] tmp: utf? source [ ; Not UTF-8
			cause-error 'script 'no-decode ajoin ["UTF-" abs tmp]
		]
		source
	]

 ; Checksum all the data, even that before the header or outside the 
 block
	;sum: if check [checksum/secure data]  ; saved for later
	
	if tmp: script? data [data: tmp] ; Find the start of the script
	
	; Check for a REBOL header
	set/any [hdr: rst:] transcode/only data
	unless case [
		:hdr = 'rebol [ ; Possible REBOL header
			set/any [hdr rst] transcode/next/error rst
			block? :hdr ; If true, hdr is header spec
		]
		:hdr = [rebol] [ ; Possible script-in-a-block
			set/any [hdr rst] transcode/next/error rst
			if block? :hdr [ ; Is script-in-a-block
				unless header [ ; Don't decode the rest if /header
					data: first transcode/next data
					rst: skip data 2
				]
				true
			] ; If true, hdr is header spec
		]
	] [ ; No REBOL header, use default
		hdr: [] rst: data
	]
	; hdr is the header spec block, rst the position afterwards

 ;assert/type [hdr block! data [binary! block!] rst [binary! block!]]
	;assert [same? head data head rst]
	
	; Make the header object, or fail if we can't

 unless hdr: attempt [construct/with :hdr system/standard/header] 
 [
		cause-error 'syntax 'no-header data
	]
	; hdr is a correct header object! here, or you don't get here

 ;if check [append hdr 'checksum  hdr/checksum: sum]  ; calculated 
 earlier

 ;assert [sum =? select hdr 'checksum]  ; Should hdr/checksum be reserved?
	

 if header [return hdr] ; If /header, no further processing necessary

 ; Note: Some fields may not be final because post-processing is not 
 done.
	
	; Skip any whitespace after the header

 ws: (charset [1 - 32]) ; For whitespace skipping (DEL not included)
	if binary? rst [parse rst [any ws rst:]] ; Skip any whitespace
	
	; Check for compressed data and decompress if necessary
	case [
		; Magic autodetection of compressed binary
		tmp: attempt [decompress rst] [
			data: rst: tmp  ; Use decompressed data (no header source)
			append hdr 'compressed  hdr/compressed: true ; Just in case
		]
		; Else not directly compressed (without encoding)
		(select hdr 'compressed) != true [] ; Not declared, do nothing
		; Else it's declared to be compressed, thus should be
		binary? rst [ ; Regular script, check for encoded binary
			set/any [tmp rst] transcode/next/error rst
			either tmp: attempt [decompress :tmp] [
				data: rst: tmp  ; Use the decoded binary (no header source)
				hdr/compressed: 'script  ; So it saves the same way
				; Anything after the first binary! is ignored
			] [cause-error 'script 'bad-press -3] ; Else failure
		]
		; Else it's a block, check for script-encoded compressed binary
		tmp: attempt [decompress first rst] [

   data: rst: tmp  hdr/compressed: 'script  ; It's binary again now
		]
		; Else declared compressed but not compressed, so fail
		'else [cause-error 'script 'bad-press -3]
	]
	
	; Save the script content in the header if specified
	if :hdr/content = true [
		hdr/content: either original [source] [copy source]
	]
	

 ;assert/type [hdr object! data [binary! block!] rst [binary! block!]]
	;assert [same? head data head rst]

 reduce [hdr data rst]  ; Header object, start of source, start of 
 body
]


Note all the commented assert statements: they are for testing (when 
uncommented) and documentation. Also, I later removed the checksum 
calculation from this code because it was the wrong place to put 
it, at least as far as modules are concerned. However, Carl didn't 
know this because he was working on it while I was offline for a 
few days.

On the contrary, there are bugs in CC which seem to only occur with 
binaries built from the hostkit. So you have a wider base of testing.

The host kit uses the same code base, but it uses extra code that 
core doesn't. Code that we haven't adapted yet.

If the binary-only is a binary built from the hostkit sources with 
the only difference that the r3 libs are statically linked instead 
of dynamically, that is the same code base.

maxim, from the userside (this is how I can talk about /library) 
the wiki from ladislav sounds very good. containing all solutions

for the current problems (pointers, fixed length arrays, nested structs,
conversions). the pointer conversion is cool too. 


what about taking the current solution and these ideas from ladislav 
as 

a clean base and built later additional higher abstraction layers 
for e.g.
automated C header or calling conversion?

for example actually being lua ruby or python most of their "regular" 
use  are to be merge as plugin into a host application that shares 
data with them Allowing to set up a base that will not change and 
an extention that will be faster to create ... This point is still 
in my opinion a strutural problem in rebol since in rebol data structure 
are hum ... special  and cool. 


One thing you can't do in rebol and that will miss us alot is for 
example the hability to create a ready made structure  in memory 
and map a file content directly to it. (For example in case of  "memory 
dumped files" in C ...) I could provide a detailled example but i 
think most of you saw what was my point...