AltME groups: search

QNX: if you're thinking about BlackBerry support, why not. But as 
BlackBerry has a decreasing market share, I am not sure that would 
be a relevant target to support in a year. Anyway, iOS is second 
on my list of mobile OSes to support (if we can find our way through 
that "fortress").

red/system running on another phone:
http://twitter.com/xearl/status/138413355126886400/photo/1/large


that's a hello world binary (using libc) compiled with red/system 
running on a nokia n9.

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

makes ui bindings extremely annoying, unfortunately. but a simple 
wrapper that bootstraps you into GL might be an option.

it's a maemo/meego mix nokia dubs "meego/harmattan"

And Clutter, and EFL... What a mess

Just checked, the only parts of GTK that remain on a stock N9 are 
glib and pango.

Switching to Cheyenne project until Saturday, I will do a Cheyenne 
presentation at a PHP event in France on friday, so I need to get 
prepared.

Doc, reading a twitter message - congrats to finishing ARM port stage 
:-)

I've tried including two bindings in one program that both include 
the C library binding, and I can't get it to do a single pass over 
the nested include, either with relative or absoltue paths to the 
C library binding

The first thing it bombs out on is a #L marker that it seems to insert 
into the source to mark line numbers (even though I didn't do a debug 
build)

I will a look at it today.

Kaj: I have just pushed a fix for the problem you've reported.

Implemented a separate SCROLL widget in the GTK binding, that can 
be used as a container for other suitable widgets to make them scrollable

So on ARM9, ARM11, Cortex A.

Red/System hello.reds now runs also on Android. If you have a rooted 
device, you can get and run the binary from here: http://sidl.fr/tmp/hello

If you use a native exe loader (like "Run Native Exe"), the ANSI 
escape codes won't be interpreted.

as for Cortex MCUs -  are those too low level MCUs, or is it just 
a matter of some work to do?

How it's supposed to be used during compilation? When I use:
do/args %rsc.r "-v 3 %tests/hello.reds"


i can see a lot of traces for files like %runtime/common.reds %runtime/lib-C.reds 
%runtime/win32.reds %runtime/utils.reds which I'm not interested 
in.

(I'm just trying to jump in and understand what the compiler does 
and in which steps) I know they must be there to create the app runable 
but I don't need such a app at this moment:)

You can use -v 6 and echo all output to a file and use a text editor 
to review the output for your code.

Disabling debug output for runtime files sounds like a useful option 
though.

Pekr: re "Cortex MCUs -  are those too low level MCUs, or is it just 
a matter of some work to do?"


Cortex-M raises two issues: first, these cores just support the Thumb 
instruction set (which Red/System does not support, at the moment). 
Second, most -M cores have no memory management unit (MMU).

(Cortex-M0 supports Thumb plus a few Thumb-2 insns, IIRC.)

Oldes: I've pushed a change in master branch, you can now use -v 
5 to get the output of your own code only (with max details).

Oldes: about floating point support, I have made a short review of 
required changes in current compiler. I will publish it tomorrow, 
so we can decide on the priority with Kaj and others.

I'm looking into the allocator. alloc-series says it takes a size 
in cells of 16 bytes, but then it relays it to alloc-series-buffer 
unmultiplied, which says it takes a size in bytes, and only rounds 
it up to 16 bytes

For anyone interested, here's a direct link to the GTK+ example that 
shows all currently implemented widgets:

Here's a screenshot of Kaj's GTK-widgets under Win7: http://static.red-lang.org/red-system-gtk-widgets.png

Alternatively, you could add a path to the icon in the program

Implemented the ability to maximise or fullscreen a GTK window

I have a basic binding with OSM GPS Map working

A simple OpenStreetMap browser goes like this:

I've got a basic binding with LibChamplain to work, too

I've moved the GLib binding in the GTK+ binding to a separate project, 
here:

For your information: A small code editor including lua scripting 
(GTK + scintilla bindings)
All sources included.
Low c footprint.
A good inspiration for further RED evolution.
http://caladbolg.net/luadoc/textadept/manual/1_Introduction.html

It's nicely integrated with Lua. Doc has a similar plan for Red, 
and I'm also looking in that direction

Hi, I am interested into building an maintaining documentation for 
those programming languages based on REBOL.
It would be nice to have a DOCBASE for them.
What I search is:
- Someone ABLE to SETUP the Linux and the Wiki Software
- Someone which would share with me the cost of hosting.
Do you like the idea ?
Write me at [giuseppe-:-chillemi-:-eu]

Hope all of the authors see the advantage of having a common infrastructure 
for documentation.

I think, it's a good initiative, but I can't judge, if it's a good 
idea, because I know too little about the different variants. How 
similar/different is Red, Topaz, Boron and World, and how are they 
compared to REBOL? Would the docs help a developer, or would they 
cause more confusion? It probably depends on the form of the docs 
too. Examples would help.


I plan to write a manual for World, something similar to "The C Programming 
Language" book. And that's not a dictionary, so there is good room 
for docs by others without overlap. And also docs, which are not 
just a dictionary, like extensive examples with explanations and 
probably other kinds.

I will write a new blog entry once that done.

But it only runs in command-line mode for now, a Java bridge will 
be required to produce GUI apps on Android.

Congratulations Nenad. I hope you're going to take a few days off 
after such an intense effort.


Great timing too! Just in time for the launch of the Rasberry Pi!!!

Thanks Peter. New year is usually a very productive time for me, 
so don't count on me to rest now. ;-)

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

You can wrap the C system() function for a poor's man support.

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

Perhaps, a line needs to be rephrased: "Such approach will allow 
us to build easily Android apps without having to write a single 
line of Java or Objective-C code" - AFAIK, Android apps are not written 
in Obj-C?

however, it is a bit difficult to use, and also - allowing non-market 
sources could be marked as dangerous. Will there be ability to produce 
native Android apps, which could be published via the market?

Anyway - not sure if such a news article for OSNews is not a bit 
preliminary ... no bindings yet, no possibility to use standard channes 
(market), no RED yet = not much of a REBOL featureset either. Achievement 
is great - RED gets us onto mobile OSes, still far superior to R2 
or R3, except that Red/System is mostly a C with REBOL syntax. I 
can understand, why Doc wants to work on RED itself some bits too 
:-)


Anyway - I am here to do some testing with HTC Sensation. The fun 
part comes, when the bridge is going to be done. Imagine having parse 
and REBOL like series handling, with access to stuff like SMS, calendar, 
address-book, and other APIs :-)

Produce native Android apps: certainly, but that requires the Java 
bridge. It should be possible to also use the NDK for accessing a 
subset of Android API, but I haven't investigated yet that option 
much, especially if it requires Dalvik code support or not.

http://www.english-test.net/forum/ftopic25371.html


And then in Microsoft Manual of Style (version 3.0) we can read "To 
form the plural of an acronym, use a lowercase "s" without an apostrophe." 
Example: several IFSs.

I will give it a new try to see if I can get Gtk binding working.

For GTK, it stops on a symbol issue with atexit():

[root-:-debian-armel]:~/ARM# ./GTK-widgets 

./GTK-widgets: symbol lookup error: ./GTK-widgets: undefined symbol: 
atexit

Maybe Andreas would have a clue about this.

I guess that it might be causing by a bad version of one or several 
shared lib from GTK.

(That should have been: "via a stub in libgcc".)

Missing double-quote in:

http://static.red-lang.org/red-system-specs.html

either a > 0 [print "TRUE"][print "FALSE]

for SWITCH I can see the need (computing labels in array to support 
indirect threading ) a speed issue.

But why do you need to implement CASE in red/system, it's only a 
sequence of if/else statements ?

In REBOL we tend to use CASE instead of EITHER because CASE is faster 
when there are more than 2 tests. Flat is just a side benefit. Of 
course, an optimizing compiler could change the resulting code from 
one to another when it's appropriate, just like most modern C/C++ 
compilers do.

I hope you have a CASE/all option. We used the CASE/all style in 
the R3 module system code to great benefit, mostly in maintainability 
but also in speed, when compared to the nested IF and EITHER code 
it replaced. It enabled us to add features and simplify code at the 
same time.

I wasn"t against CASE implementation in Red.

I was asking if it was the right place to have it in Red/system as 
a core function instead of as a latter compiled mezz.

but maybe a mixed the things between Red/system and the other layers

IF, UNLESS, EITHER, CASE and SWITCH all make sense to compile in 
a compiled language because they all translate to branches and/or 
index lookups in the generated code, and optimizing that would need 
some decent compiler support. If anything, CASE is the most general 
(the others can all be implemented with CASE), and would benefit 
the most from optimization.

I think we don't, so maybe just a preparation for what is about to 
come one day :-) IIRC Doc was investigating, what would it take to 
get floats supported by RED/System :-)

I do agree that it is a bit hard to find specific things in the current 
manual

CASE/all: could be added to Red/System (would be called case-all), 
but as I'm personally not a great user of CASE/all, I'll wait for 
other users to ask for it. ;-)

BTW, the "manual" is supposed to be a (more or less formal) specification 
of the language, but as I didn't have time to write a separate user 
manual, it now tends to serve for both uses.

In such case, result is undefined. If you need a return value, it's 
up to you to provide a "catch all" ending rule that never fail.

A Red/System-produced binary linked with the Red/System runtime arguably 
is a redistribution of the Red/System runtime in binary form.

SWITCH native implemented in Red/System, here is an example of supported 
features:

a: 5
ret: switch a [
	0 	[print "0" 0]
	1 #"^E" [print "1" 1]
	2 6 	[print "2" 2]
	3 	[print "3" 3]
	default [print "no match" -1]
]

print [lf ret lf]

Are the clauses you are matching (minimally) evaluated, or unevaluated 
like in REBOL? Would the default clause conflict with a: 'default 
?

Gabriele used this model instead for Topaz:
ret: switch a [
	0 	[print "0" 0]
	1 #"^E" [print "1" 1]
	2 6 	[print "2" 2]
	3 	[print "3" 3]
] [
	print "no match" -1
]

That's a mandatory default clause, which can be empty.

Unevaluated, but only integer! and byte! literals are allowed.


[ a: 'default ] No word!, this is Red/System, not Red. :) Anywhere 
adding words as symbols only in Red/System might not be a bad idea 
in future.

What does SWITCH return when you don't have a default clause and 
none of the choices match? None? Some undefined value? Trigger an 
error?

Suggestions for improving that are welcome (both for CASE and SWITCH), 
as long as they don't require a lot of additional coding.

Do you have something like unset!, or is it really undefined? (I 
hate undefined behavior in a programming language, pet peeve)

For that matter, do you have something like the none! type? Nullable 
types are the subject of a big debate in PL design right now.

Yuck (no offence). Triggering an error or returning none would be 
better. There are even some languages that trigger an error on compilation 
in that case, but that requires either an interesting type system 
or some dataflow analysis, so that is not likely a good idea to put 
in Red/System.

None! type might not be a so big burden to implement and support, 
but it is just not required for implementing Red, which is the main 
purpose of Red/System currently. If current Red/System users can 
come up with good semantics for such type, I could examine the case 
for implementing it, though.

I know it's a bit frustrating currently, as we could add a lot of 
sophisticated features to Red/System, but that's not the plan. :-) 
Most users will never touch Red/System once Red gets available.

Is the compiler capable of showing warnings? CASE and SWITCH without 
default cases might merit one. A caveat emptor approach might be 
bese for a C-like intermediate language, I guess :-/

I am not a big fan of warnings "à la C", I debated myself several 
times to decide on keeping it or not (converting it to a compilation 
error).

Do you have a value you can return when the value would be undefined, 
which would cause an error to be triggered if you try to use it in 
an expression? If so, CASE and SWITCH could have an implicit default 
case that returned such a value, and the compiler could optimize 
that out if the CASE or SWITCH return value is not used in an expression. 
That would solve the problem without resorting to nullable types.

Do you have a value you can return when the value would be undefined

 Yes, zero. It could work for all current datatypes: 0 for numbers, 
 NULL for pointers and FALSE for logic! (all are implemented using 
 0 as value internally).


...which would cause an error to be triggered if you try to use it 
in an expression?
 No.

The first option could be easily implemented, probably just a line 
of code or two to add in the compiler.

Thinking about it, I believe that I could hardwire a runtime error 
in CASE/SWITCH in case of unmatched value and no default.

With current CASE in Red/System, it might be required to force the 
use of a 'default keyword, as in SWITCH, for the compiler to know 
if a default clause is used or not in a deterministic way.

Done a quick implementation test on SWITCH, it seems to be working 
fine.

I think that the addition of a default keyword in CASE would be an 
improvement.

Peter: I followed the same syntax as REBOL for CASE, but I am unsure 
that adding 'default keyword would be better. On one side, you have 
a better compatibility with REBOL, so easier for all REBOL old timers, 
on the other hand, we break compatibility (on syntax level only), 
but have a more consistent syntax inside Red/System.


Also the CASE semantics do not require a special keyword for making 
a default clause.

Need some time to think about it.

Silly question: Does C-string mean that it's a C-compatible string 
type and whether there will be other string types in the future?

In short "yes". C-String in Red/System is simply a null terminated 
list of bytes. As I understand, strings in Red will support unicode 
but Nenad hasn't decided what form they will take yet.

If the compiler is only looking for 'default inside a switch statement, 
a good solution may be to #define defaiult as true in common.reds 
and then I can write

case [ a  = 1 [b: 1] default [b: 0]]

and old REBOLers can write 

case [ a  = 1 [b: 1] truet [b: 0]]

On the other hand, even if the syntax changed and default was a keyword, 
the old REBOLers could still write

case [ a  = 1 [b: 1] true [b: 0]]

and belt-and-braces types could write

case [ a  = 1 [b: 1] true [b: 0] default [b: 0]]  ;-)

Other strings in the future: for Red/System, possible but very low 
priority for now. Red will have a R3-like string! datatype with Unicode 
support.

Kaj did it again. :-) Thanks a lot! I hope that the article comments 
won't be too harsh. :-)

Basics of sales: you have to present three times before you make 
a sale

Another thing is that when I actually try atexit, it works but ends 
with a crash