AltME groups: search

(As fast as yesterday) The base-1 versus base-0 would be accountable 
for a minute delay (less than 1% of the addressed numbers in the 
array, the 0-th and the last). The use of variables in the register 
looks more likely imho. Good point for the wishlist.

I was going to add register variables to the Red/System V2 wish list.


This is not required as one of the first change I have in mind for 
Red/System 2.0 is adding a good registers allocation method to backend 
code emitters.

That change alone should make a significant difference in speed (I 
expected it close to twice faster) and code size compared to the 
current approach.

Put it on for the world to know :)

The mersenne twister has a lot of examples in other languages. finding 
out the closest 1 to red/system.

most probbly I will do so anyway ;-) Will the demo be hello world 
example, or more usefull one, e.g. getting a contact list item? :-)

@Kaj, no problem, and Peter came to the rescue. Amazing even with 
a community this small, these things get solved in such a small timeframe.

About the pointer, I got the example of pointer/value: value somewhere, 
not saying from the fossil repository but might very well be so. 
The pointer: :value suggested confuses me. I tend to stick to what 
I had figured out. I prefer to avoid pointers almost always at all 
costs because of the trouble they can be. A good description is needed 
of how they are best used in  Red(/System).

Notice that this runs on the x86 emulator, there's still a few bugs 
to fix for the ARM version.

Also, it's possible to use a ICS skin...I just need to figure out 
how/where to define it.

Rewrite bridge: that was my intention, but I gave up after hitting 
a few walls in Java reflective abilities. So, I just optimized the 
memory usage of the current one and improved it.

Objects are required to build a cross-platform mobile API for Red. 
That way, you would use the same API for accessing universal mobile 
services and hardware from Red, like contacts, phone calls, SMS, 
GPS, Bluetooth,...

In the meantime, you will only have a platform-specific API, but 
as soon as objects are done, we could add some nice abstraction layers 
on top of it.

OK, so will ask in a different way (wrt Android) - will there be 
any official release, an example published, or even a blog article? 
If not, I will post as we go. If so, I might wait, so that we can 
refer ppl to download it and try to do their own small steps ...

Parse: not necessarily, it was just a requirement from Gab.

If you mean by "official release" a 1.0, we're still far from that.

I might mention it briefly in the next blog entry. I would like to 
make merge the dyn-lib-emitter branch and make a new release. As 
the Java and Android bridges will be included, I will mention them.

So I post a teaser, and later on will mention full new release, once 
the merge is in place and/or eventually blog article appears ...

I also plan to add a quick support for compiling kernel drivers for 
Windows. It shouldn't take long and some users need it, so I will 
give it a quick try.

Post a teaser: go on with spreading the teaser! :)

stores a value in an array. There are such examples in the Red manual

You have to initialise a pointer before you can use it

Yes, in one way or another this is a trick to check if the initialisation 
step already has been performed. Hopelessly overcomplicated if you 
ask me.

You can always have an unsigned integer using a simple pointer.

Also, "unsigned" is just a convention, the data is same as the signed 
version.

this would be an nice way for users to try red and progressively 
replace their binary code base, one source file at a time... instead 
of a whole project at once.

Yes, not yet, but it's in the roadmap. Currently, you can replace 
a project one shared library at a time, or one 0MQ service at a time

I have a new test pre-release version for Android, could some of 
you test it on different devices?

http://static.red-lang.org/hello2.apk

It should display an input field and a "Do" button, allowing you 
to evaluate arbitrary Red code. The result of evaluation scrolls 
up, below the button.

Thanks Bo. Anyone with a 4.0.x device?

The printing is redirected to the logcat. To see it, you need a logcat 
viewer like eLogcat from PlayStore.

I just remembered that I bought a few months ago a cheap Android 
4.1 USB stick, I will look at the 4.x issues tomorrow.

When we'll have a true Red console emulation for Android, we'll be 
able to redirect the printing functions back to the console.

Login on SO requires a OpenID account. Don't want to link all my 
info on the web. SO is over for me.

I don't have OpenID, yet I am using SO, is it really a necessity?

creating a separate account

The deobfuscating Knuth's random program project is progressing into 
its final stage. It turned out that with getting the results of the 
program the same only the first part of the puzzle got solved. To 
use it in real programs you use the provided ran_arr_next function. 
This involved some pointer aritmetic that is not 100%  supported 
by Red/System. I finally got the function to produce the same results 
as the C version. The downside is it is now quite a mess with pointer 
indeces and other variables, so a lot of cleaning up to do and/or 
rework only using the index on the array approach.

It is just slightly different. The possibility to go back to the 
first element of the array or store that address. :(ran_arr_buf/1) 
would make it a lot easier. 

I already had a lot of help from Peter on this (thumbs up!) and I 
made good progress by now.

I get the pointer of the array and I can go up and down  using + 
and -, this works great, and the pointer is going along with it then 
and I suspect that if I do 
ptr: ran_arr_buf 
and I progress ran_arr_buf by 1 that I progress ptr too.

I now kinda solved it by using an additional variable. When I reach 
a 100, I subtract 100 from the array ran_array_buf to go back. 

Tonight and tomorrow I have some time to clean up my code and I can 
experiment some more. 

It is proven it can be done, but keeping the extra variable is surely 
slowing down compared to C's pure pointer solution.

I suspect that if I do 
    ptr: ran_arr_buf 
and I progress ran_arr_buf 
by 1 that I progress ptr too.


That's a wrong assumption. Those two variables are distincts, so 
each one has its own memory slot. If you change one, that has no 
effect on the other. What is shared there is the pointed memory region. 
So, if you change ran_arr_buf/value, that will affect ptr/value (they 
both point to the same memory location).

my trouble seems to arise from the different roles the array and 
the pointer play in the C code vs the Red/System code. In C the pointer 
is used as indicator for initialisation and signals when a kind of 
reshuffle is required and it points to the next generated value. 
In Red/System the array points to the current/next value and a pointer 
is not needed, and you can no longer use it as before to signal the 
status. This complicates things in this case.

You seem quite confused about pointers in Red/System. 


1) There's no "array" as distinct entity in Red/System, but you have 
indexed access, so you can "simulate" arrays to some extent.


2) "In C the pointer is used as indicator for initialisation and 
signals when a kind of reshuffle is required and it points to the 
next generated value." I don't understand this sentence, you should 
stick to C terminology (terms like "signals", "reshuffle" and "generated 
value" are alien to me in a C language context).


3) "In Red/System the array points to the current/next value and 
a pointer is not needed, and you can no longer use it as before to 
signal the status." I don't understand this one either... There's 
no array, only pointers. "to signal the status" has no meaning to 
me...sorry.

I think you have a complicated mental representation of what pointers 
and arrays are in C and Red/System. It's simpler and more straightforward 
than your descriptions. Basically, Red/System pointers act the same 
way as C ones (including "array" support). The only difference is 
the base for indexed accesses (1 vs 0).

Yes I know, I built one in already, except when you have shifted 
the ran_arr_buf, this one shifts along, but I want to return then. 
So I saved it in a sav_arr_buf to take care of this. All in all because 
I try to stay as close as possible to the original I have some extra 
bookkeeping to take care of. Later today I will clean up the code 
further and hope the smoke clears up ;)

Great work XieQ, congrats! Have you checked it against a C version 
to verify that the output is the same, given the same seed number?

I see a pattern.. I discovered I new method of software development!

My 'problem' with the Mersenne Twister is/was that if you print the 
integer it is turned into a negative number if the MSB is equal to 
1, the results could be the same, I did not check. Nevertheless it 
has inspired XieQ to work on his version? Nice to see this result 
XieQ! Keep up the good work!

 The Knuth algorythm is very interesting because of the pointers used 
 and I have little experience in pointers so I really learn a lot 
 and I hope to be able to document the differences, explaining it 
 to newbies in the Red language.

A good operating system will free the memory when the process ends, 
but it's a bad idea to not do your own cleanup of memory and other 
resources

The need to make variables known at the root level of the program 
is a limitation of the current Red/System compiler

Okay I mean you do an #include of a random library or other red(s) 
file, then declaration and init is done. Does the programmer need 
to call a random-free-memory function before ending his/her program?

The need to make variables known at the root level of the program 
is a limitation of the current Red/System compiler

 Actually, it's not a limitation, it's a design decision based on 
 use cases like this one: https://github.com/dockimbel/Red/issues/84

I also do a benchmark. It's seems too early to do this, but I can't 
contain my curiously ;-)
Produce 99999999 random numbers

Compare to no optimizition C version, the Red/System version is about 
1.3 times slower.
Compare to an optimizition C version, it's about 2 times slower.
Not bad! :-)
More detail: https://gist.github.com/qtxie/5835643

@Kaj, if I free the memory at the library funtion level then I lose 
the generator state all the time, I expect that not to be the best 
thing for the randomness of the produced numbers. Say I am a programmer 
and I #include the random functions file/lib. Do I need to call a 
random/free function at the end of my program yes or no?

Now we can generate the random numbers using the random algorythms. 
It is still a long way to make the random function like REBOL's random: 
http://www.rebol.com/docs/words/wrandom.html

Including a /secure that is, there are even other RNG's out there 
suitable for this purpose waiting for their transcoding to Red/System.

Yes the speed indicates there could be a possible bug, but the MS 
code is pretty straightforward and more one-to-one transcodable, 
so it might as well be right.

@Xieq, I have in plan since the beginning to add fast low-level `odd?` 
and `even?` function. When they'll be implemented, that should give 
to your code a little additional boost. ;-)

Anyway, your implementation is a good hint that Red/System 2.0 should 
be able to give us general performances between unoptimized and optimized 
C code.

Still prefer to make the choice as a programmer. How it is done behind 
the curtains is up to the compiler. Compare this with the address 
used in memory. Changing your array from 0-based to 1-based, it ends 
up in the same memory address (say that is the only change you made 
in the source). 

Besides using the 0-based structure was perhaps a struggle for the 
original programmer!!

We, no I, limited myself to keep as close to the original as possible. 
Also because of the obfusction factor of the source. I believe much 
of the construction could be made more like in the REBOL way of doing 
things. A C program just is not a Red/System program. My goal was 
to get a working program reproducing the same result in the shortest 
time. Because I had little idea what the original program did because 
it is complicating things on purpose this was the way to do it. Now 
based on this useable program it can be made more Red/REBOL-like 
step by step.

I do feel for you, for indeed a lot of stuff out there is C or 0-based 
and it brings its problems along, but the next step in bringing Red/System 
to 0-based is having Red being 0-based as well?

[...] the next step in bringing Red/System to 0-based is having Red 
being 0-based as well?


No, it's not directly related. Implementing low-level algorithms 
that require working with index 0 is not the common usage of Red. 
Also, the +/-1 offset required in such case has no noticeable performance 
impact in a Red program while in Red/System, in a tight nested loop, 
the impact could be significant.


The most important part in considering a 0-based indexing system 
for Red/System is mainly helping the user and avoiding common programming 
errors (even I get caught by it from time to time, but it's probably 
due to my strong C background).

The problem is that there is no final solution. In practice, I have 
mixed Red and Red/System code in many places, and I'm already often 
mixed up between the two. So if you change Red/System to be 0 based, 
there will be a new class of errors where programmers think in Red 
in their Red/System code, or in Red/System in their Red code. And 
as Arnold hints at, this will create an eternal pressure from technical 
people to make Red 0 based, and then we have given up on the human 
centered goals of REBOL and are back at square one - which will then 
have to be renamed square 0

Arnold, if you want to provide your random function as a library 
to other programmers, then yes, you should include a function to 
clean up its internal state

this will create an eternal pressure from technical people to make 
Red 0 based

 In fact, I've decided since a while to add PICKZ and POKEZ to Red 
 so 0-base algorithms would be more natural to implement. I need to 
 add an entry in Trello about that or I will keep forgetting about 
 it...

It's a bit confusing, but Red/System integer is as fast as unoptimised 
C (x 1 in function calling, 1.3 slower in hard integer as measured 
by XieQ), twice as slow as optimised C, and Red/System floating point 
is four times as slow as optimised C

As a function, you'd have to call that SEED or seed-random in Red/System

If you want to offer multiple functions as a library, you can wrap 
their shared state in a CONTEXT

Then you can have random/seed, but it won't be a refinement :-)

I think about a flexible solution to use the one random routine you 
want or need.

Is it a problem? :)

I consider all branches to be a development as all Red/S is still 
in alpha (or is it already beta?) version.

I don't know if it's a problem. What I do know is that the Android 
port doesn't fully work yet. If you consider it developmental, then 
you can also expect Doc to add examples later. Anyway, I was just 
providing a preliminary answer for you because Doc is offline

Quick testing of the MT Red/S and C versions on my machine give a 
~4x difference in speed.

Odd. Is that on a Mac?

So there's a much bigger difference between optimised and unoptimised 
versions than in previous tests

Compared to 6-year old GCC 4.1.2, it certainly has improved a lot.

So it's a pretty big difference in optimisation, and MSVC doesn't 
show it

We

 are a team! Yoho!! According to Frank Ruben on the Red mailinglist. 
 He has a question about interfacing a C app in Red/System.

Now in Red/System, we can't pass a function as parameter to Red/System 
FUNC,
but we can pass it to external C FUNC, right?


cmp-func!: alias function! [left [byte-ptr!] rihgt [byte-ptr!] return: 
[integer!]] 
quick-sort: func [
	base	 [byte-ptr!]
	n		 [integer!]
	size	 [integer!]
	cmp-func [cmp-func!]	
][
	; can't use cmp-func in this function
]

You should try passing the function! pointer as integer! then type-cast 
it inside the function. IIRC, function! cannot be  yet used in a 
Red/System func spec block.

I write a simple test  try to understand it, it's can be compiled, 
but the output is not expected

Red/System []


cmp-func!: alias function! [left [byte-ptr!] right [byte-ptr!] return: 
[integer!]]

cmp-int: func [
	left [byte-ptr!] right [byte-ptr!]
	return: [integer!]
	/local a b
][
	a: as int-ptr! left
	b: as int-ptr! right
	a/value - b/value
]

bar: func [
	cmp-func [cmp-func!]
][
	a: 1
	b: 2
	print cmp-func :a :b
]

bar :cmp-int

it's print a memery address ( 00401A8F in my windows 7)

Yes, because the compiler is not yet able to process `cmp-func [cmp-func!]` 
correctly. Try to declare an integer! there and then type cast it 
to a cmp-func! inside the body.

bar: func [
	cmp-func [integer!]
	/local compare result
][
	a: 1
	b: 2
	compare: as cmp-func! cmp-func
	result: compare as byte-ptr! :a as byte-ptr! :b
	print result
]

bar as-integer :cmp-int

AdrianS: do you have a previous version already installed? What is 
the installation error message?

It's a very nondescript message - "App not installed"

The only reasons I can think of for that issue are:
1) Not enough internal memory available for new apps.
2) You have a debug version of the same app already installed.

Nenad, I've installed all kinds of apps by sideloading. Even one 
from you a while back, where the app ran, but all it showed was "Hello" 
as the title of a screen with no other content. Not sure what the 
difference is with the latest one you linked.

The difference is that the new one is supposed to work. :-) Have 
you uninstalled the previous one? (It was most probably a "debug" 
version you had while the new one is a "release" version, this is 
one of the cases where the installer would block the new app installation)

AdrianS: you would need to have a look at the logcat output to diagnose 
the issue. You can do that with ADB if you know how to use it, else 
the simplest way is to use one of the logcat viewing apps, like this 
one:

https://play.google.com/store/apps/details?id=org.jtb.alogcat&hl=en

R3/Droid is most probably using a NativeActivity container, while 
Red relies on a Activity one.

It's not a big task to add armhf support to the ARM backend, probably 
2-3 days of work.

either I have mess again on my system, or there's a compilation error 
for me, when trying to do:


do/args %red.r "-dlib -v 0 %red/bridges/java/hello.red -o %../red/bridges/java/hello" 


Script: "Red/System IA-32 code emitter" (none)
*** Compilation Error: missing argument
*** in file: %structures.reds
*** in function: exec/~java-instantiate-abstract
*** at line: 166
*** near: [jni-env/jni/NewObject]

Just found out how to set a black (ICS) skin for Red apps on Android. 
Looks great! :)

That's right, you have a C Language binding to do that, don't you?

Yes, and a cURL binding for network files

There's a binary example in my 6502 emulator, where it loads a ROM 
file

It sure would be nice if we had a centralized repository for Red 
and Red/System examples, like we have for Rebol at Rebol.org.

That wouldn't scale, unless it were a repository of links

In Rebol, I can put a 'halt at the end of my script to be able to 
read output from my script.  Can I do a similar thing in Red/System?

If you have a console window in Windows that is closing, you could 
do