• Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r4wp

[#Red] Red language group

Gregg
17-Apr-2013
[7046x2]
That should be comfrotable for C programmers, yes?
Even if not required.
DocKimbel
17-Apr-2013
[7048]
Yep, C coder could feel easily at home. From what I've seen so far, 
people knowing C and Rebol can learn and use Red/System in a matter 
of hours. Even for pure C coders, learning Red/System should be trivial.
Kaj
17-Apr-2013
[7049x2]
Trivial is never trivial, especially on computers...
UTF-8 encoding would be very welcome. My I/O frameworks are of little 
use without it
DocKimbel
17-Apr-2013
[7051]
Red/System c-strings are UTF-8 compatible.
Kaj
17-Apr-2013
[7052]
I mean my ongoing request for getting UTF-8 in routines
DocKimbel
17-Apr-2013
[7053]
As I said above, that part is not implemented, it will be once the 
work on Red's I/O will begin.
Kaj
17-Apr-2013
[7054]
Yes, you said you might speed it up if I have a big need for it, 
so I'm expressing my need
DocKimbel
17-Apr-2013
[7055x3]
But someone could contribute string! <=> UTF-8 conversion routines 
in the meantime.
I'm afraid my short-term schedule is already full, I've kept postponing 
very important parts for months, I need to get them implemented now 
(shared libs, error!, typeset!, object!).
I think that those UTF-8 conversion routines would take at least 
two days of work to get implemented and debugged.    I'll see once 
I get shared libs done if I can afford them before working on the 
other urgent tasks.
Kaj
17-Apr-2013
[7058]
It's just that I thought Unicode was already there. Most of my future 
work is blocked by it
DocKimbel
17-Apr-2013
[7059]
Unicode support is there, but we don't have all the external encoders/decoders 
yet.
Kaj
17-Apr-2013
[7060]
It's nice that you can get data in, but it's useless if you can't 
get it out
DocKimbel
17-Apr-2013
[7061]
We have hardwired the stdout/stdin Unicode support because we don't 
yet have the I/O infrastructure for Red (ports and devices).
Kaj
17-Apr-2013
[7062]
True, but I do have the infrastructure. Just can't really use it 
this way
DocKimbel
17-Apr-2013
[7063x2]
Well, as I said, someone could contribute those UTF-8 conversion 
routines.
I think Peter already did some work on it as have Rudolf (meijeru).
Kaj
17-Apr-2013
[7065]
I wanted to publish an article with examples on the birth of the 
interpreter and the porting of the bindings to Red, but if a simple 
READ WRITE example doesn't work, I think it's too early to talk about 
it
DocKimbel
17-Apr-2013
[7066]
I will have a look at it once shared libs are done, that's the best 
I can do for now.
Kaj
17-Apr-2013
[7067]
OK, but I can't imagine what I would do with shared libraries if 
I can't get string data out
DocKimbel
17-Apr-2013
[7068]
Shared libraries are on the critical path to Android support for 
Red and I've delayed it way too much already.
Kaj
17-Apr-2013
[7069x2]
Same thing: what would you do on Android if you can get data in, 
but not out?
It's worse than having no Unicode, then you can at least get out 
what you put in
DocKimbel
17-Apr-2013
[7071]
For Android, java uses UTF-16, so the conversion from string! is 
(almost) trivial.
Kaj
17-Apr-2013
[7072]
But it's not there yet, is it?
DocKimbel
17-Apr-2013
[7073]
No, I will implement it when I'll need it, and I have a lot of other 
stuff to code for Android support before that.
Kaj
17-Apr-2013
[7074]
Is it wise that Red won't work on other platforms before it works 
on Android?
DocKimbel
17-Apr-2013
[7075]
The features currently implementd in Red are working.
Kaj
17-Apr-2013
[7076]
Sure, but it's pretty useless like this
DocKimbel
17-Apr-2013
[7077]
That's why it is called an alpha. ;-)
Kaj
17-Apr-2013
[7078]
I was hoping a little more could be done, but I'll have to postpone 
a lot of work
DocKimbel
17-Apr-2013
[7079]
I told you I will have a look at it once the shared libs will be 
done, just wait a few days more. If it's critical to you, you might 
want to contribute the required conversion routines?
Kaj
17-Apr-2013
[7080x2]
I could, but I know very little of Unicode, so there would be a lot 
of overhead in getting up to speed
I have no idea how long it will take you to finish the shared libraries. 
It has been a backburner project for a long time
DocKimbel
17-Apr-2013
[7082]
Not very long, I just kept it postponed since almost a year now, 
and it's getting on my way for Android support since a while, so 
I've scheduled it since a few weeks to get it done just after the 
interpreter is finished (Exit/Return support).
Kaj
17-Apr-2013
[7083]
OK, that's fine. It sounded like data out support was of undetermined 
priority
DocKimbel
17-Apr-2013
[7084x11]
The only "data out" support we need for now for building Red is the 
stdout support, and we have it since a while.
Red I/O full support is next on my list after the above mentioned 
tasks will be completed.
BTW, if you stick to Latin-1, you shouldn't have the need for any 
conversion?
Also, there might be a cheap way to achieve the conversion in the 
meantime using wsprintf() or similar function.
Hmm, it might not be enough, so you might want to have a look and 
maybe wrap libiconv:
http://www.gnu.org/software/libiconv/
For once, the API looks good and simple enough (4 functions to wrap).
From a routine, if str is a red-string! pointer, this is the dispatch 
code you would need to use:

s: GET_BUFFER(str)
switch GET_UNIT(str) [
	Latin-1 [...conversion code...]
	UCS-2 [...conversion code...]
	UCS-4 [...conversion code...]
]
Beginning of internal string buffer is given by:

	string/rs-head str	(returns a byte-ptr!)
Should be GET_UNIT(s) above, sorry for the typo/
Another typo: should be Latin1.
Anyway, you don't need any conversion for Latin1, so you just have 
to do it for the other two formats.
Kaj
17-Apr-2013
[7095]
Sticking to Latin1 is not much use these days. Many data such as 
web sites is in Unicode. It would be fine if it worked like R2, as 
a transparent passthrough, but Red eats your Unicode and won't give 
it back from its internal format