AltME groups: search

It turns out that the length of a tuple is set at tuple creation 
time, and that length affects LENGTH? and PICK, which are called 
by LAST.

The result of all of these discussions is that R3 is going to be 
much more rigorously thought through and consistent than R2. The 
little improvements are going to be the ones with the greatest impact 
in the long run.

It's about finding UTF-8 encoding errors, particularly the overlong 
forms that are used for security breaches. We can't do that check 
in TO-STRING because of the overhead (+50%), but it can still be 
a good idea to check in some cases, and the code is better written 
in C than REBOL.

TO-STRING is the primary decoder of UTF-8 in REBOL.. TO-CHAR is the 
other one, and it complains about invalid UTF because it can.

You mentioned the security, but the trick is that STACK is undocumented 
and you have to poke around and try things out for it to work. To 
my knowledge, I am the only one who has come up with proof-of-concept 
code that uses STACK, but the concepts proven were meant to highlight 
security holes :(

http://www.rebol.com/r3/downloads.html- Win and Linux this time. 
I expect non-Win platforms being Core only too ...

the changes are not yet implemented. the layout system will be changed 
to contain a guide system and multiple layers. if it works, there 
will not be any more trouble with the layout engine.

if it works like a generic keyboard, then you should be able to do 
it in R2 as well. try putting up a view layout [field] and see if 
it works.

It should most definitely be an OS thing. It should work like generic 
keyboard input. There would, though, be two kinds of input: One for 
dictation and one for GUI control. The latter might be harder to 
do in REBOL without some OS friendly extensions.

I think what they should have done here, is lift ordinary keyboard 
commands. You would simply say the key names, along with a few extra 
commands, like "again". This way you don't have to remember an entirely 
separate command set.

This is also a problem in MacOSX, because the command set is very 
limited and nearly useless.

... and slow!


>> do [st: now/precise loop 10000 [object [a: b: c:]] et: now/precise]
== 11-Jul-2009/23:55:57.406+8:00

>> difference et st
== 0:00:04.36


>> do [st: now/precise loop 10000 [make object! [a: #[none] b: #[none] 
c:#[none]
]] et: now/precise]
== 11-Jul-2009/23:56:13.578+8:00

>> difference et st
== 0:00:00.032

I find it a little strange that it is so slow:

>> source object
object: make function! [[
    "Defines a unique object."
    blk [block!] "Object words and values."
][
    make object! append blk none
]]

It is slow because he reuses the same spec block over and over, which 
means that with every loop iteration another #[none] is added to 
the spec block. This means that the spec block has to be expanded 
many times, with reallocation overhead.


The OBJECT function was meant to be used with specs that aren't reused 
- it's a convenience function for high-level objects, which may be 
replaced by a change to MAKE object! to have an implicit none on 
the end of the spec instead of needing to add an actual one.

Ah, Carl is preparing to split user and system context. What will 
that mean? Respectively - what is the purpose of such change, to 
have those isolated? Better modularisation?

It's a global search-and-replace in the source rather than a simple 
assignment, but it works.

Disappointed by outcome of latest blog. Binary conversion issues 
are still a catastrophe. We were supposed to get it right and easy, 
ok?

It's useful as a syntax type. We are thinking of making issue! a 
unique and immutable string as well, with supposed modifications 
generating a new issue!. It would be like words without binding or 
as many syntax limitations.

hmm, Carl dismissed #1113. I wonder if 'bind is used so often, that 
he was afraid of overloading it, and introduced new mezzanine instead? 
Was that really necessary? Another one to learn ...

Because historically I am far from being alone, who finds current 
R2 working as being complete mess. How can anyone defend it? I can 
easily tell you, where it comes from. I am far from good at wrapping 
libraries, but I wrapped some functionality in the end. I can often 
see constants like:

0x0010

Which are for me equivalent to:

#0010  ; which I can get via to-hex or to-issue 16

#{0010} ; to-binary 16 = #{3136} .... and this is big WTF? Now at 
least R3 gets it correctly, although padded by full of zeros to form 
64  bit value


So, as you can see, my thought pattern came from not easy way of 
how to convert between integer and binary representation. I created 
my own crazy 2-binary function :-)


to-binary*: func [value [integer!]][load rejoin ["#{" to-string copy/part 
at to-hex value 7 2 "}"]]

The r3 GUI demo code at r3/demo.r offers a Halt when running the 
test but only a Quit in the Demo launcher itself - and, at least 
on Windows XP, it blows out your rebol session - whereas the Halt 
in the demo does not.  Rather annoying as a GUI demo feature ... 
 does anyone have a moment to throw another button onto the demo 
launcher?

I am trying to traverse paths that I am using at http://cl1p.net
where a path might be http://cl1p.net/wp-aule///c2/Is there 
any way that I can use this to search for any path 3 deep such as 
http://cl1p.net/wp-aule/wiki/history/c2and  http://cl1p.net/wp-aule/wiki/alternate/c2
  and   http://cl1p.net/wp-aule/smalltalk/wiki/c2???   That is, 
can we tolerate null in paths as, say , type unset!   ??   I think 
of these as incomplete nestings of blocks where there happen to be 
unbound keys  blk: [k1 [  blka ]   where :blka  might sometimes be 
[ k3 blka1 ]  and sometimes just  [blka1]

I will go back to R2 Liguid and see what these would look like as 
data vars whose values are not yet known.   That cl1p.net tolerates 
these pseudo-URLs is immensly useful ...  for example, we tolerate 
the URL fine even in R2 as  in  test: read http://cl1p.net/wp-aule///test
 and test: read http://cl1p.net/wp-aule//path42/testand http://cl1p.net/wp-aule/path21/path43/test/

I'm having a little trouble understanding your question. File/URL 
paths have nothing to do witth the REBOL path! type - file! and url! 
are string types, so they don't have inner blocks or unset! values 
in them.

when we don't find a word in a slot, we fail;  my question is COULD 
we tolerate an unset! where a word! is now expected ... the Rebol 
path! type is just too useful to ignore here ...  and our use of 
the character '/' does have "something" to do with our natural interpretaion 
of file and url - files assume valid hierarchy depth at time of tracversal, 
a web server need not ...  at the moment we have no type corresponding 
to what follows an HTTP schema and domain other than string .... 
or am I mistaken?

/home////cfg.txt as finding /home/local/bin/scripts.cfg.txt  and 
/home/lib/ruby/site/rules/cfg.txt

The problem is that an http server has the option to provite a directory 
of their resources, but there is no generally agreed-on machine readable 
format for providing such a directory, and the human readable format 
(a Site Map), isn't implemented on most sites. If the site you are 
interested in has a site map you can grab and parse that, or you 
can trace throuugh the links on the site and hope for the best, or 
you can make use of an external service like Google that has already 
traced through the links.

I am trying to think through this as a "clade" and not a fixed "hierarchy" 
... as in every case of c2.com as a "terminal" tag there is a common 
"phylogenic" ancestor in "smalltalk" or "wiki"      Tagging is usally 
seen as in conflict with hierarchical ontoly and I am trying to get 
my head around this in looking at REBOL versus ICON to parse thses 
cl1p.net paths if I opt to go with them.   Gabriele last looked at 
some of my odd notions here ... they come from working in a PROLOG 
variant ...

The problem with ontologies on the web is that you have to get the 
server and the client to agree what the ontology should be, because 
the interface between them is just a string and a bunch of headers.

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

Glad to hear it, and look forward to finding out if you will be able 
to change-dir to those paths :)

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?

I don't want to go the way of installing and configuring Apache, 
and using some scripts to test throughput in real CGI scenario, as 
R3 CGI mode is not properly implemented yet ...

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.

BrianH: looking at tickets ... have we reached some positive point, 
where we fixed most of datatype conversion related tickets, and hence 
can move on ... to finally see the plugins released? :-) What can 
you see as the next logical priority to take? Or should we move to 
let's say networking? Networking is still not comparable to R2 - 
many protocols missing ....

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.

As for what's next: Carl is working on finalizing the plugin model 
- apparently getting the decoupling right has been tricky. I am fixing 
module importing and making a semi-formal model for the module system, 
and working on R2/Forward. I have an idea on how to simplify the 
specification of port schemes - implementation of port schemes is 
already simplified - but the module stuff is stuck in my head so 
I have to work on it first. If someone else wants to work on protocols, 
go right on ahead, preferably the useful ones first :)

984 is no longer a problem, but might be misguided. 1001 and 1056 
had one attempt to implement them that hasn't worked yet. 1081 is 
probably a bad idea (no offence intended, meijeru). 1109 and 1110 
are dependent on the result of the blog #222 discussion. 1034 is 
critical in the long run, but not as important in the short run.

hmm... immediate! and internal! typesets. I wonder what the first 
one is?

My guess is that immediate! types are ones whose values fit within 
a value slot of a block or context, and thus are not reference types. 
I would put all of the numeric types including money! in that set, 
as well as date!, time!, tuple!, and event!. Most of the time gob! 
can fit in there too, afaict, as can error! with codes less than 
100.

Robert, go to Home and Settings. There you can set your user color.

As to #1081, I merely pointed out the inconsistency, and did not 
advance a solution. The more inconsistencies, the more documentation 
is needed, and the more there is for the user to remember.

As for why it might be misguided, that is because the stated purpose 
of that request - recovering the module in serialized form - is definitely 
impossible, and would be a major security hole if it were possible 
(which is part of why it is not).

Carl has announced the applicability of logical operators to type(set)s 
for a77. At first sight, this duplicates union ( ~ or) intersect 
(~ and) and difference (~ xor). Then again, both sets of operators 
are also defined on bitsets, so there is consistency in this duplication, 
and I suspect that typesets are really bitsets, internally. However, 
there is one extension: and/or/xor may have a single datatype for 
their second operand (also for their first???). This is not the case 
with union etc.

It's also possible that excessive complexity was the problem that 
needed resolving, and the "simple method" is the solution :)

still need modules and more bug fixes

I think that when we hit beta, people might expect to start writing 
production scripts with it. So we have to be sure that the important 
areas won't change too much between beta and final.

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 
    ?

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.

Money: Well, but it should be possible to exchange it as a struct 
or whatever is needed. And we can provide some C-level code to handle 
the internal format.

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

Sunanda, so making string to words and making lit-words to words 
isn't quite the same, it seems!?

>> (to word! '=) = (to word! "=")
== true
>> (to word! '=) == (to word! "=")
== false

QUOTE is mezzanine, and in mostly for qoting function references 
and other active values in generated code.

Yeah, I found !=. I guess, the :<> is a lexical bug?

(I'm still working on a deep test on the lexical analyzer and hope 
to send the result to Carl and the rest of the R3 developers in the 
near future.)

I'll handle it in my lex report. There are many problems with < and 
> in different combinations. I guess, it's because they clash with 
the tag! datatype. For example:

>> '<
** Syntax error: invalid "word-lit" -- "'"

The lexer is where the priorities are set. What you are talking about 
isn't bugs, it is preferences (and good ones at that).

Ok, I see it differently. If it's possible to make a lexer, that 
can cope with tags and lit-words and get-words like '< and :<, then 
I see it as bugs in the current implementation.

Output from my work-in-progress lexer:

:>
Valid get-word: :>
'>
Valid lit-word: '>
<a>
Tag begin


Next it should get the whole tag and return that as a valid tag. 
I think, it's possible to make a lexer, that can handle all this 
correctly (as I see it).

I don't want to allow , in words, I want to have the word be recognized 
and then have the lexer complain about the , next time.

Or maybe because comma is used in many languages to separate arguments, 
and by not allowing comma in words, REBOL might be easier to read 
for everyone.

and

reduce [a,0]

Steeve, a period is usable, but not used (in general). And the period 
being usable is likely why the comma is an error.

comma can be _used_ in words, but not in words that have to be serialised 
and then reloaded

    to-word "a,"    ;; this works  
    == a,

    to-word ",a"   ;; there are some limits
    ** Syntax error: invalid character in: ",a"

Don't serialise and reload O:
    o: make object! reduce [to-set-word "a," 1]
    == make object! [
        a,: 1
    ]

But it's R2 compatible :)

There are other edge cases -- Latin-1 chars that can be _in_ a word 
not not _start_ them, and do not serialise well.....I did a script 
and found them all once

re: 666 -- I'll dig that script out and run it tomorrow :)

All standard functions and syntax in REBOL fit within 7-bit ASCII, 
which is why R3 source is UTF-8.

Knowing the internals isn't hard. I haven't seen the native source 
- I've just seen the mezzanine source, followed the conversations, 
and read sites like the onee Ladislav linked above. The rest is deduction.

{so making string to words and making lit-words to words isn't quite 
the same, it seems!?
>> (to word! '=) = (to word! "=")}

- again, the first TO WORD! is just a no-op

I came across another funny thing. Are << and >> planned as operators?

>> ? >>
No information on >>

So >> is a valid word. But >>> is not:

>> ? >>>
** Syntax error: Invalid "word" -- ">>>"

>> and << are likely allocated for user-defined operators. Please 
don't allocate >>> and <<< - it would be too hard to discourage their 
use if they are allowed syntax. We don't want REBOL to become a write-only 
language like Perl.

Logical, maybe. Harmless, perhaps. But odd ..... and inconsistent 
with REPEAT:
    repeat a none [print a]

    ** Script error: repeat does not allow none! for its value argument
So I am wondering if it is a deep feature, or an oversight.

As for the other functions, it is an intentional change from R2, 
which reduces special-case code wrapped around FIND and SELECT.

I think that distinguishing between upper and lower case chars is 
very difficult with Unicode.

hmm, should uppercase and lowercase really work with katakana and 
hiragana? the "small" versions have a completely different meaning 
and usage than our "lowercase" has.

it seems to me, that uppercase and lowercase should not modify kana... 
but I haven't read what the unicode standard mandates here.

No doubt you are right. I haven't read the unicode standard and know 
nothing about "non-Latin" alphabets.

BrianH: 'and, 'or, 'xor are allowed logical operations upon typesets. 
Do you think it would be usefull to allow also 'intersect and 'union, 
to allow creation of combinations?

I would need u-types for integration with .NET and other systems, 
but not for my compiled functions idea, as long as the compiled functions 
use the same frame-based marshalling interface that the plugin model 
uses.

Since the plugins only export 3 functions from their library, and 
dispatch calls to commands from a single function, I could add new 
commands at runtime as long as that function has some way to make 
sense of their indexes. Then I could make a plugin that wraps a JIT 
compilation library like libjit or libtcc.

http://tlt.its.psu.edu/suggestions/international/bylanguage/japanese.html


To elaborate on what Gabrielle said, in most languages, there is 
a large and small version of letters for use usually in sentence 
case, and also for abbreviations, etc.  Over time these began to 
be written differently, so the large and small actually look different.


But in Japanese, small letters have a completely separate meaning, 
sometimes used to elongate a sound, or form a subtle guttural stop.

Here is a sample, it is VERY subtle.


http://christopherfield.com/translation/images/hashiriame/story_a.gif


In this image look for all the symbols that look like a backwards 
letter "C" (or letter "U" that fell to the left).

Sentence 1 - 3rd from the right.
Sentence 6 - 3rd from the left.

Notice they are very subtle different sizes.

That is an example.

Bottom line, as stated, don't mess with caps with Japanese.

(it was hard to find a GOOD example of this in the same image).

This could be an advantage - there are many languages that support 
capitalization as a concept, but many that don't. The ones that don't 
have more characters than the ones that do (I'm guessing). This means 
that we could use smaller tables/code to do the capitalization in 
LOWERCASE and UPPERCASE - valuable space savings for a tiny language 
like REBOL.

But BrianH is patient enough to explain me, that 'text operations 
are pretty common, and that they might deserve special treatment.

What I don't like about REBOL, is all those read-text, send-service, 
open-service and other tonnes of mezaninnes. But I think that actually 
I might reconsider my pov, and maybe I would prefer read-text or 
read-csv, which could incorporate tonnes of possible refinements, 
instead of giving 'read special /text refinement .... 'read is too 
low level in R3 ....

IIRC there was also problem with my proposed aproach, that currently 
decoders can't stream (and it really sucks), so that we could get 
double memory consumption - first reading text, then decoding it. 
That is imo why BrianH proposes read/text, to handle it in low level. 
But - I don't like, when architecture flaws are fixed by such workaround. 
Please give me streamed codecs and streamed parse instead ;-)

I just spent a few hours trying to debug someone else's code ... 
and this was the cause.

perhaps Graham should explain what the bug was and how he fixed it. 
I have had problems with it too.

Personally I think it should always display the seconds, and we can 
trim it to remove it for display purposes.

Graham, you're actually asking for mold and form to always include 
seconds... which is something i think i agree with, though, it would 
be much better to finally have FORMAT for all these things.

Thanks...


Peter -- that was more-or-less the best solution I had. I was hoping 
for something better.


Gabriele -- that seems to work! I'm sure I'd tried it, and it hadn't 
worked for me when I tried it......But it does now. Nice!

I think I got confused because it _seems_ to work of R2 but does 
not:
    find first system/words to-word "really-no-such-word"
    == none
     last first system/words
    == really-no-such-word
Whereas, it really does seem to work on R3.

Isn't the difference between R2 and R3 because words are automatically 
bound to the global context in R2 but are not automatically bound 
to any context in R3.

You probably don't need to worry about creating entries in the symbol 
table though. Word lookup is constant-time, and there is no effectve 
upper limit to the number of words it can hoid - you'll run out of 
memory in a 32bit address space first :)

Is there any way to get  ^{ as an escape comparable to ^}  into rebol2.7.6 
?  2.7.7 ?  Otherwise generating string comtaining both dbl-quote 
" and curly-braces seems quite maddening ...  when using REBOL on 
server-side what is easy in PHP or PERL is suddenly a challenge ... 
or am I missing something about wrapping strings in curly braces 
?

My problem   token:  join  { ^{ text color = "red", name = "test1" 
}  [ token2 token3 ] ; when first value has many options and is spread 
across multiple lines for readability, the string value requires 
curly braces; token  is ok to be   token3:  { some text  values and 
then clsing escaped curly brace^} }

I see no change recorded at http://rebol.com/r3/docs/datatypes/string.html
   Is there really no hope of   {" folowed_by_space then whatever 
chacters I please _ending_with_space _before "}   or some such as 
  {~ space_before_text_then_ending_space_before ~}     It is so odd 
that for our emphasis on value that a string containing  a linefeed 
and an odd number of braces is an error.  After all,   an odd number 
of colons is not an error !   Why MUST we escape characters rather 
than allowing true LITERAL string values ?  We even allow semi-colon 
within braces without an escape !  ;comment anyone?

Sounds interesting. A few comments:

- Colons and semi-colons don't have special meaning within REBOL 
string literals - { and " do (depending on how they are specified).

- String literals in programming languages almost always have escaping, 
though the capabilities vary from language to language. Escaping 
is done to include data in the string that would otherwise break 
the syntax. Without escaping you will never be able to include certain 
characters or character sequences.


There's a lot of terms and methods for what you are asking for, such 
as here docs (from Perl), CDATA sections (from XML), etc. An interesting 
idea, though it is usually cause for concern when we look to Perl 
or XML for syntax ideas - that's usually a bad road to take. Remember, 
when you get rid of escaping you limit the characters (or sequences) 
that you can include, though with here docs that limit can be minimal.

For literal string delimiters, {~ followed by a space seems safe 
as I am unaware of where ~ is used followed by a space and at the 
other end I cannot think of where tilde is used followed by a closing 
curly brace.  Having Rebol always test for nested curl-braces in 
curl-brace values makes Rebol as difficult for my project as is Tcl 
- for the same reason.  Worka-arounds abound but the result has such 
poor usability and readability as to be unusable.

For example, I think RobertS might be happier if a new special type 
of string which is delimited by ~{ and }~ was added to Rebol.

In the content, single braces } or single tildes ~ would not need 
any escaping unless they happened to be together so that they look 
like the ending delimiter.
Or maybe no escaping is possible/necessary in such a string.

But now I'm also thinking of the start and end unique key strings 
used to delimit email attachments...

Gabriele, the problem is, that if you for example want to form JS 
code from REBOL, you will hardly have matched {} pairs. At least 
that's my experience.

What Robert wants (and I second that) is something like "heredoc" 
notation.
http://en.wikipedia.org/wiki/Heredoc

Hmm, scripts would too easily get "messed up" (that is, very unreadable) 
with Heredoc or similar stuff. maybe we could use #[{   .....    
}]# for that... I'd still rather use external files for long strings, 
and use escaping for short strings (in other languages you have \" 
everywhere, so why bother with a couple ^{ ?)