AltME groups: search

It's probably a CALL issue, we had similar issues a year ago, and 
it was CALL-related IIRC. I and Peter need to install a Win8 system 
to be able to debug that.

Doc: I wonder if there's a web service out there that lets you take 
donations and shows a page like the humble bundle one. if not, perhaps 
we should make one. :-)

What's the difference between Sysmbol! and Word!

In R3, a symbol is the internal unique string that a word refers 
to. A word is a pointer to a symbol and another to its binding. Same 
in Red?

Jerry: symbol! datatype is not reachable for Red users, it's an internal 
feature. I might also add series! and context! datatypes, it will 
be for internal use only too. You can see the types hierarchy at 
page 22 of this presentation: 

http://static.red-lang.org/Red-SFD2011-45mn.pdf

(the types in italic are internal types, not accessible for Red programming).

In R3, date! isn't in scalar! because scalars need to be able to 
support +, -, * and /, and two of those don't make sense for dates.

The issue! type was changed from a string-like type in R2 to a word-like 
type in R3, but the R3 behavior isn't completely final. It will continue 
to be a word-like type, but the syntax might get some tweaking and 
some string-like operations might be added back where possible, perhaps 
in a similar way to how tuples are series/like at times but actually 
immutable.

I have pushed a commit yesterday night that reimplements almost fully 
namespaces support in Red/System. It is now cleaner, fixes a lot 
of issues and it is allows faster compilation of apps that heavily 
rely on namespaces like Red's runtime code. For example, the demo 
Red script now compiles 20% faster.


Please test well your current scripts to spot eventual regressions 
caused by this change.

Oddly, the Windows (and MSDOS) builds are changed, but I can't see 
where that's coming from

I am studying Red/System. For me, it's good enough, so I am curious: 
What can C do and Res/System cannot do?

From top of my head: C has unions and can pass struct by value. Both 
those concerns should be addressed in future Red/System versions.

As I understand, there is no foreach in the current version of Red/System 
and no c-strings in the current version of Red.

The best loop to use in Red/System is until:

str: "1234567"
until [
  print str/1
  str: str + 1
   str/1 = null-byte
]

Will print the characters in a c-string ( as would print str).

MagnussonC, you're mixing Red and Red/System. The above suggestion 
from Peter is for Red/System, not Red. What you are looking for in 
Red is FORALL or REPEAT iterators.

Though, you can also use UNTIL in Red, but string! is not c-string!, 
the + 1 part and final test are not valid in Red.

I realize I mixed string and c-string, but it was possible to use 
foreach on the string. The problem was to find the find the last 
char.

Doc, now that REBOL is Open Source, I ask which are the differencies 
between REBOL3 and RED to create a different language ? Can't you 
propose your view and have it merged into REBOL3 ?

And when RED/System will be ready for prime time... the community 
could extend and port all/parts of REBOL3 to RED/system.

I need a veicle with 4 wheels and and engine.

You can make it however you want but I need 4 wheel and and engine.

Giuseppe - in few months, Red will gain 80% of Core functionality, 
and even surpass it in some areas. Just let it live ...

Yes but I will have 4 wheel and an engine. The same of  REBOL3. It 
is the result which counts.

Giuseppe - let's really be fair to Doc here! You are asking him to 
give-up on what was really a strong decision for him, which even 
has influenced his life. Doc moved from France to Montenegro, in 
order to work on Red. And all that would not be necessary, if Carl 
would not let us in the water. So really - just let Doc alone for 
few moments, to think about all new consequences ...

Arnold. We are talking about minor differences like a car with 2 
doors instead of 4 and electric glasses in place of manual ones. 
The comparison doesn't suit here. If BOTH languages are "Very Close" 
(read above), which are the advantages ?

Giuseppe: they might seem similar on the surface, but I can garantee 
you that you'll see and feel the difference when Red will be mature 
enough.

Giuseppe: you seem to not understand the difference between a interpreter 
and a compiler.

(And let me state again: I apreciate your commitment)

Red/System also offers a nicely compact and clean toolchain, which 
R3 doesn't even focus on. As far as I know, not many people like 
the current C toolchains.

I am talking about RED and not RED/System.

That means that we have total 100% control over how and where Red 
can build. We don't depend on the quality of the compiler for a platform.

I can see and huge difference between C and RED/System which give 
to the latter a great appeal to the developers.

Henrik speaks wise words. For the past decade, we've been occupied 
with maintaining the GNU C/C++ toolchain in Syllable. If it hadn't 
been so problematic, we could have spent that time developing the 
operating system itself, and the project might have been in a much 
better position now

To everyone: my questions are not meant to create problems. I work 
every day with customers and they always ask me "which is the difference 
between you and this other product/service".

So the difference between Red and R3 is between a car that takes 
you there, and a car that breaks down before reaching your destination

I find myself less and less interested in REBOL, even open sourced

Well Guiseppe, you may have to think of a second hand car ;) 

You can drive with it, it can be the car you wanted but some details 
as its color and chairheating can differ from what you had in mind. 
It is up to you to buy it anyway. By buying second hand you can have 
a more powerful engine than buying a new car.

Remember that the REBOLution was proclaimed to create the next generation 
operating system. However, REBOL falls seriously short there, not 
having delivered an operating system and not running well on top 
of any other operating system

And the liberation from the C tool CHAIN Viva la Liberation!

It may be time to consider REBOL an idea, a good one and one that 
now needs to have its true wings in the form of Red.

I posted in Sublime Text's forum in regard to the lexing needs that 
we might need for good Red support. The author hasn't answered yet, 
but maybe if others add to the thread, it'll keep it near the top 
and show there's interest in the idea. I suppose even if ST doesn't 
make its lexer pluggable, we could just make the built-in lexer do 
as little as possible by including no tmLanguage file for Red and 
delegating any syntax coloring/scope processing to a native library 
that's part of a Sublime Text package for the Red language. 

http://www.sublimetext.com/forum/viewtopic.php?f=2&t=9870

Jerry: when I find time to write it. :-) Probably when I get back 
to memory manager code to add the few missing parts, like GC and 
allocation of big memory chunks, that should happen in the next weeks.

AdrianS: the output of the lexer is nested blocks of Red values, 
same as REBOL with its own lexer (LOAD). The AST is not stored anywhere, 
AST nodes are created and consumed on the fly during the compilation. 
So the closest thing to an AST you can get currently is the output 
of the lexer.


For the needs of a code editor, maybe you could just invoke it on 
the currently edited line (though you would need to deal with unmatched 
opening/closing delimiters). I haven't yet though how I will achieve 
it in Red IDE.

It's not as complex as it sounds. Feel free to ask any question about 
it in Rebol School or in ~ChitChat if it's purely Red-oriented. Open 
source projects are an excellent way to share knowledge and I would 
be glad if Red project can help people (including myself) learn something 
new.

Doc and the others:

I hav had some considerations about the RED = REBOL issue and I will 
continue the discussion in the REBOL3 area.

It's late to talk about merging. It's been 2 years, Red is getting 
mature very soon aspecially after the Red/System part is almost done. 
Don't make any distraction to slow it down. ... Besides, R3 is not 
open yet (where is the code?), Red and Doc are all we got now. Doc's 
got the whole plan for Red, which is a good plan. We donate for that 
plan, not for a merge plan. The latest blog article in Red-lang.org 
made me realize that we might have a complete and mature Red in one 
year.

So, we get both worlds. If we manage to call R3 code from the Red 
section and vice versa, that would be great. We could use the compiled 
speed for inner loops and let the interpreter do all the non-speed 
relevant things.

Robert, I guess you mean Red/System and not Red? Well, the license 
are compatibles, so if someone wants to include Red/System into R3, 
he doesn't need to ask anyone for permission.

Kaj - but it is not like Cyphre creted JIT for R2, which looked like 
REBOL and was just faster. Red/System code surely can't run that 
way - it is for offline stuff, where you first have to compile the 
app, no runtime stuff ...

Pekr: the difference between AOT and JIT compilation is much thiner 
than you think. Just load Red/System compiler code to your R2 app, 
pass it any source code at runtime, use the link?: no option and 
you get compiled code and related data in form of binary! values...and 
voilà! :-) The rest is same as for Cyphre's JIT, you need a way to 
call native code in memory, something that is hardly possible in 
R2, but maybe Cyphre found a hole to achieve it anyway.

It breaks the "fit all in one binary" REBOL philosophy, requires 
to compile it for each platform and maintain OS-specific code...Not 
a problem per se, but IMHO a sub-optimal solution, that's why I was 
interested in a possibly purely "internal" solution, in case I would 
have missed it.

It's available but not documented as it is only used by the compiler 
internally for now. You can add it to any of the target definition 
block in %config.r for testing (or create a %custom-targets.r file 
instead). It will put the compiler in an "incremental" mode (it can 
compile incrementally as many source file as you want). Once compilation 
has finished, no file will be generated and compiler state will not 
be reset. You can then inspect the result of the compilation from 
console using:

>> probe system-dialect/compiler/job
>> probe emitter/symbols
>> probe emitter/code-buf
>> probe emitter/data-buf
>> probe system-dialect/compiler/imports


You can basically get most of these data in logs when compiling using 
-v 9 option.

Kaj: that's right. If you want addresses to be resolved, we need 
to add a in-memory linker. It will basically just resolve all the 
addresses. But that would not work as is with the imports that expect 
to be statically linked. So, a custom dynamic loader would be required 
(same requirements as for implementing LOAD/LIBRARY and MAKE ROUTINE!).

To put it concretely, the AVR backend needs to generate a memory 
image, without external symbols because there is no operating system, 
but with all internal addresses resolved. Can that memory image be 
constructed by appending data-buf and code-buf?

As you will notice, it uses a minimal C-based kernel and some imports 
are linked to it using syscalls.

I would like to get rid of the compiled C part, but never found the 
time to recode it in Red/System. It would also needs some addition 
to Red/System, like interruption handling (already planned) and other 
non-planned features, like a way to initialize RAM/SRAM from Flash 
memory (basically, it needs to copy the firmware data section from 
ROM to RAM), or initialize properly the timer clock (which should 
be doable with the hardware I/O support I've planned already).

Well, I do have something, but it's messy, buggy and incomplete. 
I can send you the AVR8 backend if you want to play with it, I don't 
want to publish it until it gets a stable and correct support for 
basic datatypes.

I can run the Windows executables under WINE on Linux. Oddly, cURL 
and SDL sound work there, so for now I'll blame Windows 7 for their 
failure there

Maybe I will take a shot at the tool. Outline would be handy and 
specs.

In allocator.reds, the only struct I know is cell. What are node 
and frame here? Doc.

The various frame struct!s are declared in lines 79, 86,and 94

Jerry: here is a quick overview:


Red values are stored contiguously in series slots (128-bit cells). 
Series buffers are allocated from large chunks of memory of type 
series-frame!. Series value in slots store just a head offset and 
a pointer to a node!. The node! is another pointer to the series 
buffer. So series buffer are indirectly accessed, allowing them to 
be moved in memory (for reallocating with bigger/smaller size or 
moved by GC).

A series buffer has header, with OFFSET and TAIL pointers that define 
respectively the begin and end of series slots. The OFFSET pointer 
allow to reserve space at head of the series for optimizing insertions 
at head. Series slots size can be 1 (binary/UTF-8/Latin-1), 2 (UCS-2), 
4 (UCS-4) or 16 (value!) bytes wide.

From ~Links group: "Could Red eventually become a contender for #6? 
 How strong will support for parallel processing be, eventually, 
in Red?"


#6: yes, that is one of the goals I want to achieve with Red. For 
parallel processing, the model I have in mind is the "parallel collections" 
from Scala. This means that when you are looping over a series, Red 
should be able to parallelize the loop code over n (CPU and/or GPGPU) 
cores at the cost for the user of only a change of the loop function 
name (in Scala, they use a "par." prefix for such functions). This 
requires that the compiler do a deep static analysis of the loop 
body to determine if it can be parallelized (e.g. iterations not 
dependent on results from previous ones). Now, if you also add SIMD 
support in the equation to leverage intra-core parallelism, you get 
a good picture of what I want to achieve. ;-)


So, I think a semi-assisted parallelization/vectorization of loops 
in Red is doable. To what extent and which final efficiency, I'm 
not sure before we build some prototypes.

To what extent and which final efficiency
 may be a key factor in your billionaire-worthiness ;)

There is also the basic work to do, like the lexical scanner, port 
system, etc. Some of the work on actions and natives can be outsourced 
later.

Jerry: interesting metrics. You could keep track of it month by month 
and publish them.

He should write a script, one that runs both under R3 and Red. :-)

The completeness and stability of them will be ignored here, which 
is not fair to R3. But like I said, It's just a simple comparison. 
The purpose is to see the progress of Red, not to discredit R3.

Also, Red will add its own features, like specific datatypes, natives, 
actions,... For example, MOLD and FORM both have a /PART refinement.

Many years ago, I found REBOL 2 and liked it a lot, but back then 
REBOL didn't support Unicode, so it was useless in China/Taiwan. 
I wrote e-mail to Carl, but I got no feedback. So I decided to start 
a magazine column in China and Taiwan to introduce REBOL. My idea 
was to make readers love REBOL and felt the same pain (of no unicode 
support). I also kind of encouraged them to write e-mail to RT on 
the Unicode issue.

After a while, Carl said (in somewhere, blog maybe) that he didn't 
know why REBOL had many Chinese users, and they need Unicode. So 
he decided to support Unicode.

In any case, you can always bypass the whole Unicode layer by reading 
(or converting) strings as binary! values, and then processing them 
the way you want (this is not recommended though, but some users 
might need it).

I do prefer, actually. LOAD being mezzanine and calling a separate 
parser lets you do a lot of nice tricks. The "mezzanine" might be 
native in Red, but the separation of concerns is still a value. YMMV 
of course.

Agreed too for the separation and for the bad sounding name. ;-)

I've become a low level programmer again, and I still want it to 
be one based

Off-by-one errors are everywhere in programming. Choosing between 
one-based and zero-based indexing shifts them to slightly different 
places, but they will still be there. As you said, I seldomly encounter 
a situation where there would be a strong preference for indexes 
to be zero based

By extension, I would like Red/System to be as close to Red as possible, 
so issues can be explained firmly and just once, and it's easy to 
morph Red code into Red/System code when you decide you need the 
performance

As for R3, it did not really introduce "0-based convention implicitly", 
it still is firmly "1-based" in as far as the first element in a 
series can be accessed using index 1.


When you want indices-as-ordinals, you really need to decide: (a) 
is the ordinal "zeroth" meaningful, and if so, what it means; (b) 
are negative indices meaningful, and if so, what they mean.


R3 went with the choices of (a) having meaningful zeroth, defined 
as "the item in a series before the first item", and (b) allowing 
negative indices, having index -1 as the immediate predecessor of 
index 0.


R2 went with the choice of (a) not having a meaningful zeroth, but 
instead of erroring out, functions (pick) & syntax (paths) accepting 
indices are lenient: passing an index of 0 always returns NONE. For 
(b), R2 allows negative indices and defines -1 as the immediate predecessor 
of 1.

Andreas: thanks for the good sum up.


R3: agreed that index 1 is still the first element in a series, but 
index 0 is allowed and there is this ticket #613 that clearly aims 
at introducing 0-based indexing in R3...so my guessing was these 
different changes or wishes were inter-related. http://curecode.org/rebol3/ticket.rsp?id=613


R2: I would have really prefered that index 0 raises an error than 
returning none.

There is also the option proposed by Gabriele to consider: an ordinal! 
datatype (...-2th, -1th, 1st, 2nd, 3rd, 4th,...).


It could solve the whole thing, but I see two cons about this option: 

1) negative ordinals look odd, I don't even know if they can be read 
in engllish?

2) code would be more verbose as it will need conversions (to/from 
ordinals) in many places.


In addition to the pros, making  a difference between an integer 
and an ordinal might help improve code readability.

The problem with no meaningful index 0 is that potentially meaningful 
index values are no longer isomorphic to integers. And as REBOL has 
no actual datatype for indices, all we can compute with are integers 
while relying on a correspondence of those integers to indices.


If you only ever compute indices for series positioned at the head, 
you get a nice correspondence of integers to indices, because meaningful 
indices for this series correspond to the positive integers.


But if you also want to compute indices for series positioned elsewhere, 
this nice integer-to-index correspondence breaks down as you suddenly 
have an undefined "gap" for the integer 0, whereas negative integers 
and positive integers are fine.

Andreas: do you have a short code example involving index 0 in computation? 
I don't remember ever having issues with index 0 and I use series 
with offsets a lot! Though, Ladislav claims he and Carl did encounter 
such issue at least once...the use cases for this issues remain a 
mystery well kept by Ladislav. ;-)

So sorry, I don't have a particular example at hand, but I can easily 
imagine it coming up with e.g. forall or forskip and trying to access 
previous values in an iteration.

Though, Ladislav claims he and Carl did encounter such issue at least 
once

 - I am claiming that I have revealed a bug in Carl's code caused 
 by the fact that indices are not isomorphic to integers, i.e. they 
 "contain a gap". That is a totally different issue than whether indexing 
 should be 1-based or 0-based.

SKIP works with offsets only, it's not related to indexing.

 - that is not true, in fact. It *is* related to indexing, since we 
 may always use PICK SKIP SERIES N M versus PICK SERIES K and these 
 things are realted, like ir or not.

Even if you talk about "inbetween", there is _no_ integer in between 
1 and 2, but there is an integer between -1 and 1.

Also, the SKIP function demonstrates the same behaviour quite well 
and consistently.

(And an index that does not correspond to a value in the series, 
at this point in time.)

Actually, I can demonstrate that even past-tail indices are meaningful 
for blocks, and I did.

Yes, that's certainly arguable. I say that because I think that "head 
position" and "tail position" sound like dual concepts, whereas they 
are not.

Do you consider R2's nomenclature to be particularly consistent and 
simple?

My thought behind the "tail position" complaint above was, that series, 
position, and index are already used rather exchangably, and lax 
in a few parts of REBOL's documentation. Adding "tail position" to 
the mix, only further contributes to that confusion.

If you realize that indices are one degree vectors.   A lot of this 
discussion becomes moot.   vectors of length 0 are considered impossible 
when considering only natural numbers (due to 0 divide).  This is 
why I consider R2's handling of indices proper.   


As such, any series "position" is not AT a value it is LOOKING AT 
a value (oriented in positive direction, starting at a point in space 
which is "0").   like extending your arm to grasp the nth thing in 
front of you.  


Tail are 0 length vectors (thus mathematically imposible), when we 
are beyond  the last item edge we are at the edge of space.   you 
cannot "take" the tail item, there is nothin in front of you, just 
as you cannot "take" the 0th item, there is no such thing, 0 is the 
origin of the vector).


when we consider series indices to be vectors, we see the natural 
relationship which Ladislav pointed with SKIP and other methods.


with vectors, things like COPY/PART make sense in the negative direction, 
just as well as in the positive direction.



In R3, this was changed to indices being OVER a value , with the 
first item requiring you to look down and then away for other values. 
 The issue is that index 0 is looking backwards... that doesn' map 
to any good reasoning.  In fact it creates many weird inconsitencies 
in the model, when you try to describe it.


R3's series changes seem like a kludge work-around to map non-vectorial 
infinite integer space to a bounded vectorial space. sacrificing 
model integrity in the process (while trying to ease its mathematical 
properties).  R3's series *may* be "easier to count in a loop"  but 
the values being used make no sense.   counting backwards requires 
us to manipulate the indice for it to "make sense", whereas before, 
counting backwards was the same as counting forward.  we where just 
LOOKING in the opposite direction (the vector's orientation is inversed).

empty blocks are not impossible to describe.  but all functions will 
provide special cases to manage them (return another infinitely small 
block or none, or raise an error) because as such, they are vectorially 
equivalent to null.    an empty  block is just a starting place without 
any room to move.  when only looking forward, it is exactly the same 
as the tail (when you read my original post) and hence in actual 
code, tail [1 2 3] and  [ ]   are exactly the same, if only positive 
indices are being used.

I am still sure that once we have negative numbers, we cannot do 
without zero (to maintain compatibility with the continuity of the 
underlying series). Then, actually, the SKIP behaviour is the only 
one easy to describe and use as the base of the "nomenclature".

Ladislav, I fully agree. I don't think that "0 points backwards" 
is particularly elegant either, but I'm willing to explain it ("0 
points to the element before 1") and find it much better than having 
to explain when and why you have to very careful with computing indices, 
or even debug (R2) code that was written unaware of this fact.

No problem, but that is also and "ephemeral characteristic" exactly 
like TAIL?

anyhow I always considered negative indices to be a bad idea.  I 
find SKIP and BACK convey much better meaning, because they are inherently 
directional (vectorial) by nature.  


IMHO  negative indices should have been implemented like in python, 
where they count from the tail, rather than "curren" position.   
they are MUCH more useful, they would be used daily by me (and most 
rebolers) in such a case.

And no error for out-of-bounds indices?

hm.. now I see, that even select and path notation is not returning 
error.. so I don't know where I came to this.

From R3-alpha world:

Carl:	It is zero based for math computation reasons. If you think 
that is wrong, we should discuss it and correct it soon.	11-Oct-2007 
6:03:15 PM

Carl:	Rest of REBOL is one based for this reason: first = pick series 
1	11-Oct-2007 6:03:33 PM

Carl:	The solution we discussed, but have not yet implemented (but 
it is easy to do) is to add a PICKZ (or PICK0) function.	11-Oct-2007 
6:05:41 PM

BrianH	: Those math computation reasons are why I prefer zero based. 
I tend to use SKIP instead of AT for the same reason.	11-Oct-2007 
6:06:09 PM

BrianH	: Please add PICKZ and POKEZ - I liked them in rebcode.	11-Oct-2007 
6:06:46 PM