Making a random team generator

[ddalley]

I'm struggling.

My purpose is to make a random team generator. I started by trying to create a simple structured text file with the necessary data: event date and other event details, plus the team contact info. This data was all on separate lines.

I tried to use various methods described in REBOL For Dummies, just to extract this data, but it has not been easy.

Can someone please point out a good example program, to use as a guiding light for a simple database like this?

Thanks,

Donald

[Graham]

Show us how you are reading in the data ...

[ddalley]

I tried organising the data file in text blocks, so...

event: [

date:
car:
track:
team-size:
etc...

]

players: [

player1's info
player2's info
etc...

]

but when I parsed it, I was only pulling out the date. What I would like to do is have REBOL just read it in and know what the variables are without having to rip it apart, variable by variable.

I don't want to use a system that relies 100% on the file structure, in case a user makes a change to it by mistake or whatever.

What is odd, is the book uses "toload" in his example, but it seems the command has be dropped from use, but I don't remember it to know what today's equivalent command would be. Right now I am using read/lines.

[henrikmk]

I'm not certain exactly what you want to do, except that I can see that there is difficulty in reading REBOL structured data from a file. I'll give you some hints:

Make sure that you store the data in a LOADable fashion. This will make it possible to read the whole file in one go without having to manually (and tediously) read the file a line at a time.

This means that when you save the data, you can do that like this:

>> save %filename [a: 1 b: 2 c: 3]

We haven't stored the variables. They are just words and values in a block:

>> a
** Script Error: a has no value
** Near: a
>>

When you load it again:

>> load %filename
== [a: 1 b: 2 c: 3
]

This will load the block, but not execute it. This is a good security measure and a good place to do checking for code that might violate security. To execute it, simply add:

>> do load %filename

And the file contents is loaded directly into memory with all variables directly available for use:

>> a
== 1

I hope this was a push in the right direction.

[ddalley]

I think it will be what I need, but the Saving part will be done with a normal text editor, so is there going to be a file format difference between using it vs saving from REBOL?

I thought what I did was "save in a block", but I didn't "DO" the LOAD.

[henrikmk]

I think it will be what I need, but the Saving part will be done with a normal text editor, so is there going to be a file format difference between using it vs saving from REBOL?

I thought what I did was "save in a block", but I didn't "DO" the LOAD.

What is meant by loadable is simply that LOAD returns code that can be used by REBOL. LOAD is a very universal function, not just for files, but for any kind of data that needs to be imported to your REBOL runtime environment whether it's code, data, images or binary data. Data that is not loadable, is for example a program that would not run, due to a syntax error, a malformed object or something else.

Example:

>> load "[2 + 1]"
== [2 + 1]

This block was loadable, and no syntax errors occured. But it was not run.

>> load "[2+ 1]"
**Syntax Error: Invalid integer -- 2+
** Near: (line 1) load [2+ 1]

This block was not loadable.

Handling that more gracefully could be:

>> either error? result: try [load "[2+ 1]"] ["Not loadable!"]["Loadable!"]
== "Not loadable!"

There shouldn't be any difference to what REBOL saves and what is saved in your text editor, as long as you stay within ASCII limits and don't use Unicode or things like that.

The data you create in the editor is basically just a REBOL program that is executed in REBOL with DO LOAD. There are no special cases. Code is data and data is code. :-)

[ddalley]

It's still not working. Using the format above...

event-data: LOAD %event-data.txt
PRINT TYPE? event-data

PRINT JOIN "Event Date: " event-date

I get

block
** Script Error: event-date has no value
** Near: PRINT JOIN "Event Date: " event-date

[Brock]

Did you notice this typo in what you posted?  The Print Join...    is wrong,  event-date at the end of the statement should be event-data

[ddalley]

It's not wrong. That is the name of the date variable.

I know it's confusing, but this is just the line where the code stops working because the variable is empty.

If I switch the variables around, it will do the same thing with the first empty variable.

** Script Error: car has no value

So my LOADing is still not putting data into the variables.

[henrikmk]

Looks like you forgot DO in front of LOAD. Forgetting it will just load the file into memory as a block of words that are not bound anywhere.

DO does the magic. :-)

[ddalley]

No, I purposefully left it out for two reasons.

I tried it with and without the DO and the result was the same.

I couldn't find a reference to using DO that way, so I thought it might be a variation in the syntax.

At the moment, I still get the same error - the first variable has no value.

The exact data file starts like this, with no REBOL header:

event: [

event-date: 12-july-2006
start-time: 10:00PM
warm-up: 9:15PM
car: "DTM"
track: "Zandvoort Grand Prix"
laps: 40
player-count: 12
team-size: 4

] ; event

[Graham]

I haven't read all the above thoroughly, but if you do this where %test.r holds your data

event-data: do read %test.r

turns the data from a string into a block!

event-data: do do read %test.r

executes the block to create the global variables

However, I don't think this is a good way to do what you want.

[Carl]

We've used REBOL for the last 6 years to organize the games for the local soccer league.

It was quite a challenge because of all the variables involved. There were dozens of teams of different levels that had to play against each other in a fair fashion, a dozen or so fields some closer to town and others far away, games on different days of the week plus extra hours for games on the weekends, bye weeks when a team does not play, and finally there were coaches that said things like "we can't do games on Monday's".

All of the data is kept in REBOL format, so it is easy to edit.  The script itself is quite small, but complicated... using matrix manipulation to do the pairing up of teams.  Everything worked fine until we allowed other people to edit the data files, and it was difficult to get them to pay attention to the [ and ].  This year, Cindy wants to add a GUI to avoid that problem, but I suggested perhaps the data editors can type their input into a spreadsheet, then our script can import that data.  That's kind of a middle ground, but worth considering.

[Anton]

Hi,

your event-data.txt file contains a set word and a block:

    event: [
        event-date: 12-Jul-2006
        .... etc
    ]

When you

    do %event-data.txt

it is exactly the same as including the contents of event-data.txt directly in your script.
So what happens is the word EVENT is set to a block. What you wanted to do was
evaluate the block so that the code inside was also evaluated.
So you need to DO the value of the EVENT word, like this:

    do event

Now all those set-words in the block have been evaluated, too, so you should now be able to get the value of EVENT-DATE etc.:

    >> event-date
    == 12-Jul-2006

However, unless you bind into your own context, those will be global variables.
Since you mention databases I suspect you want to have many EVENT blocks containing different values, so I recommend creating a context for each block. So your data file should now look like this:

    event: context [
        event-date: 12-Jul-2006
        .... etc
    ]

Now when you DO your datafile, a word EVENT will be set to an object (also known as a context) containing a number of unique words (all the set-words in the block) *local* to the object - that is, they are not set straight into the global context. That means when you add a second event to the file, eg:

    ....
    event-2: context [
        event-date: 29-Aug-2006
        .... etc
    ]

the EVENT-DATE word and its value, in the first event context are *not the same* as in the event-2 context.
You can refer to each value like this:

    >> event/event-date
    == 12-Jul-2006

    >> event-2/event-date
    == 29-Aug-2006

and, if you need to muck about with words, you can refer to them like this:

    in event 'event-date

    in event-2 'event-date

I hope that gives you some ideas. There are other ways to organise it. You will be surprised how far you can simplify and cut down on cruft. Let us know how it's going.
Regards,

Anton.