AltME groups: search

Great stuff guys,  been taking a bit more time to get to know RED. 
 Great work Doc, Kaj, Peter, and the rest of the testers and submitters.

However, there are no real widgets. I would have to implement them, 
or a widgets toolkit on top of Curses would have to be bound first. 
That's a bit too much work for me

Still a bit early for a prime time, as we don't have yet proper errors 
handling. One thing that would be useful though, for anyone trying 
Red, would be to dig out Peter's extraction scripts from the repo 
(in /docs), update/enhance them if needed and make a nice CSS for 
displaying the resulting list of actions/natives/mezz. Anyone?

@DocKimbel: Thanks, I have a look at it. I'm not bit stalled with 
implementation of INPUT function, I'm not sure how to delay evaluation 
until ENTER is pressed.

It is a bit confusing.

ROUND: a bit premature, we still don't have a float type in Red.

Your "construction syntax" is a bit long but accurate and meaningful 
naming.

Using [i:] instead of i: would remove the possible confusion, but 
it looks a bit inelegant.

But I need to go to dinner now, so it will have to wait a bit.

Right, adding basic float support to Red is not difficult, but as 
floats are not needed internally to build Red, they are low priority 
(but if someone wants to contribute it, it will be welcome). Moreover, 
the runtime lexer is disposable code, it will be soon replaced by 
a new one with Unicode support and more complete syntax support. 
So extending it now for additional literal forms is a bit of waste 
of time.


If someone is interested in implementing float support anyway, the 
decimal! name is reserved for a future BCD datatype, so possible 
names are: real! or float!. It will be a 64-bit float, so mapped 
underneath to Red/System float! type. A support for float32! at Red 
level is not planned, converting float! to float32! at Red/System 
level when needed (i.e. OpenGL API) should be enough.

Yep, but the fix is a bit longer.

Guys, you can just subscribe to the commits feed, and preserve your 
keyboard a bit: 
https://github.com/dockimbel/Red/commits/master.atom
;-)

Oldes: you're right, I'm becoming a bit too careless, I'll try to 
get something done at least tomorrow, then I'll go swim in the sea. 
;-)

Will be 22°C tomorrow, a shiny day, water should be still a bit cold 
though. :-P

; JS-like MAP. The order of args to the function is a bit odd, but 
is set

; up that way because we always want at least the value (if your 
func takes

; only one arg), the next most useful arg is the index, as you may 
display

; progress, and the series is there to give you complete control 
and match

; how JS does it. Now, should the series value be passed as the head 
of the
; series, or the current index, using AT?
map-js: func [

 "Evaluates a function for each value(s) in a series and returns the 
 results."
	series [series!]

 fn [function!] "Function to perform on each value; called with value, 
 index, and series args"
	/only "Insert block types as single values"
	/skip "Treat the series as fixed size records"
		size [integer!]
][
	collect [

  repeat i length? series [   ; use FORSKIP if we want to support /SKIP.
			keep/only fn series/:i :i :series ; :size ?
		]
	]
]
;res: map-js [1 2 3 a b c #d #e #f] :form
;res: map-js [1 2 3 a b c #d #e #f] func [v i] [reduce [i v]]
;res: map-js [1 2 3 a b c #d #e #f] func [v i s] [reduce [i v s]]
;res: map-js "Hello World!" func [v i s] [pick s i]

Nope, see first example. This might be a bit non/counter-intuitive, 
I will see if I can improve that.

Good progress. Nice of you to sum it up Gregg, makes the comments 
a whole lot more readable. Filename is a bit awkward though: "esceptions"

Gregg, I've reconsidered the behavior of the [catch] function attribut, 
if I change it, some use cases become even less intuitive. For example, 
the single function use case (my first example above) performs quite 
intuitively. I think the  vague non-intuitive feeling at the beginning 
comes from our habits with CATCH native in Rebol, after using Red/System's 
way a bit, that feeling just faded away. Anyway, if you have suggestions 
for improvements, it's the right time.

No need, I will process tonight as I need to do a bit more work on 
exceptions (like documenting them).

cp hold your codepoint as a 32-bit integer.

Kaj: I don't understand what you are talking about. If you cared 
about giving an example or any useful information I could look at 
or work on, your post would look a bit more constructive.

For example, there's an internal single byte encoding that's marked 
"Latin1", but I now know there is no way to get Latin-1 data in or 
out, so I wonder if this encoding will ever be used for more than 
7-bit ASCII

Actually, I did one test that confirms Andreas' statement. The only 
way to get 8-bit data in is to compile a UTF-8 string literal that 
fits into Latin-1

So, currently, only 7-bit ASCII is safe to input in the console. 
This limitation has nothing to do with Red implementation or the 
interpreter, it's a console input issue, so generalizing it to whole 
Red is inaccurate and unfair.

Actually, it is related a bit, because in both cases, you are making 
an "external" call.

Andreas and Pekr: are you using 64-bit OSes?

I might try downloading 32 bit version then ...

Will try on a 64-bit too...

Andreas: reproduced a crash on Linux 32-bit with Java 1.6.0_27.

It's now running fine on my Linux 32-bit image.

Tested ok on Mac OSX 10.6.2 (adding the -d32 option for running the 
JVM in 32-bit mode).

(checking if you're using a 64-bit VM)

java version "1.7.0_21"
Java(TM) SE Runtime Environment (build 1.7.0_21-b11)
Java HotSpot(TM) 64-Bit Server VM (build 23.21-b01, mixed mode)

hmm, now tried to delete .class files and regenerate, I obtained 
following:


Exception in thread "main" java.lang.UnsatisfiedLinkError: C:\!rebol\!Red\Red\re

d-system\bridges\java\JNIdemo.dll: Can't load IA 32-bit .dll on a 
AMD 64-bit pla
tform

        at java.lang.ClassLoader$NativeLibrary.load(Native Method)
        at java.lang.ClassLoader.loadLibrary1(Unknown Source)
        at java.lang.ClassLoader.loadLibrary0(Unknown Source)
        at java.lang.ClassLoader.loadLibrary(Unknown Source)
        at java.lang.Runtime.loadLibrary0(Unknown Source)
        at java.lang.System.loadLibrary(Unknown Source)
        at JNIdemo.<clinit>(JNIdemo.java:9)

Yes: Exception in thread "main" java.lang.UnsatisfiedLinkError: C:\!rebol\!Red\Red\re

d-system\bridges\java\JNIdemo.dll: Can't load IA 32-bit .dll on a 
AMD 64-bit pla
tform

Pekr, I'm afraid you'll need to install a 32-bit JVM to make it work 
with Red.

sho should I download whole 32 bit JDK?

The first class files where generated on Andreas 32-bit machine.

You might need to uninstall the 64-bit version first.

they can't coexist? Btw - so 64 bit version is no go ATM?

Looks like -d32 option is working on OSX only, so a 32-bit JVM is 
required on other platforms.

(My .class files where generated on a 64-bit machine, but that does 
not matter.)

Anyway, Android is using a 32-bit JVM.

The exiting crash is related to running it in a 64-bit JVM, which 
is not supported.

Working in Android Studio a bit, looking into structures, what does 
it support, etc., I can't foresee, what our aproach is going to be, 
so lookinf forward to it. E.g. the IDE generates GUI definitions 
into XML files, ditto various configs, translations. So - what I 
expect is that you create basid .apk with certain featureset, and 
from that on, it will be manipulated from Red side. Justo wondering, 
if we will be able to dynamically generate UI elements, etc? Or will 
you suggest ppl to use your basic .apk, do certain work in Android 
Studio, and the supporting backend in Red? Or is your idea that ppl 
should not need to eventually touch sw like Android Studio?

The following directories will be made group writable:
...
The following directories will have their group set to admin:
...

Hm, that's a bit disturbing, that it changes my system, isn't it?

It reminds me a bit on my RedHat days.

Do you have a 64 bit system?

Hm, then you have to find out how to get Homebrew to compile 32 bit 
versions of all that

It uses only libraries known to be shipped with OS X, so it's just 
the one executable. But you do need 32 bit versions of those libraries

John, it looks like you can supply a --universal option to brew to 
build both 64 and 32 bit versions

Well, we will see, what is Red's parse going to be about. I expect 
Gab to implement his compile rules, or something like that. Actually 
I never investigated his system, so we might get a bit different 
stuff, who knows ...

@Doc : So the text msg is really missing - only the Window's name 
is appearing on my device - Phew !!! I was not disrturbing you for 
nothing at least! Hope the last log results could help a bit - but 
don't stress too much if your time is limited (rare) and I suppose 
it is .... thanks for the screen capture you sent.

I guess a 32 bit driver wouldn't work on 64 bit Windows?

#define is_odd(x) [(x) and (1)] ; test on the unit bit of x

CPU are optimized for 0-based accesses. Using 1-base indexing will 
make Red/System a bit slower than it needs to be.

If you use it as unsigned, you have to check very carefully what 
you're doing with the highest bit

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

I'm trying to load binary data to perform some bit-level operations 
on it.

I have this bit of Red/System code that I wrote, but for some reason, 
it just closes the console window.  So I don't know if there is an 
error, and if there was, how would I debug it?

#include %../C-library/ANSI.reds

img1: as-binary 0
size1: 0
img2: as-binary 0
size2: 0

img1: read-file-binary "img1.bin" :size1

print-line img1
print-line size1

print-line as integer! img1/1

img2: read-file-binary "img2.bin" :size2

print-line img2
print-line size2

img3: as-binary size1

i: 0
until [
	i: i + 1
	img3/i: img2/i - img1/i
	i = size1
]

write-file-binary "img3.bin" img3 size1

until [no]

@james_nak, thanks for testing. Your issue is probably related to 
the fact that the output area in this demo has a fixed height, so 
it probably is a bit out of screen on your device, that's why you 
can't see the first output value.

Delay: yes, I need to optimize the starting process, it can be a 
bit slow on older devices.

I am running this on Windows currently.  XP 32-bit.  Here's the complete 
code:

#include #../C-library/ANSI.reds

img1: as-binary 0
size1: 0

img1: read-file-binary "img1.bin" :size1

i: 0
r: 0
g: 0
b: 0
im1: 0
until [
	r: i + 2
	g: i + 3
	b: i + 4
	im1: as-integer ((img1/r / 3) + (img1/g / 3) + (img1/b / 3))

 print-line im1 ;as-integer ((img1/r / 3) + (img1/g / 3) + (img1/b 
 / 3))
	i: i + 4
	i >= size1
]

Your code could be optimised a bit :-)

I've found the trailer better than the movie, I was quite disappointed 
(I'm a huge DC comics fan)...the "epic" moments weren't that much 
epic to me, so the whole movie (2h30) was a bit borring...The Krypton 
civilisation and display technology were the most interesting parts 
to me. ;-) Actually, the movie reminded me a lot the "Tree of Life", 
like a mosaic of sequences, and with almost the same soporific audio 
track... No real breathtaking moments...Even the mandatory "love 
story" sounds fake... The fx +  3D was too much to me, you're quickly 
lost in the fight sequences. But that's just my opinion, others might 
like it very much. ;-)

Thanks. The right position for the menu is a bit annoying, but I 
guess we'll get used to it...Still I prefer the previous layout.

Here's the troubling bit of code:

	dirs: make-c-string 1024
	dirs: read-file "to-process/dirs.txt"

	eol: make-c-string 1024
	eol: find-char dirs #"^/" ;Finds the first end-of-line character

 line-len: as-integer eol - dirs + 1 ;Add one byte for the end-of-string 
 character
	first-line: make-c-string line-len
	copy-string-part dirs first-line as-integer eol - dirs ;reversed
	first-line/line-len: #"^(00)"

Shouldn't 'find-char dirs #"^/" return the first newline byte?

My motion detection executable on the Pi is 30KB.  The same executable 
compiled for Windows is 15KB (50% the size).


Red currently emits only the standard ARM opcodes, so 32-bit per 
instruction. We'll add support in the future for Thumb mode (more 
compact instruction set). In the meantime, you can try to activate 
the literal pools by adding the following option to the Linux-ARM 
config block (in %config.r):

literal-pool?:	 yes


That should both reduce final binary size and give you a little speed 
improvement. But be sure to test is well as this mode has not been 
much used yet. Also, it might fail to compile if you use very big 
functions, or a lot of code in global context.

Does look to be a bit closely guarded but here are some links that 
may get you going for PDB output  -> http://ccimetadata.codeplex.com/wiki/search?tab=Home&SearchText=pdb

As for news channels - if there is anything new, and my time and 
skills permit, I do post. It is a pity, it is not reposted to your 
blog, it looks really dated with latest 0.3.2 Repl release :-( I 
find it a bad strategy, the project seems a bit stalled, at least 
Git get propagated there ....

I think that the far future plane is to have Red be made in Red.. 
now it's a little bit fake:) Probably to make it easier for potencial 
newcommeres.

FYI, I've been mostly offline these last days as a friend of mine 
came to visit me from Paris. Also, that's the moment my Windows chose 
to die, not sure if it was triggered by a hardware issue or not. 
So, I'm now in the process of setting up a new system, moving to 
64-bit and bigger disks. I hope to be able to get all my tools back 
by tomorrow, so I'll be able to start committing changes again.

Is that on a 64 bit machine?

(But to clarify a single bit: currently the plan is for MOLD/all 
0.1 to yield "0.1".)

Most of the characteristics of R3's module system are the result 
of combining the system model of R3, the binding model of Rebol, 
and Carl's goal of simplifying things for developers not familiar 
to modular programming. Every bit of syntax that Carl wanted to be 
optional or minimal in order to make things easier for end-developers 
had semantic consequences. The runtime library lib, for instance, 
is the result of having to manage a modular multithreading system 
that can be used by scripts that can be written as if R3 were single-tasking 
and monolithic like R2. Doing that requires that modules have certain 
characteristics (such as a name).

If R3's system model changes, that *would* affect the semantic model 
of modules. Right now the task! model is a bit underspecified and 
extremely underimplemented, and the module system is built around 
Carl's proposed tasking behavior. If that changes, as it might since 
Carl's proposal isn't fully implemented yet and is incomplete even 
in spec, then we might have to tweak the semantic model of modules 
accordingly.

One interesting use of isolated modules is to use IMPORT/no-share 
to force a module to load isolated even if it wasn't written for 
that. This is a way to use modules that are too messily written, 
that make too many unnecessary changes, and try to limit the mess 
a bit.

has much changed wrt bind for Rebol 3? I see, for example that this 
line (under 'Variables') in the Bindology section on rebol.net returns 
true whereas it used to return false with R2. Is that article 

variable? /rebol

Just a bit lower this:

o: make object! [a: none]
o-context: bind? in o 'a
same? o o-context ; == false -> now returns true

Is there an R3 specific explanation of binding?

saves a bit of typing out the whole spec

Yes it is.  Now we're getting a bit technical in a learning sciences 
sense.  One of the things that makes a classroom such a rich learning 
environment is the presence of resources that mediate learning. They 
provide a medium through which learning activities can take place.

Um...a bit of unexpected behavior here on the Linux ARM version of 
R3:

>> 6.63 / 59
== 0.

>> 6.63 / 59.0
== 4.

Neither are correct.

RANDOM help: "Pick a random value from a series" . The text looks 
a bit inaccurate to me. Wouldn't one of:

Randomly pick a value from a series

or

Pick a value from a series at random


For me, these reflect more accurately what is random. Any opinions?

What was wrong with the R2 text?

  "Return single value from series."


But the doc string for 'value isn't helpful with regard to series 
values either.

I would make it a bit more readable though.

  Return a single value from the series.

Example (allow me to be a bit "unreasonable"):

random/seed 0
block: reduce [1 2 random 100] ; == [1 2 31] (in R3)


now being ordered "Pick a random value from BLOCK" I may (not very 
intelligently, I know) expect that I am required to pick 31 because 
that is the only random value in there (absurd, but compatible with 
the text, as I see it)

This means that the difference between an ASCII character and a higher 
Unicode codepoint is significant. ASCII characters can be detected 
with a single byte of lookahead. Higher codepoints require multiple 
bytes of lookahead. That means that for most parsing models any rules 
that require multi-byte stop sequences are quite a bit more complicated, 
slower, and for some parsing models impossible. So I'm hoping we 
can fix this.

Yeah. It looks like it just calls open, which can be a bit of a hole. 
It's better for now but we need to come up with a better solution 
in the long run.

The multitude of defines for platforms in the same "major" group 
is a bit of an annoyance as well.

Yes that was what I mean, sorry, English is not my main language, 
so it is a bit difficult what I exactly mean.

I don't see it in the experimental 64 bit build either.

Looks a bit odd.....

In R2 it doesn't work if the val is a block! but it does with hash!
In R3, block! doesn't work but map! does

Test code:
   val: make map! [1 2 3 4] switch val reduce [val [print 1]]

BrianH: I used 'for quite a bit in R2.  But I used it simply when 
I needed access to a counter.

For those not following closely, the discussion about FOR is trying 
to clarify and document its behavior, while keeping it easy to use 
(e.g., avoid accidental infinite loops). Ladislav has also asked 
for better names for CFOR, his general loop func that is efficient 
and flexible, but requires a bit more care in use. There is also 
a general consensus that FOR takes more args than we would like, 
while noting that we have other looping funcs we can use in most 
cases.


I propose a new LOOP implementation that is compatible with the current 
LOOP func (and delegates to it internally), while also providing 
a dialected interface which is a wrapper to CFOR.

:-) Let me play with an idea here for a bit.

Let's widen the discussion a bit. Spitting a string at a delimiter. 
Easy enough to define clear behavior if the series contains the delimiter, 
but what if it doesn't? Most split funcs return an array, splitting 
at each dlm. If no dlm, return the original series as the only element 
in that array. 


What if we always want to return two elements? e.g., we have a SPLIT-AT 
func that can split a series into two parts, given either an integer 
index or value to match. Let's also give it a /LAST refinement, so 
it can split at the last matching value found, like FIND/LAST works. 


Given that, what do you expect in the case where the dlm (e.g. "=") 
is not in the series?

    SPLIT-AT "abcdef" "="   == [? ?]
    SPLIT-AT/LAST "abcdef" "="    == [? ?]

For those interested in the "alpha-channel change":

Here is the branch with first round of related code changes to the 
image! and image codecs: https://github.com/cyphre/r3/commit/472c106a0f177ead82a6f29be1ae98b4cd33b9ad


Note: This code doesn't contain any graphics related changes...just 
the image! datatype + image codecs so you can MAKE images and load 
BMP, GIF, PNG and JPG files. But it should be enough to test the 
change.

(I have this code already intergated with changed AGG graphics and 
it works well but I haven't published it as this part is not compatible 
with the 'official' git source at the moment.)

Note2: the code was not tested on big-endian systems so it is possible 
there can be some quirks. Use at your own risk and let me know about 
any problems.


The RGBA tuples on IMAGE! now work so if the fourth(alpha) value 
is not defined it is assumed the RGB tuple is opaque (ie. alpha = 
255) so 0.0.0 = 0.0.0.255 etc. This way color values in old code 
that doesn't explicitly define alpha values are still compatible.


If you are interested, try to compile and test a bit. Let me know 
if you see any issues. Thanks.

I understand your view Max, but that's not what I asked. It doesn't 
work the way you want today, but maybe there's a way to provide a 
solution that is better than what we have now. I'd love to see your 
custom version, so we can compare its results. And I'm asking about 
SPLIT-AT for a reason, separate from SPLIT-PATH. I'd love to get 
everyone's thoughts.


The funny thing is how much we can all care about the details of 
this func we (at least I) use a lot, and yet which none of us seem 
to like all that much. I think it points out that the normal case 
is the most important, where there is both a path and a file component. 
And maybe now is the time that we can make it just a little bit better, 
a little more consistent.

The problem is, that while the R3-GUI is now more flexible by removing 
reactors, it is also more difficult to understand. I remember trying 
to understand the 'on-action issue in the past, now I briefly re-read 
the doc, and I still can't understand the design. I need following 
things to be cleared up for me, so that I can both use it, and possibly 
explain it to others:


1) If you look into Actors docs - http://development.saphirion.com/rebol/r3gui/actors/index.shtml#
, there is no mention of 'on-action actors. There are many actors 
listed, but not the 'on action one


2) The 'on-action actor is mentioned in the attached doc at the same 
URL, describing, why reactors were removed. So here is the definition 
of 'on-action: 

        a) "The ON-ACTION actor is useful if the style needs to call some 
        default action from multiple places (actors) in the style definition." 
        - understand the purpose, but why and when I would like to do such 
        thing? Any example easy to understand? Just one sentence maybe?

        b) "For example, the BUTTON style needs to call the default style 
        action from the ON-KEY actor and also from the ON-CLICK actor, so 
        it is better to call the ON-ACTION actor from the both code points 
        to avoid the necessity to override multiple style actors." - looking 
        at button or even clicker style definition, I can see no such stuff, 
        as 'on-key or 'on-click calling anything named 'on-action. That is 
        the part that is most confusing for me, and which did not help to 
        understand the 'on-action a little bit. Are we talking about the 
        'do-face here?


There is also a question, if better name could be found for 'on-action. 
Unless I can fully understand, what happens here, difficult to suggest. 
Now to make it clear - I am not judging architecture, just trying 
to get my head around the docs and button/style examples. And being 
average reboller - if I have difficulcy to understand it, the chances 
are, there is more ppl, which will strugle in that area?

I am quite curious whether it would be possible to fit a Rebol value 
to less than 256 bits when using 64-bit memory pointers

And I'd generally try to stay 64-bit aligned.

Hi, all, a "stupid" question: R3 is still called "alpha" (and there 
*are* issues I want solved before moving it to beta). One of the 
issues is the "gotcha" represented by the DECIMAL! name. I know that 
it is used consistently in Rebol, but it is still a "gotcha" for 
any possible newcomers actually stating something like: "here mathematics 
is not welcome", which is not true so much as I (mathematician by 
the education) would say.


Also, having a "truly decimal" datatype called MONEY! in R3, I would 
prefer a rename:

MONEY! rename to DECIMAL!

DECIMAL! rename to REAL! or FLOAT! (or something else that could 
be popular)


So, how many of you prefer to keep the DECIMAL! name for the 64-bit 
IEEE 754 binary floating point format used in Rebol and

how many of you prefer to rename the DECIMAL! datatype to something 
else?