AltME groups: search

That's more the difference between a native and a mezzanine, than 
the method.

And that's probably an ok decision.

That's more the difference between a native and a mezzanine, than 
the method.
 - That's right.

And it makes sense.

The ++ and -- functions are in R2 for convenience and compatibility, 
not for speed.

yes and yes

I've been thinking about this before, and there was a discussion 
on Carl's blog long time ago. It came to me again, when I looked 
at LOWERCASE and UPPERCASE. They work on strings, and does change 
the sting. But many functions work on string without changing them. 
That's a bit odd, or maybe difficult for new users to understand.

I think, the ideas can be seen as: like other languages have call-by-value 
and call-by-reference (maybe using pointers as in C), REBOL could 
have call-by-value and call-by-word, both working with the same functions, 
as it's all by value, but we just give the word (REBOL's kind of 
reference) as an argument.

Leading to shorter notation and most likely also faster evaluation. 
I can't see any problem yet, but maybe there is!?

Is there a simple way to transform a block of blocks into a single 
block and maintain their types? As follows:
a: [  [1] [2] [3] ]
Changing that to
b: [  1 2 3 ]

You know, outside of looping thru each value and building a new block 
(which I don't mind doing but if there was some simple way)

ChristianE's ODBC extension for R3 includes a native FLATTEN command, 
but I haven't tested whether or not it manages memory properly, and 
it doesn't help R2, or R3 not on Windows.

Using R3 PARSE:
>> b: copy a parse b [any [change [set x block!] x | skip]] b
== [1 2 3 [4]]

>> b: copy a parse b [while [and change [set x block!] x | skip]] 
b
== [1 2 3 4]

Or simpler:
>> parse copy a [return while [change [set x block!] x | skip]]
== [1 2 3 [4]]

>> parse copy a [return while [and change [set x block!] x | skip]]
== [1 2 3 4]

The PARSE and WHILE versions above will work in all cases where you 
don't run out of memory, and for the deep versions when there are 
no cyclic references.

>> parse [[1] [2] [3 [4]] [[5]]] [return while [change [set x block!] 
x | skip]]
== [1 2 3 [4] [5]]

>> parse [[1] [2] [3 [4]] [[5]]] [return while [and change [set x 
block!] x | skip]]
== [1 2 3 4 5]

Gentlemen, thank you. I will study your methods. It is just one level 
and it was to handle indexes I was receiving from a mysql db that 
were returned as [ [1] [2][ 3]]. Again thank you. You guys sure know 
your stuff!

Brian, that reminds me. The ++ is something I have never seen before 
and it doesn't show up in the "dictionary" which is what I normally 
depend on for info. Is there some doc or source of info you recommend?
Thanks.

Right, I forgot about that. There's a -- too, and other new functions 
like FIRST+ and TAKE. I tend to just do WORDS-OF lib in R3 and go 
from there. Most of the new functions in R2 in the last several years 
are backports from R3.

R2's COLLECT is pretty similar. The backports try to be as compatible 
with R3 as is practical in R2, though is a couple cases they are 
a bit ahead of their R3 versions, where there are some tickets that 
haven't gone through yet. In particular ENLINE/with, DELINE block!, 
and MAP-EACH/into come to mind.

My solution works perfectly in this example, and don't tell me what 
to do or not to do.

(and my list isn't complete)

In general, Carl wrote REBOL to be its own metalanguage, especially 
to be able to manipulate blocks and their contents accurately. Solutions 
like the above are necessary only in languages, that do not have 
such abilities.

As to why decimals are affected, they simply are, and your example 
does not prove the contrary.

One more note: there is a FLATTEN function definition somewhere, 
which was defined some time ago to be used to flatten hierarchical 
blocks. It should be possible to find it here, but, since it was 
long time ago, I will try to find my version and put it to rebol.org 
or somewhere to make it more available.

Decimals are discussed in the DocBase (Geomol beinng a coeditor of 
the article), and, for the interested, it should not be a problem 
to find relevant informations in there.

type? load form [1] ; == integer! (i.e. not block!)


Yeah, that's a pity, I think. I would prefer LOAD to always return 
a block, so the result from LOAD could always be sent to e.g. PARSE. 
I guess, it's made this way to kinda let LOAD and SAVE reflect each 
other. But that doesn't quite make sense, as we can't save to a string. 
And LOAD can load an empty file giving an empty block, while we can't 
save an empty file with SAVE, afaik.

Many languages return inf in cases with math overflow. I would prefer

load mold 1.7976931348623157e308

to return [inf] instead of the now:

** Math error: math or number overflow

And that inf in the block should of course be of type decimal!.

And, I am content with the high level code taking care of exceptions

Guys, thanks for all the input. I didn't mean to cause this much 
excitement. :-) I just wanted to get my crazy DB program to work. 
And by the way, it does, at least so far.

more like list navigation, where one may move back and forth one 
item at a time, but never past the last item.

Think about passing :sine/radians as an argument to a function. So 
when using that argument in the function, the user would expect sine/radians 
to be calculated, but it doesn't, and it will be very difficult to 
implement that feature, if at all possible.

Also, in R2 operators are evaluated by DO itself, which has a set 
of keywords that it transforms from operator to prefix function syntax. 
R3 does this swap by value, not by name, so operator renaming is 
possible. However, this leads to behavior like this:
>> f: func [a op b] [a op b b]
>> f 1 get quote / 2
== 2

>> f: func [a op b] [op a b]
>> f 1 get quote / 2
** Script error: op operator is missing an argument
** Where: f
** Near: f 1 get quote / 2


This is why, when you are accepting and calling function values, 
it's best to either limit yourself to the types of functions you 
are expecting, or use APPLY.
>> f: func [a op b] [apply :op [a b]]
>> f 1 get quote / 2
== 0.5
>> f 1 :divide 2
== 0.5

R2 has an APPLY too, in mezzanine but it works the same way. It was 
added for security and function wrappers.

Why isn't the length of a char one?


Because characters are no series datatype and therefore it does not 
make much sense to speak or their length.


That's about the same as asking "Why isn't the lenght of an integer 
one?" or "Why isn't the length of a logic! one?"

And some code might benefit if we could ask the length of an integer.

Bitsets are useful for intexes and certain kinds of parsing (LL first 
and follow sets, not just character sets). Other stuff too.

It probably won't add overhead to length?, because that function 
already works with different datatypes, and char! is just another 
one in the switch already there.

Linux also would not consider them equivalent. I understand why Mac 
OS is always canonicizing file names, but, they chose the most stupid 
way to do it, and it's a pain in the ass most of the time. In the 
end, I prefer Linux where you can end up with two files named in 
a way that looks exactly the same, but that has a file system that 
behaves in a predictable way.

There are a few different time protocols, and the standard time servers 
don't tend to run the daytime protocol. They usually run NTP.

2 amacleod: time protocol is not very accurate, the same levely of 
accuracy you can get by reading any HTML size and distile the time 
from HTML header. OTOH NTP protocol is able to get milisecond accuracy 
but by quite difficult handshake and as far as I know not yet written 
for rebol

It might be better to enable your server's native time sync services. 
Windows, Linux and OSX all have such services, as do many more OSes.

It's enabled but does not sync as fast as the drift and I'm having 
trouble doing it manually...keep getting an error and I tried several 
time servers.

Can your number both be integer and decimal?

I see the log-10 loop as around 18% faster under core 2.7.8.

So this optimisation depends, it seems, on specific machines and 
versions.

It would depend on the relative speeds of the CPU and the FPU

Ran code like the following against a 600MB file of 500,000+ lines:

	file: read/lines %log.csv
	foreach line file [
		remove/part line 1000
	]


and was surprised that the foreach loop was near instantaneous (I'd 
assumed 500,000+ removes would at least take a second or two). I'm 
not complaining, just curious. ;)

I do something similar, generating 10'000 lines and writing to a 
file takes 5-6 seconds to complete on my Intel Core 2 Duo E7400 (2.8 
Ghz) 3GB RAM.

500'000 lines a bit too much but you read the whole file into memory 
so it is possible. Your PC is a good one as well I think.

iCore 7 with 8GB RAM and a 256GB SSD ... work PC.

In R3, you can try do a >to binary!< on the results from the calculation 
and see the difference.

I need to extract the data from an image file so it does not include 
the "64#" header and I just have the 64 bit encoding: 

64#{
/9j/4faARXhpZgAATU0AKgAAAAgABwEPAAIAAAAESFRDAAEQAAIAAAAIAAAAYgEa
AAUAAAABAAAAagEbAAUAAAABAAAAcgEoAAMAAAABAAIAAAITAAMAAAABAAEAAIdp
is3eIoxUdG7n/9k=
}


I just wnat the stuff between the quotes but as its a binary I can't 
seem to parse it or extract it with other methods like a text file.

And the mod by 32 for a rotate is only ok on a 32-bit system, on 
a 64-bit it's mod by 64. And only for integers, not binaries etc.

Hm, implementing SHIFT in World gives me second thought. The C operators 
>> and << works as doing internal modulus. So checking for number 
of shift will hit on performance. So it's probably better to just 
go with it and let it be up to the user to eventually check for this.

What's the idea with SHIFTing a binary! ?

>> b: #{80402010}   
== #{80402010}
>> shift b 2
== #{20100804}
>> shift b 2
== #{08040201}	; so far so good
>> shift b 2
== #{02010000}	; but now we're loosing information
>> shift b 2
== #{00000000}


So SHIFT of a binary! just shift each byte and don't carry bits over 
to the next. What is this used for?

or you can use command line tool like Exiftool, and wrap the result 
using CALLL in REBOL and parse the output?

and you googled everywhere you could I suppose :-)

Has the esmtp code in rebol core been completely debugged?  Is there 
some documentation somewhere that discusses how to overcome problems 
is sending e-mail? A script that worked for years can no longer send 
e-mail, and I have no idea what the problem is. We are using a bluehost 
server.  trace/net on is not revealing the problem.

Limits relative to REBOL (based on the slides):
- Static scope.
- No dynamic binding.

- Some code won't work because it's too abstract for the type inferencer 
to figure out.


There are likely a few other bits here and there, but that's not 
very limited. A lot of non-optimized REBOL code should work, assuming 
the syntax is the same.

I was planning to use a desambiguation check on loading UDT with 
literal parsing rules, to avoid collision with other type's syntax 
and delimiters. It still need to be prototyped and tested with real 
code to see if it's worth it.

Brian: right, it will look and even feel very much like REBOL to 
most programmers that don't rely on higher level semantics and complex 
hand-optimized code.

I prefer code that can be loaded by a dumb loader, code that doesn't 
have different meanings depending on which module is loaded even 
before the code runs. I've had a lot of experience with different 
languages, and any language which requires you to read the source 
of its entire runtime library to debug properly is a bad one (I'm 
looking at you, Delphi and C++).

I have a working prototype of Red/System's tool chain (compiler+linker), 
but I need to clean-up the code first, add some runtime primitives 
(there's currently only PRINT and just working on string literals, 
so quite limited). I was thinking about making it available next 
week on github. Then I will start publishing every incremental revision 
there. I'll do an annoucement this week about that on Red's blog.

In theory, you should be able to build some R3 extensions in Red/System 
(I would need to implement the DLL linker support and 3rd-party DLL 
exported functions mapping first).

And that limit could be increased with time.

And that limit could be increased with time.

 Exactly. As Red's compiler will be coded in Red (once the bootstrapping 
 phase will be over), every new feature added to Red will benefit 
 to the compiler itself.

Go: It's in my scope of languages to study, like Scala, Lua, Factor 
and Rust.

Doc, you might also consider making your type inferencer aware of 
the ASSERT function. ASSERT/type in particular would provide useful 
information, and can be evaluated statically as long as you don't 
let the function be overriden.

Quick questions about Red/System:

- Do you have DO of block expressions (getting from a word, returning 
from a function), rather than scripts or inline blocks?

- Are the conditional control and loop functions built into the language, 
or are they functions?

- Can the aforementioned functions take block expressions, or only 
inline blocks?

ASSERT: I'll look into that.

DO of block expressions

 nope, it's too high-level for Red/System. Remember that there's no 
 block! datatype in Red/System, we're talking about a C-level language. 
 In Red, you'll be able to use DO (as well as REDUCE and COMPOSE) 
 pretty much the same way as in REBOL (will require the JIT).


Control flow functions: built into the language for Red & Red/System. 
They'll be expecting inline blocks as argument, but when the JIT 
will be available, this could be extended to block expressions.

ASSERT/type can do deep type checking of paths, and after the function 
returns the code can assume that the assertions are true. This can 
help with making code that would otherwise be too general for the 
inferencer to handle be really specific. To work best, ASSERT would 
also need to be built into the language, like the loop functions.

ASSERT and ASSERT/type don't have a way to test the number and type 
compatibility of function arguments for first-class functions. It 
might be worth looking into a way to check that, perhaps as an extension 
of ASSERT, which could be ported to R3 as well. ASSERT is also high 
on the list of functions to backport to R2 as a native function.

You should definitely make sure that Red/System supports CASE and 
CASE/all, since the style that those functions allow leads to really 
efficient code.

Look at the source of LOAD and sys/load-header for some good examples 
of the CASE/all style. It's worth supporting.

Maintainability of code. We found that the CASE/all style makes changes 
to code easy to make, and control flow easy to understand. This realization 
came out of the process of rewriting R3's module system into easier-to-maintain 
code.

Of course, this will be part of Red/System own small runtime, exposing 
among other functions, PRIN and PRINT.

As in REBOL: using /LOCAL followed by name and datatype.

And /local is special, not just another refinement?

And arguments and locals can only have one type in their typespecs 
for Red/System?

I meant offset references an internal pointer to the head and an 
offset index, like s: next s.

Going with the latter (s/:c) would be more compatible with REBOL 
and Red, and leave room for expanding Red/System's capabilities in 
the future.

And no FORALL and FORSKIP.

Things would be less confusing if Red/System and Red were compatible 
for corresponding concepts. This would also let you prototype Red/System 
code in Red.

Enough for tonight, it's very late here. I just wanted to give you 
some taste of what Red/System would look like. I'll work on Cheyenne 
new release and new documentation tomorrow, I should be able to get 
back to Red after that. I hope to be able to put the current codebase 
on github during the weekend.

If REBOL would have been open sourced the force of Doc would have 
improved REBOL and not splitted into RED.

It would still be nice, if Carl would completly open-source R3 though 
:-) Because it could lift certain amount of energy into some ppl 
confidence, and R3 could grow faster. Well - in theory, at least 
:-)

And a Twitter : http://twitter.com/red_chronicle

(/View, some typos, and creation of the builds/ directory if it does 
not exist)

Oh, did the same...now need to learn how to merge and resolve conflicts 
with Git :-)

By the way, you currently have two public branches in your repo, 
one called "origin" and one called "master". I would suggest making 
"master" the default branch and dropping "origin".

Nah, don't mind. I just drop the /View fix and forward-port the other 
two.

Yes, I did a bad move with my git client and created two branches 
instead of one. Looking in github for a "drop branch" button.

Forgot to mention in the blog, but << and >> operators are not implemented 
yet. They are defined in the compiler but lacks the backend part 
in the code emitter. Anyway, you can achieve the same using * and 
/ with powers of 2, they'll generate shifts instead of math ops.

Since red/system is c-level and compiled you can't and don't plan 
to have runtime goodnes of rebol in it. But the code is still data, 
so do you think you could use compile time macros to keep the core 
simpler and solve many things with macros then (like lisps do)?

The linker needs to be extended to add an "export" section and the 
compiler needs to prepare some data to populate that section.

In fact, support for incremental compilation is almost done, just 
needs testing/debugging. With that, you could feed the compiler with 
several sources while preserving its internal states and ask to "finalize" 
the job on the last one (means link the project).

Build hello.exe under OS X and works under Windows :)

I went through the code and it's very impressive to me. Most people 
these days wouldn't think it would be possible

the helloworld.reds script exe opens a console, writes stuff and 
then closes. Is there a way to keep that wndow open so I can see 
the output?

amacleod: It's mentioned in the README file:

4) The resulting binary is in red-system/builds/hello.exe, open a 
DOS console and run it.

Just wanted to say I really like the minimalist approach and am following 
this project with great interest.

And was OTCC behind your inspiration ?

Such dialect would be an IR (Intermediate Representation), I wanted 
to avoid that, for several reasons: simplicity, efficiency, performances. 
The porting effort is not so big with the current approach. Also, 
once I'll start working on the optimizing compiler version (next 
year), I would  use need an IR, and it would need to be a little 
higher level than that (emitter/ASM-like level).