AltME groups: search

The minimal requirements for Red would be something like: a 32-bit 
CPU or MCU and 1MB of RAM. 


For Red/System, a 32-bit CPU/MCU and 32KB of RAM (at least 1KB for 
stack) would be enough to run some small programs. A 8-bit version 
is still possible though.


ARM Cortex-M controllers: no problem for running on them as long 
as we implement a Thumb instruction-set backend (could be merged 
with current ARM backend).

Doc, will it be necessary or possible to have a debug version of 
Red with deep level of integration with debugging tools as well as 
a non-debug version with higher performance, or is this something 
that can be turned on/off in the same runtime?

Depend on what you mean by "debug version" and what debugging tools 
you're thinking about. My plan for Red is to deeply integrate it 
with the IDE, so that you'll be able to have advanced debugging capabilities, 
like step-by-step debugging. Such feature could maybe also be ported 
to the console version, so you'll be able to use it even without 
the IDE installed.


Also, I have thought the Red execution architecture to be as reflective 
as possible in order to try to support memory image loading/saving 
and stopping/resuming (think Smalltalk). It's very tricky (not sure 
we'll have it in the end), but if we can achieve it, you'll be able 
to get a snapshot of a running Red program on file, transfer it and 
resume it somewhere else....ideal for reproducing exact bugs occuring 
conditions. EDIT: the right expression for that is "Image-based persistence".


In the meantime, we already have some "debug mode": -d switch for 
Red and -g switch for Red/System (we'll probably adopt -d for both, 
-g will be reserved for gdb support). It's mainly intended for internal 
usage for now, the Red/System one can be useful to locate runtime 
errors in source code (usable, but still needs some fixes though).

As long as I don't have to tug the IDE around, then it all sounds 
great. :-) Sometimes you just want to spend 10 seconds installing 
Red and then quickly run a script, just like REBOL.

block

 it's a context, the one that contains all the block! datatype related 
 code.

Yes, all actions and natives work from the stack. Sometimes they 
are just wrappers other equivalent functions that pass arguments 
in a classical way, so they can more easily be called internally 
by other parts.

Strange concept

 It looks pretty classic to me, but there are some specific reasons 
 behind such choice, that I will detail them in a future blog entry. 
 Basically, it simplifies the tracking of Red values on stack (making 
 the work of the GC easier) and stack serialization becomes almost 
 trivial (to memory, for continuation support, or to file, for image 
 support). I think that R3 doesn't do it that way, but probably uses 
 recursion, passing all R3 values on C stack instead. It's a faster 
 approach but less flexible.

Kaj, I just watched your talk. It was great, but you can probably 
benefit by putting in a diagram or two, showing the relationship 
between REBOL, Red and Red/System.

Thanks. I know, I'm low on glitz. It's because I don't want to take 
the preparation of those talks more time than they already do. I 
prepare by making sure that as much as possible works, and then I 
do a guided tour of it on the machine itself

It's the same reason why I have written only limited documentation. 
I have to prioritise my time to do the things that I need myself, 
and I don't need the documentation and the presentations that are 
a goal in themselves

Nenad, a small donation from me via Paypal underway.

This is the plan for handling numbers with decimals:

- decimal!: BCD
- real! or float!: floating point numbers

- money!: BCD or just integer with a scaling of 100 on input/output.

Pekr: your remark about the stack made me think about it. I might 
change a bit the current internal API, collecting arguments from 
stack in trampoline functions (actions.reds) instead, and then calling 
datatypes-specific actions passing them the arguments directly. This 
would reduce the runtime code size a little bit and might simplify 
the construction of the future public API. I need to see first if 
they are drawbacks before deciding to refactor the code in that way.

Those functions don't have any arguments, they seem to work with 
the stack directly? Strange concept. Are those real Red functions?


They are Red actions (the datatype "methods" if you prefer). Polymorphism 
support is implemented through a dynamically created actions jump 
table. If you really want to see how this internal API works, just 
compile small Red test scripts with the -v 1 option (-v 2 will also 
give you the generated output of boot.red compilation).

*a subset

I got it to work also three hours ago (had only a VGA monitor, passive 
adapters didn't work, I had to find another monitor)

Yeah, we bought a new one, too, but also an adapter cable from HDMI 
to VGA

I will try to fix those bindings issues on ARM once I release v0.3.0 
in a few days.

Ah Kaj, could you put up a shopping list of thing to buy too when 
you buy a RaspberryPi?

RED FUNDING DRIVE, MATCHING FUNDS CHALLENGE:  to help ensure that 
Doc can continue to work on Red without disruption, I'll match funds 
donated to him by November 1, 2012, up to a total of $1000.

Perhaps some discussion about forming a Red foundation would be helpful 
to organize anticipated future actitivies involving community relations 
or other activities that will keep Doc and other core developers 
from focusing on code.

Thanks for thinking about me, Nick. I'll refrain from asking for 
donations until Doc is in a good position, then I'll set up a website 
for the bindings to give sponsors a chance to influence my priorities

Arnold, you want me to give a list of things that you would need 
to get a Raspberry going?

 after running around all week buying additional needed equipment.

 that sounds like a shopping list comes in handy when purchasing a 
 RaspberryPi, there are some surprises like needing a VGA monitor 
 where the standard videoout on the Pi is HDMI.

You don't need a VGA monitor, to the contrary, it's hard to get a 
VGA monitor connected, you need an HDMI or DVI monitor

Arnold, the Raspberry is just a motherboard, you'd need a power supply 
and cables at the least :-)

Also saw a typo, I read the document further tomorrow and note all 
typos I see.

Maths op missing in BNF rules: good catch. You can add them and submit 
a pull request on the master branch.

I will try that, I once did a pull request but it pulling doesn't 
make sense in my mind. I think it means the Github must be pulling. 
I will try again (with possible other improvements. If I am not succesful, 
I will put a file with my improvements up somewhere. Now to work 
(my job waits)

Well I changed some text in this file, I changed it online in a black 
background box where I could not see my cursor nor the arrow pointer, 
so it sucked :( 

I thought it would be possible to edit the file offline but that 
is something to find out how to do next time ;)

Now I added a comment and it says I want to commit 182 changes into 
the master branch, which is not what I want, but Github says I want 
that. Including my comments it could be I typed in total 182 characters 
including the ones I deleted (?) but the 182 are the commits from 
the 0.3.0 branche I think. 

Me and my friend Github >:|

Agreed did one today but it was for git not for github. As github 
doesn't support OSX10.5 with her github for mac program I am temp 
stuck. maybe a REBOL script can take over the git commandlines for 
me. I go and try that to take me over the githurdle.

I can't accept your pull request, it's a complete merge of different 
branches (you're probably mixed up several branches, or you haven't 
rebase before submitting the pull request). You need to submit only 
the changes you did. For that, you need to have a clean codebase 
and up-to-date wrt the branch you're modifying.

FYI: I got my RPi video problem fixed, still no network, but I will 
go buy a  long network cable tomorrow, so I should finally be able 
to look into the issues Kaj submitted. I would like to fix the main 
ones before releasing v0.3.0.

btw - once 0.3.0 is out, what about a blog post, summing what is 
already available? Maybe a short script? btw - do we have conditions/branching 
and loops yet?

Yes, v0.3.0 is close. Of course, I will write a blog post for that 
release, it's a major one. Condition/branching/loops: that's what's 
implied (among other things) by being "Turing-complete". Also, a 
quick look at last 10 days of commit in v0.3.0 branch should answer 
your question too. ;-)

Nicolas: it is very possible that we have forgot to add unit tests 
for that feature. Obsviously, it's a bug, so please report it to 
github tracker so we can fix it asap.

number! is a virtual type used only internally by Red/System compiler.

It looks like a minor type checking bug, so it should be quickly 
fixed.

Just as a reminder, once we fix the current ARM bugs, we would need 
to add Red to the following page: http://elinux.org/RPi_Programming

It's basically unrelated to Thumb. It's not necessarily about hardware 
floating point, either, but it's a different way of supporting it

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

ARMHF: a little, it's the same work as the one done in IA-32 faster-float 
old branch. In a nutshell, it consists in passing float arguments 
in FPU registers directly instead of using the stack.

Same here, a little tour would be nice. (That is why I picked up 
a documentation check to start with). 

e.g. In actions.reds most of funtions are only present as 'name* 
and some are present as both 'name and 'name*

That was a reply to a post from Pekr from thursday 1.49 PM

Arnold: I certainly won't document nor make "little tour" for internal 
code that is in alpha stage. That would be just a waste of time. 
For the '* suffix for function names, it indicates that the function 
takes arguments from Red stack. But that might be changed in the 
future, like all the rest of the code...until we reach beta stage 
(or even until 1.0 release).

Kaj: do you have a simple callback case that's failing on ARM and 
not using floats at all?

He's a young guy - I think it was a bit before their time, unfortunately. 
Hopefully they'll now take a good look.

Is R3 chat in github? It does not handle failing open a browser window 
very gracefully.

I wodner a bit, why Carl, releasing R3, did not publish also an R3 
chat? Is that so advanced, that he felt like keeping it private?

As for me, I can see it as a chat. I am not sure it scales well to 
replace Altme like product, but maybe I am wrong. I liked IOS model 
with pluggable handlers, and I would also probably made the back-end 
SQLite based ...

Yes, a few times. I just mentioned to Nick earlier today how Carl 
seems to purposely avoid answering that question.

He would in the past however accept fixes to it, and posted a guide 
on how to extract the sources.

Nick: in your business_programming.html page, I think your missing 
a % character in following code line:

    do mysql-107.rip

You should publish it as a book someday Nick!

Graham, I haven't tried to grab a cookie or anything yet, but just 
running the SO bot errors out first thing:

** Script error: lastmessage-no has no value
** Where: get ajoin case ?? do either either either -apply-
** Near: get :name

What optimizations are you looking for?

@NickA: About enhanced r3 chat, have a look to %wchat.r in the %OpenMe/ 
folder of this Altme world.

Basically its %chat.r but it act as a proxy between the Devbase server 
and the browser. The goal is that the browser replace the CLI interface 
: not typing command in CLI but cliking link in the browser.

Its just a start. There is some work to do to handle POST request 
and then allow posting. + enhancing HTML presentation.

DideC, thank you, I'll take a look at it - never knew it existed...

Carl's comment about getting graphics running on the Raspberry Pi 
makes me wonder if Carl has a project in mind, with Raspberry Pi 
as the heart.

Cyphre has a huge responsibility getting R3GUI running on Android. 
 Everything he's ever created for REBOL has been top notch.  If we 
had 5 - 10 more Cyphres in this community, REBOL would be in a totally 
different place.

Not to mention a couple other Brian's.

Hopefully it would be adaptable to Red later, although Red has a 
bit different GUI priorities.

Pekr, unless this is a huge rehash that you don't want to repeat, 
could you let me know which View engine proposal you're talking about? 
I don't do GUI stuff so it's been a while since I caught up with 
current events. In the !R3-GUI group if that's appropriate.

Thanks, Doc. After fighting for a day and a night with the XP machine 
to keep it from self-destructing, I could test that audio playing 
also works on XP now - but no task bar icon...

IIRC you can install the virtual loopback adapter in order to allow 
tcp on a card-less machine on XP.

Kaj, just a note to say I appreciate you always including reminders 
about where things are. I'm spread so thin these days that I easily 
lose track of old messages pointing to sources.

Go Kaj Go! The order of eval buttons confused me, as I haven't been 
on there in a while. Compare is great. That's what we need on a large 
scale.

I've reordered it a bit in the modernisation, but if you hadn't been 
there for a while, it should be fresh :-)

But that is such a minor nit to pick, that you should ignore it and 
just hear the part where I say "Go Kaj Go!". :-)

Ah, now that I click them--and remember--I get it. My gut said that 
Available Words would give me a matrix with the languages at the 
top and a list of words available in each.

e.g. col 1 would be a union of all available words, and each row 
would have a check if lang-x supports it.

Just need a masert WORDS-OF reflector for each language. :-)

Routine are basically Red/System code which require a compilation 
step, so it can't run as-is in the interpreter.

But if you define a routine in a Red script, and then DO it, it will 
work. You can also build a custom console by writing a Red script 
and adding at the end an %include %<path-to>/console.red.

if you define a routine in a Red script, and then DO it, it will 
work.
 => the script needs to be compiled for that to work.

About the "painful" part, I would like to provide ready-made Red 
consoles for each platforms. If Andreas (or anyone else) could make 
a redsource site as he did for R3, providing automatic builds, that 
would be great.

And it's just a S3 bucket confiured as a website which keeps my costs 
down.

I still have a couple of his WhyWire wireless units operating on 
a ranch here north of Ukiah.

The WhyWire boxes ran OpenBSD off a CF card with Rebol installed. 
 I know Rebol was used at least for configuring the units.  I don't 
know if Rebol actually handled any of the wireless communication 
parts.

a part of the Easter story...

However, the reliable way to do a full & clean build is `make make` 
followed by `make clean prep r3`.

Hmm, why don't you "force us" to define a new (Syllable) platform?

Do you mean a Syllable Desktop build?

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

Do you really want Syllable to be ignored as a platform?

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

It's fine if the Syllable Desktop configuration becomes explicit, 
but I currently don't have a reason to spend time on it

Yes, but there already are some Rebol scripts examining system/version 
to "know how to call system libraries" or some such. I guess it may 
be a good reason to define a platform?

Yes, that would be a good reason. In my patches to port Python, for 
example, I solve it by looking if the /system/index/ directory exists, 
which would identify not only Syllable Desktop, but also Syllable 
Server

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

well, then it may be just a matter of preference (if you want to 
make Syllable "visible" at least for Rebol)

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

I see I penciled in a TO_SYLLABLE parameter here in the Syllable 
overlay of the build recipe:

Carl has given a sign of life on rebol.com rebolution blog.

I saw Carl for two minutes on Thursday.  He said he was going to 
poke his head in for a second, although he is still really busy.

If you are using a web browser, yes. If you want to run it, you should 
run GTK-browser

I see. Thanks. I also tried to get the android version to run on 
my Nexus 7.No luck there so I went back to trying the test that was 
originally posted and I can't even get that to run. Sorry, you'll 
need a more experienced test. :-(

Just a request. If you do not want the default, you can use INCLUDE/ONLY 
and save it as you see fit.

Do you think it is a complication for you?

The original demand was to have a /FLAT version which I offered to 
add, but Robert asked me to modify /LINK behaviour instead. I do 
not mind, in fact.

...but the fact is that adding another refinement would complicate 
the interface a bit without being absolutely necessary, perhaps