AltME groups: search

Doc, in an Ann-reply channel, you mentioned, that first alpha of 
Red might be out this month. Could you elaborate a bit, what extent 
will it cover?

Sent another donation, to make life in a programmer's cave a bit 
easier :-)

You'll have to research the CGI interface a bit and maybe make it 
like the REBOL one. It's quite simple: you need standard output, 
which is just printing, standard input, and reading environment variables

I've tried donating a couple of times, but Paypal won't let me. I'm 
a bit weary of using bank transfers.

Hi Doc, check for a new donation from me through PayPal.  I could 
afford 100 Euros this time. Hope it will help you a bit more.

Recently tried to run the Hello World on my Android based Galaxy 
Samsung Tab 10 but after seeing the "executing ..." msg. Nothing 
appeared. I will try to look at what could be done but I suspect 
I also have to first learn a bit more about Android and my machine 
to help ... I'm very patient and began to read about the ARM. and 
Android itself. What an evolving world we live in ...

You can make a port work a lot like a series, and you mostly did 
with the virtual block scheme. FOREACH and PARSE not working on ports 
can be a bit annoying, but they would only work on a subset of the 
port types that either work like series or (theoretically) like files 
(like open/direct file ports in R2).

@Doc : No better success even if running from NativeEXE.apk version 
0.5 and Android version 3.2 - will continue to read before being 
able to investigate myself what could be done - Please don't loose 
your time on this case for now - You have much better  to do ... 
even if it's annoying a bit. I don't despair but I really can't be 
useful to you for now... my understanding of the inner working of 
this stuff exceeds my current capabilities !

byte-ptr! is just a macro for [pointer! [byte!]] which is a bit more 
generic type than c-string!

Another question :) Is there any easy way to convert integer! to 
float! ? I wrote something for float! to integer!, but with integer! 
to float! I'm bit lost.

Another question :) Is there any easy way to convert integer! to 
float! ? I wrote something for float! to integer!, but with integer! 
to float! I'm bit lost.
 - see http://www.fm.tul.cz/~ladislav/rebol/library-utils.r

Is that 64 bit Ubuntu?

If I remember correctly, the Windows clock function is a bit different 
from the LibC one.

I chosed VID only because I knew I could do it faster than messing 
around with HTML/JS libs and intricacies. I was just a bit concerned 
about hitting some performance walls or native bugs I couldn't workaround. 
Fortunately, all went well.

Reaaly nice, Doc! btw see issue #222. This one is bit harder to trigger 
:)

of course, better than JAVA. But generally it does not work in a 
browser - you still need a plugin for each platform. Don't forget 
mobile devices, etc. But - that is a bit offtopic here in a RED group

My tests are bit random, they test just what I need but I will add 
them, it's probably better than nothing.

Doc, have a look at http://box.lebeda.ws/~rebolek/sintezar.zip

Compile file %sintezar.reds and see function ADSR in %env.reds. Even 
when I pass TRUE, EITHER always executes FALSE block. I tried to 
simplify it, but I wasn't succesfull, so it's bit bigger project 
than just few lines, sorry :)

If some external library requires 64bit integer, but Red/System supports 
only 32 bit integers, how can I supply that number? Can I "cover" 
it with a struct?

If you need to pass a 64-bit integer as argument, currently you would 
need to split it in two integers and pass them instead. A struct 
is passed by reference, not by value (yet).

Ok, no metadata, I was wrong. See http://www.mega-nerd.com/libsndfile/api.html#read
sf_count_t is 64 bit integer.

If you need to make some 64-bit calculations as suggested by the 
description, it is more difficult to achieve, but not impossible. 
I think that Peter has coded some 64-bit addition and subtraction 
functions that operate on two 32-bit integers.

I found the issue with handling 64-bit integers in Red is the lack 
of support for unsigned integers. I only needed to  64-bit integers 
support on Windows so I used Lib calls in the end.

Actually, I wrote a small lib to perform the 64-bit arithmetic ... 
but I only needed subtract and divide.

it's at:

https://github.com/PeterWAWood/Red-System-Libs/tree/master/Int64

Spanish dialects are a bit more intense than English ones it seems. 
English dialets tend to be unintelligable, very few words mean something 
offensive to others.

I presume Kaj's issue is having to cd to the red-system dir before 
compiling (it is a bit of a pain).

I'll willingly help with the doc strings but am a bit short for time 
this week.

Peter: the lib-test file is crashing here on my OS X 10.6.2 image 
with following error:

dyld: lazy symbol binding failed: Symbol not found: _strnlen

  Referenced from: /Users/dk/Desktop/Red/red-system/tests/runnable/lib-test
  Expected in: flat namespace


After researching a bit about it, it seems that strnlen() is (was?) 
not supported by OS X.

Someone else wrote:

So the 'solution' I found to this was to set up filters for the various 
repository emails by filtering on email list. The list filtering 
is mentioned here on the github blog: https://github.com/blog/967-github-secrets
(scroll down the page a bit).


I would then just forward the emails from selected repositories to 
the "correct" email address.

Agreed, I always felt unions were a bit shaky, too

Fortunately the R3 host kit unions are tagged, so they can be used 
a bit more safely. Most higher-level languages that implement this 
kind of thing do something basically equivalent to the Variant type 
of VB, COM and .NET; even Objective C, Smalltalk, most Lisp/Scheme 
languages, and REBOLs have variant types. A variant is basically 
a tagged union type underneath. Having a cleaner way to do this in 
Red/System would be good., perhaps something like the polymorphic 
types in most functional languages. Red itself could have a dynamic 
value type like REBOL, which is basically another variant type. Red/System 
should have a way to specify different variant types because the 
variants of different platforms tend to not be compatible with each 
other.

Brian: thanks for the input. 


Oldes: I think this has been discussed in same channel on Rebol3 
world long time ago. Basically, the problem is that it  breaks REBOL's 
syntactic rules (digits as first characters of a word are not allowed). 
Also, this kind of syntax looks cryptic, it's IMHO, and goes a bit 
in opposite direction of what REBOL wants to promote (readable syntax).


Maybe we can do some implicit casting when a float literal is passed 
as argument to a function expecting a float32!.

works for me too - Win 7 64 bit

I have Vista 32 bit, I am an admin ..

Gregg: thanks for taking the time to test it. I think it won't be 
needed for XP x64 as we know it works on XP 32-bit and W7 x64 already.

I think that guys had some kind of GUI in mind, or maybe more specifically 
- some GUI targets, as e.g. html5, etc., being native on target devices. 
Myself, I would support and sponsor bit a View plus VID3 transition 
towards the Red, but not sure if someone would pick up. So - in the 
end, some "GUI" might appear ....

There are short and long switches, -dlib is already a bit too long, 
so it might be reduced further in the future, the long version is: 
--dynamic-lib.

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.

Pekr: right, from now on, you can expect daily progress on Red layer. 
I will push the new code soon, I still need to complete it a bit 
and clean it up.


Jerry: the baby looks nice, we'll just have to keep it away from 
junk food and it will grow up well. ;-)

Doc, a bit late congratulations for your first Red program! (I was 
offline for a week)

No, trivial, I would then just remove #system-include and add an 
option to #system to have the code loaded outside of 'red context...but 
semantically, it will be a bit inconsistent with barebone #system, 
as it means "inline the Red/System code here"...Maybe I should just 
rename #system-include to solve that.

Added new actions: AT, SKIP, BACK, NEXT, LENGTH-OF.

You can now do a bit more than just PRINT 1. ;-) See:

	a: 123
	a: a + 2
	print a * 6 - a

	b: [4 7 9 [11] test /ref 'red]

	print pick b 2
	print pick pick b 4 1
	print pick next b 1
	print pick next next b 1
	print pick back next b 1

	print length-of b
	print length-of next next b
	print length-of pick b 4
	print pick at b 2 1
	print pick skip b 2 1

	print pick at next b -1 1
	print pick skip next b -1 1

You can certainly carry this data in the arg1, arg2 and arg3 words, 
but it's a bit awkward.

Don't we need to wait a bit for more functionality from red before 
writing user docs?

I am running on Windows 8 64 bit by the way

Ah! Sorry Kaj - I missed that vital bit of info - I will go and find 
it  now

Actually, I'm using the much more affordable Robotis Bioloid to play 
a bit with robotics, Red/System AVR8 experimental port (targeting 
Atmel328) was meant to let me, not only play with Arduino boards, 
but also drive Bioloids. ;-) Too bad I don't have time these days 
to go further on that port.

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

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.

It was a bit painful commit anyway, as the internal API is not yet 
fully stabilized and to do it right, I would need to fully define 
the public runtime API first, but that would delay the 0.3.0 way 
too much, so we'll deal with that later.


What I mean by "public runtime API", is the Red API exposed to Red/System 
and to other host languages loading Red as a library. I'm still uncertain 
if such public API can be just some internal exposed or will need 
a thin layer of wrappers to make it handier (and in some cases, safer) 
to use. 


The R3 extension isolation model is too strong for my taste and makes 
the extensions harder to write than they should. I'm also uncertain 
if this model was stricly motivated by providing the safest possible 
interface with the core or, if the willing to keep the core internals 
as secret as possible was also playing a big part in this model choice.


Once the `dyn-lib-emitter` branch merged, I plan to study the Lua 
(and others) public API, to see if and how we can do better for Red. 
I already have a rough idea of how it should look like, I just need 
to refine it.

Oh, the particular quality of the R3 extension dispatch model that 
makes it well-suited to JIT compiler implementation is that a command 
function contains an indirect reference to the dispatch function, 
and an index integer. When the command is called, the runtime calls 
the dispatch function and passes the integer and a marshalled stack 
frame. For a JIT compiler dispatch function, the index of the command 
can be an index into an array of function pointers or something like 
that, and the dispatch function can just pass the stack frame to 
the appropriate function, then return the results. This means that 
the hard part of JIT compiling - getting the regular runtime to call 
the created functions - is something that you essentially get for 
free with the existing command mechanism.


You could also use the dispatch function to marshall arguments into 
another runtime with a different call model. You could, for instance, 
have a dispatch function that pushes the contents of a marshalled 
stack frame onto a Lua stack and calls Lua functions. Or you could 
do something similar for LLVM functions, or ActiveScripting languages, 
or V8, or ODBC queries, or even Red's JIT.


This all depends on having a good marshalling model in the first 
place that can handle the datatypes you need to support, and it would 
also help if there was a good task-safe callback mechanism that actually 
works (R3's needs a bit of work at the moment). Still, the principle 
is sound.

You're welcome! I use Cheyenne too in my business and I didn't donate 
for it before, so I feel guilty a bit, and do it for Red :)

Also, currently ARM binaries are about twice larger than for IA-32. 
It has several causes, costly 32-bit literal handling in ARM, 32-bit 
fixed size instructions,.... We'll deal with these issues mainly 
during the rewrite process of Red and Red/System. Possible solutions 
are:


- good literal pool allocator (there's an optional one currently 
in ARM backend, but not good enough for big apps).

- code optimizations that will reduce the number of 32-bit literals, 
like good registers allocation.
- support for Thumb instruction set.

as I think about it, it would be best to have some kind of interpreter/library, 
which would download just once, and then only the app package would 
be downloaded. But that's just most probably prohibited by mobile 
platforms. Having just each "hello world" app to take 60KB etc. is 
a bit too much ....

Having just each 

hello world" app to take 60KB etc. is a bit too much ...." You're 
not having the right metrics in mind. What matters is not the size 
of a "Hello World" app, but size of a real app. A typical real app, 
like with REBOL + /Encap, will be just a few dozens KB bigger than 
the runtime library. So, most Red apps will be less than 500KB and 
still less than 1MB for really big ones (not counting additional 
resources data). A "Hello World" using Appcelerator (one of the leader 
in Android dev tools market) is around 600KB. Also have a look at 
the size of apps installed on your Android devices, most of them 
are bigger than the typical apps size Red will produce.


If you want to compare with app size that Java can produce, take 
Red/System in order to compare apples to apples. Anyway, Java apps 
are cheated, because the JVM is built in Android. I don't remember 
seeing any way to install a shared library across different apps 
on Android, but maybe there's a way?

Calling it DOS would annoy me, as I had that on Atari 8-bit :-)

AFAIK, windows consoles only supporting Windows 8-bit codepages or 
UTF16. Red/System can print the full range of UTF-8 characters (as 
can REBOL) but the console can't display them.

View 2.7.8 on Vista 32 bit here ...

it is a bit difficult to see which one is solid, a different color 
might be better. It's a great game by the way.

Remove the bad lines version 1.04 works for me here. Mailed and uploaded 
just in between some modifications to clean things up a bit. Sorry 
for the inconvenience!

And a picture sometimes says more than a thousand words can. (Especially 
when your Chinese is a bit rusty like mine) :)))

Jerry, looks like a smart move. My Chinese is a bit rusty to say 
the least.

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.

BTW, wrt to ARM big size binaries, it's also caused by ARM using 
32-bit words for every instruction, while IA-32 has still a lot of 
8 or 16-bit ones. For example, there's a lot of PUSH 0 instructions 
emitted for the datatype registration block (the unimplemented action 
pointers), that's 16bit on IA-32 and 32-bit on ARM.

Robert: Brian also added: "We wouldn't have any restrictions on usage 
then." Except static linking r3lib. Or being able to see the source 
and work on Red or Topaz"


Guys, you should think about it a bit deeper and not only to cover 
short-term needs. I'm not sure that betting on R3 + copyleft license 
(even LGPL) will be a winning bet when Red will catch up with R2/R3 
and then, leave them behind.


MIT/BSD is the only way for R3 and Red/Topaz to collaborate instead 
of being in direct competition.

I am not skilled at licencing stuff, but isn't it a bit exagerrated, 
that just looking into sources or even studying them just to understand 
the architecture, might possess a legal problem, if you use different 
architecture in the final product, along with your own code implementation, 
which can't be regarded a direct 1:1 rewrite?

All MSDOS/Red binaries run fine here (Windows 7 32-bit).

DocKimbel, windows XP 32 bit

I can see an aproach of how to steal the thunder from ppl being eventually 
interested in Red
- then your sight is a little bit far-fetched

Ladislav - in 2004, when R# was slowly taking off, Carl published 
a blog article or announcement, describing R2 plugin feature. The 
supposed release was "imminent". Prior to that, Carl even contacted 
Doc to eventually stop working on R#, or so I remember. Of course, 
the announcement was just to distract ppl from alternative, keeping 
them interested in REBOL. 


Later on, I several times rightly identified some blog-post, whose 
purpose was nothing more, than to buy some time for RT, where in 
fact promissed things were not delivered. 


So - of course it is just my speculation, but with the history of 
R3 development I find it really curious to try to hype users to believe, 
that port to ARM could happen in 5 minutes, when RT was not able 
to deliver it is 5-6 years of R3 existence? And if so, it sounds 
a bit unfair to me ...


Simply put - wish Red, R3, World, whatever clone a success. It is 
just that what I would like to see is - a realistic estimates on 
any side ....

Good news: ARM compilers are better now too. They were a bit iffy 
back then.

Great work Kaj! Can it be used to emulate 32-bit CPU?

Doc, it's firmly an 8-bit CPU emulator, but it can certainly serve 
as a general example to implement other emulators in Red/System

Have to think on that a bit, and find some spare time somewhere. 
:-)

I don't know the answer about what's best, just rustling the bushes 
a bit.

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

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?

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

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

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

This is probably because there is no 512-bit AES algorithm -- see 
http://en.wikipedia.org/wiki/AES%5F%28cipher%29

I believe the reason I still have DIFFRENCE in there, as far as it 
will work, is for greater accuracy. I don't remember why I have the 
zone negation bit in there, but I probably hit some issue that required 
it.

Thanks guys. Endo: Special thanks for  going so far as type out an 
example that includes checking out that everything is OK.


 I realize that one cannot trust outside sources of info and that 
 one has to always be prepared to outsmart dumb users, but the needs 
 of this project are straightdforward and I am in unfamilar territory 
 so if it can make things easier I can go on a bit of faith for now. 
 That being said, better code that covers mistakes is better code 
 and I am appreciative of it.


 Sunanda: That is what I thought, but I had to be sure. Thanks for 
 helping with the details.


 Graham: Is that general advice or a comment on code examples I posted? 
 I thought I had done what you just said.

Yes, ANSI. I solved it by re-saving the same source file as UTF-8 
istead of ANSI. Still a bad complication, as by default, Windows 
sets Notepad to ANSI, so it is a bit inconvenient ...

you can make it a bit smoother than that by wrapping the whole thing 
in a panel and assigning a new face tree to that panel every time. 
Then you won't need to close and reopen the window.

You can study different styles using GET-STYLE.

For example:

probe get-style 'field


It's a bit misleading, though, as many styles share the same code. 
To really see how styles are built, you need to read the sourcecode 
for VID.

When I name the labels lr1 thru lr8 and use the trick I found on 
www.pat665.free.fr/gtk/rebol-view.html which is w: to-word rejoin 
["lr" n] (for n is 1, 2, 3 or    8 you get the picture.) and f: get 
:w 

f/font/color: white and directly show the label: show f I can set 
them seperately. But it is a bit ugly to do it like this if I may 
say so.

am fumbling with the get in bit...

I am busy with a little chess program. Just the board and the pieces 
to be moved on the board. (I have seen the examples on rebol.org). 
It is meant to be for a chess learning/training program and possibly 
demonstration/game review and maybe have a coupling with an open 
source chess engine like Stockfish.. I am going to write a little 
script to determine all possible legal moves.  

 I want some information for what is an appropriate way to represent 
 the board and moves in REBOL, for example the 8-bit white/black init-position 
 king queen rook bisschop kNight pawn and board could be a1-h8 or 
 an array of 64 elements or a block (of blocks)
Suggestions welcome please. Tia.

Got it, thanks a lot. I didn't know that FIRST gives me a "new" word, 
I thought that I'm BINDing *the* word itself and it should stay BINDed.

This confused me a bit:
>> o: context [a: 1 b: 2 c: 3]

>> foreach x bind [a b c] o [probe get x] ;this works, BINDs block 
to O

>> foreach x [a b c] [probe get bind x o] ;this works too, BINDs 
the word 'X to O

Hm, my Atari 8-bit already had that. I guess that's progress these 
days

Please put some example, you are a bit vague

obviously, this depends on the input data being pristine... 

if there are chances that the input isn't, then a bit more code would 
allow you to safely skip invalid lines.

I added a bit of processing to show how to use parse in order to 
actually do things beyond just match patterns.


note that the paren is at the end, once we have all data we want 
to match.  An error people often do is to start processing too soon.

It is a bit long to my taste, but I can repost here if you prefer. 
Also, BTW, welcome to REBOL, Marc

Ladislav: would you be interested in improving the 'proxify function 
from the REBOL profiler I've built for Red project, it has the same 
kind of constraints as 'tail-call? The current code is a bit "rough", 
I don't have time to make a cleaner and simpler version of it.


See code at: https://github.com/dockimbel/Red/blob/v0.3.0/red-system/utils/profiler.r

it's also possible to simply add a pane of faces that construct the 
text in the necessary parts. with SIZE-TEXT you can then calculate 
the necessary size of each part and write a little routine to lay 
it out. it's a bit of work, though.

The configuration can be sped up a bit by using -fast if you are 
using -nomake like that on significant parts

during VM setup, I chose "Other" and 32 bit for the OS choices - 
not sure if that was what I should have chosen

So it's a bit of a mystery. The forum indeed doesn't reflect it, 
but there also other reasons for that. It's been hard to register 
there for years, because we've had to block most common mail domains 
due to spam