AltME groups: search

Yeah, it is on the list, I call it the Knock Knock feature.  The 
way it works is people can actually sign up before even getting into 
AltME from a website if they want.

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.

Ammon, yeah, I agree.  We are slowly locking down what I call a "pattern 
language."  In other words using the same UI parts the same way everywhere.

I think of communication software a little differently (in general), 
so I will share this.  

Read states

 (like the Red we are talking about) are a very interesting issue. 
  


Most computer software does a very poor job of replicating empirical 
or visceral conversations.  Email for example has a method of describing 
the "direction" you are speaking.  TO: Bob, CC: Carry.  Where the 
TO: indicates you are speaking directly to Bob, and that Carry is 
standing somewhere to the left or right of you.  BCC is someone hiding 
behind you. 


Email could have an interface where you first pick the people in 
the "room." And then use something like a 2D interface to move the 
listeners around a symbolic version of you.  This would be both silly, 
time consuming, and somewhat confusing, but you get the point.


What you have read and what you have not read though has a similar 
analogy.   There are thousands of sub states and markers people use 
to sort things they have read, will read, need to read again, need 
to respond to, etc.


In Box, Out Box, Papers upside down, putting papers you need to sign 
under your car keys on the floor in front of the door leading to 
the car, etc.


I have one friend who re-wrote some open source email program to 
have some huge number of states and then some simple filters.  It 
works VERY WELL, if you know his system.  He never forgets anything.


So the current model AltME has (right now) is a very simple interface. 
 Tantimount to "Have I ever seen this before."


We are playing with some other models in Qtask, which may get adopted 
into AltME.  I'm working on a system I call Venn Chat.  Some features 
include:

Have I read this before? (like AltME)
Mark this:  

Follow up (add to a list of messages you want to think about more)
Note (All should read this when they come into the group)
All Must Read (converts it into an AltME-like alert)


Convert to a task (and keep the context of the chat in place, this 
is opens up a whole other area)
Branch (something like forum threading)
Re-file (move from one group to another)

Re-post (copy to another group, at the same time, similar to branch).
Trigger (tell me when someone has finally read this).
Status (tell me who has read this so far).
Attach (files, links, etc)

Reichart, I like your ideas.

I would guess that one of the goals should be to pick a 'realm of 
inclusiveness' (I don't know what else to call it).

i.e. If AltMe is suppose to be fashioned as a message-logger then 
these 'new messages' should be flagged until read.

However, if AltMe is suppose to be fashioned as a meeting-place then 
maybe 'new messages' should only be flagged after you log in.


Now, don't get me wrong here.. I am not saying that messages shouldn't 
show up at all, I am stating that their container wouldn't be flagged 
(red).

and that normal becaus in C to initialise data I will use a malloc 
call witch will attrubute to a and b on the same based type different 
memory location

OK, Feedback .... but I dunno what license I'd like to use ... what 
would you call it?

I would call it an 'RT license for now.

Yep, we have our  own sort of flood detection running. I call it 
RID (rampaging intruder detection)


Problem with a captcha tyope solution is that we may need View to 
generate the random images. But our CGIs currently can only run under 
Core. Plus it disadvantages the visually disabled.

Each time I see an attack like this, it gives some more ideas for 
tightening up. Most of the time (like tis time) were one step ahead 
of the vandals.

http://www.rebol.org/cgi-bin/cgiwrap/rebol/view-script.r?script=rebcall.r
seems to work through a port. I guess he runs some native app to 
do the real call.

write-io call-port command length? command
        read-io call-port result 4

have run repack-core.r, then call "explorer .", double-click %qml-ed.r, 
"save html", saved with requester, an alert "Error saving file: Cannot 
open /C/Dokumente und Einstellungen/BN/Anwendungsdaten/rebol/public/www.rebol.org/library/public/template.html"

I would call this the Rebol Vault.  or in short   REVAULT which ties 
is very nicely with the REBOL itselft.

The structure of an object is static (which fields in which order), 
but the values assigned to those fields are as dynamic as you want. 
Also, if you want to add or delete fields it is quite easy to create 
a new object with your changes at runtime. If you are just using 
an object as what other languages call a dictionary or hash map, 
you might as well use a block or hash type for your data.

as for always-on-top or other modes of Windows, it is a pity we don't 
have them. It is just one single function call, which even C lamer 
as me was able to wrap ;-) ShowWindow or ShowWindowPos

Can someone recall me what function to call or where should I indicate 
a new download default directory of the console.  By default, it 
seems set to C:/Documents and Settings/AdminHome/Application Data/Rebol/public. 
 I would like to change that.  Thanks.

I don't see a difference between [ [] [[]] ] type nesting and what 
is currently used...I see that what you call "containers" are what 
the /  \  tags are doing.  Are you saying you prefer the scanner 
to die if the input is "illegal" than trying to proceed with it anyway?

Maxim: if you're guessed right on the access denied issue, you should 
be able to fix it by addind a few 'wait 0.01 to the 'do-handshake 
function. Put one 'wait just before each call to 'read-packet and 
if you have time do some tests.

Syllable is clearly focussed at the desktop, and we want a system 
that is as friendly as possible for regular users, while still being 
very powerful for people who know what they're doing, and offering 
a smooth learning curve between those two states. Pretty much the 
Amiga philosophy. And we have no intention of resting on our laurels 
once we call it 1.0 :-)

What I like a lot is that CALL and things like GET-ENV are already 
there, so you can do a lot in a Unixy system by calling external 
commands, which is exactly what my programs do

Dont know that eally well myself. what i firued out: usually (debian, 
suse) startup-scripts are in /etc/init.d. on debian there is a /etc/init.d/skeleton 
as base for own script. then there are the runlevels in /etc/rc?d/. 
links there go to /etc/init.d/ an tell the system what to start/stop. 
the numbers in the filenames are the priority, lowest run first. 
Usually there is a gui-tool like yast or ksysv which scans /etc/init.d/ 
for scripts and makes the appropriate links. tricky things are to 
write the startup-script, to figure out which runlevel to use and 
how the os figures out what to stop. although if you dont need that 
runlevel smartness, because you call it on boot and let it be killed 
by shutdown, you can just use a normal bash-script.

perk you are right it's call lol

OSX supports call, as far as I can see

I use 'call pretty frequently to shell scripting on my Linux partition

yes ;) But I allways fool my self betwin call and run functions

call is mutch fophisticate than run :)

call: i have 2.6.0.4.2 and call is there. IIRC thats the real release, 
not even beta.

Damn Small Linux 2.0 released..  http://www.damnsmalllinux.org/index.html


Damn Small is small enough and smart enough to do the following things:


    * Boot from a business card CD as a live linux distribution (LiveCD)
    * Boot from a USB pen drive

    * Boot from within a host operating system (that's right, it can 
    run *inside* Windows)

    * Run very nicely from an IDE Compact Flash drive via a method we 
    call "frugal install"

    * Transform into a Debian OS with a traditional hard drive install
    * Run light enough to power a 486DX with 16MB of Ram

    * Run fully in RAM with as little as 128MB (you will be amazed at 
    how fast your computer can be!)

    * Modularly grow -- DSL is highly extendable without the need to 
    customize

Well, I wouldn't call it 'junk'

Volker is suggesting this:

escape-metachars: func["escape metachars" s][
 replace/all s "'" "''"
 rejoin ["'" s "'"]
]

browse: func[url]compose/deep[

call rejoin ["screen -X screen -- " (view-root/bin/browser.sh) " 
" escape-metachars url]
]

That's why we call this "Open Source", which is not the case for 
Rebol.

Hybrid open source I call it.

I got following under my Fedora Core 1 Linux, when trying to run 
cgi, with rebpro (when run only in -c mode, I got only REBOL - Security 
violation). Am  I able to call librarie under CGI?

[[root-:-linux] jablunkovsko.cz]# ./index.cgi
REBOL - Security Violation
./index.cgi jablunkovsko.cz]#
** User Error: SQLite near "100": syntax error
** Near: make error! reform ["SQLite" error]

you can't call it CGI if you run it from the console can you?

Well, you don't ... rebol does not support sending email using sendmail, 
but

if you have a version with command-shell support ( call ) you can 
probably create the command line to call sendmail yourself ... I 
don't know how to do this, though.

CALL was freed for use in unlicensed Rebol/View some time ago.

no, i mean, does not call the cgi-stuff.

3) I would not put rebol in cgi-bin. If it is there, one can call 
the rebol-exe from the outside, without it doing a string. Never 
tried that, but it may think post-data is console-input. rights should 
be 755, only you can modify, but everyone can read it. the server 
may call it as "somebody else", and so it must be readable for that 
"user"

If you call it .. so what?  You can't feed it parameters.

but hard to exploit more. security is on, so only access to cgi-bin 
and childs. cgi-bin should not be writable by the cgi-user. except 
if cgis run as your account, then i could write a script with -cs 
and call that in the next step.

Yes, but i could also call hundreds of regular scripts to keep server 
busy. although this way is  easier, i can allocate lots of mem with 
one call.

can you have subdirs with cgi-scripts? so that you can call http://cgi-bin/project1/script.cgi
?

size-text: xwindows is client/server. the x-server , that is your 
local computer, which offers to aplications to display things to 
you. And it has some important informations locally, especially the 
fonts (and can cache images and such).

/view needs access to the fonts and so access to a running x-server. 
the x-libs are only an interface to connect to the server. (The xserver-libs 
could be used directly, but well, /view does not do that. Seems to 
be tricky.)
A incomplete sketch how to do it, with no attention to security:

So with /view you need a running x-server, one way to do that  headless 
is vnc.  Can also run on another machine. 

Then you need to tell  rebol where it is, there is an env-var $DISPLAY. 
Which must be set before rebol runs. Did not figure out how to configure 
that. Running a bash-script as cgi, set  $DISPLAY, call the real 
rebol-script should work. And there may be issues with authentification, 
x-windows does not like everyone to connect by default, or the other 
way around, its too easy to make it too open ("xhost + ip"). There 
are more secure ways, but looked more complicated and i never tried. 
All in all i would run such things on windows.

google "javascript cookies tutorial" and use rebol to call javascript 
to get the cookies

Hi,  question for the webheads.


   In short.  Can a form call a cgi action that processes data but doesn't 
   output any Content-type

(or anything for that matter) without the browser status coming up 
with "waiting for reply".


   I've got a client that wants a form for requesting more info, but 
   they want to leave the user on

the same screen, so I thought I could have a %process.cgi that takes 
the data and plays with it

and then have an intrinsic  onsubmit=alert(...)  to inform the user 
that the request has been submitted.

The %process.cgi doesn't 
print "Content-type ..."


it doesn't print anything, as I was hoping to leave the same browser 
screen up.

Am I living in lalaland?


Should the %process.cgi just redirect back to the original page with?


print "location: /original.html^/content-type: text/html^/"  or is 
that deprecated now?  It works under my test heads, Cheyenne and 
nonIE browser, but is there a bigger better way?  Or do I tell the 
client that the browser needs a new page and I can add a back link 
(not preferred).

Thanks for listening

usually PHP uses the sendmail command directly, not SMTP, so it can't 
be compared unfortunately (ie the fact tha php can send mails does 
not guarantee that rebol can). but, you could use CALL and call sendmail 
directly too if there is no other option.

One of my clients updates his site via some tool, which always seem 
to add some space between the lines. After some time, the page is 
instead of 400 rows something like 13K rows - the size goes from 
cca 25KB to 100KB. So I wrote a cgi script, which reads index.html 
and removes blank lines. Everything is OK, when I run the script 
from the console. But when I run it via a browser as a CGI script 
call, it can't write the file. Dunno why - cgi-script is being run 
using -cs switch, I even put secure none in there, cgi-script has 
the same own, grp set as index.html, but I can't write it ....

I call my internet keyboard "The Surf-BoardTM" ... ;-)

What do you prefer on notebook - touchpad as a mouse, or that IBM's 
- how to call it - stick between the keys?

first let me turn off this bill because it is messing up the speech 
recognition I think that is where the word call is coming from all 
all

I would probably like to see a cookbook example on some kind of error 
handling/redirecting to file or a nice popup window. I've experienced 
terrified users that call me about "that white text window with cryptic 
messages in it" that crop up on fatal bugs.

You forget et remove the 'update-tabs call in the 'show-pane function.

Carsten, I've added suport for " and ' in xml2rebxml. I've 
also added preservation of comments, if xml2rebxml is called with 
/preserve refinement (just call it like: xml2rebxml/preserve <xml 
code>). I've uploaded the scripts to my page: http://home.tiscali.dk/john.niclasen/rebxml/

I think, they need some testing, before they go to the library at 
www.rebol.org.

something called runit exists AFAIK. But i never understood what 
the advantage in regard to rebol is. i can just write a testscript 
and call it?

foreach file scripts[ call/wait file ]
and in each script:
 echo on
 print "Test1"
 ..
-> report

So we can call it RebSAX approach :-)) ?

Balancing the detail of the events against the function-call overhead 
of the language may be appropriate. One advantage to SAX-like apis 
is that you can register handlers for certain events and ignore others 
you aren't interested in, making your code even more efficient.

We have done a little in Qtask.  WE save the tasks as XML (and call 
it XLS so that Excel can load it).
We will be writing an RSS reader soon.

All works, "read/custom url reduce ['POST query-string]" did the 
trick! Thanks guys.

My little 64 line script now does the following:


 1) Read Address Book vCard file and extract a list of number/name 
 pairs (I prefix the numbers with 'n to assist with lookups)

 2) Read each Linksys SPA942 IP Phone's call history and create a 
 sorted list of number/frequency pairs

 3) Join these 2 lists and create a query string for matches and an 
 exception report for numbers without an address book entry
	4) POST merged and updated name/number pairs back to each phone


Script took 2 hours to write and debug, runs in 2-3 seconds and gives 
us the features of an advanced call management facility for free. 
Once again, REBOL to the rescue (my business partner shook his head 
when he saw this and just said, "but HOW can REBOL do all this???").

I meant to do a call for papers/presentation abstracts earlier, but 
have been busy, the time is still good.

It is already a time to do a call for papers/presentations to build 
up publicity, and to do a press release, which gives plenty of time 
for it to google up.

If it is decided to do, then first press release could be one for 
call for papers, not naming exact location, only the name, then when 
a location decided, a second press release. (just wanting to throw 
some ideas from last years experiences)

Find me a language that make it shorter ! (except a phone call, that's 
just 12 number ;-)

reason: first of all, the devcon is for rebolers first, others second. 
second, we need speakers, otherwise there's no point in having other 
people coming; if we have no speakers, then let's just make a "meeting" 
or "party" or whatever you want to call it.

Pekr yes, external library call can solve it (partially). I have 
to install some C/C++ SDK and start to learn it again...

That which we call a siren, by any other name would sound as sweet?

im going to port it to R3 tomorrow and rely on Call to play sounds

that is the set of proto functions - those string manipulation functions 
- you do use them everywhere ... even in graphics ... you have face, 
which has pane (container), and you insert, append, find, replace 
another gui elements, and then you call 'show ...

R, and you call it "SafeWorlds!"

denismx, when I've taught REBOL to people, even people who are already 
familiar with other programming languages, it has been helpful to 
make the distinction between the REBOL language and the dialect engines.


REBOL is really a data model and related syntax, and a bundle of 
library functions that manipulate data in this model. A dialect is 
really a semantic model for interpreting this data, like what people 
think of as a language in real life. A dialect engine is a set of 
library functions that think of the data in the same way - I know 
this sounds anthropomorphic, but it makes it easier to explain REBOL 
if you think of the different dialect engines as entities that are 
acting on a set of commands you are giving them. You can even use 
role playing to demonstrate this, having one of your students act 
out the part. It also helps to name each of these models after the 
main function that implements them - otherwise people might not get 
the distinction between them and REBOL as a whole.


There are some functions that only deal with the REBOL data model 
and don't really do anything with the data other than translate it 
from or to some concrete syntax. It is best to group these functions 
by the syntax they implement - the group that implements what people 
normally think of as the REBOL syntax is LOAD, SAVE and MOLD.


When teaching REBOL dialects I usually start with what I call the 
DO engine, what people normally think of as the REBOL language. DO 
is a stack machine like Forth, but it uses a prefix syntax to make 
it easier to use (by making DO dialect code more resemble that in 
other programming languages). DO also does a simple swapping hack 
to implement inline operators, which you will have to demonstrate 
so that your students will understand DO's operator precedence or 
lack thereof. DO always works on REBOL data: If you pass it a string 
or file that contains REBOL syntax code, DO will call LOAD to convert 
it to REBOL data - this is an important distinction to make so that 
your students can distinguish between the data and the processor 
of that data. There are many functions that depend on DO to interpret 
their blocks of "code", such as IF, WHILE, FOR, etc. It is important 
to note that these are just functions, not "syntax". DO's only syntax 
is the predefined operators that DO swaps (these are effectively 
keywords because of how the swap is implemented), the word/set-word/get-word 
difference, the interpretation of paths and the precedence of parens. 
Everything else is a function.


There is also the PARSE engine, a rule-based recursive-decent parser 
with limited backtracking, that implements three dialects (simple 
parse, string parse and block parse). These dialects actually have 
keywords, as well as an entirely different execution model. Also, 
there is the View engine, which implements the LAYOUT and DRAW dialects.


Refering to these engines as state machines isn't helpful, because 
the distinctions between their execution models, or whether they 
even have execution models, is important for distinguishing between 
them. You need to use the higher-level terms like stack machine, 
composition engine and such.

I hope this helps!

how about using 'call and some exe?

Was just checking it a little bit, and it looks that the mtasc is 
pretty complicated. First action script I wanted to compile using 
mtasc was not compiled successfully:) The biggest difference is, 
that the mtasc is only ActionScript compiler, but in my dialect one 
can compile everything (shapes, sprites, images, sound). You must 
use swfmill or how they call it to compile such a things (and it's 
using XML so I thing it's not much useful for making complete application 
in it (as I do).

And it's easy, you just run rswf and call MAKE-SWF and print the 
result (probably would have to remove some warnings which are printed 
when I run make-swf)

Using rebol to call mxmlc.exe and deliver it some Rebol generated 
xml gives you a Flash 9 .swf file all set to go.. kinda cool.

(By request, relayed from rebcode group) 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).

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.

Call it 1.3.62 or something :)

BTW i found the rebol desktop verry userful in some tasks its geat 
i IOS is even better but the leack ability of interaction with aplications 
and elements out there make it a bit "closed" to my taste, dont get 
me wrong here, i just mean it for those people we use to call "useres" 
the weenies :-) we dont need that :-)

Just on those issues I mentioned maybe someone here knows:


Issue 1 - CreateObject won't start Photoshop but does work with Microsoft 
products like Access, Excel, Word...

>> obj_application: createObject "Photoshop.Application"
--------------------------------------------------
ERROR:
--------------------------------------------------
Member:   Photoshop.Application
Function:     CreateObject
Error In:     CreateObjectEx
Error:    %1 is not a valid Win32 application.
Code:     800700c1
Source:   Application
CODE: -2147024703
--------------------------------------------------


If I start PS by hand or use Call from REBOL then there is no problem. 
It is starting the process which is the issue.

Issue 2 - Photoshop method PrintOut only works the first time, subsequent 
calls are silently ignored.


I had a loop so my workaround was to Quit photoshop programmatically, 
then restart it with Call - bit of a sledgehammer but I generated 
my cards :)

Ok thanks for that. Is there something I can use to start the application 
apart from REBOL's Call command?

wouldn't it be prettier with:

tts: CreateObject [Sapi SpVoice]
tts/call [Speak "Hello, let's have a conversation"]

just to make the syntax more smooth and REBOLish... :-)

you can call it REE-ball

Now I recall one my old rant... would be very nice if  there's a 
way to call rebol func from javascript.  Something like: 

<input type="button" value="Send" onclick="rebPlugin.evaluate('send');"> 

So we can build an html interface and use plugin & rebol instead 
of  XMLHttpRequest and Javascript

We need to investigate it. On IE, this is accomplished through a 
COM Interface to the browser object (via IDispatch), and then we 
call the method execScript on the IHTMLWindow object, passing the 
string of the code. But on Mozilla, there is no such COM interface, 
so we need to find if there is an interface available to the plugin 
to pass JS code.

The plugin itself can handle the automatic updates, or call an updater 
that can handle plugin updates too.

Google uses Flash and they use javascript's onresize to call the 
flash script's window resize function.

does not npruntime extension allow for both the ability to call into 
plug-in (being scriptable from the browser pov - probably java-script) 
and to access browser objects? Would be probably nice if rebol plug-in 
would support such new calls too ....

I still don't understand, how browser, loading it's rebol dll, has 
anything in common with being or not being thread savy ... you can't 
call the same dll from different thread of parent app?

wrt the slim word... you can rename it in the slim.r file if you 
really want to... but its your call.

ah... just wanted to announce a little milestone of liquid useage 
 :-)   In the current instance of liquidator, event handling and 
window refresh have been successfully decoupled  :-)  this means 
I can refresh based on a timer, instead of based on input events... 
 so I can now properly scale interactively of the view based on its 
weight without even removing one event from the view  :-)


you'd say... but we can already do that... well not exactly... yes 
 you can prevent the call to 'show in your mouse handling... but 
can you prevent the whole processing occurence when you are interactivally 
editing an item?  hehe .


because of liquid's lazy computing, the actual processing is delayed 
until needed, and the show will only occur after this.   so I can 
call update 30 times a second, and it will still only call show when 
things have realy changed, inversly, I can change the data 100 times 
a second, and only the real number of calls to update will actually 
cause a data refresh of all dependent data which changed (like the 
draw block :-)

and thus, even if you change any input node's values or link new 
stuff to node_c... none of that will actually call any processing, 
untill you ask for the content of  node_c

applying this to a gui driven with liquid nodes, you could freeze 
the the whole layout on a modal window... and let your inputs continue 
to process in the background... updating animation, and reacting 
to async reads... for exacmple.


when you unfreeze the gui and call a refresh of the gui plug, all 
the data which was being processed in the background, is now automatically 
available ,as if nothing had been frozen and a simple update of the 
node, will refresh you gui with nothing to manage.

It could probably call php as a cgi, but I don't think it's designed 
for such a purpose. And about version - the latest available are 
probably the best.

Will "Mike, I started using Apache and rebol as cgi, this is not 
suited for performances as on every call to the cgi, a new instance 
of rebol is  initialized, run and closed.

I thought about using fastcgi, but never came to a working solution.
Now I use uniserve as main webserver, here some advantages:

-it is fast! On my local machine I get +- 600 req/sec for static 
pages and a max of 160req/sec for dynamic rsp pages

-it is written in rebol, I could easly(less than 10 lines code) add 
a rewrite engine

-child process are persistent, this mean you can keep state of your 
web applications, implement caching, keep a pool of connection to 
databases open (in apache + rebol/cgi you'd have to open and close 
the connection for every request)
-it is written by Dock whom I may be the biggest fan ;-)

btw I'm running an unreleased version (have bought commercial support) 
 that support http 1.1, stuff like If-Modified etc..

If you have more specific questions, I'll be glad to try and answer."

the only thing it needs is someone to adapt it for cgi use... I have 
too little CGI practice and no real need, atm... so its hard to put 
time on this... but its a rebol script, so its easy to adapt.  all 
it would need is to check if its been started as cgi and call a different 
startup, which only prints out one file.  for static pages (which 
CAN include dynamic conent like sql queries) then its a very good 
solution which already supports site magamenent and ftp xfer.

I really do worry about conference a bit. No proper activity/propagation, 
call for sessions. The only one session so far is Carl's R3 introduction 
.... Hopefully it will all come ...

you could always call it "hocus pocus"  if you like that instead 
 ;-)

yes, but then i say, we meet, and allow others to see video stream 
(worked well in France), and call in via skype (just need to make 
sure we have a pc with skype set up ;). 100% virtual is not even 
1% of the fun. ;)

Call for topics and presenters placed in the checklist.
Sent out an email on the mailist to inform and gather input:

Dear Fellow Rebolers (of the mailist faction),


There has been some interest in a virtual gathering of Rebol developers 
and users. These discussions have been taking place in the Rebol3 
Altme World. I know there are many here that do not regularly go 
there but nonetheless would be interested in participating. The date 
and time that has been looked at is December 27th from 12:00 PM. 
How does that sound to you?


There has been no decision on the technology to be used but you're 
input would be much appreciated. We are also in need of presenters 
and/or desired topics.

To summarize, we are looking for:

An agreement on the time and date
Topics desired
Presentors
Ideas for technology to be used
Other