AltME groups: search

Try with following C executable:  http://static.red-lang.org/tmp/loadlib.exe
(or .zip if you have issue downloading the exe).


Put it in the same folder as temp.dll and run it from DOS shell, 
you should have something like: 

C:\Dev\Red\red-system\builds>loadlib
error: 0
hModule: 268435456				;-- library handler
error: 0
&f1: 10001a85				;-- f1 function address
124						;-- f1(123)
error: 0

If it works, the DLL should be ok and the issue would be with your 
REBOL instances.

Rebolek: if you have a antivirus, can you disable it and try?

Try to watch what happens when loading the dll using Process Monitor 
and File Monitor from System Internals.

Anyway, if it works for everybody else, it's just probably some problem 
with my setup. I'll investigate it and let you know.

No, I mean the source code file ... but not sure it matters. E.g. 
for R3, I had difficulcy running some scripts, unless I re-saved 
the source file to UTF8. Some strange chars appeared in the console 
and apps crashed

I compiled it OK and loadlib works

How do I get different branch onto my PC?

 If you're using TortoiseGit client, just search in the context menu 
 for "Switch/Checkout", then select the `dyn-lib-emitter`branch. If 
 you don't have it, you need to click on "..." button and create a 
 remote to dockimbel/dyn-lib-emitter.

Well, downloaded zip. I was scared it will sync to the same dir and 
will create a mess :-)

well, and if you want to keep several branches?

I've uploaded a file on Altme, DLLFunc, it loads a dll and prints 
the function names. It works with temp.dll, shows "f1" function.

I use Total Commander, and they have cool plugin called FileInfo. 
It is able to nicely inspect DLLs .... I am comparing temp.dll to 
some other ....

I checked four additional DLLs, and the tool reports for all of them:

Entry Point RVA: 	00001000h
Entry Point RAW: 	00000400h

temp.dll is however:

Entry Point RVA: 	00000000h

Entry Point RAW: 	Invalid or not in CODE section (possible Encrypted 
or Compress Executable)

however - it might be unrelated, if it works for some of you, and 
it does not work for me and rebolek. Maybe somehow related to a czech 
locale Windows version? Any language dependency?

Pekr: I wonder if there's not an issue with the lack of entry point 
in the DLL, I just don't get why REBOL would choke on it sometimes 
and never the C apps (except your testing tool).

well, but the same library works for you and other users, when used 
with R2, so ....

REBOL does not return an accurate error msg when failing to find 
a DLL file:

>> lib: load/library %xyz.dll
** Access Error: Cannot open xyz.dll as library
** Near: lib: load/library %xyz.dll


This can be misleading thinking that %xyz.dll exists but is invalid, 
while it doesn't exists at all. So for the people having issue with 
%temp.dll, check if the DLL is present in the working folder and 
that you have correctly CD to that folder in your REBOL session.

Rebol and DLL in same dir. No response at all for me.

Rebolek: I run a french localized W7 here and no problem with the 
DLL, I doubt the localization is the cause...

So only Pekr and Rebolek have issues with it so far...

Rebolek and Pekr: I just fixed a regression in PE header, can you 
try it with this new revision?

just a note that the REBOL that is linked on the Red github page 
is core, and that doesn't work

I will better redownload .zip archive. Is there any way how to get 
link to particular branch, so that I can keep my working directories 
intact and not mix a stuff from various branches into one directory?

You can't mix things if you use a Git client and do a Switch/checkout 
each time...

I am ok to download zip until I figure it out ... Did so, and no 
change yet ...

it is imo not definitely a path problem. Just check with exists? 
%temp.dll, and it returns true. Still library is not loading ...

So for ppl where it loads, we have msvcrt rev >= 7600, for ppl where 
it doesn't load, we have rev 2600 and 6002 (Vista). 

Rebolek, are you running on a pre-RTM version of W7?

My msvcrt.dll version is 7.0.2600.5512 (on XP/Pro Turkish). and it 
works.

Petr - for a git GUI you might want to try SmartGit - free for non 
commercial use and, IMO, the best GUI. Also, it's available for all 
platforms. I use this, tortoise and the command-line, depending on 
the context

Pekr: it's easier than you think: just open https://github.com/dockimbel/Red
and click on the "Clone in Windows" button ;)

Pekr and Rebolek: could you try to use ProcessMonitor (PM) to see 
if we can get a clue about what is blocking the DLL loading from 
R2?


1) Download it from: http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx
2) Run it

3) Open a REBOL console and CD to the folder where the DLL is located

4) In PM, drag'n drop the "target" icon to the REBOL console window
5) Type in console: lib: load/library %temp.dll

6) Scroll down in the PM window to look for rebol.exe process entries, 
look for failure reports in Result and Detail columns...

I mean - now we can make wrapper libs, coding almost in REBOL (syntax), 
no need to become dirty with C, and hence get more libraries to work 
with R2, via a wrapper libraries written in Red/System?

Doc, can you statically link other C libs and use the functions from 
Red?

For static libs linking, if someone could contribute by providing 
a .lib and .a file reader/parser, that would help get that feature 
implemented sooner.

(.lib and .a reader coded in R2)

So, next steps (next week), add PIC support to backends and implement 
shared lib support in Mach-o and ELF emitters.

My personal favorite is Blender, I'd very much like to add Red/System 
support to it (and kick out Python later when Red will be there). 
;-)

But bridging with Android and iOS is high priority, so Blender will 
wait.

What I still think is, that we need strong parse. It is very cool 
technology. Yes, I dare to call it a technology. We need r3 level 
parse. Then we can create dialects, and show other guys, that dialecting 
is a cool concept. Pity we were not able to capitalise on it more, 
mainly due to closed nature of R2 possibilities to bind to other 
environments .... you imo :-)

I've looked at the Blender interface, but it's rather big and complex

As c-string! and struct! are already implicit pointers, the only 
pointed datatypes allowed are integer! and byte! (logic! pointer 
is not needed).

Pointer declaration is only required for local pointer variables 
in functions' specification block. In such case, the datatype declaration 
can be omitted and left to the inferencer to guess.

Blender: yes, API is huge and it's a lot of work, but I'm convinced 
that Red, with appropriate dialects, would do wonders there and it 
could be a great way to make Red known.

can I generate e.g. ARM executable/library from Windows Red/System?


You can cross-compile ARM/ELF code from Windows or MacOSX, just use 
the appropriate target (https://github.com/dockimbel/Red). Currently 
there's only two ARM targets: Linux-ARM and Android. You can cross-compile 
to these targets from any platform Red/System compiler works on.

Gregg: thanks for taking the time to test it. I think it won't be 
needed for XP x64 as we know it works on XP 32-bit and W7 x64 already.

And are you able to use the exported values (foo, bar, i)?

I think that guys had some kind of GUI in mind, or maybe more specifically 
- some GUI targets, as e.g. html5, etc., being native on target devices. 
Myself, I would support and sponsor bit a View plus VID3 transition 
towards the Red, but not sure if someone would pick up. So - in the 
end, some "GUI" might appear ....

It's important to distinguish between View and VID, and I assume 
that any kind of graphics engine can be implemented. I would personally 
like a View/VID like clone without the design flaws, but there is 
probably no hindrance in using GTK+ or whatever.

I'm not sure it's useful to repeat this, because people seem to wipe 
their memory and start over the discussion, but:

- Red's roadmap includes binding to native GUIs. That means there's 
supposed to appear a binding for every platform Red is ported to. 
The intent is to try to create one dialect that would be able to 
drive all these native bindings. This would be a common denominator 
dialect.

- Some of those GUIs are actually cross-platform, such as GTK and 
Enlightenment. so those can figure as a cross-platform GUI. They 
could offer more functionality than the common denominator dialect 
but still be cross-platform.

I'm not convinced with the native GUI bindings. A lot of framework 
have tried it too and it's a lot of work to bridget the gaps. Or 
if the least common denominator is becoming to small the native look 
& feel won't help since the app feels crippeled anyway: Why don't 
they use widget ABC here?

Porting / binding R3 GUI to Red shouldn't be hard to do. It's a lot 
of work but we would get a simple and fast to use GUI. One of the 
major USPs of Rebol. I don't know any other simple to use interpreter 
that gives you a GUI out of the box. And, in these app days, it's 
no longer so critical to support native look & feel in all aspects.

Robert - it is just that talking to Cyphre, he was eventually interested 
in a "port", which would be more of a new implementation, supporting 
more advanced stuff in the backend (as switching targets, hw acceleration, 
etc.), and doing it in his free time the initial guess was 12 months. 
Such product would be surely cool, but it seems to me, that it could 
be just the second stage. 


In first stage, I would prefer having windowing/events plus AGG ported 
(still fast enough for many things, I don't understand the obsession 
about the speec, well, apart from devices lacking float support, 
here, AGG would be really slow). Such step could be done in 2-3 months 
of work? Then ppl could start port R3 GUI to it ....

That's fine; it would be one of the supported cross-platform GUIs, 
next to Enlightenment and GTK. Of course, you'll have to make sure 
you have the rights to use the R3 GUI

About the native GUI option (using only what the OS provides), I'm 
pretty confident that the minimum common should be enough to cover 
most needs for business apps, I will do a prototype for the Red IDE. 
Having a free drawing x-platform canvas, for games and non-native 
GUI would also be needed, SDL seems to be the best backend for that 
AFAIK (that gives us also OpenGL for free).

I have this code for Red/System DLL:

f-1423181: func [a [integer!] return: [integer!]] [a + 1]
f-10584225: func [a [integer!] return: [integer!]] [a - 1]
#export [f-1423181 f-10584225]

and this code in R2 to load it which throws error:

>> lib: load/library %builds/routines.dll

>> foo: make routine!  [a [integer!] return: [integer!]] lib "f-1423181"

>> bar: make routine!  [a [integer!] return: [integer!]] lib "f-10584225"
** Access Error: Cannot open f-10584225

Is it Red/System or R2 problem?

How am I supposed to cross-compile a Windows DLL from Linux? I'm 
getting an internal compiler error with any combination of -dlib, 
-t WinDLL and -t Windows

From a non-Windows system, you have to use -t WinDLL target (and 
just that).

There are short and long switches, -dlib is already a bit too long, 
so it might be reduced further in the future, the long version is: 
--dynamic-lib.

New Twitter message from Doc: "Making good progress on Red language 
layer, got a stable core compiler now and minimal datatypes set"

Maybe there is no original screenshot and I remember it wrong, but 
the kernel exists and you can test it. It's Linux 0.00 and the major 
feature is switching between two tasks that print A and B in the 
console:

http://gunkies.org/wiki/Linux_0.00

No easy way AFAICT, even if the big picture is there, you need to 
think and take decisions for a lot of details every day, even if 
you try to isolate parts, you always end up with some conflicts to 
solve both at the design and implementation levels.

Thanks for the link...if I take Linus' code and add it to Red/System, 
I should be able to output a VM image directly from a Red/System 
program, no? ;-)

Doc - what I noticed (and please don't take it personally) is, that 
sometimes you miss on how R3 was designed and solved some areas. 
Maybe you could talk to BrianH, who knows lots of things about what 
was/is good about R3, so that you can take similar path? E.g. Unicode 
support took Carl 2-3 months ...

For Red, the bootstrap stage is really costly, I'm really impatient 
of getting rid of the REBOL part and only have Red code.

Pekr: thanks for the advice. :-) I haven't followed very closely 
the developpement of R3 nor I have ever wrote R3 code, so I'm not 
aware of all the reasons for some design decisions. That's why I 
ask when I need to. AFAIU, R3 was designed to solve R2 issues. I'm 
building Red from scratch, so I don't have legacy issues (so far) 
to deal with, I have more freedom than Carl with R3 and I intend 
to use it. They are some parts of R2/R3 design that fit well my plan, 
so I use them as inspiration, but there are other parts (especially 
in R3), that I am not fan of. Also, do I need to remind you that 
Red is compiled while R3 is interpreted? These are two different 
models which require different trade-offs.


The difficulties I have to deal with in Red (both design and construction 
process) are inherent part of any non-trivial work to build something 
new and that's my role to solve and overcome them. The best way others 
can help me are by pointing out errors or inconsistencies both in 
the design and implementation.


Wrt Unicode support, I should be able to say in a few days how long 
it will take to support it. I doubt I  need as much as 2-3 months, 
but anyway, nobody but Carl knows what he had put in, and exactly 
how long it took him. ;-)

I am glad that you are doing the Unicode part now. Better support 
it sooner than later. Back to 2008, I was one of the three Unicode 
testers for Carl, and I found many bugs and reported them back to 
Carl before he released it to the public.

There is a bit that is worth learning from R3's Unicode transition 
that would help Red.


First, make sure that strings are logically series of codepoints. 
Don't expose the internal structure of strings to code that uses 
them. Different underlying platforms do their Unicode APIs using 
different formats, so on different platforms you might need to implement 
strings differently. You don't want these differences affecting the 
Red code that uses these strings.


Don't have direct equivalence between binary! and string! - require 
conversion between them. No AS-STRING and AS-BINARY functions. Don't 
export the underlying binary data. If you do, the code that uses 
strings would come to depend on a particular underlying format, and 
would then break on platforms where the underlying format is different. 
Also, if you provide access to the underlying binary data to Red 
code, you have to assume that the format of that data can be corrupted 
at any moment, so you'll have to add a lot of verification code, 
and your compiler won't be able to get rid of it.


Work in codepoints, not characters. Unicode characters are complicated 
and can involve multiple codepoints, or not, but until you display 
it none of that matters.


R3 uses fixed-length encodings of strings internally in order to 
speed things up, but that can cause problems when running on underlying 
platforms that use variable-length encodings in their APIs, like 
Linux (UTF-8) and Windows/Java/.NET/OSX? (UTF-16). This makes sense 
for R3 because the underlying code is compiled, but the outer code 
is not, and there's no way to break that barrier. With Red the string 
API could be logical, with the optimizer making the distinction go 
away, so you might be able to get away with using variable-length 
encodings internally if that makes sense to you. Length and index 
would be slower, but there'd be less overhead when calling external 
API functions, so make the tradeoff that works best for you.

If there are parts of R2 or R3 that you like or don't like, don't 
assume that they are part of the design. There's a lot of stuff in 
there that doesn't match the design, is buggy or unfinished. Also, 
for R3, don't assume that only Carl knows the design. He worked with 
others, discussed his design with the other contributors. There's 
some stuff which only he can answer though, and some design decisions 
that weren't resolved, let alone implemented.

The concurrency model was not fully designed, for instance, and almost 
completely not implemented.

However, the part of the concurrency model that was designed so far 
affected the design and implementation of the system model and module 
system. You'd be surprised how much the module system was affected 
by the system, binding and interpretation model of R3; very little 
of its design and implementation was arbitrary. You might be able 
to get the syntax the same for Red's module system, but given the 
different system/binding/execution model there wouldn't be much of 
the implementation in common.

I am for sure no expert regarding unicode, but as red is a compiler 
and open source, why not not add flags that the user has to choose 
which unicode/string support he wants; either flexibility, but of 
cost of speed or no unicode support, then he  has to do the hard 
work by himself

One hypothetical advantage you have with Red is that you can make 
the logical behavior fairly high-level and have the compiler/optimizer 
get rid of that at runtime. REBOL, being interpreted, is effectively 
a lower-level language requiring hand optimization, the kind of hand 
optimization that you'd want to prohibit in Red because it would 
interfere with the machine optimization. This means that, for strings 
at least, it would make sense to have the logical model have a lot 
of the same constraints as that of R3 (because those constraints 
were inherent in the design of Unicode), but make the compiler aware 
of the model so it can translate things to a much lower level. If 
you break the logical model though, you remove the power the compiler 
has to optimize things.

sqlab, it would make sense to have the user choose the underlying 
model if you are doing Red on bare metal and implementing everything 
yourself, or running on a system with no Unicode support at all. 
If you are running a Red program on an existing system with Unicode 
support, the choice of which model is best has already been made 
for you. In those cases choosing the best underlying model would 
best be made by the Red porter, not the end developer.

That's not as hard as it sounds. There are only 3 API models in wide 
use: UTF-16, UTF-8, and no Unicode support at all. A given port of 
Red would only have to support one of those on a given platform.

So far, my short-list of encodings to support are UTF-8 and UTF-16LE. 
UTF-32 might be needed at some point in the future, but for now, 
I'm not aware of any system that uses it?


The Unicode standard by itself is not the problem (having just one 
encoding would have helped, though). The issue lies in different 
OSes supporting different encodings, so it makes the choice for an 
internal x-platform encoding hard. It's a matter of Red internal 
trade-offs, so I need to study the possible internal resources usage 
for each one and decide which one is the more appropriate. So far, 
I was inclined to support both UTF-8 and UTF-16LE fully, but I'm 
not sure yet that's the best choice. To avoid surprizing users with 
inconsistent string operation performances, I thought to give users 
explicit control over string format, if they need such control (by 
default, Red would handle all automatically internally). For example, 
on Windows::

    s: "hello"		;-- UTF-8 literal string

    print s		;-- string converted to UCS2 for printing through win32 
    API
    write %file s	;-- string converted back to UTF-8

    set-modes s 'encoding 'UTF-16 ;-- user deciding on format
or
    s/encoding: 'UTF-16

    print length? s	;-- Length? then runs in O(1), no surprize.



Supporting ANSI as internal encoding seems useless, being able to 
just export/import it should suffice.

BTW, Brian, IIRC, OS X relies on UTF-8 internally not UTF-16.

Be sure to not forget the difference between UTF-16 (variable-length 
encoding of all of Unicode) and UCS2 (fixed-length encoding of a 
subset of Unicode). Windows, Java and .NET support UTF-16 (barring 
the occasional buggy code that assumes fixed-length encoding). R3's 
current underlying implementation is UCS2, with its character set 
limitations, but its logical model is codepoint-series.

IIRC Python 3 uses UCS4 internally for its Unicode strings, with 
all of the overhead that implies. UCS4 and UTF-32 are the same thing, 
both fixed-length.

If you support different internal string encodings on a given platform, 
be sure to not give logical access to the underlying binary data 
to Red code. The get/set-modes model is good for that kind of thing. 
If the end developer knows that the string will be grabbed from something 
that provides UTF-8 and passed along to something that takes UTF-8, 
they might be better off choosing UTF-8 as an underlying encoding. 
However, that should just be a mode - their interaction with the 
string should follow the codepoint model. If the end developer will 
be working directly with encoded data, they should be working with 
binary! values.

Got my first real Red program working: 
    Red [] print 1
outputs:
    1


It doesn't look like much, but it validates the compiler + runtime 
from end to end, and at this point, it's really cool! FYI, the native 
PRINT here triggers a FORM (action) on the passed argument. No REDUCE 
yet (not implemented).

Pekr: right, from now on, you can expect daily progress on Red layer. 
I will push the new code soon, I still need to complete it a bit 
and clean it up.


Jerry: the baby looks nice, we'll just have to keep it away from 
junk food and it will grow up well. ;-)

Pekr: "I wonder what the strategy for Red is going to be in regards 
to GC ..."


Currently Red is using a per-OS thread mark-sweep-compacting GC. 
I intend to make it concurrent (maybe parallel) and incremental when 
(and if) possible. The collector is not yet fully implemented. It 
is also possible to easily make it generational if we need it. When 
we'll have big Red apps, we'll profile them and determine the best 
tuning options for the GC.


There's no silver bullet for memory management & GC, you need to 
adapt it to the language specific needs (and they may vary depending 
on the type of application: client-side, server-side, realtime, ...).

Just want to have your advice on a issue I will have soon with Paypal 
and donations: there's a limit of 2500€ per year of reception allowed 
for EU accounts. It is possible to extend it by providing a lot of 
administrative documents to Paypal and even then it's at their discretion. 
Has I moved out of France, I won't be able to complete this requirements 
(and Montenegro is not supported by Paypal). So suggestions are welcome 
on how to keep receiving donations in a easy way for donators?

They're still hacked now and then, but there are ever more. Here's 
a market share list:

BitInstant is doing interesting things, giving out Bitcoins in stores 
in the US, Russia and Brazil, and claiming to introduce a Bitcoin 
Master card in a few weeks:

Well who is issuing them, with what authority and what fundamental 
value? I cannot see this, whereas the state has the authority of 
the land where we live and foods are produced to base money value. 
(Second life 'money' was a hype.)  But that is a discussion for outside 
this Red message group.

Doc, Services like Plimus or Fastspring probably have option to get 
you wire transfer or at least check (or some send you prepayed visa). 
Not eactly meant for your case, but if you don't find anything else. 
You could (I hope) make a "products" with them and then. I used them 
for similar transactions when nothing else could come into play. 
Paypal wasn' working here either and even now it's very clunky to 
retrieve the $$ from it.

BTW, I might also post soon a description of a redbin format (similar 
concept as Carl's rebin). The overhead and footprint of the Red boot 
script (loading all the words and their values) is not negligeable, 
so I may switch to redbin option sooner than later.

I will push the current Red compiler & runtime code base tomorrow, 
still some more code cleaning to do. It will contain the Red boot 
script with all base definitions (currently actions, ops, a few natives 
and a few char! values) and a compiler front-end (similar to %rsc.r).


Don't expect too much, only MAKE has been fully implemented and FORM 
on integer! values only. PRINT is the only native currently.


This is not the first Red alpha, but it's a working base we can implement 
the alpha on (basically implementing actions and natives).

Kaj: not yet, there are several ways to integrate Red/System in a 
Red program:


- inlined in Red code: it will be done using a #system compiler directive 
followed by a Red/System block of code. You should be able to use 
it pretty much anywhere. Trivial to implement.


- executed at runtime: using a DO/SYSTEM, but we need the Red/System 
compiler written in Red to be implemented first for that.


- through Red/System exposed functions to Red: this needs a native! 
definition in Red. It needs some intermediary code for supporting 
automatic marshalling/unmarshalling arguments passed between Red 
and Red/System. But it could be added quickly. Red's routine! type 
will use the same approach for mapping imports.

- by directly coding the native! in Red using something like:

    foo: make native! [[<spec>] [<Red/System body>]]

Lot of fun in perspective! ;-)

You'll got it by tomorrow. 


And BTW, the generated Red binary is in the working directory by 
default. ;-)

I will add math ops and basic block actions later today, so we can 
play with it a little. ;-)

Looks like you made some modifications in your existing code before 
updating and you ended up with merging conflicts (most probably you 
have merged two branches).


You should first do a checkout to the right branch, then issue a 
pull.

Two notes:


- when in root directory, where %red.r resides, is there a need to 
specify it in compilation process? do/args %red.r - or do we expect 
more compilers here?


- executable is spilled out into the root too. I would probably use 
the way compatible to red/system, and create /builds subdir?


Or is all above intentional to allow to compile/link from working 
dirs?

*Important*: Red will be distributed as a binary to end users and 
the effect of:

    red script.red
    

will be to compile and run it from memory directly. So the -o option 
will become mandatory in the future for generating an executable 
without running it. During the bootstrapping stage, it is complex 
to support that feature, but it will be implementd as soon as possible.

The main drawback right now to support direct Red script execution 
is REBOL inability to execute native code from memory. The workaround 
would be to provide a DLL to pass the memory pointer and call the 
Red code, but as I aim at a single Red binary, this option wouldn't 
be very satisfying.

and it returns the max in maximum?

Nice features of the new macro support: 


- the replacement in the argument block operates for any block series 
(includes paths types)

- nested macros in macros are resolved


- you can define the argument as paren! instead of block!, and paren! 
will then stay once macro resolved.

Nenad, thank you for the explanation. Good to know even the simple 
test works both ways, and I am a programmer not a tester ;)

I got the redme.md and the license ...

If your `git clone`succeeded, `cd`inside the repo, and do a `git 
checkout origin/v0.3.0`