World: r4wp

The last snippet of code was some test I did for verifying how the 
strings behaviour are similar between Rebol 2 and Red. Look by yoursel 
and you'll see some small difference for the Escaped characters which 
are interpreted differently. Was this supposed to be so Doc ? Just 
asking before posting my tests for revision and correction ...

The tests evaluated here are based on the Perl string related features 
which appear on the Perl Cookbook (pleac website).

How do we install support for Unicode when using a Windows console 
?
 


You just need to select Lucida or Consolas font, raster font has 
no Unicode support. The CJK plans are not supported anyway by those 
fonts AFAIK.

The console script for Red supports only ASCII input.

You compile the script for full Unicode support for now.

You <should> compile...

hello

Hey Gerard :)

For named characters like "^(line)", IIRC, we don't support it yet.

It seems I already did it without having seen the right results but 
now it works ... : )

OK For your information about what I have done today for the introduction 
to the Perl Cookbok  just go to the REBEL BB forum and see my last 
post, it will be quicker to judge by yourself. - please you can comment 
too if you have some time. but LEt the others do the real work for 
revision and correction please.

I noticed your answer for the escaped chars

Is it the same for the other codes given in the Rebol 3 doc ? as 
for example when I type #"^(3B1)"     in the Red console, I get some 
errors too ...

I suppose it is the same case as the one before ...

when I type #
^(3B1)"     in the Red console, I get some errors too ..."

The console script for Red supports only ASCII input. :-)

OK but in a sense what I typed is in full ASCII, isn't ?

Thanks Doc and I leave you now - going "à la soupe"... You will soon 
go to bed too I suppose.

Glad you came back already and safe

Yes, you input ASCII characters, but the runtime lexer needs to decode 
your Unicode codepoint in hex format, and the lexer has no support 
for that.

OK that's already fine as is for now.

Right, I'm not far from going to bed. ;-)

Keep up the good work - i'll support you by means of other donations, 
as soon as my next cheque is coming in.

Must go back to some real work now - I just played all the day with 
these other websites and books ...

Thanks Gerard! I'll have a look at your posts on RebelBB and will 
send you my comments, if any.

Results for the initialized state-table are now the same, finally. 
Thanks!

Red/System: Could it be that if you 
#define MAX-SIZE 100
my-array: as int-ptr! allocate MAX-SIZE * size? integer!
then using  
my-array/MAX-SIZE 
gives a compilation error??
*** Compilation Error: undefined pointer index variable

Probably food for an issue?

I remember that we allowed macro replacement in paths, but it might 
be only for macros with parameters. Have you found an existing ticket 
about that?

doesn't look like it.

That may indeed very well have been only about macro parameters

You could work around it:

i: MAX-SIZE

my-array/i

Right but then I have a #define macro AND a variable. So I had better 
started of with the variable in this case.

But is really is a constant.

Yes, it's imperfect

That is why I created an issue for it #504.

I'm finishing installing the tools I need and migrating all my data 
from old disks, I should be able to get back to full coding tonight....finally.

Such things always take a lot of time

I reached this:
C code:
hex value 2214165945 is=0x83f97db9

* 1664525 gives 32710463130033 plus j 0 and plus the init_key of 
value 291 
mt[i] 32710463130324 and(&) FFFFFFFFh results in mt[i] 4287171284
Red/Systemcode
-2080801351 which is also (to-hex -2080801351)
== #83F97DB9

multiplied by 1664525:: 1658067045 and then added also 291 and 1 
minus 1
state-array/i: 1658067336

(My) Conclusion the multiplication by 1664525 causes the results 
of the C source and Red/System source to diverge, possible reason 
calculation with long integers in C versus integer calculation in 
Red/System troubled by overflows.

Is that on a 64 bit machine?

It is my Macbook from 2008.

That is 64 bit but not the core or something, that is why it can't 
upgrade beyond Snow Leopard.

It must be 64 bit, because a long on Mac would probably be 84 bit 
there. Indeed, your multiplication result is 64 bit, so on Red/System, 
it is wrapping around

64

However, the algorithm should also work on 32 bit, shouldn't it?

Or is it using long longs?

Yes, there is a trick to AND with FFFFFFFFh to bring it back to 32 
bits, but harm to the resulting values has been done then.

Not if the algorithm is meant to work on 32 bit