World: r3wp

hi, would like to know why have this error want i try to import a 
file in R3.

rebol[
	file: %carte-joueur.r
]

joueur: make object! [
	id: none
	nom: none
	prenom: none
	date-naissance: none
	adresse: none
	code-postal: none
	commune: none
	pays: none
]

rebol[
	file: %carte-db-joueur.r
]


db-joueur: make object! [
	table: 't_joueurs
	oo: make joueur []
	
	
	list: func[
		o[object!]
		/local
		fields-in-file
		where
		test-nom
		test-prenom
	][
		fields-in-file: select my-db/tables :table
		where: copy []

  if all[(not o/id = 0) (not none? o/id) (not empty? o/id)]  [append 
  where compose [id = (o/id)]]

  if all[(not none? o/nom) (not empty? o/nom)] [append where compose 
  [find nom (o/nom)]]

  if all[(not none? o/prenom) (not empty? o/prenom)] [append where 
  compose [find prenom (o/prenom)]]

   return self/find-where fields-in-file compose/deep [all [(where)]]
	]
	
	find-obj: func[
		o[object!]
		/local
		fields-in-file
		where
	][
		fields-in-file: select my-db/tables :table
		obj: none
		where: copy []
		
		foreach field fields-in-file [
			if not none? o/:field [
				append where compose/deep [(field) = (o/:field)]
			]
		]

  return self/find-where fields-in-file compose/deep [all [(where)]]
	]
	
	find-where: func [
		fields-in-file [block!]
		where[block!]
		/local
		return-list
		data
		obj
	][
		return-list: copy []
		data: copy []	
		obj: none
		either not empty? where [
			data: (db-select/where * :table :where)
		][
			data: (db-select * :table )
		]
		do compose/deep [
			foreach [(fields-in-file)]  [(data)] [
				obj: make oo []
				set obj reduce [(fields-in-file)]
				append return-list obj
			]
		]
		return return-list

	]
	
	insert: func[
		o[object!]
	][
		db-insert :table compose [next (skip get o 1)]
	]
	
	update: func[
		o[object!]
	][
		do compose/deep [db-update/where (table) 
			[(skip select my-db/tables :table 1)]
			[(skip get o 1)]
			compose[id = (o/id)]
		]
	]
	
	delete: func[
		o[object!]
	][
		db-delete/where :table compose[id = (o/id)]
	]

	commit: func[
	][
		db-commit :table
	]
]

i try to use rebDB3.r from Ashley

>> import %carte-joueur.r
>> import %carte-db-joueur.r
** Script error: joueur word is not bound to a context
** Where: make do applier make catch if import
** Near: make object! [
    table: 't_joueurs
    oo: make joueur []

but whit the word 'do haven't got the problem ........... why ?

do and import are the same or not ?

in doc R3 => http://www.rebol.com/r3/docs/concepts/modules-loading.html

Another method of importing modules is supported. If you use do on 
a module file, it will also be imported. This is provided as a convenience, 
because do has been used in REBOL for years as a way to load and 
initialize additional functions and values.

Looks like Frank Sievertsen did the python wrapper for openssl .... 
http://ns2.canonical.com/lucid/python-ncrypt

Claude, DO and IMPORT aren't the same thing at all. Scripts (loaded 
by DO) have a different context model than modules (loaded by IMPORT, 
DO or better yet the Needs header). Your scripts above don't set 
their type to module, don't export words, and have no name - they 
basically aren't modules. You should use DO and treat them as scripts 
until you better understand the module system. Ask in the "!REBOL3 
Modules" group here for more details and help, if you like.

BrianH: are modules complete? Or you still need protect/lock to work, 
to have all features we need?

(UN)PROTECT/lock is needed for module header security. Compressed 
modules are done and submitted (in theory), just not released yet. 
Delayed init is delayed until Carl explains a little what he means 
by that. The rest of the core design works,

Docs are not yet done enough - we need docs. And there's no prebol 
yet, for app bundling.

don't you think we need another round of bugfix release? There seem 
to be some critical tickets to implement ...

don't you think we need another round of bugfix release? There seem 
to be some critical tickets to implement ...

don't you think we need another round of bugfix release? There seem 
to be some critical tickets to implement ...

eh, I can see trippled my message :-) I have got connection outage 
for 20 secs ... strange ...

but let's Carl work on Extensions/Host kit better, bugfixes then 
:-)

There are some critical tickets that are essentially delayed. I think 
that all the critical ones that can be fixed right now have been.

We could do several releases that focus on bug fixes, but that's 
not what's critical right now - the next round of host changes is.

We could throw in a few fixes in with that though, like a few features 
got into a97 with the fixes :)

thank you BrainH

Are ports working properly yet?

>> p: open/read/write %a.txt
>> append p #{00}
>> size? %a.txt
== 1
>> length? p
== 0
>> close p
>> p: open/read/write %a.txt
>> length? p
== 1

You might be only reading the traversal length.

I would like to know more about Tasks.

How do we use them and how do we talk to them.

Ashley, that's a pending bug, already posted in curecode.  (I'm waiting 
to see if anyone reads the Host Kit source code. Compared to anything 
else, it's so clean and simple.)

I don't know why that length issue is a bug.  To me it seems more 
like a feature.

Ashley try using length? head p

I guess I'm saying that it would be a bug if it were only supposed 
to return the size of the file.  But  if it is to return the size 
of the remainder from the index position then I would say it is buggy. 
 Either way there is a problem with it. I just we keep so that it 
is returning from the index position.

If you ask me it is that head seems to be a problem with the file 
port.

unless we mean to modify those ports now without setting the port.

in other words head and next operate on file ports much differently 
then I would have expected.  I would have expected to have to do 
this:

port: head port

but this works:

head port

Next is the same way.

Again, if this is the intention - then I like it - and not sure if 
there is indeed a problem with length? but maybe our need to understand 
how to use it R3 ports.

I made some significant changes already to R3DBMS based on some of 
these findings and getting great results.

Doh wrong group.

R3..."Cannot upgrade from web."


using a96...is the server down or is there a prob with this version?

working now...never mind

Here is something I think that could be changed in R3 (and I'm pretty 
sure a lot will now explain me why it's not possible):

>> a: [1]

== [1]


>> a/1

== 1


>>
 a/255

== none

If we now have an object:

>> a: make object! [a: 1]

== make object! [
    a: 1
]


>> a/test
** Script error: cannot access test in path a/test


IMO it would make our life a lot easier of the last one would return 
NONE as well.

As object! is being used more and more now in R3 and (within the 
GUI) a lot of words in objects will only be present if there is a 
value available, we have to cross-check a lot more if specific words 
are present. And this can pollute the code.

so you want to access a missing value in an object and have it return 
none?

That's going to make it more work to determine if the value is none 
because it's missing or because it's none

It could be unset! or even a special NP! (not present). Javascript 
has a nice rule that it just skips things that are not there without 
an error. It makes the code very simple. And you can still test explicitly 
if it's available.

I would worry that it would make finding bugs harder

Anyway it sounds like a fundamental change .. to make all paths return 
an unset! value instead of an error if the path is absent.

All for the sake of not having to write some error trapping code

Robert, the whole advantage to objects is that for them it actually 
matters whether the field is there. Otherwise, binding wouldn't work. 
If you need the kind of behavior you propose, use the map! type instead 
- it acts exactly like that.

We like errors in R3, they are considered the programmer's best friend. 
The error you are complaining about is considered a feature.

What about a way to set an error level?  Only want to see levels 
of a particular severity ...