World: r3wp

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?

Already spported, Pekr :)

ok then. Carl started to write-down A77 changelog, so it means we 
might be close to the first release .... or do you think he will 
merge some other tickets?

We'll see. Part of the reason for the release is to sync his work 
with the rest of the community. So, soon after a77 I can merge my 
fixes of those 15 CureCode tickets I wrote about modules yesterday, 
as well as other mezzanine fixes.

I think it's mostly a sign that we are reaching the end of this tunnel 
on plugins :)

no, we are starting to see the light at the end of the tunnel :-)

We saw the light last week :)

Hey, I just this moment figured out hot to do JIT-compiled native 
functions for R3 using Carl's new plugin model...

hot -> how

:-) cool, isn't it?

If I can get that method to work, that would allow me to work on 
the compiled REBOL dialect that I have been waiting on user-defined 
function types for. This is good news! It moves forward my schedule 
by months :)

so you don't need u-types anymore?

By the way, the method would not work with R2's library wrapping 
model - it requires the command! model.

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.