AltME groups: search

I figure it might be worth it (for me at some point) to do some test 
exports in native format in order to reverse-engineer the format, 
then write some code to generate that format ourselves. I have to 
do a lot of work with SQL Server, so it seems inevitable that such 
a tool will be useful at some point, or at least the knowledge gained 
in the process of writing it.

sqlab: you can have cmake generate a codeblocks project file for 
you

just need to get Carl to generate r2 docs in a similar location

Do we need to do aliases, or generate from a common set of data? 
Perhaps common pages for common functions, since R2 people might 
be interested in R3 compatibility notes.

Isn't the documentation system able to generate docs automatically 
 from help?

going to take 15 mins to generate the password for me

no good .. I've lost the password so can't access it anymore.  And 
it won't generate a new password for me.

So, what header files do you find a need to generate above?

CMake provides the benefit that we don't have to reinvent the wheel 
for now. It has, for example, a nice installer for Win32 and can 
automatically generate Visual Studio project files from the above.

The method I use for R3 simply uses REBOL to generate the host-kit, 
the makefile, and other related files at the same time.

With CMake the workflow of a user who wants to build the hostkit 
on Win32 would be as follows:
- Download and install a toolchain (e.g. MingW or MSVC)
- Download and install CMake
- Download the R3 Hostkit

- Generate a R3 build script for your preferred toolchain using CMake. 
E.g. use CMake to generate a GNU make Makefile for MingW
- Build the R3 Hostkit (using the generated build script)

true, but objects can be nested. and a single small object, like 
in the above, may actually represent MANY draw commands.
 

for example... a single block of text strings... may actually represent 
all the items of a text list.  parsing that list to fit things within 
bounds. 

re-creating the whole AGG block as you scroll the list, forces you 
to possibly generate a few hundred draw items in a block.


but you have to build that block using intepreted code, which only 
ends up being an intermediate in order to pass the visuals to the 
rendering.


with an object, constructing that visual can all be handled on the 
native side and will save a lot of work on the interpreter and the 
GC.

Having had a look to the extension pages of the R3 documentation, 
I see that the use of make-ext.r to generate the init_block is no 
more relevant.

The only way is to generate rebol wrapper func which will pass the 
args in a block! or object! imo.

REBOL doesn't have a "warning" mechanism at all, it just has an error 
mechanism. Warning mechanisms are really awkward at runtime - that 
is why you only see them in compilers or applications with runtime 
logging. And only the latter would apply to us. We have been talking 
about making a binding lint tool for R3 though, and that could easily 
generate such warnings.

It's quite clear, what it should return, when you see it in REBOL 
like form, but it's quite difficult to do such a decision when parsing 
the spec.. that's also the main reason, why I decided to work on 
human readable dialect. (I was trying to generate the extension directly, 
it's possible, but it seems to be hard to maintain.)

I have a very strange effect: The init_block gets a c filename attached. 
The .r file that is used to generate the .h header file of course 
doesn't inlcude it. And the generated init_block numbers don't include 
it too.

Used MDP to generate docs. Not optimal, but at least something. What 
I did was:

- replaced =image-code by =image
- shortened path, as images are just in the same dir as doc

- gui-panel-sizing-3.PNG should be renamed to gui-panels-sizing-3.PNG
- gui-panels-visibility.PNG is missing

No, that is implemented, but the color that is passed to the materials 
system to generate the final color or material object, is ultimately 
still passed to it inside the style.

The primary reason there's no OSX hostkit is that Carl has not yet 
managed to generate a libr3 to his satisfaction :)

he says he can't generate a .so on OSX that doesn't export all symbols

No, because you don't have the script to generate it :)

I may be missing something fundamental, but


1) am I supposed to be able to build a A110 r3.exe from the sources 
at github.com/carls/R3A110 on Windows with MinGW and gcc? The gcc 
makefile differs in a lot of places from earlier versions (A109 and 
below) and even seems to generate some .so's instead of .dll's. It 
fails for me with 

gcc  -c -O1 -D_FILE_OFFSET_BITS=64 -Wno-pointer-sign -I ../src/include/ 
 -o obj/host-main.o ../src/os/host-main.c

cc1.exe: error: unrecognized command line option "-Wno-pointer-sign"
before doing anything.


2) given that I somehow manage to build it and include my own changes 
in a clone of that repo, what happens to them if once there's a A111 
repo? I don't see how a A110 repo could be turned into a A111 repo 
- I would have expected to have a R3 repo on github and to have commits 
tagged as constituting a alpha version like A110, A110 etc.

Cool, I'll take a look. I've been trying to generate compatible parsers 
in mezzanine PARSE code, which could then be translated to other 
parse models like syntax highlighters for editors when necessary. 
I'm hoping to make a module of rules that can be used by a wide variety 
of syntax analyzers.

Lit-word arguments are for functions that treat words as keywords 
or part of the syntax, or for interactive command line functions 
that are supposed to act like shell funcs. If you use lit-word arguments, 
you can't easily generate the value passed using an expression, especially 
in R2 - in R3, those expressions can be put in parens, as is emulated 
in the R2 mezzanine backports of R3 functions that take lit-word 
arguments. For instance, if you made GET take a lit-word argument, 
GET IN wouldn't work.

Given that the "missing" parts of the precision aren't actually missing, 
sure, that works. And the standard allows those portions to be not 
depicted, just assumed. If you have to generate something less flexible, 
that is a *different* standard, so a different formatting function 
is appropriate.

Keep in mind that the main intended purpose of MOLD is to generate 
REBOL source code. You are suggesting that it generate more complex, 
larger source code.

KISS in this instance means default reduce, and use a refinement 
if you don't want this behaviour

 - well, that is very much like saying, that e.g. for the TEXT widget 
 in the Laout dialect you prefer to use a code block, which should 
 (re)generate the string to be displayed every time it is SHOWn. While 
 possible, it is not KISS

Cyphre was against it, and, in fact, it is not needed, since you 
can substitute so, you can generate any string you like this way.

Forgot to mention in the blog, but << and >> operators are not implemented 
yet. They are defined in the compiler but lacks the backend part 
in the code emitter. Anyway, you can achieve the same using * and 
/ with powers of 2, they'll generate shifts instead of math ops.

The original Java case benefits more from the concept than REBOL 
would because there are many addon standards like JavaDoc that need 
managing, but at least have been agreed upon by their community. 
We don't have that kind of agreement in the REBOL community. Also, 
the structure of the Java language is very limited, so it's a bit 
easier to parse it and have its structure just be in the background 
even though the language wasn't designed for that like Smalltalk 
was for its browser. For Red, since it's so early, things like integrated 
documentation can be developed along with the language, so something 
like this would make more sense. However, if Red is going to have 
even a large fraction of the power of REBOL then it won't be as structured 
as Java, making it a little more difficult to retrofit a Code Bubbles 
interface onto existing code. This is why you would need an IDE to 
understand code written in this kind of IDE: A Code Bubbles style 
interface doesn't generate code with story structure the way scripts 
are structured, so you can't just read the code without the context 
of the IDE.

ELF seems to be a bit smarter about page loading, it doesn't require 
explicit padding to page boundaries in the file itself, so can generate 
smaller exe. (It's possible with PE too with some hacking).

Supporting ARM directly only gets you so far on Android. Native Activities 
were only introduced in 2.3, so the vast majority of Android devices 
don't support them. This means that unless you have some way to generate 
Dalvik code, applications witll still need some Java in them in order 
to run.

You don't want to overdo it of course, but the more info the compiler 
knows, the better code it can generate.

Humm, looking at it a bit closer, it is not totally equivalent: the 
* and / operators will generate shifts only if the right argument 
is a literal integer. So: 
    a: 4
    123 * b
won't generate a shift.

So, I guess the conclusion would be: it is worth adding them. :-)

Red can load library functions with different calling conventions, 
but which convention does the emitter generate for its own functions? 
Cdecl?

By DLL building mode, do you mean having Red generate shared libraries?

give me a few minutes, i'll try to generate a binary that has that 
fixed

A define would still generate code, so it wouldn't lead to reduction 
of source or binary size

The integer! -> logic! is not free, it implies generating extra code 
for converting properly (see the type matrix). So the define won't 
generate any more overhead than needed.

Besides, the #define would still generate the extra code, wouldn't 
it? There's currently no way to specify that no conversion is necessary 
for a return value

Red/System can now generate dynamically linked ELF binaries.

GDB on Syllable currently only supports real-time debugging, as crashed 
applications do not generate a 
core" file (crash dump)."

On the callback matter, wouldn't it be better to always generate 
them as cdecl?

Since a few years, Qt and KDE use a new tool: Smoke. It's more automated, 
so it looks like it can generate a C interface without writing C++ 
yourself. However, the cross-compilation problem still exists. Because 
the tool is so generic, the bindings it generates are also quite 
bloated and probably otherwise inefficient. In any case, it's just 
the first step for a Red binding, because I put abstraction layers 
over my bindings that are much more REBOL like

Being able to make GUI apps on Android requires at least two more 
steps:
- have Red/System linker be able to generate shared libraries

- build a generic Java bridge to be able to instanciate java objects, 
invoke methods and receive events

Using a JNI interface is my plan, but it requires to be able to generate 
Red/System shared libraries. I was mentioning the TCP option, as 
it could be done right now.

I will stick with ARMv5 until we rewritte Red/System in Red and add 
a code optimizer. Such optimizer will be able to generate v6 and 
v7 specific code when required.

A few points releting to recent posts:

Nenad is already working fulltime on Red.


He has already accepted contributions to the Red/System compiler 
from both Andreas and Oldes.


Finding bugs by using Red/System will help speed the process of Red 
especially as Nenad's current design is to generate Red/System code 
from Red.

Pekr: (short answer) Red/System (and Red) generate executable binaries 
while R2/R3, while World and all other interpreted languages just 
run code in an interpreter or VM. This is a big difference, because 
Red can use the OS to load libraries at "load-time" instead of having 
to write code to do it (as all others interpreted languages require). 
This is also faster than loading manually. Red/System doesn't have 
yet a x-platform extension for adding "run-time" library loading 
support, just because we don't need it at all for now, but it can 
be added easily, by wrapping libFFI for example, or implementing 
it purely in Red/System.

Evgeniy: (short answer)


1) IIRC, there's no recompilation of included files in Red/System, 
the only overhead is parsing the preprocessor directives and reducing 
them. I agree that the whole compilation process would be significantly 
faster without a preprocessor, but that's another topic.


2) Preprocessor is a handy addition for compiled languages, that's 
why it was introduced in Red/System, not because it was a planned 
feature, but just because we _needed_ it for going further. The distinctive 
# prefix is used to make it clear both for users and the compiler 
that these parts are reduced at "compile-time" instead of "run-time" 
and avoid confusing both users and the compiler. For example, from 
your examples, the compiler has no way to distinguish a "compile-time" 
IF from a "run-time" IF, unless you make it a lot slower by doing 
static analysis and complex inference (the cost would be huge compared 
to the preprocessor). Also, this might also introduce a lot of new 
restrictions in the language semantics, which is not desirable.


3) IMPORT is better than INCLUDE: you might have missed it, but we 
can't yet generate libraries, so importing Red/System code now is 
not an option.

When I was trying to replicate the R3 word syntax, it was partly 
to document R3, partly to serve as the basis of a more flexible TRANSCODE 
that would allow people to handle more sloppy syntax without removing 
the valuable errors from the regular TRANSCODE, but mostly it served 
to generate new CC tickets for syntax bugs that we weren't aware 
of because the syntax wasn't well enough documented, and they hadn't 
come up in practice yet.

No () please, but you can of course use code to generate the static 
rule in the first place :)