AltME groups: search

IMHO it should return a syntax error

That must have changed in later version. I tested such things deeply 
1-2 years ago and wrote a document, that I sent to Carl. Back then 
I noticed:

>> 2.2#
** Syntax error: Invalid "integer" -- "2.2#"


, and I suggested, it should be an invalid decimal, not invalid integer. 
Today I get:

>> 2.2#
== #.2#

There are many such situations.

trying to get info on a file via ftp using to long version of teh 
port spec as my user name is an email address:

fport: [
    scheme: 'FTP
    host: "ftp.example.com"
    target: %/file.txt
    user: "bill@ example.com"
    pass: "vbs"
]

I can read it with "read fport"

but I can not get other info from it like:

print modified? fport

Whats the method here?

Sometimes depending on a flag you might want to call a function with 
a refinement or not.

So:

either flag [ test/refinement ][ test ]


Is there a simpler way this could be done without passing a parameter?

how about making a refinement of none always legal??

You could always add a refinement of /none in the function spec.

R2 has a mezzanine APPLY, R3 has a native one.

We use it a lot in R3 for wrapper functions that forward refinements 
to the functions they call. The names can even be different because 
APPLY is positional. It is a little slow in R2 for small numbers 
of refinements when compared to the conditional code, but really 
easy to use, which makes the difference.

>> foo: func [a /b c] [reduce [a b c]]
>> apply :foo [1]
== [1 none none]
>> apply :foo [1 /b 3]
== [1 true 3]

I need a public key encryption method though

RSA is significantly slower than symmetric key encryption algorithms, 
and a single encryption or decryption operation can only process 
an amount of data up to the size of the RSA key. For encrypting or 
decrypting large amounts of data RSA is usually used in combination 
with symmetric key algorithms or secure checksums as follows:

Also, from Wikipedia - AES has a fixed block size of 128 bits whereaas 
Rjindael can have a blocksize in any multiple of 32 between 128 and 
256 bits.

It may well be that REBOL uses a 128-bit block size with Rijndael 
but it isn't clear from the documentation.

If you only need to encrypt data at a single source, you could easily 
call a command line tool such as OpenSSL to perform the encryption 
for you. (It could well be quicker than REBOL too).

Again, this might be a Graham question: I'm still working with that 
video encoder which uses http to communicate. They have a .cgi script 
which downloads the recorded video file from the internal SD card 
to the requester. My problem is the content I receive is somehow 
different than the files which I can download via a browser and of 
course will not play. I still using your http-tools to GET/POST. 
My initial thought was that  data returned is somehow being translated. 
Any thoughts?

if there is a binary switch ... it has to occurr after the port is 
opened.

I am making a simple (I hope) worfkflow prototype and want to use 
REBOL objects which I can SAVE and LOAD.  A workflow object!  to 
have a node-map collection in it of simple nodes of the workflow 
graph.   Source ->A -> B -> SINK where the workflow knows about the 
next node and status. Externally there is UI to support the work 
part ... which is URL data on a given node.   Looks like it fits 
into Cheyenne RSP well - maybe zmq when I get a bit further along. 
  Save a flow in process as a .txt file using SAVE/ALL filename.txt 
work-flow-instance.   But no success with work-flow-instance: LOAD 
filename.txt        Do I have to BIND on LOAD to re-instantiate the 
object?

What do you get when you do a load?

probe load %/c/cheyenne/www/makework/data/wf001.txt
[make object! [
        id: 'wf001
        name: "Add Work"
        node-map: [make object! [
                id: 'SOURCE
                Description: "Add new software for Site"
                status: 'Complete
                Next-Node: 'A
                sub-tasks: "1. Used RFA to enter."
                When-completed: []
                Time: 60
                Notify: none
                status-url: func [] [

                    join http://localhost/makework/status.rsp?id=ID
                ]
                action-url: none
                mark-complete: func [] [
                    Status: 'Complete
                ]
            ] make object! [ ....

The SAVE is a workflow function persist: does [save/all to-file rejoin 
[%data/ id ".txt"] self]

so looks like you have a block containing an object?

is there a good way to use mingw with CALL? I need to call git through 
msysgit, while using ssh keys. From what I can find, this looks almost 
impossible.

OK, this is freaky:

>> system/version
== 2.7.8.2.5
>> a: list-env
== [
    "TERM_PROGRAM" "Apple_Terminal" 
    "TERM" "xterm-color" 
    "SHELL" "/bin/bash" 
    "TMPDIR" "/var/folders/6O/6OnXy9XG...
>> help a
A is a block of value: [
    "TERM_PROGRAM" "Apple_Terminal" 
    "TERM" "xterm-color" 
    "SHELL" "/bin/bash" 

    "TMPDIR" "/var/folders/6O/6OnXy9XGEjiDp3wDqfCJo++++TI/-Tmp-/" 
    "Apple_PubSub_Socket_Render" "/tmp/launch-BrITkG/Render" 
    "TERM_PROGRAM_VERSION" "273.1" 
    "USER" "Ash" 
    "COMMAND_MODE" "legacy" 
    "SSH_AUTH_SOCK" "/tmp/launch-HlnoPI/Listeners" 
    "__CF_USER_TEXT_ENCODING" "0x1F5:0:0" 

    "PATH" {/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11/bin} 
    "PWD" "/Users/Ash" 
    "LANG" "en_AU.UTF-8" 
    "SHLVL" "1" 
    "HOME" "/Users/Ash" 
    "LOGNAME" "Ash" 
    "DISPLAY" "/tmp/launch-U0Gaqw/org.x:0" 
    "_" "/Users/Ash/REBOL/rebol"
]
>> length? a    
== 18
>> select a "USER"
== "Ash"
>> select a "HOME"
== none

Length? a should be 36 given the above code....
Does this list you all the env variable names?:
    foreach [x y] a [print x]

I get the same results on Windows. When I assign a block with the 
same contents to a directly, it all works. It looks like LIST-ENV 
is building a bad block.

No such error in R3, but LIST-ENV returns a map! there, so it wouldn't 
have the same error.

>> map-each e [] [e]
** Throw Error: Return or exit not in function
** Where: map-each
** Near: return any [output make block! 0]


is it a known bug? im new to cure code. i don't even know where to 
look for it. can some one help? (it works in r3)

Onetom, that error has been reported already and fixed in R2/Forward, 
but it hasn't made it into R2 yet. Here is the revised MAP-EACH:

map-each: func [

 "Evaluates a block for each value(s) in a series and returns them 
 as a block."
	[throw catch]

 'word [word! block!] "Word or block of words to set each time (local)"
	data [block!] "The series to traverse"
	body [block!] "Block to evaluate each time"
	/into "Collect into a given series, rather than a new block"

 output [any-block! any-string!] "The series to output to" ; Not image!
	/local init len x
][
	; Shortcut return for empty data
	either empty? data [any [output make block! 0]] [
		; BIND/copy word and body
		word: either block? word [
			if empty? word [throw make error! [script invalid-arg []]]

   copy/deep word  ; /deep because word is rebound before errors checked
		] [reduce [word]]
		word: use word reduce [word]
		body: bind/copy body first word
		; Build init code
		init: none
		parse word [any [word! | x: set-word! (
			unless init [init: make block! 4]
			; Add [x: at data index] to init, and remove from word
			insert insert insert tail init first x [at data] index? x
			remove x
		) :x | x: skip (

   throw make error! reduce ['script 'expect-set [word! set-word!] type? 
   first x]
		)]]
		len: length? word ; Can be zero now (for advanced code tricks)
		; Create the output series if not specified
		unless into [output: make block! divide length? data max 1 len]
		; Process the data (which is not empty at this point)

  until [ ; Note: output: insert/only output needed for list! output
			set word data  do init

   unless unset? set/any 'x do body [output: insert/only output :x]
			tail? data: skip data len
		]
		; Return the output and clean up memory references
		also either into [output] [head output] (
			set [word data body output init x] none
		)
	]
]

There is a similar bug in many of the R3 mezzanine control functions 
(the opposite, actually), but fortunately most of R2's mezzanine 
control functions were converted to native in R3, so the bug doesn't 
affect much.

The revised mezz-series.r (relative to the 2.7.8 SDK source) is in 
R3 chat #8008 - that's the number of the particular version, which 
you can see by going to #41 (R2/Mezzanines) and doing a LF command.

The chat interface uses numbers as a deliberate design choice because 
it is easier to memorize and refer to a number than it is to a path 
or message ID. You can even write a message number in #8008 form 
in another message and it can be followed like a hyperlink to the 
message of that number. You can also do the hyperlink trich to CureCode 
tickets using the bug#539 form, which will take you to http://issue.cc/r3/539
(that R3 bug I mentioned above).

Is there a point in allowing refinements like this?

/1a

I can cook it down to: Why would REBOL allow refinements like:

/1
/1a
/1.2


My guess is, it's a side effect of how the scanner handle paths with 
integers, like: blk/1

So shouldn't refinements have the same rules as words, like the core 
manual suggest?

Ah, now I understand. It's probably a "bug" in scanner.

I'm having problems renaming a file on a USB stick with R2 under 
Windows. It reports "cannot access". R3 does not have this problem. 
Can anyone reproduce this?

Henrik, I have no problem with renaming a file on USB stick...tested 
under WindowsXP SP3

perhaps it's a timing issue?

it does not work for me under Windows either. seems like a port bug.

Cyphre, Robert reported this from a customer, who I assume is running 
Windows natively.

new -- new name (not a path)

rename capabilities in file handling do not normally allow paths 
to be used (in the OS itself).  otherwise these are a called 'move 
file operations. 


e.g. if you try using paths with rename in the DOS shell, you get 
errors.

Sorry, the actual decision was in a different ticket, but the discussion 
was in #743. Sometimes it can be a problem to make multiple tickets 
for the same problem, as opposed to different parts of the same problem; 
it can get a little confusing. Stuff like this is why we rearrange 
tickets more now.

It seems to me to be a sought for explanation of some inconsistency 
in the language. Also from the discussion in that ticket.

Sure, but do you believe, refinements like /1, /1a and /1.2 are made 
on purpose or just a side effect on how it's implemented?

There are a lot of values that can appear in paths that don't translate 
to refinements. Paths and refinements are only related in function 
call syntax; otherwise they are not related.

There were a lot more tickets related to this, which are unfortunately 
difficult to search for because different people use different terminology 
for this problem, so they don't find the previous tickets. What I'm 
summarixing here is the final decision. I don't remember when that 
decision was made, but I remember the reasoning.

We are still making tickets related to word and refinement inconsistencies 
for R3 (or at least I am, when I find bugs in the syntax while I'm 
trying to reverse engineer the syntax docs). While the numeric refinement 
issue is settled, there are other issues that haven't yet been discovered. 
Most of the syntax problems are related to scanner precedence. All 
of the word and path datatypes can be constructed with characters/contents 
that don't really scan the same way in literal syntax, but it is 
not really considered an error. Datatypes are meant primarily for 
in-memory use - their syntax is secondary, and in many cases the 
literal syntax only covers a subset of the possible values.

The original design of REBOL has many many great ideas. It's just 
the implementation, that isn't good enough in many cases. With these 
new explanations, the whole thing just get more complex, which isn't 
good. My view is, that it's better to stick with a simple design 
and work on getting that implemented.

For a scanner (also called lexical analyser), I can recommend studying 
the UNIX command lex. The code produced might be a bit bigger in 
size, but it's fast and produce good result.

One of the tricks when refining the details is to realize that there 
is a real runtime difference between recommending that people not 
do something, and prohibiting something. Every time we prohibit something 
it has runtime overhead to enforce that prohibition. So every recommendation 
needs documenting and explaining, but every prohibition needs justifying. 
There are situational tradeoffs that recommendations can resolve 
easier than prohibitions. This is why we have to be extra careful 
about this.

REBOL has 26 or so datatypes recognized by the scanner. That I would 
call complex lexical rules. Maybe a generated lexer will resolve 
many of the problems?

Actually, that's still considered pretty simple. You still might 
need a DFA for some of the rules, but most of them can be recognized 
by hand-written code more efficiently. The problems are not caused 
by not using a generated lexer - even a generated lexer can have 
precedence errors. The real syntax bugs in R3 are there because noone 
has really gone through and figured out what they are, systematically; 
most of them are still undocumented. Recently, in my spare time, 
I've been trying to go through and document the syntax and ticket 
the bugs, so soon the limit will be developer time. (In R2, the bugs 
are there because the syntax is frozen for backwards compatibility.)

As for the syntax-vs-memory data restrictions, it's another tradeoff. 
Regular REBOL syntax is much more limited than the full data model 
of REBOL, even if you include MOLD/all syntax, because the syntax 
was designed more for readability and writeability by humans. If 
we limit the data model to match the syntax, we limit our capabilities 
drastically. Limiting to the syntactic form only makes sense when 
you are serializing the data for storage or transport; in memory, 
it's unnecessary. A better solution is making a more comprehensive 
serialization format that doesn't have to be human readable - Rebin 
- and then using it when we need to serialize more of the in-memory 
data.

I went through the scanner systematically 2 years ago, produced a 
document, which I sent to Carl. It's here:
http://www.fys.ku.dk/~niclasen/rebol/rebol_scanner.html

Cool, I'll take a look. I've been trying to generate compatible parsers 
in mezzanine PARSE code, which could then be translated to other 
parse models like syntax highlighters for editors when necessary. 
I'm hoping to make a module of rules that can be used by a wide variety 
of syntax analyzers.

if you include schema validation... I'd say XML is a nightmare  :-)

C++ hmm. Is that because you see each of the reserved keywords as 
a different token? I see all them as one.

One of the interesting tradeoff tickets is http://issue.cc/r3/537
- I wrote up the ticket initially and expanded it to include all 
affected characters, but looking at it now I'd have to recommend 
that it be dismissed. If it is accepted it would have the side effect 
that more syntax would be accepted, but all of the newly accepted 
syntax would be hard to read. Accepting that ticket would make R3 
more difficult to read, debug and maintain, so it's a bad tradeoff.

XML and HTML are relatively easy to lex, and require Unicode support, 
so hand-written lexers are probably best. Schema validation is a 
diffferent issue.

In answer to your comments link above:
- Syntax errors are triggered before semantic errors: 1.3, 11

- Words that start with + and - are special because of potential 
ambiguity with numbers: 1.1

- Arrows are only allowed in the special-case arrow words, not generally: 
1.2, 1.3, 4

- %: is ambiguous - it could be a file that wouldn't work on any 
OS, or the set-word form of %, so an error splits the difference: 
10.2
- Fixed already: 2.2 for arrows in R3, 7, 13


Some of the rest are related to http://issue.cc/r3/537and others 
have been reported already. If you want 10.2 to not trigger an error, 
it is more likely to be accepted as a set-word than a file. Thanks 
for these, particularly the lit-word bugs.

Never mind about the 10.2 stuff: For some reason I forgot that % 
wasn't a modulus operator :(

If I in a function have a local variable, v, but I want the value 
of a variable v in the context outside the function, I can write:

get bind 'v bound? 'f


, where f is the name of the function. Is that the way to do it, 
or is there a better way? Full example:

>> v: 1
== 1
>> f: func [/local v] [v: 2 get bind 'v bound? 'f]      
>> f
== 1

Is that the way to do it
 - I guess not, there is a more efficient way

If you know the context you want to use and it is always the same, 
then it is a bit inefficient to call the BIND function, not to mention, 
that

    bind 'v 'f

is more efficient than
 
    bind 'v bound? 'f

It's for the parse function, I'm working on, and I want to be sure, 
I don't get a local var, if vars are used in the parse rules.

if the parse rule is given as a parameter, vars within the rule will 
not be bound to the function.  the binding is static, i.e. it occurs 
only once, when the function is created.  the word in the parse, 
already is bound (or not).

Tonight's Moment of REBOL Zen:

Check this Fibonacci function:

fib: func [
	n [integer!]
	(
		if not local [
			a: 0
			b: 1
		]
		prin [a b ""]
		loop n [
			prin [c: a + b ""]
			a: b
			b: c
		]
		print ""
	)
	/local a [integer!] b [integer!] c
][
	do bind third :fib 'a
]

>> fib 10
0 1 1 2 3 5 8 13 21 34 55 89 
== 89
>> fib/local 10 55 89 none
55 89 144 233 377 610 987 1597 2584 4181 6765 10946 
== 10946


If you only want to execute the paren in the function spec, put this 
in the body instead:

	do bind to block! third second load mold :fib 'a

A more simple example of this weird function construction:


>> hello-world: func [(print "Hello, World!")] [do third :hello-world] 
    
>> hello-world
Hello, World!

Tonight's Moment of REBOL Zen:


The /local refinement in functions is just like any other refinement. 
This again mean, any refinement can be used for local variables, 
like in this example:

exp2: func [
	"2 raised to exponent"
	exponent [number!]
	/il-locale number [number!]
][
	if not il-locale [number: 2]
	number ** exponent
]

>> exp2 3
== 8.0
>> exp2/il-locale 3 3
== 27.0


But HELP will search for the /local refinement, when producing its 
output. But as any word, HELP can just be redefined to serve ones 
needs. HELP is even a function, so its source can be looked at, if 
someone wants to produce ones own HELP function.

>> zen: func [arg [integer!] /local /private base] [add any [base 
0] arg]
>> zen 1
== 1
>> help zen
USAGE:
    ZEN arg

DESCRIPTION:
    (undocumented)
     ZEN is a function value.

ARGUMENTS:
     arg -- (Type: integer)
>> zen/private 1 10
== 11

just remember that in R3, the /local refinement might be given special 
status in a future release. this was mainly to prevent you from supplying 
default values to locals which can be a pretty big security hole 
right now.

That shouldn't be a problem, Max, I don't think too many people abuse 
implementation specific hacks like this one in code other than zen 
examples ... ;-)

Tonight's Moment of REBOL Zen:

>> skip [a b c] to integer! true
== [b c]
>> skip [a b c] true
== [a b c]

Carl uses PICK instead of EITHER a lot. He also marvels that this 
trick isn't used more often, especially since he added logic indexing 
specifically for that purpose :)

Interesting explanation! Gives us even more Zen to think about:

>> pick [a b] true 
== a
>> pick [a b] to integer! true
== a
>> pick [a b] false           
== b
>> pick [a b] to integer! false
== none

well, difference in types is expected, its the point of having dynamic 
typing.  I don't think its a required feature for type casting to 
result in symmetric uses of other functions.    I expect to-from 
one type to another to be as symmetric as possible, but not what 
they mean in another context of usage.

perhaps there should be a three-state PICK instead.

is -> is a

Lit-word arguments are for functions that treat words as keywords 
or part of the syntax, or for interactive command line functions 
that are supposed to act like shell funcs. If you use lit-word arguments, 
you can't easily generate the value passed using an expression, especially 
in R2 - in R3, those expressions can be put in parens, as is emulated 
in the R2 mezzanine backports of R3 functions that take lit-word 
arguments. For instance, if you made GET take a lit-word argument, 
GET IN wouldn't work.

The only exception to the above is ++ and --, which take lit-word 
arguments because their primary use is with a literal word value, 
so taking a lit-word argument gets rid of a ' in the most common 
case. And since ++ and -- started in R3 and has its behavior explicitly 
emulated in R2, you can put word-generating expressions in parens 
for the less common case.

Does it make sense to have a timestamp datatype as distinct from 
a date type

A timestamp more precise than NOW/precise?

No, to date! creates either a date only , or a timestamp at present

it should create a date at 0:00 and GMT

A source for errors ....

The date! type is a datetime type with an optional time portion. 
We can get rid of the time portion already. What do you want that 
we don't have already?

to date! should create a timezone and hour by default

But that doesn't work when you don't want a time and date.

When you requested a timestamp type, I thought you were requesting 
a timestamp type, not a datetime type.

A few SQL implementations call the datetime type "timestamp" for 
some cunfusing reason. It's best to keep the concepts distinct.

at present 'to-date gives you either a date, or a datetime depending 
on the input.  that is inconsistent

A TO-DATETIME function would be great. GMT by default, or local time 
like the rest of REBOL?

For me the issue is that when dealing with dates, I want to get only 
the date, but it it's a date with no time portion, then date/date 
gives you an error.

Better to have a to-datetime function though

Don't see why not. It also is a simpler solution than splitting the 
date! type into date! and datetime!.

and just a refinement to default to local time

Given that R3 might get some restrictions
 on the use of /local (there was a blog about it).

Anyway, I raise this because most web services want times to a fixed 
degree of places.  Not varying by the second

not less readable to a web service though

The default formatter is pretty much for situations where you don't 
need that kind of inflexibility. Most people don't need the whole 
gamut of different formatting options, since only a small percentage 
of them are used in any given situation. It would be useful to have 
a library of date formatting routines that could support all of the 
many standards. If you need to talk to a service that requires a 
particular format, use a particular formatter.