scriptonite-dev

[Scriptonite-dev] CVS access.

[Etienne M. G. <eg...@j-...>]

Hi everyone!

I have made a few cosmetic changes in CVS.  One of the files I have added is
"ChangeLog". This file uses cvs log message history to keep record of every
contribution, as required in the LGPL license.  You should not update this
file by hand, as I generate it using the "cvs2cl" perl script. [So, just leave
this file alone.  I'll take responsibility for updating it.]

You should probably start working on the lexer/ast-grammar.  Or, you could at
least start discussing tasks assignments between developers.  SourceForge
allows the administrator to create projects [e.g. "lexer", "ast",
"interpreter",...] and tasks, and assign these tasks to developers using its
"project management" pages (http://sourceforge.net/pm/?group_id=2858).

If any of you wants to contribute, don't forget to ask "pvl" for being added
as a developer.  Then, you will be granted "cvs write" access.

If you do not know CVS, here are some references:

SourceForge specific:
Un*x/Linux: http://sfdocs.sourceforge.net/sfdocs/site/user/cvssshfaq.php  
Win*: http://cdx.sourceforge.net/win-HOWTO.htm

CVS book (online): http://cvsbook.red-bean.com/

------------------------------------------------------

Here is the basic Un*x/Linux operation.  You need not know anything more:

[assuming ssh/cvs is correctly installed]

FIRST TIME:  (avoids firewall problems)

[/home/myself/]$ echo ssh -P \$\* > myssh
[/home/myself/]$ chmod u+x myssh
[/home/myself/]$ export CVS_RSH=/home/myself/myssh
[/home/myself/]$ cvs -z3
-d[YOUR_USER_NAME]@cvs.scriptonite.sourceforge.net:/cvsroot/scriptonite co -P
-R scriptonite
[/home/myself/]$ cd scriptonite

NEXT TIMES:

[/home/myself/]$ cd scriptonite
[/home/myself/scriptonite/]$ export CVS_RSH=/home/myself/myssh

You may now start editing/modifying files.  If you want to add a new file
(ALWAYS in the current directory), simply type:

[/home/myself/scriptonite/src/]$ cvs -z3 add filename

If you want to add a directory, simply type:

[/home/myself/scriptonite/src/]$ mkdir dirname
[/home/myself/scriptonite/src/]$ cvs -z3 add dirname

If you want to remove a file, type:

[/home/myself/scriptonite/src/]$ cvs -z3 remove filename.

You cannot remove a directory.

To bring your local version in psych with the repository, type:

[/home/myself/scriptonite/] cvs -z3 update -P -d -R

To commit your changes, type:

[/home/myself/scriptonite/] cvs -z3 update
*** NOW: resolve any pending merge conflict ***
[/home/myself/scriptonite/] cvs -z3 commit
*** IN the editor enter a log message! ***

This is it!  Not more complicated.

------------------------------------------------

Now, for everything to work smoothly, we need a few project specific CVS
guidelines:

(0) DO NOT add any "binary" file into the repository.  (no .class/.jar files)

(1) DO NOT "import" source code, e.g.: DO NOT TYPE: 
  $cvs ... import ...

(2) Never create/use branches. e.g.: DOT NOT TYPE:
  $cvs -q tag -b...

[If you are knowledgeable about branching/merging, please use a "local" prcs
repository on your computer to do your parallel development.  Anyway,
branching/merging is "broken" and convoluted in cvs (in my opinion).  PRCS has
a much cleaner project (instead of file) version management system.  See 
http://www.XCF.Berkeley.EDU/~jmacd/prcs.html (Un*x only).  

We only need cvs because:
(1) prcs is not yet client/server
(2) it is the only repository available on SourceForge
(3) It enables us to get a "ChangeLog" effortlessly.

But, we must keep it simple: we'll use a single trunk.]

(3) DO NOT TAG.  Or, if you want to use tags, put your "sourceforge user_name"
as a prefix, e.g. EGAGNON_XXX.

(4) DO NOT EVER DELETE/CHANGE old revisions of files!  If you checked-in
something by error, just check-in again the fixed version.

(5) ALWAYS include a log message when you commit your changes.  This is
important, as this text is displayed in the ChangeLog.

[If you made a typo, or forgot it, please contact me, and I'll fix it. 
Please, DO NOT ATTEMPT TO FIX THIS YOURSELF.]

-------------------------------------------------------

What do you think of these guideline?  Please feel free to comment on these
suggestions, or ask for help.

Etienne
-- 
----------------------------------------------------------------------
Etienne M. Gagnon, M.Sc.                     e-mail: eg...@j-...
Author of SableCC:                 http://www.sable.mcgill.ca/sablecc/
----------------------------------------------------------------------

Re: [Scriptonite-dev] website

[Etienne M. G. <eg...@j-...>]

Cool logo!

Etienne

[Scriptonite-dev] website

[Pedro V. L. <eq...@eq...>]

hello guys,

I've placed a quick hacked webpage on scriptonite.sourceforge.net.
It's just a start of course.

I'll take a look at the grammar during the weekend.

bye

pedro

Re: [Scriptonite-dev] grammar

[Etienne M. G. <eg...@j-...>]

Uwe Hoffmann wrote:
> when I started resolving conflicts in the typed-up grammar I might have gone
> the wrong path down. Maybe we should keep the other version of the grammar
> around (the one before I started to mess with it ;-). 

I've replaced the grammar with this version in CVS.  I moved the files one
directory higher too.  (scriptonite/scriptonite/* -> scriptonite/*)

> On the lexer side most of it is copied from sablecc's java grammar so later
> on we should check to make sure we catch the token differences (there are a
> few between java and javascript)

Why don't you guys start looking at the lexer.  It will buy me some time.  I
have many other things to do.  I'll send a message as soon as I get some time
to look at the grammar conflicts (and the extra lookahead directives in the
spec...)

If you run out of things to do, you might also start thinking and designing
the simplified AST grammar.

Ideally, this is a grammar where precedence is removed, as well as unnecessary
tokens. e.g.

exp =
  {plus} [lexp]:exp [recp]:exp |
  {mult} [lexp]:exp [recp]:exp |
  {div}  [lexp]:exp [recp]:exp |
  ... |
  {id} identifier |
  {this} |
  {num} num;

statement =
  {if} [cond]:exp [then]:statement? [else]:statement? |
  {for} ... |
  ...

Obviously, this grammar will be ambiguous, and is definitely not the "parsing"
grammar, but it contains the semantic essence of the program, it is much
smaller and, it is a lot easier to work with.

At this point, don't worry about how to get from the parsing grammar to the
AST grammar.

This should keep you busy for a while.  You should put this ast grammar into
scriptonite/src/scriptonite-ast.grammar.  You can include a "Tokens" part, if
you want, but you should stip it from any unused token. (e.g. "if" ";" "for"
"+" ...)

Have fun!
 
Etienne

[Scriptonite-dev] grammar

[Uwe H. <uw...@ia...>]

hey gang,

when I started resolving conflicts in the typed-up grammar I might have gone
the wrong path down. Maybe we should keep the other version of the grammar
around (the one before I started to mess with it ;-). The expression part
was conflict-free. The statement part introduced a few easy to fix conflicts
but then the {} problem came. I was excited hoping to get it to work and I
might have rushed. Now that we have the grammar  typed in we should resolve
the conflicts in a more organized fashion with guidance from some
experienced people like Etienne...

On the lexer side most of it is copied from sablecc's java grammar so later
on we should check to make sure we catch the token differences (there are a
few between java and javascript)

uwe

[Scriptonite-dev] Test

[Etienne M. G. <eg...@j-...>]

This is a test