AltME groups: search

Altme is buggy.

  Graham...........on that I have to call BS!  AltME has less bugs 
  in it that almost any multifunctional application I know of.  It 
  should get a bloody award.

yes, but maybe it would be vital, if FINALLY RT would explain a bit 
a plan. We saw documents about more of community involvement, also 
about how some parts will be opened. But what we never saw were details 
to such a plan. R3 is coming. My understanding is, that is should 
make situation much better, as what does not belong to kernel, should 
be kicked off from Rebol, into module/plug-in, call it whatever ...

Ok. Your call.

SWIG bindings are one-to-one bindings, mapping a C library call to 
a function in the high-level language. This disregards the richer 
ways of expression that are possible in the high-level language. 
As we know, REBOL is especially powerful, and I think it would be 
better to write bindings in a more suitable way

then call it Freebol :-)

To be more concrete: I mean a lib interface that uses the INIT, CALL, 
QUIT structure on the C side. Uses the access to parameters via frames 
and same return concept. And callbacks like done in R3.

It is a potential security hole, but not more of one than assigning 
a function to an object field. It requires the same ASSERT/type call 
to screen for it. Still, it would be nice if it triggered an error 
on evaluation, especially since newbies would benefit from that error 
when they naively try to do a get-path for a function call instead 
of using APPLY or a direct call.

>> buff: copy ""
>> call/wait/output "exiftool img_0033.jpg" buff

I should be able to do that, looks easy enough. I'll call you if 
I get stuck. :-)

GrahamC, thank you for passing this around.  I did get part way to 
a solution, as noted on your site.  Strange as it may seem, I am 
able to get to the network drives if I run a copy of REBOL that I 
download and leave with the name it came with, namely rebol-view-278-3-1. 
 The copy of REBOL that was giving me trouble was the same rebol-view-278-3-1, 
but I had renamed it to rebview to make a desktop shortcut work. 
 I had the name "rebview" in the shortcut so that I would not have 
to change the shortcut if I ever got an upgraded version of REBOL 
with a different name, like maybe rebol-view-279.  So my first problem 
with WIndows 7, REBOL, and network drives seems fixed.  


I still am not to a full solution to my Windows 7 issues.  I have 
some REBOL scripts that use the "call" command to run powershell. 
 Powershell then runs a powershell script to extract stuff from an 
EXCEL spreadsheet, which then is manipulated by the REBOL script. 
 Actually it's a bit messier.  I run a REBOL program launcher on 
the C drive which runs a REBOL script on a network drive.  The script 
on the network drive calls powershell with parameters to make powershell 
run a powershell script.  The powershell script extracts EXCEL data, 
and the calling REBOL script then makes a report of the extracted 
data.  


When I try to do this, the result from powershell is that I am not 
allowed to run scripts on that computer.  I am aware of this feature 
of powershell, and I have done what has worked for Windows XP (set-executionpolicy 
remotesigned).  I can run powershell directly, and execute scripts 
located on a network drive.  When a REBOL script that worked on XP 
calls powershell on WIndows 7, it won't go.  I am not expecting any 
help with this last issue at this time because the "call" does work 
in some cases (call/shell "notepad") (call/console/show "powershell"), 
so I still have several things to try, and if none work I am plotting 
a work-around.

Also try to use the full path. Once I have faced a problem CALL with 
REBOL style file! value. It worked with a windows-style path.

And also have problem with /shell worked on my XP but did not on 
my customers W7.

In your example, you didn't spec the /do-this refinement on the call. 
Probably just a glitch in posting here though.

Maybe do somehing like:

>> keys: make hash! ["a" "b"]
== make hash! ["a" "b"]
>> values: ["b" "c"]
== ["b" "c"]
>> pick values index? find keys "a"
== "b"
>> pick values index? find keys "b"
== "c"

The
	pick values index? find keys
could be put in a nice function to call.

Andreas: "Except that if Red (not Red/System) is to be statically 
compiled as well, that'll make the language quite different to REBOL. 
In fact, I'd assume that except for some superficial syntactic similarities, 
it won't have much to do with REBOL at all." - nevertheless, if Red 
will be a sublanguage of what I call the Data Exchange Dialect, it 
will be a REBOL dialect in my opinion, no matter how limited/unlimited 
it is going to be.

Thanks to Andreas' help, we now have a first experimental support 
for Linux/ELF for Red/System. It's still very limited (basically 
just being able to call a system function with an argument), but 
it's a good start. It should be extended in the next days to support 
compilation of the hello.reds demo script.

Red/System is a C level language, so you can just call C functions

The only thing you have to do to call a C function is to translate 
the defintion of it in the C header to Red/System. It would be possible 
to write a C header parser to automate that process, one of the things 
that SWIG does. However, it would lead to ugly Red function definitions 
that don't make the most of the interface

Agreed with Kaj.
 

AFAIK, it might be possible to interface with C++ at very low-level, 
to be able to instanciate C++ objects and call their methods from 
Red. Same solution for obj-c interfacing, which will be required 
at some point to port Red to iOS.

Another C mistake that shouldn't be emulated is in 14.5. Don't call 
your 8-bit integer "char!", as it doesn't work with multibyte characters. 
Use "uint8!" or "byte!" instead.

Call the boolean type uint1! and be done with it. For a systems programming 
language, 0/1 as valid boolean results makes eminent sense.

I have mixed feelings about it. Pointer arithmetic is considered 
appropriate in a systems programming language if you want to make 
sure from the beginning that it is unverifiable. If you want a safer 
language, C++-style references are better. But the main problem with 
this is the same problem with R2's struct! type: It's too C-centric. 
Many languages other than C support actually passing structures into 
functions and returning structures, not just passing and returning 
pointers (or references) to them. Because of this I found the R2 
FFI model to be unusable to interface with the code that I really 
needed to call, which was as a matter of course never written in 
C.

Or you could call it handle! like R3 does.

considering callbacks are just pointers, its not that big a deal 
to provide the capabilities...  all you need is a way to get the 
address of a function rather than call call it, and you're good to 
go.  this could be achieved easily with get-word notation...

I've only succeeded since a billing snafu caused my email provider 
to delete a year's worth of email, about 5 years ago or so. All I 
missed was the REBOL mailing list, so I just never resubscribed to 
it. Since then, people call or text msg me to tell me they've sent 
me email, or I get it several months later. Paper mail is nearly 
dead for me too.

I saw the commit history so there is a SteeveGit a Peterwood a earl 
this is what you call alot of people are you joking ?

I'm a hudge militant of both the typed variable way (easy to interface 
C libraries) and the untype variable ( code more readable less maintenance 
etc...) This paradoxe tends to push me to imagine a world where the 
software will know what I need what ever the real sturcture behind 
is lets call it predictable type variable. How we do that ? I don't 
know but it seems fun enough to spend some brain cells  thinking 
of that. the idea is realy that interfacing external c/c++ java what 
ever library and maping it to the language innher variable and code 
will be absolutly transparent. (something like the .NET librabry 
browser but easier... Or more easyly we can have both system cohabiting 
side by side on the language schemes

Well, it can't become strictly strongly typed, as a certain amount 
of type breakage is the whole point of its existence. You can't be 
strictly strongly typed if you have typecasting, pointer arithmetic, 
literal pointer values, or the ability to call C code. Red/System 
is supposed to be strongly typed with those rule breakers, in order 
to shield Red itself from those features.

I cringe whenever I see a multi-part statementthat is supposed to 
be taken as one thing that isn't a function call or in a block; all 
of the pointer! [something] statements qualify. Why is the 'pointer! 
word there at all? In the places where types are allowed, wouldn't 
the block be enough? Or is pointer! not a type, but instead a one-parameter 
function that returns a type, that for some reason has a ! on the 
end of its name?

Operators are infix. Prefix is functions. But it might be implemented 
as a special case builtin, which would make it what other languages 
call prefix operators.

Pushed a fix for the missing conversion code on type casting function 
call return value.

The memory you allocate in your input function is returned from the 
function, so it must be freed outside the function, after every call

STRUCT is used to declare literal structures. As all literals, it 
is stored in the data segment of the executable image, you don't 
need to free it as it is not allocated with a malloc() call.

print functions from Kaj's C-library has different precedence than 
ordinary print/prin when you call the red's exe from REBOL using 
CALL/console command.

Which means.. if I have code:

print-1 "int %d" 1
print "hello"

I get in REBOL console:
>> call/console %builds/test.exe
hello
int 1== 0

A long-term solution could be to disable buffering of C's stdout 
stream, using a call to setvbuf(). It requires passing a stream pointer, 
so I am not sure this is doable now.

With the latest series of Red versions, the 0MQ binding didn't work 
anymore due to crashing on a certain imported function call. This 
is now fixed, probably as a side effect of the last few fixes

How do you call AS-MESSAGE?

calls => call

My point was: don't return a logic! statut from functions like RECEIVE, 
rather set a flag and check it after RECEIVE call.

I could call it a port from the R3 binding, but it will be more like 
a rewrite

Ok, it's probably because I don't understand Red completely. At "load 
time", is that when the system starts up? (Maybe comparable to compile 
time.)


FFI is, as I understand it, a way for high-level languages like Python, 
Ruby, Rebol, etc., to load a library at runtime and call its functions. 
Like we do in R2 with load/library and then some make routine! and 
finally call the functions.

R3 uses dlopen/dlsym/dlclose to load R3 extensions, which have a 
clearly defined exposed API (RX_Init, RX_Call).

Well, then I am ok to add that libC init call in Syllable's runtime 
part (runtime/syllable.reds) as long as it doesn't need any other 
OS-specific additions in Red/System.

BTW, this call could prevent Red from working on Syllable as that 
libC init is a blackbox. I especially fear a clash with Red and libC 
thread init routines.

Is 'fixed a function call in the dialect?

I call it Goodbye Cruel World

I mean, instead of having to call it from every user script, it could 
be called as last expression in %GTK.reds source file directly?

I guess a solution could be to implement a 'cdecl attribute support, 
to be able to manually force the right convention. But that would 
make things it a bit more complicated for the GTK binding user. 


Another option would be to define a trampoline function in the GTK 
binding that would call the user callback. That trampoline function 
would be directly (no nested calls) passed as argument to the imported 
function, so the compiler could infer its calling convention correctly.

I don't really see a connection between the function a pointer is 
passed to and the function that will eventually call it

(inside a terminal. for those not so familiar with linux: the first 
two lines are the call of the binary and the resulting output. the 
rest is just platform porn.)

Is there possible something like CALL in Red/System? I expect currently 
"no", so what's the right aproach to it? Map system calls via wrapping 
an OS libary? Do you plan to have something like CALL to have easy 
interfacing along with PARSE in Red level? :-)

CALL support: sure, that's on the roadmap, but it's not a required 
feature in Red/System to implement Red, so not high-priority. I might 
add it if we really need it for a demo though. Anyway, it's pretty 
simple to implement, so I'm expecting some contribution there. ;-)

My C library binding has a basic CALL using system()

It's effectively call/wait. It may help to remember that the binding 
is complete at the ANSI C level

Also, the "Each context-free rule" expression on page 1 of the BNF 
grammar description is not accurate, it would need a specific comment 
for <fixed-arguments-function-call> rule.

if you want to parse function calls into a call tree, you'd need 
some argument delimitations

on the other hand, i'm certain that you can model Red/System's syntactical 
structure with a context-free grammar. it's just that the CST/AST 
would look quite different from other languages (i.e. in that it 
does not explicitly model function call structures)

Oldes, wrap it in a struct. I call those references

Kaj: I gave a new try on making the GTK+ binding work on Linux/ARM, 
I was able to track the crash up to the call to `gtk-append-container` 
from `gtk-window` function. The argument values passed are:

    window: 0006C000 value: 12

which results in a Runtime Error 1: access violation (segfault)

Kaj: I gave a new try on making the GTK+ binding work on Linux/ARM, 
I was able to track the crash up to the call to `gtk-append-container` 
from `gtk-window` function. The argument values passed are:

    window: 0006C000 value: 12

which results in a Runtime Error 1: access violation (segfault)

I am trying to wrap our LED screen control dll. I am not sure how 
well it is defined, as LED Studio and surrounding SW is rather weak 
and sometimes crashes, but I tried in R2, thinking I again reached 
some R2 DLL interfacing limit/bug, and am trying now in Red/System. 
Well, my first attempt to wrap some DLL functions here. So - I can 
turn-on/off led screen, even if I don't set COM port, open-sending-card, 
etc. But when I try to call functions to get e.g. brightness, contrast, 
it crashes. Those funcs are defined as e.g.:

typedef int	 (WINAPI *LSN_GETBRIGHT)();       // 0..100
typedef bool (WINAPI *LSN_SETBRIGHT)(int);
typedef int (WINAPI *LSN_GETCOLORTEMP)(int);//ScreenNumb

typedef bool (WINAPI *LSN_SETCOLORTEMP)(int,int);//ScreenNumb,nColorId 
0,1,2,3


None of above functions work for me, although above code is from 
sources to LEDSet application, where those funcitons work, those 
are just being set via dialog boxes (which I can invoke even from 
Red/System, so those are part of DLL ...

My definitions are:

      led-get-brightness: "LSN_GetBright" [
         return: [integer!]
      ]           

      led-set-brightness: "LSN_SetBright" [
         brightness [integer!]
         return: [integer!]
      ]

      led-get-color-temperature: "LSN_GetColorTemp" [
          screen-number [integer!]
          return: [integer!]
       ]                 


etc. So what coul be causing run time error? I am running on a PC, 
where I don't have internal LED screen communication card. I thought, 
that DLL functionality might check for the screen, can't find it, 
and so the app returns error, which does not fit return value - e.g. 
some error code/string, or a dialog box. But moving the exe to the 
PC where the card is, it i just the same - some functions work, I 
can see LED screen being turned on/off, but those brightness etc. 
don't ....

typedef int (WINAPI *LSN_GETBRIGHT)()


^^ That defines LSN_GETBRIGHT to be another name for a pointer to 
a stdcall function that takes no arguments and returns an int. (WINAPI 
== __stdcall)

extern LSN_GETBRIGHT		fpGetBright	;


^^ That now is the actual "function", although held indirectly as 
a function pointer. So somewhere in a library is a fpGetBright value 
which holds a LSN_GETBRIGHT function pointer.


In C you can directly call that as e.g. `int brightness = fpGetBright();`. 
However, I fear in Red/System it's at the moment not possible to 
perform that call.

Then for each function you have to write a Red/System wrapper function 
and pass it the function pointer as if it were a callback function, 
and call it. There are examples of such constructs in my bindings

Ah, that's only supported in import functions, I think. That's why 
I handle them as integers everywhere, but then you can't call it 
as a function. So game over

What happens when you call the same functions in C or C++?

I haven't try. There are their Ex variants, imo related to dialog 
boxes. In fact I haven't tried anywhere in the source call to those 
funcs. So maybe those are called from dialog boxes.

I wrapped a dialog box call, as DLL can cal e.g. LSN_BrightDlg, and 
it opens in English. When I explicitly call a language setting function, 
later on, set/get brightness still crashes ... I will see moving 
to the PC, where the sending card to LED screen actually is.

#ifdef _AFXDLL

 Enable3dControls();			// Call this when using MFC in a shared DLL
#else

 Enable3dControlsStatic();	// Call this when linking to MFC statically
#endif

That is what I call a protecting C nonsense. We are REBOL, not C, 
period. I am so mad about it, that if there would not be option to 
use print along with block, I would stop using Red/System ...

I am able to disrupt R2 compilation session to the state, where its 
restart is needed. Not a big deal, but maybe you will see something 
obvious. The code causing it is as follows:

print ["led-set-language: " led-set-language 3 lf]


The trouble is, that led-set-language does not return any value (void). 
This is understandable, that 'print has problem with such a clause. 
The error returned was:

Compiling led/led.reds ...
Script: "Red/System IA-32 code emitter" (none)

*** Compiler Internal Error: Script Error : Out of range or past 
end
*** Where: resolve-path-head
*** Near:  [second either head? path [
compiler/resolve-type path/1
]]


Correcting the issue (moving function call away from the print block, 
I get another error:

Compiling led/led.reds ...
Script: "Red/System IA-32 code emitter" (none)

*** Compiler Internal Error: Script Error : Out of range or past 
end
*** Where: resolve-path-head
*** Near:  [second either head? path [
compiler/resolve-type path/1
]]


This error repeats, untill I restart the R2 compiler session, which 
is a proof, that I corrected the source code, as aftern the R2 restart, 
I can get clean pass ...

Right, it should be put before _any_ call to floating point code.

would it be possible to cast import values directly in import clauses, 
to prevent the need to write another wrapping functions? call me 
lazy :-)

The main point is being able to properly call this "beast" from Red/System: 
http://www.msbit.com:82/LSB/booksets/LSB-Core-generic/LSB-Core-generic/baselib---libc-start-main-.html

(TCO = taill call optimization)

I keep getting knocked off. "Call initiation failed"

I wonder if it makes sense to allow REBOL to call try-topaz.html, 
although it would be calling JS code? Then you could mix Topaz with 
REBOL for tests, etc.

but, i guess you can use CALL to run node.js, or you can get node.js 
to listen to a tcp port and connect to it from REBOL, etc.

Is there a call-in interface available, meaning I can embed w-l in 
other programs?

Regarding your thesis I guess you have something like an integrated 
db or a special datatype for permanent storage too..

Q: We already know that your physics background influenced the new 
complex numbers datatype. Should we expect further progress of this 
kind (physics/science)?

A: After pointing this language out to a couple of friends from university, 
I was quickly asked to give scientific examples, like making a Lorentz 
attractor. There will come examples like that. Also I have some contacts 
at the Niels Bohr Institute (Copenhagen University), that I would 
like to show the language to and see, if we can create some projects.


Q: How long has this been in the making in general & how much time 
have you spent programming it?

A: I started R&D late March 2009. In March 2010, I had >7'000 lines 
of C. Then I took almost a year break from World and started up again 
Spring 2011. I have used much time on it this year (2011). So I've 
used 1-2 years effectively, I guess.


Q: Is there a way loading and interfacing pure object files, how 
about callbacks?

A: I don't have much experience in this area. Two of the closed alpha 
testers have looked at interfacing with sqlite3, which uses callbacks 
for some stuff. I would say, it doesn't work 100% yet, but it's being 
worked on. I need to see examples of loading and interfacing with 
pure object files to judge, how much of such functionality should 
be in World.


Q: Wouldn't it be useful to treat the kwatz! type same way as binary! 
so you don't need to always convert it? I mean, all functions that 
are able to take binary! arg should be able to use the kwatz! as 
well...or do you think are there any problems regarding that?

A: I've thought of that and came to the decision, that KWATZ! should 
be treated with some care. Are we always sure, we want to treat that 
data as binary? I need more experience using KWATZ! to judge that. 
Conversion could be fast, if the AS function was introduced, which 
should just change the type without copying.


Q: Is there a call-in interface available, meaning I can embed World 
in other programs?

A: Not yet. Internally I do call World functions from C (to parse 
URLs) by pushing arguments on the VM stack and call the execute_vm() 
C function. I imagine an interface much like in Lua (lua_call), but 
a little more work is needed, before we're there. This is an alpha 
release, so things will change/be added, before we move to beta release.


Q: Regarding your thesis I guess you have something like an integrated 
db or a special datatype for permanent storage too.. ?
A: Too early! :)

Q: What subset of REBOL2 will run without change in World?

A: Uh, ah, hard to tell at this point. When I need new functionality 
in World (because I want to run some of my R2 scripts), I consider, 
if it should be part of World/Cortex or if the new functions should 
go into the REBOL expansion/dialect (%rebol.w). I want World/Cortex 
to be small and compact. The idea with %rebol.w is, that much of 
R2 code could run, after this script has run.


Q: Are there datatype and function comparisons between World and 
REBOL2?

A: No, I haven't documented that ... yet. Maybe someone else wanna 
document that!? But there are differences, like the REBOL decimal!, 
which in World is called real!. And then %rebol.w just include the 
line:
decimal!: :real!
, so REBOL scripts using that will run.


Q: How many people were working on this World? :) Is it just a single 
man project?
A: Yes, just me.

Q: Will there be a GUI?

A: I would really need a GUI for my own work at some point. I have 
ideas, but nothing set in stone yet. And I want World to be open, 
so different GUIs should be possible, also the native GUIs in the 
different OS.


Q: Are you rich enough to buy Rebol Technologies and employ Carl? 
:-)
A: [KWATZ!]

Yeah. I'm also glad, it's faster. That was some of the first tests, 
I did, long before you could call it a language.

John, on range! values, do you envision transparent iteration/lazy 
generation support for them? I use the term 'bounds for what you 
call range! and my 'range is a series with the values filled in (with 
/skip support).

btw, I really like the   call-by-word   idea you show in countdown: 
 2

:) Look at the bottom of the %cortex.w file. You'll see the test 
function and the m function. I just include them for now, because 
I call those two scripts all the time.

Maybe I should call it "Linux32" and hold the 64-bit versions clean... 
So there can be a future "Linux", which is 64-bit.

Block compiled state will be reset by functions such as INSERT and 
REMOVE. And if the block is set to another location (NEXT/BACK with 
call-by-word for example).

Correct. World is not designed to cope with such cases, where words 
changes from functions taking arguments to passive non-function values, 
or if number of arguments changes to a function. To change the behaviour 
of the c block, a compile is needed. So question is, if that compile 
should be executed by a COMPILE call, or if the compile state of 
the block could be reset, and in this case, it would be compiled, 
the next time, it was executed with DO.

Naming pointer-adr, I considered also *pointer, but found it too 
C-like and 'pointer, so didn't quite like the syntax, even if it 
lead the thought to call-by-word.

I also considered leaving pointer-adr out, and let the call define, 
how the routine should be called. Something like:

h: make handle! none
sqlite3-open "test.db" 'h		; notice the lit-word!


But this will slow calling routines down, because the call will have 
to look h up.

As I understand localtime is not thread safe, the thread safe version 
locatime_r requires the address of a tm structure as an argument. 
(Though it returns the pointer to that same structure if the call 
is succesful.


In general, isn't it a better option for strucutures to be allocated 
in World rather than the called function?

Geomol - could you please explain, how wrapping libraries in World 
are done? Call me dumb, but I can't understand it from a website. 
OK, found more in PDF docs. I just wonder, if I always should use 
typecheck? Eg. I wanted following function to return 0 or 1. I tried 
with variou int types on the C side, and integer! datatype on the 
World side. I was receiving very large integer numbers as a result, 
untill I put [typecheck] in there. Maybe I just had incorrect argument 
type on the C side selected?

led: load/library %ledctrl.dll

led-is-power?: make routine! [
   [typecheck]
   led "LSN_IsPower" []
   uint integer!
]

World is 64 bit. If you don't specify typecheck, it assumes the return 
value to be a 64-bit integer, e.g. sint64 or uint64 in C and integer! 
in World. If the return value of the C library routine isn't a 64 
bit integer, you need to specify typecheck to get it converted from 
8, 16 or 32 bit to 64 bit. If the return value of the C library routine 
is 64 bit, typecheck isn't necessary, but can still be used, and 
it will slow the routine call a bit.