option(formatted as a code block).Options because it is actual field name. (I also feel options is another choice for language without capitalizing, like Japanese and Chinese...isn't it more accurate?)vb redProbe redBlockVB(42, "hello") ' Creates the [42 "hello" hi] block
hi come from?. - if confirmed, I am happy to provide a full list of functions (Rebol Red and Red/System alike) that have a docstring NOT ending in a full stop. This is a by-product of some internal technical documentation work I have been doing.help took care of it and added full stop when it's missing?help function should handle both cases>> fn: func ["no dot"][]
== func ["no dot"][]
>> fd: func ["dot."][]
== func ["dot."][]
>> help fn
USAGE:
FN
DESCRIPTION:
no dot.
FN is a function! value.
>> help fd
USAGE:
FD
DESCRIPTION:
dot.
FD is a function! value.。 instead of ..help is not (yet).Help was updated for this, but localization was clearly not considered. Thanks for bringing that up @AT-Aoi. alg-digest-size function runtime/crypto.reds "Return the size of a digest result for a given algorithm." alg-from-symbol function runtime/crypto.reds "Return the algorithm ID for a given symbol." also function environment/functions.red "Returns the first value, but also evaluates the second." arctangent2 native environment/natives.red "Returns the angle of the point y/x in radians, when measured counterclockwise from a circle's x axis (where 0x0 represents the center of the circle). The return value is between -pi and +pi." arg-info function environment/console/help.red "Returns name, type, and doc-string for the given word in the spec." collect-exports function system/formats/ELF.r "Collect a list of exported objects: symbol, type, offset and size. As the object size is not yet stored in the symbol or exports table, we have to compute it here." CRC32 function runtime/crypto.reds "Calculate the CRC32b value for the input data." doc-string function environment/console/help.red "Returns the doc string for a function." form-struct function system/utils/virtual-struct.r "Serialize a virtual struct! and returns a binary! value." func-spec-words function environment/console/help.red "Returns all words from a function spec." help function environment/console/help.red "Displays information about functions, values, objects, and datatypes." help-string function environment/console/help.red "Returns information about functions, values, objects, and datatypes." known-method? function runtime/crypto.reds "Return true if the given symbol is supported." layout-binary function system/formats/ELF.r "Given a file structure and file layout commands, generate a full file "layout". A file layout collects the type, offset, address, size, metadata and data for each element in the file's structure." make-struct function system/utils/virtual-struct.r "Returns a new virtual struct! value built from a spec block." OS-call function runtime/call.reds "Executes a DOS command to run another process." OS-call function runtime/call.reds "Executes a shell command, IO redirections to buffers." parse-func-spec function environment/console/help.red "Parses a function spec and returns an object model of it." rejoin function environment/functions.red "Reduces and joins a block of values." show-function-help function environment/console/help.red "Displays help information about a function." show-object-help function environment/console/help.red "Displays help information about an object." struct? function system/utils/virtual-struct.r "Returns TRUE if the argument is a virtual struct!."
help implementation, and the checksum stuff, because I'm more used to using it. Not *all* mine though.consecutive expresses the physical placement of the tables in the Redbin payload. If the word is incorrect in English, we can replace it with a better one.A context contains two consecutive tables by A context structure in Redbin contains two consecutive tablesconsecutive hurts anything, unless it implies "contiguous in memory" and that doesn't hold true due to padding.construct doesn't have any embeded doc, why?>> help construct
USAGE:
CONSTRUCT block
DESCRIPTION:
CONSTRUCT is a native! value.
ARGUMENTS:
block [block!]
REFINEMENTS:
/with =>
object [object!]
/only =>Object is also missing a doc string. Good catch @DideC. I'll add something for those real quick.to/thru/ahead may need some more details, to clarify why we have each of them, but that's also a very important section to have.m n rules, and opt any some, since they are all related. There is also overlap, so up to you how explanations match best with the rest of the parse docs.arc part : 2 times <radius-x>.a: {my
{ string}} to execute the code. Maybe I miss something...Mindmap on Red and related topics; maintained by Sabu Francis is dead.red/red/system room.what on console. ? what says what " Lists all functions, or search for values". rejoin is a builtin that..." be understandable for all?func, has, function etc. func, has and function are words, for a start ;) I saw "commands" only in Draw dialect documentation, and they make sense in such context. Draw is a *declarative* DSL, and "command" implies that user *declare* something.any-function... rotate is a predefined word that ..." . Sounds good.query on file! values is already implemented, and that it yields the data and (UTC) time of last modification?simple-io so that is perhaps enough reason. Let's wait for 0.7 then to come out with it.about/debug. Can't recall.Deep Dives page in the Wiki.tag!s are like ">tag<" instead "<tag>" there?pick - the help info is:>> help pick
USAGE:
PICK series index
DESCRIPTION:
Returns the series value at a given index.
PICK is an action! value.
ARGUMENTS:
series [series! bitset! pair! tuple! date! time!]
index [scalar! any-string! any-word! block! logic! time!]
RETURNS:
[any-type!]index:integer! and logic! for all types of the first argument, additionally pair! for image! and char! and string! for bitset!index types come from? Besides, time! is already included inscalar! so it would not have been needed separately.arcsin, arccos and arctan but these are now actually named asin, acos and atan.arcsin, arccos and arctan, but arcsine, arccosine and arctangent.arcsin that was indeed removed from the language?toc markers at the end of every section in some datatype documentation pages, namely map!, char! and date!.apt-get install libc6-i386 libcurl3 lib32ncurses5
angle parameter of arc asangle indicates rotation of the arc's underlying ellipse by degrees.elliptical arc curve:angle represents a rotation (in degrees) of the ellipse relative to the x-axisx-axis-rotation, [...] indicates how the ellipse as a whole is rotated relative to the current coordinate systemcircle to ellipse. arc would benefit from circle->ellipse change. But "angle" as it appears there --angle in shape's arcis altogether different thing. Initially I tried to follow current wording and was confused - why to specify angle between starting point and ending point when both of these are already given and angle between these can be calculated but not changed with additional parameter. Only after some experimenting I saw that the angle parameter has nothing to do with angle between starting and ending points but only with rotation of ellipse underlying the arc. Later checked with svg specs and got confirmed. Try it out on [arcodrome](https://gist.github.com/toomasv/01817e797fdb38d277d4c01dad89b326). :<)Velodrome, that combines an elliptical track and your other bicycle model (IIRC, @toomasv ).git log or a git gui to view the changes. I was just curious if it can be done through github?do is the same as do load . In this case load scans string input and produces a block of Red values, i.e. does the conversion. do itself returns the last result from expression.path! datatype description where it has been taken from the specs doc section 5.2.13. Its use is in explaining the evaluation of a path value.any-path!.@Greg T took this over in the Gitbook. I leave it up to the docs team to finally determine whether such formal ways of saying things are appropriate for the Reference document...path=: [path-head= some path-selector=] path-head=: word! path-selector=: [integer! | word! | get-word! | paren!]
>> towns/ukiah/web
== http://www.ukiah.com
>> towns/-/web
*** Script Error: path towns/-/web is not valid for none! type
*** Where: catch
*** Stack:
>> towns/ukiah/foo
== none
>> towns/ukiah: none
== none
>> towns/ukiah/web
*** Script Error: path towns/ukiah/web is not valid for none! type
*** Where: catch
*** Stack:
>> towns
== [
Hopland [
phone #555-1234
web http://www.hopland.ca.gov
]
Ukiah none
]>> towns/ukiah
== [
phone #555-4321
web http://www.ukiah.com
email info@ukiah.com
]>> towns/ukiah/- == none >> towns/-/web *** Script Error: path towns/-/web is not valid for none! type *** Where: catch *** Stack:
select?select select towns '- 'web, so you can easily view a path in reverse as a bunch of select/pickcalls.none, the buck stops there.head for a series.path=: [word! some path-selector=] path-selector=: [#"/" [integer! | word! | get-word! | paren!]]
parse (I would like to use parse outside the spec, but understand the spec is for implementors coming from outside).<path-literal> ::= <word-literal>/<selector>+ <selector> ::= <integer> | <word-literal> | :<word-literal> | <paren>
/ be part of the selector production rule?// wouldn't work | /<word-literal> ; refinement!
| #<word-literal> ; issue!< and > may appear in words, <> can only form stand-alone word; neither can <...> be part of any word. Datove typy or Datovetypy would work.symbol! datatype?all-word! typeset, I very much welcome such conceptual unification. :+1:issue! nor refinement! have. would be good choice. It would be somewhat similar to how series implementation type is reflected by series! typeset.all-word! to be renamed symbolic!... :laughing:# character on first line is not visible)Symbol!, AFAIK is an implementation detail and, as @meijeru said, not part of the language proper. Whether we can safely leverage that term without confusion I don't know. It would be nice, as it's a strong word. symbol terminology in a couple word-related rules. As we know, those two types simply don't enforce the same limitation on the starting chars. That is when lexing, not post-processed to identify types. begin-symbol-rule vs symbol-rule. a: 1 o: make object! [a: 2] f: func[][a: 3]
a is used in three contexts in the code above, it is bound to a different value in each context.>>
>> a: 1
== 1
>> o: make object! [a: 2]
== make object! [
a: 2
]
>> get in system/words 'a
== 1
>> get in o 'a
== 2bind, and the recurring question of "words *refer to* values, values are not *assigned to* words.">> o: make object! [a: 1]
== make object! [
a: 1
]
>> oo: make object! [a: 2]
== make object! [
a: 2
]
>> w: bind 'a o get w
== 1
>> w: bind 'a oo get w
== 2o context and then to the word a in the oo context.>> a: 1
== 1
>> o: make object! [a: 2]
== make object! [
a: 2
]
>> oo: make object! [a: 3]
== make object! [
a: 3
]
>> w: bind 'a o
== a <-- w is bound to a in o
>> get w
== 2 < a in o is bound to 2
>> w: bind 'a oo
== a <-- w is now bound to a in oo
>> w
== a
>> get w
== 3 <-- a in oo is bound to 3w didn't come across as intended, so I'll resort to the age-old example.>> a: 1
== 1
>> o: make object! [a: 2]
== make object! [
a: 2
]
>> oo: make object! [a: 3]
== make object! [
a: 3
]
>> blk: reduce ['a bind 'a o bind 'a oo]
== [a a a]
>> print blk
1 2 3bind in context? set> ooo: make object! [b: 1]
== make object! [
b: 1
]
>> a: bind 'a ooo
== a
>> context? 'a
== make object! [ <-- still global context
datatype!: datatype!
unset!: unset!
none!: none!
logibind does exactly what it says, it binds a word or list of words to the in the specified context.>> settings: [start + duration] == [start + duration] >> schedule: function [start] [duration] [ ;-- start & duration are defined in the schedule ;-- function context [ duration: 1:00 [ do bind settings 'start ;-- binds `start to `start in the function context ;-- + does not exist in the function context so ;-- remains bound to its value in system/words ;--binds' duration to duration [ ] >> schedule 10:30 == 11:30
a in context [a: 1] is not bound to a word, it is only "bound" to the context. However, it is true that words *contain a reference to* a context. This is what we call the binding. We have also said that words "carry a reference to" their context at times, which is a nice, less technical explanation.red-word!: alias struct! [ header [integer!] ;-- cell header ctx [node!] ;-- context reference symbol [integer!] ;-- index in symbol table index [integer!] ;-- index in context ]
red-context!: alias struct! [ header [integer!] ;-- cell header symbols [node!] ;-- array of symbols ID values [node!] ;-- block of values (do not move this field!) self [node!] ;-- indirect auto-reference (optimization) ]
'owned which is defined in %series.reds and inherited by block! paren! any-path!. @dockimbel has agreed to have it inherited by other types (see #1957 and comments to commit [6f06015](https://github.com/red/red/commit/6f0601549eae8217e060d321d7ac6a606d4e399c)). My question now is: what does it represent?? Inspection of %ownership.reds does not enlighten me enough :frowning: .modify action... in theory.on-deep-change*.to-logic yields true for any argument value except **false or** none. is written as _two or more_ characters containing one @ but not beginning with it.>> type? @ == email!
false being "falsey" at all.string! <-> red-string! etc.). Where do you get your 1st, 2nd etc. argument from? Where do you leave your result?red-*! structs as routine's function's arguments. Allocating memory is done by R/S code generated by compiler, and deallocating memory used for params does not need to be done by person who writes the routine.red-*! struct. But here I think that memory for a returned value should be allocated inside routine. Most probably it will be deallocated on routine's exit by code generated by compiler. This is done by stack/unwind function, I think.Red [] next-char: routine [ c [char!] return: [char!] ] [ c/value: c/value + 1 return c ] print #"a" ; a print next-char #"a" ; b
.adoc for the specs document on one particular point: within backticks \, the # sign sometimes disappears, and has to be superquoted with a \`red>> dehex "%41BC" == "ABC" ; 41 is hex for B it should state: ; 41 is hex for A
read https://source.unsplash.com/random/310x200 but request timeouts, from browser or curl it works but it takes more then 1s to get a response, is it possible to increase timeout for a request in RED?until [attempt [read ...]], but watch for infinite loop./binary refinement - read/binary https://source.unsplash.com/random/310x200
rebol/red some search engines can understand site: red-lang.org or some other site.point! is a datatype introduced to expose specific info (a slot with 32-bit integers) from Parse's internal stack in Parse event functions. It's a WIP, and meant primarily in its future final form for 3D representation (and eventually coordinates if a suitable literal format is found).to integer! is described in the specs section 5.4.5; to binary! is indeed missing -- thx for pointing that out, I will add itred/docs/conversion-matrix.xlsx made by dockimbel; that is not maintained by me, so if you want that kept up-to-date you should make an issue in the red/docs repository binary! conversion is covered in 5.4.10.any-type! or else a _single_ type name that is either integer! float! or logic!, or one that has a Red/System struct! alias defined that describes a value slot of that type. I had already raised issue #2642 in this connection, but now I have seen a new consequence: a routine that works for both word! and lit-word! arguments, must have any-type! for its argument, and do the type check in R/S in the body; thus the routine spec block has less documentation effect, if you see what I mean.source function is any-word! and any-path but in the body of source the argument is supplied to get/any which only allows word! and path. Thus source can restrict its argument also to these two types. Is this worth an issue? absolute is defined on char! values -- this makes no sense. Note that sign? , positive? and negative? are NOT defined on char! values. Again, worth an issue?reduce accepts any-type! i.e. including unset! and compose accepts only default! i.e. without unset!.to-pair with a single percent value is accepted, but with a block of two values they may not be percent. Is this inconsistency disturbing anyone?absoluteabsolute #2700to pair! 100% it will give 1x1.and, or, xor also works with char!routine! values, or a wiki page where we can note things that are outside the scope of the spec doc?char! here. Technically, zero?, positive?, and sign? can return plausible results. That doesn't mean they're useful. So we're faced with the question, again, of whether allowing/supporting actions that *might* make it easier to deal with some edge cases is preferable to enforcing stronger semantics based on standard type usage. http://doc.red-lang.org/v/v0.6.2/react doc is already out there. May be link to it?504 - Timeout for the link, site is temporary down I think.- used in the official red documentation for view is not the 45th ascii character and would not work when pasted directly.Ctrl+F and ‑ as a search target.U+2011) on all these 20 occasions. block and some are not. ‑. I wonder if the bold markup (*) gets confused if there's a standard hyphen. alert. This I will bring up in the red/gui-branch room.view [
rich-text data [ "Hello" font 24 red " Red " /font blue "World!" ]
rich-text data [i b "Hello" /b font 24 red " Red " /font blue "World!" /i]
rich-text data [i [b ["Hello"] red font 24 [" Red "] blue "World!"]]
rich-text data [i/b/u/red ["Hello" font 32 " Red " /font blue "World!"]]
]