AltME groups: search

It's unlikely that someone has issues starting with an alphabet character


Serial ID, product keys, etc... often start with a letter. From the 
implementation POV, your proposition is fine to me.

It may be a bit counter-intuitive that #dd64cc4f-1859-4c2d-86ff-31400868ec14 
and #033168aa-b7b1-413d-a57c-01f9c469d3b3 have vastly different performance 
characteristics when it comes to comparison. But maybe that's really 
the tradeoff worth making.

Red has a dedicated notation for hexadecimal numbers

If you know it's a number, you shouldn't use a string issue for storage: 
that's wildly inefficient

There definitely is a point. Please read the above discussion

Another thing: are natives more efficient than routines?

  Routines and natives are both Red/System code that use Red runtime 
  internal API, so they perform the same. In case of routines, you 
  might have a tiny overhead for integer! and logic! that are converted 
  back and forth between Red and Red/System, but it is really very 
  small, and only significant if you iterate a lot of times over a 
  routine call.


From the memory and boot time perspective, natives are more efficient 
because their body block is not stored internally  for reflection 
like routines. So, for functions like QUIT that should be part of 
Red core, it is better to implement them as natives, to save memory 
and booting time.

Doc, thanks for the explanation. About reflection, will there be 
a compile option to turn it off, for commercial code that should 
stay closed?

About reflection, will there be a compile option to turn it off, 
for commercial code that should stay closed?


What I planned so far is a compile option to switch between different 
modes of bundling the functions/routines source code into the final 
executable. Main options are: 

- in form of native "build instructions" (the current behavior)
- in form of compressed text


The latter option will generate smaller executables, but will be 
slow down boot time a little, as it will require the interpreter 
to process it. The former option provides a high level of obfuscation, 
that requires a lot of work to decompile (cracking REBOL's SDK protection 
is probably an easier job).

Doc - Kaj wants some option to trigger functions being complied in 
various ways. I just said, that maybe it can be done on per function 
basis, using special parameters ...

my-func: func [[dynamic] a [integer!]][]

Kaj: you should add your syntax proposition for keyword! + issue! 
to github tracker as a wish, so we don't forget about it.

Congratulations: the rhythm of changes in Red is just fast!

I scripted a little command that I run from time to time, just to 
see how both Rebol3 and Red are going:
cd ~/dev/Red/ && git pull && cd && cd dev/r3/ && git pull

And I can see through gitk that the rythm of Red's work is just amazing. 
Courage!

De rien, merci à toi!

I cannot really find a startup guide for Red: so, if no one shouts, 
I'll try to write one, during my long hours of flight next week.

I had read another version of these instructions; it looks like it 
was reworked a bit.

I found a reference to $LIGHT$ at the bottom of red-system-quick-test.txt 
, in what looks like a rebol script below a make-doc document.

Isn't it a bit dark?...

Something that I miss, from this doc page, would be a "getting started" 
with a step-by-step guide to start coding in Red

Well, I try to switch to dark themes to both save powers and my eyes. 
;-) 


I've provided a switching option to more classical "light" theme 
for the docs, but doing the same for the web site was too much work 
for me, so I've left it with the dark theme only. I will fix that 
once we get a new web site for Red (or if someone skilled enough 
can make the changes, I'll be glad to push them online).

yes; and white on black with my firefox fonts is quite painful. I 
have a nuclear power plant nearby, providing enough electrons moving, 
so that I can afford to waste a few photons...

don't worry about this... just a detail

Can you add a link to the makedoc files on each html page?

There is no makedoc files, I'm using the Blogger platform (Google). 
Unfortunately, a bad choice, it is an awful blogging platform, the 
only part that doesn't suck is the Google Analytics integration.

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...

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.

Is there a MD3 that is OS?

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

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

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?

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.

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

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

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.

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.

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

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.

Hmm...let me see, I might have introduced a regression in my uncommited 
code...

It would be very useful to have a search path for includes that could 
include directories elsewhere, possibly in the compiler tree, but 
it should start by checking relative to the source file

~/Desktop/Red/ is a symlink to ~/Red/. Not sure if that complicates 
anything

Arnold - binding just means, that Kaj have created a library of some 
functions in Red/System.

Just want to briefly describe that in my expectation a C-level language 
means you can do things like you would when using C. So it is not 
that you would have to call functions/programs/libraries with C programs 
to do those things. So for speed issues or fast prototyping purposes 
or to do things not yet possible in another way you use the bindings. 
In my case I wanted to try to program a relative simple algorithm 
of which I have an example in C and I want to do that using Red or 
Red/System. I can accept it is too early at this stage.. at least 
for me but this kind of thing is what others will be doing in the 
near future and they discover you can do literally anything using 
Red and Red/System, as long as you make a C program to do it and 
call that. That is a bit of a black and white view, but that is how 
I see it.

Thanks, Doc. That's a major devil driven out of the details

Arnold, Red/System has been ready for writing code for at least a 
year. Red is only getting to that stage now, so that's why I have 
been working in Red/System. My 6502 emulator is a major self-contained 
work in Red/System, but there's also the issue of communicating with 
the outside world. Unless you write your own operating system, the 
way to do that is by binding to the existing operating system

I've tested a number of complex scenarios, including one I hadn't 
reported yet, and they work now

I've done a full build run with the path fixes, without regressions

http://www.rebol.com/cgi-bin/blog.r?view=0527#comments


Fork: "I am porting Red to R3--and while I won't claim I'm "almost 
done", I will say I've made significant progress. Red/System now 
builds a working hello.reds under both R3 and R2."


Great! Like Nick says, hard to keep track of everything happening 
these days. :-)

Why don't we wait until more of Red exists? Or is Red feature-complete 
for core language features that would be used to write a compiler? 
If not, and you ported the Red compiler to the Red subset you have 
now, it would be a lot of work to do. And you'd want to rewrite it 
when you actually implemented the Red features you would want to 
eventually use in the compiler. Removing the dependency on Rebol 
should be done eventually, but it isn't as high a priority as implementing 
Red, right?

I haven't been of much help to you yet. I even may have been "too 
loud" sometimes polluting this discussion with my preferences. What 
I want to say now, though, is that I consider it good to have more 
dialects of Rebol instead of having just a totally compatible copy, 
so, please, take that as an encouragement and appraisal of your work.

The Rde presentation shows the use of the binary Red. In it shows 
how to compile to get a cgi and a dynamic library. Are these also 
implemented in the current compile scripts? In that case that holds 
a good argument to update the Redcompiler.r script. It needs some 
work anyhow I noticed, it is rather location dependent atm.

Arnold: no, it's not implemented yet, it's a target.

I'd like to know if it would be possible to use Red/System to implement 
a program to capture frames from a web cam on a Raspberry Pi?  Or 
would this be better performed in another language?

I know that François Jouen is already using Red/System to make image 
capturing from multiple cameras on OS X. Also as a rule of thumb, 
everything that is doable in C can be also achieved in Red/System.

That it is a target I can see now I have viewed the presentation 
a second time. Do you have a faint idea of a timeline when various 
stages of Red could become part of the real world? So version 4 in 
april and the first binary Red in 2015?

Binary Red could be added in a few weeks (except for the interpreter 
with console which would need an additiion binary), we just need 
to encap all Red codebase files in one executable.

For a complete single binary, we need Red to be self-hosted, so probably 
not before end of 2013.

The interpreter console is already a binary

Thanks for the info.  I have a 512MB RasPi and a 16GB SD card on 
my desk right now.  I'm going to give it a shot soon.

However, it's not yet supported for functions defined by #import, 
so if you need that, you have to write a wrapper function

Since Red needed jump tables, you can also go the other way around, 
and cast an integer/pointer to a function, then call it

Nice! It's amazing how fast you came up with a VID-like dialect for 
Red.

Well, most of the work is in the Red/System layer that I did more 
than a year ago

Plus, when putting a Red layer on top of it, you're staying within 
Red and Red/System, so you're on known terrain. Starting a new binding 
in Red/System throws you into the abyss of the external library's 
C code, headers and idiosyncracies, and documentation that may or 
may not exist or be correct

It requires a completely extra set of bindings, including to the 
Java VM and the GUI. We're thinking about it

OK.  Say I have a fresh Windows PC and I want to start coding in 
Red/System for the target of Raspberry Pi.  Help me understand what 
I need to do.  Here is what I assume needs to be done, but I may 
be wrong.

1. Download R2, I assume.  Any particular version?
2. Download Red/System compiler.  From where?
3. Write the program on the PC.

4. Compile it with Red/System on the PC, but for the Raspberry Pi 
target.  Is that just a setting somewhere?
5. Move the compiled file to the Raspberry Pi and execute it.

View for windows, there is a helper script redcompiler.r on rebol.org 
to facilitate (cross-)compiling

Bo - R/S is low level - mostly a wrapper to C to enable Red like 
syntax. It will not contain stuff to open files and do more advanced 
things imo, unless you link to some library and create a wrapper 
for such a purpose. I am too eagerly waiting for Red to get more 
advanced stuff. I think, that once Doc finishes the interpreter stuff 
ec., he is back to objects/ports, and then networking/files IO will 
come and more fun begins :-)

mostly a wrapper to C
 Red/System doesn't wrap C, it replaces it. ;-)

There's also standard input for Red there. Further, there's a wrapper 
for full-file I/O for both Red and Red/System that includes network 
I/O through the cURL binding:

This gets you reading and writing files, but you have to do any decoding 
yourself. So for reading JPEG data, you would probably write a binding 
to LibJPEG

If it doesn't need to be as specific as JPEG, you could write a binding 
to some wrapper library that supports multiple formats. For example, 
a simple BMP loading function is available for Red/System in the 
SDL binding:

or xnview command line - then you just need a CALL ....

There's also a basic binding to image loading in GDK, so that would 
load you all image types that GDK supports, including JPEG:

GTK sounds like a winner.

Thanks for all the tips, guys!

Bo, it depends on the code in question and the processor it's running 
on. It could be the same speed, it could be many times faster, and 
for some code it could be resolved completely at compile time and 
replaced with a constant.

Some optimizations will be very difficult or impossible to do if 
Red/System is used as the intermediate language, because those optimizations 
sometimes depend on the semantic model of the intermediate language, 
and Red/System doesn't have the semantic model of a compiler intermediate 
language. Optimization is hard work and people get PHDs for doing 
it. We can hope to catch up with modern C compilers, but don't expect 
it. One advantage is that Red is a high-level-enough language that 
an optimizer can make assumptions that a C compiler can't, so it 
is possible that we could get better code - it depends on the language 
and how much time we want to allocate on optimization.

I'm feeling nostalgic.  I used to hand-craft machine code on the 
6502/6510 series of processors back in the 80's, so I have an idea 
of what you're talking about.  There are some pretty neat tricks 
you can do when you're dealing with memory addresses directly.  I 
crafted more than one self-modifying program to squeeze every bit 
of computing power out of a processor.  I know that a lot of that 
ability has been removed by protected memory and abstraction, though.

Kaj, now that I've had a chance to do some work with Red/System, 
it's amazing to me how much work you've already done on adding features!


Here's something that I think would really help out a lot of us who 
want to make use of all your hard work.  Would it be hard to create 
http://red.esperconsultancy.nl/index.htmlwith a link to all the 
Red stuff you've done?  The only way I found what I needed to download 
was by searching through AltME for links, and had to manually enter 
in things like Red-common, Red-C-library, Red-cURL, Red-GTK, etc.

Thanks. A website is planned, but I haven't gotten around to it yet. 
I figure the time is better spent doing Red work

I saw that you wrote a 6502 emulator, but haven't had time to look 
at it yet.  Sounds like a fun project!

It's more like USE. CONTEXT exists as such in Red/System, but it's 
a compile time namespace instead of a runtime object

You first define a CONTEXT, then you can use it with WITH, or path 
notation