AltME groups: search

is it too big to be posted directly? maybe you could just post a 
link to the code...

your post in RAMBO? you can't. I'll have to change it for you, or 
we can dismiss the old ticket and create a new one.

Regarding async speed: I posted a note in the async group to look 
at that closer.

Just noticed: HIDE stopped minimizing a window face some time after 
1.2.5.3.1, eg:
	view lay: layout [button [hide lay]]
Is that a bug, or intended? (I'll check this out more later.)

*smackme* right, its turned in a rebol-value..

almost always
 - when it is a valid word. :)

On HIDE: sounds like could be a bug. So add to RAMBO if not already 
there. Thanks.

Why couldn't paths do that for us ? ie. to-path "042" becomes a word...

Gabriele, I mean, that a path component should be converted to a 
"string" word only when it can't be parsed into a normal rebol value.

ah!  I have to add a bit extra:  ".... which molds back to the original 
path component string."

load-path: func [str [string!] /local result val][
	result: copy []
	foreach component parse str "/" [
		either any [
			error? try [val: load component] ; loaded doesn't parse it
			component <> mold val ; or it looks a bit different
		][
			append result to-word component ; make a "string" word
		][
			append result val
		]
	]
	to-path result
]

load-path {my/path}
load-path {my/path/042}
load-path {my/path/1.s3m}

oldes: i don't think it's disarm, it's more likely that you hit a 
GC problem. btw, most of the code in the errors seems to come from 
some handler.

It's interesting, surely, but it doesn't make me feel any better 
about it. It's like I have discovered a scratch on the nice smooth 
surface which is the rebol user interface.

Anyway, now I should try to sink my ship; I don't think adding the 
above functionality (of load-path above) to LOAD would slow things 
down at all. But maybe there are some cases where such allowances 
would cause problems. I am thinking if such a loaded path was converted 
to a block, molded, then loaded again, it would cause the error then. 
That's just moving the load error - from the path to the block. I 
think this contrived case would not occur very often - less than 
using new path notation.

I need someone else to chime in here with any scenario which would 
cause a problem using this path notation, because I don't currently 
see any serious problems with it.

that could be solvable: convert the part to a string (or file). block 
then has a string. if you do to-path block, you get dir/"042", but 
that should be ok (with new pathes). its not more "buggy" than making 
42 from 042 IMHO. would be nice to get this, and pathes ending with 
"/" :)

IMHO, Paths were definitely meant to be able to files you just have 
to realize that you are dealing with a path not a file datatype.

so, i don't really see where's the problem in using a file! instead 
of a word when a component is not a valid word

IIRC in the bbs-project Carl prefered [data-file: dir/file] over 
[data-file: join dir file]. i prefer that too, but currently no "/", 
so [data-dir: dirize dir/file], ugly IMHO.. And now comes changing 
file-names when they are numbers. thats a bit risky to me.

Literal filenames within paths are a bit of an exception -- the standard 
method should be to use % or " around them.

Well, I'm sticking to my guns - I have some supporters, and the opposition 
is weak :) so I'm making a rambo ticket.

o: make object! [type: 'face]
third o
; == [type: face]  ; <---- should be a lit-word!   ?

OK, submitted a ticket "Load paths in a more relaxed manner".

There is a limit on the number of callbacks available I think is 
16.

That is because rebol can only have maximum number of callbacks. 
It is a design decision.

How safe is catch?
	

I have some rebol applications serving message communication (around 
1000 to 2000 messages per day mostly) running for more than half 
a year on Windows2000 Server without interruption since the last 
update of the OS for security reasons.

Recently I had to add some message splitting:
one-message -->  [message-part-1 message-part-2 message-part-3]

I used a construct similar to this

forever [
	until [new-messages-available]
	foreach message new-messages [
		catch [
			if not important [throw]

   do-some-heavy-message-processing-and data-completion-using-odbc
			if some-tests [throw]
			message-parts: split-messages message
			until [
				catch [
					message: first message-parts
					do-more-conversions
					if other-tests [throw]
					deliver message
					emtpy? message-parts: next message-parts
				]
			]
		]
	]
]

Now I saw two crashes in one day.
I was somehow able to reproduce the crash 
Invalid data type during recycle
 

by playing again the history of one to two weeks. But the crash happened 
always processing another message.

As I had seen in the past instable behaviour with constructs like 
this
foreach ... [
	catch [
		..
		data: any [
			a
			b
			throw
		]
		..
		..
	]
]

I replaced the inner catch with statements like this
		if not other-tests [
			deliver message
		] 
and the crash went away.


Now I am curious if someone else encountered the same behaviour too?

I don't know, but if you have found instability there that would 
be a great bug report !!

playing again the history of one to two weeks

 means I process all messages of that period in the same order and 
 send them to a dummy receiver.

Of course, there is some non reproducibility regarding the time axis, 
as this takes around three to four hours compared with two weeks 
in reality and more processes running at the same time on the production 
server.

On the production server the crash happened in reality with less 
messages two times during a period of  around two hours.


The crash happens not always at the same message. This can depend 
of the time behaviour or that the data, that are retrieved from the 
ODBC source is from a live DB, with many inserts, updates and deletes.

Without ODBC the crash did not happen.

Ok, submitted a ticket for the DLL callback crash "root block overflow", 
I mentioned a few days ago. (Gabriele, sorry, first I submitted an 
empty one).

I've just noticed a new global word PATH existing since View 1.2.10, 
an undocumented function.

Is it worth a ticket ?

not sure, a reminder is never bad, though i guess Carl is aware of 
this.

Probably it's better to wait for betas closer to a full release.

I just uncovered this while working on that JumpField over in the 
View group...

>> print compress {A: #"^M"
{    switch A [
{    #"^M" [print {A}]
{    ]
{    }
#{
789C73B4525056E255E22A2ECF2C49CE50705488E602F115A20B8A32F34A14AA
1D6B63B962B900B34009D526000000
}
>> do decompress #{

{    789C73B4525056E255E22A2ECF2C49CE50705488E602F115A20B8A32F34A14AA
{    1D6B63B962B900B34009D526000000
{    }
** Syntax Error: Invalid char -- #"
** Near: (line 1) A: #"
>> print decompress #{

{    789C73B4525056E255E22A2ECF2C49CE50705488E602F115A20B8A32F34A14AA
{    1D6B63B962B900B34009D526000000
{    }
: #
switch A [
 [print {A}]
]

>>

The decompressed string was identical to the original string. The 
compression/decompression has nothing to do with it. The problem 
is in loading a string of code copied straight from an editor or 
somewhere. If that code had been MOLDed first it would have been 
OK.
>> mold #"^M"

== {#"^^M"}        ;<--------- note the double escape, this string 
loads properly.

.... mmm that may explain LF because it has an alternate representation 
#"^/", which is by default molded by rebol, but that doesn't explain 
#"^M"...  Anyway, it seems to be a bug. I vaguely remember it was 
found before.

yesp, it's not a bug as Brian says.

^M and ^J (in causing the load error) are exceptional in the alphabet 
of A  - Z.  For example:
	>> load {#"^A"}
	== #"^A"

None of the rest require double-escaping. I am trying to think of 
the reason why rebol treats the newline characters differently.

anton: that's not a suprise

>> {#"^A"}
== {#"^A"}
>> {#"^/"}
== {#"
}

the closing " is on a different line. that causes an error.

>> as-binary {#"^A"}
== #{23220122}
>> as-binary {#"^/"}
== #{23220A22}

>> form :source
== "?function?"
>> mold :source
== {func [
    "Prints the source code for a word."
    'word [word!]
][
    prin join word ": "
    if not value? word [print "u...

a number of bugs have been fixed. please check out the "Waiting for 
testing" tickets to see if you favorite bug has been fixed, so that 
you can test it and we can switch to tested. :)

Is there a way to see only the rambo entries one has made ?  I am 
"guest" and hope no body else was guest !

don't know if it's really a bug ...

if it's a bug it could be cool to patch it too ...

Carl: "On negate bug: looks like a C compiler problem. I may be able 
to fix that with an explicit check for that value, but it will slow 
down the function by a lot. Is that worth it?"

find - hmm. till 'as-string it was handy with big data. now we can 
rewrite it, but detecting that use is tricky. but its surely a surprise. 
maybe we can forbid find without /case for a while with binary? gibing 
some usefull warning.

i have a wish: integrating 'comment in some more dialects. parse, 
layout come to mind. could then be used for embedded documentation. 
what do you think?

a lot of bugs fixed: http://www.rebol.net/cgi-bin/rambo.r?sort=1&limit=2&cmd=Search&id=&pattern=&subject-only=true

3662 parse/lines second arg: how to split into lines and apply the 
rule to each line?

 a grep:   parse/lines string-with-list-of-file-names [ set file thru 
 ".r" end ( ?? file ) ]

btw, can we discuss auto-dequoting again? maybe together with /all? 
i don't like such surprises:
!>> parse {
a
b
} "^/" 
== "a" "b"

correction, result is == ["a" "b"]
my "do from editor molded /only..

#3463 : still crash with 1.2.104 - the problem is not construct/with, 
it's using an object containing a recursive block as prototype :
b: copy [] append/only b b 
an-object: make object! [a: b]
make an-object [] ; crash

like
  b: copy [] append/only b b copy/deep b

make object makes deep copies of all blocks. sure that crashes. crash 
should should be a softer?

could it be regarded a bug in interpreter parser?
>> ; test
>> ; test "aaaa
** Syntax Error: Missing " at ; test "aaaa

favourite bug - the one where an encapped application is unable to 
launch another instance after it does a system call

Particles & Bubbles demo are a true CPU eater under linux... refresh 
of the GUI desktop under linux drops very quickly when 2 times running 
Particles demo...

rebview1210242 does not kill child processes when executed like 
$ ./rebview1210242  &
[1] 9203
$ 
[1]+  Stopped                 ./rebview1210242

$ ps a
  PID TTY      STAT   TIME COMMAND

 9203 pts/2    T      0:00 ./rebview1210242
 9204 pts/2    T      0:00 ./rebview1210242
 9205 pts/2    T      0:00 ./rebview1210242

$ kill -9 9203 9204 9205

that was after doing a "fg job-id" and kill parent...

No its a new folder in View/Desktop

Romano: that should be fixed, that error came out whenever there 
was a face with size = 0x0

pekr: that happens in 1.2.1 too, and i think it's a console quirk.

With 1.2.107 (and may be others), when I launch a script from the 
desktop (clicking its icon) the new interpreter open a security request 
to read %rebol.r in the directory where the interpreter is (ie: %/c/rebol/view/).
Something wrong with 'secure setting ?

Wow. I read the call for bugs, I check my favorites to see if they 
have been fixed, I submit one to RAMBO that was half-fixed a while 
ago. Two days later, there's a new build (104) that fixes my bug 
(3685). This is the quickest bug fix I've ever experienced from REBOL 
Tech. Bravo!

With 1.2.106.3.1 and 1.2.107.3.1 : bug with pen color setting in 
draw block:
view layout [box white effect [draw [
	pen none box 10x10 70x20 ; invisible box
	pen black                                ; pen to black
	pen none box 10x30 70x50 ; invisible box
]]]
is ok,  but not
view layout [box white effect [draw [
	pen none box 10x10 70x20 ; invisible box
	pen black text 12x32 "hello" ; pen to black, some text

 pen none box 10x30 70x50 ; without AGG (->1.2.48), invisible box, 
 with AGG (alpha & 1.2.106+), visible box
]]]
Drawing something with a visible pen breaks invisible pen usage.

I wonder what font AGG use ? None of the ASCII 128+ char are displayed, 
 except 251 that show "OBJ" in a box !!

Here is a more complete test :

I believe that text rendering will not be included in View1.3 version 
of AGG/Draw. It will come a bit later.

Henrik: this shows, that time! and decimal! datatypes are a bit "incompatible". 
The time! values are able to represent 0:12:01.4 exactly, while decimal! 
is actually a binary IEEE754 floating point representation, that 
is unable to exactly represent 721.4

this is from changes documentation:
Face related warnings like 

face in more than one pane" and "invalid face" are no longer printed 
to the console. They now throw errors and you can catch them or let 
them go to the console. The warning that a face is shown in non-visible 
pane or closed window type errors have been removed. Programmers 
can determine that for themselves."

#3687 : bitwise ops - it was submitted at the start of the /View 
1.3 project (2003/2004). 

Both MacOS 9 and Amiga /View 12.1 (big-endian MC 680xx / PowerPC) 
have this bug for bitwise operations on series.

I had to do a workaround for %gzip.r (painful slow byte per byte 
operations) and %rebzip.r (calculations with integers.)

maxim: it isn't just AA. font support is not multiplatform right 
now so it can't be left in. i'm sure we'll find a solution to this...

I wrote a simple one that is available through rebol.org.

I'm about to release a new version of the printer lib with multiplatform 
support, so if anyone noticed something to fix or improve that I'm 
not aware of, that's the right time to report ;-).

I hoped to have time Doc, but I don't have a need, and I seem to 
have *no* spare time for playing right now. :-(

I've been pretty flat out as well, but will have a ook at it today. 
 Thanks for the work.

So, this implementation is as a page description language?

Nope, that's too high-level, it's not a feature of Draw dialect. 
The printer scheme provides a cross-platform low-level layer to build 
such higher-level frameworks.

Making text flow from one page to another is a job for a word-processor 
like MSWord or LaTeX. The printer scheme aims to be general purpose, 
so it can be used to print anything (not only output from word-processors).

Text can only flow inside boxes fully contained inside a page. This 
is achieved by extending Draw dialect with a new primitive : 'text-box.

What I am doing now is printing the text to a virtual draw page, 
and then when it reaches the bottom of the text box, it then flows 
to the next text box.

if the next text box is above the current text box, it assumes a 
page break and so starts a new page.

What I tried to do was create a print template that the user can 
define.

The underlying GDI API I've used does a lot more than needed, I should 
restrict its behaviour.

This is the "dialect" I am using to generate a multi-page letter. 
 Words like "consult-date" "provider" "My-name" are processed by 
a pre-processor to substitute the correct variables.

flowbox 75x150 540x590 float 20  


means to put a text box that accepts text that flows into another 
box, but to start the text inside the box 20 points below any text 
above it.

the same dialect gets converted to draw to allow a preview.

So, you have a draw converter for this dialect ?

gonzo is a postscript utility to do micro justification and other 
goodies

ok, so it's 100% PS. I wrote a few helping functions in PS too.

For eps, I just put a yellow box in the print preview ....

Thanks for the food for thought, I think that I could reuse several 
routines from gonzo. But PS is just a low-level layer for my printer 
dialect, doing too sophisticated things at PS level is not an option 
for me. All the calculation and fancy things (like good justification) 
have to be done in Draw dialect, so that WYSIWYG can be achieved.

I have multipage preview working ... some time ... I have a block 
of draw blocks and I am supposed to switch between them to page thru 
the different pages.

Is it an issue with View/Draw or a bug in your code ?

Nah, not really. It's been printed typically on a separate page after 
the actual print.

Or that is more used for text under an image in a book?

summary
 is a good word, thanks!