AltME groups: search

FYI, I am making good progress on the Red runtime, but I had to start 
implementing the Red compiler earlier than planned, to be able to 
define more accurately the right runtime API that the compiler needs. 
So at the time that the runtime will be ready, I should have a first 
Red compiler partial implementation working.

Doc - we are watching your progress via the Twitter messages, and 
looking into Github :-)

Sometimes progress doesn't feel like progress :-S

Doc, thank you for your swift response to my bug reports. There's 
clearly visible daily progress in Red/System and it's getting more 
and more usable every day. Red/System clearly shows advantages of 
open sourced language compared to closed source ones. I'm really 
happy with it and I look forward to next versions of Red/System.

Doc, Not to rush you, just curious about the progress of Red and 
its Unicode support. Unicode is very important here in China. :-)

Red: I'm still working on both the compiler and the minimal runtime 
required to run simple Red programs. I have only the very basic datatypes 
working for now, no objects (so no ports) yet. I not yet at the point 
where I can give an accurate ETA for the first alpha, but I hope 
to be able to provide that ETA in a week.


Red string! datatype will support Unicode (UTF-8 and UTF-16 encoding 
internally). I haven't implemented Unicode yet, so if some of you 
are willing to provide efficient code for supporting Unicode, that 
would greatly speedup Red progress. 

The following functions would be needed (coded in Red/System):

- UTF-8 <=> UTF-16 LE conversion routines

- (by order of importance) length?, compare (two strings), compare-case, 
pick, poke, at, find, find-case
- optinally: uppercase, lowercase, sort


All the above functions should be coded both for UTF-8 and UTF-16 
LE.

Lookinf forward to whatever progress is made :-)

Pekr: expect a firework of new features and progress until christmas. 
;-)

New Twitter message from Doc: "Making good progress on Red language 
layer, got a stable core compiler now and minimal datatypes set"

Pekr: right, from now on, you can expect daily progress on Red layer. 
I will push the new code soon, I still need to complete it a bit 
and clean it up.


Jerry: the baby looks nice, we'll just have to keep it away from 
junk food and it will grow up well. ;-)

Thanks for the updates Doc. Very exciting progress.

If you communicate clearly your financial needs, I'll do everything 
possible to help keep you funded.  An occassional update to your 
funding requirements would be appreciated.  I would appreciate being 
added to a regular email update, in case I can't keep up on AltMe. 
 I wonder if others who have donated on Paypal may be interested 
in an occassional update, so they can help when able/motivated.  
Your current progress is very motivating.  I hope that others who 
are watching feel the same way.

Congrats Kaj!  It's so encouraging to see so much daily progress.

I don't see currently any trivial task that could speed up the progress 
of Red, unfortunately, all the tasks in the Roadmap are non-trivial. 
If I stumble upon some non-coding task that can be outsourced, I 
will contact you.

So let me just say what I am thinking.. I wonder if R3 would be released 
already if you weren't making so much progress with Red..  I hope 
2 (or more) options will be able to bring even more people into Rebol 
family of languages. The time is about to be right. Python is getting 
sort of backlash (finally).

Fast progress

This coming saturday october the sixth,  Kaj will show his work (in 
progress) to get the Red Programming Language running on the Raspberry 
Pi.

The completeness and stability of them will be ignored here, which 
is not fair to R3. But like I said, It's just a simple comparison. 
The purpose is to see the progress of Red, not to discredit R3.

I agree with Peter, you can't measure Red's progress by taking R3 
as a target goal. It is better and more accurate to measure progress 
by counting what is built in Red.

Red is making progress fast :-)

Wow! You are making great progress Doc!

Go Doc Go!

Other donations have been made as well, but it's great to remind 
people that we need to support Doc so he can focus and keep making 
great progress. Thanks Petr.

Is http://www.red-lang.org/p/roadmap.htmlcurrent? You've been making 
so much progress, I'm guessing it's a little out of date.

Great progress Nenad.

Great progress Nenad on this console. 
It must be getting more and more fun to use Red now!!

Gregg: "Remember, everyone, I'll match donations made by 31-Dec up 
to USD$200."

I just donated 50 eu (68,93 usd) to Doc for the big progress of Red!

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

With the implementation of a random function on Red/System I have 
some questions:

#DEFINE seems to become obsolete towards version 2, no preprocessor 
anymore, so any progress on a decision? https://github.com/dockimbel/Red/wiki/Alternatives-to-Red-System-pre-processor-%23define


How are you supposed to implement an array, I can figure out some 
things about using a pointer, but I cannot believe it will work with 
the example value of 40000000h 

http://static.red-lang.org/red-system-specs.html#section-4.8(.3)

I do not have a clue if this is a realistic value as a memory-address, 
that is why a simple array could come in handy.


At this moment I will not worry about support of a L(ong) or 64 bit 
type, I'll work with 32 bits for now.

#DEFINE seems to become obsolete towards version 2, no preprocessor 
anymore, so any progress on a decision?


It is not the time for taking decision about Red/System v2. For the 
preprocessor replacement, we are for now just gathering ideas in 
the wiki.

More great progress Doc. Thanks for the update.

http://www.rebol.com/cgi-bin/blog.r?view=0527#comments


Fork: "I am porting Red to R3--and while I won't claim I'm "almost 
done", I will say I've made significant progress. Red/System now 
builds a working hello.reds under both R3 and R2."


Great! Like Nick says, hard to keep track of everything happening 
these days. :-)

OpenCV binding is done by François Jouen, it's a work in progress. 
There's a Red/System version that you could find from this page (in 
french):


http://www.digicamsoft.com/cgi-bin/rebelBB.cgi?thread=%3C25May2012200150764026200%3E


There's a Red version that François sent me privately a few days 
ago for testing, but I haven't had the time yet to review it.

Nice, we're making progress. So still not direct from the command 
line?

some problems where having an array  would come in very handy. (So 
I have the allocate sought out but I am not sure of the free, and 
my progress is really slow now). I am generally considered a good 
programmer by colleagues but there are specialities and different 
leagues, I am not playing in. :D 

R3 and Red both need each other to make the best case for both of 
them and attract a real momentum. Both need very much the same best 
solutions, yet there are differences to live with.

State of Red's PARSE: 


It's not on the roadmap because it's too low-level for the bird view 
(maybe I need to add it anyway?). Moreover, PARSE is not (for now) 
useful for the internal construction of Red/System and Red, so from 
that perspective, it's quite low-priority.


OTOH, it is quite simple to implement in Red/System, and users could 
see that as a sign of good progress, so I probably need to schedule 
it for a weekend to implement a R2-level PARSE (with a couple of 
features from R3's PARSE) and a few more days to test and debug it.


Also, Gabriele is interested in implementing a "compiled" PARSE version 
for Red, but unfortunately, Red has not yet all the features that 
Gab needs for it (mainly object! support). So, he's waiting on me 
to get Red ready first.


As currently, object! support is much more important to implement 
(for completing the context/binding model of Red and enabling ports) 
than PARSE, you might get Gab's version first. Also if it's fast 
enough, I wouldn't need to make a Red/System version then.


Last but not least, I don't agree with 100% of the changes/addition 
in PARSE for R3, so I would need to review R3 parse and make a "cleaned-up" 
version for Red. Also, Topaz has some interesting improvements on 
PARSE what I might want to include in Red's version too, so that 
needs a bit of preliminary review work.


So, as you can see, it's hard to give you a precise timeframe, I 
guess we would have a first version of it during Q2 2013.

Great progress guys!!

No flooding or trying to prove anyone wrong. I'm happy to see improvements 
and progress in Red's development. There is no Red-vs-R3, we're all 
in this together.

nice progress

My progress on the Red/System random function. I tried to have an 
a declaration of an array as a import, but that failed because is 
was to be declared at runtime so the array was missing at compiletime. 
Yep it is not Rebol.

All these logos are missing some pegs. Could be a real cool way of 
depicting progress. All of the tower starting at the left (REBOL) 
site and ending as a full tower on the right Red site. We are now 
somewhere with the top two layers on the second pin. (Only to find 
out we moved the complete tower to the middle pin.)

Great progress Doc

Compiling the console works out of the box as described on my Macbook. 
I am impressed. The Repeat by Endo does what I read it that it should 
be doing. The Doc: is it intentional?
red>> repeat i 10 [  ]
== 10
red>> i
== 10

is what I expect it to be after the performing of the repeat. Unless 
you argue that i should only be valid inside of the repeat, but you 
should work with a function then not with a repeat. I do not see 
what is not to be liked about that?

In REBOL and Red it is the human way that is leading not the programmers 
mind that is used to bend along with the computers view of the world.
Again beautiful progress Doc.

More screenshots of OpenCV binding progress: http://www.wuala.com/fjouen/Code/OpenCV/Red/pub/

I've started on some Red mezzanines in %Red/mezz/ here. Early days, 
but my hat is off to Doc for how far Red has come already. Yes, I 
crash the console a lot, and I can't DO files yet, but I can paste 
code into the console, play, and still make really good progress.

; 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]

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"

There is as I read this a different issue. Dock want Red to be as 
complete as posible, Kaj wants it to officially useable. Kaj really 
needs UTF-8 (and or Latin-1) character support, for getting this, 
I guess this has to do with the Syllable operating system amongst 
others.

I would like Red to support time and random functions as natives 
and (Gregg is one of your mezz funcs REJOIN ? I want that too) be 
able to connect to a MySQL database so I can dump PHP for some webdevelopment.

Besdies that we all love to see a VID (like) solution for display 
and creating apps. 

We have to be patient agreed 100% amongst everybody? Where the roadmap 
mentions all things to progress Red, above things are not on that 
list. I want Red to have enough to make it useable in production 
and after that expand, imho that is the way to really attrackt more 
funding/enthousiast programmers and make sure current support does 
not fade/ loose interest.

I think, and hope, the conflict over this will fade soon, and everyone 
will be happy again. We're just all so anxious for the things we 
each need, and Doc has made such great progress that it seems like 
Red should be almost ready to use. I was going to post that REJOIN 
wasn't stable yet, but decided to test it on my latest console build 
and it seems to work great.

Red HELP func made some decent progress, but I stopped work on it 
because of some issues, and I didn't want to distract Doc until he's 
done with Android.

Therefore it's cool to see a project like Red, that seems to be well 
thought trough, and where there is slow but (I feel) solid progress 
towards a goal.

OK, thanks! Looking forward to further progress and First Red android 
APK example relase :-)

I'm making good progress on the new Android bridge and demo, I should 
be able to release it tonight with all the new changes in source 
code (so Pekr will not need to reverse-engineer the apk ;-)).

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

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

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

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

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

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

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


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

@Doc, What is the next on Red development? New progress plans are 
made on Recode?  In your experience what was the best of Recode?

made good progress over the holiday, powered by turkey sandwiches 
from France.


Prep of C source nearly done. See, not just a dump and run. Sure, 
a few problems came up, but I'm not going to hold up the release 
for them. You can decide.


Grabbed latest git source and built it for this dev box (which did 
not support 1.8 version as bin.)


Once released, I've got a number of notes to write up. Like how to 
quickly port R3. Takes about 5 mins if you know what you're doing. 
Got it up on ARM & MIPS Linux.


Also, I have some goals in mind. Android and iphone, that kind of 
thing. Getting graphics and sound back up. GUI and tinyGUI. A micro-R3 
for smallish embedded systems.

There's a lot you can help with. Delegation, right?

I'm making another $500 matching donation offer for the Saphirion 
R3 port, till the end of May 2013.  Please help keep up the progress.

Robert, thank you for the improvements and progress with Android 
(sorry, I've been away from AltMe for a while)

I'm happy to announce that we made good progress regarding the Android 
R3 encapper.


A major breakthru in the multiple-app generation has been made (thanks 
to Andreas for ELF format hints). Now it is possible to create encapped 
apps with unique app-id. Such apps can be recognized properly by 
the Android OS and also accepted on the Google Play market.


The cool thing with this approach is one really don't need anything 
more than the Android encapper to produce the apk file. No need for 
android NDK, SDK or even JAVA to be installed ;-)


There are some glitches we are going to fix and than the encapper 
is ready for production.

In conjunction we did a new R3-GUI release as well.


added DETAB flag support
fixed TEXT-AREA issues
fixed TEXT init-size handling
fixed SIZE-TXT bug
built new R3GUI release (version 4897)
delete "experimental" layout-sizing-independent.r3
improve rouding
move docs/r3-gui/ to documentation/r3/r3-gui/

remove documentation/r3/r3-gui/license/ directory containing obsolete 
license
Copyright notice update
license update
typo fixed
Rounding correction
improved rotate event handling

improved drag handling code (removed duplicate gui-events/drag reference)
improved android text input handling
fixed progress resizing
improved text-able cell font handling
fonts are antialiased by default on android now

http://development.saphirion.com/resources/r3-gui.r

we'll see, but at least if it allows R3 to progress, even if we need 
to purchase a separate license for locking down your own apps (like 
it was with the SDK, and may dual-licensed GPL tools out there) I 
don't think its a big issue.  at least we don't have to wait.

Kaj how is the progress in testing on all platforms?

Half a Raspberry, or run two emulators! Good progress Kaj.

Yeah, I think my biggest was 18KB, complete listings of the TurboBASIC 
interpreter and compiler. We haven't made any progress since then 
;-)

Kaj, still very important progress too!

Thanks Andreas, Cyphre, Robert and all the others actively implied 
in R3 dev, the ongoing progress and all the tools you shared and 
have committed online. The R3Droid chat works well under my Android 
3.2 (Samsung Galaxy Tab 10.1). and the chat also runs fine under 
my Win7 Toshiba -  from the binaries set online at http://www.rebolsource.net

That article is still a work in progress.  Glad to see some approval 
:)

More great progress Kaj. I hope I can make time to play soooooon.

For example it would be nice to see the actual Android work in progress.

This is fantastic Doc. I know it's still very early days, but you 
are making great progress and it's very exciting to see it come to 
life. When I copied the commands from the new blog entry, to build 
the console, and it worked the first time, perfectly, it made my 
day. Then, even doing just simple things in the console was fun.

Kaj, sounds like great progress.

Robert, Woohoo!

I started my binding first, to try to help Doc make progress towards 
supporting Android. He used some code from it, but he doesn't need 
a complete JNI binding in Red itself

Kja, nice progress on OpenGL support!

Hm, my Atari 8-bit already had that. I guess that's progress these 
days

Definitely a work in progress, but has saved me some time.

Yes, it's in progress. Some like SQLite are one-to-one in Red like 
in Red/System. SDL is used more as a part in other low level bindings, 
such as OpenGL. OpenGL itself is waiting for floats in Red

To start some new discussions, 1) I like Squeak/Pharo Smalltalk's 
AIDA/Seaside systems. Hope to to practice them in realworld soon 
(creating a community site)... 2) I'm coding a new Oberon system 
 which will be able to do one of the following at once: a) interpret 
oberon b) translate oberon to x86 machine code c) translate oberon 
to javascript. This is a very long-term project, but I get excellent 
support from the oberoncore.ru community, and am actually making 
good progress. Current oberon project status is c++ sourcecode-based 
ssystem interprets oberon, interpreter has many temporary stubs.

Well, to save you some time you should get the R3 form repository 
either from Andreas or me on github. These repos are work in progress 
for Win/mingw at the moment (maybe others have simmilar repos as 
well)

Anyway, great progress ... looking forward to accessing large memory

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

Bit of both in my view. Money to support full time development. And 
the knowlegde to know how to is also sparse. A little bit extra on 
info and tutorial like stuff could maybe get some more people started. 
Google's summer of code like the HAIKU project is putting to use 
is beyond reach for the small base of devs for instance.

We are on the other hand lucky to have the enthousiastic giants we 
have now. It is enough to let the projects live on, but not in the 
way blooming as we feel should be the case. 

Yet the progress even in the last weeks is a great accomplishment, 
cannot be said enough..

Reichart -- glad to hear Altme is being actively worked on.  I'd 
got the impression from an earlier message of yours (on REBOL2, maybe) 
that Altme was what we used to call "functionally stabilised" (ie 
dead as a development)

Now about some interim releases? Create a sense of progress and momentum.

Thank would be good thanks.

Part of the problem is that though theoretical discussions are useful, 
a direct comparison ("is this better or worse than that?") is more 
likely to make better progress.

Thanks -- looks like there is a problem with the content-length header 
 (I thought there might be as I remember problems in testing when 
trying to get a value that all browsers were happy with. I think 
I've made IE happy while bemusing Firefox).


I've re-uploaded the script. It now doesn't set a content-length 
header. So, if you try again, it should work. But you may not get 
a download progress bar (because your browser isn't told the length 
in advance)

My apologies for the problem!

Good points.  And Charles had some trouble with 'printouts'.  :) 
 I stopped following
the progress quite a few years ago.

Thanks for all those suggestions.   I was out for quite a while and 
am very happy of all those remarks. It will help orient my trials&errs. 
 About  objects, dynamic versus static, If I understand it, in Rebol 
it is static?  I never had to use them except to encapsulate the 
whole of an app.  Is there a trick to mimick something dynamic to 
hold changing values?  Maybee a copied block is enough?  I wonder 
because I regularly try to add code to a bibliographic database, 
a kind of a variation on bibtex (never ended, allways in progress), 
And I am not too far from aiming the storage mechanism and wonder 
what I should use to hold something like from 5 to 10 thousand references 
(my actual need is 3.5K)  I used endnotes in the past, but dreamed 
about my own.  It is a lot of work (more than I expected as it is 
my first app).   Up to now I think I will use simply name-value pairs, 
like Carl's cardex.  This kind of data is more like a ragged array, 
the fields and their numbers allways vary, and I may amend their 
list with time.  The idea of using an object would be nice but need 
something where I may add or retract variable names and change their 
values.  By the way, I thank Volker for his edit-tools, that may 
help to add a writing pad.  And his double slider is refreshingly 
new for such and old paradigm as an editor.

rebmail 4.10.11 & associated helptext has been released (18/06/2005) 
...

Changes Since 4.9.6
4.9.7   - Enhancement - Import emails" "Phil Bevan" 21/02/2005]

4.9.8   - Enhancement - Apply rules to a folder" "Phil Bevan" 30/05/2005]

4.9.9   - Bug Fix - Correct backdrop on getmail progress window" 
"Phil Bevan" 31/05/2005]

4.9.10  - Enhancement - decode ISO-8859-1 / ASCII-US encoded text" 
"Phil Bevan" 31/05/2005]

4.9.11  - Enhancement - allow Shift select to select multiple emails" 
"Phil Bevan" 01/06/2005]

4.9.12  - Bug Fix - Ensure download time is updated correcly" "Phil 
Bevan" 01/06/2005]
4.10.1  - Enhancement - Add options window
4.10.2  - Enhancement - Add rules maintenance
4.10.3  - Bug Fix - Remove Debugging info
4.10.4  - Bug Fix - Make Select Folder in Rules work
4.10.5  - Bug Fix - Apply send patch under View 1.3
4.10.6  - Bug Fix - Better Error trapping when applying fixes
4.10.7  - Bug Fix - Fix folder returned from unknown folder name

4.10.8  - Bug Fix - Do not try to copy email to itself when applying 
rules
4.10.9  - Enhancement - Add default inbox for incoming mail

4.10.10 - Bug Fix - Make Select Folder in Rules datila work for View 
1.2
4.10.11 - Bug Fix - Ensure preferences work on new install


rebmail.r can be found at .... http://www.upnaway.com/~philb/philip/pbmail/readmail.r

reabmail is also the following formats 

rip format at  .... http://www.upnaway.com/~philb/philip/pbmail/readmail.rip

zip format at  .... http://www.upnaway.com/~philb/philip/pbmail/readmail.zip


the archive containing rebmail.r & rebamail.html (rip = compressed 
self extracting rebol archive)
 
Any problems let me know.

a 'progress version without sub-face:

progress: make face [
	    effect: copy [draw [pen blue fill-pen blue box 0x0 0x0]]
		data:	0
		font:	none
		para:	none
		feel:   make feel [
		    redraw: func [face act pos] [
		        if act = 'show [
		            face/data: min 1 max 0 face/data

              face/effect/draw/box: to-pair reduce [to-integer face/size/x * face/data 
              face/size/y]
		        ]
		    ]
        ]
    ]

Antor if you're interested, here's a screenshot of work in progress 
- http://krutek.info/pix/sintezar.jpg

http://krutek.info/pix/PM101.png(work in progress)

I'm starting to sort the concepts out, cross-referencing several 
explanations. I will have to tone down the explanations for my students, 
obviously. But to do so, the teacher needs to have a very good grasp 
of the language so as not to make faulty reprensentations that would 
work small scale, but not later on when some students progress further 
in the language.

Oldes, making some progress thanks to your help. There is one example 
with soem embedded rebol code (the arc example). Is there a way to 
have rebol do some processing then expose what it does to flash? 
I want to write a function in rebol to take a string and create a 
block of characters which I then want to pass to flash. 

For example, I can hardcode a_block: ["h" "e" "l" "l" "o"] but I 
would rather send the string "hello" to a function and have it generate 
that block then pass it to flash. It seems that what I do within 
a "rebol [ ]" block is hidden from flash.

Hi .... with recent Rebcode releases, we can see that internally 
new Core is marked as 2.7 and View is marked as 1.4 Is it just working 
"title" or will those products be marked as that? And if so, can 
we know, what other changes will go for 1.4 View release target? 
Will there be any AGG fixes/additions (to support SVG RebGUI progress), 
or even VID changes? I still think, that VID is missing few fine 
styles as tab, group-box, better list as was introduced on IOS Developer's 
server, (eventually tree, menu), to allow novices to start using 
VID/View more productively. Any chance RT can tell us, what is the 
plan for 1.4 release?

Q: What does the world on Nov-15-2005 look like?


A: Our main goal is to get REBOL into the hands of more users, not 
just programmers and techies.... by the millions over time.  By doing 
that, we create a market for not only handy free REBOL apps, but 
also for commercial apps and entire businesses that are related to 
REBOL.



Q: Given that  window transparency is OS specific, will there be 
a dialect that covers both Windows, Linux and 40+ other OS?  In other 
words, does RT plan on continued support of so many languages, or 
are we entering a new era of specific OS support?


A: Our plan is to make that a window option that is part of the face/options 
for a window.  If an OS does not support this mode, then the option 
will be ignored, but the application will still be fully functional.



Q: I hope it is still valid that cooperation with RT is possible. 
I mean - last few weeks I play with some Win32 functions (thanks 
to Gregg) and I would like we would have proper app behavior in multi-monitor/multi-desktop 
environments .... so I wonder if any SIGs will be created, some ppl 
will be invited to participate, comment etc., or if RT is gonna cook 
it all themselves?


A: Yes, there are many such special interest projects currently going 
on. (Most of them are occurring via private projects in AltME and 
IOS.)  These days 90% of REBOL changes are done in cooperation with 
the REBOL community.



Q: Hi .... with recent Rebcode releases, we can see that internally 
new Core is marked as 2.7 and View is marked as 1.4 Is it just working 
"title" or will those products be marked as that? And if so, can 
we know, what other changes will go for 1.4 View release target? 
Will there be any AGG fixes/additions (to support SVG RebGUI progress), 
or even VID changes? I still think, that VID is missing few fine 
styles as tab, group-box, better list as was introduced on IOS Developer's 
server, (eventually tree, menu), to allow novices to start using 
VID/View more productively. Any chance RT can tell us, what is the 
plan for 1.4 release?


A: Regarding 2.7 and 1.4 question: we change the revision numbers 
(the second number) whenever there is a major change in REBOL that 
may be unstable.  The /core 2.7 kernel (that is in /view 1.4 as well) 
adds new datatypes to REBOL, and they are the first datatypes added 
in several years, so we consider this to be a major change, and marked 
it that way.
Yes, we do plan to be making a few AGG fixes very soon.

Oh, and regarding VID: we plan to be making very big changes there. 
More to come soon.


Q: Could you add struct! support to /Core?

I keep on having situations that would be made much easier by struct! 
when I don't need libraries. For instance, conversions from external 
binary data encodings to internal REBOL values, say for file formats, 
network protocols and so on. Now rebcode has added other forms of 
strong typing like the type-specific opcodes and the vectors. Having 
structs with their constrained field types, their specific data layouts, 
would be a perfect match for the low level operations of rebcode. 
They would be helpful later when implementing your own data types 
as well.


A: On structs: yes, we will enable this feature on core, but it should 
only be used for lower level code.  Objects are more powerful.


Q: Could you add an APPLY opcode to rebcode?

    apply: ["Apply function or path to arguments, save result" word! 
    word! | path! block!]

In rebcode:
    apply x f [arg1 arg2 ...]
Is equivalent to this in REBOL:
    x: do f arg1 arg2 ...


The advantage to doing function calls this way is that the arity 
of the opcode is fixed, even if the arity of the function called 
can't be known ahead of time. The value assigned to the function 
word could be either a function or a path, or for efficiency you 
could have a seperate opcode APPLYP for path values (I'd prefer just 
one opcode for generality but it's your call).


A: I'm not sure what is meant by the path for it. You mean for refinements?
That may actually slow down the apply interface.

Any progress ?

About the settings: I would prefere something like built in side 
(top/left/down/right) bar which can be hidden if user want or still 
visible or even animated, where can be info about plugin version, 
configuration buttons or user defined buttons. In this bar there 
can be built in progress bar as well. I'm agains the right click 
context menu as the right click we can use for other user defined 
purposes, for example If I would like to make my own designed right-click 
menu etc.

I would make it also some 5% transparent, black and white design 
.... top bar displaying some basic buttons, date/time and progress 
dialog ... kind of minimalistic aproach ....

And definitely - interactin part - we need that config access plus 
progress bar - without progress bar, it has strange feeling, as you 
can't know, if something is happening or not, which leads you to 
reloading the page ...

How's progress on session handling?

Sounds like good progress then.