AltME groups: search

Is there any place in your extension where series are passed between 
commands and are supposed to survive between calls?

Ah... ;-) To much c-coding. And there I don't use spaces that much.

according to Carl :

The most current graphics library changes have been included. Many 
thanks to Cyphre and the RMA project.
Beforehand, it was better to use the RMA compiled host-kit
I also have seen that some bugs disappeared.

Carl asks:


this week tried building libr3.so on PPC ... but there is a problem, 
the compiler is too old.

I tried updating gcc, but all the apt-get 
links are too old, and  it failed.   I'm looking for a ppc compiler 
>= 3.4, if you know where one is archived.

You have a R2 implementation of CALL for Windows here: http://code.google.com/p/cheyenne-server/source/browse/trunk/Cheyenne/misc/call.r


Shouldn't be difficult to port it to C and extend the existing R3's 
CALL implementation to support /output, /input and /error.

The issue with this async CALL is that it's not possible to make 
user events in R2's event loop, so it's relying on a dirty port hack 
and a bit of busy looping IIRC.

I was thinking of fire and forget, but that was my next question.

Async call, and async in general, is a lot easier in R3. I would 
be quite interested in an async call port in R3, particularly when 
we start to get port plumbing.

In fact, this blocking mezz-level CALL is used in worker process 
where it's allowed to wait. Right, WaitForSingleObject is the correct 
way, this CALL was just a quick adaptation of my async version for 
Cheyenne (I needed to pass environments variables to a child process 
for CGI support),  but I think I'll drop it in next Cheyenne revisions 
and use a different approach.

And maybe a more efficient evaluation in case of R3.

Yes to both of those. With the old LOAD, noone other than me could 
add features because the old control flow was too complex. With the 
new LOAD and LOAD-HEADER, features were easy to add.

The most efficient way to add non-conditional code is to put the 
code in the conditional clause and have none for the associated code 
block. There are several lines like that in LOAD-HEADER.

And it is definitely more efficient evaluation in R3, and R2 as well.

What makes CASE/all different from a long sequence of IFs?

 - as far as I am concerned, I simply don't use, and never used CASE/ALL

As to why CASE/ALL is hard to test: for example, if you have 10 cases 
in a CASE statement, and use 10 different tests for testing such 
a code, then, to be as thorough when CASE/ALL using 10 cases you 
would need 1024 tests.

How bad would it be to have a strict  version of rebol vs a relaxed 
version.  I'm thinking of things like skip which require an integer 
and choke on none ...

Can I create object from block of words and values?

See http://issue.cc/r3/1558and http://issue.cc/r3/1559

Is there some good documentation about ports and schemes? Finding 
anything on rebol.com is almost impossible.

http://www.rebol.net/wiki/Ports
http://www.rebol.net/wiki/Port_Examples

http://www.rebol.net/r3blogs/0130.html- More about Port layers - 
the OSI Model

http://www.rebol.net/r3blogs/0129.html- Simple TCP example: HTTP 
web page transfer
http://www.rebol.net/r3blogs/0128.html- Skip and Seek on ports
http://www.rebol.net/wiki/TCP_Port_Details

The same for DO B/1. Which is the difference between the WORD "now" 
used by "DO B" and the WORD "now" you get from DO B/1 ?

So, getting rid of the distracting REDUCE, the first line is this:
    b: [now]

It is a block with a word! value in it. In the context that the word 
is bound to, the function value NOW is assigned to that word.

You can either have a dialect processor like DO interpret the block:
    do b

or you can treat the block like data and interpret the data yourself, 
emulating the dialect processor (all of these lines are equivalent):
    do do first b
    do do b/1
    do get b/1

That makes some sense, thanks.

Also consistent with local words (and unused refinement words) in 
functions

That is not exactly what I had in mind. (especially when taking into 
account, that the usage of RESOLVE does not need to be considered 
"initialization") What I had in mind was, that:


1) there are two different values used to initialize variables: #[unset!] 
and #[none!]

2) because of that, the situation cannot be considered "consistent", 
unless one of the above values ceases to be used for initialization 
purposes, no matter whether we move some of the variables from the 
category of "initialized to #[unset!]' to the category of 'initialized 
to #[none!]'

Moreover, the local words in functions (I mean function arguments) 
actually are not initialized to #[none!]. The only observation that 
is true is, that after a function call, and only when the corresponding 
refinement is not used in the function call, the corresponding "refinement 
variables" are set to #[none!] - notice, that I intendedly did not 
use the notion of "initialized", since the function variables (do 
not confuse with closure variables) "exist" even before a function 
call is made in a sense, that can be easily demonstrated.

Does anyone know about some cross-platform decent serial communication 
library? I miss serial port in R3. We are playing with some devices, 
and serial communication is still being widely used method. We could 
ask Carl to release it for R3, or just map some existing open-source 
library as an extension. I could start bounty on that ....

A111, 27 Feb Linux PPC, 5 Mar Amiga OS 4 and there has supposedly 
been a Linux ARM build for a while

Why on earth doesn't Carl announce/blog/tweet this? He has plenty 
to tell, but seems to be intent on letting all supporters believe 
he and REBOL are dead

Unfortunately, A111 hostkits are only available for 3.1 (Win32) and 
4.4 (Linux libc6 2.11) so far.

Bug #1825 "Crash in RESOLVE" (and/or #1865 "SIGSEGV when importing 
modules") are getting annoying really soon, once you try to seriously 
use R3 modules.s

I am now regularly tripping over this in my own code, and I know 
of several people who do as well.

Available for 9 platforms (which makes it the most widely built R3 
alpha so far). Released between Feb-20 and Mar-5.

(http://www.rebol.com/r3/downloads.html)

And RMA of course publishes their A111-based hostkit.

It's probably time to reactivate my Git hostkit mirror, and update 
it with those recent sources ...

And for Linux libc6 2.11:
http://www.rebol.com/r3/downloads/r3-host-kit-a111-44.tar.gz

Carl just posted an answer to Oldes question in R3 chat -  he seems 
to be working on  Linux embedded systems. The worrying part is, that 
he admits R3 would be fine there, but he is not using it, and also 
no mention, what's his further plan with R3 .....

Red is compiled. REBOL is not, and many REBOL features aren't compilable 
to any kind of bytecode. Red won't have those features.

You might find that R3 could be accellerated by FPGA implementations 
of its function dispatch model, and especially action dispatch (redirecting 
to type-specific implementations of standard functions). Direct support 
for its data model might help too, for operating on blocks of value 
slots. The REBOL execution model doesn't really correspond to either 
a register-based or stack-based model, but the interpreter does have 
its own semantic model and you might be able to come up with a minimized 
core of that model that you could implement in hardware directly. 
I don't have enough knowledge of the limits of FPGAs to know for 
sure.

It would be possible to make hardware that interprets REBOL values 
directly (it would be VLIW in the sense, that REBOL values are usually 
large, ie. 16 bytes in R2), however the hard part is striking a balance 
between complexity and utility.


The simple fact that code would not be "flat" but more like a tree 
would pose a lot of issues compared to the mainstream hardware architectures.

Unlike JVM bytecodes, which were designed to be implemented in hardware, 
or CLR bytecodes, which were designed for JIT compilation, REBOL's 
semantic model was designed for efficient interpretation from the 
start, and then made more efficiently interpreted over time. A machine 
interpreter for the REBOL semantics would not really resemble the 
machine architectures with which you are familiar (maybe the Lisp 
machine?).

brianH none of the non compilable programming languages was a success. 
Face it Softwares companies want to steal idea from public domain 
but don't want anyone to steal from them that's how it is. And as 
compilation hum brianH SDK is a half assed intent to hide source 
codes of rebol scripts to people common view no ? So the statement 
I'm making Carl made it like 9 years ago when he create the sdk branch...

what are the things not compilable ? list them and then we will see 
if there are of any interrest in fact, if you want to discuss  things 
come with arguments for the discussion and not

So close and yet so far away. It could easily be called a beta right 
now, and a release with some more bugs fixed and just a bit more 
implementation, for example in SORT

R3 has a real chicken and egg problem. Much work could be done without 
Carl's direct involvement but for many people Carl's work is not 
yet sufficiently complete for them to do it. (A good example being 
the work you've put into R3 schemes, Graham).


The RM-Asset team are doing a great job of making progress with R3/GUI. 
Lets hope that they can continue and don't hit some issues which 
will need a lot of Carl's time to fix.

It is going to be a long. long time before there is a version of 
R3 published which inlcudes ftp, smtp and pop3.

Graham I was never able to get connection using Doc's NTLM to IIS 
6.0.   Do did you have success with a Windows domain where you can 
display the login with a REBOL UI and then request information from 
IIS?

Thanks. Doc and I have had a series of discussions on it where he 
has helped me out. In particular was Cheyenne being able to pull 
IIS information authenticated to a Windows domain for presentation 
from Cheyenne. We got to ... some more detailed / dedicated Doc work 
needed because NTLM is tricky.   That's not an option now because 
Red is a priority for everyone including me.  But if Curl enables 
it ...

NTLM is a hard to support, even using OS API. Making my NTLM implementation 
work in all cases would probably take days (or even weeks) of research, 
tests and debugging.

There are two sides to R3 adoption for me. First is the available 
features. I greatly prefer to have basic schemes (HTTP and FTP in 
particular) built in. A basic GUI system is also important to me, 
but I can use R3 for non-GUI things without that. The second, and 
more important, aspect is stability and robustness. Is the module 
model stable, is it robust? Will tasks ever work? Are there outstanding 
core bugs that will prove problematic if they are never fixed. That 
is, if RT never did any more work on R3, could I use it for production 
work?

The module model is stable for now, and has no current errors in 
the mezzanine code, though OSX has some errors in RESOLVE. When tasks 
are supported better there will need to be some minor underlying 
changes, but not many because the module system was written with 
the proposed multitasking model in mind. The module list hasn't been 
locked down from a security standpoint, though its layout was designed 
with that in mind. There are still bugs and missing features in the 
(UN)PROTECT functions that are blocking the locking down of R3, so 
don't run untrusted code yet.

And if R3 stops now ... is there any advantage to R3 over R2 ?

Sure, either mezzanine or host-embedded extensions. And loadable 
extensions too, while SECURE isn't working.

And this is the main advantage over r2?

As for advantages, YMMV. For me, the improved PARSE, binary conversions 
that make sense, the map! type, the module system, the faster and 
more powerful loops, better error handling, and the increased consistency 
make R3 much easier to use. The extension model makes it more powerful 
- I always hated R2's library access model. But I don't do much GUI 
work in REBOL. R2 has database access that I use pretty often, and 
HTTPS support which I use rarely but it's important when I do. I've 
backported the most important missing functions from R3 to R2 in 
mezzanine form, though there is still some stuff I miss.

The improvements in 2.7.8 were pretty significant, so R2 is getting 
a lot more useful. I would love to have some kind of proper dialected 
binary conversion facility in R3 that could be ported back to R2, 
preferably compiled (generating conversion functions) - that would 
make it possible to have code like Red's compiler a lot more portable 
between R2 and R3, no explicit struct! use needed.

I can't invest any time in R3 without a fully working GUI and https

Between a rock and a hard place

0MQ is a wedge for me, between the rock and hard place. If I can 
use that for messaging, pieces can be (re)written in any language.

And also a danish: galge humor
where galge = gallows

I've already finished the major projects I was working on in R3 itself, 
like the module system; I can't start more without the protection 
bugs being fixed. My next stuff is all docs (modules and PARSE) and 
addons (that dialected binary conversion, plus maybe some schemes). 
What I really want to work on is Android, but I can start that work 
using Red for now.

We already have odbc, and a possible sqlite ...

And the ODBC scheme is indeed using the Windows interface

(And get that merged back into the native later on.)

here's one list i once started of crashes and blockers:
1422    Rebol crashes when opening the 128th port
1799    maps broken for >2**24 entries

1806    Error after loading an extension: "REBOL System Error #1207: 
assertion failed"
1825    Crash in RESOLVE
1865    SIGSEGV when importing modules

1867    In extensions, returning with RXR_BAD_ARGS or RXR_ERROR has 
no effect

feel free to send me your blockes, and i'll collect them as well

we are missing device extensions and there are some limitations in 
the event model which make it impossible to extend it with new event 
types or actually fixing some of the weird event handling I've seen 
(its munging some events being fed by windows).

And it can't be called alpha or beta.

I'm all for anything that moves us forward, but solutions like cURL 
and CALL via an extension means I know I'm going to have to change 
things later, or live with more pieces.

And it can't be called alpha or beta.
 ?

We need a prioritized list of stuff that we need Carl to fix. The 
rest (mezzanine and host) we can do ourselves.

(Just privmsg me and I can try it quickly.)

Crashes on Linux and OSX as well.

6 works on Linux and OSX on a fresh console every time as well.

Where exactly is one supposed to store user specific data for scripts 
eg. userid and passwords

I'm suggesting a couple of wrapper functions to return userid and 
password etc so that these can be changed if the store system changes

The only consensus we reached was that %user.r would be a good place 
to store preferences, and that it should only store data. Executable 
code would be prohibited in %user.r, and screened for. But we never 
started the discussion of how the preference data would be formatted 
or managed.

The no-executable-code thing is a security issue. R2's treatment 
of %rebol.r and %user.r is a big hole.

These settings shouldn't go into system/user in R3, they should go 
in system/options/user. The system object will be task-specific, 
but the options are probably going to be global. And system/options/user 
might best be a map!, with categorized options in sub- maps, blocks 
or objects, depending on the situation. Or better yet just sub-maps, 
with the serialized preferences in blocks of name-value pairs so 
they can be parsed, and converted to maps at runtime.

Two-level category-options, and then the values could be any type 
you want. Screen thoroughly for evil values.

The %user.r serialization of this data should be human-writeable 
and loaded with LOAD, not DO.

But the slowness of validating would be offset by the speed of loading 
and saving, so it might be worth it.

Another disadvantage is that loading errors are currently harder 
to recover from with serialized constructors than they are with normal 
literal values like blocks. There's a ticket about this already. 
However, if you are loading the entire preference file in one go 
and just catching the error with TRY, there's no difference in the 
error handling.

The only consensus we reached was that %user.r would be a good place 
to store preferences, and that it should only store data. Executable 
code would be prohibited in %user.r, and screened for.
 - frankly, that decision never made sense to me.

...and I am afraid, that it is not hard to prove

The real distinction is between serialized constructors: #[map! [a 
1]]

and programmatic constructors that you have to DO: make map! [a 1]

Not at the OS level. We can only define permissions within REBOL 
itself, not permissions when it isn't running. And REBOL doesn't 
have any facility for user-specific permissions.

as said, for me the formulation: "...a file that is done automatically 
be writeable using the same permissions that the scripts are run 
under..." is substantial, and it can be done, as far as I know.

The difference between #[map! [...]] and a constructor is roughly 
the same as the difference between a constructor, and a list of arguments 
given to the constructor, when a constructor is called - it is a 
totally different thing.

I am talking about the code that is called when those syntactic constructs 
are loaded, which is type-specific and constructs a value of that 
type. REBOL types have 3 builtin constructors (#[type ...], MAKE 
and TO). The user can't create new constructors because the user 
can't create new types.

And #1857 indicates that the #[type ...] constructors are seperate 
code from TRANSCODE, and called by it.

...and it surely does not make sense to call #[map! [...]] a "serialized 
constructor" - it is just a syntactic "construct" used as data by 
something.

I do not know whether I should repeat my opinion or not, but, here 
goes:

#[map! [...]]


and similar syntaxes are not "constructors" in the standard sense 
of the word. That is why I do not like seeing such phrases in documentation 
or elsewhere.

Andreas, in the OSes with which I am familiar, you can't set a file 
to read-only and then count on that file staying read-only unless 
the user is asked for permission to change that setting. In REBOL 
you can. The security of a DOable %user.r depends on it not being 
writeable between when REBOL shuts down and when it starts up again. 
So that means using OS permissions to guard it, and those are based 
on user capabilities, not enough protection. The situation is different 
with %rebol.r since we only load it from the same location as the 
R3 executable, and that location can be protected with user permissions; 
this is why we can still DO %rebol.r in R3.

The security of a DOable %user.r depends on it not being writeable 
between when REBOL shuts down and when it starts up again.

Why?

I do not agree with "The security of a DOable %user.r depends on 
it not being writeable between when REBOL shuts down and when it 
starts up again."

Because you can have a worm spread using a combination of REBOL and 
code that is not written in REBOL but writes %user.r to do its propagation.

you can have a worm spread using a combination of REBOL and code 
that is not written in REBOL but writes %user.r to do its propagation

- yes, you can, but when you run a worm like that, then you are insecure 
anyway, since the worm could overwrite even your rebol.exe file.

Sure, and such a worm could spread much more easily by writing my 
.bashrc to do the propagation.

And I don't really trust .bashrc for that reason, though there might 
be some OS protection for that file of which I'm not aware.

Depends on where you put %user.r and your OS capabilities, I guess.