AltME groups: search

Is there any point to continuing testing at the moment? I'm not sure 
now what reports you want

My point is: an undefined word error is a user error, and exiting 
the interpreter with an error message is currently the best thing 
to do. I've removed the exit points after such errors because you've 
asked me to for making your demos run without exiting. But I shouldn't 
have done that.

Good point, about (). :-) Will change it.

Jerry: no, these are not yet supported. You can see what is missing 
for full floats support here: 


https://github.com/dockimbel/Red/wiki/Floating-point-support-todo-list

I plan to write an HOW-TO guide for that someday, but in the meantime 
and in a nutshell, this is what is required:

1) NAT_<name> enum entry in %macros.reds (order matters!)


2) pointer entry in REGISTER argument block (same order as in macros) 
in %natives.reds


3) an entry point implementation in %natives.reds (if the code is 
too big you can move it elsewhere as long as the entry point is in 
natives.

Refinements would come in handy at some point in future, no?

Huh, it seems that both current versions of R2 and R3 are not binding 
the loop body on each call to the hidden context:


>> foo: func [code [block!] /local a b][a: 1 b: 2 repeat i 10 code]
>> foo [a: a + b]
** Script Error: a has no value
** Where: foo
** Near: a: a + b


I'm pretty sure I've seen it, maybe in older versions. Anyway, if 
current Rebol versions are not making that binding on each call, 
it makes most of my point a) irrelevant. So, you can forget about 
the binding cost. :-) Still the other concerns and limitation remain.

Arnold, the point is that Rebol makes the loop counter a local word 
in a hidden context. It saves user from having to defining it as 
local manually (I have argued above about how I think this is, in 
practice, rather counter-productive).


We need to find the right balance between human-friendliness and 
efficiency/productivity.

For MOLD/ALL, are you calling it "serialized" format in Red? And 
I assume that's a TBD at this point.

'For MOLD/ALL, are you calling it "serialized" format in Red? And 
I assume that's a TBD at this point.' Gregg, suggested reading:

http://en.wikibooks.org/wiki/REBOL_Programming/mold

On Windows I get:


The procedure entry point isNaN could not be located in the dynamic 
link library MSVCRT.DLL.

http://www.gnu.org/software/libc/manual/html_node/Floating-Point-Classes.html

The catch flags position on stack has been changed to a safer place, 
so it's now resistant to a "dirty" stack left by user code (unbalanced 
PUSH/POP actions at the exception raising point).

Pekr: you understand that building Red is not going from 0.0 to 1.0 
in one step? So, like in any other long ang complex building processes, 
you have intermediary building steps and states that are not necessarily 
representative of the final product. Think of a house in construction 
with scaffoldings, you don't point at the scaffoldings saying that 
the house will look horrible.

4) "It was announced last year that Unicode support was implemented 
in a week. What I found first is that Unicode support is useless, 
and now I've found that only ASCII is really supported." Unicode 
support has been implemented exactly as stated in (will get back 
to that point later):
http://www.red-lang.org/2012/09/plan-for-unicode-support.html

Furthermore:


Red can input some Unicode and print some Unicode. That's enough 
to support the test suite, but mostly useless in real life programs

 I must have missed the point in time when Red was declared beta. 
 :-) AFAICT, Red is not yet ready for real-life programs (Red/System 
 is though).

It's not even true that I/O is to be done, because I support it

 Reading how you put it, I just hope you still remember which version 
 is the official one? ;-)

Why is it such a problem to have some criticism, too?

 There is no problem with that, and believe me, you can't be more 
 critical on Red that I am myself. But I find it really unfair to 
 paint a bad picture of whole Red because some features that are planned 
 are not yet implemented. 


I can't go faster than the music, to get I/O done with required encoders/decoders, 
I need to setup the ports/devices infrastructure. To do that, I need 
objects support done. Also, as shown by my entries on Red Trello 
page, error! (and typeset!) support and getting a Unicode runtime 
lexer are even more prioritary to make Red "more usable for real-world 
apps". Moreover, when you manage a lot of tasks, some of them marked 
as "important" that keep been postponed because of other more urgent 
ones, will at some point become "urgent" themselves. That is what 
is happening with shared libs support, which is a blocker for getting 
Red on Android and iOS. I'll also probably make a Java bridge prototype 
this week before getting back on other Red features.

No rejected items yet, looking good! Point 5 and 17 both have a wish 
for a BREAK.

The main effect is that Red/System init code is not run when the 
shared lib is loaded, this affects floating point exceptions flags 
and runtime error catching routines. Not a problem for now.

So far adding the rswr section modifies these values:   [ entry-point-addr 
code-base data-base ] which should be same as without rsrc in my 
tests, and not increasing init-data-size.

Ok.. moving [ build-rsrc job ] after [ build-import job ] leads to 
expected result with the  [entry-point-addr code-base data-base] 
values

Would java-do [frame/getContentPane/Add ...] work?


No, as Kaj said, you need to split it in two parts. However we could 
extend the API to handle sur syntax, but at this point, it would 
be overkill.

I know .... I just tried to point out example of kind of chaining 
method calls, which I expected not being covered by the bridge. But 
as you both stated, it migh work by separate calls ....

Think of Red as REBOL that can be compiled. The main docs are for 
Red/System at this point. 

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

I/O is not in Red, only in my extensions. DO is the internal interpreter, 
so it doesn't know about my I/O. It's a good point, I should try 
to override DO

Ladislav - I don't care if I am able to use some guru system - it 
either works for me as a user, or it doesn't. Reserving something 
for gurus should not be the point. Not in Rebol imo ....

I only have R2 parsing in World today, as my initial goal was just 
to get to a point, where my R2 programs could run. It would for sure 
be an idea to look at the extensions at some point. And then desicions 
has to be made, if it should all be with extensions, if there should 
be more than one way of parsing, if it should still be mezzanine 
or made in C, or maybe some JIT compilation. Many options. :)

Me too - thanks Andreas - So I regretfully missed the point basing 
my view on the previous Red/System Hello.apk. - Really Sorry Doc 
for this misconception. Just thinking that I should have looked at 
the source code instead of being like a blind - asking unuseful questions. 
I'll take note as to not disturbing anybody in this way in the future....

I will clear both scripts from the extra display's I built in during 
debugging.

Optimisation? Just hit build in XCode, happy it does something. You 
want the sources when I am ready cleaning them up? 

I thought about looping it a 1000 times each and see how it performs, 
but that is maybe only for more digits beyond the decimal point..

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

Unsined integers is on the wish-list for Red/System v2 https://github.com/dockimbel/Red/wiki/Red-System-v2-Wish-List
point 29

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

Doc, I don't know if you've done other tests, but in the benchmarks 
so far Red/System was only 4 times slower than optimised C in floating 
point code. For integer code, it was around twice slower than optimised 
C, so the Mersenne Twister confirms this

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

Which also means that Red/System floating point is twice as slow 
as unoptimised C

XieQ - that's what Doc stated, no? you use cmp-func! function type 
in func spec block, which is not allowed (except the external functions, 
whatever that means). Sorry if misunderstood on my side, just trying 
to point that out ...

I guess I should complete the function! support at some point before 
starting on Red/System 2.0.

Red has no floating point yet, only Red/System

At this point I am stuck on the sun.security.tools.JarSigner file 
issue.

You can't call Red/System functions in Red

 that almost literally made me fall of the chair. Somehow I really 
 expected that to be inherently supported. I cannot make any chocolat 
 from the routine example atm, but as I see it now, it requires me 
 to reprogram/copy my Red/system program to Red and renaming FUNCTION 
 to ROUTINE. This means double maintenance in my eyes. 

This is definitely a point to add to the wishlist if you asked me.

Garbage collector, error trapping, objects, floating point, PARSE, 
other complex datatypes

However, the driver just has a skeleton success return entry point, 
it doesn't try to take any devices or anything yet

Bo: The issue I had to fight with in my hotel room was just that 
my own prebol replacement lib was adding  an extra layer of MOLDing 
to the input source, because of the workarounds to avoid the #include 
(and others) directive collisions. This resulted in disabling some 
parts of the code leading to  odd runtime errors. I couldn't focus 
enough on it to see it that night because I was too exhausted and 
wanted to listen to the discussion at the same time. :-) (For others: 
my room was a kind of meeting point in the hotel ;-)).


To debug that, I reproduced the preprocessing changes step by step 
in a console until I located the "disabled" parts of the code, once 
I PROBEd those parts in the console, the cause was clear and the 
fix easy.

Doc and/or Kaj, at what point will we be able to use Red and R/S 
to start things off by programming the MBR and jumping to a Red OS. 
What I am interested in is learning to use Red and R/S to build a 
native O/S from the ground up as this is the best way to truly understand 
computers. Also a PC that is Red and R/S from the ground up is a 
very exciting prospect.

We'll to that too at some point in the future.

Not sure why it's like that .. should fix it to point to the correct 
URIs

And is there any point in uploading the html docs?  Since they have 
to be generated

I wonder, if it's worth getting a Raspberry Pi at this point and 
try compile World to it.

Robert, if it's extra work to make it work with earlier versions 
of OS X, then maybe you shouldn't use too much time on it. We can 
just upgrade to latest OS X, which at least I will eventually do 
at some point. Maybe some hardware can't be updated, I don't know.

Another point of MDP2 is to retain the single-script ease of use 
that MDP has, as well as being REBOL based.

I've been rather dormant in many rebol spheres in the last months 
because I've been working a lot and most of it is commercial and 
private work, but I feel like its time for Rebolers to break out 
of their inferiority complex and show others that Rebol is better, 
more cutting edge than ever.  

And it still stays simple, overall, even in large projects.


I think the community has lost a bit of its resolve, and I am trying 
to make a point with the devcon.  Rebol has never gone away and its 
back on track.  


I think its up to everyone involved in public projects to promote 
this by actually playing on Its strengths.   I resisted the urge 
to build the site using public tools, and I think, Chris and I and 
building a super default framework just by catering to the needs 
of the devcon's web site.   Chris just added a news module to it 
(in one day).  we will show the site's internals at the devcon, showing 
how easy it really was to build up, using a centralized Git Repo 
to share the code and with the server, when ready for production.


Its ALL coded with REBOL.  at the devcon, we will look at packaging 
QM with cheyenne, Remark and making sure it all works with my web 
service API... with this l think the rebol community will have a 
pretty nice framework to rival RR and others.

@Gregg, asciidoc uses a header *because* it's a document formatting 
tool.  There's a variety of styles supported .. and it's a pain to 
try and remember but I guess it gets easier with use.  The point 
for me is that it provides entry to docbook and then multiple other 
formats whereas makedoc/pro are stuck in a single page style html 
which is really past it for any serious documentation.

@Arie, wrong group Announce. Bas already pointed this out. (Softwarefreedomday 
is his channel). I do not want to steal viewers from Bas' channel.

The point is I want to use this new channel as a dedicated channel 
for Red (and REBOL) specific video's. I imagine this being used by 
this community to post self-made tutorial video's on. The softwarefreedom 
channel is much broader than this. One does not exclude the other.

Why not use separate channels for Red, Red/System and Rebol respectively 
or conversely using a family name like "Rebol-like languages" or 
"Rebolish" or something similar ? Personally I prefer using separate 
names, even splitting furthermore amongst Rebol2 and Rebol3 ... but 
this is a suggestion only. In the end I also see some specific place 
for Boron, World, and Topaz but then everyone should point to the 
others or to a single "entry point portail" which points and summarizes 
the évolution and differences while it could alos only point to each 
of the specific related websites, as they appear  !!!

Guess I'll have to consider an Android device at some point now. 
:-)

Guys, this is great news! My first reaction was to get it posted 
on the MSDN site, but I'm not sure that reducing the need for Microsoft 
tools would be viewed as a positive thing from their point of view. 
It should be, though, since simplifying Windows driver development 
leads to more peripherals/accessories being integrated with the OS. 
It's a win for everyone (well, I guess not for the rabid anti-MS 
crowd). Between this and the similarly simple mobile dev that's coming, 
Red and R/S will be unbeatable.

I hope to be able to provide a general-purpose virtual drive system 
for Red apps at some point (would be nice if this was contributed 
or sponsored).

That's my best guess as to where the problem is happening, but I 
haven't gotten to that point yet.

Still, all of that can be added on or retrofitted, that's the whole 
point of being modular. Having them implemented and available before 
3.0 would be a good idea for marketing reasons (don't knock those, 
they're important), but not having them done before 3.0 won't break 
user code the way not doing core semantic changes before 3.0 would. 
People will be working on these before 3.0 comes out because they 
need them, and the ones that we as a community consider to be the 
most important to include in 3.0 will likely be worked on the most. 
But the great part about that stuff is that it doesn't have to be 
developed as part of R3 itself, just like the GUI is being developed 
separately.

Just because it's modular doesn't mean it can't or won't be bundled, 
and in many cases imported by default. We can do one-exe builds with 
modules inside, that was the point from the start.

(Replace file:/// with anything else, I think the point stands.)

For #1991 se need a better approach. We aren't at the point where 
we would need to disable a feature while we wait to figure it out, 
at least for something you have to explicitly call.

well, I can imagine more scenarios, and it needs some thought to 
stay consistent between the cases. So my first thoughts, starting 
with the latest example:

for i 2 1 1 [prin "x"]


If above scenario means returning #none (and I agree with that), 
then I think that the for i 1 2 0 [print "x"] could be just the same. 
But - it might be related to the thoughts of the indexing. In REBOL 
series (if I am right), the position is in between the elements (not 
on the first element). So in that regards, skip 0 moves nowhere. 
But - it might also mean (as "first series" returns first element), 
that it should perform the loop just once. 


The last option for me is to cause an infinite loop, although from 
some point of view, it might make some sense too - you simply want 
to traverse the range, from 1 to 2, but you skip 0. If you would 
use just 'skip, you would cause an infinite loop. So - I really don't 
know ....

for i 1 3 0.2  [print i] ; prints 1 ... 2.8 (end value is not included)

 - this is an arithmetic problem; 0.2 is not representable exactly 
 by a binary floating point (i.e. decimal!) value.

This is an excellent question Ladislav. What if we start with the 
doc string:

  R2: Repeats a block over a range of values.
  R3: Evaluate a block over a range of values.


That makes me think 'bump has to be non-zero, and it should throw 
an error. It should also throw an error (under R2) if 'start and 
'end are series values and won't terminate (e.g. empty series). R3 
does this now. That is, FOR should always terminate.


R2 allows char! values, R3 does not. Under R2 specifying an 'end 
of #"ÿ" (char 255) also results in an endless loop. My RANGE func 
tests for that, because it caused me a problem at one point.

We can't really discourage anything because we don't have "warnings" 
in Rebol (no way to implement them without a logging facility, and 
no point in logging them without a precompiler). It's allowed or 
it's not. If it's allowed (in R3 at least) it's because it's part 
of the intentioned model.

So the question we're posing is whether we want the developer to 
be able to manually affect the FOR loop process from the inside (a 
feature, useful for advanced developers), or whether we want the 
loop process to be inviolate regardless of changes to the index in 
the code (another feature, useful for compilers that might want to 
unroll loops). Given that we don't have a compiler, that suggests 
that affecting it might be a useful feature, but Red compatibility 
and the overhead of checking the index value rather than just setting 
it based on an internal value in native code suggests that the latter 
might be better. There is no point in discouraging anything, since 
there is so much overhead to allowing it at all that we should only 
do so to provide a feature explicitly.

in languages like C  the for loop is the basic iterator and it should 
be completely open.   but in REBOL we do have a lot of purpose-built 
iterators, I think FOR shoudn't allow non advancing steps and should't 
allow the inner loop to affect index.   This would make FOR faster 
for its primary purpose.  


I don't see the point in trying to make every different iterator 
another interface to while/until

Ladislav, that's a feature list, not a dialect. It's a great feature 
list, and when we're building the dialect we should take all of that 
into account. But what you suggest in CFOR is not much prettier than 
FOR, and is almost as ugly as C's for loop. It's powerful, but not 
something we can point to and say "Look at how powerful we are!" 
to people who don't understand that surface stuff doesn't matter 
when you're talking about power. Imagine people who haven't heard 
of big-O notation or Turing completeness, but have used Python or 
Ruby. Especially Ruby because of how pretty it is but how much it 
sucks beneath the surface.

CFOR, EVERY etc

I'm happy with FOR as I do not need to construct and perhaps REDUCE 
a block to set up variable start conditions -- just have to set words 
to values.

For me, the syntaxtic sugar neatness of the new proposals is outweighed 
by the simplicity of the setup for the existing method.


No real opinion on how to standardise the existing behavior other 
than to reiterate a point Brian has already made: FOR start and end 
can work on series too; all the examples I've seen of proposed change 
behavior is for numbers. We need to ensure thar series FORing works 
as expected too.

The whole point is to avoid accidental infinite loops.

Brian, can you point out which test case is incorrect, and what it 
should produce? That way we can match against Ladislav's examples.

R2's original target market was newbies, but it kinda failed to hit 
that market. So at this point R2's target market is existing R2 users.

if it where a generic string handling function I'd agree with you... 
but its not... it has added meaning, it splits filesystem paths. 
 its not just a string.  if it where, I'd use parse or some tokenize 
func.

I see absolutely no merit in trying to make split-path act like a 
generic string handling func.  the point of the func is to separate 
folder and file into two parts.   to me it comes down to either you 
decide that when there is no data you invent a default, or use the 
internal one which is none, which works well with soooo many other 
funcs.  if there is no directory part in the path, do not try to 
find a suitable value for it... there is none... funny, even when 
trying to explain my point of view, the actual sentence reads almost 
like a line of rebol source.  :-)

I think ppl in kind of an wait mode. Some interested in Android in 
general, some interested in Red progress, som interested in Ren, 
most of us busy other way.  Max in fact is doing a good job - he 
tries to use the system in a practical way. My questions are just 
theoretical, just by reading docs and looking into the code. I know 
I will be back to GUI at some point, just dunno when ...

Point the "frame" to the full function value instead of just the 
function's body.

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?

If counting just the votes for/against naming the IEEE 754 binary 
floating point datatype as float! and adding BrianH as one who prefers 
the decimal! name for backward compatibility reasons (he perceives 
a datatype name to be influencing language syntax in a big way) I 
am currently getting:


For float! name: Ladislav, Henrik, Andreas, Gregg, Robert, Doc, Rebolek, 
Endo
For decimal! name: BrianH

I would like to get more votes on this, though.

Carl blog about "Currency designator for money datatype" http://www.rebol.net/cgi-bin/r3blog.r?view=0201

Carl stated in its reply "4.  No, we are not renaming decimal. It 
will remain as is." just to remember us.

So:

1) current R3 money! datatype is not a money type as R2 define it. 
So it can be renamed.

2) Should the actual R3 money! be renamed decimal! is againt Carl 
point, but I'm not against it if we ponder the compatibility issue 
(BrianH point).

3) decimal! -> float!  I don't like it but  Icould probably leave 
with!

4) a money! type must be considered as a BCD + currency type. A "must 
hvae" would be the possibility to programmaticaly define the rules 
to apply if mathematical operations arrived between different currency 
numbers. So it can throw an error or apply a conversion or change 
the resulting currency...
A dialect would be used to specify the rules :

money-rules [* M M currency M²    / M M error     / M² M currency 
M       + EUR CDN error     + EUR USD multiply 1.30800]
Think ">> M$2.0 * M$2.0     == M²$4.0"

I don't think people are against a money! type per se.   we are just 
against the current datatype names assigned to implementations.

decimal! is not a decimal type
money! is not a currency type


we simply need to add a new real number type called FLOAT! and  properly 
assign the current types to what they really are.


shifting the implementation of money! to decimal!  (without its $ 
or currency designation) won't actually break any previous code a 
part from making it more precise and possibly a bit slower.


we can always keep the current money! as-is, but  I see no point 
in it.  since it doesn't actually do any type of currency management.

The speed difference must be at least (actually, it should be even 
greater a bit due to the deimal nature) equal to the difference between 
floating point arithmetic done by the coprocessor, versus it being 
done by an emulator.

Gregg, good starting point. I was looking for something like a simple 
diff version to identify the code parts needs to rewritten

and estimate the workload when migrating R2 to R3. Ladislav, will 
talk to Robert. Thanks for info.

pair! can be floating point in R3. Is there a reason, it wasn't made 
a new datatype?

Otherwise it's unmanageable. Since there is no single point of R3 
project at the moment, it doesn't make sense to spread information 
on several places, get them out of sync etc. We need one place, where 
people know what they get.

I see your point, but it just raises some concerns in relation to 
REBOL. For example, /* is a valid refinement:

>> type? /*
== refinement!


So some might wanna make a shell command in REBOL to be used at the 
REBOL prompt, that reads /* as all the files in the root directory, 
like

	LS /*

That will not be possible, if /* is part of a comment.

I don't think REBOL should support it Giuseppe, but you can write 
a dialect that does. Carl mentioned at one point that he considered 
allowing "filler" words, but decided against it. I sometimes allow 
them in my dialects.

Giuseppe, all I'm saying is to experiment first. Dialects are great 
for that. I'm not against all verbosity, and was reminded recently 
by an article I read that we can add value by adding information 
and structure to our programs. And I think the idea of the editor 
knowing, and highlighting, filler words is great. At this point, 
and I'm happy to be convinced otherwise, the standard REBOL interpreter 
should not handle it.


Is REBOL more like math or natural language? Would you implement 
comments the same way if you said "Math"?

avconv (formerly ffmpeg) is open source, so I imagine some or all 
of that could be used as a starting point (if the licenses are compatible).

Well, I was originally against /REDO, taking a more moderate point 
now, but, as I said, I am not sure there was an agreement to remove 
it.

Hmmm...interesting behavior.  I am trying to use R3 to act as a TCP 
server on Linux-ARM.  Here's a code snippet:

	if probe port? prt: wait [1 camsrv][
		probe cmd: copy prt
		call/wait reform [cmd "> cmdout.txt"]
		insert prt probe read cmdout.txt
		close prt
	]


The probe at the top returns 'false when there is no TCP activity, 
but it returns "TCP-event accept" when there is, and then it just 
sits there.  Escape (ESC) and CTRL-C will not break out of R3 at 
that point.  CTRL-C just outputs "[escape]" each time it is pressed, 
but doesn't escape.

So, what's interesting about it is, that one gets access to a complete 
vertical technology stack. The black-box dependencies (those that 
you can't influence) are mostly zero. Of course you don't have a 
big community, eco-system etc. around. But I'm coming more and more 
to the point that I don't need a big eco-system, I need the right 
eco-system. I don't want to use big frameworks, zillions of libs 
etc. This all makes product development a hell.

Nice, Henrik!


I do that sort of stuff all the time, and I am sure others do too. 
So to have it as a single item is a good thing.


One small point -- your way of extending the existing object works 
only for single-level values....I often have configuration objects 
that have sub-objects. A field added to a sub-object would be missed 
by your code.  Take a look at:

http://www.rebol.org/cgi-bin/cgiwrap/rebol/view-script.r?script=extend-an-object.r
Which was created for this sort of purpose.

One point that would make it simpler : you didn't used 'of keyword 
for your tog style.

'of keyword allow to group toggle, radio or checkbox in order to 
reset others while you set one.
Like this you don't need 'update-tabs functions :

Henrik --- One question: how good is the SEO on your site? Little 
point putting cookbook entries where they are hard for the world 
to find.


One idea: why not write a wiki-formatting to HTML function (you'll 
need it anyway) and donate it to the Library ?.....

.... REBOL.org can then accept cookbook entries and other articles 
in wiki format --- we already accept all other major formats: MakeDoc, 
NicomDoc, eText etc.  And we do have good SEO.

Volker, I've just begun to really get into the dialect so I can't 
comment on how one "translates" the actionscript into it, however, 
the actionscript pdf is at least a start into trying to figure out 
the examples.

At this point, I am taking one of the examples from the flash actionscript 
pdf and rework it into the dialect form. Before I had this documentation 
I was just guessing at the whole process.

Yes, you're right. Up this point I was really looking at the wrong 
documentation so the Actionscript clue was helpful.


Here's an example. I haven't tried to translate it yet. It looks 
pretty straight forward. 

Movieclip.prototype.fade = function(speed) {
this.speed = speed;
this.f_index = this._alpha;
if(this.f_index >= 100) this.fade_by = -this.speed;
if(this.f_index <= 0) this.fade_by = this.speed;

this._alpha += this.fade_by;
}

Or you can use these to fadeIn() or fadeOut()


Movieclip.prototype.fadeOut = function($decrement, $fadeLimit){



	var $mcObject = this;

	//If $decrement is not defined, then define it

	if($decrement == undefined){

		var $decrement = 11;

	}//End if



	if($fadeLimit == undefined){

		var $fadeLimit = 0;

	}//End if



	if(eval($mcObject)._alpha < $fadeLimit){

		return(true);

	} else {

		eval($mcObject)._alpha -= $decrement;

	}//End if



}//End function

Parts. That's the whole point. That means I won't be able to port 
it on other platforms, because I need the source of the whole thing. 
(I'll be happy to be proven wrong).

it's not the only point, i'm wondering why have no killer apps

hmm, just looking at sources of mySQL and I can find pthreads are 
there, so they might use photothreads? Carl once wanted me to remind 
him of that. So Jaime, if you know libevent is considered for even 
loop, you might once again point Carl to http://www.sics.se/~adam/pt/
, but maybe he has already decided how to do such things properly 
for REBOL 3.0 :-)

Funny enough, I will be posting soon two articles: "Why I don't use 
the Mac" and "Why I don't use Linux"  and I was going to open this 
up to everyone to do battle with me on each point.  The idea being 
that all can learn from this and make the move to the machine they 
like best.  For some people they might read one of the articles and 
say "those five things don't matter to me, so I'm going to buy a 
Mac now" 


For others, it will serve as a thermometer of when it is worth going 
to Mac or Linux.