World: r3wp

Mchean - as for Geomol - I feel sorry for him - he is a victim of 
RT's treat of the community .... Geomol has clear view of how to 
put his project forward, but ppl don't seem to be interested - that's 
my impression at least ...

on the other hand I understand his concern about getting a return 
on his investment, and if world were

My impression (correct me if I'm wrong, Geomol) is that Geomol doesn't 
require our interest to get a return on his investment. He's already 
got a planned use for World in his own projects. Our interest and 
feedback is a bonus.

Pekr! Take a breath. When you're calm, then read your words here 
again. You're very off topic. Please move such rants to appropriate 
group. Please!

Then reality check:


This group was started 2 months ago. It's easy to go through it and 
look for my blue and yellow releases and notes. That's a lot of progress 
in 2 months. If you see it otherwise, then you're blind. The C sources 
of World has grown a lot in those two months, and it's quality work 
with few errors considering the amount.


You will most likely see the progress of World come in waves. I had 
worked intensely on it more than full time since before summer. Yes, 
more than full time (more than 8 hours a day, also week-ends), so 
that's a lot of man hours. The last month, I've done paid freelance 
work too. At the same time, for World I'm researching better networking 
(cURL), getting lib calls to work under Windows 64 using libffi and 
finishing the memory model, so circular references are coped with 
correctly. Why didn't I say so? Because I like to announce things, 
when it's done, instead of giving false hopes, but now I made an 
exception.


1) I'm not going to give my work away for free at this time. That's 
because I see no benefit in doing so.

2) World will not come in a situation like REBOL, with lots of errors 
for a long time and still closed source. If I wasn't able to continue 
work on World (to fix errors, make further progress or whatever), 
and if people relied on work already done, then I would open source 
it. As this isn't the current situation with World, this is no argument 
to open source it.


If you don't like my model, move on. Negative rants here are not 
productive.

sounds good to me.

First try on a World Map:
http://www.fys.ku.dk/~niclasen/world/World_Map.html

Made with FreeMind and exported as Flash.

That's cool! Then you can add explanations & examples to them, later.

And look at the "Note Window" under View menu, you can add notes 
to items. They will be exported to Flash / Javascript as Tooltips 
which is quite useful.

Oh and also try "Auto Layout" under Format menu, it makes it nice, 
but make a copy before use it.

Thanks!

very nice!

Excellent John.

Very cool.

Thanks, guys. Easy to do with the right tool, and FreeMind works 
well for me.

Geomol: Can you put icons to show which parts are completed, priorities 
and you work on?

The Map is the current picture of what's implemented, so it's not 
an image of all for version 1 of World. As I mention in the README 
on GitHub, date! and time! is only partly implemented, the rest is 
more or less completed for version 1.

I would like to improve the Map, so I'm working on that.

That's cool. Making a RoadMap diagram can be useful as well. So everyone 
can easily see what is next, what you are working on, what priorities 
are etc. of course if it helps you as well.
It is much more readable than a wiki.

Yes, much better overview with this type of tool.

New World Map at:

http://www.fys.ku.dk/~niclasen/world/World_Map.html


I freshed it up with some colors, which is also informative, added 
system, sys-utils and net-utils, added icons for parts with issues 
and added parts not implemented yet as grays.

Nice.

Nice map !

Looks great John.

Gregg wrote in group #Red: "World has similar goals I believe."


Yes. To clarify: There is World and there is World/Cortex. World 
is written in C and the Cortex extension is written in World. It's 
a design goal to have as little as possible in the C part, but because 
it's also a goal to have good performance, especially with math stuff, 
some functions are native (written in C), which could have been mezzanines 
(written in World), like ABS, COS, SIN, TAN (all small functions 
in C).


But large functions like PARSE and SORT and many other functions 
are part of the Cortex extension, so they're written in World and 
is therefore open source.


With the good support for dynamic loaded libraries, good performace 
with heavier functions can be achieved that way.


And then there is the REBOL extension (in the World file %rebol.w), 
which is there to hold further extensions and definitions needed 
to run REBOL scripts. Those are not in the Cortex extension, because 
I disagree with some of the REBOL design decisions, and because I 
would like the Cortex extension not to be too large.


For me, World and Cortex has the higher priority, the REBOL extension 
the lower priority, meaning I use more time on finishing World/Cortex 
for now.

Great info John. THanks.

Geomol - could you please explain, how wrapping libraries in World 
are done? Call me dumb, but I can't understand it from a website. 
OK, found more in PDF docs. I just wonder, if I always should use 
typecheck? Eg. I wanted following function to return 0 or 1. I tried 
with variou int types on the C side, and integer! datatype on the 
World side. I was receiving very large integer numbers as a result, 
untill I put [typecheck] in there. Maybe I just had incorrect argument 
type on the C side selected?

led: load/library %ledctrl.dll

led-is-power?: make routine! [
   [typecheck]
   led "LSN_IsPower" []
   uint integer!
]

World is 64 bit. If you don't specify typecheck, it assumes the return 
value to be a 64-bit integer, e.g. sint64 or uint64 in C and integer! 
in World. If the return value of the C library routine isn't a 64 
bit integer, you need to specify typecheck to get it converted from 
8, 16 or 32 bit to 64 bit. If the return value of the C library routine 
is 64 bit, typecheck isn't necessary, but can still be used, and 
it will slow the routine call a bit.

I say C, but the library can be made with any language, I guess. 
It's just, that the C types (actually typedefs) are used in the explanation.

Maybe typecheck should be default, even if it hits performance, when 
it isn't needed, and then some other word should be used to remove 
typechecking (and conversion)? Argh! I don't like to change that. 
:)

Well, a trade-off :-) It is about to get the most expected result 
preferably, vs your mentioned speed :-)

What about a compiler option to turn on and off the typecheck? More 
complicated, but we would have a chance to run in default (typecheck) 
and then test it without typecheck by changing just one option.

After I wrote the above, I considered it some more. Right now, most 
people will probably run into this problem, because most libraries 
return 32 bit values. But in the future, and with what World is very 
much designed for, namely science, 64 bit values will be used. So 
I'm not gonna change it.


Problem with compiler option is, that we then have two versions of 
World, and programs made for one won't run on the other.


Maybe better to make a World wrapper function with it's own routine 
definition dialect!?

Like ROUTINE is a helper function calling MAKE ROUTINE!, a ROUTINE32 
(or something) can be made to have typecheck as default.

with *its* own ...

But we should set the option in the (on top of) source code, not 
in runtime, so it should not be a problem having 2 versions of World. 
We can say "compile this source with "typecheck" options". No?

ah, I'll consider that.

In the boot time of World compiler some functions changes according 
to some options. As in "Option Compare", "Option Explicit" options 
in VB6.

Continuing from #Not REBOL. A MORE? function could look like:

more?: make function! [[
	"True if a series isn't empty."
	series [series! none!]
][
	if none! = type? series [
		return false
	]
	0 < length? series
]]

Could also be made easier to read maybe, but slower:

more?: make function! [[
	"True if a series isn't empty."
	series [series! none!]
][
	not any [none? series tail? series]
]]

And to make is less confusing, the function description should probably 
read "True if a series isn't at its tail."

Working on the next release of World, I implemented coercion for 
words and datatypes, so things like block! = 'block! returns true. 
This lead to a much simpler implementation of SWITCH, which is a 
mezzanine in World, so it looks like I'm on the right track.

Another point talking against open sourcing at this time. World is 
not completely set in stone yet, I admit that. When I make design 
changes like this coercion between datatypes and words, it affect 
all other code, which can fast become a mess, if you have 10 people 
working on it. When it's completely set in stone, it's another situation.

Update!


I'm implementing support for cyclic series in World these days. My 
initial research about freeing memory taken by cyclic series made 
me realize, that it'll hit performance, if every block and paren 
freed is being tested for cyclic references. So I'll implement a 
FREE mezzanine written in World, that can free such structures. This 
lead me to molding such structures, which is only partly implemented 
in current version of World and copying such structures. Those functions 
will be mezzanines too, as it's much easier to write the code in 
World than in C. So some C code will be removed in next release, 
but we'll have some more World code instead.

Btw. COPY is by defauit deep in World (contrary to REBOL), and World 
will support deep copying of cyclic blocks, which gives a stack overflow 
error in REBOL.

no cyclic error in R3 IIRC (it was fixed in some alpha).

In one of 114 alphas :-)

Maxim, the fix was requested for R3 but not yet implemented, or planned.

hum... strange I feel like it was fixed, since at some point, R3 
coudn't make objects which I required, then, when Carl did the whole 
copy/make makeover, I was able to start using R3 because of deep 
copying issues being resolved ... maybe it was not completely fixed.

I don't think that was about cyclic structures

yes.. definitely but I think Carl may have only fixed it for cyclic 
Objects references.