AltME groups: search

Or just send me a copy of your DLL at [nr-:-red-lang-:-org], I should be 
able to quickly see what's wrong.

Works fine here: 

>> lib: load/library %builds/temp.dll
>> f1: make routine! [a [integer!] return: [integer!]] lib "f1"
>> f1 123
== 124

Guess what. That works:

c:\code\Red\red-system\builds>loadlib.exe temp.dll
error: 0
hModule: 268435456
error: 0
&f1: 10001a85
124
error: 0

So it's probably really a bad day here for coding/testing :)

The only cause I can think of is because the DLL produced by Red/System 
are not (yet) relocatable, they can be conflicting with other loaded 
DLLs (but shouldn't happen with a fresh REBOL session), or are triggering 
something in anti-virus or Windows security sub-systems.

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

I don't get any output, just a question if I'm allowing to open a 
port for read/write ...

You mean the C source code I posted, I guess it's a Unicode main() 
from VisualStudio, you can safely replace it with a standard main().

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

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.

You need to checkout the branch in a new local folder if you want 
to have several branches of code at the same time (I never had that 
need as switching between them is done in a couple of seconds).

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?

Ah ok, the info you get there are Windows file metadata (probably 
a resource section in the file), these are not from DLL core structures.

(which has also a handy disassembler)

otoh who knows, how reliable is R2's DLL interface? Maybe it checks 
on some metadata, e.g. a language? It seems only on Czech Windows 
is the problem ...

Gregg: could you try to load this DLL using R2: http://box.lebeda.ws/~rebolek/temp.dll

lib: load/library %temp.dll
f1: make routine! [a [integer!] return: [integer!]] lib "f1"

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.

MagnussonC: you need to define the routine! first:

lib: do load/library %temp.dll
f1: make routine! [a [integer!] return: [integer!]] lib "f1"
f1 123

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

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 don't recall - did REBOL core only have library support if you 
had a licensed sdk?

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

Pekr: be sure to get the lastest commit (pushed a minute ago).

Yes...you need to test with a different source:

Red/System []


on-load: func [a [integer!] b [integer!] c [integer!] return: [logic!]][
	print-line "on-load executed"
	true
]

f1: func [a [integer!] return: [integer!]][a + 1]

#export [on-load f1]

Would be nice if more ppl on Windows could test it, so we maybe get 
a clue why it doesn't load on 
some configs.

Pekr: are you running an admin session on W7? (or a user with admin 
rights)

When I ran my successful test, I ran as a user not admin.

same problem here

>> read %temp.dll

== {MZ€^@^A^@^@^@^D^@^P^@ÿÿ^@^@@^A^@^@^@^@^@^@@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@€^@^@^@^N
^_º^N...
>> lib:  load/library %temp.dll
** Access Error: Cannot open temp.dll as library
** Near: lib:  load/library %temp.dll
	
but
>> load/library %shell32.dll
>>

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

I suspect about the different msvcrt.dll versions.

AdrianS: "did REBOL core only have library support if you had a licensed 
sdk?" - yes licensed Core (Core/Pro) support library.

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?

Anyway, it should load even on XP, so I really suspect a relocation 
need for boxes with older msvcrt.

I have changed 'on-load definition in last commit:


You can now _optionally_ defined 4 callbacks when producing a DLL:

 on-load:        func [hModule [integer!][...]
 on-unload:      func [hModule [integer!][...]
 on-new-thread:  func [hModule [integer!][...]
 on-exit-thread: func [hModule [integer!][...]

 hModule is a handler on the DLL instance.

They don't need to be added to #export block.

I tried to put a msvcrt.dll > 7600 into the same path as temp.dll, 
into system32 or into the rebol home path. still no success

I just tested on a XP/Pro on VirtualBox, msvcrt.dll version is 7.0.2600.2180, 
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

Well, I am ok with tortoise, I just somehow can't easily swith the 
branches, it can't see them ... one option can see dyn-lib, other 
is still seeing a float branch, etc ...

Will try that. I though I will have to do something on the github 
page. I thought it is "watch" which is needed, but it was not it. 
Clone in windows - what a name ;-)

So it's not a msvcrt issue it seems.

With the latest series of fixes, I've finally been able to move the 
SQLite binding into a CONTEXT

This has led to a huge shift in the naming of words. If you had written 
anything on this binding, you need to update your programs

Also, because it needs the latest non-released Red/System, I have 
put the binding changes in a separate developing branch:

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

Pekr & Rebolek: can you give it a new try with latest commit (it 
adds relocation support to DLLs).

Red/System []

on-load: func [a [integer!]][
	print-line "on-load executed"
]

on-unload: func [a [integer!]][
	print-line "on-unload executed"
]

i: 56
foo: func [a [integer!] return: [integer!]][a + 1]

#export [foo i]

Try now:

foo: make routine! [a [integer!] return: [integer!]] lib "foo"
foo 123

>> foo: make routine! [a [integer!] return: [integer!]] lib "foo"
>> foo 123
== 124

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?

Well, if someone would create a plug-in wrapper, we could use the 
aproach for R3 too ...

Easly creating self-contained DLLs with a R2 / R3 interface would 
be a major time-saver.

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)

that's not a microcontroller, right? :-)

But that enables already to build a lot of things, like bridges with 
other languages or VMs.

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 have added a sample program for those who want to play with DLL 
generation:


https://github.com/dockimbel/Red/blob/dyn-lib-emitter/red-system/tests/shared-lib.reds

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.

-dlib option: it's just set the flag to produce shared library instead 
of executable.


-t option: sets a target which is just a handy way to group several 
options together (most options don't have a specific command-line 
switch).

When Windows for ARM will be out, I guess we'll need a few modifications 
to PE emitter to support it. Does anyone know if Windows8/ARM beta 
versions are available somewhere?

So I've got this working:

>> foo: make-native [a [integer!] return: [integer!]][a + 1]
>> equal? 124 foo 123
== true


Still needs some work before publishing, but it shouldn't take long.

Great! :-)

I'll push a fix for the on-* issue in a couple of minutes.

Is Rebols GUI code (view etc) going to be usable in Red? Or is it 
going to something completely different? A while back I think there 
was talk of an dedicated Red editor (Reditor?). Is this still included 
in the roadmap?

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

... but GUI is not a priority right now I think ....

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.

You don't have to accept anything: the roadmap calls for a binding 
to the platform you already work on

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

I could afford. e.g. 50USD/month for that. I know, it does not make 
for a living, but maybe such an effort would be considered by more 
ppl?

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

R2/R3: probable, for the GUI code, it depends how close our VID version 
will be (R3 VID seems to be a good model that we could push further).

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

-dlib just activates the flag for generating a shared lib for the 
systems the compiler runs on.

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

May I suggest that -shared is a more common switch, usually on systems 
using GCC?

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.

A lot of stuff. Just my way of claying a new binding out of an old 
one. We'll see when I encounter some specific situation

Have you tried loading a Red/System DLL with Wine?

I've pushed a fix for the compiler crashing on missing #export.

Thanks. No, I don't have a meaningful DLL yet

The callback attribute is added automatically to a function when 
passed as get-word. But there are some cases where  it needs to be 
manually set, like for the ***-dll-entry-point function from the 
runtime.

Doc, will you extract all the information string of Red source code 
into a file, so I can translate them into Chinese without modifying 
the source code.

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

There are still a lot of details to work on, but the core part is 
there. The bootstrapping does had several complications (like literal 
series handling) that will vanish once we get Red compiler rewritten 
in Red.

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

I should be able to make a "hello word" script in Red in a few days. 
I still have to make some design decision wrt Unicode internal handling, 
that's really a complex part.

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? ;-)

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

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.

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.