World: r3wp

OK, I will try ...

he just generates a large set of random chars

strange ... I even tried to do those consecutive parse examples on 
the copy of data ... the result is still random ...

I thought that first parse might disrupt the input, which is used 
for the second parse too. But it does not work even for the copy 
of the data ...

Following code almost kills my DualCore notebook. View exe consumes 
almost 1GB of RAM :-)

c: ""
for i 0 255 1 [	append c to-char i ]
data: to-string array/initial 255 * 255 random c 
print length? data
m: parse copy data "^/"
print length? m

print length? data
i: parse copy data "^/"
print length? i

did you calculate how many strings you build ?

I tried that code in R2 and R3.....R3 took about twice the memory.

UNICODE strings plus unoptimised data structures may account for 
the difference.

Worth noting too perhaps: after trying the test three times, unsetting 
'c and 'm and recycling .... R3 got stuck trying to get into 'chat 

Possibly some screwed up garbage collection when recycling large 
elements? The failure is repeatable.

http://www.rebol.net/r3blogs/0307.html

A bit of work to do for those interested.

I looked at Ratio's import-email function on the blog and was wondering 
if R3 is supposed to have an import-email function? He claim's R2's 
import-email function is buggy and there is really an unfixed report 
in RAMBO.

Is there any RFC related to the email string which is being parsed?

RFC 2822?

I'm not aware of any bugs with import-email... but of course it does 
die if you get non compliant email

I used to run a routine to fix an email first before running import-email 
on it .....  ie. add missing fields etc

R3 chat seems to be so much slower these days ...

Is there something wrong with the server?

I think there is a blog entry about this...

and a chat message .. tcp outages on rebo.net

Here's a newbie question:  In general, do scripts written for R2 
run under R3 as is or are there specific changes one must go through 
first.  I read that many of you are running older projects in R3 
and wondering how you are approaching the changes that might exist. 
Thanks.

there are many subtle changes, so I wouldn't expect too many scripts 
run out of the box. GUI scripts won't work at all.

OK, thanks Henrik. BTW, since your last info on the vid-kit. It's 
been working like magic, even the list-view!

Ladislav and I have both written about our early experiences:
   http://www.rebol.org/art-display-index.r?a=R3

Note the use of the RCO object (REBOL Compatibility Object)  that 
attempts to make scripts R2 and R3 runnable.

Thanks Sunanda. I've been holding off R3 as it takes "my all" just 
to write stuff in R2 and generally they are tools that "have to work." 
I feel badly though because so many of you are putting so much effort 
into it. I could definitely give a non-guru perspective. Thanks for 
all you guys do.

james, cool :-) I hope to get back to work on it soon.

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.