World: r3wp

A GUI client will certainly help usability, but since we have console, 
we can use it over SSH and that's a great thing.

Hi. Henrik, thanks for your answer on Carl's blog.

kib2, it's unfortunate there is confusion. releasing software should 
be simple, but it's not.

Can we use it via SSH? Hmm, interesting ....

SSH ??

Well, it is more flexible than Altme and Carl wanted to be some prototype 
start of new Altme. It has real threading, tagging, ranking, private 
messaging, is spriptable. So good so far. But - we also need read-only 
groups, private groups, or other app schema over it.

pekr, when we get an R3 for real operating systems, of course.

So, I use my cellphone to ssh to another box so that I can then run 
the chat??

Graham, yes, just like you can SSH to a linux box and use Rebol/Core 
through that already now.

for sure! Just a newbie question: as I've to wait for R3, is there 
a way to have a descent font rendering on Windows (antialiased) ? 
Ugly courier fonts really annoying for working/ reading AltMe messages.

Gabriele - read my comment above, please. Those 3 namead are prominent 
App servers, not webservers. Your team should really think to implement 
some file options ...

ah, wrong group ... sorry ..

kib2, not for AltME. REBOL/View (which AltME is based on) is hardwired 
to non-antialiased fonts in its View engine.

Henrik : so I really have to wait for R3!

kib2, yes and I hate to say it again, but: R3 also solves this problem. 
:-) It's quite amazing how many times I've said that now.

Graham, the console client is also because Carl uses SSH quite a 
lot in different locations, which is why he started with a console 
client instead of a GUI one.

This is really cruel...waiting for something that may never come!

If you die tonight ... well, everything will never come.

don't sweat over things you have no control over!

So, is Carl going to prevent developments that will eventually render 
this type of chat unusable in a console?

like attachments, formatted code, or color syntax coding etc

That's an interesting question. Perhaps you should ask that in RebDev. 
:-)

Just wondering how this will all scale over different devices and 
media

bad joke, but R3 it's like Perl 6 for me.

I don't want to be a negative influence :)

Graham, I think that if the message format is going to get more complex, 
there would still be ways to parse it for console use.

kib2: why? Perl 6 is in development two times the R3. And one year 
ago there was a public alpha. Soon enough there will be another one. 
This time with final GUI architecture (although not complete yet)

Henrik - is rebdev usable from R2? It has much better console. Windows 
one sucks, I can't set it wider easily ...

kib2, I know, but as I can see now, making a programming language 
is no picnic. This is the first time I've witnessed it close up. 
There is still a long way to go.

pekr, no, r2 console version is low priority. Carl wants to do R3 
GUI version next.

good to know GUI is next. It will help to further improve GUI ...

html version should be next ...

Graham, that would delay the GUI.

ok, concurrent then :)

The only way to truly speed up development would be to clone Carl.

So Carl1 could focus on rebdev, Carl2 could focus on tasks and Carl3 
could focus on modules. Carl4 would work on the GUI and ReBrowser.

just give us more docs and we can do this

that's really the point of collaboration

But can we provide stuff of high enough quality for him? That's the 
issue.

Pekr: I wasn't aware of the GUI stuff.

if that's an issue .. then he should close off all collaboration.

It is _the_ issue. Carl trusts no one unless you can work at his 
level. And that is also why the quality of R3 alpha feels like everyone 
elses release versions. :-)

Where should I report DevBase bugs?

I suppose the best place for now is CureCode.

When we use to block! on input data, most of the time we don't want 
 duplicate them if data are already a block.
(we use copy instead if we really want that behavior)

i think to block!, to string! , form and some other native conversions 
should never duplicate the data if they already have the correct 
format.

This, should limit the memory overhead in many scripts or mezzanines, 
and save us from coding many useless tests.

I agree Steeve.

it appears to me that most of mezzanines who have to do such conversions 
could be 1) shorter and faster 2) with less memory overhead

I agree with you and it seems to me that it would be a wise fix.

to block! copies data? if so - why? :-)

actually it copy them, don't know why...