World: r3wp

Again.. when talking about fonts.. I want bitmaped font support. 
For example I create font's for my Flash apps in Rebol using simple 
image where I draw pixel precise glyphs:
http://box.lebeda.ws/~hmm/fonts/fixedsys.png
And provide the needed informations in Rebol format:

http://box.lebeda.ws/~hmm/fonts/fixedsys.png.txt(using UCS2 to map 
the glyphs)
Then I use my vectorizer to get the Flash font format.

The last step could be skiped in Rebol. And just the bitmaps could 
be used. So as in my Flash apps I can be sure, that the font will 
looks like I really want it!

But first we must have the R3 core stable and opened host sources. 
I will wait:)

but using font bitmap doesn't that will be slower than normal font 
/ text anti-aliased ?

I think it could be faster if you bypass the fon't engine. At least 
I suppose that font engines are using bitmap caches to speed up the 
rendering anyway. But of course it should be used to render in the 
size for which the font is created.

the means you need to create a font for each use that's a pain no 
?

How often do you change font in your text editor?

never

because to make it easier to handle the tete live motion we decided 
to fixe the size once for all

since that's do the makes the rest of the work more easy to grow

tete = text

and that's mainly because of a lack of a suitable fast way to determine 
size of a bunch of text (we can use a face dummi and sizetet to calculate 
but that not fast

Shadwolf, R3 have rich text dialect built in so it should be much 
easier to write RichTextEdit widget.

hum having the dialect doesn't' means you have teh proper low level 
set of drawing function to handle properly the text rendering

well i imagine that since the TDM (Text  Dialect Markup ) exists 
than AGG will follow and offer brand new things to handle conveniently 
the texte (and please please forget once for all about teh caret 
system please i beg you T___T)

what is in my opinion import in text handeling is to be able to get 
heigh and width taken be each letter or each set of letter (can be 
a word or a line ...

for example actually we are able to handle properly the text motion 
because we use fie font with a fixed size but this because what we 
want is to handle text in color and not mixe differnt kind of font 
styles and size like it would be the case for a MakeDoc format richtext 
rendering /editing widget

sure in our area-tc taht would be a plus to be able to handle ctrl+wheel 
action to grow shrink the text size (like you can do in any modern 
web browser for example) or to be able to set through a config panel 
the font size and type of your choice

Solved the other bug by commenting out one line of code. :-)

do http://rebol.hmkdesign.dk/files/chat.r

If I can get a couple of confirmations that the bugs are gone, I'll 
submit them to curecode.

I haven't been able to generate the segfault with your version in 
the way that I could with the live version.

and the "more 3365" bug is gone too.

Interesting. The changes are quite small.

actually, it could be because mine is not compressed.

That's a possibility. I'll try to compress your script tomorrow if 
I have time (it's late here) and see if it segfaults.

I'm trying to sort files by modification but it's not working.  sort/compare 
files: read %/c/ by-date: func [a b] [to-logic attempt [greater? 
modified? a modified? b]]

sort/compare files :by-date

does anyone use this type of code?

What exactly does Pending mean in Curecode?

Nicolas, sort/compare does not work in R3. This bug is in Curecode: 
 http://curecode.org/rebol3/ticket.rsp?id=161&cursor=8

It would be nice to see that one fixed, especially if it is easy 
to fix.

Pending means someone (me, usually) has already written a fix and 
submitted it to DevBase, but it's not built into R3 yet.

Carl's fixes don't get marked pending, he just builds them.

I don't understand a lot of these complaints where people say they 
can't contribute because REBOL "isn't open source". Large chunks 
of R3 were written by me, and every line I wrote was open source, 
freely available in DevBase.

A lot of REBOL is written in REBOL, and all of that is open source 
(in theory). The source is all in DevBase.

By the way, hash! being gone is not even in the top 100 drastically 
incompatible changes in R3. It's a new language :)

BrianH, then my fixes fit under the Pending category :-)

Yup, as long as they are submitted to DevBase. I mark fixes as pending 
before they are even accepted in DevBase, so pending doesn't mean 
inevitable. Some pending fixes have been dismissed (mostly requests 
for new functions).

I keep the new functions in my archives for later submission to the 
community library, if they are worth saving.

The function with the most incompatible changes in R3 is LOAD. There 
were many errors in R2's LOAD that have been fixed in R3. Almost 
every feature of LOAD is different, in sometimes subtle, sometimes 
drastic ways.

I am happy that you guys exist :)

Graham, VID+ was being worked on in order to get the core in good 
shape, by uncovering bugs and helping set priorities for fixing them. 
Now we are fixing the most important core bugs, including the one 
that has been blocking infrastructure development the most: the lack 
of a decent, working module system.

Now the thing blocking us is the lack of a multitasking model, so 
we are (mostly Carl is) implementing what we need to get multitasking 
working: memory protection and a new system object. It looks like 
we will have a shared memory model after all, rather than a shared-nothing 
approach. It's still up in the air though.

PeterWood, don't store the associated values in a map! as #[none} 
- that removes them from the map!. Use #[true] instead.

Shadwolf, the design of the map! type is pretty-well finalized already. 
It's the implementation that still needs work :(

Also, don't base serious development on alpha software unless you 
can afford to finish your development after it's no longer alpha 
:)

Janko, thanks :)

wow, now you are focusing on multitasking.. that is a big core thing 
... if there will be shared memory model we can probably build various 
other abstractions on top of it (I did observe some backslash vs 
pure message passing / actors lately also -- especially for concurrency 
on the same computer / cpu ) ..  this is interesting thinking IMHO 
http://clojure.org/state"Message Passing and Actors" under "I chose 
not to use the Erlang-style actor model for same-process state management 
in Clojure for several reasons:"

well he uses quite complex thing in form of persistent (functional 
-imutable (versioned)) data structures... that is probably something 
too complex to focus on now.. but if we have simopler / more primitive 
means of concurency we can probably build stuff on top of it .. and 
even try with some fancy data structures (factor folks were playing 
with them so they are doable)

persistent here doesn't mean it's in a db or a file but it means 
that data structures in clojure are immutable and theoretically when 
you change one you always get a new copy so threads can't break stuff 
to other threads in the middle of process, but the catcth is that 
that copy is not really a copy (which would be simple and *expensive*) 
but same structure reused with some different paths so that it is 
different ( I hope I made any sense ) .. he explained it in some 
video very nicely

Shadwolf: re R3 richtext; R3 will have the posibility to get all 
useful information at the font glyph level. The richtext module is 
able to give us all that info internally. We only need to design 
interface at the Rebol language level.

BTW even in current R3 version you can get the proper width/height 
 using SIZE-TEXT command. But I believe the final version will offer 
even more.