AltME groups: search

It looks a long way off. Easy to make something that looks a bit 
like REBOL. Hard to make something that is REBOL.

R is research. Rebcode is an example. We do those to push a bit, 
because we know they require a lot of thought, plus user testing 
and feedback.

Sunanda. I fully agree, and the reason for my asking. I will wait 
for a bit more input before deciding which route. An solution is 
to create rebol-compat mezz. That way you get the best of both worlds.

We could write the code to reflect the altme chat to a website if 
necessary. It's accepting chat from the web as well which starts 
to make it a bit of a larger task.

yes, but maybe it would be vital, if FINALLY RT would explain a bit 
a plan. We saw documents about more of community involvement, also 
about how some parts will be opened. But what we never saw were details 
to such a plan. R3 is coming. My understanding is, that is should 
make situation much better, as what does not belong to kernel, should 
be kicked off from Rebol, into module/plug-in, call it whatever ...

Pekr, AltME doesn't cover all linux platforms yet, so that would 
limit the audience a little bit.

But I'm making a bit of a push. :)

OK, should relax probably. It is just, it seems a bit contraproductive 
to me, which is a pity .... because if RT could use some good things, 
maybe they would decide to open some of theirs ones, as e.g. Console, 
etc., but it is a pity, the way for cooperation is ... nearly impossible 
....

so once we have the host and Carl realized that he'd waste less time 
giving us a bit more control, there is a chance for a bit more core->host 
migration still.

Sure, we all want that, but that's quite different from anything 
else being crap if it doesn't match R3 to the last bit

A bit surprizing move, I guess that Red project is stimulating competition. 
:-)

GrahamC, thank you for passing this around.  I did get part way to 
a solution, as noted on your site.  Strange as it may seem, I am 
able to get to the network drives if I run a copy of REBOL that I 
download and leave with the name it came with, namely rebol-view-278-3-1. 
 The copy of REBOL that was giving me trouble was the same rebol-view-278-3-1, 
but I had renamed it to rebview to make a desktop shortcut work. 
 I had the name "rebview" in the shortcut so that I would not have 
to change the shortcut if I ever got an upgraded version of REBOL 
with a different name, like maybe rebol-view-279.  So my first problem 
with WIndows 7, REBOL, and network drives seems fixed.  


I still am not to a full solution to my Windows 7 issues.  I have 
some REBOL scripts that use the "call" command to run powershell. 
 Powershell then runs a powershell script to extract stuff from an 
EXCEL spreadsheet, which then is manipulated by the REBOL script. 
 Actually it's a bit messier.  I run a REBOL program launcher on 
the C drive which runs a REBOL script on a network drive.  The script 
on the network drive calls powershell with parameters to make powershell 
run a powershell script.  The powershell script extracts EXCEL data, 
and the calling REBOL script then makes a report of the extracted 
data.  


When I try to do this, the result from powershell is that I am not 
allowed to run scripts on that computer.  I am aware of this feature 
of powershell, and I have done what has worked for Windows XP (set-executionpolicy 
remotesigned).  I can run powershell directly, and execute scripts 
located on a network drive.  When a REBOL script that worked on XP 
calls powershell on WIndows 7, it won't go.  I am not expecting any 
help with this last issue at this time because the "call" does work 
in some cases (call/shell "notepad") (call/console/show "powershell"), 
so I still have several things to try, and if none work I am plotting 
a work-around.

Thank you guys. I know the behaviour of charset in FIND. But I expect 
to skip the char that found, if I use /TAIL refinement as in using 
string.
Same for /LAST as Gregg said. It ignored for charsets. 
And also;
>> find/reverse "endo" charset "d"
== none
a bit confusing..

I think people don't realize just how much power lies in parse.  
 Even I'm impressed with it right now.  I've been doing tests with 
really crazy stuff like two-cursor parse rules and run-time auto-recompilation 
of 400MB parse rules. 


 I've been doing things like parsing 100MB word documents and pushing 
 the interpreter to the limit ... reaching the 32-bit 1.6 GB RAM limit, 
 6 hour loop tests, etc. :-)

The problem with R3 right now is that it isn't yet compiled in 64-bits 
we still have the 1.6GB RAM limit for a process which is the biggest 
issue right now.   I have blown that limit a few times already, so 
it makes things a bit more complex and it doesn't allow me to fully 
optimize speed by using more pre-generated tables and unfolded state 
rules.

Memory is cheap. It's the 32-bit limit that is the real problem -- 
as you stated.

its the MS windows limit.   it can only address 1.6GB of memory in 
32-bit mode.

(hope it explains it a bit)

If I could move time back a few years and I could vote, I would like 
Carl to enhance R2 a little bit instead of starting R3 which he probably 
never finish.

Or it's a 16 bit return, and the machine, it's from, is little endian, 
where World is big endian. Then it's the last 4 zeros in the result, 
that is the bool.

Oldes, complex numbers hold 2 double = 128 bit, then OP-code, register 
pointer and maybe some more.

I also think that 256-bit VM insn size sounds a bit wasteful. That'll 
thrash the data cache easily.

REBOL code is interpreted, but not its source. The slow part of a 
source interpreter is parsing the source into the intermediate code, 
the AST. REBOL is an AST evaluator. The advantage to that relative 
to a bytecode VM is that you can extend the runtime with more fast 
operations without breaking the bytecode encoding, but the disadvantage 
is that the interpreter overhead is larger so if you want your operations 
to be efficient you have to use larger ones. This is why C-like code 
is slow in REBOL, but high-level code can be fast.


If you want to get the advantages of a bytecode VM with the extensibility 
advantages of REBOL's model you could go with an address-threaded 
interpreter. Address-threaded interpreters have more data going through 
the processor than bytecode interpreters do, but it you need to support 
higher-level operations they are more efficient overall. However, 
if you don't need to support higher-level operations and only need 
to support a tiny number of low-level operations then bytecode can 
be encoded in a much smaller amount of space. If your language is, 
for instance, a spreadsheet formula evaluator then you might even 
be able to have 4-bit bytecodes, with two operations per byte, and 
have an interpreter that fits entirely in the instruction cache of 
a processor. Bytecodes can be much faster then.


Still, Lua's bytecode VM, as efficient as it is, has been running 
into performance limits as well. Fortunately, a bytecode model that 
maps well enough to the native code model (remember what I said earlier 
about C-like bytecode VMs?) can have the bytecodes translated to 
native code at runtime and then execute the native code. For C-like 
code that is usually even faster than address-threading. This is 
why LuaJIT has been doing so well when compared to Lua's bytecode 
VM.


World being Lua-like means that it can improve using methods similar 
to the ones that Lua has been using to improve. That's definitely 
a good thing, since it means that Geomol doesn't have to work from 
scratch :)

If so, I'd probably try splitting immediate complex-loads into two 
insns. Then reduce insn size to 128-bit (if possible) and check the 
effect on code size.

As I assume that your stack slots/registers are also 256-bit wide?

Andreas: The compelling evidence being Lua, which is the main register-based 
VM in popular use for which that is true. However, that depends on 
a number of other factors, not the least of which is the target architecture, 
or instruction-set design, or how well the register model maps to 
the underlying register model. It might be noted that there are not 
that many hardware platforms with 192-bit registers, so that might 
affect things.

Another nice change to REBOL for sure, where we unfortunately never 
got 64-bit builds.

single level Mark and Sweep GC?  or did you put a bit of time into 
making it a bit more powerful (multi-zone, multi-level, multi-threaded, 
etc.) ?

Thaks for the kind words, Gregg. I was very much in doubt when growing 
the instruction size to 256 bit, but I must do something right, as 
the performance shows. This is an alpha, and things will change. 
And I haven't done much compiler optimization.

Maybe I should tell a bit, how I work, to make it easier for you 
to understand, what you've got for now. I do much of assembly line 
programming, because it reduces the time of development. So when 
I wrote the lexer, I didn't just implement e.g. numbers, because 
arithmetics would be the first functionality, I would finish. I implemented 
all 40-50 datatypes, I wanted in World, in the lexer at the same 
time. So the lexer is prepared for more datatypes, than what actually 
works for now, and you will just see "Valid <something>" from the 
lexer, when it recognizes such a type.

Maybe I should call it "Linux32" and hold the 64-bit versions clean... 
So there can be a future "Linux", which is 64-bit.

The current Linux version is compiled under Linux Mint 12 "Lisa" 
32-bit.

Defining routines is very flexible, a bit against my simplistic philosophy 
for World, but now it's done. Having e.g. libc (OS X example):

libc: load/library %/usr/lib/libc.dylib

Defining PUTS can be as simple as:

puts: make routine! [
	libc "puts" [
		[string!] pointer
	]
	sint
]

or as full of info and features as:

puts: make routine! [
	"Writes a string to stdout followed by a newline."
	[typecheck]
	libc "puts" [
		string [string!] pointer "String to write to stdout"
	]
	sint integer!
]

(Not sure if just calling COMPILE w/o context after modification 
would always be the same. Will have to think about it a bit more, 
but I have a hunch that it is not.)

I get a malloc error under OS X (64-bit), when redefining a function 
with code like:

f: make function! reduce [pick :f 1 pick :f 2]


I didn't find the error, so I tried it under WinXP (32-bit), and 
the error isn't there!? Any suggestions?

More about routines.

The next release of World will introduce the handle! datatype. It's 
used to hold pointers, which are normally handled by structs and 
integers in R2.

If we take the sqlite3_open routine as an example:
http://www.sqlite.org/c3ref/open.html


The routine takes a pointer to a pointer as its 2nd argument, and 
this is the db handle updated by the routine. The handle is again 
used in sqlite3_close:
http://www.sqlite.org/c3ref/close.html


, but this time, it's the handle itself as the argument, not its 
address.


In World, using routines should be as easy as possible, and the consequence 
is, the definition of the routine gets some complexity. World uses 
libffi as the underlying motor to carry out the calls. libffi defines 
15 datatypes, where World uses 14 of them (not longdouble). Beside 
"pointer", I will introduce "pointer-adr", and routines like sqlite3_open 
can use that. Then the address of the handle will be given as an 
argument. Routines like sqlite3_close should just use "pointer", 
and World will internally typecast the handle to an integer (32- 
or 64-bit depending on version), and give that to the routine.

You list of 5 things:


1) Not sure, I wanna do that. It takes time away from me finishing 
version 1.
2) I have set the goals for ver. 1.
3) No (see Q&A)

4) "Ask for cooperation" - World would need schemes for the different 
protocols. I will welcome others work in that area. Me (and most 
likely others too) would like to see World on more platforms than 
the current 3. Host kit is open source. I will welcome ports to other 
platforms. (That's what I can think of for now, but I'll keep it 
in mind.)

5) It's faster for me to write the documentation than building a 
comm/doc infrastructure. I'll write the World 'bible'. Work has started, 
and I'll use more time on it, when version 1 is a bit closer.

About instructions being 256 bit, half can be used to hold constants 
of the types:

- complex! : 2 double
- range! : 2 64-bit int (also pair! in the future)
- tuple! : 14 bytes + length (could be 15 bytes)
- date! : 128-bit in all


The rest is used for opcode, type of constant and a register offset. 
I put a 32-bit filler in, when going from 32- to 64-bit to reach 
a 64-bit boundary. So it should be possible to go down to 192-bit 
instructions without loosing functionality. To reach 128-bit instructions, 
the above constants needs to be spread over two instructions, which 
will hit performance. But it's important to notice, there is room 
for improvements here.


It hasn't been important for me to uptimize in this area yet, so 
that's why it is like this for now, but that time will come.

On the other hand, on a 64-bit system with 64-bit pointers, compiler 
optimisation of code such as:

	0 GET_TVALUE	0		10031dff0
	0 GET_TVALUE	1		100150fa0
	0 ADD			0		0		1
	0 SET_TVALUE	10016f6f0	0


will require 192 bit just for the 3 pointers, which will mean 256-bit 
instructions (with opcode), if the code can be optimized into 1 instruction. 
Optimizing four 128 bit inst into one 256 bit inst will halve the 
memory required. I haven't dug enough into optimisation in World 
to say, if it's possible.

I wish you luck with World. It may be a bit difficult for me to use 
it though, because of the ASCII strings. Any language that isn't 
built from scratch with Unicode strings, instead having them retrofitted 
later when the inevitible need to support users outside the the English-speaking 
world, will have a great deal of problems. Python 3 is just the latest 
example of the problems with not having a well-thought-through Unicode 
string model. One of the best parts of R3 is how well we handled 
the Unicode transition.

My view is, implementing unicode everywhere will add to unnecesssary 
complexity. Each such level of complexity is a sure step to downfall. 
My first rule of development is simplicity, then performance, then 
low footprint, then maybe features.


Words in World can hold 7-bit ASCII. Chars and strings can hold 8-bit 
characters. That's the level of simplicity, I aim at.


I will have to deal with unicode, of course, and I'll do that, when 
World is a bit more mature. There could be a unicode! datatype.

About bit operations, I looked at SHIFT. R2 got it at some point, 
but there is no ROTATE. Wouldn't that be useful too? I think about 
graphics operations and maybe other areas.

SHIFT and ROTATE can only operate on 64-bit integers for now. We 
have to see, if operating on binary! and maybe other datatypes is 
needed.

And then I should be able to make 64-bit Windows version too.

I have World calling COBOL code.  It'll be nice to get a full on 
64 bit core though.  Much mucking about with 32 bit libraries, compiling 
COBOL in a VBox etc.

Getting close to automating the Dictionary wiki pages as well.


Adding to the old topic of openeness.  OpenCOBOL is open source, 
but very few people fork it.  Roger is the principal developer, and 
we wait for his releases ... but we get to see the compiler, build 
it on our platforms.   John, I don't want to see World core open 
so I can change it, I'd like to see it open so I can read it, build 
to suit, learn things.  So, if it's not asking too much, put the 
core code up in a read-only repo and ignore the forks while you develop?

Lastly; fun and looking forward.

I have a Win7 (64-bit) install now and did some work yesterday on 
porting World. I ran into problems with building libffi, which World 
use. I will look into it.

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.

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!?

Humm... a bit old, well with the last version you're true

Brian, Can you show me what is broken ? I'm a bit unsettled by your 
concern