AltME groups: search

Actually, I am trying to send 50 on a month basis. Now r3 gui project 
is temting too, but i would have to see the project outline, eg seeing, 
that cyphre will be paid to update the engine to use hw acceleration, 
etc. I would love View engine to be useable with Red too. I ca feel 
some excitement last few weeks, fort both r3 and red projects :-)

Gregg: I have already code for a R2-like console (as shown by Rsharp.exe), 
but anyway, if I can find someone willing to do it and skilled enough, 
I would be glad to delegate that part.

I added a checklist for consoles and IDEs. Put suggestions there 
to gather ideas.

A partial system object was even present.

I have fixed the main issue in Red runtime for the REPL to work properly, 
now I just need to extend a bit the tokenizer (LOAD) to handle  blocks 
and a few more details before releasing the code. The current tokenizer 
is very crude, I will rework it in the next days.

@ Doc, Thanks a lot for this REPL implementation. this is welcome 
for newcomers I think.

Debugging features: sure, but maybe not the same as R3. I have a 
`stack` native in my notes to add, not sure what `hooks` refers to?

This is just a 4 days work, most of the code was implemented in the 
first 24h, the rest was spent debugging it and adding minor features.

I might also implement a cross-platform console if nobody shows up 
to do the job.

I will also probably make a new major release, bumping the version 
to 0.4.0 when the REPL will be completed.

Currently yes, I thought making a ncurses-based one too, but my time 
was sucked out by bugfixing.

Don't you have a Windows VM on a Linux box?

Gerard: thanks for the links. It is too early for debug hooks, when 
Red IDE will be there, it will be completly integrated with Red, 
so those debug hooks as a public interface will probably be unnecessary.

Thanks for your last reply Doc. It's interesting you'va such a golbal 
vision !

For the stack, I was planning to add a stack trace on errors display 
in Red, the current REBOL error report is too poor to be able to 
quickly and accurately locate the code lines involved.

Just a small notice: please do not post yet any bug reports about 
the REPL to github, it is too early.

@Gregg : "I'll match donations made by 31-Dec up to USD$200"  I just 
spent 100 Euros a few minutes ago  (about 135 $ CAD) -  Sorry! my 
personal funding is not good enough to give more ... at this moment 
! Xmas is a past thing now so I plan to do better with the New Year 
coming ...

@Doc : Don't despair Doc. We are all behind you - even if I don't 
code for now, as I'm a first day addict, I'll follow your efforts 
regularly and other's too! May be some day I'll be able to send my 
own code ... for something useful !

Yes, that was the idea from the beginning. Until now, I have implemented 
only datatype registration (just missed a dynamic type ID attribution).

Gerard: thanks very much for your support! I have good faith in Red 
and its future. I have a strong will to make all my plans for Red 
happen. If I can continue to work on it fulltime for a year more, 
I am convinced that, one way or another, Red will have its momentum 
far beyond the AltME community.

@Doc : About the R2/R3/Red console enhancements, I've always missed 
the MS way to move/select  from left to right (on a word by word 
basis - MOVING on a word-by-word is CTRL+left / right Arrow and adding 
the SHIFT key in combination with the CTRL means SELECT - it's that 
simple) but going to the beginning or ending of the line is at least 
a welcome start ... if we want to go this way - and then going right 
or left on a character basis - as is for now!  And for right-handed 
ppl it would also be welcome to restore the old MS way of handling 
the current left-handed ppl to do CTRL-X / C / V  - which were CTRL-DEL 
or SHIFT-DEL / CTRL-Insert / SHIFT-Insert - but this kind of thing 
I can add myself when time comes ... it's just a matter of being 
more productive - it's far from being a "caprice des Dieux". For 
opponents : If you've never experimented it - you then never used 
it either on a regular basis and you can't catch why I regret this 
not being supported anymore in recent MS software too ... but this 
is deceptive either from them since it costs so few to leave it there 
in the first place. However I must admit that on my iPhone and other 
mobile tools I will miss it in anyway - until I code my own keyboard 
for this use too !!!

But Doc I dont' plan you to code these enhancements - it's just a 
reminiscenceof what I had to leave behind with the years that I found 
useful to me - but hard to memorize at first.

@Doc : I never thought you would do so much work in a so short time. 
If my support can help you a bit to go further and leave behind - 
with the help of the other donators - the bad feeling of having to 
work elsewhere to  get money for your living, then it's a pleasure 
for me to do it as much as I can.  Keep up the good work Doc and 
have a happy new Year form Quebec, Canada.

Thanks Gerard, it does help for sure! I wish I could have done more, 
but as french people use to say: "A chaque jour suffit sa peine." 
;-)

Wow, the interpreter and console add all of 3.5 KB to a Red executable 
;-)

Seems to be a WINE limitation. Dunno if it's fixed in newer versions:

Can it be that the Windows PE backend compiles in a random number 
or otherwise random uninitialised values? Windows builds seem to 
change on every build run without Red having changed. This is inefficient 
for my incremental builds repository and makes it hard to validate 
build correctness

Doc - console does not seem to support two consecutive expressions? 
E.g. a: 1 print a, crashes ....

Can it be that the Windows PE backend compiles in a random number 
or otherwise random uninitialised values?

 No, it shouldn't AFAIR, you can open a ticket on the bugtracker if 
 it's the case.

That's great Endo! I'm glad Doc's hard work is turning into donations, 
so he can see real support for the project from others. Kaj and Peter 
are doing a lot to help him, and I hope to make time in a few weeks 
to show my support with action as well.

Pekr: just the natives that are processed as keywords by the compiler 
and that don't needed a runtime counterpart until now. Anyway, as 
you can see from the commits, it's just a thin layer.

Kaj: congrats on the first binding made available to Red! :-)


I've noticed in %examples/do-sql.red the comment for #include:  "FIXME: 
#252". Actually, #252 is for Red/System, Red  implements its own 
#include which behaves differently than the Red/System version. I've 
tried to make it more intuitive, but it still needs some adjustments, 
so feel free to open new tickets about that (with simple concrete 
test cases I can reproduce). 


Also keep in mind that #include at Red level is intended to be a 
temporary feature until we get DO, LOAD and READ working with files. 
I would like an include system that could work both for the interpreter 
and compiler without having to change any code. I'm not sure this 
is achievable, so in worst case, we'll keep #include as fall-back.

Yeah, there's a question mark behind it because I wasn't sure it's 
the same issue, but #252 is the closest

Until ten minutes ago it was a Red/System binding. :-) Now it's both 
a Red/System and a Red binding, built on top of the Red/System one

Shouldn't block/rs-head and rs-tail have a /local s ?

You should wait for me to add the marshalling and unmarshalling functions 
(that will be used everywhere Red needs to interface with non-Red 
code). In your code example, it should be: 1 + length? version (as 
it needs to account for terminal NUL character). Also, you need to 
get sure that the source c-string! buffer is always available or 
make a copy of it (a pointer to it is stored as a UTF-8 cache, unused 
yet, but intended for speeding up I/O, still experimental, not sure 
it will stay for v1.0).

Since Red compiles to Red/system, how can I get the red/system source 
result?

Red is simpler to use but sometimes we want speed so why not let 
red compile to r/s

and then use that source to make a routine! or as a stand-alone program?

About antivirus false positves (VERY annoing): Red exes give alerts 
while r/s ones not (at least not the demos), isn't it a bit strange?

Marco: some antivirus have too aggressive heuristics, there's not 
much we can do for that. From time to time, I send some reports to 
AV vendors for notifying the false positive, most of the time, they 
take it into account.


Doing a quick test on virustotal using the latest console exe, it 
seems that my reports have been successfully processed, I don't have 
the old virus reported anymore (except with Panda): https://www.virustotal.com/file/a8c189ed790fd1d5bce2d86878e85445c21880dafb4220605df4ef2e4d4f4ce5/analysis/1356894544/

What AV are you using?

Kaj: right, the `free` call here is unsafe. Actually both allocate/free 
calls in input were just meant for temporary use. The whole current 
console code is temporary, it will need to be replaced by a proper 
cross-platform full-featured console.

'm offering a matching funds drive to for Kaj and Esper Consultancy's 
work on Red.  I'll match funds donated to them by January 31, 2013, 
up to a total of $200.  If you're interested in Red, please help 
them devote some additional time and effort to this project.

Very good vid even without a fitting musical distraction! 

Today I watched a tutorial for the AVR Dragon, a kind of arduino 
thing, when I heard in that video the programming environment was 
a download of about 500MB and needed the .NET framework I stopped 
it and realised that would be about 5000 times bigger than the programmable 
memory of that board. That is why the world needs Red :)

If someone wants to add music, he can make a new video using gource 
and add appropriate music, I hadn't the time to  also work on the 
audio part. :-)

Donations are currently vital for Red continuation as it is my only 
revenue stream. Without all the donations I have received, Red progress 
would slowdown a lot. So, it is probably even more important than 
contributing code. ;-)

Good question: I am just about to add issue! support to Red today. 
I think the change in R3 to treat it as a word is a good one, as 
the main issue! usage is for keywords. As in R3, it will allow digits 
as first character.

Each issue number adds a word to the word registry, that isn't garbage 
collected like strings are

As I mentioned in Rebol School (and elsewhere earlier), issues can 
be made to behave like strings to a certain extent even if they're 
words. To do that in compiled code you'd need to keep their spellings 
around though, unless you resolve all of those function calls statically 
(which you would be able to because issues would be immutable).

Symbols are structs in the Red runtime. If you have an app server 
running that handles issue!s, it will accumulate memory over time 
that you can't collect. It will be indistinghuishable from a memory 
leak

You could even use it for a DoS attack

True, but that's not a good reason to increase the problem

If you think about what you'd have to do to secure a server from 
memory overload, it would be reasonable to limit acceptable words 
to a certain dictionary, but it wouldn't be reasonable to limit issue! 
to a small range

As programmers, we usually see forms such as #if and think it's a 
REBOL issue!, but that's not how it is used in common English

In business correspondence it can mean number, in Twitter speak it's 
a hashtag, in music it means someone wrote a sharp with the wrong 
character. In English, it's a symbol that means pound (the weight, 
not the currency), but it's not common anymore.

I think it only precedes a word when it means number, or is in Twitter-speak.

It doesn't really mean pound; English keyboards have a pound sign 
(the currency, which is the weight of silver) where # is on American 
keyboards

Would it be possible to have a recycle feature for the symbols registry?

Hardly, the symbol table purpose is to provide a mapping between 
an integer value (the symbol ID) and a string representation. If 
we could allow the removal of a symbol, we would need: 


1) to be sure that a symbol is not used anymore anywhere (would require 
an equivalent of a full GC collection pass) before removing it.


2) maintain a list of freed "slots" in the symbol table for re-use.


3) being able to trigger the symbols-GC at relevant points in time.


Even with that, it would still be hard to counter a LOAD-based attack 
on the symbol table.

screen for limited word use

 That would need to happen at the LOAD level...not very clean from 
 a design POV.

As a basic screen, you can check the length of what you're loading. 
It can't blow out your memory much beyond twice the length of the 
source (once to read it, once for the results).

I use issues for IDs, phone numbers, pseudo-GUIDs, and serial numbers. 
I use INCLUDE as well, and the other PREBOL bits that use them as 
keywords.


Could I use a string for those things? Sure. But I like having a 
datatype with more meaning.

I think issue-as-string could still be useful, so I was wondering 
if supporting both would be a good idea. I could be achieved by adding 
a keyword! datatype, we could then have two syntaxes:

    #<keyword>			;-- for issue-as-word (keyword! datatype!)
    ##<issue>			;-- for issue-as-string (issue! datatype!)

What do you think?

Jerry: keyboards are only able to handle a tiny subset of Unicode.

How about @ for a keyword prefix? It has some precedent in TeX and 
such, I think

I don't think so. mail! always needs to have a name before the @

I wouldn't program a system where users would have to enter ##1 for 
a bug number or such

We can still use #1 as we always do. My proposition was just trying 
to cover some rare cases where we want to process issues as strings. 
But I see it brings a lot of confusion, so I will probably leave 
it as-is for now.

I think the split is fundamentally over that I don't see REBOL as 
just a language for pogrammers, but as an engine for user dialects

The system that I'm referring to has been collecting data for 10 
years or so. There are hundreds of REBOL scripts that would need 
to be changed.


More importantly , the users have got used to using the issue format 
when entering data.


It would be a massive emotional change and quite a large programming 
change to move from using issue-as-string.

Do we post Red/System questions here as well?


Kaj, is your example for Red or Red/System?  I think you're talking 
about Red.  If it's Red/System, 'tail? is not the way you check to 
see if you're at the end of a c-string.

But I know you know that.  I just wanted to see if I am getting a 
handle on Red/System... ;-)

One reason it would be bad to adopt a different literal form for 
the issue! datatype from REBOL (whether any-word! or any-string!) 
is that it would make it more difficult to exchange data between 
REBOL and Red.

Peter: I agree partially with your last argument: it wouldn't change 
anything about data exchanging with REBOL (as the literal #... form 
exists in both languages), but it would make some code testing for 
issue! (vs keyword!) incompatible between them.


The point in making issue! work as a word is fast comparison wherever 
it been used as a keyword or an ID (usually used for lookups). It 
is not a trivial performance difference, it is between one and two 
orders of magnitude faster with words than with strings.

Peter, no, I did not mean to use FUNC. I like to standardise on the 
full, comfortable form. In a compiler, the overhead is no problem

From there, how about \ as a prefix for keywords?

there are still § & ~ unpopulated and without a special meaning .)

and & is a word character

An altenative for preprocessor command could be
.if
(It starts in column 1 doesn't it?)

On the other hand isn;t it possible to get the meaning from the context? 
#if #define etc could be preversed preprocessor words?
(or I am on a complete other level again this time)

(The sz sign i a bad choice as is the ¤ or the & ^ * @ and Euro sign 
together with all backets and braces.)

#1 2# if one needs it as a string, I consider current Rebol behaviour 
as confusing:
>> probe to-string probe to-issue "1 2"
#1
1 2

Carl's post was interesting because (and I think this is true for 
Carl in general) he sees himself as a regular REBOL user, so when 
he decides on a design point, he extrapolates that to general use. 
Fortunately, his choices are generally very good. :-) In this case, 
he was the one who set the precedent of using issues as keywords, 
which I think came from familiar syntax for them in other languages.

I like things that are different to look different. But we don't 
have many goods chars left as leading or bracketing sigils, and I 
don't know if Doc has anything planned for those (e.g. [! @ & ~ | 
_]). 


The doubling of a sigil, to me, seems more like something we want 
to use as a convention, not a datatype. But the real question is 
what value each datatype adds. I've asked Carl a few times about 
a marker! type, for use in tagging locations in documents. Good chars 
for those are not easy to type († ‡ §), but could have mappings from 
(+ ++ $ $$). And now hashtags are a widely used meme. What lets us 
add meaning and clarity to the things we write, beyond just code. 
I still think REBOL's great success in expression comes from the 
fact that it was designed for data exchange.

Note that most respondents to Carl's old blog liked to keep issue! 
as is

 I just see people expressing irrational fears... I was pointing on 
 this article to refer to Carl's statements about issue! which I completely 
 share: 


It was a good attempt, but rarely, if ever, has it been used. Normally, 
we use strings for those types of values. Instead, the issue datatype 
has gained usage as a meta keyword.


Also, I fully agree with him that having issue-as-word is more helpful 
than having issue-as-string.

You should be aware that you will never have a 100% script compatibility 
between R2/R3, R2/Red and R3/Red. This means that migration tools 
would be required anyway for R2 scripts. Adding some rules to change 
issue! to keyword!, issue? to keyword? and to-issue to to-keyword 
is really not the biggest show-stopper.

As for me, don't bother adding another issue-as-string. I won't use 
a syntax that's not compatible with natural language. I'll have to 
do string processing and convert the original issue! syntax to string!

The compiler generates code to pass the function! value from :halt 
to quit:, then the interpreter evaluation `quit` by analyzing its 
value, detecting a function!, then processing it.

The compiler needs to do that at compile-time, so it needs to recognize 
what is a function! call and what is not.

Red/System is in beta stage. Whether or not it is a good choice for 
a GUI app is matter of personal taste. I personally gave up building 
GUI apps in a C-level language a long time ago. However, if you want 
to give it a try, I recommend you Kaj's GTK+ binding, which now works 
fine on Linux ARM, as shown here: 

http://static.red-lang.org/rpi-gtk-widgets.png

You can see the source code for this GTK+ demo here:

http://red.esperconsultancy.nl/Red-GTK/artifact/3453dd410a1c64ca8f842f75c7431b6f7fc3c4b3


As you can see, Red/System has some limited dialecting capabilities 
that Kaj leveraged to build a very nice GUI dialect (which is quite 
an achievement for a low-level language).

Thanks Doc for sharing this information and Kaj for doing this GUI 
binding, paving the way for newcomers and sharing the source for 
deep study. When I will be going back to my former status (more free 
time) I plan to deeply study Red/System in parallel with the C language 
just to be able to write some small doc (or book) to help newcomers 
to start with Red/System after coming from the C environment. In 
fact it's a long time I planned to do it for myself first but never 
found the time to do so when I worked as a teacher in the past. Now 
I hope I will better drive my diary to cope with this new planniing 
!!!

Doc or Kaj, do you think it would be usable on my Android tablet 
- since it uses Linux on Arm as basis ? Already I can use the R3 
port from Cyphre and the console is working fine. The single problem 
I see for now is that the Red/System app is still not working on 
my tablet ... but I suppose some time in a near future this will 
be a thing of the past. Bue Doc I don't tell you this so you feel 
yourself as if you would put more time on this issue. This is not 
even disturbing me for the moment sinc in any case I don't have much 
time left for now - so even if it already worked I couldn't use it 
anyway. It's damage I don't know more by myself about all these new 
computers and environments but I have to think I'm not alone in this 
case ... Regards

Keyword! sounds much more like it means a reserved word in the language 
to me. 

issue!
keyword!
label!
marker!
cue!

Gregg: (I'm not sure if I understand your question correctly) If 
you use an issue! as a keyword/hashtag, it will be better for issue! 
to be a sub-type of word! rather than string!.

It's possible there's currently a problem with Red/System on Android. 
Can anyone confirm this?

A possible cause of the hello app not working on Android anymore 
is a mismatch between the output encoding of Red and the expected 
one from the Java wrapper. I will check that when I'll start working 
fully on the Android port.

I can't push to GitHub because it requires a Git version newer than 
the one available in my Ubuntu of only a year and a half old

Got it working through SSH instead of HTTPS. I spent a whole day 
setting up GitHub to be able to fork and push Red contributions

Doc, what I meant was, if you use blocks as a message structure, 
you include issue! values as hashtags, you gain speed and storage 
efficiency. But you may also hit limits. Suppose you have a blog/chat/tweet 
system, how many unique issues can you have without blowing a symbol 
table if they are words?


Not saying they shouldn't be words, to be clear, just making sure 
I know how to use them correctly. :-)

Limit for symbol table is available memory, but it would be a bad 
idea to make the symbol table grow too big with current implementation, 
it would slow down a lot addition of new words. This could be addressed 
by using a more sophisticated internal data structure in the future.

As there are frequently used, native is probably a better choice.

I'll leave them in my Fossil repository, then. I have a function 
for empty? and a routine for zero?

My brain came up with a solution for issue! while I was sleeping. 
It's a notational problem, so how about having both issue! and keyword! 
start with a # but when the next character is alphabetic, it's a 
keyword, and otherwise, it's an issue!.


This is consistent with both issue notation in American English and 
preprocessor keywords in C-like languages.


It's an easy rule for the lexer, and a relatively easy rule for humans, 
that is intuitively clear.


It optimises keyword use for speed, while preventing memory leaking 
into the symbol table for almost all issue notations.


It's unlikely that someone has issues starting with an alphabet character, 
but when they do, most cases will be transparent. In other cases, 
only little code needs to be added to handle them as keyword!.