World: r3wp

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.

Is the a replacement for read/lines?

the =  there

I will reword my question.  In R3 how can I read in one line of unicode 
text at a time to process it?

I think that is not yet implemented. Just ask Pekr. He has talked 
alot about it. :-)

ah, damned, read/lines. What a crap :-)

Well, my only objection was, that I did not agree to read/text, but 
was suggesting more general read/as data 'decoder ....

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

read/lines in R3.....Best we have in R3 so far is DELINE/LINES. Eg 
from the R3 console:
    deline/lines to-string read %user-db.r

READ/text wasn't my proposal, it was Carl's. I often write the CureCode 
tickets for other people's requests, if they are good ones.

Pekr, expect the number of visible mezzanines to go down after the 
module system is fixed. The code is written already, but we are waiting 
for the plugin-related mezzanine changes before the overall module 
system changes can be merged in.

Louis, there may be a solution to your problem that involves direct 
port access, rather than a READ refinement...

Thanks for the feedback, everybody.  Brian, I'll check into direct 
port access.

Request ... I would like now/time to always return the seconds.

Edge conditions every exact minute are annoying...

Annoying isn't it? Have you submitted a wish to curecode.org?

For now, I use something like this:
    reduce [x: now/time x/hour x/minute x/second]
    ==[12:30 12 30 0]

no, I'd thought I'd solicit opinions first!

I think its a good idea!

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

I agree. Good idea.

however one can use:

to-itime 11:2
== "11:02:00"

to-integer now-time

eh, to-integer now/time ... does it return seconds? I think so ...

I am against now/time returning seconds - it shoul stay "human readable" 
....

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

I prefer consistency. Consistency makes it more easily human readable, 
despite all these "humanizing" algorithms. So I support Graham's 
request.

Henrik, I had forgotten about to-itime, but it looks quite inefficient


>> t1: now/precise loop 10000 [ copy/part join next form 100:00 + 
t ":00" 8 ] difference now/precise t1
== 0:00:00.073

>> t1: now/precise loop 10000 [ to-itime t ] difference now/precise 
t1
== 0:00:00.32

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

to-itime is only really good for consistently printing time, for 
example for a running clock.

Well, it is supposed to be used for forming internet time strings.

How can I check if a word exists without incidently creating an entry 
in the word table for it?
eg this does not work as the act of finding creates the word:
    find words-of system/contexts/user 'no-such-word
    == [no-such-word]

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.

Sunanda, I haven't checked, but to word! with a string might work, 
as it does not bind.

Slowly like this :

>> probe words-of system/contexts/user
[system a words-of contexts user to string! find context probe]

== [system a words-of contexts user to string! find context probe]

>> find to string! words-of system/contexts/user "no-such-word" 
== none

>> probe words-of system/contexts/user                          
[system a words-of contexts user to string! find context probe]

== [system a words-of contexts user to string! find context probe]

perhaps that should be simplified

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.

.... not all words ..just those that are forned with to:

>> probe words-of system/contexts/user
[system probe words-of contexts user]
== [system probe words-of contexts user]

>> 'my-word
== my-word
 
>> probe words-of system/contexts/user 
[system probe words-of contexts user my-word]
== [system probe words-of contexts user my-word]

>> to word! "your-word"
== your-word

>> probe words-of system/contexts/user 
[system probe words-of contexts user my-word to word!]
== [system probe words-of contexts user my-word to word!]

I would suggest, for R3:

 foreach word words-of system/contexts/user [if "my-word" = form word 
 [break/return word]] ; <-- untested.

Seems to work.

Note that system/contexts/user is not the word table, as system/words 
is in R2. The actual word table in R3 is an internal native thing.

Thanks for the clarification.

Can we test if a word exists without creating a junk entry in the 
internal table?

find mold words-of some-context-or-object "word-you-are-looking-for"
Expect it to be slow, at least relatively.

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

The limit is much relaxed compared to R2 where long running large 
applications needed some very careful word hygiene to not bust the 
2000 [then 4000 then 8000] limit.

But there is documented R3 limit of around 500,000:
http://www.curecode.org/rebol3/ticket.rsp?id=587