AltME groups: search

Oldes - according to his mendoradio blog, he still is http://mendoradio.wordpress.com/
 .... noone knows though, when and if ever his new linux related 
job ends, and what does it mean for the REBOL future ...

Legacy code. Our products are R2 based and I want to use the same 
extensions. At the moment I have to handle code differences on the 
C side which I would like to avoid.

What you would be developing is already in R3, so It's a lot simpler 
to just interface R2 and R3. Probably the most straightforward option 
for that is 0MQ

To integrate the extension interface into R2 would be a huge task, 
and I'm not quite sure how to get around the lack of extendable objects 
(to build the module system on, since extensions are integrated with 
the module system). Adding the handle! type would be easy; adding 
the command! type would be a bit harder.

It would be rather difficult to fake the command! type if you are 
doing the library method, but you could use a similar method to that 
used to fake the closure! type. I am not sure how much you could 
replicate the value marshalling, and callbacks would likely be impossible.

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.

And then back to a handle! if it's going to be passed back to Red 
code.

No mistake, that is a correct way to see the separation between Red 
and Red/System.

Cool. That will allow us to reuse some of the the reasoning about 
code that has been made about those situations in other languages, 
and tweak the model to learn from their lessons.

I was thinking about struct parameters to functions. If C doesn't 
allow struct parameters and return values, only struct references 
or pointers, then Red should follow that model when declaring functions 
with the cdecl calling convention, and similar restrictions for stdcall, 
fastcall, etc. Then when we need to support other calling conventions 
that do support passing actual structs as parameters, we can just 
add to the list (pascal or Delphi, for instance).

BTW, I was thinking these last days that I maybe should allocate 
a week before starting the work on Red's compiler, to implement an 
experimental JVM bytecode emitter (and a .class file format). The 
reason for that is to have a 2nd emitter (in addition to IA32) that 
is addressing a very different architecture. This should help make 
a cleaner abstraction layer for upcoming emitters (especially those 
not written by me).

A good calling convention to add would be JNI, for Java and Dalvik 
code. We would have to reverse-engineer the behavior of the C macros 
and types that implement this in the JDK and NDK.

Never heard of JNA. Java and Dalvik both use JNI.

I tested the new section headers on Syllable Desktop. We're a step 
further, but it doesn't work yet. It doesn't complain about them 
missing anymore, but about read-only and write sections overlapping, 
which our loader doesn't support, if I remember correctly

Kaj: thanks for the report. I thought we were cleanly separating 
RO and RW sections in two different LOAD segments...maybe the flags 
are not correctly set in sections (or in section headers). I'll give 
it a look this weekend if Andreas has not the time to fix it before.

Another function is the math EXP function. It just raises the number 
e to some power (the argument). A language like C (and probably most 
others languages) has this function (in the math library though). 
Probably to make code faster, but it can easily be defined as a REBOL 
function, right?

I just woudn't want it to take over the topical discussions related 
to actual Red implementation and use.

With e defined, the hyperbolic cos, sin, tan, etc. are easy (REBOL 
doesn't have these), and maybe also normal cos, sin, tan!? At least 
for complex numbers, but not so sure about reals. Maybe a better 
mathematician can tell us that? Ladislav?

For now in R3 there are some restrictions about the kind of functions 
you can make an operator from - number of arguments and such. It 
is planned to eventually relax one of the restrictions, and allow 
function!, closure! and command! functions to be used. However, even 
in Red there will likely need to be a fixed format to the arguments 
of such a function: 2 args with no refinements, the first arg corresponding 
to the left side and the second arg corresponding to the right.

Yeah, operators with only 2 arguments sounds like a good idea. More 
and it fastly become too complex leading to confusion.

brian, can we already build the FROM as an op in R3?  I've tried 
using the to-op and I can never get it to work.

Exactly, safer and cheaper to do with a compiler.

If C doesn't allow struct parameters and return values, only struct 
references or pointers

C allows struct values as parameters and return value.

Are there size limits to these parameters and return values?

i.e. if your struct fits in two machine words, some (x86) compilers 
use eax and edx to return it

Would that behavior be standardized for a particular calling convention 
and ABI? For instance, that seems like the kind of thing that would 
have been standardized by stdcall or fastcall, but maybe not for 
cdecl or pascal.

Kaj: "I tested the new section headers on Syllable Desktop.

memmap_instance() RO overlap RW (08048000 + 00001000 -> 08048000)"


besides the entry point address being a problem, this could also 
be due to segment alignment, which we basically ignore, at the moment. 
could you try changing "page-size: 4096" to "page-size: 1" and see 
where that gets us?

Judging by the tables, it looks like passing and returning structs 
in C is better done in internal code than in exported functions. 
There are too many exceptions and fallbacks.

The difference may be between a variable and a constant

This test code compiles and works OK.

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

though in rebol not having type for vars and () for function arg 
submition, make difficult to identify var content  distinguish var 
from function ... Maybe then  a syntaxique item like th e $ in php 
for vars or the @ in ruby for tables would be an interesting point... 
Sorry I try to think about rebol syntaxe structure like someone seing 
it for the first time

Shad, typed variables with type inference handles the readability/maintenance 
problem pretty well, which is why several statically typed languages 
have been retrofiting type inference into them recently. Fortunately, 
Red is planned around that from the start.


Your "predictable type variable" proposal (I don't know the standard 
term either) sounds useful. Many languages do this through reflection 
facilities, but that kind of thing requires dynamically typed variables 
at least as an option if you are going to use the reflection facilities 
of the language you are interfacing with - this is necessary for 
C++ at least because there isn't a shared standard for encoding that 
information in a static way. It would be more useful for integrating 
with .NET or CORBA objects, since direct field access is prohibited 
anyways for those so there's no extra overhead in the field access 
itself, just in the runtime discovery, and ahead-of-time static compilation 
has shared rules that work on a binary standard.

i was thinking about syllable server. what has to be ported on it 
to arm? if u ubuntu runs on this thing, then the kernel and c compiler 
shouldnt be an issue

We've had a pattern of people who came to our mailing list shouting 
enthusiastically that they had found out that the "GNU C compiler" 
would compile to PowerPC or something, that they would compile Syllable 
to it over the weekend and report afterwards

And if you don't know all the parts intimately, they can easily pose 
a big problem to a particular developer

It can easily take me half a year to create a next version of Syllable 
Server, and that's on the same architecture

I have updated the 0MQ binding to the latest Red version, and moved 
it to a Fossil repository:

From sources: "libzmq.dll" cdecl [  ; stdcall for Windows? => should 
be cdecl, stdcall is used in Windows DLL (and rarely by C libs).

I found the same info that Windows system libraries use stdcall, 
but that MSVC defaults to cdecl. I had been compiling the binding 
with stdcall, and both work. I standardised on cdecl and retained 
the comment for the moment being

I mean, don't use the word 'handle! as an alias because it will likely 
be a built-in datatype in Red, and in all Red/System functions and 
datatypes exported to Red.

Keep in mind that there is no bounds-checking for Red/System's pointer 
type, and Red/System has typecasting (rather than conversion). Neither 
of those would be allowed in Red itself because of typesafety issues. 
Red/System will be like the unsafe code of C#.

That would be just a little code, and it's obvious that you have 
to develop your programs to stay in sync with a language that's in 
alpha status

Yup. But it's also good to warn them of planned developments once 
they're definitely planned, and this one is pretty well established.

Basically, Red's handle! type would be the same as R3's handle! type. 
Opaque value that is pointer sized, but can't be used as a pointer 
without typecasting, and no arithmetic possible. No conversions to 
other datatypes either in typesafe code.

And since it isn't defined in the runtime now, I have to write it 
myself until that time

The main thing is that it needs to be defined as *non-dereferenceable* 
and *no pointer arithmetic allowed*, so if Red/System's equivalent 
of the void pointer is so restricted, that will do. If dereferencing 
or pointer arithmetic is allowed on Red/System's void pointer type, 
that needs to be fixed asap.

In a strongly typed language, which even Red/System is, dereferencing 
a pointer means getting a value back that is of a known type; pointer 
arithmetic means adding in increments of the size of that type. A 
void pointer references nothing, and that nothing has no size. You 
must be required to typecast to another pointer type explicitly if 
you want to dereference the pointer, or to know how much to increment 
or decrement it.

The difference between Red and Red/System is that such typecasts 
are possible in Red/System.

Right, there need to be pointers to other types. And support for 
more types, for that matter.

It is not currently planned *by Doc* to have Red/System be a complete 
language, since he only needs it to access a few system libraries 
and implement the Red runtime. He's said that others are welcome 
to contribute the necessary changes to make Red/System a more complete 
language.

If you want to use Red/System as-is to do more advanced stuff than 
that, then go ahead and break the rules. Or better yet, add the features 
you're missing.

If and when that happens, I'll update my programs to be compliant, 
as I'm doing now

You wanted to know if the appointed error locations are correct. 
That seems to be alright, and the error for a struct is nicely descriptive, 
but an error for a function definition is rather unspecific:

Oh wait. I have to use a block for #define, and then it works. But 
not ALIAS

And the error output for a function starts at the offending parameter, 
so that's actually pretty good, but it's not obvious

I just pushed a new commit that reverts back some of the changes 
I did for aliased types yesterday, and fixes the compiler errors 
reported by Kaj.

So, #define is the way to go to rename existing types and ALIAS is 
reserved for struct! only (it allows to circular references that 
couldn't be done using macros).

I know it zas made for Illumination software creator and was a good 
enightenment for it

Kaj: I pushed a few fixes and changes on ALIAS support, it now behaves 
strictly as described in the specification. For the 0MQ binding, 
you need to replace [struct! message!] occurences with [message!] 
to make it compilable with the new version.

Processed your changes, and indeed it builds again

In the spec in 4.5.5, shouldn't the child structs gift/first and 
gift/second be created individually (and assigned to the struct pointers 
in gift) before their members can be assigned?

It would also be good to make it clear that the integer! pointed 
to by p needs to be separately allocated (presumably by foobar and 
GetPointer)

4.5.5: yes, you're right, the example is missing gift/first and gift/second 
proper initialization.

Not that I'm testing Server on 486, and the utility is dubious. But 
Red will be suitable for embedded systems, so there may be a good 
niche in 486 systems-on-a-chip

Weirdly enough, if the ! was gone from that keyword for the typed 
pointers it wouldn't trip me up because it would look like the subsequent 
block is part of an expression. Then the pointer! word would refer 
to an untyped pointer (void pointer) on its own with no block needed, 
though I would prefer handle! instead for R3 compatibility, and to 
make it more visually distinct from pointer (without the !).

Well, it is a bit late now as Red/System implementation is reaching 
its end. I am trying to stick as close as possible to the REBOL syntax 
we are used to, if you have better propositions for the syntax, I 
am ready examine them, but I would like to finish on Red/System and 
start working on upper layers, unless you want me to polish Red/System 
for the next months and start working on Red 6 months later than 
I planned?

I would like also to remind you that Red/System will be re-implemented 
entirely in Red at some point, so we'll have a second chance to fix 
design and implementation issues/limitations if necessary.

The pointer! [...] syntax does make sense as a shortcut for struct! 
[value [...]] in function specs - that type equivalence was the important 
part of the earlier argument, not syntax issues. The only place that 
the syntax looks weird is in AS calls, where otherwise expression 
rules would apply. I'll look over the specs later this evening and 
see if there's anything really weird-looking.

No, I mean that pointer! [integer!] would be exactly the same type 
as struct! [value [integer!]] - type equivalence between pointer! 
and struct!. This would make the pointer! type a syntactic sugar 
shortcut for a subset of the struct! type. That is the semantic portion 
of what you wanted me to write down for you in a google groups post 
so you could refer to it when you were implementing that suggestion. 
There were also syntactic issues, but those don't matter as much.

I've been busy lately so I haven't read the latest couple spec drafts. 
Must catch up and comment, quick before you finalize things.

I will push new specification changes and fixes tonight. I have added 
a type casting matrix for all possible type combinations. I am currently 
  implementing the missing cases.

Do you make a distinction between implicit and explicit type casting? 
Does Red/System have any implicit type casting at all yet?

Yes, it does an implicit type casting for math and bitwise operations 
on the second argument.

So far I have bound 25 functions and written two higher level wrappers

I know, but this is a solid solution, and there are 26 more functions 
:-)

I've bound all memory management functions, most of the string processing 
functions and a few system interfacing functions

Looks good and will also act as a good example.

Kaj, thanks for the contribution. I have planned to wrap some of 
the memory manipulation functions too as soon as I finish the work 
on aliasing and type casting.

I thought about implementing PIC support first and testing it using 
Syllable's executables.

BTW, I tried installing Syllable on VMWare 7 and it failed to recognize 
the disk controller (I tried every possible disk modes and Syllable 
boot mode). I might have not picked the right image to install...I'm 
retrying right now with this one: http://downloads.syllable.org/Linux/i686/systems/Server/0.1/SyllableServer-0.1.i686.VM.7z

hm, kaj, could you try setting
base-address:  -2147483648
and see if that generates binaries which work?

You'r mixing up Desktop and Server. 0.6.6 is Desktop, X11 is Server, 
which is Linux

If you want to run Desktop, 0.6.6 indeed has a ready VMware image. 
On the other hand, the live CD you have has some enhancements. Such 
as R3 and the cURL binding :-)

Desktop can only run ORCA, Boron and now R3. That's why I've never 
been able to use REBOL in the past decade

Server has R2/Core, Boron and ORCA onboard

Ok, so I need to compile Red/System scripts elsewhere and copy them 
in Syllable.

I've compiled the 0MQ binding, and that isn't ported to Desktop yet

I've compiled empty and hello now

Kaj: 
I tested the new section headers on Syllable Desktop.

memmap_instance() RO overlap RW (08048000 + 00001000 -> 08048000)"


besides the entry point address being a problem, this could also 
be due to segment alignment, which we basically ignore, at the moment. 
could you try changing "page-size: 4096" to "page-size: 1" and see 
where that gets us?"

and change back page-size to 4096 before that

I've taken over Andreas' changes, corrected the runtime syscall, 
and uploaded new empty, hello, reply-server and request-client

GDb and strace are treated in here:

You'll still need prolog and epilog syscalls, and I think Doc wants 
to minimise libc usage

requires libc.so.6, calls puts and exit

Implemented block i/o and status handling

Implemented low level byte and line i/o

The article is very well written and it is the best introduction 
to Red I have seen so far.

Nah, yours are better. :-) I'm just placing it in a context for Syllable 
and OSNews readers

Implementation constraint for + and - to support pointer/struct/c-string 
arithmetic without having to explicitly cast the 2nd argument. So 
to avoid having a different rule for * , / and //, I chosed to let 
the implicit casting occur on all math operators. But as the implicit 
casting is reducing the safety of expressions, I might make it more 
strict than it is currently.