World: r4wp

 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!)

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

What are you missing from using pointers?


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.


The example is just showing how to do a dereferencing. It will probably 
crash on most systems if you use it with that value (reading should 
be safe on Windows, but writing not, as it is the default read-only 
memory starting page for PE executables). If you have a better alternative 
example that can work for real on all OS, feel free to submit a pull 
request. For example, retrieving the pointer value from an OS or 
C lib call would maybe be better (but much longer). My intention 
in this example was just to show how to dereference a pointer, how 
the pointer is initialized is a lesser concern.

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.

We will add an integer64! datatype in v2 ("long long" in C IIRC).

What I am missing, is the background about the memory-management 
in certain OS'es, so where is it safe to place/store the data in 
memory. That is why I expect the example value to fail in a general 
situation. When array is supported, this will be taken care of by 
the compiler is my simple thought.

For constants, #1 seems most the the annotation/decoration model 
that is used in other languages.


I like #3, because it looks like an dialect to me. Feels REBOLish.

Arnold: if you use DECLARE on pointer! or struct!, you already get 
an automatic memory allocation done by the compiler for you. Such 
memory will be statically allocated from the data segment (defined 
by the executable). 


Alternatively, you can use ALLOCATE to get a memory buffer for your 
array during the execution of your program (just don't forget to 
release it with a FREE call at some point).

Gregg: so far, I also think #3 is the best as it is the most compact 
form (when defining a lot of constants, all can fit in one PROTECT 
block). I would probably use set-words instead of words though.

Yes, that sounds good to me Doc.

Arnold, I've said it before, but there are time and random functions 
for Red/System in my C library binding:

http://red.esperconsultancy.nl/Red-C-library/dir?ci=tip

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

No, it strips any ../ prefixes from relative include paths and then 
looks for them in the compiler tree, instead of just using them relative 
to the location of the source file

I'm working on a new fix for that...

Thank you Kaj and Doc!

Kaj: I have a problem with #381. I have reconstructed a similar directory 
structure relative to Red/System root folder (on Linux). My issue 
is that #include directives specified from Red or specified from 
embedded Red/System should have the same base folder from the user 
perspective, but that's not the case currently. So, my question is: 
do you see any drawback in fixing this inconsistency? (Also from 
the implementation perspective, it is a nightmare to handle otherwise)

https://github.com/dockimbel/Red/issues/381

Think of it in the context of Red being encapped and used a single 
binary, having a reference to a Red/System base folder would make 
no sense.