I am experimenting into creating commands that can be run either locally or remotely:
A command could be run as
command/ref arg1 arg2 refarg1
but if you write
server: HTTP://192.168.0.22
command/ref/remote arg1 arg2 refarg1 serverThen command creates a block with its name and parameter, and executes it remotely. Then it receives the result from the remote server.
Using a refinement to make it remote seems to be the complicating factor. As far as you're concerned, a call is complete (command/ref arg1 arg2 refarg1), correct? So you can store that internally as a block, and make the remote part separate if it's used.
my-call: [command/ref arg1 arg2 refarg1]
do my-call ; local
RPC reduce [my-call 'on server] ; remote, semi-dialected block for fun.RPC does all the magic and the func is none the wiser.
RPC sends the block to the server who does it, and returns the result.
I don't know about RPC function but I remember having seen it in Cheyenne.
Yes, refinement is the complication factor but I have chosen to have it on purpose. I have already made experiments with:
- blocks
- objects
- Dialected blocks
Mostly I have experimented creating functions whose arguments is a block or an object containing the arg/value pairs and build the internal function context bypassing the function interface, doing everything by hand. It worked well but the experiment goals is to pass regular Redbol commands and bind them to a remote object with contains the "allowed" commands and I want to take into the picture passing refinements too.
This It is the most difficult thing as I have no way to get a make specs with refinents as set words.
RUN-REMOTE. You simply provide a block of code and it Is executed remotely and you receive the return value.As I have said this experiment goal is to have regular functions which run on a remote server just having the
/remote refinement set and passing the server address, so they recreate the command needed to run themselves. This to not change the current usual coding, otherwise everything would become run-remote compose [command/arg (arg1 arg2 arg3 refarg)]
apply syntax. I will try.
/remote server the command just dispatches the request to an execution server`
@greggirwin Another option to transfer the current function context words and refinements and the values, is to use the set syntax. It is perfect for keeping trace of refinements:
ctx: [[a b c /red ref-arg] [a b c false false]]You have just to convert /red to word before executing set
When words-of and values-of will be implemented for function it will be easy to write
ctx: reduce [words-of context? 'ref values-of context? 'ref]Also set words argument could accept refinements, so you can simply write:
set ctx/1 ctx/2
By far my most common case for filenames is date-naming them, which isn't a good match for
compositeand handled better byformat.
It's good until you want to customize it a lot.
It's good until you want to customize it a lot.
I guess I've always customized them a lot, because it's so helpful IMO. e.g. zero padding counts and ISO8601 formatting dates, so lexical sorting works.
`"..."` is so utterly bad for you, let's consider just an empty issue # "...", because #` is completely ugly and using only opening quote makes no sense to me, if it's quotes they should be on both ends. # "..." is somewhat similar to char syntax though. But then any other symbol allowed in issues will be better than backquote. ## #! #$ #% #= #| #/ #\ #. #~
A poll from Nenad ☻
Which way to you guys use try most of the time?
- To silence errors, as in
if error? try [...] [..after-error recovery..] - To catch errors and process them later, as in
set/any 'err try [...] (... later err is processed...) - I never used
try
Please post your answers into thread if possible. Thanks.
18 replies
try/catch isn't a thing. We have throw/catch which is not specifically error related, but is about general non-local flow control.