AltME groups: search

I was interested in erlang before it got popular .. but it's code 
always looked very ugly and complex .. then I got one e-book about 
it .. and in book where I knew what what I was looking it seemed 
very very clean in concepts

yes :) .. I still think it's code concepts are very nice and clean 
but it's hard to see them when you look at code

One way:

On startup:
-- check for your timestamp file

-- If it does not exist or  (it exists and timestamp is over 2 minutes 
in past), proceed to run

-- otherwise, wait 65 seconds.  Test if timestamp has changed: yes-halt; 
no-proceed

While running:

-- write the  timestamp file at least once a minute with an updated 
time

On clean closedown:
-- delete the timestamp file.

Drawbacks:

-- application could take over a minute to restart if immediately 
restarted after a crash.

-- manual deletion of timestamp file can lead to multiple instances 
running (you can minimise this by re-reading file and aborting if 
timestamp is not the last one you set)
-- all those writes of the file.

Well, you can clean it up to a usable structure on read, process 
it nicely, then regenerate the bad XML on write.

Nice language - clean and small, pretty to look at, compiles to native 
code.

more clean...

parse-out-date: func [
	trial [string!] /local day
][
	trial: parse trial "-,/"	
	all [
		negative? now/zone 
		integer? attempt [first to block! trial/2]
		;** swap day/month
		insert trial take next trial
	]
	attempt [to-date form trial]
]

Does this do it?
    clean-path %//

Yup. On R3 it's slower though, sincee clean-path is mezz.

You can clean up input. Accepting invalid input is another matter 
- that way leads to exploits.

Will, this is the one I did:

get-path: func [
  "Calculates the relative path between two directories."
  p1 p2 /local i p3
] [
  p1: clean-path p1
  p2: clean-path p2
  p3: copy %""
  until [
    any [
      find/match p2 p1
      not p1: first split-path p1
      not append p3 %../
    ]
  ]
  append p3 find/match p2 p1
  either p3 = %"" [%./][p3]
]

Yeah, sorry, TO-RELATIVE-FILE doesn't do full relative, it's mostly 
a variant of CLEAN-PATH. I wrote the R2/Forward version for use in 
DevBase 2, included it in 2.7.6, then ported it to R3. It's one of 
the two functions where the flow went the other way (IN-DIR being 
the other).

It was originally used to clean up saved file/directory preferences, 
where the default app behavior follows the portable app model: Data 
and settings going in subdirectories of the app directory. If they 
aren't subdirectories, they're absolute paths.

yes.  it would be exceedingly easy, since you have state information 
about things being clean or not, and liquid is 100% class based OOP 
(as opposed to prototype) so once a node has been defined, it can 
be freely JIT, since every reference to the instance is referenced, 
not bound.

now, dropping the if for an all, speeds up things minimally, but 
it clean up the code

I've just finished my tests... I've got a keyed search func which 
returns the exact same results as feach but  20 times faster!

I'll put the whole script in the profiling group... it  has several 
dataset creations for comparison and includes a clean run-time printout.

local-request-file is only available for Windows and Mac ... and 
the Mac version supports a subset of the functionality available 
on Windows (e.g. no multi-item selection). Two simple examples of 
usuage:

	open-file: make function! [
		/dir path [file!] "Default file name"
	][
		all [ 

   local-request-file path: reduce ["Open" "" clean-path %. either dir 
   [compose [(path)]] [copy []][][] false false]
			join third path first fourth path
		]
	]

	save-file: make function! [
		/dir path [file!] "Default file name"
	][
		all [ 

   local-request-file path: reduce ["Save" "" clean-path %. either dir 
   [compose [(path)]] [copy []][][] false true]
			join third path first fourth path
		]
	]

Clean console?
>> ? content
No information on content (word has no value)

So far it's just a working mess - take it or leave it - I will clean 
it and document in a future.

There is probably nobody here who can find it useful, but I've uploaded 
new XFL related scripts:

https://github.com/Oldes/rs/tree/master/projects-rswf/xfl-clean/latest

https://github.com/Oldes/rs/tree/master/projects-rswf/xfl-combine-bmps/latest

The first one we use to clean XFL sources, the second to merge bitmap 
assets into pow2 textures.

Maybe it is just coloring, which distracts me. Whole background etc 
- beige, like in XP. I would vote for Detective design - clean, modern 
....

Time to clean up radio-group and drop-list. With radio-group I'm 
contemplating getting rid of all the ID code and making it default 
to:

	data [1 "Opt 1" "Opt 2"]


if no option is selected. You'll still be able to start with no option 
selected (either by specifying none or 0), it's just that having 
no option selected by default is confusing to new users.


For drop-list, I want to fix some of the remaining bugs and add the 
two changes discussed above; clicking anywhere in the area to activate 
the drop list and pressing DnAr to activate it by keystroke. The 
first change could really confuse folks used to changing focus by 
mouse click so I'm thinking of making it an option, say "options 
[click]". Comments?

A word on my design philosophy, which might help determine whether 
you can live with the standard widgets or not.


I like widgets that are small, efficient and satisfy the majority 
usage case. I want to be able to look at a widget I or someone-else 
wrote and "grok" it quickly. When I rewrite a widget I'd like to 
make it simpler and more efficient. Let's look at tab-panel as a 
case in point. It now does everything I'd reasonably expect it to 
do:

	1) Multiple tabs
	2) Auto label size determination
	3) Automatic widget size and resize
	4) Supports Tab actions

 5) Options to start with another tab selected and fire the initial 
 action


The code is simple, clean, efficient and weighs in at just over a 
hundred lines. I can look at it and "grok" it in a couple of seconds. 
But there are many additional things it could do:

	1) Ability to add/remove tabs at runtime
	2) Ability to rename/reorder tabs
	3) Handle case where tabs > available display width


But you get diminishing returns when you implement functionality 
to support these operations as they don't constitute the major usage 
case, and you can code most of them at the app layer by treating 
the tab-panel data block as a block of data that you can manipulate 
and display (via an unview/redisplay sequence).


But what about the third point, where the tabs don't fit? Isn't that 
a problem? No, that's an app design issue. It's no different from:

	display "Test" [
		text 10 "Some long text that doesn't fit"
		radio-group 20x5 data ["Option 1" "Option 2"]
		drop-list 15 data ["Some long text that doesn't fit"]
	] 


You have to allocate sufficient space for your widgets to render 
correctly. If you need to render volumes of data that won't fit then 
use area or a list type widget (e.g. text-list, drop-list, table, 
grid, etc).


My aim is to progressively review and rewrite each widget to conform 
to the above design philosophy, starting with the simpler widgets 
and leaving the more complex ones till last. I'm about half way through 
at present.

It's just so i can create a clean screen capture with out the borders

I need to clean up my old source then!

I will prep up some logos, and a few alternative treatments.


You can actually simply take anything you like from Quilt.  The art 
is not complete, let alone finished.  Meaning, I have to go clean 
everything up in the next 30 days.  The art is being designed to 
allow several concepts:

-	Faster rendering through HTML.

-	Ability to change the colour theme with nothing more than a few 
simple CSS changes (o art changes).


For example, the Search icon is really a white magnifying glass, 
with a Knock out (alpha channel).  This way, the Search input and 
button are nothing more than a table with a cell with a green outline, 
and a box that is solid green.  Add the small image and presto, custom 
widget.  One can simply change the colour for a new look.

Sorry Graham, I was in vacation recently. Yes, now I have write access 
to the repo. I will need to clean up a bit before posting my changes 
though.

It seems to work on macs that were upgraded from Tiger without doing 
a clean install or an archive and install. Some library is being 
carried over from the Tiger install, I think.

A tiny bit of status report:


- Working on ports now. It's a very straight forward system, if you've 
been reading the docs.

- Carl found a bug in the garbage collector that would speed up a 
loop test case from 35.2 seconds to 6.4 seconds.

- After a while of core unicode testing, graphics is finally going 
back in. The third test version of View with unicode is going to 
be released soon.
- Still no unicode support inside View graphics, though.
- 445 bug reports so far.

- HTTP protocol recently done (IMHO a very nice and super-clean implementation 
of http1.1 by Gabriele).

- Test case system temporarily put on hold. Ports are more interesting. 
:-)

- WAIT now switches between efficiency and accuracy. It's accurate 
but CPU intensive when selecting a WAIT lower than 1 ms, because 
in those cases it uses it's own routine for waiting, but it can be 
done much more accurately than the OS timer. When above 1 second, 
it uses the OS timer.

Simple, Clean VID Requirements - http://www.rebol.net/r3blogs/0132.html

hum but it's fast on my computer and that's a pre-alpha double dash 
++ X 2008 version  (that's way there is the probes) If I go enough 
far in the process obviously I will do a clean share. That's just 
to show  wich direction it takes and puts some animation here while 
we are pending for news from R3 ^^. I plan even to declinate it to 
wrok with rebGUI and do a synntaxe colored widget wich could be used 
for an IDE for example

As far as I can tell there are animation effects in it as well as 
a small suite of debug tools. Each source file is really small, around 
2-8 kb with a few going above 10 kb. Fully commented and very clean.

oh no, I hope we did not go with read-string and all possilbe read-my-file-format 
instead of clean read/as and decoders aproach?

Most major UI frameworks have theming support nowadays, mostly to 
support system theming - it's a checklist item when comparing frameworks. 
Not as much of a deal killer as a lack of Unicode support, but still 
what people expect. A clean, unified cross-platform look is a necessity 
to include, but making it the only look would reduce the uptake of 
REBOL. Many business apps need a platform integrated look, and many 
other apps want to establish their own identity (look at WinAmp, 
Chrome or the Apple apps).

We turned the system from low level clean gob design to single-gob-SVG 
renderer ...

Bloated is the opposite of working correctly, as a clean design is 
one of the design requirements. So, 1.5 negates 3 :)

Steeve, the reasons for minimizing the parse proposals are given 
in the proposal doc, but they boil down to these:

- Clean, simple and powerful is not only the REBOL way, but more 
efficient at runtime. It's the greatest strength of PARSE.

- PARSE is only one dialect of many in REBOL, and they are designed 
to be used together.

Some status (not much since Pekr told most of this):


- Improved console presentation (sounds so Windows-like, doesn't 
it? :-)) in the latest R3 alpha. http://rebol.hmkdesign.dk/files/r3/gui/178.png

- Carl wants to do a larger release of R3 "soon". This involves a 
merge of my skin or parts of it. I'm not sure everything you see 
in screenshots can go in, because those parts are not clean enough.
- Still working on RebDev.

- Carl noted that RebDev helped him find many bugs in R3. Some of 
those are fixed.

- GUI has not progressed for a couple of weeks as I'm working on 
a big R2 project. I will get a few days in January to help, but I 
won't get more time until mid-March at best.
- Some Devbase submitted changes and fixes are added to R3.

The intended priority for RebDev front-ends is:

1. R3 Shell (doing this now)
2. HTML mobile (doing this now)
3. R3 GUI
4. HTML pretty
5. R2 Shell
6. RSS feed
7. Whatever people want to do.

You mean that programming language syntax and data syntax don't match 
exactly. LOAD is for REBOL syntax, and we want those errors for REBOL 
syntax. Those thrown errors help you clean up your bugs.

I was working. I just fixed LOAD, DO and CLEAN-PATH, and they will 
be incorporated tomorrow. The current build has built-in functions 
to get to DocBase, RebDev and CureCode. We're really close to release.

I'm aiming to open up REBOL to "all data" analysis and I don't see 
where that should scare normal rebols from going about producing 
good clean parses just as today;  with the addition of a foreign! 
datatype that has semantics of "junk"

ALTME is not the best medium for that type of  effort.  The forum 
remains with some clean code and examples.

The process now is to clean up the skin, making it as simple as possible 
first (no gradients or prettiness for now), so Carl will be able 
to approve it and so I've started from scratch, fetching in the styles 
one at a time. During this process, I've exposed a few problems and 
solved those, so it was a good idea to do that.

Eh, there is many docs written by Carl, that are forgotten. DocBase 
became a mess, it needs serious clean up (e.g. all docs about VID3 
should be removed, it confuses ppl). When I told to Carl, that we 
need release notes, he told me he needs to think about doc structure. 
So I pointed him to one year old Doc of his (earlier alphas) and 
he told me he forgot about the doc :-)

Yeah, I have just been working on a whole-package browser spoofing 
client, not just the user agent. I should clean it up and port to 
R3.

>> source launch
launch: make function! [[
    {Runs a script as a separate process; return immediately.}
    script [file! string! none!] "The name of the script"
    /args arg [string! block! none!] "Arguments to the script"
    /local exe
][
    if file? script [script: to-local-file clean-path script]
    exe: to-local-file system/options/boot
    args: to-string reduce [{"} exe {" "} script {" }]
    if arg [append args arg]
    call args
]]

Steeve, if you are worried about your English the reviewers can clean 
that up in your tickets, with your permission.

It's not a big deal. Steeve can post to Curecode and request for 
a clean up.

We needed the system object changes for modularity and security too. 
Once we clean up for those, multitasking won't be that hard.

but there is definitely one thing that needs to be added, unless 
its just not documented.   the ability for import to RESTRICT what 
is exported by the module. 

this is the most powerfull concept in slim and I'll never want to 
live without it.  


in slim, its the module USER that has control over the module.  when 
you load the module, by default it uses the module's expose list, 
but if you supply your own, then the module doesn't expose anything 
else than what you ask of it.  


this allows me to have a clean current context, and I can prevent 
my module from cluttering the context its loaded in.  especially 
if its loaded AFTER some code has been defined, or using common global 
words.

brian I know all of that...   /only is a choice, not a burden.   


the way it is setup up now, we are imposed the decision of the module 
author.  its EXACTLY like people who currenly use:

set 'word func [][]


this is very bad design, even more if the module functions themselves 
require words to be global.


PITL requires control over modules.   in all languages which have 
modules, name clashing is always annoying.


python has a very nice module system, cause you import specific words 
or all of a module.   with a few hundred libs as standard they had 
to make it clean.  I think they did their homework.

Apples idea how to do real concurrency (on multicore) .. http://images.apple.com/macosx/technology/docs/GrandCentral_TB_brief_20090608.pdf
-- it seems to be based on something like closures (or blocks from 
smalltalk)  -- it seems simple and clean idea

R3 file! paths ignore multiple / characters, though the CLEAN-PATH 
function replicates the leading multiple / fill-in-the-blanks behavior 
of R2 file! access, relative to a cuurrent directory.

To not to be able anymore to reduce this [( )] at this [ ], is really 
annoying.

I have to clean my reduced blocks from unset! values returned by 
called functions.

Really, I don't  understand such modified behavior in R3, what's 
the gain, what the purpose ?

I want a reduce/clean refinement T_T

just so its clear... 


wrt MODULES, I'm not at odds with the work you have done brian, which 
is very clean and well done... I'm at odds with the philosophy itself 
of the module model Carl decided to use.  It doesn't change anything 
wrt to R2's scalability problems, a part from removing paths in DO. 
 that's just my PoV and people aren't obliged to agree with it.  
:-)


python's module management is the best I've used, cause users have 
control, not the modules.  And since its a language based on the 
use of modules, I hoped we would follow that path.  but it seems 
not. what can I say.  

slim R3?  ;-)

Anyvay when you play with demo IP applications you can find that 
rebol doesn't clean memory the consumed memory grows slowly but after 
few hours/days you could be short of memory IMO. Not good for serious 
(server) application.

How are things going on adding a few schemes?  


I mentioned that I would review the docs and add more examples; however, 
if someone has implemented a simple scheme example, like finger or 
such, then let's use that as the starting point, clean it up (if 
necessary), and put it on the wiki for others to learn from.

ftp://ftp.compkarori.com/pub/clean.exe

I just paste functions into the text area and run clean script on 
it ...

clean.exe is just a text area that has clean-script running on  a 
button.

Henrik, trying to answer your questions/issues :


to serve multiple document roots on the same site without having 
separate domain names

 => Use sub-domains for such isolation. Everything that's under one 
 domain can be accessed with /.. parent syntax. I think that you can 
 hack it around with ALIAS, custom webapps on-page-start event  handler, 
 but there aren't clean solutions. Use sub-domains for such isolation.

I think webapps require a bit more than static pages?

 => Just to make it clear, webapps are REBOL applications interfaced 
 with external world using RSP scripts. Webapp are not meant to be 
 container for *only* static pages (HTML/CSS/JS/images).


attempt [load join request/config/root-dir %/app-init.r] ; TBD: report 
errors !!! [...] 
RSP: error in events from %app-init.r now logged. 
That's from the change log. That's not correct.

 => Yes it is. What's being logged so far is the errors caught at 
 runtime in event functions declared in app-init. What need to be 
 logged is the LOAD %app-init.r process (syntax errors at boot time).


after a lot of experimentation, the latest encapped version was the 
only one that worked properly.

 Both encap and sources versions works well on Win/Mac/Unix. The issues 
 you have are related to running a rebol app as daemon in console 
 mode on a remote Unix server (without a UI desktop). Cheyenne can 
 work in source mode on such server, but it's much easier and pratical 
 to use it in binary form in such case (typical remote linux server 
 case).

so, now app-init.r works for whatever reason. at least I can observe 
that changes to app-init.r only take into effect after restarting 
Cheyenne.

 => Webapp are persistent application in memory. RSP pages will be 
 reloaded on modification but %app-init.r can't without "restarting" 
 the whole application. As there's no clean/reliable way to completly 
 "unload" a Rebol app from a Rebol session, it requires to restart 
 the whole processes (all the worker background processes that may 
 have run your webapp). This can be achieved either by restarting 
 the whole server, or better, by using the "Restart Workers" feature 
 (documented in the changelog file). For unix: kill -USR1 <pid> (where 
 <pid> is Cheyenne main process id).

SVN r45 : Web Sockets support


FEAT: experimental Web Sockets support added. (See %www/ws.html and 
%www/ws.rsp)
FIX: regression on bad HTTP request filtering. (Thanks to sqlab)
FIX: minor code clean-ups.

to lazy to clean it up

curecode is also visually full while very clear and clean

What need for clean templeting is access to the html source file. 
I'd use the element ID to match with a backing .r file variable / 
component model. No scripting, no tags in the html file. So the question 
is, how can cheyenne let me map these two files?

What I need, is a clean html page that my code would not touch directly.

Oldes: we have one here somewhere, but I can't find it right now. 
Anyway: 
 

1) "kill -9" is not a good way to stop Cheyenne, a simple "kill" 
is the right way (this signal is caught by Cheyenne to clean up things 
and exit properly).


2) "ps aux | awk ..." is not required, Cheyenne stores its main PID 
in /var/run/cheyenne.pid (or /tmp/cheyenne.pid in revisions < r90). 
Just read this PID and send all signals to that process only. Watch 
out if you run it on port <> 80, you'll find the port-id inserted 
in the PID file name.

Long ago, there was a RESET function in REBOL.  It would restore 
the runtime environment without reloading the exe.


This allowed REBOL to run as an apache mod, because the process would 
persist and could start "clean" each time.

Such a thing could be done in R3.

let me try a clean checkout

Max: I am very busy today, I am not sure I will have time to review 
your code now (you should send me a copy of the changed files first 
BTW). As you could see, supporting such feature at the config file 
level is complex because of config file being loaded only when HTTPd 
service starts (for historical reasons). I am not sure that initializing 
the HTTPd service ahead is a clean solution (the boot/ line has become 
a bit hard to read with this /no-start flag that loads and init HTTPd 
service...).


The solution I had in mind was to extract the whole config file loading 
from %HTTPd.r and put it in %cheyenne.r. This is a deep and complex 
change, that is why I was waiting to have enough time to do it in 
a single working session. Anyway, I will examine your solution first.

I would like to take this opportunity to clean up things and hide 
the low-level mess under a unique abstraction layer.

Thanks for the summary. I need to study every cases first anyway 
and find a clean and simple way to implement it. My first idea would 
be to use a custom scheme for that, like vfs:// that would resolve 
all virtual paths transparently.

I'm getting a *very* weird problem launching cheyenne from win7.


using a clean download of the latest build sources, if I try to start 
up the cheyenne.r by double-clicking on it in windows, it fails. 
 

no tray icon appears, the rebol process is running buts its dead 
(no pages are served, and no workers are launched).


if I try to run it a second time, I get the console which tells me 
it can't open the rconsole and logger ports (so cheyenne actually 
did start)., but the "no response" flag appears on the window title 
and its as dead as the first instance (I even get the busy mouse 
cursor treatment). 


but if I start it from the command-line, using the exact same command-line 
that I see in the task manager, I have no problem!


to make this even more strange, dragging the cheyenne.r script icon 
on the rebol.exe icon, launches cheyenne without any issues!

launching it from my editor's automated script launching setups also 
works without issues.

all of these show the exact same command-line in the task-manager 
(which includes the -qs rebol flags).

note, I am *not* running cheyenne as a service.

Questions:
1) can any one else replicate this (am I going mad ?  ;-)
2) why does this happen?
2) can this be solved?

I will have a lot more experiences about this in few months because 
I am just working on this stuff regarding the API and export. I used 
aditional get param so user can select what format she wants. But 
I was educated by this guy that I should look at Accept headers, 
which I ignored happily ..:) .. same about statuses which I didn't 
use. Now I am getting home at this, so we can talk in a while and 
determine the most systematic and clean way for this. And such that 
will make the REST purists happy

Graham, you code looks clean, i like it

putty is the best place to start work on adding SSL to R3.  its all 
there, in MIT it is 100% stand alone and the code is compact and 
clean.

i've finally come up with a clean (imho) low-level interface:
mbox: open pop3://
until [empty? msg: read mbox]
close mbox

I won't complain though. Your code is excellent. Clean and easy to 
read. Very nice.

I need to port it to the latest R3.  There was a point where the 
GC got changed and the real-time performance went crazy, and I want 
to blend it into the new architecture...so I don't want to put out 
something that requires an old R3 alpha...and the dialect is not 
100% clean...guess I'm being kind of a Carl here...not ready for 
prime-time yet.

http://www.rebol.org/view-script.r?script=clean-script.r

Ashley, that's a pending bug, already posted in curecode.  (I'm waiting 
to see if anyone reads the Host Kit source code. Compared to anything 
else, it's so clean and simple.)

How about allowing: clear object!


This could set all object! words to none. Would be a nice way to 
reset an object! into a clean state.

the problem is, that such a situation cannot be "hidden" by any number 
of hacks, but there is an easy and clean solution: just allow the 
majority of contexts to not contain the word 'self

By "conflict of interests" I mean:


1) the interest to have seamlessly working loops, functions, closures, 
Use, etc. By "seamlessly" I understand "working without ever doing 
unsolicited 'self binding.

2) the interest to have a simple syntax for Mold/Load to describe 
these contexts


As far as I am concerned, 1) is a priority for me, therefore I prefer 
to have a different syntax for this type of contexts. Another possible 
option, which *might* be considered as an alternative is, to have 
a /self refinement for Bind as in BIND/SELF, since that variant covers 
the minority of use cases (just objects and modules), but I doubt 
it cold be called "functionally clean" anyway, thus, probably still 
violating 1)

Yes, Andreas, my point of view is the same. This solution is clean 
and working.

yes, that is very reasonable for me, as a clean solution

The point is that we would have a clean way to refer to an environment 
which is not conflated with an object.

pekr... here I must say, you really do not know what you are talking 
about.


all the binary changes brought to R3 are due to user responses about 
how fucked up it really was to use binary stuff in R2.   really. 
 I had to build binary data-driven TCP servers in R2, for example, 
and I had to use so many shitty work-arounds and fix up numbers .. 
it was an ordeal.


R3 makes binaries, clean, no hassle and simple.  they are a simple 
series of bytes, nothing more.


they are manipulated from the start to the end in that order.  that's 
all there is to it.

probably we need a new FSM dialect, parse is not suited to do that 
job. We have to do too much hack to simulate a fast and clean state 
machine.

Once the module system is revamped we can start working on making 
many of the mezzanines optionally included. We plan to clean up the 
namespace :)

Otherwise, here is one, feel free to optimize:

delete-dir: func [dir /only criteria] [
	dir: clean-path dir
	foreach file read dir [
		if any [not only do func [file] criteria file] [
			file: dir/:file
			if dir? file [delete-dir file]
			delete file
		]
	]
]

Earlier prototypes worked well. They were functional, clean, and 
simple. Understandable.

 - that simply means, that Carl does not like something about current 
 system ...

I meant to say that I was starting work on the *release* itself (preping 
and cleanup folders of bogus files, and basically uprooting the current 
compilation setup into new clean folders, while doing a little bit 
of diffing on the released A107 to see if any oddities have crept 
in the code.

tried A108 from console, and got:

** Script error: clean-path word is not bound to a context
** Where: if -applier-

** Near: if slash <> first boot [boot: clean-path boot] home: file: 
f...

If our goal is not to break things, yes. If our goal is to clean 
things up for the long term, now is the time.

I find that R3 is the right time to address these issues in the language.


R3 is already incompatible.  I don't see a reason not to clean this 
up.

What it actually does, is that it disables to write some, otherwise 
clean, code.

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?

people have to realize that R2 has routine! and struct! types.  we 
don't in R3.  so it a clean slate, I can't just improve the R2 system... 
there are fundamental differences in the API which add features, 
but also remove some...  due to this fact.