World: r4wp

You can just use Firebug or the developer mode from your browser 
to retrieve the CSS files.

Oh ...

I've tried playing with the background in the CSS, but it is not 
really convincing... I got a dark red, which looks more like vomi 
d'ivrogne...

Off-topic warning: I know most of you know this, but for any noobs 
that come along:  With LCDs and LEDs, the number of photons remains 
constant no matter the color scheme as the LCD/LED layers just filter 
out the light that is already generated by the backlight.  Some advanced 
screens will dim the backlight to the intensity of the brightest 
pixel, but these screens aren't as common.

vomi d'ivrogne
 Isn't that shade of red color better known as "Bordeau". ;-)

yes, sort of...

you are more poetic than I am...

Regarding docs, the issue for me, and perhaps others, is that reading 
html on your portable device requires an internet connection. So, 
an offline version such as epub or pdf is an advantage

Bo: ah thanks...then it is just for the eyes. ;-)

I do a lot of reading on an itouch ( should upgrade to something 
bigger )

GrahamC: yes, I totally agree. I am quite often out of Internet connexion 
for long periods, so I do appreciate long html pages that I can save, 
rather than bunches of small html pages. A large pdf is even better. 
Or a large .txt file, actually.

Well, all the existing Red docs are on github, so feel free to add 
PDF generation, I will gladly add them to the web site.

I'm not sure the Makedoc version I'm using supports PDF export though...it 
might need an upgrade to MD3.

all the existing Red docs are on github
 => is that what is in Red/docs ?

Is there a MD3 that is OS?

 is that what is in Red/docs ?

 Yes...except the "Red/System BNF grammar" doc that is produced directly 
 in PDF format by Rudolf.

MD3: I don't remember...but I sort of remember a MD version with 
PDF export...

Yes, we've been discussing this in R3 docs  There isn't one that 
is publically available.

Hasn't Gabriele done a MD-to-PDF converter by any chance?

Gabriele's md3 was his literate documentation

I have a rather tortuous path using makedoc => asciidoc => pdf/epub

Yes, Gabriele has a PDF generator. Don't remember if it supports 
MakeDoc format

Can't someone from the community make a MD to Gab's PDF dialect converter?

Such tool would be useful both to Red and R3 projects.

Gab's PDF emitter is pretty old now.  Doesn't support active links

That, and I believe you'd still need to manage much of the typesetting.

And AFAIR, it doesn't support external images

It'd be a significant undertaking.

Not sure how it works in PDF, but I wrote a VID/Postscript converter, 
using the layout engine of VID to "typeset" in postscript. Maybe 
this is the way to go for a PDF typesetter.

Better move this to the #Red Docs channel

It'd be similar, but your converter only rendered to a single page, 
right?

I would wait with the new site until it is possible and realistic 
to do it using Red.
long ago

 I explored a bit into themes for blogger that would give a better 
 fit for Red, but in the end the one chosen by Nenad turned out to 
 be far from the worst choice. (There were nice blue and green themes 
 but 'red' kind of limits the possibiities in that sense) The generated 
 CSS is like any generated webfile: big and bloated. I had no lust 
 in reducing it, spending a lot of time on it.

My own website is done with Cheyenne and the HTML dialect and is 
very easy for me to maintain: Makedoc files are rendered on the fly 
to each webpage. I can SSH to the server and edit files as I please 
and there is nearly zero HTML involved.


Granted, there is no blog or comments section, but is another example 
of how a small toolchain (one Cheyenne executable and a few script 
files) can be used to build a good website.

i made a pdf emitter for QML: http://www.colellachiara.com/soft/Misc/qml/

still old stuff, though.

Would boot.red be a suitable place to put bindings for individual 
functions? I would like to add a simple CALL implementation

If you're thinking about OS bindings, they should go in %platform/ 
folder. Can't you add CALL to natives? If you need help I can give 
you a check-list of things to add to support a new native, it's pretty 
simple.

I'll have a try

I'd like to keep it simple and quick for now, so I've done the CALL 
implementation externally in the C library binding, where the Red/System 
counterpart is

Kaj: could you please test if the fix for #277 solves also #381 for 
you?

Will do

It fixes 381 but not 252

Ok, thanks! I will see if I can add a fix for 251/252 too...

I've done a complete build run and I see no regressions in the examples

Kaj: I've made fixes for #251 and #252, does it work fine for you 
now?

With the implementation of a random function on Red/System I have 
some questions:

#DEFINE seems to become obsolete towards version 2, no preprocessor 
anymore, so any progress on a decision? https://github.com/dockimbel/Red/wiki/Alternatives-to-Red-System-pre-processor-%23define


How are you supposed to implement an array, I can figure out some 
things about using a pointer, but I cannot believe it will work with 
the example value of 40000000h 

http://static.red-lang.org/red-system-specs.html#section-4.8(.3)

I do not have a clue if this is a realistic value as a memory-address, 
that is why a simple array could come in handy.


At this moment I will not worry about support of a L(ong) or 64 bit 
type, I'll work with 32 bits for now.

Time is another fine thing. The OS should support one or another 
timestamp that can be picked up and molded into a preferred representation?

#DEFINE seems to become obsolete towards version 2, no preprocessor 
anymore, so any progress on a decision?


It is not the time for taking decision about Red/System v2. For the 
preprocessor replacement, we are for now just gathering ideas in 
the wiki.

The fourth alternative suggested for defining a constant looks best 
to me, but personally I would just use caps for the name, assign 
a value and not even think about changing it ever again.

The fourth alternative introduces a new datatype, so it has a high 
cost.

Ah, message crossed, I like to be prepared for the future :)

Then I like my method of using a variable and keep it a constant 
myself (but hey I still am a COBOL programmer!)