AltME groups: search

On my Linux VM, it now performs as fast as C, but I'm not sure how 
accurate is the emulated clock.

from that doc, the osx stack layout looks identical to linux/elf

so osx looks just like linux :)

Okay, libc-init is now working fine for Linux and conforming to Gcc 
ABI. Once again, man has won over the machine, but I wonder how many 
neurons were killed both in my and Andreas brain during the battle...;-)

I've managed to get most of it built, but I don't have much running 
yet. It's certain that I can eventually get it to work on my Linux, 
but I'm not sure yet it will succeed on Syllable Desktop

What? Why not to pack whole 150GB Linux to 400 KB Red executable?

Enlightenment is like Amiga coming to Linux, and also other platforms 
these days

:-) It's only the first steps yet, that are guaranteed to work because 
it's on Linux. The major question is whether I can port it to Syllable 
Desktop

I have tested 0MQ, GTK+ and SDL on both Windows and Linux, no regression.

I've tested almost all binding examples on Syllable and Linux

On Linux, you could also avoid going through strings and use lrint(3)/lrintf(3).

Where I can find the window and linux RED executable?

james - there is no Red yet, just Red/System. And yes, you can kind-of 
create Android apps. But - those are bare-bones linux ARM apps, which 
can run on an Android phone. I tried that on my HTC Sensation. Right 
now, there is no app-store support, nor the ability to link to Android 
API, which would require the JAVA bridge. You can find some info 
here - http://www.red-lang.org/2011/12/arm-support-released.html

How can I 'wait in linux red? Should I wrap something as sleep() 
function?

a "hello world!" written in and compiled by red/system running on 
a raspberry pi:

[pi-:-raspberrypi]:~$ ./hello-reds.arm 
hello from red/system!

([pi-:-raspberrypi]:~$ uname -a

Linux raspberrypi 3.1.9+ #90 Wed Apr 18 18:23:05 BST 2012 armv6l 
GNU/Linux)

In Linux, on your original code, I get:

Syllable Server (Linux):

Ok, but Rebol is better than html5. You write your script and it 
works on MacOS, Windows, Linux, in a browser. "write once and use 
it every where" better than Java.

But in short - Red is going to be compiled language, and it will 
probably get some kind of JIT too, to allow interactive stuff like 
console. Red language compiles down to Red/System, which is kind 
of VM for it. In fact, it is REBOL-like low level wrapper to C, allowing 
some bindings. Red/System apps recently run even on ARM, eg I am 
able to run it on my HTC Sensation. But that's raw ARM Linux, no 
Android API linking yet ....

It doesn't work for me, on Linux

So far, testing with a modified %rsc.r on Linux, it seems to be reliable.

(Testing with R2.7.8 on Linux.)

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.

Doc, this is where we need that screenshot, like the one Linus Thorvalds 
took of the Linux kernel, when he showed it was able to switch tasks 
back in 1991. :-)

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

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.

quick-test is also broken on Linux.

No, I haven't yet tested the Red codebase on Linux, but I will in 
a few minutes.

@szeng: I will look into the Linux issue tomorrow.

On Linux, the executable ends up in the directory of the compiler, 
instead of the working directory

I can confirm the segfault on Linux

I've found the cause of the linux regression, it was this commit:


https://github.com/dockimbel/Red/commit/fabad833b6bb8b82f9efdf4933c18bfd997a863f

Fixing it...

Red doesn't work yet for me on Linux. See tracker

Tests are running fine on Windows with master branch. I've tested 
them successfully with linux/v0.3.0 too. Will tray again with linux/master.

Tests also seem broken on Linux.

The output I'm seeing on both Linux and OS X is the same as on V0.3.0 
before you applied the patch.

The problem is on Linux. I prefer to handle it in the tracker because 
stuff gets lost here

Peter: I can reproduce the issue on Linux, I'm investigating it...

All tests pass on Linux and OS X after latest master branch commit. 
Thanks.

I don't think you should use syscalls. It's not the POSIX interface: 
that is implemented in the C library on Linux, and probably most 
other systems

Well, when CPU I/O instruction will be added, you'll be already able 
to make kernel drivers for Windows or Linux....and an OS is typically 
90% made of hardware drivers.

Jerry: My Windows doesn't support CJK, I'm not sure my Linux VM supports 
those characters too...will try it.

Happy to report that Unicode on Linux with an all-UTF8 setup works 
just fine for me.

but - Red apps is an executable, so theoretically, on systems like 
Linux, maybe it can be piped?

It runs Intel Linux, so it should be no problem, even right now

Kaj: I noticed Unicode characters rendering does not work on my Linux 
ARM running on QEMU. I'm not sure yet why, I'll investigate that 
in the next days.

I'm fixing the Unicode string printing issues on Linux/ARM...will 
post the fixes tonight.


BTW, I've now an ARMHF image installed, so I'll work very soon on 
supporting ARMHF ABI.

It's about dealing with different Linux kernel incompatible ABI for 
float support on ARM platforms. Red/System uses the FPU unit (named 
VFP in ARM family) directly, but when having to pass/receive float 
arguments from libc or 3rd-party libs, Red/System needs to do it 
respecting the installed system ABI, which might be `softfp` or `hardfp` 
(there's a third one, but it's for not a concern for us). 


Currently, Red/System floats are passed using the `softfp` convention, 
so it works only on ARMEL platforms (while ARMHF platforms require 
`hardfp` convention). `hardfp` is a much more performant, while `softfp` 
is for legacy  systems or systems with no FPU unit).

BTW, I've also applied the same fix for callbacks on IA-32 backend, 
so retesting all bindings on Linux/Intel would be needed.

It's all very slow, though. I don't understand why everyone is so 
excited about the Raspberry if they're all running LInux

Linux is pure C, too

Well, but Linux suxx anyway, so :-)

Fixed missing function! pointer dereferencing in ARM backend, all 
my Red tests are now running fine on Linux-ARM backend.

I get a new error on GTK on Linux when it tries to load the Red-48x48.png 
logo:

Other than that, Linux x86 still works

It's helpful to make a conceptual distinction between the host interface 
and the extension interface, even though for R3 they are currently 
related to each other and share a lot of the same code.


For the host interface, the host is the OS (more or less) and provides 
an execution environment that the R3 runtime runs on like a program 
(this is all metaphorical, but I'm sure you get it). The OS in this 
case could be something like Windows, Linux, some microkernel, whatever, 
or it could be an application or application plugin like Eclipse, 
Visual Studio, Notepad++, Excel, Firefox, whatever.


For the extension interface, R3 is the OS, the extension-embedded 
module is the program that runs on the OS, and that program calls 
the extension's native code like a library. The program source is 
returned by the extension's RX_Init function, and that program then 
wraps the native library code. The module source is loaded like a 
normal script (slightly hacked after loading to make it a better 
wrapper), so the script could be embedded in binary data along with 
non-Rebol stuff just like with normal scripts. You could even have 
Red and Rebol scripts in the same file (if they use the same embedding 
method) so you the data the init function returns can be like a Red/Rebol 
fat binary, metaphorically.


Given this, Red could either be (or compile) a host for R3; or it 
could be (or compile) a runtime library that implements the same 
host interface as r3lib, making it a drop-in replacement for R3; 
or it could be (or compile) an extension that R3 is a client of, 
returning R3 code that calls calls the compiled Red code; or it could 
be an alternate extension container, for extensions that return both 
Red and R3 code from the same init function, which would call the 
Red code returned, which would in turn call the same native code. 
The two languages could be integrated at any point in the stack, 
along with other languages.

Btw, you can't run applications for Linux on Unix without a compatibility 
library either. Bringing MS into it is just an insult.

Not like in linux.....

It's already planned to install Linux Mint

Since Darwin and Linux are kernel names, how about NT instead of 
MSDOS? Would Red conceivably run on Windows 95?

I can run the Windows executables under WINE on Linux. Oddly, cURL 
and SDL sound work there, so for now I'll blame Windows 7 for their 
failure there

There are GTK+ and SDL bindings. There will be bindings to native 
GUIs in the future (I consider GTK to be the most native binding 
for Linux and BSD systems)

As Kaj underlined, GTK+ will most probably be the native target for 
Linux.

Well, I don't necessarily like big solutions/libraries. Of course 
it will make sense, if they are already a part of the toolchain, 
e.g. GTK being part of every linux distro, Android, etc. , ditto 
Cairo. So far I could see complaints about AGG not being accelerated, 
and what irritates me about such claims is - we never ever utilised 
full advantage of AGG, yet we complain. And then we are going to 
use crap like Cairo, just becau HW is going to help us. I would rather 
use smaller AGG instead of several times bigger Cairo lib, and orientiate 
myself on HW, which has floating point unit. Before we finish, even 
our small devices are going all to have FPU imo ...

I have to wait to start programming my Raspberry Pi until I actually 
get it from Sinterklaas. After that I can try to test Red on it. 
I watched your presentation on programming in Red on the Raspberry 
Pi. No Syllable yet? WHat Linux did you use on the Rasp again Kaj?

I said it in the video: Raspian, Arch Linux, and my preferred Bodhi 
Linux (based on Raspian)

I would never want my app to look like GTK, easy as that. Maybe because 
I have zero intention to do Linux native GUI app. Linux, in a big 
picture (desktop), is irrelevant. Alway was. Who claims otherwise, 
lives in separate reality :-) Mobile will prevail classical PC sales 
very soon (if not already). Own GUI, for small niche, might be good. 
But - it has to have attractive design. The situation with Saphirion 
was, that the substantially rewritten Carl's engine. Nice enhancements, 
resizing and other stuff. But I NEVER understood, why the look was 
so totally unattractive. You see, Henrik once again claiming the 
old stuff, which was the basic reason of a failure. Design is a separate 
animal, which was supposed to come later, which could be done by 
anyone, which "just" needs material system which never appeared, 
etc. And result for me (as a sigle person)? Carl's GUI desing attracts 
me by some 60% more, just because of look. Once again - look sells 
...

Gregg - my constructive suggestion is to orientiate on the platforms, 
which have a future. Is that an AmigaOS (to which R3 got ported as 
a paradox), is that a BeOS? Is that even a Linux? I would vote - 
Android, iOS, WP8, BB10. If new players with new potential appear, 
let's add them. How many of us would ever need to do a real native 
Linux app? And Linxu, is a big name here.

Pekr: you don't get the right picture. When I mention "native widgets", 
I am mainly referring to the ones provided by each OS, which is what 
most users expect to find in an app for their OS, and what most developers 
wants, is to provide a consistent experience for users. So, actually, 
such approach will be lighter then /View, because the OS provides 
you with everything you need. In the case of Linux, GTK is the main 
standard and it is built-in many distros, so that is the one we will 
probably use for Linux target and you don't need to provide it with 
your app.

Doc, fine - then I'll never use Linux as a desktop - hate it, easy 
as that, so no REBOL/Red apps for me there  ... What I wonder even 
more is, if you would be really able to unify, even in the case of 
Linux - what about e.g. Ubunty, and their Unity? Will it work just 
with GTK? Will such app look native in Ubuntu? Just curious ...

How many of us would ever need to do a real native Linux app?


We are talking about a cross-platform GUI framework, that means: 
write once, run everywhere. Using native widgets from the OS is an 
option, using custom ones (with non-standard look'n feel like /View) 
is another option. So, you write a Red GUI app on whatever system 
you like and your Linux users will be able to run it.

Unless you want to boycot Linux users and prevent them from using 
your Red-based product because you don't like Linux? :-)

I've added executables for all six current Red target platforms: 
Syllable, Linux, Linux-ARM, Android, Darwin (OS X) and MSDOS (Windows)

made good progress over the holiday, powered by turkey sandwiches 
from France.


Prep of C source nearly done. See, not just a dump and run. Sure, 
a few problems came up, but I'm not going to hold up the release 
for them. You can decide.


Grabbed latest git source and built it for this dev box (which did 
not support 1.8 version as bin.)


Once released, I've got a number of notes to write up. Like how to 
quickly port R3. Takes about 5 mins if you know what you're doing. 
Got it up on ARM & MIPS Linux.


Also, I have some goals in mind. Android and iphone, that kind of 
thing. Getting graphics and sound back up. GUI and tinyGUI. A micro-R3 
for smallish embedded systems.

There's a lot you can help with. Delegation, right?

RepRap is not Windows only. Most of the software is developed on 
Java and Eclipse for Linux and Windows, with some versions available 
for Mac

Congratulations, jerry.

@Kay: RebRep is tied to Windows because I don't have a working linux 
box. I have tried to install Kubuntu 12.04 on an sdcard but it stops 
at the login where I don't know what to write since the most obvious 
"kubuntu" and <return> do not work. I have also tried ubuntu 12.04 
and it works but have a nasty bug configuring audio and seems not 
to regognize all the hardware.

Android binary is twice the size of Linux one because ARMv5 architecture 
is bad at dealing with 32-bit literal values, so it takes much more 
space than for IA-32.

Pekr, he already did port it to ARM Linux, but at the time noone 
working on the project had an ARM machine to test with other than 
an Android phone. And porting the core to Android is the simple part; 
the host would need to be rewritten almost completely for Android 
due to the different application model. Noone was using Amiga either. 
The only alternate platform that was getting any use by the project 
members was Syllable.

You have to remember also that when the old R3 project was active, 
cheap ARM computers that could run straight Linux were almost unheard 
of, or were too expensive. Nowadays we have cheap micro-ARM computers 
that can be bought for less than $100 and can be easily experimented 
on.

Pekr, he already did port it to ARM Linux, but at the time noone 
working on the project had an ARM machine to test with other than 
an Android phone.


Maybe I fall into the "no one working on the project" category, but 
I had ARM machines available for at least the last 6 years or so. 
Last time Carl was rumored to have ported to ARM (most likely "again"), 
I was certainly around, with ARM machines, offering to test :)

But in any case, I see no indication as to why "porting to (Linux) 
ARM" should _not_ be a matter of 5 minutes, and I also see no real 
reason as to why not to believe Carl when he last claimed to have 
done such a port.

I think someone else also had this problem, but I'm getting this 
when building this source on Linux:

I'm running on Syllable Server now, so the Linux version is correct

And because it's not needed. The Linux-configured source - and even 
the binary Linux library - work fine on Syllable Desktop

What I'm doing now is just a Linux build. A build on Syllable Desktop 
yields a different host executable: that is not compatible. The library 
would also be internatlly different when compiled on Syllable Desktop, 
but Desktop can still load a library compiled on Linux

Builds are not byte for byte compatible across Linux platforms, because 
they depend on compilers, headers and startup fragments from the 
compiler and possibly the assembler

I supposed that was why there were other platforms for Linux than 
just 0.4.4?

AFAIU, 0.4.x for Syllable Server sounds appropriate (it seems to 
be "just" a Linux distribution).

I've tested it quite well. We've been running R3 Linux binaries for 
years on Syllable Desktop. Having the source it's properly built 
on Syllable, but it hasn't fixed any problems

As long as programs use the Linux configuration as default in a decision, 
it almost always also works on Syllable Desktop

Again, it would be nice if just a copy of the Linux configuration 
were made under the name "Syllable", but currently I wouldn't want 
to ask anyone to spend time on it

Arnold: I believe that Rebol/View uses Windows Codepages under Windows, 
MacRoman on OS X and ISO-8859-1 on  Linux. Sadly this means it only 
really supports true ASCII characterrs cross platform unless you 
manage encoding your self.

Yup. You should see what they have in store for SQL Server 2012. 
It can be run on a fully command line OS, managed remotely entirely 
through PowerShell scripting. And you can do PowerShell scripting 
of MS servers from Linux clients too, reportedly.

i am not using linux

Kaj, not sure if it's of use to you, but I dug out the timings from 
the last time I built Qt (on a Linux host, 4 months ago):


$ ./configure -opensource -nomake examples -nomake demos -nomake 
docs -nomake translations
5 minutes

$ make -j2
34 minutes


That was on a moderate dual-core machine with 2GB ram and spinning 
disks. Not sure how much make could parallelise, but for a single-core 
machine roughly twice the build time will be a reasonable worst case 
estimation. I guess that otherwise the configure-to-build time ratio 
will still be roughly the same.

I'm starting to get the GUI build to work, and it takes a few hours 
here, but Syllable Desktop can't use the second core on this machine, 
and compiling is roughly half the speed as on Linux, anyway, so that's 
roughly consistent with your timing

I already had Qt running before in embedded mode on the Linux framebuffer

Adrian, your selection in VMware should work. A generic Linux option 
should also have a good chance of working

I wonder how most people come to it - if you search for compact/small 
Linux distributions, does it come up in the results? I would think 
most people looking to get something lightweight would look at linux, 
not some completely different OS

We get hits from many of the same search phrases as Linux, since 
most of the same software is in Syllable, and we have an extra Linux 
system