AltME groups: search

so since we export some words and extension mezz are essentially 
unnamed modules... their content really is hidden and can't be extracted 
  :-)

although I guess scanning the extension with a hex editor will reveal 
the code inside!?

Just read a R3 blog post about the future of the alias cmd in R3. 
Someone commented that we should see the state of the art : http://www.extjs.com/products/gxt/
 not too foolish but can we do something similar with R2 or R3 ? 
That's where I would like  to go with R2 and R3 ...

The extension mezz are not just unnamed modules, they are real modules 
that follow the same rules as regular modules, including naming and 
isolation. IMPORT doesn't know the difference between a module and 
an extension.

You are right about a hex editor seeing the REBOL source though, 
unless you do something weird to generate the source instead of referencing 
a literal string. However, remember that the code in memory is the 
result of executing the code in the module source, generating the 
in-memory data. That generation can be really elaborate if you like.

hmm, actually does not sound like a plan ...

I think you are underestimating how badly REPLACE sucks. I wrote 
it, so I know it is as good as you are going to get in mezzanine. 
And it's a widely used and reviled function.

I expected such a comment on your part :-)

I agree about the need for replace being a native. I would prefer 
emphasis on other areas though, e.g. on parse enhancements :-)

If it didn't suck, it would be used a *lot*. This would be almost 
as much of a speedup as REDUCE/into and COMPOSE/into.

I more care about the completness level, hence I am a bit surprised 
that e.g. CGI mode is not on the list and networking protocols are 
low priority. As for those, maybe Carl plans that community should 
do it. But as for CGI - why are not CGI related mezzanines in R3?

Because there has not been any discussion or proposals for what those 
mezzanines should be yet. There isn't even any CuureCode requests 
for such - only a request to get CGI working on Windows (it already 
does on Linux).

Making a module, even a community library, is the best way to get 
the more complex stuff in. Post it to DevBase, start the discussion, 
get it refined, and then it may be incorporated, or may not be. Don't 
waste all of the work I did to get the module system working.

As for where the right place to put the CGI environment variables, 
R3 currently leaves them in the environment, and uses GET-ENV to 
get at them. When system/options/cgi was first created, REBOL didn't 
have a user-accessible GET-ENV function. You could easily write a 
REBOL function that could construct an object containing all of the 
information passed to a CGI process, but that function and that object 
would be web-server-specific.

However, you are missing the whole point of the module system: R3 
won't be as monolithic as R2, and will have fewer mezzanines, not 
more, on purpose. We are trying to make R3 cleaner than R2, and easier 
to customize for your specific use. That means less built in, and 
more added on, in some cases from a common library of modules that 
the community maintains. Non-CGI apps don't need CGI mezzanines.

Re user types, Its just that I've realised a common theme in the 
last weeks, and they all can be handled via a simple user type datatype. 
 They wouldn't need any C coding and can start very simple and be 
augmented as usage gives us valuable feedback.


Coupled with extensions, they could be a VERY interesting way to 
add toolsets to REBOL. (just like people do it in python  ;-)  


I could very easily wrap liquid, as an example, and allow completely 
invisible dataflow to some extent!  It would take me less than an 
hour to do with what I propose (once liquid works in R3).

BrianH, what's a quick check for CGI?

I don't really know - I'd have to look up the CGI specs and write 
a script. I don't have Linux working here locally, so I can't experiment.

it's easy to make a VID front end to pilot a oggvorbis player for 
example it's more difficult to mix VID and opengl.

actually it isn't hard to mix VID and OpenGL  :-)  all we need is 
a way to do a quick memcopy of the OpenGL pixel buffer into an image! 
datatype... that's it.  really simple.


now I dont want to be forced into using View though.  I want to be 
able to use extensions to control the windowing too.  I need to be 
able to use other window managers if I want to integrate into better 
engine which are already ported to all major platforms.  Things like 
open scene graph or other game-oriented 3D engine, DirectX, whatever.

extensions are the key to liberating REBOL from its platform limits. 
 just like python can focus on its core, all the rest is modular 
and is maintained by other people, not Guido.


once I get the OpenGL extension working to some basic level, RT will 
never need to support it, I am pretty sure, John, Cyphre, Henrik, 
Anton, I and others will be able to give it a life of its own, all 
that RT will have to do is provide a link to it on its own site and 
say that R3 supports OpenGL natively.


same for sqlite and pekr, and many other tools many of us use daily 
and wish we could manage with rebol instead.

pekr is a tool??

Device interfacing was officialy added to project-plan. It is a good 
sign it will come, along with image and vector datatype support. 
No callbacks yet though ....

pekr, once you see what can be done with a 3D engine you won't call 
it crap... believe me.  Apple's GUI is based on a 3D engine, which 
I believe is based on OpenGL... can't remember precisely.  same thing 
for vista's aero which is based on DirectX which also uses 3D.

Max - unless my GUI looks precisely the same on all systems, I don't 
want to use it, easy as that. So - give a call to gfx card and driver 
makers, and try to standardise that :-)

Anyone is free to do anything. What I don't like is early split. 
I think that R3 without View has little sense. Who thinks that Core 
will make it, is imo mistaken. What would be browser plugin good 
for, if it would be Core only - there is no point in making such 
a plugin. And what GUI will we get? Multimegabyte SDL linked one? 
No VID?

why would using OS integration kill REBOL... its the first complaint 
I have EVERY time I deliver an application to a client...  its not 
integrated into the OS.

I'm saying that I need to be able to get shit done.  :-)


as much as I like the community and would love to be paid to work 
on improving R3 and making the world a better place, REBOL is and 
will always be a tool.  my needs are not the same than yours, or 
Graham's or Carl's.

If R3 has VID3 working, I'll probably use it for some projects... 
but when GLass will start to work (using OpenGL) then I'll probably 
never need VID anymore.  simply cause it'll do 5000 frames a second 
for my interfaces, including very advanced looks and next gen functionality 
like run-time interface manipulation by end-users.

I hope there is no underlying assumption that a gui for R3 will make 
it hugely successful.

Just let Henrik build a GUI for both R2 and R3 ...

People forget that I chose REBOL a decade ago because it was the 
exact same design I had built as the language for the OS I have envisioned 
15 years ago.  


Now just about everything is in place for me to bring this vision 
to reality... finally.  (and not all of this is directly related 
to REBOL).

funny thing is that my project was initially called magma and rebol's 
original codename was lava and I wasn't aware of rebol until a few 
years into my design.  :-)

Name me any candidates for a killer app on vid now.

our killer app lays initially in plugin, and showing world few presentation, 
easy of gui creation, and some real service wrapping, doing a tour 
comparind sources. Wrap OSnews.com, when you post article there. 
Wrap gmail, or later on their Wave, and show the code difference, 
compare sizes, compare speed. And at the end of presentation do a 
bundle - show stand-alone app called gmail, not needing browser ...

I asked you for a candidate vid application ...

I was quite keen on the plugin .. I wrote a chat client, and a fax 
editor to run under the plugin.

Alright, new task: I have a linode server for various purposes. One 
more will now be to offer REBOL 3 in a webshell, similar to this 
one:

http://tryruby.sophrinix.com/


I'm going to need some help with that and I hope it won't collide 
with the Cheyenne already running there.

Henrik, have you purchased a Linode server for your stuff now?

Graham, yes, have had one for a few months.

Pekr, well, we have to figure out to extend the R3 console to javascript 
and basically do a console in a browser. It could be a big job.

I think Frank did a Rebol in Java which was accessible in a browser 
.. or something

Henrik, I think that Pekr is thinking of a browser alternative rather 
than a one to one replacement. 


Perhaps it would be difficult to use an extension to embed one of 
Mozilla's monkeys in R3.

Some requirements:


1. It would have to be a real console, so we can't simply send CGI 
jobs and close REBOL again.
2. There would have to be a way to spawn and kill consoles.

3. REBOL 3 will have to live up to its ability to limit itself memory 
wise. CPU hogging, we can't do much about. My Linode only has 384 
MB RAM right now.

4. The Ruby console can respond to various input and display help 
text related to what you are typing. This can be used to create tutorials.

5. I have a Cheyenne on my Linode. It either has to use it or not 
collide with it, if we don't use it. Can Cheyenne use a special R3 
process?

6. Managing the console output will obviously need to be done with 
AJAX.

7. Syntax highlighting seems a little superfluous right now, so the 
target right now would be a basic console.

8. In case this is too much on my Linode, I'd like to remove the 
console again. Then perhaps it would be better at that point to invest 
in a dedicated Linode server. :-)

Graham, I think this can be intercepted with LOAD. Perhaps you can 
redefine CALL to become harmless, or simply return a restriction 
error.

Pekr, yes, that will be an issue. But I think Carl will eventually 
comply, once he sees that this is a problem.

dir isn't a prograam, it's a cmd.exe command.

Pekr, demo is a mezz. Another issue is graphics commands, lowlevel 
View and such. How do we handle that? I'm not sure we want to submit 
graphics via HTTP to the browser.

Henrik - we might have more problem that that. Even with real plugin 
- imagine networking - we have our own networking, we don't use browser's 
one. For the console demo, it should not be probably a problem though 
....

Actually a RT branded Chrome browser would be great .. have R3 embedded 
into it.

I think that maybe networking is not a problem. I would shut 'call 
though, or some users will try to inspect your system :-)

Linode have some network abuse policies. I think we don't want networking 
at all here. Imagine a spammer taking advantage of this.

you could probably paste a binary that is decompressed and voila: 
SMTP server.

Can we prevent the creation of ports in case someone provides a low 
level alternative to READ?

henrik, maybe you can create modules for each session and use do 
within each module... they will be shielded from each other, but 
you'll only need a single rebol process to run all users  :-)

Henrik, there was a guy on EC2 who had his instance exploited thru 
some vulnerability and it started spamming for  a while. And the 
spamcop or something blocked his smtp server :(

no whatever calls your R3 decides which module to interact with and 
just calls something inside the module which returns the result of 
a 'DO executed from within the module.

What I am thinking is that your R3 would be talking to cheyenne via 
a tcp port and the communication would include a session number, 
which is mapped within your R3 server to a specific module.  you 
could easily kill modules when some events happen like sessions being 
 inactive too long

so basically, you build a little module in cheyenne which does a 
tcp exchange to your R3 server.  

the R3 server maps the request to a module, returns the molded result.

cheyenne then returns the value in an xml block which your ajax app 
did the request for.


allowing multiple handlers on the cheyenne side (and an equal amount 
of R3 servers) would allow you to support multiple concurrent users, 
but you'd have to map which R3 service is being used within the cheyenne 
module, in order to send your tcp request to a free R3 service.

does any of this make sense?

:-) I suppose we want a standard 80 column console.

if you bring up a javascript console, writeConsole("string") will 
output a string to the console.

MS just integrated code they already had... its just a run time which 
basically integrates .net and directX code...

sort of like a mini embeded windows kernel... very similar in spirit 
to REBOL actually... but taking the abysmal route in terms the coding 
interface (XML aaargh ... depressing).

http://97.107.135.89/projects/rebol/r3shell/


A tiny bit of progress. No visible cursor yet. Limited console history. 
Only capitalized chars (dunno why yet).

just had an error in my code, try reloading, I won't edit for a few 
minutes.

there is no R3 yet, only trying to get a decent console for now. 
returned values are just echoes of the buffer.

when i construct an event! with something like:
>> make even! [type: 'minimize gob: my-gob port: port-event]

i got:
** Script error: cannot set gob: field to gob! datatype

Wtf, i can't set the gob field with a gob ??????

seems that capturing the correct keycode is a bit chaotic in different 
webbrowsers.

I see, you are using a standard PC keyboard, right?

that is of course in VMWare on a mac.

You did not ask about Win32+Opera, but I tried anyway....

 % (shift+%) acts as a backspace.... but that is when the console 
 works.
Other times the console is just black.

if the console goes black, then the row is blanked out. pressing 
enter should reset that and give you a new line.

I think I'll have to rethink this. I've done it mostly like a traditional 
terminal, but this is clearly not very stable.

But it works sometimes and gives a new console line.

From Linux and Firefox and spanish keyboard. Every shift 0-9 works 
ok, but shift 7 open the "Quiick search of firefox". I think this 
is not a error. I read this is the Firefox default for shift-7

console is going to be down for a bit while I do a rewrite of the 
console code.

REBOL 3.0 accepts UTF-8 encoded scripts, and because UTF-8 is a superset 
of ASCII, that standard is also accepted.

If you are not familiar 
with the UTF-8 Unicode standard, it is an 8 bit encoding that accepts 
ASCII directly (no special encoding is needed), but allows the full 
Unicode character set by encoding them with characters that have 
values 128 or greater.

see the system/catalog/codecs for a list of loaded codecs

 - hmm, docs need an update. Dunno why the section was moved to system/codecs 
 ... will ask on R3 chat ...

possible, but I've always seen them output as double byte...  this 
topic has come around a few times in the last months

I think that to binary! will decode a Rebol string! to utf-8 :

>> to binary! "^(20ac)"  ;; Unicode code point for Euro sign     
== #{E282AC} ;; utf-8 character sequence for Euro sign

maybe peter's excellent encoding script on rebol.org could be used 
as a basis for converting between ascii -> utf8  when using R3 binary 
 as an input.  while R3 has them built-in

but R3 is now fully encoded, which is REALLY nice.  you don't have 
a choice.  Resistance is futile  ;-)

OK, so we have http headers, which are supposed to be in ASCII, and 
then html content, which can be encoded. Which responsibility is 
it to provide correct encoding? A coder, or an http server? Hmm, 
maybe coder, as I am issuing http content headers in my scripts?

Pekr: Just try a quick test with: 
 print to binary! "Content-type: text/html^/"
 print to binary! get-env "REQUEST_METHOD"
 print to binary! get-env "QUERY_STRING"
 print to binary! get-env "REMOTE_ADDR"

to see if it is an encoding problem.

but the loading actually does a re-encoding.  utf-8 is compact, buts 
its slow because you cannot skip unless you traverse the string char 
by char.  which is why they are internally converted to 8 or 16 bit 
unicode chars... it seems strings become 16 bits a bit too often 
(maybe a change in later releases, where they are always converted 
to 16 bits for some reason).

The content of the binaries are fine but their format is a probelm. 
Sorry, I forgot about that when I suggested to try them.

(as per a past reading on R3 blogs and previous discussions about 
this)

maybe a cgi-specific version of print could be added as a mezz which 
handles the proper encoding issues to make sure that console and 
cgi printing are both functional on all distros without needing to 
change the source.

Maybe there's a trick that --cgi could do with I/O ports.

but if we need to output latin-1 afterwards (while dumping the html 
content, for example), the output encoding  should be selectable 
as a "current default", and all the --cgi would do is set that default 
to UTF-8 for example.

and some systems pipe the std to have it pushed remotely to other 
systems... which can expect a different encoding than what is being 
used by the local engine... I've had this situation in my render-farm 
management software, as a real-life example.

FYI: posted a note on the september plan where I proposed a clear 
meaning of different releases and detail a better approach to deliveries 
where different versions are concurrent. Each one addressing a different 
aspect of the release cycle... this is how releases are handled at 
the larger places I have worked at ... maybe Carl could comment on 
this !?

which is why I say that releasing a Beta with stuff as it is already 
working is a good idea.  but continue working on an alpha which lets 
us give valuable feedback on stuff to come.  The curecode bug squashing 
is concentrated on beta version, design & core implementation is 
limited to alpha/experimental versions.

many issues where raised because of the alpha nature of R3 which 
would have ended-up in a screwed up release version, in the old RT 
philosophy.

** But a lot of R3 is working very well right now.  **  


Going to beta could also mean that a select few people have the capacity 
to build the ports to other platforms. Squashing OS related stuff 
in parralel with stuff specifically in beta, meaning they would NOT 
have to concentrate on the latest alpha buggy stuff to fix and port.

releasing a Beta with stuff as it is already working

 - what is the point in calling it beta then? Carl will surely continue 
 to implement new stuff the way he did it till now. Calling something 
 a beta just for the sake of the word itself, is not important for 
 me. Features and completness is important ...

once you get to beta, the porting is official, for example... its 
just a definition of what you can expect at this point. what is in 
the beta works... what is in the alpha isn't guaranteed.  but many 
of the bugs are independent of what is new in the language.  so these 
later bugs can still be fixed in the beta stage even if new features 
are being added.

yep.  beta is limited up to the point where the alpha stuff works, 
at which point the beta/releases have new but working features just 
needing more testing in order to be sure all is well.  but the important 
thing is that if something really is discovered in the beta, you 
can still officially change and go back.  at which point something 
rolls back to the alpha stage and Carl plies his will to that specific 
problem in priority.


its just a way to make expectations, promise, and procedures clear 
and explicit.

right now... there is no rule to say when "we go into beta"  no way 
to clearly say what will go into the beta and why.  its just some 
vague point in the future... "soon".  having this explicit means 
we can have beta and alpha concurrently, with a clear path to release. 
 today, I still can't know what to expect will be in the beta.

we could have a R3/core beta version next week with a subset of what 
is in the R3 alpha today.  (if the last of the very core issues are 
finished by then).