zsx / r3 Goto Github PK

See this demo for an example of the bug: https://github.com/saphirion/documentation/blob/master/r3/r3-gui/examples/layouts/layout-32.r3

The rebol >> prompt is emitted before the call result when /shell is used.

I understand why the message is displayed, but I think it would be better to not display the message at all. For instance, when only one r3 executable is on a system and it is used in an X environment and other times in a console-only environment, it would be handy to have the message not display by default. Tried using -q and -c to turn it off, but neither worked.

My original Problem with demo crashing on i3wm has been resolved, Now I get the following error.

demo
Fetching demo...
Script: "Untitled" Version: none Date: none
Fetching GUI...
** Math error: math or number overflow
** Where: + repeat do update-panel actor all foreach do-actor case repeat do update-panel actor all foreach do-actor either -apply- apply case view catch either either -apply- do try demo
** Near: + min-heights/:i max-pane/y: either any [
max-pane/y = m...

Manjaro Linux, xfce4 with i3wm,
linux binary r3-view-linux 2014-02-21 16:03 from this repository.

When attempting to build from vcbuild.bat (which has to be modified to detect VS2015 by looking for the VS140COMNTOOLS variable), there are 40 symbols that end up not being defined in the final link step:

_T_Library, _T_Routine, _PD_Struct, _T_Struct, _T_Callback, _Call_Routine, _Init_Serial_Scheme, _dtoa, _STRTOD, _Cmp_Struct, _MT_Struct, _MT_Routine, _Free_Routine, _reb_i32_add_overflow, _reb_u32_add_overflow, _reb_i64_add_overflow, _CT_Routine, _CT_Library, _CT_Callback, _CT_Struct, _Struct_To_Block, _reb_qsort, _reb_i64_sub_overflow, _reb_i64_mul_overflow, _Init_Core_Ext, _OS_Close_Window, _OS_Destroy_Graphics, _OS_Image_To_Cursor, _OS_Show_Soft_Keyboard, _OS_Get_Metrics, _OS_Init_Windows, _OS_Update_Windows, _OS_Open_Windows, _OS_Init_Graphics, _OS_Load_Cursor, _OS_Destroy_Cursor, _OS_Set_Cursor, _Dev_Serial, _WinMain

When attempting to build from the r3.sln, VS2015 has the following errors:

Severity Code Description Project File Line
Error C1083 Cannot open source file: 'C:\Users\Vincent\Documents\dev\rebol\src\libffi\src\x86\win32.S': No such file or directory libffi C:\Users\Vincent\Documents\dev\rebol\make\msvc\libffi\c1 1
Error A2088 END directive required at end of fiplai libffi C:\Users\Vincent\Documents\dev\rebol\make\msvc\libffi\Win32\Release\win32_plain.asm 1
Error C1083 Cannot open include file: 'ffi.h': No such file or directory r3-view C:\Users\Vincent\Documents\dev\rebol\src\core\t-routine.c 33

New asserts caught an invalid access coming out of maps, so I went and looked and saw this line, that has been there since R3-Alpha:

https://github.com/rebol/rebol/blob/25033f897b2bd466068d7663563cd3ff64740b94/src/core/t-map.c#L160

When a hash miss occurs, it stores the current length of the data array in the hash slot, plus one.

The "wide" parameter is the length of the record, with the key at the head. For a map's data array, this is always 2. But some routines like UNIQUE which use the hashing will use another number:

>> unique/skip [a "b" "c" a "d" "e" z "f" "g"] 3
== [a "b" "c" z "f" "g"]

Failures apply to all clients of the hash, including map and set operations. One is unlikely to get a localized crash, because the off-the-end-writes are statistically likely to write into allocated memory in the memory pool...so a corruption that causes a crash later on something non-map related would be typical. Besides the corruption of writing the hash numbers outside of where they're supposed to be, the numbers not being in place leads to false negatives, e.g.:

>> union/skip [1 1 2 2 2 2] [] 2
== [1 1 2 2 2 2]

The problem here is that it's not dividing out the width when it stores the index. Usually it does, for instance when making the initial hash:

https://github.com/rebol/rebol/blob/25033f897b2bd466068d7663563cd3ff64740b94/src/core/t-map.c#L190

And this is important because it's going to multiply that width back in when it does the access:

https://github.com/rebol/rebol/blob/25033f897b2bd466068d7663563cd3ff64740b94/src/core/t-map.c#L129

If the width isn't divided out, then the multiplication will yield the wrong number that is quite likely outside the bounds of the array data.

I've not used maps much, but this is a pretty serious indicator that they didn't work! Patch seems to be to divide by the width:

metaeducation@9311640

There is another serious bug uncovered relating to the usage of /SKIP in the set operations, also with a relatively brief patch:

metaeducation@5e2fa93

Lots of bugs coming out of it, hard to pick just one...but here's one (try in R3-Alpha):

>> intersect/skip [1 2 1 3] [1 1 1 5] 2
== []

about

---

** REBOL 3.0 **

** Copyright: 2012 REBOL Technologies **
** All rights reserved. **
** Website: www.REBOL.com **

** Version: 3.0.90.4.20 **
** Platform: Linux libc6-arm **
** Build: 8-Aug-2014/17:30:20 **

** Language: English **
** Locale: United States **
** Home: /home/odroid/ **

---

a: view/no-wait [text "Test"]
== make gob! [offset: 894x551 size: 132x21 alpha: 255 text: "REBOL: untitled"]

to-image a
Segmentation fault (core dumped)

Hi,

just would like to let you know, that with this commit: f397fae
you introduced regression that wait with just time value is not precise enough.

Before:

>> t: now/time/precise wait 0.001 now/time/precise - t
== 0:00:00.001

>> t: now/time/precise wait 0.001 now/time/precise - t
== 0:00:00.001

>> t: now/time/precise wait 0.002 now/time/precise - t
== 0:00:00.002

>> t: now/time/precise wait 0.002 now/time/precise - t
== 0:00:00.002

Now:

>> t: now/time/precise wait 0.001 now/time/precise - t
== 0:00:00.002

>> t: now/time/precise wait 0.001 now/time/precise - t
== 0:00:00.01

>> t: now/time/precise wait 0.001 now/time/precise - t
== 0:00:00.01

>> t: now/time/precise wait 0.001 now/time/precise - t
== 0:00:00.019

>> t: now/time/precise wait 0.002 now/time/precise - t
== 0:00:00.014

>> t: now/time/precise wait 0.002 now/time/precise - t
== 0:00:00.01

(tested on Windows)

do %r3-gui.r3
either not request/ask "" "Do you like this?" [alert "No!"] [alert "Yes!"]

seg faults in 3.0.0.4.40 Linux libc-x64

This type of code https://gist.github.com/gchiu/9a6c16ce0bbc3ecc5be4455c3e096832 I think should show some SSDP activity but nothing happens. Similar code for Rebol2 sees SSDP network activity being broadcast.

I tried to perform the following:

write/append %orders.txt enline rejoin [order-text "^/" mold order "^/"]

and Windows popped up a requester stating that r3.exe had stopped working and was going to be closed. Tried the same script on the mainline r3.exe build (Win32), and it worked as designed.

During the source conversion a coverity instruction was moved to a double slashed comment line - may need your review to see that it works: https://github.com/codebybrett/ren-c/blob/20151117-source-conversion/src/os/posix/host-error.c#L71

If changes are required to support coverity then the parser on/around this line may need to change: https://github.com/codebybrett/ren-c/blob/20151117-source-conversion/src/tools/common-parsers.r#L148

As an aside, I believe @hostilefork has more editing before he applies the conversion to ren/c.

i: 9'999'999'999'999'999'999
== 9223372036854775807

Tested on Linux odroid 3.8.13.23 #1 SMP PREEMPT Sun Jul 6 04:53:31 UTC 2014 armv7l armv7l armv7l GNU/Linux

** Version: 3.0.90.4.20 **
** Platform: Linux libc6-arm **

In src/mezz/mezz-help.r function load-gui says Spahirion's instead of Saphirion's.

The reb-value.h and reb-series.h files are part of some dependencies that really should be gotten rid of, and I think the only usage R3-View has is here:

struct rebol_series* img = (struct rebol_series*)GOB_CONTENT(gob);
int w = IMG_WIDE(img);
int h = IMG_HIGH(img);

That seems to be the sole use of rebol_series, and rebol_value is nowhere to be found. If that's it, and if RL_Gob_Width and RL_Gob_Height cover it, then I'm getting rid of those files now.

(I'll let you do add the RL_Gob routines in case you can think of something more generic like RL_Gob_Property that you might want...)

Check this console session:

>> recycle/off        ;<--- to make sure it is not GC related issue
>> <a>
== <a>   ;<--- correct result so far

>> load "22-Feb-2019" ;<--- this seems to make a problem
== 22-Feb-2019

>> <a>
== <>   ;<================= WHY THIS?

>> b: 1 ;<----------------- this makes it normal again
== 1

>> <a>
== <a>   ;<--- correct result again

There seems to be a problem unless I'm misreading it in that a server UDP port has to have a read on the port before it starts processing READ events.

So, something like https://gist.github.com/gchiu/0c26eddfdb89a688445e0167ef004d76 line 31 or 32 is required before incoming messages appear.

Trying to view a root gob like: view system/view/screen-gob should return none or throw an error instead of crash.

>> find/any "A1" "A?"
== none
>> find/any "A1" "A*"
== none

show none crashes Rebol.
You should (for example) add test for none value here:

Each call to view without providing own handler is adding the default view handler into handlers block here:

The default handler should be added only once or the handle-events function should replace handler with same name as the new one instead of adding it multiple times.

At one point I noticed that git was trying to get something from a 10.x.x.x ip address for reb-skia. Not sure if there's a machine down or if someone forgot that it was a local IP or what.

When I try to run a script that contains a UTF-8 character(s) in its filename or path, rebol fails with this error messages:

Path: /home/esko/tmp/sandbox/今日は/ascii

$ rebl ~/tmp/sandbox/今日は/ascii/whatdir.r3 
** Script error: invalid argument: %/home/esko/tmp/sandbox/ä»æ¥ã¯/ascii/
** Where: change-dir either -apply-
** Near: change-dir first script-path either exists? second script-pa...
>>

Filename: /home/esko/tmp/sandbox/проба.r3

$ rebl ~/tmp/sandbox/проба.r3
** access error: script not found: %sandbox/пÑоба.r3
>>

$ uname -a
Linux hal 4.19.0-5-686 #1 SMP Debian 4.19.37-1 (2019-05-05) i686 GNU/Linux

P.S. A temporary workaround is using --do:

$ rebl --do 'do %sandbox/проба.r3'

Sorry to take so long on the FFI fixes. It's unfamiliar code, so when working out new code it's best to get them nailed down with familiar code for starters.

First a heads-up on what's changed. It used to be that the [0] element of an object's "varlist" was a FRAME! data type that helped in navigate to the second series, the "keylist". This FRAME! datatype was tricky and internal, never meant to be seen by users (and if they did it was likely a bug). But what it allowed one to do was to use a single platform pointer to effectively pass around a whole object, that you could later reconstitute with just Val_Init_Object(&value, frame).

There were a number of drawbacks to that, including that if you had a frame for some other context type (such as an ERROR!, PORT!, or MODULE!) that information was lost. So a lot of code that would extract a frame and pass it around, to later be given to the user, would come back with an object.

>> port: open %foo.txt
>> probe port
make port! [ ; << here, it's a PORT! 
    spec: make object! [
        title: "File Access"
        scheme: 'file
        ref: %foo.txt
        path: none
    ]
    ...

>> words: [spec]
>> bind words port
>> bind? first words-of port
== make object! [ ; << now, it's an OBJECT!  :-/
    spec: make object! [
        title: "File Access"
        scheme: 'file
        ref: %foo.txt
        path: none
    ]
    ...

It was a bit convoluted, introduced a new type the user shouldn't see, and wasn't adaptive to things like if the various context types had the struct fields in the cell change. So the better idea seemed like to put in each paramlist a canon instance of the value itself. Hence the [0] would be an OBJECT! if it were an object, a PORT! if it were a port, ERROR! if an error, etc. If you wanted to get a copy of that value back, you'd just copy out of that position.

This same thing seemed to be applicable to functions...so it was applied there as well. The [0] slot in the paramlist was no longer unused, but a value of that function. This made it easier to pass functions around by just a pointer and get the whole value back.

That helps some in the FFI where previously it had been necessary to work a bit harder to pass a function around by its payload:

Now it doesn't have to, one pointer will do:

https://github.com/metaeducation/ren-c/blob/bc3356d8ff8c42b1ec9275595398b2df2b069e53/src/include/sys-value.h#L1749

The mistake I made (or at least one) when taking the "all you need is the one pointer" mentality to the FFI was that I didn't extract the whole value to reconstitute it. I replaced the line for filling in the whole payload with something that effectively only filled in the paramlist. The right answer is to copy out that value from slot 0 in its entirety:

metaeducation@bc3356d

Note that should also mean you could use a callback that was a closure (for instance), because it would get back the right type. (CLOSURE! is being expired and FUNCTION! is being fixed, but the point is still relevant...it's parallel to the issue about PORT! and OBJECT! above.)

Anyway, that actually seemed to be the only thing going wrong in the %qsort.r and %gtk.r cases. So let me know if there's anything else.

Other issues:

• The WRITABLE bit is now checked in debug builds. This means it's possible to make any value you want read-only as far as a debug build is concerned, but it also means that to make a REBVAL slot writable you have to "format it" for writing. That's done in series automatically, but if you create a REBVAL on the stack you have to use VAL_INIT_WRITABLE_DEBUG(&value); on it before you can write to it. Due to randomness of stack memory, you may or may not be warned about it if you forget...though you'll be warned more often than not, since a zero bit in the least significant position means "read only".
• Let me know if you feel there's still something worthwhile to be learned from the Ren-C Split branch. If you're able to link up the GUI now then it's old news and out of date...so if I can let it go then that keeps the number of things I look at in lists every day down by one. :-)
• Rebol Debugging! A start at it, anyway...

Here is some output from r3-serial compiled by Josh Shireman:

gs: open serial://ttyUSB0/57600
write gs "m"
print to-string read gs
m
------- HARDWARE TEST MENU -- 1=on 0=off-------------

Here is the same test using the latest executable from this repo:

gs: open serial://ttyUSB0/57600
write gs "m"
print to-string read gs
m

I always only can read the characters I sent out via serial, but no other serial data come through. I verified that writing to serial works fine, but reading from serial appears to be broken.

this is ok:

y: make struct! [ c [struct! [a [uint8!]]] ]

this is also ok:

x: make struct! [ a [uint8!] ]
y: make struct! [ c: [struct! [a [uint8!]]] x ]

but this is not:

y: make struct! [ c: [struct! [a [uint8!]]] ] ;<--- CRASH (as there is expected the value)

This is OK:

>> x: #{FF00FF00} debase/base enbase/base next x 2 2
== #{00FF00}

but this is not:

>> x: #{FF00FF00} debase enbase next x
== #{FF00FF}

Here is fix I did in my brench: Oldes@767fd06

Can be reproduced using:

make struct! [a [int32]]
evoke 2

A new commenting format is proposed for the Rebol C sources for which your acceptance is sought.

Example:

//
//  quit: native [
//  
//  {Stop evaluating and return control to command shell or calling script.}
//  
//      /with {Yield a result (mapped to an integer if given to shell)}
//      value [any-type!] "See: http://en.wikipedia.org/wiki/Exit_status"
//      /return "(deprecated synonym for /WITH)"
//      return-value
//  ]
// 
// While QUIT is implemented via a THROWN() value that bubbles up
// through the stack, it may not ultimately use the WORD! of QUIT
// as its /NAME when more specific values are allowed as names.
//
REBNATIVE(quit)
{

To see the effect of this in context with other functions see the draft conversions at: https://github.com/codebybrett/temporary.201508-source-format-change/tree/master/src

An introductory comment to a function declaration will contain rebol function metadata indented from slash by two spaces, a blank line, then any ordinary comments set off from double slash by a single space. Extra blank lines around the function description make easier reading.

Your opinions would be welcome in the chat room.

When I try to input utf8 characters in my Linux terminal window via input or just in REPL, I get ?? or ??? (depending on number of bytes). print input, print to-string input do the same.

On the other hand "view" handles utf8 just fine. For example

view [ f: field button "Click" on-action [ print get-face f ] ]

prints every utf8 character as expected.

By the way, windows terminals (both cmd.exe and cygwin) get and print utf8 correctly.

Linux linuxhost 3.16.0-4-586 #1 Debian 3.16.7-ckt25-2+deb8u3 (2016-07-02) i686 GNU/Linux
Windows 7 Home Basic (russian)

I tried building metaeducation/ren-c (a fork of this repo with some build files incorporated from rebol/rebol) with OS_ID=0.3.02 in order to get a 64 bit Windows build.

The preamble in the resulting executable incorrectly states:

Platform: Windows dec-alpha

This led to seeing that https://github.com/zsx/r3/blob/atronix/src/boot/platforms.r and https://github.com/zsx/r3/blob/atronix/src/tools/systems.r seem to disagree on the ID for a Windows 64 bit build. How come the 64 bit exe you provide has the correct tag in the REPL if you are using OS_ID=0.3.02 to build? Is your executable produced from another source tree?

>> s: make string! 256
>> call/output "dir" s
>> s
== none

I wanted to give you a heads up on an impending plan, and get your input about it--based on your experiences and what directions you might have seen for the FFI.

The direction I'm moving in is to get everything under one FUNCTION! type, where the sub-behaviors are based on a couple of bits in the type-specific flags. It's not too hard to imagine the user understanding that a "NATIVE!" is a function that perhaps when you say BODY-OF and it doesn't give anything back (or gives some internal identifier, like an ISSUE of #45 or something like that) However, ROUTINE! is a bit different.

So it got me to thinking about how it might be done another way. This other way would be to have a single FFI-dispatch "native" which took a description of what to call and then a function frame to decode. So for instance imagine there were no ROUTINE! but something more like a MAKE ROUTINE! that produced something like:

gtk-init: func [argc [integer!] argv [integer!]] [
    ffi-dispatch #[library! [...]] "gtk_init" this
]

I'm using this as a placeholder for something that would get the currently running frame, right now you can get it via binding, so imagine something morally equivalent:

>> gtk-init: func [argc [integer!] argv [integer!]] [probe context-of 'argc]
>> gtk-init 10 20
make frame! [
    argc: 10
    argv: 20
]

But to paint the rough picture, the idea would be that some structures that are built and managed on the C side would instead live directly in the body, and be associated that way. The FRAME! very lightweight--size of a REBSER node only (2-pointers-in-size larger than a REBVAL, plus one pointer and change for overhead), and has a data pointer directly to the stack.

It seems to me that if FFI-dispatch did the frame decoding, what you'd have won't be much different than today in the invocations. However I think a big win here could be if a lot of the MAKE-ROUTINE part of the logic of doing the prep work could be Rebol code. If it needed to do some kind of precalculating it could even do that into a binary that could be passed along as a constant. For that matter it could do all precalculation so the call winds up looking like:

gtk-init: func [argc [integer!] argv [integer!]] [
    ffi-dispatch #{73CAD0...E5F9} this
]

I'll have to look more into it. But because I've only started thinking about this recently, it's not urgent. I just thought I'd mention the direction to you now in case you had any thoughts.

I changed some code that started creating a lot of series--one per function call (though most of the time this series should just be GC'd). Unfortunately, tight loops wind up making quite a few before the GC has a chance to get called. So it's easy to hit high water marks in memory that don't get released.

There are some things that can be done about it, and I expected it to be a performance hit... but I saw something strange with it seeming to GC on just about every cycle. Then I saw this code here:

https://github.com/metaeducation/ren-c/blob/8d29c1169c69dc5b9e733bfe39fa7c0f7b3220dd/src/core/m-gc.c#L1244

The GC_Ballast has always been a bit of a mystery to me, and I imagine you have looked at it . But when I put some debugging code in to print out numbers at this point I got back things like this:

PG_Mem_Usage = 14515476
TASK_BALLAST = 60
GC_Ballast increased by half -52
Recycled 0
PG_Mem_Usage = 14515476
TASK_BALLAST = 90
GC Ballast cut in half 298
Recycled 2
PG_Mem_Usage = 14515476
TASK_BALLAST = 45
GC_Ballast increased by half -11
Recycled 0
PG_Mem_Usage = 14515476
TASK_BALLAST = 66
GC_Ballast left alone 114
Recycled 1
PG_Mem_Usage = 14515476
TASK_BALLAST = 66
GC_Ballast increased by half -46
Recycled 0
PG_Mem_Usage = 14515476
TASK_BALLAST = 99
GC_Ballast left alone 147

So it has gotten to the point where it is GC'ing very frequently with a tiny TASK_BALLAST that is just sort of flipping around at small numbers, and it's recycling one or 2 series at a time.

If you've looked at this code can you give some insight into what it should be doing? Is this expected behavior that it thinks 14 MB is too much and really won't keep going without a GC every cycle?

Example:

write %test.txt "a^/b^/c"

When opening %test.txt in Notepad, for instance, you'll see:

abc

read %test.txt
== #{610A620A63}

Brett's got the Ren-C file headers conversion going and we'll be wanting to run it in a bit. But I wanted to put it out there for feedback in case any modifications are requested. Here for instance is a file nonexistent in R3-Alpha where the copyright is to Atronix:

https://github.com/codebybrett/temporary.201512-file-headers/blob/master/src/core/t-routine.c

We're moving to a different model for credits, which is basically to curb the idea that people are trying to maintain lists of names in the source file and instead put together a CREDITS.md. What that will be like isn't set in stone, but basically it's a chance for everyone to link and say what they want to up front in the repository. So if you and David have a way you would like it to be it's temporarily a wiki to sort that out:

https://github.com/codebybrett/temporary.201512-file-headers/wiki/Draft-CREDITS

Brett says he's going to be unavailable for a while so it will probably be > 2 weeks before the conversion runs, so there's time to get feedback...and of course it will be in the source repo, so it can change after that too...

The reason I asked for it to be a bit "heavier" with those line breaks is because I do want to have some sort of unit of divisions within the file for sections. Again, this is not set in stone. But once you have sections it would be weird if the header were too much "lighter" than the section is... it would be like having larger fonts further down the page for subsection headings.

The //=/////=// is used to avoid triggering three-slash syntax highlighting for Doxygen etc. Also, kind of cool looking. :-)

r3-make-linux is a link only. misses r3-make

Such a code should not be allowed:

>> s: make struct! [ a: [uint8] probe random 100 ]
25
>> mold s
== "make struct! [a: [uint8] 25]"
>> spec-of s
== [a: [uint8] probe random 100]
>> probe make s []
make struct! [a: [uint8] 25] ;<---- the spec is not used anymore

As reported by user "Rex" on rebolforum, read/string crashes/hangs current dev builds:

>> system/version 
== 3.0.91.3.1 

>> system/build 
== 22-Oct-2014/15:07:38 

>> read %umlauts.txt 
== #{C3A4C3B6C3BC} 

>> read/string %umlauts.txt 
== (R3 crashes here) 

On a current Linux build (from b040420), read/string creates an infinite signal loop (printing [escape] over and over and over).

Was going over some old unmerged pre-Ren/C bits on files.

I found that I had hit CureCode #1422 and noticed that Append_Event() wasn't doing anything to signal the events to be processed. The clients seemed to think it did. Then there was a smoking gun of a NOT_USED_INVESTIGATE in Do_Signals regarding the handling of said event.

This fairly minimal fix might take care of it:

https://github.com/metaeducation/ren-c/pull/116/files

I restored the EVENTS_LIMIT but added your chunking code in case someone needed an expanding event queue at some point.. So it's initialized to a smaller queue to force expansion, to keep that tested if it is needed.

In testing with the TCP port prober from #1422 I noticed that the output I got was different from with just the large queue. I got:

TCP-event lookup
port 1 is open
TCP-event lookup
port 2 is open
.
.
.
TCP-event lookup
port 200 is open

So it was printing this extra "TCP-event lookup" message, which comes from the "default awake handler". I do not know enough about what the schemes are supposed to do to know if that is good or bad. But what I did notice was that these lookup events were indeed pending, because if I ran a WAIT after running the scan in the large-queue-method they'd all come piling out and printing anyway.

In any case, submitted for your review.

Downloaded r3-32-view-linux-dev from Atronix website and get this issue:

./r3-32-view-linux-dev 
./r3-32-view-linux-dev: /lib/i386-linux-gnu/libgcc_s.so.1: version `GCC_7.0.0' not found (required by ./r3-32-view-linux-dev)

uname -a
Linux alpha 4.9.0-6-686-pae #1 SMP Debian 4.9.82-1+deb9u3 (2018-03-02) i686 GNU/Linux

read https://stackoverflow.com/users/login

will cause a windows crash whereas the Saphir version reads the html fine.

rebol/version
== 3.0.0.3.1

Hi,
I get the following error message when starting the 32bit linux version with no display.

XOpenDisplay failed, graphics is not supported

It then starts up, but if I make a simple network call like read http://rebol.com then I get a segfault.
Linux version kernel is -
3.4.62-53.42.amzn1.i686

I can work around it be setting up xvfb which resolves he issue.
Thanks
John

I hit some barriers trying to update Do_Commands() in response to some changes, which forced me to stop and look to understand what it did.

Once I understood what it did I quickly looked at how to get rid of it. It's a bad version of DO which claims to be "faster" (though I very much doubt it is would be noticeably so). What it will do is break error reporting, debugging, etc.

R3-View has 2 uses in a switch statement in %host-draw.c:

case CMD_DRAW_PUSH

case CMD_DRAW_SHAPE

Looking at that REBCEC it seems like the only thing that's happening is that Do_Commands() gets called with the block...and it runs but with the commands getting the ctx->envr passed through.

I committed my guess on what would in practice provide the effective same behavior for these cases. It just has a global REBCEC pointer that is pushed when you start RL_Do_Commands and popped before it returns, and the Do_Command dispatcher passes on whatever the state is:

metaeducation@41ba66d

I would think it should be the same for reasonable input... because if it suddenly starts evaluating arguments that means that it was passing FUNCTION!s to the commands before--seemingly unlikely (?) It also could be a problem if you start calling other extensions and they're not able to interpret the context. But that also should not happen for existing code since the existing Do_Commands() calls were all are expecting to get the same context anyway.

If you run into problems with that let me know...