AltME groups: search

Strange concept

 It looks pretty classic to me, but there are some specific reasons 
 behind such choice, that I will detail them in a future blog entry. 
 Basically, it simplifies the tracking of Red values on stack (making 
 the work of the GC easier) and stack serialization becomes almost 
 trivial (to memory, for continuation support, or to file, for image 
 support). I think that R3 doesn't do it that way, but probably uses 
 recursion, passing all R3 values on C stack instead. It's a faster 
 approach but less flexible.

Thanks. I know, I'm low on glitz. It's because I don't want to take 
the preparation of those talks more time than they already do. I 
prepare by making sure that as much as possible works, and then I 
do a guided tour of it on the machine itself

It's the same reason why I have written only limited documentation. 
I have to prioritise my time to do the things that I need myself, 
and I don't need the documentation and the presentations that are 
a goal in themselves

Yes, the hope is that we can rally support to do the things, like 
web sites, forum moderation, etc. so core developers (i.e. Doc) can 
focus on development.

Well I changed some text in this file, I changed it online in a black 
background box where I could not see my cursor nor the arrow pointer, 
so it sucked :( 

I thought it would be possible to edit the file offline but that 
is something to find out how to do next time ;)

Now I added a comment and it says I want to commit 182 changes into 
the master branch, which is not what I want, but Github says I want 
that. Including my comments it could be I typed in total 182 characters 
including the ones I deleted (?) but the 182 are the commits from 
the 0.3.0 branche I think. 

Me and my friend Github >:|

You probably need to check out master, then cherry-pick the BNF file 
from v0.3.0, then make your change, then do the pull request for 
master

It's about dealing with different Linux kernel incompatible ABI for 
float support on ARM platforms. Red/System uses the FPU unit (named 
VFP in ARM family) directly, but when having to pass/receive float 
arguments from libc or 3rd-party libs, Red/System needs to do it 
respecting the installed system ABI, which might be `softfp` or `hardfp` 
(there's a third one, but it's for not a concern for us). 


Currently, Red/System floats are passed using the `softfp` convention, 
so it works only on ARMEL platforms (while ARMHF platforms require 
`hardfp` convention). `hardfp` is a much more performant, while `softfp` 
is for legacy  systems or systems with no FPU unit).

BTW, Red or Red/System apps that do not use floats seems to work 
well with both ABI.

And also - do I need to know, which platform I need to support, or 
support can be in one exe, for both worlds?

have to do ...

Kaj: I've pushed a fix for ARM that should improve the stability, 
can you do some quick tests to see if some of the issues are fixed?

Basically, Red/System compiler is doing automatically what C compiler 
requires you to do manually (i.e. specifying function prototypes 
separately in headers).

Some blog article about what 0.3.0 brings to the table, would be 
nice then, to show ppl what is implemented, what one can do already 
in Red (eventual list of supported dtypes, natives, actions?), and 
what comes next? That would keep ppl motivated ...

Did not know making the to-do list takes two to three days ;)

:-) to do list to get done means, to implement all to-do items :-)

Get Cyphre to do a modern View like engine, and we will be kings 
- just believe me :-)

Is that still on your to-do list Pekr :D

Kaj, clause 4.3: "You must retain, in the Source form of any Derivative 
Works that You distribute, all copyright, patent, trademark, and 
attribution notices from the Source form of the Work, excluding those 
notices that do not pertain to any part of the Derivative Works"


It's the only place in the distribution section where they specifically 
mention Source form rather than Source or Binary, and that's the 
only clause that requires copyright or other notices be retained. 
Except for that weird NOTICE file requirement, of course.

I'm not following the Licensing group anymore. I have work to do

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


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


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


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

Needed 6 programs to do that! Schermafbeelding (screenshot?) to make 
the picture, Spotlight to find it, Imagewell to change tiff to jpg 
Preview to check Finder to put it in the right directory Filezilla 
to transfer Safari to check (clipboard to transfer the url to here)

I need one HTC sensation, press of a shooter, one button press to 
get jpeg into my email or facebook. Just throw your workflow to the 
trashcan, you can do better nowadays :-)

If there's no new issue to fix, we should do the merge this weekend.

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


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


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

Ah, but the interface is too simple to need an IDL - make command! 
will do. The extra stuff is for system integration, which is only 
needed when you are doing port schemes, dialects, anything that you 
wouldn't expect to be cross-language compatible anyways, unless you 
explicitly implement a compatible system model. If you're just exporting 
functions then you can implement a simple IDL just by interpreting 
the (cooincidentally the same) module spec code with a very limited 
IDL dialect processor if no Red script wrapper is found.

For that matter, I expect to make my own Rebol spinoff language that 
will follow a completely different system model than either Red or 
Rebol, and the only reason to do so is because those other languages 
don't cover that situation (otherwise I would have been more active 
in Red so far). Being different justifies their existence; interoperating 
with each other justifies their cooperation :)

I don't expect it, but that doesn't mean that we won't do our best 
to fake it :)

So, no lexical binding? Or do you plan to infer lexical binding where 
possible, and use direct where not?

Certainly, but AOT compilation would be a big plus. Also, in Red 
we need to modularize the compilation process itself, so  we can 
do incremental AOT compilation on multi-files projects instead of 
having to rebuild everything (include runtime libraries) each time. 
We need to, somehow, match those compilation units with the higher-level 
module system (it's not the only option, but probably the most simple).

An asymetric permissive licensing model between Red and R3 might 
prevent me from publishing info about what we'll do next, to prevent 
the features from being implemented first with a copyleft license 
attached. It would just be unfair to Red, so I would have to be cautious 
about that.

I thought, that once compiled = you know what is resolving to what

 Certainly not possible with a REBOL-like language, as it needs only 
 one "unresolvable" expression to force you to attach whole runtime 
 library.


Don't expect any Red app to fit in 5KB or anywhere close, that would 
be magic, not computer science. Higher-level abstractions have a 
cost, if you don't want to pay for them, there's Red/System.


There's also no "magic" in compilation, some expressions can be reduced 
to very close to CPU counterparts, most can't. Don't expect the first 
Red alpha bootstrap compiler to do extensive optimizations (it does 
none currently). Also, a sentence you will probably hear from me 
very often: "Don't expect a v0.3.0 to be a v1.0.0!".

We'll do our best to spread libRed everywhere. ;-)

Pekr, runtimes interpreters are allowed on iOS now, as long as they 
are approved by Apple. What is prohibited is running external scripts 
or scripts downloaded from the internet. All interpreted scripts 
need to be bundled with the app, so the app can be evaluated as a 
whole by the app store gatekeepers. I've given this some thought, 
and it may be possible to cripple an R3-like interpreter sufficiently 
to meet these criteria; all you need to do is put some limits into 
the LOAD and DO mezzanine code. Red could be similarly crippled if 
you want.

As I said before, I'll announce it officially. I still have a couple 
of things to do before: decide about one bugtracker ticket and write 
the blog entry to announce it. :-)

Kaj: do you have more info about that? Just to know if releasing 
0.3.0 tonight is safe or if I should wait more?

I will release v0.3.0 in a couple of hours, if you want to do some 
tests to track regressions, that would help.

I've hesitated between DOS and MSDOS in the beginning, and I've chosen 
the later one, because it is more meaningful for everyone, especially 
those that do not use Windows often (or never use it). As I've said, 
if someone ever ports Red to old MSDOS, we'll deal with the name 
conflict then.

I've just got an answer from F-Prot, they just whitelisted the sample 
binary I've sent to them but didn't send me any info about their 
heuristics... So I think that in order to avoid loosing my time trying 
to get any info from those AV vendors, I'll just add a specific signature 
to Red generated binaries, so that they can be whitelisted by all 
AV vendors (when possible). I can't see what else I could do, except 
warn users about some crappy AV software.

Afaik, authenticode is supposed to handle that process, at least 
to a certain extent. You cryptographically sign your binaries so 
when they do bad things there's someone to blame. If your binaries 
aren't signed, they're assumed to be bad by some people.

The other way is to convert the utf-8 c-string! to  UTF-16E integers 
on the fly  and feed them into llibc putwchar yourself. More work 
upfront but may be easier in the long term.


The code in red/runitme/platform/win32.reds is a pretty clear exmpale 
of how to do it but you wuld still need to write the UTF-8 to UTF16-LE 
on the fly conversion yourself. (That one is UCS-4 to UTF16LE).

what do you mean by anonymous? What I think is OK is to display list 
of donators, in no respective order. It is the same like list of 
eventual top frequent code contributors. I think that ppl could be 
ok with that. Of course, if someone opts to stay "hidden", you will 
not list him/her ....?

The other option is to do categories like kickstarter does and just 
indicate a number of donations in a certain range

You do seem to have downloaded an old version. Go to the latest checkin 
and download the package there. Or better, update with Fossil

OK, I just installed win 8 Pro 32 on one of my machines and I downloaded 
the v0.3.0-0 zip and ran the run-all.r file. Perhaps that's not the 
right thing to do since it printed "running lexer-test" and then 
proceeded to lock up my machine. I can't even ctrl-alt-del. Let me 
know how you would recommend me testing Red since I may be the first 
to have win 8 among us but the last to really use Red passed the 
original "let's see if I can see 'hello world' on my Droid" a few 
months back :-)

I posted in Sublime Text's forum in regard to the lexing needs that 
we might need for good Red support. The author hasn't answered yet, 
but maybe if others add to the thread, it'll keep it near the top 
and show there's interest in the idea. I suppose even if ST doesn't 
make its lexer pluggable, we could just make the built-in lexer do 
as little as possible by including no tmLanguage file for Red and 
delegating any syntax coloring/scope processing to a native library 
that's part of a Sublime Text package for the Red language. 

http://www.sublimetext.com/forum/viewtopic.php?f=2&t=9870

So, we get both worlds. If we manage to call R3 code from the Red 
section and vice versa, that would be great. We could use the compiled 
speed for inner loops and let the interpreter do all the non-speed 
relevant things.

Ladislav: I was thinking about an internal only solution, I know 
it's possible to do it by using a tiny C code in a shared lib.   
        If you've figured out a way to do it without any external 
dependency, I would be glad to learn how you did it.

I know it's possible to do it by using a tiny C code in a shared 
lib.
 - does that look like a problem?

Nope, you need to do some processing first. All global addresses 
in code are zeroed by default. The linker fills the blank by calculating 
the right code or data addresses.

Well, I do have something, but it's messy, buggy and incomplete. 
I can send you the AVR8 backend if you want to play with it, I don't 
want to publish it until it gets a stable and correct support for 
basic datatypes.

Nope, Red/System is statically typed, you can never change the type 
of a variable. You can just do type casting to convert the variable's 
value to a compatible type.

From ~Links group: "Could Red eventually become a contender for #6? 
 How strong will support for parallel processing be, eventually, 
in Red?"


#6: yes, that is one of the goals I want to achieve with Red. For 
parallel processing, the model I have in mind is the "parallel collections" 
from Scala. This means that when you are looping over a series, Red 
should be able to parallelize the loop code over n (CPU and/or GPGPU) 
cores at the cost for the user of only a change of the loop function 
name (in Scala, they use a "par." prefix for such functions). This 
requires that the compiler do a deep static analysis of the loop 
body to determine if it can be parallelized (e.g. iterations not 
dependent on results from previous ones). Now, if you also add SIMD 
support in the equation to leverage intra-core parallelism, you get 
a good picture of what I want to achieve. ;-)


So, I think a semi-assisted parallelization/vectorization of loops 
in Red is doable. To what extent and which final efficiency, I'm 
not sure before we build some prototypes.

There is also the basic work to do, like the lexical scanner, port 
system, etc. Some of the work on actions and natives can be outsourced 
later.

if Red is reflective enough to do that yet...

You might be able to do source analysis using an external tool, for 
now.

Doc, I am glad that Red support Unicode in the first place, so I 
don't have to do the same trick to you. :-)

Also, if we define 0-gap (possible) then we do not have any right 
to use negative indices.

Do you consider R2's nomenclature to be particularly consistent and 
simple?

I am still sure that once we have negative numbers, we cannot do 
without zero (to maintain compatibility with the continuity of the 
underlying series). Then, actually, the SKIP behaviour is the only 
one easy to describe and use as the base of the "nomenclature".

Anyway.. reading this discussion, I'm feeling like deja vu... I would 
stay with REBOL way of indexing. Although I don't have any problem 
to switch into 0-based indexing in other languages. The problem is, 
that the other languages don't have functions like next, back, tail.. 
which enable series traversing, do they?

He doesn't, I do, that's my contribution to this bridge. ;-)

So, who do you think to suggest as "masters"? DocKimbel has time 
for it?

re Carl's message ... dunno why, but once again I can see an aproach 
of how to steal the thunder from ppl being eventually interested 
in Red, claiming bright future of R3. It feels almost irritating 
to read the message containing claims, that porting of R3 takes 5 
minutes, yet the only port which happened was Amiga, and ARM or other 
platforms never ever happened, from whatever reason. I have to ask 
myself - why Carl did not find 5 minutes to do the port?

porting of R3 takes 5 minutes, yet the only port which happened was 
Amiga, and ARM or other platforms never ever happened [...]. why 
Carl did not find 5 minutes to do the port?


1. An ARM port was done, supposedly. 2. Porting is one thing, supporting 
a port is another.

IIRC he actually use the Android NDK compiler to do that build. But 
don't take my word for it.

Arnold, just FYI, I'm tinkering with your redcompiler script, and 
will send you my version soon. When I started with REBOL, many people 
were kind enough to pass on suggestions, to make my code more REBOLish, 
so I try to do the same from time to time. It's not a critique of 
your code, just ideas you can accept or reject.

Thank you!

Gregg, I left the ** comments as clarification and did not spend 
a lot of time to consider if they were necessary or not. I'll have 
a look at them and clear the comments if they do not add to the flow.

Magazines were fun then .. now you have to do a random walk across 
the web

ChristianE: nice work! 


How do you cope with multiple columns having the same name returned 
by INSERT? This can happen when you select from several tables, and 
may lead to nasty errors.

Doc, those column names are meant for binding to the result set, 
but it is not necessary to access the result set that way. You usually 
just do the positional access. If you want to use the column names, 
you have to make sure the column names are unique and that all columns 
have names, same as you have to do with all SQL.

I'm proud to say I have the second fastest Android phone tested so 
far. ;-)  I am SO excited for the future, especially for the Android 
network and file access and the graphics port.  Cyphre, how do we 
make donations again?

Yes, but that's a 6502 emulator ... not really what I want!  And 
the other thing was called "empty.exe" which doesn't seem to do anything

This script already hides the use of Fossil. All you need to do is 
download its one file

Is it possible to provide an overview of all the Red information 
on the various links on http://red.esperconsultancy.nl/?
(do not follow this link it will only show you "Not Found")
Are all the links independent Fossil files?

If I wanted to run Red on my Windows-based computer, what would be 
the process to do it?  Do I download the Red sources from Github 
and compile it on my computer?  If so, are there instructions on 
how to do it with a free compiler?

sorry to say, but

this is just one more of  the "too many sites" as MaxV calls them.

it seems, that too many rebol user think they should do their own 
and can do it better.

this may be, but I think the average Rebol user is just to much individualist 
to join

Rebol 3 Bazaar is Saphirion Rebol 3, at the moment. Saphirion wanted 
to go on GitHub, but htey ahve not time to do it. Now everybody can 
contribute and speed up Rebol 3 devolpment.

I pushed Facebook Rebol group  from 100 to 263 users now, but people 
is loosing interest in Rebol, I write the Rebol blog quite every 
day; and I'll dedicate my time also to Rebol Bazaar. I don't know 
why Rebol software is orphan and I don't care. I'll try to rise again 
it in the Olympus of best software (since nobody else do it), if 
you are with me you are welcome. I have no enemies, just friends.

In my humble opinion there is an immense wall between users and developers, 
that is not the open source way. Altme is inaccessible to most user, 
nobody know it and the procedure to register is hidden somewhere 
and too complicated; here we have no more than 50 readers. Rebol.com 
site seems a dead site. Curecode seems a secret society (it's impossible 
to reach if don't know the correct link, who is  working on it?). 
 Stack overflow is the only way at the moment users have to discover 
somenthing about Rebol, but it's not the appropriate site. We cold 
multiply 1000 times users with a good support.  Rebol must be more 
partecipative, but I don't see around anything about it.  Everytime 
I write a post about Rebol, I feel like an archaeologist with a dead 
language. Searching information about Rebol is a huge quest.
What did you do for Rebol? What can you do now for Rebol?

Do you want to build an open working infrastructure or you want remain 
sat on your chair looking Rebol going in ruin?

We have finally Rebol and Rebol VID source working, now we have to 
attract developers from all around the world.

I''m not starting a new Rebol, just making attractive for normal 
people, the bones and muscles of every good open source project.

Well to me it looks like there is just way too much happening to 
follow it all. Then one github repository for R3 is enough unless 
you really need another one to test and fool around with completely. 
The source being on Github is nice because I now have a copy, but 
it hinders me to contribute because I do not have the time nor the 
will to find out how to contribute changes, and when I tried I found 
it puzzling enough, so I decided it is too much trouble for now and 
to only look at the sources and not to contribute. (This goes for 
the Red github situation as well).

We haven't needed one yet. Foundations tend to do better when they're 
for well-established projects, since otherwise they don't tend to 
get enough funding to cover even their own overhead. So the first 
part of a foundation-building plan would be to grow the community 
to the point where a foundation would be a good idea :)

As an observer of open source projects since there were open scource 
projects, I see some challenges that no open source community that 
in my opinion have yet to be overcome, outside a limited vertical 
or academic market.

1.  Self-interest:  Each person views the code as their own opportunity 
to promote their own goals.  Since it costs nothing except time and 
effort and there is no remuneration, people develop forks that suit 
themselves.  When the need for them disappears, the support for them 
vanishes.  Result:  Whether a company owns the source or a company 
makes money with the source you are always dependent upon somebody 
who has more at stake than you do.  Right now that means Sapphirion.

2. Money:  Even with open source projects it takes money to push 
them forward.  If a company can make money they will pay for it themselves. 
 if somebody else needs the port or feature, they donate if there 
are enough people interested. So you either pay a company or pay 
into a project, either way you pay.

3. Leadership:  Usually a company ends up taking leadership because 
the original leaders begin to tire of the constant promotion and 
hard work.

The solution to this would a very radical idea, one that isn't easy 
for a group of people to do.  Think of others as more important than 
themselves.  In this case I believe that R3 could become a movement 
against technology squeezing people into its own mold.  It could 
become technology that makes us smarter and better, rather than less 
adequate and worse.  It could become an enabling technology, but 
only if its people are devoted to enabling other people.

I have the same problems with XP.
The exe does nothing but the url line.

If I try to do or read  the .red from the console-pro, the console 
window closes.

I tried to do that with local .red files.

Some more Android port info. Since some people around were asking 
if it will be possible to 'encap' scripts with the Android R3 I've 
spent some time researching/prototyping in this area and I think 
I can now answer this question positively. It surely will be possible 
to make "encapper" for R3 on Android and my current prototype results 
show that we'll be able to do it without the need to install any 
SDK or other bloated instalations. It will be just one good-old "encapper 
exe" that will do the job for you.

How much do we need to get chat going?

Couldn't tell you, but in an indirect way, I would think that Rebol 
would be easier to do than quite a few other languages. This is because 
the current scripting language, Thyme, is very much Lua-like.

My daughter married John Resig's brother.  Long conversations.  John 
is a good guy, a human-centered technology sort of guy.  Saw the 
DOM and went yuk.  I've got to do something about this.

Well, maybe all we need to do is to ask Carl, if the Chat could be 
released too? Has anyone tried already?

Graham, I haven't tried to grab a cookie or anything yet, but just 
running the SO bot errors out first thing:

** Script error: lastmessage-no has no value
** Where: get ajoin case ?? do either either either -apply-
** Near: get :name

What optimizations are you looking for?

@NickA: About enhanced r3 chat, have a look to %wchat.r in the %OpenMe/ 
folder of this Altme world.

Basically its %chat.r but it act as a proxy between the Devbase server 
and the browser. The goal is that the browser replace the CLI interface 
: not typing command in CLI but cliking link in the browser.

Its just a start. There is some work to do to handle POST request 
and then allow posting. + enhancing HTML presentation.

There is only so much Cyphre that we can apply to the projects, alas. 
I hope that we can get some other talented people to take on perhaps 
individual Cyphre-class projects so he doesn't have to do so much 
overall. Hopefully the new open source projects can attract more 
people, or even have some come back (Hi Maarten!). Fork's efforts 
may help here.

Pekr, unless this is a huge rehash that you don't want to repeat, 
could you let me know which View engine proposal you're talking about? 
I don't do GUI stuff so it's been a while since I caught up with 
current events. In the !R3-GUI group if that's appropriate.

:-) I just expected all the DO buttons to be together, with help 
stuff on the right.

But if you define a routine in a Red script, and then DO it, it will 
work. You can also build a custom console by writing a Red script 
and adding at the end an %include %<path-to>/console.red.

if you define a routine in a Red script, and then DO it, it will 
work.
 => the script needs to be compiled for that to work.

However, the reliable way to do a full & clean build is `make make` 
followed by `make clean prep r3`.

Do you really want Syllable to be ignored as a platform?

The original demand was to have a /FLAT version which I offered to 
add, but Robert asked me to modify /LINK behaviour instead. I do 
not mind, in fact.