World: r3wp

CRT beams from the top..to bottom..

so, fairly arbitrary.  It would be good if that could be user selectable.

is there a reason why we want to start the origin elsewhere?


From most daily activities, origin for drawing , writing, reading, 
tends to start from top-left.

for postscript compatibility :)

for graph drawing.

Gregg - in RT QA channel Gabriele once put answer from RT, that there 
is definitely big plan for library interfacing improvements, plus 
much more .... well, we just don't know yet, what Carl has in mind 
....

I made a .h header file parser, which handled function names, typedefs, 
structs, and enums. It was made specifically for FMOD and FMOD EX 
libraries, but it is pretty general, able to be tuned for other libraries 
"fairly" easily.  Swig is probably the ultimate way, though it's 
not as easy as it sounds on the cover, and you might lose associtated 
documentation found in comments next to functions, struct elements 
etc.

I think with Swig you still need to be prepared to dive in pretty 
deep and swim around tying things together for a while.

I've done some little C processor dialect ideas as well, mainly to 
handle DEFINEs and convert structs to REBOL friendly data. I think 
those kinds of tools are useful and, for the amount of use they get, 
I prefer that approach to trying to do a complete C processor/loader. 
Ultimately, that might be good for some people, but I still want 
an interface dialect in REBOL that makes things easy to read and 
understand from a REBOL perspective. I think "dialect first, then 
tools".

I'm also willing to accept tradeoffs. I'd rather have a tool that 
can handle 80% of common C files, than to say it can't be done because 
of the other 20%.

For anyone who has written these kinds of tools, should we collect 
them all and see if we can come up with a spec we like, that is better 
than what we have today (e.g. that addresses the things that are 
painful today)? Does anyone want to be in charge?

I'll probably be getting back into C interfacing again soonish, so 
I'll probably have more to say after I refresh my memory on that.

About mezzanines in REBOL 3.

Instead of having hundreds (or thousands) of mezzanine functions, 
will it be a good idea to put those in includes? Problem with lots 
of mezzanine functions is, that programmers might have their own 
similar words, that then redefine the default ones.
(The same can be said with natives, of course.)

Or to look at it in another way:

It might be a good idea to keep the default REBOL vocabulary at a 
minimum and put extra functions (that people want for certain functionality) 
in includes.

Hopefully this will be solved by using dictionaries or namespaces

I too think that modules (namespaces) will solve it ....

Redefining system words:  It's an annoying problem. Geomol, and none 
of us is immune.

(I once debugged a CGI written by Carl. He'd used the info? mezzanine, 
but accidentally redefined the query word that it depends on. The 
results were wierd).
Namespaces should help.

I try to *not* clash with any words by always encapsulating code 
into objects -- so it's not 'query as global word, it's 'utilities/query
Meanwhile; the best we have is protect system.

I don't know how includes would be done, but I'm definitely all against 
splitting the mezzanines out in various libraries. Having the ability 
to be monolithic is one of REBOL's biggest strengths, and allows 
you to work with REBOL out of the box in minutes, not having to worry 
about including things.

henrik, yes.

I found learning rebol very easy because of it is just about words 
if you know 50 words you can write script if you know 200 you do 
it better. All those namespaces, dictionaries, classes ,trees or 
whatever does not help in writing programms and you need to remember 
more things. Using rebol is like using foreign language. Rebol has 
contexts and dialects for changing meaning of word. Maybe every script 
should work in its own context from default? I notice that many scripts 
are written in that way with use of 'set to put something to global 
context. And to be practical I use editor with syntax highlighting 
so every word from global context (set only) are blue so i can easly 
see if I redefine global word - after all it's just warning like 
in any language

but there are other systems which I have used which did not need 
include statements to actually include words.

what I have seen a lot through the years about people suggesting 
things (me included) on how to improve REBOL, is the tendency to 
ask for things from other languages.

I have somehow changed my perspective in that I find myself asking 
things like, why should I be doing that in REBOL.

I like protect-system, + words like add-archive . Thats similar to 
namespaces, but 'helps better.

many things are added to other languages, not because they are usefull, 
or where included by design.  but because the language eventually 
outgrew its original design or because new users request feature 
XYZ so many times it felt like a good idea to add it.

I think instead of trying to change how rebol thinks we should concentrate 
on making it deliver on all of its promises and adding actuall features 
to it.

I agree. Toi master a language, i have to master the core-features. 
And if there are a lot of them, that slows down. And i can do the 
same things with current features in a slightly diferent way, i am 
lazy, so keep core small :)

people want modules, some dont.   some need them, some can't stand 
them.

I think that REBOL right now is in a hard place.  It wants to stay 
pure... yet it wants adoption.

modules are nothing more then isolation of contexts ... sometimes, 
more strict aproach does not hurt, if you want it and need it ...

I only used the modules as an example of what REBOL has to deal with 
right now as its questioning its identity.

Is namespacing the only way to do it?

I wish modules existed, hell, that's why I coded slim which handles 
code modules almost 90% exactly like Carl had planned them.

but I don't think the language should change in a way that it depends 
on them.

Volker,  many times I thought I mastered rebol but then I found many 
features that was hidden behide even ONE word.

exactly... which points to one thing...

documentation.

How much does it hurt not to know about this features?

I think I know what trouble novices have though .... when you look 
at C or java-script like languages, it is clear what is happening, 
even if you don't know exact meaning of function name ... but imo 
with rebol - novice is looking into longer sequences of lots of english 
words, without parens, so the programmer can't immediatelly map to 
what is done and when .... :-)

just like trying to understand a german sentence  ;-)

A thing that hurts is this copy-thing. You have to know it, that 
effct occurs everywhere. Thats what i call a core-"feature".

but its a feature. its not a bug.

it has to be made clear to newbies from the onset.

(i meant "hurts if you dont know it")

I was burned just as bad in python and its the other way around.

imo every novice will go into the same kind of trouble with references 
issue .... but iirc Core docs in pdf explained it even graphically, 
so I would urge novices to learn those facts first ...

but the documentation, when I looked, made it very clear.

Or multithreading would be a core-feature, or language-feature. If 
it is present, you have to expect random changes everywhere.

Volker, not much harm, I mean Rebol not showing everything at first 
look so you don't need worry about mastering everything

if you don't need it - don't start other threads then :-)

I dont think so.  python does multithreading and its just something 
you start once you need it.