AltME groups: search

paul  -- try it: you already can:

http://www.rebol.org/cgi-bin/cgiwrap/rebol/search.r?find=sendmessagetimeout


There is already a win-api domain, so any script can be flagged as 
containing such commands:
http://www.rebol.org/cgi-bin/cgiwrap/rebol/list-all-filters.r

and since I am babbling here... I will throw in some suggestions 
as well.


1. User are not interested in how many scripts there is in the library.

2. User are not interested in how many messages in the mailing list 
archive.

However, user may be interested in

1. Most popular script by download
2. Latest script contributed to the library
3

user rating is an interesting concept......But that needs defining 
as a metric too. Who is rating for what? And who would bother?


Download is heavily biased by the fact that most downloads are by 
bots.

Older scripts are, by definition donwloaded more simply because they've 
been around longer

Also scripts near the start of the alphabet have an unfair advantage 
(they are near the top of any bots list)


Check out the "what does this all mean?" link on this page for a 
more detailed discussion:
http://www.rebol.org/cgi-bin/cgiwrap/rebol/script-popularity.r

The Library now has a search tool for the Mailing list archive.
     http://www.rebol.org/cgi-bin/cgiwrap/rebol/ml-search.r
Please play, and let me know the problems, thanks.

Problem is that the download page *is* a static URL if you go to 
it directly, eg,
    http://www.rebol.org/library/scripts-download/menu-system.r

But of you click the "download script" link while viewing a script, 
you do go via a dynamic URL -- it creates the static one for you 
and then redirects, eg

http://www.rebol.org/cgi-bin/cgiwrap/rebol/download-a-script.r?script-name=menu-system.r


{What we should do is update the static file whenever a script is 
added or updated. That would fix most instances of this....I'll put 
that on the list, thanks]

Just trimmed about 100 people from the Library membership list....
http://www.rebol.org/cgi-bin/cgiwrap/rebol/cpt-view-users.r


A lot of them were drive-by signups by spammers to get their URL 
a link ("Hi I'm Mandy, click my link for photos") And most of *those* 
must have an IQ hovering aound their waist size because they'd failed 
to click the profile option to make their URL visible to other Library 
members.


So the membership list (claiming 200+ members) is more relevant than 
it was before.


But the automated expiry script may have caught some genuine members. 
If your userid has gone and you want it back, please drop me a private 
message.

When we added validation for the license field, we limited it to 
licenses that had actually been used by people contributing scripts:
http://www.rebol.org/cgi-bin/cgiwrap/rebol/license-help.r


I reckon there are way too many license variants already in the world 
-- it's the bane of the open source movement. (We had a list of over 
40 licenses that people in theory said they'd like to use when contributing 
scripts)

But,. as the note on the page says:

f you'd like to use a license for a contributed script, and you can't 
see it listed above, please send us Feedback.

I tried doing a search for "probe system" in the mailing list because 
I know it is a topic that has come up a number of times and has been 
discussed.  After spending 30 minutes searching for relevant conversations 
but came up with essentially nothing even though I tried alternate 
search engines such as Google.  I'd like the ability to specifically 
search for code snippets.  I tried different methods of entering 
the search value but in every case I ended up with {Searched for: 
["probe" "system"]}  That's not what I want.  I want "probe system" 
How do I get it?

Sunanda,  I didn't try that.  I had assumed that search would use 
that index as a key.  Is there a way to search the topic index other 
than by clicking on a letter in the alphebetical list and relying 
on the browser's find functionality?

The library list talks about a new project where there is a patched 
version of View that can make library calls.  I haven't downloaded 
it .. and hope that it doesn't violate RT's rights.

Mike, I'd rather wait until the volunteer who is doing the RSS has 
added the code, rather than bypass their efforts.

Meanwhile, you have several ways of finding out what  scripts are 
new or changed on REBOL.org:
-- we'll sen doyu a tailored email

    http://www.rebol.org/cgi-bin/cgiwrap/rebol/cpt-update-profile.r
    See Section 4, Notices
-- you can peek at your unsent notices to get advanced warning:

     http://www.rebol.org/cgi-bin/cgiwrap/rebol/uns-display-notices.r?ml=yes&my=yes
-- You can use the LDS API:
       do http://www.rebol.org/library/public/lds-local.r

      probe lds/send-server 'list-updated-scripts [5]   ;; what's changed 
      in the last 5 days?
-- Just eyeball the script library home page:
     http://www.rebol.org/cgi-bin/cgiwrap/rebol/script-index.r

Graham in the All group asked:

<<Is it not true though that you are limited in what you can do with 
rebol.org ? >>
Yes and no.

It's a shared server with the usual sort of quote limits, so that 
stops some of the wilder plans.

On the other hand, the limits are fairly generous. Right now, we 
do these sorts of numbers:
* 150,000 CGI executions per month
* 2.5 gigabytes of data served per month

* 70 megabytes of hard disk used (mainly for the Mailing List archive)


Of course some sort of bandwidth quota would exist with a dedicated 
server too -- that one comes from the ISP, not the box.
---- 

We've had the same problem most of us have had with servers at one 
time or another: REBOL going feral and failing to close tasks. That 
brought down the server once, and got us suspended for about 30 minutes 
until I beseeched forgiveness. Of course, that could happen with 
a dedicated server (no one quite knows why it happens).


Similarly, we get some leak-through from what are supposed to be 
the chinese walls; and that has caused the odd problem: mainly file 
permissions going askew.
---

As Peter said, the main limitation is manpower. There are several 
things under development at rebol.org right now; there is room for 
many other improvement projects too.

Just an idea ... how about subscribing the mailing list to a weekly 
library update?

This way one would see, that at least something is happening in rebol 
land >:-)

Allen -- problem is we have *three* separate searches:
-- scripts
-- mailing list
-- articles
Not easy to decide which should be the one on the home page

If you pick a section, then the right search appears on the LHS menu.

have the single search  as a wrapper around the other threethan on 
the search list return page show the hits in the different catagories

Yes, I already get rebol.org updates by mail. 
And if the ml is subscribed, too we would get:
- some traffic on the mailing list
- more people know about rebol.org

- during those quiet times where _nothing at all_ happens on rebol.com/net, 
we show that at least _something_ is happening in rebol world.

Either that, or the publisher will need a list of which forums are 
public, and the date range(s) for which messages can be published.
That initial list would need to be constructed manually.

Thereafter, they could keep it up to date by watching for "[web-public]" 
to appear or disappear in group titles.

I would welcome more open AltME design - it is a good app. But maybe 
on rebol.org we could list on-line rebol related worlds, and provide 
free accounts, and maybe later on we can come up with mechanism, 
how to feed some info into db .... to be searchable

everyone, its all working now... sorry if we forgot to notify the 
list...

wrt slim, people might say its not documented... well, it was all 
documented on the web for a long time... but that didn't change anything. 
 And I can't be the only one providing all the answers for such a 
community oriented project.  Other people have to jump in.  The list 
of advanced features within slim is too long to list here, but it 
has many things even python coders wish they had.

Sorry, hit return to soon.  The above is supposed to be preambled 
with a whine about me not getting into the mailing list.  I can't 
talk to lists spat rebol spot com.  And I just noticed I didn't mungle 
the list email in above.  I mungled  IP addressed to xxx.

For those who never visit the Mailing List: Brian has stepped up 
to the mark and is a member of the Library Team.....He's going great 
work already:

http://www.rebol.org/cgi-bin/cgiwrap/rebol/ml-display-message.r?m=rmlVPCC

Sunanda: i keep the list of know words external to the script. there's 
a link to it from the html doc i posted (look for the #include directive 
and click on it). there's also a script that generates that file 
(apache directory index is enabled for that dir, so you'll be able 
to see it there)

Gabriel -- Thanks....A word list sounds a good way to go.
***

Jean-Francois -- a hover-over on kewords is certainly do-able and 
could look fun for the first couple of minutes on colorised scripts. 
Though it has drawbacks:
** it'd just about double the size of the page

** I think I'd be serious annoyed by it after 30 seconds -- though 
that may just be me

** lots of hidden-by-css styles (that's the way I'd do it, usng some 
of Eric Meyer's clevernesses) could create confusion for anyone using 
an elderly web browser or screen reader.


A good step in the right direction would be better styles for the 
code as we display it now.....So anyone experimenting with that is 
doing us all a great service ... Amd it would pave the way by creating 
a better foundation for higher cleverness.

like them hour
 should have been "list them here" (yes, I'm insane!)

Posted docs to the last of the Anonymous scripts.  Starting the  
none  list. Do I change the Author to Anonymous and the version to 
1.0.0 for these scripts, or just leave the headers alone?

if you just put maxim in the search field, blood is in the list

Also, the link to the list of license tags from the [license] link 
of a script is broken.  You have an extra slash in there.

Chris, one issue that we face with the mailing list archive is not 
knowing how the imput is encoded. I think this is also true of scripts.

yes, in the script description above the start of the script, under 
the :


     [View in color]   [View discussion [1 post]]    [License]   [Download 
     script]    [History]  [Other scripts by: moliad]



menu... just a list of uploaded images with a one line caption when 
you click on it, showing the full image. obviously, you should impose 
strinct size limits, enforcing proper compression.  and potentially 
a maximum size.

Thanks Maxim, that's helpful.......Not sure when I can start twiddling 
with something like that, but it's on my list.

area-face/line-list: none
show area-face

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.

There is no such thing as "fully fixed" software. :-) 


There are many many many things on the list that didn't get in, and 
even a little change like this--which may seem safe and easy--means 
more testing and inspection, often a lot more than you expect. 


In this case, let's look at how many people are screaming that this 
particular issue is killing their apps; not many; it's been around 
a while. Let's also look at whether we can work around it even if 
1.3 doesn't fix it; yes we can, and without too much trouble it seems. 
So, as one person hammering on RT to ship 1.3, I'd vote to ship without 
it.

Major highlights include improved audio/video support, support for 
CD writing with Cdrtools 2.1, enhanced POSIX compliance, a large 
list of kernel enhancements including basic ACPI support, a major 
new version of the GNU C library, several installation related fixes 
which should create a smoother installation compared to previous 
releases.

If you're interested in the video driver framework, we're now having 
an excellent discussion on the mailing list about how to integrate 
OpenGL:

to list the directory contents

Brent just posted his phone number on our public mailing list...

well, it's the latest update. just switched out warty with hoary 
in the sources.list and so I run Hoary :-) I think I need to check 
the DPI on both machines. I don't have any warty machines.

if the user sending the email (usually "apache" or "httpd" if you're 
on CGI) is in the trusted users list for sendmail, it will accept 
whatever you put in the From: header. are you calling sendmail directly 
to send the email?

I read your post on the mailing list and tried the code you posted. 
same thing....

if a dir is readable but not "executable", you can list its contents 
but not access files in it.

if x but not r you can access files in it but not list its contents

if both, you can access files in it and list its contents.

You're missing Lady and Lord in that list of titles :)

Looks good.

The problem with having a list of titles is you'll *never* think 
of them all [Ambassador, Brother, Comrade :-)] A type-in field would 
be more flexible.

Sounds like I should to think about other solutions of human control 
and image resizing & texts on them.
It is a pitty.

Human control could be organized by just set of image files with 
some "kidnaping" fonts letters and some simple script in Core.

Image resizing (f.ex. when uploading) theoreticaly could be done 
with Core - but it seems too much work for me now, because I dont 
know yet how image files is built and those resizing algorithms.
And about text placing on uploaded images I can forget.
All things above could be done in View just fine.
:(

It was good idea, that I made first my private blog site on Linux. 
Despite Rebol runs on so many systems - running the same things on 
other systems should be checked before. Especialy if there are no 
expierence of work on that system.


BTW I found in the google the similar response was caused from uncomplete 
View instalation: http://demo.rebol.net/list/list-msgs/34071.html
But it looks that this is not the case.

but I think, that it's not on the top in the priority list

Maybe the cgi script current directory is not where the index.htm 
file is.
See if you can list the file, eg. instead of 
	write/lines %index.htm data
do this:
	print mold info? %index.htm

Thanks.....that's a limitation of the approach taken by that design 
then.

Probably best not to use the same classes and ids as are being used 
the the templates for data editing. You'd need a list of the "reserved" 
names -- or ask him to use a special prefix to distinguish them from 
the ones you use.

The biggest restriction of CSS is you have to work harder to build 
layouts.  Otherwise CSS gives you *all* the control that depricated 
HTML attributes give you -- *plus more*.  So perhaps there is a dominant 
web style used by those experimenting with CSS (understandable if 
designers are learning from the same source, whether that is Eric 
Meyer, A List Apart, or WPDFD); but to use CSS as the excuse for 
this is a copout...

maybe at the 'checkout' part where u list all the items in the cart... 
that could be one of the area where I think 'table' is better suited

personally, within the product category, I would not use table. But 
the whole left column (seach field, mailing list subscription, prodcut 
category ) will probably sit within a table

For a product list -- a table -- then yes, I'd use a <table>. It's 
what they are for.

If it'sa single column table (just the product name, say) use a list 
-- <ol> or <ul>

That way the page is "semantically" marked up -- that helps accessibility 
aids.

a little suggestion.


the current cookbook page at , http://www.rebol.net/cookbook/, needs 
to have better tagging for sorting and searching purposes.

Example. An example can be tag to 'view', 'cgi', 'ios'


Or, we can break it up into 'logical chapters in a book'. Example

1. Part I. Rebol Basics
2. Part II. Advanced Rebol
3. Part III. /View Basics
4. Part IV. /View Styles
5. Part V. /IOS
6. List of Examples

rebol.org library already have tagging for the scripts.


Both in terms of levels ["Beginner" "Intermediate" "Advanced"] as 
well as the domain ["cgi" "gui"] etc...


Perhaps there is a way to feed the cookbook examples into rebol.org 
and let the Library be the holding place for future cookbook examples.


There are '3 major' rebol sites (those with rebol in the domain). 
And they are rebol.com, rebol.net, rebol.org.

It is not incredibly clear whether certain docs should be in .org 
or .net. 


Other suggestion to consider is how can we leverage off works done 
in various sites and avoid duplication. Why not let rebol.org be 
the host for cookbooks as well?


I would think new comers will prefer to find both cookbook examples 
and other contributed scripts all in one location. Rebol.org also 
lets you search the mailing list.

Tom started this group with a reference to
http://www.rebol.net/cookbook/requests.html

It's a set of outstanding requests for cookbook entries -- ie examples 
that people would like to see.

As he says.some have been done independently of the request, and 
published on the REBOLn Altmes or the Mailing List.

It'd be a great collective community New Year's resolution to clear 
some of the cookbook request by the end of the month (and that leaves 
plenty of time to enter the competition too)

If you use a linear structure it would probably be best to use a 
list instead of a block to better facilitate insertions and deletions. 
This would be OK because you would have to access it in a linear 
way anyways. But if you are doing that, you might as well be using 
an event-based parser instead of a DOM.

First, the values returned by get-elements-by-tag-name doesn't have 
to be in the same format as the internal block structure. It can 
be a list of objects that contain references to the original nested 
structure, or objects that contain fields that correspond to the 
information items that you want, including properties that are constructed 
at runtime like parent.

well, try to keep up your good work. What is standard anyway? Or 
just make some calculation, how using different technology makes 
process more complicated/expensive (unless your opponents don't use 
other open-source technology, e.g. python) ... the bad thing is, 
e.g. here in our company, that the price is not always deciding factor. 
RT does wery bad job here. Our managers want to read some success 
stories, want to see list of other customers who do use such technology 
.... some case studies etc. Maybe simply Europe uses different kind 
of logic than US.

I wish I would not have said anything about licensing, but I saw 
uniserver on the list and it's gpl.  that doesn't mean BSD, which 
was part of the spec.  I like BSD MIT school of thinking.  My brain 
doesn't jive with GNUfree  the old free was just fine.

Will do.  Thanks for your work on this enabler ... it's a long list 
of your work that i leverage.  [looking for the donate button ....]

list-dir

Oldes, I'm still amazed at this dialect and the sites you have created. 
I wonder if you have a list of the commands that are being used. 
I've been going through the examples to try to figure out what does 
what but it seems like a list would be faster. Thanks.

Oldes' dialect  is something I always wanted to study, but never 
managed. Adobe's products are very interesting as well to study, 
so I delved more time in learning actionscript directly. Next on 
my list is Flex. But Oldes' dialect is a feat on itself.

I will collect all questions from here and ask Carl. The mailing 
list is ok to send questions too. Anything that can reach me is ok 
actually.

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.

Kru, one of the list of suggestions we compiled for rebcode was a 
BIND opcode.

Q: (note - my view may be influenced by insufficient knowledge in 
the area given) - last weeks I played with wrapping some Win32 functions. 
I started discussion on dll.so channel, to ask developers, if they 
would enhance interfacing to C libraries in some way, and there was 
few ideas appearing. We currently have also rather strange callbacks 
support (limited to 16) and I would like to ask, taking into account 
that DLL interface in Rebol was not changed/enhanced since it appeared 
long time ago, if RT sees any area in which it could be made more 
robust, developers friendly etc.?


A: We are planning to do a lot more on DLLs. In fact, future versions 
of REBOL will expand on the way DLLs are used in REBOL.   For example, 
I would like to see DLL support for media loaders and savers, so 
if we do not directly support a specific type of media file (say, 
TIFF) then an external DLL can be provided to load it.  There are 
a few other DLL related features down the road, but it is still a 
bit early to talk about them.



Q: I realize that the open sourcing of the viewtop wasn't that successful, 
but do you still intend to keep releasing newer versions of it? AFAIK 
the current release is over a year old. I've experienced a lot of 
obvious bugs in the viewtop editor, which I think can easily be solved 
by people outside RT.


A: yes we will continue to release newer versions.  View 1.3.2 fixed 
a number of bugs in the Viewtop editor that were listed in on RAMBO. 
Any fixes and enhancements from the community are greatly appreciated 
(by everyone, not only RT!)  You can post them to RAMBO, and we will 
review and include them (if they look good).



Q: While reviewing the action! functions, I noticed the path action. 
The doc comment says "Path selection.". The parameters aren't typed. 
Does anyone know what this action does, and how to use it? Or whether 
it can be or should be called directly at all?


A: the PATH action is what the interpreter uses to evaluate VALUE/selector 
expressions for each datatype. It is an internal action and has no 
external purpose in programs. These kinds of words often appear as 
a sort of "side-effect" from how REBOL is structured.  Datatypes 
are implemented as a sort of object class, where the interpreter 
"sends messages" to the class to evaluate expressions. The PATH action 
is a message that tells the datatype to perform a pick-like or poke-like 
internal function.


Q: Is rebcode going to support paths and/or some kind of binding?


A: Certain rebcode can support anything we feel is important to put 
into it, but note: many things we add could slow it down, by a lot. 
 For example, if we were to allow paths as variables, I estimate 
that rebcode would be about two times slower than it is now.  Perhaps 
one way to solve this issue is for you to use COMPOSE prior to specifying 
your rebcode body.  Within the compose, you can use IN object 'word 
to "pre-compute" the context references for words. For example:

    add.i (in object 'num) 10


Your question about binding is not clear to me. Rebcode already supports 
binding. Your rebcode can be part of an object context, and rebcode 
function words are bound to the code context.  (Perhaps you are referring 
to an older bug that has since been fixed?)



Q: What do you think about  http://mail.rebol.net/maillist/msgs/39493.html
? Why not say a word in your blog, if you think that it's interessant 
for rebol developpment, and if you want to contact them ?


A: Recently, I had the chance to sit down and talk with one of the 
main people from the One Laptop Per Child project (he is a friend 
of mine from Apple Computer days).  The project has an interesting 
goal, but there are also many difficult issues around it (not just 
in the technical side, but also on the social and cultural sides). 
My current understanding is that the target software is Smalltalk 
based. Yes, it would be very interesting to allow REBOL on that system, 
but if you look at the list of principals for the project, you will 
see that such a revolution is unlikely.  Is it possible that perhaps 
REBOL could provide some additional capability in the future? I think 
so. We have some special plans that I think will bring REBOL to platforms 
like that in the future. But, this is too early to say more.



Q: 1. What is fixed/added in 2.6.2/1.3.2 (change-log, please) ? 2. 
What is planned for 1.4.0 (rebcode, rebservices, rich-text, RIF, 
and last but not least, fixed sound ...) ? 3. When can we expect 
1.4.0 ? Thanks.


A: 1. Gregg is preparing a summary. The document should be available 
this week. 2. We are evaluating a large variety of changes in REBOL, 
more than even the 1.4 release that we've talked about.  I hope to 
be able to say more about these plans soon.

Yes, this bind-like opcode was one of the requests that we came up 
with when we were compiling a list of rebcode enhancements. Thank 
you for implementing many of the other enhancements on that list 
:)

pity we don't know RT's priority list even a bit. 1.3.2, that is 
the cool thing. However, async kernel retired no-one is able to know 
for how long, rebcode is retired no-one knows what and when happens 
to it (e.g. will there be bitmap opcodes as discussed implemented?), 
unicode, rif (where even RT admits it is important for Altme2.0/coop 
project, rebdb is stagnatting because of that), rebin, we wait for 
what-is-going-to-happen-with-VID since devcon, being said we will 
know "soon" ... etc ... So, what is next, guys, and when? :-)

question: I own a Linksys WAP54G access point which runs on a MIPS 
processor with a small Linux server on it. I tried loading REBOL/Core 
for MIPS onto it, but it couldn't run.


The thing is, there is quite a lot of embedded hardware that runs 
such small linux servers. It would be easy to make control software 
via REBOL, connected to a PC running an encapped REBOL/View application. 
This would allow for rich realtime control software, rather than 
using the normal (slow and non-realtime) built-in webserver. I already 
managed to get realtime readouts on signal strength, by polling the 
access point through telnet and displaying a simple meter in a REBOL/View 
script, something not normally possible. But  you could do much, 
much more, if you could run /Core on it directly. I think there is 
a lot of unused potential here.


Would RT consider such ports of REBOL/Core to various embedded hardware 
products and provide a list of embedded hardware products that can 
run /Core?

just to keep you informed (this is not an official announcement, 
we will be releasing a roadmap soon), the development of REBOL 3.0 
is starting. no eta or feature list available yet.

You should announce this project on the mailing list as well .. I'm 
sure that there will be a lot of interest.  This channel isn't web-public.

no, the mailing list.

cyphre, hopefully it wouldn't have to be the end of it. it should 
be the final product that users should pay for and native support 
for GUIs is not the goal but the means. I think it would be a bit 
sad if Rebol had yet another essential component as payware. you 
can do most of this stuff for free on other languages, which would 
cause even smaller motivation for using Rebol as a development platform.


this is why I release my components (LIST-VIEW, Tester, Tab-view, 
TOOLBAR) as BSD licensed freeware. If I didn't, I would have zero 
users.

There was a video link posted on the mailing list to chickenfoot 
.. which allows you to script Firefox.

But I have to put the drug in the top field, search, select the highlighted 
item in the list, move it to the right list and repeat till done 
.. then check interactions.

My list is shorter : Rebol.exe ;-)

Seriously, I'd love a list of any security problems that you guys 
have encountered as you've used the plugin.

OK, I got the REBOL title issue on the list.

An OSX version would probably be their request list as well.

(I want to change the above priority list. Mozilla 1.3.2 and IE 1.3.3 
are equal priority, pri 2)

regarding security: so we need a list. i.e. change #1: disable xyz. 
change #2: make xyz a prompt that looks like this. etc.

Regarding timeframe: I'm still in the middle of developing this new 
installation system which will allow automatic updating. After that, 
we'll move to whatever you guys think is next on the priority list. 
Maybe security? :)

Right. It will be on the list, but may not make it until REBOL 3.0. 
That seems a little tougher to do. TBD.

1) UI - we are not Flash player, we will likely produce real-life 
apps. So - do we give up right mouse click for configuration options? 
What if you will have your own one in your app? OTOH imo there NEEDS 
to be some UI for setting some parameters! Not everything which comes 
to my mind can be hidden from user. The ones which come to my mind 
- do you want to check for updates? Once a month, week, daily, Automatic 
downloade newer version? Ask, download. Use newest version if app 
does not specify its requirement? (maybe not needed, just an example 
of what could be configurable). Proxy settings .... List available 
version, provide uninstall button, etc.

2) Installation - I like several versions installation - IIRC even 
Java can coexist? I use it with mozilla - I run Mozilla suite or 
Seamonkey, various versions from various locations - they do share 
profile - settings, sandbox .... 'Needs field could work for us too. 
If the app specifies it, try to locate particular version. If such 
version is not available, display dialog, where you preselect latest 
version and provide with list-box, with ability to manually choose 
from available versions ... and "run" button ....

hmm, firefox extensions can get an entry in the options dialog, or 
they can be configured from the list of extensions ... haven't found 
anything like it for plugins, though.

PhilB: make sure you've got it in the right plugins directory. if 
you go to about:plugins, it should appear in the list. make sure 
you coped both the DLL and XPT.

I can see cheyenne cookie in the list of cookies for SeaMonkey ...

For Text CGI script I get:


#!/usr/bin/rebol --cgi REBOL [ Title: "show" File: %show.r ] print 
"Content-type: text/html^/" print {Back

} print ["Script path :" system/script/path "

] print 
CGI Object :" print "

 foreach name next first system/options/cgi [ either :name = 'other-headers 
 [ print [
 name 
: 
] foreach [n v] list: system/options/cgi/:name [ print [
 n 
: " mold select list n ""] ] print "
 ][ print [
 name 
: " mold system/options/cgi/:name ""] ] ] print "
 if system/options/cgi/request-method = 

POST" [ vars: make object! decode-cgi make string! input if not empty? 
next first vars [ print " Variables passed :

 foreach name next first vars [ print [
 name 
: " mold vars/:name ""] ] print "
 ] ] print 

that is probably true. however I may change the architecture a bit 
since the parser is limited to two levels and is not recursive. the 
pages are generated from a limited list. all I really wanted to do 
was to make it easy to combine blogger.r, makedoc documents, dir 
listings and customized html output in a pipeline. it does most of 
that now, but the parser is only about 80% elegant. :-)

sorry pekr, posted the link as there is some info not present on 
the official site but that page may be more internal organization 
stuff but at least there is the list of people involved. Hopefully 
some of them are listening and will come with updates.

I just registered Carl and myself for the conf.  Does anyone know 
how many have registered yet? I wonder if we should have a list of 
attendees on the conf website or is that not a good idea?

on my list there is better keyboard support, but a part from that, 
have any of you trying to do games ever gotten to a point where you 
give up for this or that?

hehe - you found my todo list - i didnt have to write it after all 
:)

James, do me a favour, click that little icon of the pen above the 
new messsage input window.  Then enter your list again in "one entry"

You will need to press control + S to send it, or press teh send 
button.

Then I can copy your list easily, and work on it.

For the Icons at the top: Blue = Crystal Mines, Green = Forests, 
Red = Gold Mines.  These are your base resources that reproduce each 
turn.  They create stockpiles of Energy, Wood and Gold respectively. 
 These stockpiles are used to activate cards in your hand.


card.png is the 'hidden' or deck card face.  This is used to hide 
the computer's cards and the deck and discard piles.  card1.png is 
a sample of the format that the card images are in.  This can be 
used as a basis for creating new cards to the correct size.  (86x64 
pixel size with a 7x7 pixel offset into the card1.png template). 
  I have a card editor that can add in the card details to match 
their stats etc.


Regarding image names - ill compile a full list and place it on the 
website later today once i finalise the deck size :)