AltME groups: search

A function! is a more complex value, which contains a spec and a 
body.

Although, now that I think about it, that *could* be useful in some 
circumstance, maybe.... Many functions with similar argument lists 
could share a context.

ok. Thanks a lot.

I think I can bind a bunch of functions as well, right?

So for example I specify a block of function names, that I want to 
bind.

You could append each function's body block to a single, large block. 
Then bind that.

blk: [] foreach func funcs [append blk second :func]  bind blk ctx-A

Yes, remember it's possible for same-named but differently-bound 
words to coexist together in a block.

Each word has a single value slot (per context).

If I'm binding SECOND FUNC the body's reference is used, so this 
particular block is bound. Not a copy.

>> ctx-A: context [a: 60]
>> my-func: func [][a: 5]
>> bind second :my-func ctx-A
== [a: 5]
>> ?? ctx-A
ctx-A: make object! [
    a: 60
]
>> my-func
== 5
>> ?? ctx-A
ctx-A: make object! [
    a: 5
]

>> ctx-A: context [a: 60]
>> my-func: func [][a: 5]
>> blk: [] append blk second :my-func
== [a: 5]
>> bind blk ctx-A
== [a: 5]
>> ?? ctx-A
ctx-A: make object! [
    a: 60
]
>> my-func
== 5
>> ?? ctx-A
ctx-A: make object! [
    a: 60
]

foreach func funcs [bind second :func ctx-A]

>> ctx-A: context [a: none]
>> f1: does [a: 1]
>> f2: does [a: 2]
>> foreach func reduce [:f1 :f2][bind second :func ctx-A]
== [a: 2]
>> ?? ctx-A
ctx-A: make object! [
    a: none
]
>> f1
== 1
>> ?? ctx-A
ctx-A: make object! [
    a: 1
]
>> f2
== 2
>> ?? ctx-A
ctx-A: make object! [
    a: 2
]

Ok, thanks a lot. That's stuff I'm really going nuts by. I think 
I will collect all kind of examples and publish them.

A BIND how-to, that not only explains what's going on but shows examples, 
examples, examples is what we need.

I actually think that your best bet here is to pass the context you 
will be saving to the saving function as a parameter, like your original 
example  storage/save-record context-to-save  or if you really want 
to delegate you can assign the function as a member of context-to-save 
and call it like  context-to-save/save-record context-to-save , but 
then you are changing the context you are saving wih saving overhead. 
REBOL does direct delegation by default, rather than mixin delegation 
like Delphi, because REBOL doesn't pass the object reference as a 
hidden parameter like object-oriented languages do. Rebinding your 
function body every time would be time-consuming and either non-recursion-safe 
(bind) or consume a lot of memory (bind/copy) - just passing the 
context as a parameter would be quicker.

I might fall back to the parameter solution. My goal is, that with 
BIND the code becomes much more natural to read and maintain. Because 
teh storage context needs some knowledge about the context to save, 
as I'm using a dynamic field-mapping method. Hence I only need to 
alter the context-to-save (add / remove words) and the storage context 
can handle it automatically. I have to deal with scheme evolution 
and versioning.

Anton: "
>> ctx-A: context [a: 60]
>> my-func: func [][a: 5]
>> blk: [] append blk second :my-func
== [a: 5]
>> bind blk ctx-A
== [a: 5]
>> ?? ctx-A
ctx-A: make object! [
    a: 60
]
>> my-func
== 5
>> ?? ctx-A
ctx-A: make object! [
    a: 60
]


 - you would have to change it to:

ctx-A: context [a: 60]
my-func: 
 func [][a: 5]
blk: [] append/only blk second :my-func
bind blk ctx-A
?? 
 ctx-A
my-func ; == 5
?? ctx-A

No.  I think I didn't think I still wanted to think about it, perhaps 
finding a better way as the second function is attempting to do.

i think there are issues with ftp as a url path is not guaranteed 
to match the file system path

A URL path is _supposed_ to map to the file system path _if_ the 
scheme is ftp://
/
 has no assumed hierachical meaning in other URL schemes.
Hence the confusion at times.

I think REBOL is playing safe in not assuming the mapping. And, given 
how badly many FTP clients are written, that is probably for the 
best.

then you can query the smtp directly.
Try 

insert smtp "HELO Louis-here"
probe copy smtp
and you should see a response

made a feature request for it

Temporarily made this group not web-public. I guess in a day or two 
we can switch it back. Not sure how it works.

Don't worry about that email address. It was a temporary one I created 
for test purposes.

Hmm.. I don't know the correct terminology, so I can't explain what 
I mean very well...

>> smtp: open/lines tcp://bible-way.org:26
>> insert smtp "HELO Louis-here"
>> probe copy smtp
** Access Error: Network timeout
** Near: probe copy smtp


SMTP ports stay open while data is transferred back and forth.  Copy 
doesn't return until the port is closed - so in the above line, copy 
is waiting until the server closes SMTP, and the server is waiting 
for a command from the client.


It's the reason why (as I understand it) Grahams "pick smtp 1" worked, 
but copy did not - SMTP was still open, even though there was data 
for the client to read.  (I was stuck on that myself for a long time 
 ;-)

just be careful though, because you may end up compariing a 1 char 
string! vs a char! , you might not get the result you expect
y
 <> #"y"
== true

It is, but since it is not a priority it can't be given a deadline.

quite a bit of code there. hopefully my suggestion for EXTRACT for 
REBOL3 will be accepted :-) that would make this a whole lot simpler

graham, I looked at printf and it seems to require a DLL interface?

Try this thread, which includes a version of Gabriele's form-decimal 


http://www.rebol.org/cgi-bin/cgiwrap/rebol/ml-display-thread.r?m=rmlLTLK

Rebol uses ' as a separator

I have trouble sending a BCC email with the new send function. Can 
anybody verify ? (I am using authenticated smtp)

looking at send source, /show just clears the header to field, so 
it works when you send to multiple recipients and each one doesn't 
see who else received the email. When a message is sent to a single 
recipient the client shows the message is directed to you anyway. 
The trouble is this is not bcc

Sorry, the above to posts refer to the Core 2.3 docs. I have trouble 
with the "similar to bcc" If someone can provide some hints on how 
I should handle BCC then I will modify send source. To me this is 
a bug (i submitted to RAMBO) and I don't see what's the point of 
having BCC field in the standard header if this field is ignored

I can't think of any reason why an email client should ever receive 
an email with a bcc field.

Graham, I tried that but you get the same email than before with 
a different recipient but no BCC. I want to use BCC for some archiving 
project so I want to preserve the original To field like in real 
Bcc messages

A semi-solution to this problem has been posted in RAMBO http://www.rebol.net/cgi-bin/rambo.r?id=4103&

This is a hack because the message shows the original headers so 
it's not true bcc but it partly solves my problem thanks

Joe, I had problems with BCC in a corporate mass emailing I did. 
 Even though it did not display the email address in the mail client, 
if you viewed the header of the mail message the BCC content was 
there.

A disgruntled recepient spammed the entire BCC list indicating our 
company didn't care or respect their privacy... just my luck.. .this 
was the first attempt to use Rebol for a valuable task at this job!! 
:-(

send - i think there is a lot of confusion here

the BCC header field is a field used by mail clients to let users 
type addresses that will *not* be included in the header. it is, 
basically, a user interface. back at the time mail clients did not 
have a gui, and just processed mail from a file or by letting you 
type them on the terminal

so what a mail client does, is reading the mail, collecting the addresses 
from to, cc, and bcc, removing the bcc lines, and then sending the 
message to the collected addresses.

but send is not a mail client. it is a function to send email messages.

to make things easier, send will fill in a default mail header if 
the user has not provided one. however, if you are after something 
more complex than send [luke-:-rebol-:-com] "hi!" then you probably will 
want to pass your own header.

this header is sent as-is, except for a couple things such as setting 
To if you haven't set it (this is so you can have a header template 
and send many messages with it easily)

now, since this is a very common error among users, it may be useful 
to let send remove bcc. personally, i will vote against this, because 
i prefer educating users (documentation) rather than keeping them 
stupid and happy. ;) even in the case we do it, send is still *not* 
collecting the addresses from bcc anyway - so we're just wasting 
time removing something that someone wasted time adding.

so what you need to do now to send a message is - just send/header 
[list of addresses] msg header, with header being composed correctly 
- to should have what you want your recipients to see in to, from 
should have what you want your recipients to see in from, and so 
on; there should *not* be any bcc lines.

graham: that's a good idea and the desktop already has something 
like that, a gui that lets you type to subject and message. we could 
just add bcc and cc

also, i think there are a couple of mail clients written in rebol 
around :)

IMHO that are to much internals. I would add bcc to send. First, 
if you use bcc, its almost 100% a privacy issue. So at least no bcc. 
Second, users read "email", they know email and email has bcc. What 
happens inside the mail-client they have no clue. So bcc should also 
be added to the header-list IMHO. At least as option, send/bcc or 
such. Should not be much parsing and things works a lot more right. 
As this discussion proves.

To pass recipients in the bcc too, parse that.
  send/header [x-:-y] text [bcc: "[a-:-b]"]
-> mail goes to [x-:-y] and [a-:-b]

send [to: ...] msg     where send detects this checking for a set-word?

Not mm, Brocks. "Joe, I had problems with BCC in a corporate mass 
emailing I did.  Even though it did not display the email address 
in the mail client, if you viewed the header of the mail message 
the BCC content was there."

currently we have a brief dictionnary with SOME but not all of the 
information.

No we don't. A programmer who wants to know how the mail system works 
should read existing standards documents.

if a language has a feature which supports something, it has to explain 
exaclty how it does it.

send  is just the example of what the word does SOME things more 
than it should, but not all, and does not fully explain everything. 
 We are used to a lot of consistency in rebol. and if a word makes 
email shortcuts but not all of them... I understand the frustration 
which can come from a mistake, when you can't really know how -REBOL's- 
mail handling is performed... no matter what are the standards.

But, how about dropping 'send and switching to 'email completely 
in R3? 'send is a nice word for rebservices etc. IIRC Carl noted 
that somewhere.

http is supposed to be handled in rebol, yet I had to rewrite my 
own http-post function to talk to a webservice operating only in 
http1.1 of which rebol had a lot of trouble handling.  yet the service 
was compliant and rebol was not.

make send more stupid so we assume/expect less of it.  and make a 
proper email function which handles most common useage like a mail 
client does it.

I've got a question. open/skip does not work?

I just spent a couple of nights working on a batch-downloader.

Anton, yes bcc is a blind copy. Gabriele explains it better than 
I did.  I found it very easy to code the new send function with the 
snippet above . The trick is to compose the right header and then 
send the message to both the to and bcc recipients. The MTA does 
remove the bcc field so the to: recipient or even the bcc: recipient 
do not have a bcc header field

Maxim, re http-post. Are you talking about a bug in the http scheme? 
You seem to be implying something structural. Is the issue fixed 
in the new versions of REBOL or still present?

I though I've got it working but it was a mistake. I'm still not 
able to use /skip refinement on files succesfully. Does anybody now, 
if it's possible to OPEN or READ file from some offset? I saw some 
bug filled in RAMBO two years ago :(((

Do I need reduce/deep? Example:
x: 0.123
v: reduce/deep [ [- x 1.0 1.0] [0.0 0.0 0.0] ]

v should now hold: [ [-0.123 1.0 1.0] [0.0 0.0 0.0] ]
But reduce don't have a /deep refinement, and if I do:
v: reduce [ [- x 1.0 1.0] [0.0 0.0 0.0] ]

those inner blocks ain't reduced. Is there another easy way? I don't 
wanna have REDUCE inside the block.

compose/deep ? Also a reduce-deep would be a few lines.

Yeah, I guess. compose/deep require parens inside the block. I could 
make a reduce-deep function, but that'll hit performance. REDUCE 
is native. Should reduce/deep be part of REBOL 3 maybe?

You need a lot performance?

I'm using this feature in the OpenGL API, I'm working at. Maybe I 
could do a late reduce, when accessing the inner blocks.

Is there a time when one doesn't want inner blocks to be reduced?

James,  parse-rules inside a block?

You would think  there would be a "complete" reduce parameter though 
that just works the way one would think it would.

Would rebcode be an option? Or a dll for some datastructures?

Volker, a rebcode version will probably make sense later, but I'm 
under OSX right now, where the rebcode is an old version.

I doubt  i find a good idea, so if i am boring just say stop.

Would it work to flatten the datastructure? /skip instead of nested 
blocks? Tehn 'reduce would work.

Well, that could work. But the situation is, that the datastructure 
is made by the user, so it should be as straight-forward as possible. 
Example of a structure:

vdata: [	
	[- X 0.0 Z] [X 0.0 Z] [- X 0.0 - Z] [X 0.0 - Z]	
	[0.0 Z X] [0.0 Z - X] [0.0 - Z X] [0.0 - Z - X]	
	[Z X 0.0] [- Z X 0.0] [Z - X 0.0] [- Z - X 0.0]
]


I think, I'll do a late REDUCE of the inner blocks, when I access 
them. But thanks for your ideas! :-)

You could also "compile" the users data into something else one time, 
and have a better format in the loops?

james, no C syntax. I'm making a REBOL version of the OpenGL API 
with REBOL syntax. Users will be able to use normal REBOL and call 
OpenGL functions (with REBOL syntax).

John, Is your opengl api rendering in a rebol window or face?

The commands are sent to a C program (task), that'll execute the 
OpenGL code. So the C program owns the window, not REBOL.

james, no. It's from 2 different programs. The datastructure is just 
used in one example. Some OpenGL commands take pointers to datastructures 
as a parameter.

You can see the full example here: http://home.tiscali.dk/john.niclasen/OpenGL/GLClient.html

First you have the C source, and below that the REBOL source, that'll 
do the same thing. I first thought about putting a REDUCE in, where 
vdata is defined, but I've changed my mind. The glVertex3fv function 
has to reduce it's argument.

And that of course doesn't work. The datastructure has to be like 
this in REBOL:

vdata: [	
	[- X 0.0 Z] [X 0.0 Z] [- X 0.0 (- Z)] [X 0.0 (- Z)]	
	[0.0 Z X] [0.0 Z (- X)] [0.0 (- Z) X] [0.0 (- Z) (- X)]	
	[Z X 0.0] [(- Z) X 0.0] [Z (- X) 0.0] [(- Z) (- X) 0.0]
]


Maybe it's time to make a new group about this. I'm not home the 
rest of the day (beer festival going on), but I should have something 
for others to try out tomorrow (those who's interested).

Volker, I've solved the reduce problem, and it makes sense now. The 
C function glVertex3fv takes a pointer to it's data as a parameter. 
I do the same thing in REBOL (using a block), and I then reduce it 
inside the REBOL function glVertex3fv itself.

heh, it works now. I get a icosahedron drawn. :-)

Is there a way to mix it with the 3d-engine from the contests? So 
plain rebol could be used as 3d-editor?

YOu would get  a robot for free :)

Thanks! Actually I map from the pointer function glVertex3fv to glVertex3f, 
which takes it parameters as values, but that should be no problem. 
(I can't send a pointer to another task over tcp.)

(I suddenly have name-blackouts) That great tutotial-writer has a 
little demo how to use the  engine IIRC.

Yes, it should be possible to call my OpenGL functions from an engine 
like that. That's the sort of things, I'm going to use this for. 
Only thing is, that the OpenGL window is inside a C execute, so you 
can't put REBOL controls (view stuff) in there. But you can then 
just have 2 windows.

I think of a world ingl, with lots of models. and for editing a model 
can be picket into the rebol-window. (much smaller, rebol can handle 
that.) But maybe overkill and better concentrate on gl-integration?

We'll see, how fast this thing I'm building will be. I hope to be 
able to use it like you think of - having a world with lots of 3D 
stuff and be able to walk around and change things.

I'm announcing this because it took me a bloody long time.

You could fairly easily do your own recursive make-dir at the usual 
rebol level, but since the recursive mkdir is done inside the handler, 
the overhead of opening/closing/initializing ports is avoided.
Phew!  I'll publish that after some more cleaning and testing.

Isn't this a bit funny?

>> "x" = "X"
== true
>> #"x" = #"X"
== false

But luckily it works in e.g. SWITCH:

>> switch #"x" [#"X" [print "x found"]]
x found

Maybe
#"x" = #"X"
should be true in REBOL3?

It's possible to add a /case refinement to the SWITCH....

Ah, maybe not. E.g. #"a" = 97 is true. #"A" = 97 is false. I suppose, 
this is the best behaviour.