AltME groups: search

On the interest in Orca. As I mentioned before, Orca is included 
in Syllable 0.6.1. In that form, many thousands of copies have been 
distributed already all over the world. We're currently up to about 
4500 downloads of the install CD, so those would presumably be people 
really running the system, 2300 live CDs and an unknown number of 
VMware images, which have been very popular in the past. It's also 
in the shops on the DVD version of Linux Format magazine. I don't 
know how big the DVD part of its circulation is, but it must be many 
thousands

Yes, short form when we need it, kind of a standard shortened name 
convention.

(I've reduced the use-case to its minimal form)

Seems that there's a shorter form that has the same issue: "[<][>]""[<][>]"

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).

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.

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.

Graham, have a look at http://www.rebol.org/view-script.r?script=form-date.r

As for SORT, that's an interesting problem. LESSER? and GREATER? 
are supposed to be constrained to datatypes that are comparable, 
and that have some form of magnitude or ordering. For datatypes that 
don't really have magnitude or ordering they don't really work. When 
it comes down to it, true is not greater than false inherently (considering 
it to be so is more of a moral stand). And none is not greater or 
less than 'a, they just aren't comparable concepts.


SORT doesn't have that luxury though, because it is designed to not 
fail (or rather, not trigger errors because a comparison fails). 
So it has to define some extra comparisons that don't really make 
any sense, as a fallback in the cases where there is no comparison 
that does make sense. The datatype ordering trick is one of those, 
where they are ordered by their inner datatype number, and different 
data that isn't otherwise comparable is ordered by its datatype number 
too (words are greater than unset but less than none, for instance). 
R3 has a list of those datatypes in order in system/catalog/datatypes, 
but if there's a similar list in R2 I don't know where it is - Henrik's 
above is a subset, just the datatypes with externally referenced 
values. R2's and R3's datatypes are in a different order.


SORT/compare is supposed to allow you to provide your own ordering 
function if the standard ordering doesn't make sense. However, if 
you want to support all of the comparisons that the built-in ordering 
supports, you have to make a really complex comparator function with 
a lot of special cases, and in the case of R2 replicate a lot of 
internal data; that function would be pretty slow too. This is why 
SORT/compare is more often used for more restricted cases, like reversing 
the order, or comparing based on object keys.

but we use FORM for that, don't we?

the only place that I find use for MOLD is when wanting to preseve 
brackets when displaying a block. otherwise I use FORM or MOLD/ALL

That's not how I originally understood it, when I first read about 
them. Displaying values was the intent with FORM as it does not necessarily 
produce REBOL readable output, but human readable output. MOLD was 
meant to be used for serialization, so that the data could be re-read 
by REBOL.

Indeed, the help strings:

FORM: Converts a value to a string.
MOLD: Converts a value to a REBOL-readable string.

>> print ["==" mold "a^^b"]
== "a^^b"
>> print ["==" form "a^^b"]
== a^b

So, it is clear, that MOLD is used, not FORM

I'll rephrase:


What I have a problem with, is that there are apparently degrees 
of serialization:


One that we call MOLD, but doesn't really work on all REBOL data. 
I very rarely use this alone.

One that we call MOLD/ALL, and works on nearly all REBOL data. I 
use this very often.


Then we have FORM, which should work on human readable output. The 
problem with FORM is that it isn't flexible enough. For example it 
should have been capable of reformatting numbers, such as 2E-3 to 
".002". It doesn't do that.

Nevertheless, there is reason to have good native support for any 
numeric format, correct? You and I know that our NLPP app suffers 
performance wise over this, having to use FORM-DECIMAL. Don't you 
think that FORM is a good candidate for assigning it to be only for 
human readable output?

Then, does it not make sense to have configuration for this, which 
FORM would use?

I thought several times to implement FORM-DECIMAL in C and support 
the different country styles. Should be queried from the OS. And 
yes, all Rebol functions should be aware of this.

you can redefine the word FORM as you wish, no ?

Steeve, btw, R3:

>> form .00000000000000000000000000000000000000000000002
== "2.0e-47"

What I usually use to differentiate these is that there are literal 
values which do not have to be interpreted (only parsed), and logical 
values which have no real meaning without this interpretation.

Serialization

 in the REBOL sense, hence the quotes,  is used to give the second 
 form of data a way to be described in the first, *where its possible* 
  which it isn't at all in the case of some types (native,etc) and 
 only partially in others (objects!, functions!, etc.)   


even with these distinctions there is still a sizeable amount of 
REBOL *data* (interpreter values, not human visible source code) 
which cannot be serialized (in the real sense) in any way because 
either:  

-the notation has simply not been defined for it (cyclic series/objects, 
which is serializable in other languages)

-it implicitely depends on its interpretation (a VID dialect block 
(you cannot save the vid from the faces)), custom types (in the future))

so the way I see it is that: 
-MOLD is the counterpart to DO
-MOLD/ALL is the counterpart to LOAD.

which leads to saying that:

only MOLD/DO can effectively represent all data,  (with the caveat 
that it is extremely insecure)

only MOLD/ALL can effectively represent literal data without interpretation 
(with the caveat that it is not complete)

BOTH , are highly complex to use effectively in non-trivial cases. 
  


IMHO, if it's notation where completed, the second form could actually 
be built to represent all data, since it could be built to include 
binding hints, series reference graphing and more.  It doesn't have 
to be pretty, it just has to be symmetric.

The only problem right now, is that the serialized form of the language 
is just not complete. all the edge cases I can think of have a way 
of being resolved, especially in R3.

having cyclic references be checked and used on object/block types 
would already go a very long way.


#[block  1  [ val1 val2 ...]] ; serialized block with uid as first 
parm (only needed when it is shared in the string being loaded).
#[block  2  [ val3  #[block 1]  val4]  ; shared block
#[block  3  [ #block 3 ]]   ; self-reference


effectively shows a simple way to solve the cyclic series/object 
problem.

The only problem right now, is that the serialized form of the language 
is just not complete.

 - I would say, that "the Load dialect is not complete relative to 
 the Do dialect", being unable to express some values of the Do dialect.


Nevertheless, the question arises, whether the relative completeness 
is necessary. For example, you demonstrated how cyclic blocks could 
eventually be handled, but, I am not sure you do suggest your solution 
to be used, or just demonstrate the possibility.

How would other than you know?
 - exactly as I did, form the public expressions

The FORM can be implicit if the argument is not string.

For some types of data (not embedded objects)
    to-block form [ .... ]

Yet an alternative:

>> load form [[1][2][3]]
== [1 2 3]

Why shouldn't decimals work?

>> b: load form [[1.5] [2.5]]
== [1.5 2.5]
>> type? b/1
== decimal!

another example, which does not work:

type? load form [1] ; == integer! (i.e. not block!)

I suggested the same approach, geomol. I added a caveat that it works 
for some datatypes, not others. It is particularly bad for objects:
    load form reduce [make object! [a: 1]]
So, a useful approach if we are mindful of its limitations.

type? load form [1] ; == integer! (i.e. not block!)


Yeah, that's a pity, I think. I would prefer LOAD to always return 
a block, so the result from LOAD could always be sent to e.g. PARSE. 
I guess, it's made this way to kinda let LOAD and SAVE reflect each 
other. But that doesn't quite make sense, as we can't save to a string. 
And LOAD can load an empty file giving an empty block, while we can't 
save an empty file with SAVE, afaik.

Regarding decimals in blocks, are you saying, that if I have a block 
with a decimal, then the decimal can be different after going through 
a LOAD FORM combo?

If a decimal changes by a LOAD FORM combo, isn't that a bug?
(I haven't found an example yet, that does what you claim.)

If a decimal changes by a LOAD FORM combo, isn't that a bug?
 - it was intended

what is the fastest way to find the number of digits in a number, 
if you want to use it to calculate the pixel width of the number 
for a table column? simply using:

length? form number

?

but that's slightly slower than yours, it seems
 - strange, here it looks much faster than length? form

>> number: 1234                                       
== 1234
>> time [loop 1000000 [1 + to integer! log-10 number]]
== 0:00:00.293239
>> time [loop 1000000 [length? form number]]          
== 0:00:00.28022

On R2 version 2.7.7.2.5

I just tried:

do to-rebol-file "L:\some\path\here\test.r"


and everything went OK, Win Vista here. Console is being launched 
form the shortcut on start bar, pointing to renamed to rebol.exe

That's incredible Maxim. Good work. With what you do with parse, 
is the knowledge available online  in tthe form of the present parse 
documentation, or did you have to discover new techniques? I have 
to admit I just barely use it when I need to. Anyway, thanks for 
sharing your experience. I

You can use FORM as well.

And having alternatives should not be something to complain about. 
:)

I'm a little worried about the (literal form accessible) part of 
your pluggable module type (UDT) feature. Languages with user-extensible 
syntax are almost impossible to debug.

So, I finally chose to use the & character (already used in C and 
other languages to mean "address of") with a datatype description 
for pointer! literal form.

Regarding hex form of integer. What if someone write:

ah: 42
foo: ah

Should foo be 42 or 10 (= ah hex)?
Maybe hex integers should require prefix zero in this case?

a lot of companies go to universities for some specific problems. 
 they fund a specific project form a team and a professor and team 
has work for 2-3 years.  sometimes it goes through the school, sometimes 
it almost like "renting" the professor for cheap.

I would keep PRIN. And instead of PRIN-INT I would like to see FORM.

The problem with FORM is that it implies a new buffer allocation 
that you need to free at some point.

that just hardcoded freebsd-specifics, so would have broke linux 
in that form. only a quick experiment to see what's really necessary

unless all [
	(
		message: receive socket 0
		as-logic message
	)(

  prin "Received request: "  print as-c-string message-data message
		end-message message
	)(
		;wait 1
		send socket  as [byte-ptr!] reply  1 + length? text  0
	)
][
	print zmq-form-error system-error
]

Btw, your code snippet could be rewritten as:

message: receive socket 0
unless all [
	as-logic message
	end-message message
	;wait 1
	send socket  as [byte-ptr!] reply  1 + length? text  0
][

 prin "Received request: "  print as-c-string message-data message
	print zmq-form-error system-error
]

Hmm, form me the AltME large font swallowed the "refers to Red :)" 
remark.

In PureBasic, there are Print and PrintN functions. PrintN adds new-line 
to the end.
For Print-ws, what about Print-Form ?

I considered PRINT-FORM but I've found it not meaningful enough. 
PRINT-WIDE is a better hint at what the function does.

I've updated my bindings to the new PRINT form and marked them as 
needing the latest Red/System

#include %../SDL.reds


log-error: does [  ; Log current SDL error.
	print [sdl-form-error newline]
]


red:	as-byte FFh
green:	as-byte FFh
blue:	as-byte FFh

screen:		as sdl-surface! 0

event:			declare sdl-event!
mouse-event:	declare sdl-mouse-motion-event!

either sdl-begin sdl-init-all [
	screen: sdl-set-video-mode 640 480 32  sdl-software-surface

	either as-logic screen [
	while [all [
		sdl-await-event event
		event/type <> as-byte sdl-quit
	]][
		if event/type = as-byte sdl-mouse-moved [
			mouse-event: as sdl-mouse-motion-event! event

			if as-logic (as-integer mouse-event/pressed?) and FFh [

    unless plot screen  mouse-event/x-y and FFFFh  mouse-event/x-y >>> 
    16  red green blue [
					log-error
				]
			]
		]
	]
	][
		log-error
	]

	sdl-end
][
	log-error
]

I think that extending the RTTI system to distinguish different type 
of structs (or at least aliased structs) should be doable without 
that. Aliases are already a form of user-defined type.

There is hardly any talk of SSL, but of the separate authentication 
methods that it comprises. Indeed, SSH implies what is called SSL, 
so it's in there in some form

I think, it's a good initiative, but I can't judge, if it's a good 
idea, because I know too little about the different variants. How 
similar/different is Red, Topaz, Boron and World, and how are they 
compared to REBOL? Would the docs help a developer, or would they 
cause more confusion? It probably depends on the form of the docs 
too. Examples would help.


I plan to write a manual for World, something similar to "The C Programming 
Language" book. And that's not a dictionary, so there is good room 
for docs by others without overlap. And also docs, which are not 
just a dictionary, like extensive examples with explanations and 
probably other kinds.

http://www.english-test.net/forum/ftopic25371.html


And then in Microsoft Manual of Style (version 3.0) we can read "To 
form the plural of an acronym, use a lowercase "s" without an apostrophe." 
Example: several IFSs.

The reason for using the Boost License for the runtime was clause 
two: "Redistributions in binary form must reproduce the above copyright 
notice, ..." .

A Red/System-produced binary linked with the Red/System runtime arguably 
is a redistribution of the Red/System runtime in binary form.

In short "yes". C-String in Red/System is simply a null terminated 
list of bytes. As I understand, strings in Red will support unicode 
but Nenad hasn't decided what form they will take yet.

but in REBOL, it is a short for REDUCE-FORM.

I'm aware that the current theme is not always very readable, if 
someone with good design and CSS skills wants to tweak it, I'll see 
if I can give you access to the admin form.

Kaj: I have enabled underflow and overflow exceptions in x87 by default 
for Red/System. This will help us write more reliable code. We'll 
be able to optionally disable all FPU exceptions once we get support 
for INF and NaN. So the init code for C lib is now:

#if target = 'IA-32 [
	system/fpu/mask/underflow: on
	system/fpu/mask/overflow: on
	system/fpu/mask/zero-divide: on
	system/fpu/mask/invalid-op:  on
	system/fpu/update
]

or in shorter, but less readable form:

#if target = 'IA-32 [
	system/fpu/control-word:  033Fh 
	system/fpu/update
]

henrik, do you mean something like? :

topaz: func [ block ][

 load read/custom http://server/try-topaz.htmlreduce ['POST  mold 
 block]
]


(where the post data above is replaced by whatever is required to 
properly fill in the form)

The nice thing about the book I bought is that I can report errata 
directly from the pdf ... click on errata and it takes me to a web 
form

I guess you need form for feature requests as well :) For example 
the routine! part is not good enough, R2 version is better at this 
moment.

- Reimplemented bitset! as binary
- Added native function: COMPLEMENT
- Added native function: ROTATE
- Added native function: SHIFT
- Added << and >> operators to cortex.w
- Added hex form for characters, ^(00) - ^(FF)
- Added REFORM to rebol.w
- Added DETAB to rebol.w
- Added ENTAB to rebol.w
- New test
- Bugfixes

http://issue.cc/r3/1477- Special-case / words not recognized in 
lit-word!,  get-word! or set-word! form

http://issue.cc/r3/1478- Special-case arrow-based words not recognized 
in set-word! or refinement! form

Those seem to be the last two unimplemented syntax fixes in R3, at 
least that I can find/remember.

I still think there is a problem with that form [aaa/]

It will be checked like 2 separate valid words although it's an invalid 
path

Introducing email! datatype next.

form: '?[*-:-*'] 
':' may be in the first position only
'<' can't be in the first position
'%FF' escaping chars in hexa notation

you can use 2 forms for file! :
in R2
- %"*"  quoted sting file, with ^ escape notation allowed
- %*  Form  with %ff escape notation allowed  
in R3
- quoted string file works fine

- in the %* form, the % escape notation works fine but the ^ char 
mess up  things in some cases without issuing an error

In the %* form, R3 should recognise the ^ char as a normal char (not 
one escaping notation) as R2 does.