AltME groups: search

but doesn't call it

to get around it I use this function    call2: func [file][call quotate 
quotate to-local-file file]

Perhaps you want 'run and not 'call ?

e.g.  call: func [file] [system/words/call quotate quotate to-local-file 
file]

old: context [call: get in system/words 'call]
call: func [file] [old/call quotate quotate to-local-file file]

call: func [file] compose [(:call) quotate quotate to-local-file 
file]

Anton, I think, it's a "ground rule" in Carl's design of the language, 
that everything entered into the parser are datatypes (or series 
of datatypes). I can't think of anything with semantic meaning, that 
is not a datatype, when we talk REBOL. The language is recognized 
by it's minimalistic syntax. That's why I call it a "ground rule".


I think, it's legal to call REBOL a sequence of datatypes. It's maybe 
more precise than calling it a programming language (also because 
it's so different from traditional programming languages).


And then, yes, he has added newline markers to e.g. blocks. But they 
have no semantic consequence.

call "touch.exe"

tough call, but if it can't lead to data corruption, I'd say the 
later.

At least don't call it a "chat system" without the description "direct 
hotline to the main developer", as that line would stand out and 
make people think it's a joke

Same problem with call:

>> call "pwd"

/Users/peter/Desktop/Rebol3

== none

I checked call on Windows and it doesn't work either. I opened ticket 
757.

CALL works correctly on Windows. The behavior you describe in ticket 
757 is by design. See the comments for that ticket.

The mac version appears to be working. At least call "ls" gives me 
a directory listing.

Yeah. CALL doesn't return a value yet. I'm waiting for the host source 
before I make proposals.

Or rather, CALL retrns none.

>> source launch
launch: make function! [[
    {Runs a script as a separate process; return immediately.}
    script [file! string! none!] "The name of the script"
    /args arg [string! block! none!] "Arguments to the script"
    /local exe
][
    if file? script [script: to-local-file clean-path script]
    exe: to-local-file system/options/boot
    args: to-string reduce [{"} exe {" "} script {" }]
    if arg [append args arg]
    call args
]]

Louis: Better solution
browse: funct [ url ] [ call reform [ "x-www-browser" url ]]

And browse works, and all commnads based on browse ( docs, bug, changes 
) too

what do you call words such as "back" and "tail" and "next"?  Is 
there a special term were using for these?

I call them navigation functions, usually for series. I'm not aware 
of any official term.

You don't call make-module - MAKE calls it.

I don't care about the exact name much ... I usually call it reduce 
but reduce has a very important and basic meaning in rebol already

Posted by Doc - "Having the TCP/IP part open-sourced in R3 will be 
great. It will allow to use much faster OS hooks for file transfers, 
extend the port! API to bind only on selected interfaces, etc...I 
wonder if the main event loop will be there also, so we can replace 
the not-scalable Select( ) call by other faster ones or even integrate 
libevent. That would definitely make Cheyenne able to handle a much 
higher number of connections."

I don't want to call it "unit!" because the type would be really 
poor for that, and we don't want to reserve the word "unit" for a 
poor implementation of the idea, especially when we have user-defined 
datatypes.

I know. I just thought, that money (better let's call it currency), 
is just another unit ...

constructors: I guess, that it is actually "nonstandard" to call 
#[...] representations "constructors", since they actually aren't 
"methods used to create instances of...", in fact, they actually 
aren't "methods", but rather "textual representations"

moreover, the #[...] constructs are actually executed by the LOAD 
function (or maybe Transcode,...) internally, which may call whatever 
functions it likes to construct any specific datatype represented 
by the discussed #[...] text, but this does not make the "#[...]" 
text a function, anyway

Ladislav, if you think that I am saying that the lexical form #[...] 
is a function call, you are wrong. I am saying that the processing 
of that lexical form is handled by an internal function call that 
constructs a value of a particular datatype. That is what I have 
always beenn saying.

quoting brian " the syntax matches the international currency syntax 
standard" well... to me that's resoved then .... lets call it currency! 
  :-)

Yup, it's a noop. It was deemed more important to eliminate all potential 
test-to-see-if-something-is-a-bitset-and-not-call-unique code.

Yes, but making it native might be a good idea. I call this function 
a lot and with a lot of numbers while filling input-forms.

I meant the one he labeled "the bottom level", the non-transitive 
one  ;)

I'll call "the bottom level" level 1, then increase to 4, for now. 
 Generally I only use EQUAL? in R2, which appears to me to be level 
2 (although you named it level 1?), but can see why the stricter 
levels 3 and 4 are helpful - I just don't see where level 1 can be 
used right now.


As far as naming goes, my only question is the need for negatives. 
 Why isn't NOT sufficient? ("not equal?" rather than "not-equal?", 
etc)


I forget MAKE can be used with things other than object!, I use it 
that way so rarely.  So yeah, /deep doesn't make sense now that I 
think about it   =P

(the variants having different case are "automatic aliases", as I 
call them)

yes, but it takes time: the "probability of encountering" is proportional 
to running time as well as to call frequency

Will there be a way for R2 users to call the R3 dll and use it that 
way?

BrianH: is there any difference between R2 and R3 'call functions? 
I would like to test the boot time of R2 vs R3, and I thought I might 
use one REBOL process to call another one in a loop. I want test 
R3 vs R2 and R3 vs Rebbase. What methodology would you eventually 
suggest?

CALL has been completely rewritten in R3 - it has almost nothing 
in common with CALL in R2, and is much lower-level. If you want to 
compare the startup times, if you use the same method to call all 
of them you should have something comparable. R3's CALL doesn't wait 
for apps to return yet on Windows, so writing your wrapper script 
in R2 might be easier.

Why is 'call limited in functionality in comparison to r2 version, 
and why also 'shift misses all its refinements?

CALL is lower-level, and thus faster in theory, and easier to implement 
on different platforms which might not have all of the concepts in 
the old R2 CALL. SHIFT doesn't need any refinements, and is *much* 
faster without them. Refinement processing overhead is really significant, 
even for natives, so low-level math functions tend to not have them.

Two questions about calling other programs /scripts:


* when is CALL going to get some refinements -- like /wait and /output 
?

* what is the point of:
     launch none 
    ?

AFAIK:

* CALL might or might not get refinements - it may be a better strategy 
to just fix CALL so it doesn't need them. In any case, changes to 
CALL are likely to happen after the host code is released, since 
that is where CALL is implemented.

* What is the point of <anything about how LAUNCH behaves>: It's 
due for a complete redo - none of its current behavior is intended.

BrianH: I miss call/output, call/wait refinements at least ....

I also don't understand, why the regressioin of 'call happened.

Following on from asking about CALL and LAUNCH.....Is TASK meant 
to be any thing other than a placeholder in the current alphas? All 
it does for me is crash the console.

I somehow can't understand, what is the difference between a plug-in 
funciton, and for e.g. C level function wrapped into DLL call (R2 
way)? The example provided in doc shows rather complicated aproach 
of how such function has to be constructed. You simply can't write 
it your way? There has to be some reason for it :-)

Pekr, there is no regression: CALL in R3 is an entirely new function, 
which uses an entirely different, lower-level method to call stuff. 
I don't know whether the /output and /wait methods are possible with 
the new method, or whether they will be necessary once CALL is fixed. 
Right now CALL is a placeholder - the implementation is going to 
be in the host code (read: open-source), so development has been 
put on hold on CALL until the host code is released (which is intended 
to be soon).

As for the JIT, I could write the compiler in REBOL and generate 
the intermediate code of the JIT, then pass that intermediate code 
to the JIT with a command. The JIT would then generate a function, 
add it to its list, and return the list index as an integer. That 
integer can be  used to create a new command!, which RX_Call can 
dispatch to the internal JITed function.

not to vex, I hope, but I just saw that PHP 5.3.0 added so-called 
"now docs" which are what I call literal strings or verbaibm strings 
in that no substitiutions occur so no escaping is done.  I believe 
this how at least comment {should behave in R3 if I use a { as in 
just print {this} { to get the effect you want }  which comment is 
not the same which has to explain that you do whis without the escapes 
- which is fine if thosei are the only and very  escapes in question 
...

Tried R2 vs R3 call (R2 used using /output refinement):


1) "icacls c:\windows" - R3 call returns output, but you have to 
press enter to get back to console prompt - why?

2) "dir c:\windows" - R2 works, R3 returns following error - why?

>> call "dir c:\windows"

** Access error: external process failed: "Systém nemùže nalézt uvedený 
soubor.^
M^/"
** Where: call
** Near: call "dir c:\windows"

Works beautifully in linux R3 2.100.76.4.2 :
	call "ls -l user.r"

Try other commands: call "cmd" ...

hehe, interesting - I run call "cmd.exe" and now I seem to get the 
mixture of windows shell and rebol one or so? :-) REBOL history is 
gone, when I try print "ahoy", it returns czech message, telling 
me PRN can't be initialised :-)

Try   call "start dir"

Fresh R3 console, typing call "dir", getting still the same error

Try   call "cmd dir"

>> call "cmd dir"
== none

>> Microsoft Windows [Verze 6.0.6001]

Copyright (c) 2006 Microsoft Corporation. Všechna práva vyhrazena.

c:\!rebol\altme\worlds\r3-gui\files\rebdev>

ah, consecutive call works, interesting ...

>> call "cmd dir"
== none

>> Microsoft Windows [Verze 6.0.6001]

Copyright (c) 2006 Microsoft Corporation. Všechna práva vyhrazena.

c:\!rebol\altme\worlds\r3-gui\files\rebdev>dir
** Script error: dir has no value


>> dir
 Svazek v jednotce C nemá žádnou jmenovku.
 Sériové èíslo svazku je 0054-60D0.

 Výpis adresáøe c:\!rebol\altme\worlds\r3-gui\files\rebdev

13.08.2009  12:12    <DIR>          .
13.08.2009  12:12    <DIR>          ..
02.07.2009  15:38    <DIR>          base

so:

1) call "cmd dir" boots me into cmd shell - notice single >
2) calling dir there boots me back to ... where? Notice >>
3) then mysteriously dir works from there ...

Some commands work, some don't call "path" does not work, call "help" 
works, etc.

Pekr, commands like dir and path are built into cmd.exe - they aren't 
separate programs. So CALL "cmd.exe /c dir" should work.

At a command prompt, call cmd /? to get help on cmd.exe and its commands.

R2 intermixed the cmd shell with CALL - with R3 you do that manually 
if you need to.

As for your other question, look at this:

>> call "cmd.exe /c dir"
== none

>>  Volume in drive E is APPS
 Volume Serial Number is 7845-7730

 Directory of E:\REBOL\2.100

01/14/2009  03:17 PM    <DIR>          .
01/14/2009  03:17 PM    <DIR>          ..
01/14/2009  03:24 PM    <DIR>          base
01/15/2009  12:17 PM    <DIR>          updates
07/12/2009  03:08 PM                56 blah.txt
02/25/2009  08:09 PM               492 user.r
03/02/2009  10:22 PM    <DIR>          work
04/09/2009  08:41 PM                66 test.r
06/13/2009  12:09 AM                28 mod1.r
06/13/2009  12:09 AM                28 mod2.r
06/13/2009  12:10 AM                47 mod.r
08/10/2009  08:39 PM    <DIR>          plugin
08/13/2009  03:35 PM           613,376 r3.exe
08/13/2009  07:08 PM    <DIR>          extension
08/13/2009  08:46 PM            20,480 ext-test.dll
               8 File(s)        634,573 bytes
               7 Dir(s)   4,893,769,728 bytes free
1 + 1
== 2


I did that 1 + 1 to show that I didn't have to hit enter to get back 
to REBOL. You only have to hit enter to see the prompt. The extra 
>> above the dir outpt is the result prompt that you aren't seeing 
below. This is because CALL on Windows returns immediately, rather 
than waiting for the called process to finish its work, including 
its console output.

Keep in mind that this behavior may change in the future: CALL is 
in the host code.

how do I trap the console output into the variable for e.g.? something 
like str: call "cmd /c dir" does not make it ...

call/output "cmd /c dir" my-var

I think

there is no refinement with R3 call :-)

Call is pretty unusable with R3. I have to say, that some ppl could 
already move to R3, but we have few showstoppers:

- call - really bad situation ....
- missing networking protocol 
- missing CGI mode

- DB access ... now we can proceed with extensions for SQLite, but 
not sure. If call would work at least, we could at least call sqlite.exe 
;-)


Unless those issues are fixed, R3 will be in alpha stage, and my 
opinion is - absolutly unnecessarily ...

echo? who want to work with file? Theat is weird. I want call being 
fixed, or it is good for nothing ...

I thought you wanted debug output. Otherwise wait until CALL is fixed.

anyway Pekr, just use:

call "cmd dir > somefile.txt"

then you can just read the file back into a string.

Paul - I know that is an option ... but what is it good then to get 
'call output into console, if it can't be even easily captured into 
a string?

dunno. As an interim solution, you suggestion is good enough .... 
I'll wait for 'call being fixed/enhanced ...

Yeah, we will have to wait and see if they develop 'call further.

CALL is in the host code. We'll fix it when the host code is released.

I have heard at least one other opinion, that name "command" might 
be too worthy to waste on simple and signle thing as wrapping merely 
a funciton call. Of course even Devices have commands, but those 
are not probably rebol level related and influence nothing ...

and to just describe meaning of wrapping a call, I though external!, 
extern!, ext!, wrap! could be used instead. Probably too late to 
try to convince anyone :-)

In general, if I were a sysadmin, I would not load any functions 
in %rebol.r - I would just put a call to SECURE in there, to limit 
access to my resources. This would help me lock down my user's scripts. 
I wouldn't use %rebol.r at all for user's personal computers, just 
for public-use computers.

BrianH: thinking about submitting 'Call function for fixes. I gave 
it some thoughts, and I think I am not satisfied with answer, that 
'call will be part of Open Host code - we are waiting for host code 
for 2 years, and there is no guarantee, that we will see it anytime 
soon. I think call should be fixed, or it is big let-down in comparison 
to R2. It messes with console in such a way, that it looks inconsistent, 
and its output can't be trapped easily. It might be a show-stopper 
for some ppl, in regards to R3 deployment. What do you think? Maybe 
it can be improved a bit? We are seening good changes to many natives, 
so why to wait with call for host code release?

Not just for the os shell which has launched rebol, but rebol scripts 
that do other rebol scripts - the DO could be considered like a function 
call, and the DO'ed script could RETURN just as if it was a function.

The attractiveness of the idea is that there is just one function 
(return) to learn which handles the same concept (returning) in different 
contexts.

What do you mean by completness? IMO R3 is more advanced than R2 
already, and we are nearing beta stage =  system architecture is 
in-there, all slots in the right place. Now we need to finish few 
things, for user to be usable as R2 is:


- better console (not necessarily needed, but Windows one is total 
crap and makes experience 40% worse for me)
- fixed call
- network protocols (ftp, pop, smtp, proxy )
- ported DB drivers (done by community hopefully)

- improved parse (needed probably if we want to have DB drivers and 
network drivers done new way, but not necessarily)
- missing CGI mode
- GUI far from beta

Well, to my mind, the GUI is written with Rebol code (it can be exported 
in a module). The graphic engine (GOBs, draw dialect) will stay in 
the core.
It depends of what you call the GUI.

REBOL "The language" is IMHO the best on the surface of Earth, but 
the platform (the actual executable, the desktop, view, IOS, et all) 
all show signs of tearing at the seams when you really want to "DO 
REAL WORK". 


You can get by, but its often painfull, or result to dubious work-arounds. 
  I have a lot of experience in big REBOL apps, so its not just word 
of mouth... I'm one of the few who has been succesffull at PITL work 
in R2 (hobby and commercial) for years.  But not everyone likes to 
say that problem-solving the platform itself is part of the work. 
 Most people want to work, they don't have time to try and fix view, 
or some tcp scheme, or charging their clients 30 hours to find a 
way to make 'CALL  work properly (or implement a MS COMLIB hack).

Maxim, the reason that custom datatypes can't extend the syntax is 
technical, not a control issue. When TRANSCODE/on-error was proposed, 
Carl revealed that TRANSCODE can't call out to external code on syntax 
exceptions without making it drastically slower, too slow for use. 
This is why the /error option was implemented instead: it doesn't 
use hooks or callbacks.


We do have custom datatype hooks for the serialized syntax constructors, 
but those are passed the preparsed REBOL data inside the #[ ]. Custom 
syntax hooks for ordinary literals would require a complete redesign 
of the parser, and that redesigned parser would be much worse, in 
terms of resource usage (speed, memory).

It was the compromise Carl came up with - my idea was the /on-error 
option, but that was rejected because it required TRANSCODE to call 
back into a provided function, something Carl said was infeasible.

Submitted my CALL complaints to CureCode. Let's see what Carl thinks 
about it ;-)

Geomol, the main problem with sharing is doing it in a manageable 
way. The advantage of using explicitly shared contexts is that you 
can know where your values are and distingish them from non-shared 
values.


Your idea about a different word type for shared values won't work 
because words don't actually contain anything. All values are stored 
in contexts, blocks or type-specific containers. All values "assigned 
to words" are contained in contexts, no exceptions. Even function 
words are associated with contexts. The question is which one.

R3 has two context types already:

- object!: Similar to system/words in R2, though for some internal 
instances (like error!) expansion is blocked. Direct reference.

- function!: Not expandable, stack-relative reference. Task and recursion 
safe.


Closures have object-style contexts, with a new instance created 
with every call (with bind/copy overhead on the code block, sort-of).

hmm, protect/hide - where do I call it from? At what stage? What 
about having header options - exports, imports, protects? :-)

BrianH: it is not about wasting. I just want we don't do fatal mistake 
- pretending we order users how they should use R3. R3 would be already 
used by many ppl, but is not, due of following reasons:

- missing network protocols, proxy
- call incompletness in comparison to R2
- weird console
- missing CGI mode
- missing DB protocols


No matter how your module system is usefull, if we don't provide 
users with R2 level completness, we are doing fatal mistake ...

pekr, once you see what can be done with a 3D engine you won't call 
it crap... believe me.  Apple's GUI is based on a 3D engine, which 
I believe is based on OpenGL... can't remember precisely.  same thing 
for vista's aero which is based on DirectX which also uses 3D.

Max - unless my GUI looks precisely the same on all systems, I don't 
want to use it, easy as that. So - give a call to gfx card and driver 
makers, and try to standardise that :-)

call "rm *"

Linux can swap, no? If I would be about to judge R3 console quality 
upon Windows, then well ... don't let user to use 'call, this is 
totally messy  ....

The question is, if it should create sandbox for each user, I mean 
letting user to download something, save something, call something, 
parse it, etc. Or do you want to limit console to prevent file operations 
for e.g.?

do join "call " "init 0"

Graham, I think this can be intercepted with LOAD. Perhaps you can 
redefine CALL to become harmless, or simply return a restriction 
error.

this will limit access to external stuff... doesn't call have its 
own secure option?

'call has its own security setting IIRC ...

hmm.. tried this briefly in win32:

>> call "dir"

** Access error: external process failed: "The system cannot find 
the file speci
fied.^M^/"
** Where: call
** Near: call "dir"

What's call's environment?