AltME groups: search

ICarii, using what OS and what version of View?

I assume, looking at the order of top-down, that the next Bus-OS-Stop 
for beta releases will be linux? :-)

so except fonts, we now have linux and os-x Views compatible already?

make-char-elements: func [name count /local result][
    result: copy []
    loop count [insert tail result reduce [:name [char!]]]
    result
]


OSVERSIONINFO: make struct! compose [
    OSVersionInfoSize [integer!]
    MajorVersion      [integer!]
    MinorVersion      [integer!]
    BuildNumber       [integer!]
    PlatformId        [integer!]
    (make-char-elements 'CSDVersion 128)
] none
OSVERSIONINFO/OSVersionInfoSize: length? third OSVERSIONINFO


;-- Requires NT 5.0 (NT4 SP6) or later
OSVERSIONINFOEX: make struct! compose [
    OSVersionInfoSize [integer!]
    MajorVersion      [integer!]
    MinorVersion      [integer!]
    BuildNumber       [integer!]
    PlatformId        [integer!]
    (make-char-elements 'CSDVersion 128)
    SvcPackMajor      [short]
    SvcPackMinor      [short]
    SuiteMask         [short]
    ProductType       [char!]
    Reserved          [char!]
] none
OSVERSIONINFOEX/OSVersionInfoSize: length? third OSVERSIONINFOEX


;---------------------------------------------------------------

lib: load/library %kernel32.dll

GetVersion: make routine! compose/deep [
    lpVerInfo [struct! [(OSVERSIONINFO)]]
    return: [integer!]
] lib "GetVersion"

GetVersionEx: make routine! compose/deep [
    lpVerInfo [struct! [(OSVERSIONINFOEX)]]
    return: [integer!]
] lib "GetVersionExA"


; load the OS version info data.
OSVI: OSVERSIONINFOEX
if 0 = GetVersionEx OSVI [
    OSVI: OSVERSIONINFO
    GetVersion OSVI
]

free lib

;---------------------------------------------------------------

get-CSDVersion: func [OSVer-struct [struct!]] [
    trim/tail to string! copy/part at third OSVer-struct 18 128
]

ExInfoAvailable?: equal? third OSVI third OSVERSIONINFOEX


OSPlatform: [
    0 Win32s    ; Win32s Win32s on Windows 3.1.
    1 Win32     ; Win32 on 95, 98, SE, or Me.
    2 WinNT     ; WinNT Win32 on Windows NT.
]

major-ver: OSVI/MajorVersion
minor-ver: OSVI/MinorVersion

major-ver?: func [val [integer!]] [major-ver = val]
minor-ver?: func [val [integer!]] [minor-ver = val]


PlatWin32s?: does ['Win32s = select OSPlatform OSVI/PlatformId]
PlatWin32?:  does ['Win32  = select OSPlatform OSVI/PlatformId]
PlatWinNT?:  does ['WinNT  = select OSPlatform OSVI/PlatformId]

Win95?: does [all [PlatWin32?  major-ver? 4  minor-ver? 0]]
Win98?: does [all [PlatWin32?  major-ver? 4  minor-ver? 10]]
WinMe?: does [all [PlatWin32?  major-ver? 4  minor-ver? 90]]

WinNT?: does [all [PlatWinNT?  major-ver <= 4]]
WinNT351?: does [all [PlatWinNT?  major-ver? 3  minor-ver? 51]]

Win2K?: does [all [PlatWinNT?  major-ver? 5  minor-ver? 0]]
WinXP?: does [all [PlatWinNT?  major-ver? 5  minor-ver? 1]]

WinServer2003?: does [all [PlatWinNT?  major-ver? 5  minor-ver? 2]]

os x but geomol ryoed on linux I think a swell

Or an os where you don't have write permissions

Maybe it's your OS and not Rebol ?

rebol 2.7.7 , os windows serwer 2008 x64

I'm not familiar with changes MS has made to make the OS 64 bit. 
 Does this change apply to all API functions?

I think it's part of the virtualization stuff that 2008 does to make 
the 32 bit app think it is running under a 32bit os.

(BTW, I get to say this because the first 64 CPU OS architecture 
I helped design was in 1981 at HP.)

I"m looking for an open source OS platform that doesn't have library 
hell ...

full ack BC, graham if you need (like) zfs try freebsd, it's already 
there. 
better perfomance, cleaner handling and much faster than linux. 

if you need a wm try xfce or lxde. feels like running win 3.11 on 
a quadcore.


for rdbms look also at monetdb, in nearly all cases 5-10 times faster 
than mysql.

very advanced designed dbserver and a nice abstracted query layer 
for sql and xquery. 

if you need a good allrounder/workhorse try postgresql (scales good 
on multicore)

free- or netbsd is a solid base for this. (but only until a real 
smp ready microkernel
os like minix is finished :-)

I have come across a strange problem with View 2.7.7 on Mac OS X. 
If I load a library, run a function from the library and then put 
the machine into sleep mode, Rebol crashes with a Floating Point 
Exception when the machine wakes up. Here is ahte console session:

>> mylib: load/library %Code/Pascal/libtestlib.dylib
>> add1: make routine! [a[int] return: [int]] mylib "myfunc" 
>> add1 12
== 13
>> Floating point exception


I compiled and tested the library under Windows, put the machine 
to sleep, no problem when it woke up. (I was running Windows as a 
Virtual Box VM).

Any suggestions?

waking up is where my mac or some application hangs.  though the 
lastest OS updates (I have leopard) seems to have pretty much cured 
these bugs for me.


it used to be that every 10 wake ups would require a hard-reset on 
my machine!   so this might not be specific to rebol, possibly just 
a compilation switch.

Jaime's test apparently ran from View/Pro under OS X 10.4

I have found that the problem with OS X View 2.7.7 crashing on wakeup 
was caused by a problem with the dylib. The root of a problem is 
a conflict between the linker on Snow Leopard and Free Pascal (the 
problem didn't exist on Lepoard).


I have a workaround which is to statically link the pascal code into 
a C "wrapper" dylib.

Yes, it's screwed up, but the screw-up is because permissions are 
user-based rather than app-based. This problem is shared by Linux, 
OS X, and most other Unix-serived OSes.

It's a common mistake in OS design, and in some cases one that is 
mandated by law (DOD rules).

Operating systems may react badly to that, because they may expect 
their standard file extension. R3 extensions are OS dynamic libraries 
and are expected to be registered that way in the system

Just in a program, not the OS. Each program loads its own modules 
and extensions. Unless R3 *is* the operating system.

You can use different IMPORT blocks depending on the OS, in the same 
code. The highest-level script is usually a not a module, so you 
can call IMPORT directly. Then your modules can just do their requirements 
by (word) name instead of specifying filenames.

Exactly, so every program needs to test on which OS it runs and execute 
different IMPORT branches. So why not pull that into IMPORT itself?

IMPORT uses the OS's dynamic library loader, which searches through 
the system's locations where libraries are registered. So you install 
R3 extensions there, in the system. If you use .rx extensions, they 
will be the only ones, awkwardly between lots of .so files on POSIX 
systems and lots of .dll files on Windows

The common use case is a modular operating system. You have a standard 
R3 installed. During the life of the system, you install new extensions 
and programs. R3 makes the extensions be operating system dynamic 
libraries and lets the OS look for them, so they must be installed 
in the OS. You don't want to also have to embed each new extension 
in a new R3 binary. You want to install and write separate REBOL 
scripts that load these extensions, and you want those scripts to 
be cross-platform, because they easily can be

So, you want to make a modular OS that has all dynamic libraries 
be R3 extensions natively - LOAD-EXTENSION won't load arbitrary libraries, 
just extensions - and you want the library filename suffix to be 
something other than .rx. OK.

Oldes, R3 has decided to let the OS find an extension as a native 
library. I really don't want to override that and write my own loader 
in every script

A system-wide loader like that is a feature of an OS that starts 
once, not of a language platform that launches many times

Do you acknowledge my concern at all, even after learning that R3 
uses the OS loader?

Once the program closes is not usefull at all. Think about R3 as 
an OS. It somehow should track resources. And/or stuff like GUI etc. 
should be isoloted in some context which you could easily scrape 
- unset, free, whatever ... or the memory consumption will rise endlesly?

I don't think we are so far (making R3 OS) :)

So there is no way, how to "disconnet" an extension from your app, 
so that OS finds out - look, some not connected orphan here, let's 
clear the memory here?

Right, because R3 has no way of knowing what resources the extension 
is using. But extensions could be swapped out to VM if they aren't 
being used (depending on the OS), they don't have to stay in main 
memory.

You'd have to eventually call the OS loader again to unload ir

I've used a few applications which have their own extension names 
simply because there is a lot of overlap in names and clashing with 
the OS is very easy at some point.

I'd prefer using system names, only not the system load path management. 
  Rebol, should only look for R3 extensions withing its path configs... 
whatever they are... the R3 extensions *will* use the OS loading 
path, which is normal, since the extension is in fact a bridge between 
the OS and rebol.

The OS's shared library loader, that is.

it goes beyond name clashes... R3 extensions have a specific duty, 
we are not loading OS libs directly within R3... import must not 
try to access these.


I would prefer to have a specific loader for extensions something 
like.

EXTEND my-extension

yep we agree.   but I like having .rx also.    its something pretty 
standard on windows to have different names for dlls... the OS itself 
uses different names for various subsystems.

my only issue is that the interpreter musn't look for extensions 
in OS paths cause that will invariably lead to library management 
issues.   


many extensions are simply stubs for real OS libs.  furthermore, 
some stray lib could be picked up and cause dangerous side-effects 
when run by the interpreter.


if an R3 os package is built, any extension packages which are built 
for it, should dump the files in R3's own unique search-path setup.

What happens after that is up to the OS's loader.

no... only.  I really don't want rebol to start playing around in 
the OS, looking for extensions, if I set up a unique path.  really.

My whole point is: you want those paths _preferred_, but ultimately, 
if you don't find an extension in those paths, you should just fall 
back to the OS loader's search path mechanism.

This allows distributions with a strong library management to properly 
and fully integrate R3 into the OS.

Roughly summarising: an extension search path (preferred) + os loader 
search (fallback) + a cross-platform mechanism to load extensions 
via abstract names.


Could be as simple as reusing system/options/module-paths and load-extension, 
allowing the latter to take a word! parameter and also search the 
former. The possible extensions themselves are already in place (system/options/file-types). 
Loading is already done via dlopen, so loading a lib only by name 
(w/o any path component) will use the OS loader's search mechanisms.


And alternative would be to add a system/options/extension-paths 
(block!) option, and a dedicated loading primitive, say, import-extension, 
which searches the extension-paths and tries all possible platform-specific 
extensions (as per system/options/file-types).

You want an optional search path for extensions, and that's fine, 
but Andreas and I are pleased with the OS managing them

I'd also be fine with having module-paths used for extensions as 
well (before falling back on the OS search paths). In fact, I would 
prefer re-using module-paths over adding another extension-paths 
option.

While there wouldn't be a point to the OS managing REBOL modules, 
because it doesn't know what they are

But in any case, as you say, _don't_ take away the ability to just 
have extension search managed by OS mechanisms.

If you want to fully integrate R3 into an OS, that is a job for the 
host code. For most OSes you want as much isolation between the OS 
and R3 as you can get. Unless you have a locked-down OS (most don't) 
then what constitutes a "safe" extension would vary widely between 
programs. That is why the module-paths option and others like it 
are just set by default by the startup code, to be changeable by 
the program code as needed.

We do have a way to have extension search managed in a portable way 
by OS-specific means: LOAD-EXTENSION is implemented in the host code.

Yup. But keep in mind that for most potential R3 users (who like 
most users are running Windows, OSX or some stock Linux) the OS mechanisms 
for managing libraries shared between programs are really poor, and 
they are encouraging program-specific storage. I'm really interested 
in how you will experiment with integrating R3 with a properly managed 
OS, which (I hope) Syllable is.

Even though Syllable has its own dynamic loader in the kernel, we're 
not managing user space libraries vastly differently than Linux, 
which has a user space loader. The difference is in kernel drivers, 
which are standard ELF libraries just like user space libraries, 
which isn't possible in Linux. I consider this similar to the nice 
circumstance that R3 extensions are native OS libraries, which has 
similar integration benefits - if you take advantage of them

Maybe RMA team could set-up a blog too (re Amiga group post about 
OS 4.1 progress). I know there's probably not much time for that, 
but I do remember some of Henrik's articles, and it was really nice 
to read :-)

Carl challenged to port the graphics to OS X on Twitter, but that's 
fairly pointless in the current state

the point here is the dialect edicted by carl can be adapted to any 
other library so why not considere taking a library already ported 
to the 3 main OS. Wich we would have the full sourcing and the would 
even in a shrinked version of it to save us the pain to do X times 
the work X being the number of  OS we want the R3/GUI on ...  and 
this  will too avoid us compatibility issues...

so yes the goal seeked is for the rebol programer to have a transparent 
and portable API in rebol to make graphical user interface. But on 
the ground level you need to adapt the C code to your OS window management 
solution... With some specific tweaks for example on linux you are 
not obligated to have X11 started so you linux rebol/view -hostkif 
R3/GUI- have to detect if the X11 server is run and if it will be 
able to display things or warn you it can't

sorry to contradict you oldes but can you explain me what is that 
?  taken from r3-hostkit/Sources/src/os/win32/host-windows.c

my point is instead of having to do this interface 3 times for windows, 
linux, macOS X  why not  take the time to discuss the probability 
to do it with another library that could be use as it  on the 3 main 
OS ...

of course you must do this for each OS, there is nothing like only 
one solution.

oldes there is .... using GTK QT or wxwindows or even glut... or 
any other library that is already ported to those 3 OS and there 
is alot...

If the ground api isn't a problem then that' s again another reason 
to me to choose something else  that exists as same everywhere without 
need for you to change your C code  you just recompile it on the 
3 os and that's it .... Then we can talk  on  what is needed can 
a GTK+ or a QT 4  limited versions can fit our need. limited version 
means the ground functionnalities - widows management; display and 
event management -

Ok, except that the power of REBOL was that it can run under 40 different 
OS !

Nowadays, it runs good for R2/View under Windows and MacOS... Linux 
lots of problems because there's so many version of Linux...

And for R3/GUI we have Windows version... and when Windows 8 will 
be released... not sure it will work.

Community has falling down and it is hard with no open source to 
attrack new developpers... I know host-kit is hybrid open source 
model...

Real question in 2011 is : port language on JVM because every computer 
and device (except iPhone) has a JVM in order to reach the mass market.

Make it popular and then we can found money, people to work on small 
VM that make the power of Power.

I expect R3 being ported to JVM would be - slow. Carl can compile 
R3 library to the target OS in almost no time. The problem is the 
rest - OS dependant stuff - and this IS actually open source. It 
needs to be ported to target system no matter what ....

Pekr native is a pain that's all ... it took already 5 years to do 
rebol VM version 3 on windows 32 and it's not over and according 
to the source code of r3-host-kit there is no GUI part in linux or 
macOS X.. we don't know either if more than the 3 main os will be 
supported and in what extense. Doing a change on 1 VM  means finding 
a way to do it on all other VM that's why if i remember well along 
the years R2 was supported on lesser and lesser OS and that's why 
too the rebol VM source code grow to a point that it was impossible 
for Carl to maintain it .That was the main justification for the 
retrofiting of Rebol VM  in the rebol 3  project... mean while all 
the  industry changed can you seriously say that  java vm is the 
same now that it was 5 years ago same goes for mono.

Industry has move to the cloud, so we have to focus IMHO on the language... 
and RT must offer cloud Services... 

and when you reach the mass market you may consider to built small 
VM for specific OS... 

RT has fail his idiom to be portable on over 40 different platform... 
and worth of that is REBOL has no VM on iPhone, Android, Symbian, 
or WebOS... 

even if R3 and with host-kit in theory you can do it, who is going 
to do it ?

Nicolas, those 40 different OSes weren't really 40 different OSes, 
they were mostly different builds for at most a dozen different OS 
variants. Most of those OS variants are now no longer developed, 
or have changed so significantly that they are essentially different 
OSes now. The platforms that RT is actively supporting now for R3 
covers the vast majority of the current market, more than would be 
expected for an alpha product, and the host kit allows you to port 
it to the most obscure OS you want, as long as it can work on the 
scale that REBOL works at (not your microwave).


every computer and device (except iPhone) has a JVM in order to reach 
the mass market

 - Of the most popular smartphone platforms, only RIM and Symbian 
 (sometimes) have a JVM; iPhone, Android, WP7, and WebOS don't.

We need the ability to create events, and we should also be sure, 
that we are able to obtain modern events, as e.g. above mentioned 
FF4 can now handle multi-touch native Windows 7 event. And we are 
not even receiving such things as ctrl tab for tab handling. What 
I still don't understand is - the system port? Is that port still 
available in R3? And what was it good for? It would be e.g. nice, 
if by opening the system port, you would insert such a listener to 
the OS event model, registering for particular events. Well, that 
might be slow, if you are not carefull, but that way you might be 
able to receive any system event possible .... but not sure it is 
even possible :-)

actually better in all regards  :-)  but it had all the OS friendliness

no, taken from Carl's gui. How the hell scrollbar can be 16pixels, 
whereas progress is 22 pixels? It look like Mac OS-9 relic of the 
past, and is completly off with the rest of the design? I want to 
have it fixed, before I go mad :-)

Following few things:


- why is "custom" include needed? We should either user R3 native 
facilities, or include an include as a standard into R3 :-) (this 
is no real question, just a remark that if we find it usefull, then 
why notto make it part of R3?)

- RMA does not work with CureCode tickets. It would be good to either 
dismiss/close or resolve them? E.g. I find renaming of do-style and 
do-face to do-action, do-reaction a good tip to implement


- we should resolve the size of buttons vs scroller vs tabs. In Carl's 
GUI, button is 28 pixels tall, and it feels OK. Our's here is 22, 
I have no preference here, but could be those 28 pixels. Scroller 
is only 16pix - not acceptable imo. It should be of the size of the 
progress. Tabs are proportionally too tall.

- tabs should have line removed for actual tab. I suspect it might 
be more difficult to draw the container then.

- there seems to be someone at RMA liking Old aqua interface of MacOS. 
Tabs, buttons and scrollers are a good example ... of how to not 
do visuals anymore :-)

- area - enter few lines, go to bottom, and try to hilite the text 
by keyboard (shift plus arrow-up). It always hilites only actual 
line

- info areas, labes, etc., should prohibit display of caret, maybe 
allow hilighting, but allowing to have caret in "disabled" area is 
not looking nice

- text-table buttons are Excel filter inspired, but looking strange 
- some more thoughts needed
- select-an-option does not allow keyboard navigation

- text-list does not scroll, when navigated by keyboard, ditto text-table

- tabbing feels strange for text table. I alway said, that we need 
nested tabbing. I can imagine tab stopping on table, but next tab 
moving away, not actually going into tabbing in terms of the hilited 
widget. Enter should enter the more complex style, escape move away. 
That is not typical also at OS level, but then - everybody has it 
wrong :-)

- between the text-list and text-table, I have to press tab three 
times -visually I am not sure, "where" hilite disappears

- is text-table a compound style? What sense does it have to have 
buttons hilighted, not being able to enter the action? Why are not 
arrows tabbable? Table headers cells should be one style, not two.

- text-table is the weakest "grid" we ever had. Comparing to Cyphre's 
style pack, and rebgui grid. This is like 5% of functionality, not 
thought out style, useless for any serious data. I want to see the 
display of infiinte amount of data, proper caching.

- tab should be tabbable, ctrl-tab allowed to switch between the 
tabs  


I find the styles/gui inconsistent. There should be someone defining 
the styles, their behaviour to keyboard navigation, tabbing, etc. 
So far it seems like style being put together with no deeper thought 
about the end result of the whole GUI.

One general question to GUI/gfx gurus. I know it is very preliminary, 
but - what about scaling? I mean - playing with my phone, I wonder, 
if it is facility of mobile OS, or particular app is receiving some 
zooming info, and acts accordingly? Are we ready for something like 
that? Because just recently, what we do is - resize. But we don't 
scale (fonts). It is just question of catching particular OS events, 
and create particular actors?

I guess, it's extremely hard to create a really good and preferable 
GUI. I'm struggling with Cocoa and Interface Builder on Mac OS X 
atm., and I haven't seen any glimpse of a 'perfect' GUI in that yet. 
If I was to design a GUI, I would go for simpleness, and still make 
sure, advanced users can make the advanced things.

I had a couple of crashes that went away when I set trace on ...they 
were both on OS X and I think are related to memory issues. They 
are still open in CureCode.

So the Amiga is first from non mainstream OSes. Which one do we choose 
next? Any mobile OS takers here? :-)

Here is the problem with OS X host-kit release:
http://www.rebol.com/r3/docs/osx-linker-symbols.html

I seem to remember from last time we tried this... there's a special 
linker tool required on OS X.

So, I just wanted to post the doc above... and see if there's anyone 
who wants Host-Lib on OS X and is willing to solve the problem in 
some reasonable way.

Steve, on window close issue, we need to decide.


The issue is this: when use hits a close button (or causes OS-side 
close event), do we close the window at the host layer, or do we 
send an event, allowing the higher layer to pre-empt the close.

What we want eventually is for host-kit to detect ESC, and call RL_Escape 
for that too.  But, that requires that we use raw stdio processing 
(or use an OS that's good enough to detect and signal us on a specific 
key press), so it's not implemented yet.

I just implemented CTRL-C checking in OS event handler and I call 
RL_Escape() when it is detected. Seems to work fine now.


On Amiga, all signals must be explicitly checked for. This is both 
good and bad of course. The control is nice but the code duplication 
for things like CTRL-C is not.

So you mean that the OS should be able to control the closing of 
the window and REBOL should not be able to interrupt that?

Ah, so REBOL is in control and the OS must obey.

I am currently doing cleanup in the RDC_QUIT vector of the OS Events 
device.

Ok, seems we solved the OS X linking issue even for older toolchains.

Ah, very good. This solution looks like it does what is needed!  
I should have the OS X .so out soon.

A: yes, can export static lib for OS X and Linux.

Uploaded OS X libr3.so to github.
http://www.rebol.com/r3/changes.htmlupdated

Cool collaboration on the OS X build

Cool, now work on OS-X can continue ...

btw - I read some OS-X/Flash related discussions on OSNews, and it 
seems Adobe is being criticised for not using new API. Is that Cocoa? 
Now as we have R3 library available - will we target this environment? 
IIRC R2 did not use it?

Well, there should be no problem for us yet, no? So far, R3 uses 
SW rendering, there's not much to worry about in regards to OS-X 
API, no? Later on, as we have proper codec system, or we try to accelerate 
gfx or video, it might be a different topic.

Henrik, opening a browser is not really implemented in the OS X port. 
The methods that are tried are Linux conventions

Win7 Mo is a toy OS, as iOS is. If someone is able to port it to 
such phones, it will be good, but dunno how difficult is it going 
to be, or if it is even allowed ...

I may be missing something fundamental, but


1) am I supposed to be able to build a A110 r3.exe from the sources 
at github.com/carls/R3A110 on Windows with MinGW and gcc? The gcc 
makefile differs in a lot of places from earlier versions (A109 and 
below) and even seems to generate some .so's instead of .dll's. It 
fails for me with 

gcc  -c -O1 -D_FILE_OFFSET_BITS=64 -Wno-pointer-sign -I ../src/include/ 
 -o obj/host-main.o ../src/os/host-main.c

cc1.exe: error: unrecognized command line option "-Wno-pointer-sign"
before doing anything.


2) given that I somehow manage to build it and include my own changes 
in a clone of that repo, what happens to them if once there's a A111 
repo? I don't see how a A110 repo could be turned into a A111 repo 
- I would have expected to have a R3 repo on github and to have commits 
tagged as constituting a alpha version like A110, A110 etc.

The current "main" (src/os/host-main.c) is a good demonstration of 
what is necessary to init libr3 and eval strings.

I've found it.. rich-text is doing the conversion here:

https://github.com/rebolsource/r3-hostkit/blob/f331c6a46947e6e5afedc90f3d375bcd3f7ad8a1/src/os/win32/host-graphics.c#L714

Would TERMINATION be a good name as well.  


I would imagine that Rebol would have a common exit point (a place 
in the executable where all terminations go) before control is handed 
off to the OS.  If that is so, then the suggested code could be placed 
there, which should simplify intercepting QUIT or HALT.  To be more 
consistant, I'd like to amend my ERR? proposal to be "code to be 
evaluated after an error is captured and printed" instead of before 
being printed.

The only thing that cannot be intercepted is when the OS itself closes 
rebol for any reason.  An example would be a user clicking on the 
[X] box to close the window.  Although it would be great to have 
a CLOSE? termination condition, I certainly understand that Rebol 
would not be able to intercept that.  Now that I think about it, 
the only way that Rebol could intercept a CLOSE? condition is if 
the window panel itself is under Rebol control through the GUI -- 
but even then, that may be a difficult proposal to implement.

and because memory isn't released to the OS very often, I can make 
a fair guess that the GC doesn't compact on collect.