AltME groups: search

hehe, found-out Carl started to address bitsets, as new doc starts 
to appear here - http://www.rebol.com/r3/docs/datatypes/bitset.html
:-)

He also restructured a bit main R3 Doc page ....

Same a finding a charset, except it's a set of longer values than 
single characters. Position of the first in the set found returned.

I was thinking about the /into for appending the result to a different 
series.

I think that FIND/all would just return true/false, not a block full 
of positions.

I think he means both. He just talks about TRUE/FALSE for bitsets:


One possible justification would be if FIND/all is useful for other 
series. For example, a FIND/all on a block might return a block of 
results.

That could perhaps be useful. Generally there has been some level 
of index concurrency control with multiple series missing in R2, 
like being able to do a FORALL on multiple series simultaneously. 
I can't remember if R3 solves any of that, because it's been discussed 
quite a long time ago.

so, FORALL is native in R3. that might make it harder to change. 
Otherwise I would suggest, since it uses a word for input series 
to use a block for multiple series:


forall [series1 series2 series3] [print [index? series1 index? series2 
index? series3]]
1 1 1
2 2 2
3 3 3
...

I run into this curiously often, which is why I suggested it. It's 
useful where you need to get a block of  blocks "turned 90 degrees".

Reading the bitsets document, says:


Create a bitset large enough to holds bits up to 1000 and set bit 
1000:

	bits: make bitset! 1000  ; note that bit 1000 is set

But in A92:

>> make bitset! 1000
== make bitset! #{
0000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000
}

Is this right?

Added an idea on the bitset complement dilema, worth considering 
IMHO.

its a logical extension of the new bitset notation

ah... well, I was just proposing a way to prevent bitsets scaling 
to2^16 bits when you join them in specific ways.

created ticket #1292, addresses a few problems date!  handling of 
time.

actually... doing more tests.... I realize that the time is added 
to the date directly, not counting current time... which is actually 
proper, since I'm doing a set... not an addition.

so I'll change that bug report to a documentation one... cause it 
can be misleading until one understands it.

hmm, a bit too many crashes, recently, no? :-) Are unit testings 
still being done for releases?

this could be interesting to those building a "Try rebol" web page: 
http://www.masswerk.at/jsuix/

Chris: "Is 'load/next supposed to return binary as the second part 
of the result?"

Yes. R3 source is defined as binary encoded in UTF-8, not as a string. 
LOAD/next of a dir or url which returns a block on read, or of a 
script-in-a-block will return a block reference as the next though.

We could do a Q&A type session.   It would be live.  We could use 
a new group if desired.  Perhaps put the date in the name.

Pekr: I'll be back in a while to check for your reply.  I want to 
be sure that I can post my notes where they should be.  Perhaps we 
need some new group chats?

c: so the modules in rebol will works like the external libraries 
in c langagues or java ? require "thismodule" and then it works? 
but then how i'm sure the modules i need are loaded when i script?

one of the good point in rebol was anything was available anytime 
and you didn't had to care about what module is load in your context 
or not...  that was a good thing at least for people like that starts 
projet  with a bare skeleton and then feed the skeleton to make it 
grow

Carl: thank you for the parse rebuilding i didn't understoud what 
was going on with that topic, but since  parse is the foundation 
part of rebol it's nice to have if enhance and evolved once in a 
while.

/utc is a very good idea though.

for example, writing a clock program, I'd rather just have now/hour 
to lookup than having to fiddle around with time zones.

its a bit akward though... cause setting time and hour won't give 
the same results... and getting hour for a date within midnight your 
time and the UTC will cross dates and make it so that if you get 
the /hour and the /day... they actually don't match  ' :-/

I am absolutly agains it. It will confuse hell of a user. If you 
have 28-Oct-2009/20:38:01+1:00, I expect /hour to return WYSIWYG 
value. If I need the UTC time (how often actually?), I can apply 
addition of time zone ...

the /utc time is VERY usefull... I've had to deal with this in cgi 
and its not fun at all to have to manage it manually... but the discrepancy 
between /hour and /time  and the fact that the window where /hour 
and /day don't match makes this a non-trivial problem, and actually 
makes the date! type inconsitent.

I will ...  with  a nice recipe for disaster as an example  hehehe 
   ;-)

Maybe Cygwin could be a use as a console for REBOL under Windows? 
Libraries like this could be used then:
http://www.astro.caltech.edu/~mcs/tecla/index.html


I can't imagine a serious developer would be ok with the default 
Win console and no history and such.

Max - have you added your ticket? I can see it as a serious problem, 
so if you don't post it, I'll do ....

Geomol, the default Windows console has history, both in terms of 
a screen buffer and command line history.

Can't the problem with the console be posted to stackoverflow? There 
might be a few Windows experts out there willing to help

maybe Carl would be too proud to let part of the implementation of 
REBOL be influenced by a stackoverflow answer :-)

we reallly need to get 'SUM into R3... its just  soooooo slow to 
sum values in a block using rebol iteration.

as in
>> SUM [ 1 2 3 4]
== 10

Geomol, the default Windows console has history, both in terms of 
a screen buffer and command line history


Yes, I just noticed that today, when I tried under Windows. What 
exactly is the problem? The pasting of text into the console could 
be better, I think.

Max - Carl objected a bit to my ticket, so please ad your comment 
there at least :-) http://curecode.org/rebol3/ticket.rsp?id=1308&cursor=1

that's a little problem ...

Showing the correct character in a string might be a console font 
thing. Is %test encoded in UTF-8?

The syntax scanner has been accumulating a set of changes that need 
fixing. I would guess that Carl wants to do them all at once, since 
fixing the scanner is apparently not an easy task. It might be hand-made.

i try to have "ls -lisa echo" from telnet but a obtain only {} !!! 
why

the /hour refinements where changed to reflect timezone   :-D   


goes to show we have a lot of voice in how R3 evolves... when we 
can provide concrete arguments.

there is nothing stopping Carl from adding the R2 console back into 
R3.  the current.exe is still a GUI app.

I had many problems running sdk command-line apps when doing client 
work a few years ago... now at least this whole issue can be addressed, 
by simply flicking a switch in the host code and compiling a console 
version  :-)

I am really not satisfied with the Comments of Carl to #0001309 .
If I should read/as, I have to patch do and load and whatever.
I woud prefer a setting in the system/options.

I also think the "default" user text format should be configurable. 
  I have absolutely no desire to start using utf-8 for my code and 
data, especially when I have a lot of stuff that already is in iso 
latin-1 encoding.

The systems I know before, had a default codepage and did use Unicode 
only as an option.

I think it would have been enough, if R3 just added an Unicode datatype.
But now it's probably too late.

R3  is unicode from A-Z.   the code is unicode.

utf-8 needs no BOM... its only used as a signature.

..and sticking to the old ways means living with the old problems 
... like not knowing how to interprete characters properly ... like 
AlrME for example ... it assumes makes the assumption that all text 
in messages is encoded as though it was entered on your own machine. 
So messages from Mac users are incorrecly displayed on Windows machines 
and vice-versa.


For me, moving to utf-8 is a much easier problem to live with than 
not being able to properly share text across different platforms. 
It may be different for you.

Livnig with the old problems means knowing the old solutions.

Displaying text in windows is a different problem to loading programs.

By the way, Ticket #0000589  leads still to a crash, even it was 
set to build again.

handling encoding is complex in any environment... I had a lot of 
"fun" handling encodings in php, which uses such a unicode datatype... 
its not really easier... cause you can't know by the text if its 
unicode or ascii or binary values unless you tell it to load a sequence 
of bytes AS one or the other.

but having some kind of default for read/write could be usefull, 
instead of having to add a refinement all the time, and force a script 
to expect a specific encoding.

IIRC there was intended to have a header attribute specifying encodings 
for the script body...

I put a suggestion on the blog about allowing user-creating encoding 
maps... otherwise, you can load it as binary in R3 and just convert 
the czech chars to utf-8 multi-byte sequences and convert the binary 
to string using decode.

ok yeah a few different diacritics between those two encodings

R3 will interpret litteral strings and decode them using utf-8 (or 
the header encoding, if its supported) so in this case no.


but if the data is stored within binaries (equivalent to R2 which 
doesn't handle encoding) then, yes, since the binary represents the 
sequence of bytes not chars.


if you use a utf-8 editor, and type characters above 127 and look 
at them in  notepad, you will then see the UTF-8 byte sequences (which 
will look like garbled text, obviously).

I don't know if R3 has a way of specifying the encoding litterally... 
like  UTF8{}  UTF16{}  or WIN1252{} ... this would be nice.

A script cpud have two different encodings if differenlty encoded 
files were included. For example, you could use a script from Rebol.org 
in one of your scripts. You probably use Windows Code Page 1250 but 
most scripts in the library use other encodings.


This doesn't give big problems as most of the code in the Library 
is "pure" ASCII

I use uedit which handles unicode natively when you want to... a 
lot of preferences for it ...

Ok, so... no one reads the wiki.  That's ok... we're all developers. 
We don't read things other than code.

So, here's a summary of R3 and Unicode:

http://www.rebol.net/r3blogs/0286.html

Max: maybe you should start using a real operating system. But, that 
aside, if you have any software that does not handle utf-8, simply 
trash it. guys, really, this is crazy, we are in 2009, let's put 
an end to this codepage crap!

Max: a system wide default means that my script will NOT run in the 
same way on your system. that is the definition of bad language design.

gab, having a system-wide option will allow people to use the same 
code for different encoded source data.  it doesn't break my code 
or yours.  its a setup not a definition.

i love that documentation on bitset http://rebol.com/r3/docs/datatypes/bitset.html
 -> I give it A+++ a you must read it documentation !!

CArl on french forum they are wating to now if you plan to bring 
rebol world to the modile phone 3 generation area ? (android windowsphone 
or iphone). Could be a good way to show that not only adobe flash 
can provide things  in that area i think. But they a special "set" 
of feature should be build in rebol to feet the particular need of 
those plateform. What do you thin about it Carl ?

hum ... who said to develop an application that runs on a iphone 
you had to run it on an iphone ^^

its easy to compile VID blocks into other languages.  the only real 
tricky part is the actions, which have to be compiled too... so the 
best approach is to use a dialect within your event code, and stick 
to it.  this dialect can then be built so it can compile into languages.

a lot of rebol can be converted line for line in just about any language... 
you just need to keep the compilable language basic and you should 
be fine.

its a recurring request since REBOL as firat released.  with R3 we 
will now be able to compile rebol on ANY platform, which allows us.

Max: "action code 3 (flash) is now also licensed." I don't bellieve 
this is the case. Adobe has gone to great lengths to develop a Flash 
SDK which builds "regular" iPhone apps.

yes, that is it.  its a licensed development tool.

I don't think there is a standalone Flash player for the iPhone either.

nope... Apple doesn't want you to use flash in the browser... it 
kills their app market  :-(   
for example:

  bejeweled, one of the most successfull flash games ever, is available 
  as an app... they wouldn't want you to just play in on the net.. 


This is my only real Anger generating aspect of the iphone.   but 
this is true of just about every digital device out there... the 
provider wants to make money out of their appliances, so they control 
as much of what you can do on it, so they get a few cents every time.

Max, maybe i was not clear. If your rebol scripts are latin1 by default, 
while my rebol scripts are utf-8 by default, when i send you a rebol 
script IT WILL NOT WORK in the same way in your machine. the *script*'s 
encoding *must* be a standard everyone agrees on. then, the script 
can do whatever it wants with the data, it's your fault if you make 
it so data cannot be exchanged easily among systems.

I may miss something, but still I have problems with accentuated 
letters: 
when I type print "terminé" in the console, the result is ok.

When I put this instruction in a file, I get a syntax error: invalid 
"string" -- {"terminé"}

are you putting it in a file from a text editor?

jocko - the same happened to me here under Windows. The problem is, 
that I used plain Notepad, which by default stores in ANSI compatible 
charset. Then I realised, that on a Save-as dialog, there is a button, 
where I can change ANSI to UTF-8 unicode. Then my strings loaded 
correctly. So - you have to be sure that your editor by default saves 
in UTF-8.

Yes, that was the problem ... and I already had it. But it will really 
be a trap for many non english users, from many countries. Another 
point to consider is that we may have difficulties reading normal 
(non-UTF-8) text files coming from other environments. In R2, this 
constraint did not exist.

I can see it as a problem too. The trouble is, that I can't see any 
practical solution to it.

actually, it is a problem in R2.  if you store your code, and I open 
it with a different codepage version of windows... some letters will 
be skewed. 


In an application I wrote, I couldn't write out proper strings for 
the netherlands, as an example.


unicode is slowly becoming the standard for text... especially utf-8. 
 but yes, users have to be educated.  


within your apps, though, you can handle the encoding as you want... 
only the rebol sources have to be UTF-8 .  as R3 matures, more encodings 
will be most probably be included in string codecs to support 8 bit 
Extended ascii from different areas of the world.


and even high-profile applications like Apple's iweb have issues 
with text encoding... so this is a problem for the whole industry 
& users to adapt to.

its a relatively new preoccupation, because the internet forces people 
from all around the world to exchange data in real time...

One interesting thing about R3 scripts is that they are UTF-8 *binary*, 
not converted strings. A header setting would just require R3 to 
convert the script to string! and then back to UTF-8 binary before 
reading the file. This is why we recommend that people DO [1 + 1] 
instead of DO "1 + 1", because that string needs to be converted 
to binary before it can be parsed.

Even if we had a text encoding header for R3, it would be a *bad* 
idea to ever use encodings other than UTF-8. So don't.

I just tried to see, what is in my bitset. I used to-string, and 
received following result:

>> bits: make bitset! "abc"
>> to-string bits
== "make bitset! 64#{AAAAAAAAAAAAAAAAcA==}"


This is more lika a mold, right? What is bitset internally, a binary? 
I probably expected some conversion, but curious if the output is 
what you would expect?

You created a bitset of just one byte. When you append 1 to the bitset, 
you set the bit representing position 1 in the bitset, so you get 
#{40}, which is equal to binary: 2#{01000000}
Position 0 in the bitset is the first bit. Example:

>> bits: append make bitset! 1 0
== make bitset! #{80}

which is equal to binary: 2#{10000000}

Note that bitsets have changed in R3!

do you really need a 16MB bitset !! ?

Would it just be clutter to add a synonym for 'not  ... eg. 'no ?

so Carl, seems it was a bit more work than expected to get that host 
code out of your disk  ;-)
(reffering to this http://www.rebol.net/wiki/Host-Builds)

2^48 is as high as I can go on a 32 bit windows intel  before  abundant 
underflows    

and  only  2^ 49 on a  64 bit solaris sparc . Does R3 use the entire 
width of the available processor?

is this a common IEEE floating point issue?

I could see that  being the case on a 32 bit machine but not one 
with an exact representation

you should create a curecode ticket and discuss this with Carl.  
AFAIK he is savy about this stuff, so you could help him improve 
this if at all possible  :-)

he takes curecode VERY seriously.  and it will act as a databank 
of info however this turns out, for future reference.

modulo is a wrapper  around mod to make the result pretty in some 
cases

anyone got a rebol 3 icon for the desktop?

yeah, it's not a priority, but i moved the shortcut to my desktop

maybe its the return of REBOL as a team instead of a one man show? 
  

like its used to be in the golden days of rebol 1.x   

ahh  Bo, was such a cool guy at support   :-D

Some understandings.
What Rebol is doing when a serie is growing. ?
We know Rebol expands them, but following what scheme ?

I made some tests and saw really strange things.


Starting with an empty string and adding 32 * 1024 chars, I listed 
when the string is expanded.
>>8 16 48 112 240 512 2048 8192 32768


Meaning, when adding the eigth char, the string is expanded to fit 
15 chars.
It makes sense, because the size of a cell in memory is 16 bytes.

So, in the first cell, only 7 chars can be stored (remember, in R3 
a char takes 2 bytes)
Why 7 chars and not 8 ?
Because a string is terminated with the (null) char.


Another things we can see is that more a serie is large, more the 
reserved cells are numerous when an expansion occurs. 

It's a little frightening because we don't control very well the 
expansion in memory.

Now say, we're starting with a string of 8191 length.
>> 8192 16384 ... 

By, just adding one more char in it, my tests show it will double 
the whole size of the string in memory.
Is that not too much ?
Don't know...

I feel, it's a common thing to double sizes of series, when they 
grow. Lua does it too.

Steeve, it is not true that a char takes 2 bytes. That depends on 
the content of the string.