r3wp [groups: 83 posts: 189283]
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r3wp

[RAMBO] The REBOL bug and enhancement database

Anton
18-May-2005
[567x2]
Romano, I am seeing some weird face bugs, too, using View 1.2.107
Maxim: "why can't AA fonts be supported on Linux ? they're supported 
on windows..."  ;-)
sqlab
18-May-2005
[569]
[Cyphre | Gabriele]: Do you still need more information about the 
Win98 crash or is it solved?

If needed I can send an echoed trace log file to your email address.
DideC
18-May-2005
[570]
Here is what I get with 1.2.48 (standard draw) and 1.2.107 (AGG draw) 
:
http://membres.lycos.fr/didec/images/draw-text-48.jpg
http://membres.lycos.fr/didec/images/draw-text-107.jpg

I have tested on Win2k and WinXP with French Regional settings : 
"French (France)" with "French (France)" keyboard layout.

I don't know the exact code page, 1252 or 850 ? Where can I get it 
?
Cyphre
18-May-2005
[571x4]
sqlab: the Win98 bug has been fixed for next release. Thanks for 
your useful bugreport!
Vincent, DideC: thanks for the report. I'll try to investigate more. 
But remember the current font handling in Rebol/AGG will be removed 
 for the 1.3 version. (AA and vectorial fonts will be added once 
we found good crossplatform solution for it)
Romano, Anton: the new error!s were introduced to rebol instead of 
"face in more than one pane" and simmilar console prints.
regarding this error
** Script Error: Invalid graphics face object
** Where: view
** Near: show scr-face
if new [do-events]


I have got it when one of face/size coordinates are lesser than 1.
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."
Vincent
18-May-2005
[575]
#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.)
Gabriele
18-May-2005
[576]
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...
Ammon
18-May-2005
[577]
One could build a function that catches "face in more than one pane" 
errors that duplicates the face and ties the data values of the faces 
together so that they act like one face but are in fact two faces 
with identical values and therefor allows view to display the face 
in more than one pane...
shadwolf
18-May-2005
[578x4]
I noticed a crash with rebol 1.2.107.3.1 on win2k with the script 
logo.r (tet program for AGG)  when I resize the windows ...
the script is http://www.rebol.net/tests/view/logo-maker.r
the crash message is :
** Script Error: Invalid graphics face object
** Where: evt-func
** Near: show out
>>
Gabriele
18-May-2005
[582]
btw, i have a question: is there anyone using smtp:// directly?
shadwolf
18-May-2005
[583x2]
maybe graham with rebmail ?
but i think is using the core VM not the view one
Romano
18-May-2005
[585]
the new error!s were introduced to rebol instead of 

face in more than one pane" and simmilar console prints".the problem 
is that previous versions did not print any messages in the console 
with the same code.
Vincent
18-May-2005
[586]
special category of time (only one known value): negative negative 
time
>> time: to-time 2 ** 31
== --596523:-14:-08
>> time = - time
== true
>> time + 1
== -596523:14:07
>> time - 1
== 596523:14:07
Ammon
18-May-2005
[587]
Oops, should have actually read the conversation before commenting, 
huh?
Gabriele
18-May-2005
[588]
romano: indeed, that was a bug, and should be fixed. (though, zero-size 
faces are debatable. vid uses them for sensors, so for compatibility 
that must work, however it doesn't seem such a great idea to me.)
Anton
19-May-2005
[589x2]
Some bug reports now contain the umbrella phrase "fixed in View 1.3". 
  I would prefer to know the exact version, so I know which version 
to test the bug against, and whether I have that version yet or not.
Can we find out who is doing that ?
shadwolf
19-May-2005
[591]
Anton try changes? in the lastest consol ... not very detailled I 
know ...
Gabriele
19-May-2005
[592x3]
anton: if a response does not have "-Gabriele" in it you can assume 
it was written by Carl :)
about #3016: does it still apply? (PARSE and recursion limits have 
been changed much lately) could anyone provide me with an email that 
breaks the parser?
#3402: does it still apply? i think it was fixed already. any example 
where it breaks?
Anton
19-May-2005
[595x2]
:)    #3437 is "Built", but on View 1.2.107 it still does not return 
an error.   func [a 'a :a][]
oh.. built today, I guess I have to wait for next release :)
Romano
19-May-2005
[597]
Gabriele that was not a bug, only the new version it is not backward 
compatible.
DideC
19-May-2005
[598x12]
I have an undebugable bug !! It hapen with 1.2.104 and more, in a 
script that use Uniserve.
Here is the code that throw the error :
init-connection: func [
		new /service server 
		/local proto evt list len names i fun
	][
		new/locals: context [
			handler: any [
				all [service server/server-type]
				proto: select protocols new/locals/1
			]
			write-queue: copy []
			file-chunk: 64 * 1024
			stop: handler/stop-at
			in-buffer: make binary! 64 * 1024
			file: flag-close: events: none
		]
		if proto [
			evt: reduce new/user-data
			help new/locals
			list: array len: length? names: new/locals/handler/events
			i: 1
			until [
				if fun: select evt pick names i [poke list i :fun]
				len < i: i + 1
			]
			new/locals/events: list
		]
		actives/add new
	]
I have added an 'help  in the code to help locate the error (2 lines 
under "if proto [" )
When it works you get :
NEW/LOCALS is an object of value:

   handler         object!   [name port-id hidden peer stop-at shared 
   module ev...
   write-queue     block!    length: 0
   file-chunk      integer!  65536
   stop            none!     none
   in-buffer       binary!   #{}
   file            none!     none
   flag-close      none!     none
   events          none!     none
When it crash I have :
NEW/LOCALS is an object of value:
   write-queue     block!    length: 0
   file-chunk      integer!  65536
   stop            char!     #"^/"
   in-buffer       binary!   #{}
   file            none!     none
   flag-close      none!     none
   events          none!     none

** Script Error: Invalid path value: handler
** Where: init-connection
** Near: list: array len: length? names:
The problem is simple : new/locals is set at the beginning of the 
function and it's content has changed 3 lines later !!
It's 100% reproducable, but with precise conditions. It's called 
by a timer (manually, I haven't get any error).

With a timer of 2 mins, it happens the second time. With different 
time it does not happen, or I haven't wait enough (but did not make 
to much test on that)..
I don't know how I can post that to Rambo !
Sorry to flood this group.
Gabriele
19-May-2005
[610]
could it be that reduce user-data is changing something?
Carl
19-May-2005
[611x2]
Yes, please confirm user-data is not doing anything.  Then, add an 
empty word/value at top of locals object.  Does that same cell get 
deleted?
What makes this bug very unusual is that the rest of the object seems 
to be ok. It is as if something deleted the word from the object 
(but that is never done in REBOL).
Brett
19-May-2005
[613x4]
Gabriele: #3402 is an outstanding bug when using /CUSTOM refinement. 
 An example is submitting a  form over http using REBOL. You need 
to specify both HEADER and POST. For example:

   read/custom url [HEADER [Content-Type: {multipart/form-data; boundary=---xyz} 
   ] POST {blah}]

The problem is that the handling of POST *overwrites* the Content-Type 
and Referer even though they may have been specified in HEADER. This 
logic bug is within the create-request function of Open in HTTP scheme.
Gabriele: #3016 still applies but is less likely to occur with the 
increased limits.  On View 1.2.46.3.1 my test failed after 100 To 
addresses, now on 1.2.107.3.1 my test fails after 256 To addresses. 
My test is next:
test-address-import: func [

 {Returns true if pass, false if discrepency and none if failed with 
 error.}
	limit [integer!] "Number of TO address to generate."
	/quiet "Does not display error."
	/local to-list eml sep msg obj
] [
	to-list: copy {} sep: ""
	repeat i limit [
		eml: to-email join "test-" [i "@test.com"]
		repend to-list [sep {"'} eml {'" <} eml {>}]
		if empty? sep [sep: {,^/	}]
	]

	msg: replace copy {Date: Thu, 12 Feb 2004 11:41:49 +0100
From: test <[test-:-test-:-com]>
MIME-Version: 1.0
To: TO_LIST
Subject: [REBOL] test message - edited copy of real message
Content-type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 8bit
Sender: [rebol-bounce-:-rebol-:-com]
Reply-to: [testing-:-testing-:-com]
Status:   


Test message.
} {TO_LIST} to-list

	either error? set/any 'result try [
		obj: import-email msg
		limit = length? obj/to
	][if not quiet [print mold disarm result] none][result]

]
This test generates a test email with the desired number of addresses 
then attempt to import it.