AltME groups: search

Ahh, just add a #.  Nice.

using string as a temporary data holder is ok too, as long as you 
can be sure the dataset will not get mixed up in a temporary value 
or actual string data.  either by its structure or content.

I can't say I've been 'using' Rebol for long, but I've been playing 
for quite a while now.  I discover something new every time I open 
up the system.  It's too cool how RT has put something as wide and 
deep as the ocean into a cup, a cup with blinking lights no less.

hehe  even if the cup has a few crack  ;-)

Issues can actually contain spaces, but they don't parse or mold 
that way. i.e. the datatype can hold them, but the lexical form doesn't 
allow it. Meaning you can get bitten, but do tricky things. :-)

>> a: #This issue has spaces in it
** Script Error: issue has no value
** Near: issue has spaces in it
>> a: to issue! "This issue has spaces in it"
== #This
>> probe a
#This
== #This
>> b: to string! a
== "This issue has spaces in it"

What makes a good dialect? Does anyone have any rules to share with 
us?

DSLs have been around for a long time.

A "true" dialect in REBOL follows REBOL lexical form--i.e. you use 
block parsing--which is what would be called an embedded DSL in other 
languages. The concept is often associated with Lisp and its descendants. 
REBOL takes it furhter, and makes it easier (IMHO).

What makes a good dialect? That's a hard question to answer. What 
makes a good GPL (General Purpose Language)? There is no formula 
I know of, but I would say it should be:


* Focused. *Domain* specific is the key. If you don't know the domain, 
it will be hard to get it right.


* Well thought out and refined. Don't just take the first pass and 
call it good. Like a writer, think about the words you choose and 
how they're put together. 


* Small. Think about how the language will grow, but don't try to 
put too much in it.

As mentioned, you can parse in two different ways in REBOL: string 
parsing and block parsing. Recently (after using REBOL for years!!! 
Yes, you always keep discovering new things in REBOL.), I start to 
think about the two different ways of parsing, before I make a dialect. 
It's rather crucial, which way you choose, creating a dialect. String 
parsing is good for dialects, where you allow the user to type almost 
anything ... where you give lots of freedom. Block parsing is good, 
when you want the rules to be more narrow ... when you want the user 
to think in terms of works and symbols.


Latest I made the math dialect for NicomDoc. I choose string parsing 
giving lots of freedom. The dialect ended up specifying presentation 
more than semantic. The dielect is good to produce the formulas, 
just like you want them visualized. If (when?) I would make a math 
dialect, where I would put weight on the semantic (the meaning of 
the mathematical symbols), I would choose block parsing.

import [
    name ["Chris" "RG"]
    address [
        street "19th Terrace"
        town "Birmingham"
        zip 35205
    ]
][
    name: block! [string! length is more-than 2 string!]
    address: block! [
        street: string!
        apt: opt string!
        town: string!

        zip: issue! [5 digit opt "-" 4 digit] else "Must have a valid US 
        zip code"
    ]
]

== [
    name ["Chris" "RG"]
    address [
        street "19th Terrace"
        apt none
        town "Birmingham"
        zip #35205
    ]
]

I'm not quite sure how to pan this out.  Also, the 'name rule doesn't 
have any set words, it is operating on an unnamed series.  I think 
I want this type of rule to match the content.  In that if [string! 
string!] does not exactly describe the content, 'name throws a bad-format 
error.

Nice Chris. If you can nest named and unnamed value blocks, what 
you say seems logical, that the parent block is given as the error 
location.


Why do you use literal bitset values, and have the human-friendly 
format of charsets just as a comment in the code?

You mean 'digit vs 'chars-n?  I've been using the latter for some 
time, mainly for consistency.  I'm going to migrate to more common 
names where there is a precedent.

Albeit, I'm not a master at measuring such things...

Gregg wrote (in group Rebol vs Scheme):

I would *love* to see mini-primers on language design for Lisp, Forth, 
Logo, etc. in REBOL.

I've taken the first step for a BASIC dialect:

do http://www.fys.ku.dk/~niclasen/rebol/basic.r

It only knows a few commands so far: auto list new old
And these statements: end goto print rem run
And these functions: cos sin

Very cool John. Now, let me throw another thought into the mix, just 
for fun. 


If you were to write a language interpreter long ago, you would do 
it in a low level language like ASM or, later, C. In those languages 
you didn't have high level constructs like we have in REBOL. Certain 
languages have very specific models; consider Lisp and Forth, each 
has a few core definitions and the rest of the language it built 
on those. Lisp has lists, Forth has blocks, etc. 

With REBOL, we can do things in many ways. 


1) Leverage all REBOL has to offer. For example, how hard would it 
be to write a simple Lisp system if you (basically) use blocks for 
lists and supply a few standard Lisp functions? Is eval'ing a Lisp 
paren/list different than DOing a REBOL block?


2) Write lower level code, simulating how you would have to write 
a language using something like C or ASM. You could go as far as 
writing a simple virtual machine with its own set of ops.


3) Write dialects that are designed for building specific kinds of 
languages, showing the core concepts of languages, where they're 
similar, and where they differ; tools for teaching language design. 

I think all of those approaches have something to offer.

I think that making a Basic interpreter in Rebol is more useful, 
powerful, and educational than almost any other endeavour I have 
heard regarding Rebol (ever!).


-	People like the idea of Basic.  
-	Almost all programmers know some Basic
-	Although "basic" it tells programmers this is simple to do.
-	It is a great way to learn a dialect.

-	It has "news worthiness" would be good to write a compete dialect, 
and post on SlashDot.

-	If you can run QBasic - it would me instantly thousands if not 
millions of applications that could run instantly on any platform. 
Probably all would be faster even with graphics.

What may happen, is people (kids for example) would begin hacking 
old Basic applications rewritten in Rebol, to show off.

100 lines of Basic becoming 7 lines of Rebol for example.


There is a group of people hacking Nintendo emulators with a program 
that emulates the joystick, and attempt to play games in the shortest 
time possible.  It is very interesting, but why these types of things 
take off is that people can have fun, and without too much knowledge, 
show off their talents.

This Basic dialect parse in block mode, and this set some restrictions 
on the syntax, but it's probably faster and easier to program the 
parse rules. To make a QBasic would require, I used string parsing. 
Probably the same for most other languages. Unfortunately I don't 
have much time for this project atm., because I have 3 examins in 
the coming week, and after that I'm on vacation for 2 weeks. But 
I would like ot do more of this. Maybe we could make a real project 
with some goals!?

I added a few new things to the BASIC:

added DELETE command, added arguments to LIST, added STOP statement 
and some more (see source). Example of use:

>> do http://www.fys.ku.dk/~niclasen/rebol/basic.r
connecting to: www.fys.ku.dk
Script: "BASIC" (24-Jun-2007)
BASIC

>auto 5 5
    5 print "Line 5"
   10 rem goto 20
   15 blab
   20 print "Line 20"
   25 stop
   30 0
>run
Line 5

Mistake at line 15
>10 goto 20
>run
Line 5
Line 20

STOP at line 25
>

Yes, I was not suggesting YOU do this, but rather than it be a goal 
of the Rebol community...

I use this guide as a base for the BASIC interpreter: http://www.nvg.ntnu.no/bbc/doc/BBCUserGuide-1.00.pdf
I found it on this site: http://www.nvg.ntnu.no/bbc/docs.php3

I choosed that one, because I once owned a BBC Micro. I have no idea, 
how far that is from QBasic. But I guess Basic is Basic. They probably 
differ in stuff like graphics and sound.

To Gress's post:

1) Yes, it's interesting to find out, how much we get for free using 
e.g. blocks in REBOL to simulate lists in other languages. Maybe 
using hash! will benefit in some situations!?

2) Using rebcode is also a way to write lower level code. But it 
should also be possible to define REBOL functions, that work like 
(or simulate) the lower level commands in other languages. 

3) Yes, it would be interesting to find out, how languages differ 
in their cores.

Read before you post! Read before you post! Read before you post!

(Does that help? ;-) Well, we sometimes get a laugh, when people 
don't do that.)

Could this group we [web-public]?

It's an interesting discussion of techiqyes that deserve a wider 
appreciation.

Web public. Yes
Gress = Gregg. NP :-)


QBASIC - Ahhh, now we get to have some fun. QBASIC is not your old 
fashioned, line-numbered BASIC. I think it would be cool to do both, 
but the Q(Quick)BASIC language is much better for writing programs 
that actually do something. I've been tempted to do something like 
that myself. To actually run exisiting QB code, screen access would 
pretty much be a must-have feature. Nothing like those old character 
mode interfaces you know.

A z-machine interpreter could be fun - plenty of infocom games to 
play. ... http://en.wikipedia.org/wiki/Z-machine

http://maschenwerk.de/foerthchen/


This guy has written a forth in javascript ... guess it's doable 
in Rebol

The start of a BBC BASIC interpreter using string parsing: http://www.fys.ku.dk/~niclasen/rebol/bbcbasic.r

How do we best get this rolling? I'm interested in making some language 
interpreters in REBOL, because I see future potential. Reichart and 
Gregg talked about QBASIC, which I don't know. Where are the specifications 
for that language? BASIC is a start, and along the line, I would 
like to dig into other languages as well. Is it best keeping it all 
public, or should we make new groups for teams interested in this?

Very nice...  As for the other questions...can't say...but well done 
sir.  And a nice reading code space to boot.

Nice John! I'm not sure how best to get rolling. I'm totally buried 
at the moment, but I can provide web space for the project if we 
need that. I also a number of grammars and things here, if we need 
references.

Oddly, I don't seem to have a QBASIC grammar. :-\

I started on a VB grammar once, which is similar, and I still have 
most of my manuals here somewhere. :-)

Gregg, first I'm making a simple 'engine' or 'template' for BASIC. 
Today I implemented expressions, some simple string handling and 
a little more. I'll make conditions (IF) and loops (FOR), then that 
should be a good start to build on.

3 datatypes is implemented. Examples:
a$ is a string
a% is an integer
a is a real.

Use a zero (0) to leave AUTO. Pressing <Esc> will end the BASIC intepreter.

New version 0.1.0 of BBC BASIC. Added FOR ... NEXT loop. Example:

>> do http://www.fys.ku.dk/~niclasen/rebol/bbcbasic.r
connecting to: www.fys.ku.dk
Script: "BBC BASIC" (19-Jul-2007)
BASIC v. 0.1.0 

>auto
   10 for a=10 to pi step -2.3
   20 for n%=1 to 3 step 2
   30 print a n%
   40 next
   50 next
   60 0
>run
                  10                   1
                  10                   3
                 7.7                   1
                 7.7                   3
                 5.4                   1
                 5.4                   3

A modern BASIC should maybe be able to recognize both lower an UPPER 
case, like in my examples. The original BBC BASIC distinguish between 
upper and lower case. I should change my interpreter to work this 
way, so already written programs will work.

One thing is to implement old languages, it could also be interesting 
to make a modern BASIC using block parsing in REBOL. That way, it 
would be possible to easily implement many of the datatypes found 
in REBOL. Also imagine to be able to have BASIC (or other language) 
code in the middle of a REBOL script, doing something like:
... (some REBOL code) ...
BASIC [
... (some BASIC code) ...
]
... (more REBOL code) ...

In the early 80'ies, before the era of PCs, the Amiga, Mac and Linux, 
there were a whole range of home computers more or less expensive 
(the BBC Micro were in the high price range back then). They all 
came with some version of the BASIC language. It was also possible 
to program in assembler (the BBC had a 6502 CPU). Imagine a new homecomputer 
with REBOL and rebcode. And many other languages supported as REBOL 
dialects. It should just have a keyboard, network, some RAM and maybe 
a memory stick instead of a harddisk. And connection to a monitor. 
That shouldn't be too costly to produce. Would it sell if the price 
was right?

Oh, and it should have a low-energy CPU to run the scripts, something 
as the G3, I think IBM made to only use 1-2 Watt. Then it could be 
sold all over the World.

geomol, I think you'd have to price it like a midsized calculator

I think also we need a new age of exploratory computing (meaning, 
people exploring other than porn sites and youtube), and it requires 
its own hardware.

the problem is that people expect to do everything on a PC, whereas 
in the 80's, people expected to do everything on a C64.

Pekr, is it strong enough? As datatypes, it support different kinds 
of integers, floating-point and strings. BASIC as a REBOL dialect 
would be able to have much more, wouldn't it?

Wow John! I haven't even had a chance to look at it since the original 
release and you're already on v2, well, 0.2, but still. :-) And, 
yes, I think it would be very cool to have a BASIC that supports 
REBOL's datatypes. Part of my, perhaps not so hidden, agenda for 
these things--in addition to being great for teaching language design 
and construction--is to show how REBOL can work *inside* the idioms 
other languages use.

:-) I have a feeling, that dialects is a good way to go, because 
so many problems become much easier to solve.

Geomol, the problem with such a computer is that it would only appeal 
to geeks, and geeks already have a pc anyway. for developing countries, 
there's the OLPC eventually.

i think, time would better be invested in an OS (both for geeks, 
and non-geeks). then you can make cheap computers for the OS to run, 
once it has been recognized, so parents could buy a $100 computer 
to childs (one each) instead of one big $1000 pc for the family.

Is there a Powered by Cheyenne logo?

Terry: I'm about to release a new version of Cheyenne with a redesigned 
and more reliable RSP engine. I've also started documenting the RSP 
API and features (takes much more time than I expected).

Powered by

 logo: they're is no one currently. I'll enhance the design of the 
 current logo and I'll add a "powered by" logo too (thanks for the 
 suggestion).

PHP support: Well, I hope there will be good news soon about PHP 
interface with Cheyenne as soon as I found a way to properly compile 
the latest PHP sources for Windows (compiling under *nix is ok). 
It seems that the latest PHP is able to fork itself automatically 
under heavy load in FastCGI mode. If this feature works well, I'll 
officially include the PHP interface in the next release.

ie. it uses a Rebol async client

Are you using a REBOL/Services layer for that ?

Just a rebgui client ..

I'm thinkin' ez-plot/q-plot might be a nice place to start for that 
app.  Hmmm.

I wrote a core based analysis tool some years ago .. dunno where 
it is now!

This rewrite rule takes any request (third line) for a file that 
doesn't exist (second line) and redirects to my cgi script.

For example, from this url: http://foo.com/pages/edit/1-- I get 
the Request_Uri value "/pages/edit/1" then parse it -- ["pages" "edit" 
"1"] -- here I have a controller, and action and an id.  It is a 
more enduring approach than http://foo.com/cgi-bin/qm.r?controller=pages&action=edit&id=1

why do you regard it being a difference?

The Rewriting engine for Cheyenne has not been implemented yet. I 
know that Will developed a simple one for Cheyenne/RSP based on PARSE 
rules.

I haven't delved deep enough to understand if this'd be better written 
as a Cheyenne handler, though that would require forking the cgi 
script, which for the time being, also has to run under Apache.

If I give you a customized Cheyenne handler for QM that can check 
URLs (with parse rules) and send them to /cgi/qm.r before checking 
the local filesystem, would it suit your needs ?

The whole Zope website is just a huge Python object, and when you 
access a path, the Zope webserver executes the object referred to 
...

Don't know how Zope handles rewriting, but the solution I've proposed 
to Chris is quite specific (even if it could be parameterized). The 
solution I had in mind for a Rewriting engine would be much more 
generic.

A few of us are experiementing with Chris' project .. so something 
that just sends everything to qm.cgi or qm.r would be helpful.

so, the application could just be a large object?  Or the objects 
are on disk?

From memory Zope has a disk based object database ...

All the application in a large object, if you design it like that, 
sure.

Very well, I'm currently testing the whole RSP framework by building 
a "test" application : a new web-based bugtracker ;-)

Yes, I quite happy with the speed and stability of the new implementation, 
I have RSP pages with 3 SQL queries to a MySQL backend, input and 
output filters, session handling, tables constructed dynamically 
with data from DB, all this occuring in a few milliseconds...I still 
need to test how it scales.

RSP now supports a thin layer for easier DB access. No need to open/close 
connections, they are persistent and pooled.

As soon as the bugtracker is ready, I'll put it online and release 
a new beta of Cheyenne.

I think I just opened a connection from start up and kept it open.

The "thin layer" I was talking about doesn't do much more than that, 
but it's done in a clean and handy way, and once for all.

I'm finishing a mod-qm for Cheyenne. I'll need to test it and will 
drop here a download URL.

hum, problem with [get-env "REQUEST_URI"], I can't set-env ! Is there 
a simple way to set an environment variable from REBOL ?

making a custom module if just not enough, I need a way to set  "REQUEST_URI" 
env variable.

Looks like it's stored in memory only : "In short, environment variables 
are internally stored as a pointer to an array of pointers to characters; 
this array is stored in order and terminated by a NULL pointer (so 
you'll know when the array ends). The pointers to characters, in 
turn, each point to a NIL-terminated string value of the form ``NAME=value''"

Sorry for QM, I don't have a simple solution to integrate it with 
Cheyenne, for now.

I don't need Request_Uri specifically, just something that acts that 
way.  When I say I don't want to fork QM, I mean the script -- a 
few 'if find request/server-software "Cheyenne"' calls are not a 
problem.

For example, if there was a way of hijacking 404s, passing the 'request 
uri' as do/args to %qm.r, that would work too...

Then in the CGI handler, I changed this line (just to see if it works, 
not as a recommendation):

Cheering squad: Give us a "C", give us an "h" ... Go "Chris"  


On a more serious note.  I've offered to help design/beta trial REBOL 
Want Ads.  QuarterMaster seems

like a candidate for this.  There isn't any time pressure, as this 
will take a while, but what is your gut feel for Cheyenne support? 
 From reading !Cheyenne you seem to have got a workable solution 
to get at the REQUEST-URI functionality?  Or was that just me reading 
with rose-coloured glasses?


Just FYI, the very first cut is going to be a blog.r test.  But I 
think rebols would appreciate a little more.

Thanks again by the way.

Sorry people.  This was meant as a private message to Chris...but 
now it's out there and that's...ok.
(Could you hear the Stuart Smalley impression?)

I have a 'workable' solution, but it still has a little way to go.

My Cheyenne installation has been modified, but I've noticed crashes 
when adding a trailing slash to an existing file (eg. http://cheyenne/index.html/). 
 I think this happens out the box in mod-static -- when you do info? 
%/path/to/file.r/ and file.r exists, it will return info/type of 
'file but when you read %/path/to/file.r/ you get an error.  Is this 
correct? -- view 1.3.50.3.1 core 2.7.0

Chris, sorry to not have chimed in before, I have a quite modified 
cheyenne that is in production for some time, only I have little 
time to help as I'm evely under pressur, somu guys came up with joomla 
in the company I work for, so it's either me coding from 0 or them 
assempling  jomla modules.. I could clean it up and send u a copy 
but this will be obsoleted by Dockimbel next version. it has rewrite 
rules and a slightly modified mysql protocol and a hihly modified 
mysql wrapper  to support stored procedures and getting data easly. 
like database: mysq://localhost/dbName db-open value: db-get 'table 
'column [{id=?} variable ] .

Will, thanks for the offer.  For the moment, I'm trying to keep QM 
server agnostic -- mod-QM is just good enough for Cheyenne support 
(also fixes the above slash problem).  QM needs to mature some, and 
I'd rather that development were contained to one script.  But when 
it is more mature, I can see now that it would benefit from a seperate 
Cheyenne implementation that more efficiently takes advantage of 
Cheyenne's features.

There was a question a while back about a REBOL web log analyser. 
 TGD did one.

AnalyseIt!.  Needs a license from TGD though.  It states personal 
use, but kakked when

I tried it under 2.7.6.4.2.  Perhaps they sensed I was days away 
from a trial run.

http://www.tgd-consulting.de/Download.html#AnalyseIt

Oh...haven't run a Mac since MacOS 7.  :)  Good luck.  If you get 
a solution, please
post.  I'd be curious and appreciative.

Donated to a dying friend, so when I miss it, I miss him more and 
try not to think about it.

I think a guru is needed here, it may be my modifs (none in uniserve) 
or a cheyenne bug (probaly not, Dock would have fixed it) or something 
in rebol or rebol/osx

thak you brian for the help 8-) time to go sleep here 6AM.. have 
a great day!

Looking again on the file handles exhaustion issue with a fresh eye, 
I found a case in the universe engine where file handles may not 
be released to the system. I'll make some test today about that and 
if the results are positive, I'll post a fix here for uni-engine.r

Graham, yes sessions are working ok now. I'm planning to make several 
releases this weekend, including a beta version of the new Cheyenne/RSP 
engine.