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

Izkata
2-Jul-2005
[871]
oh.. sorry then  =^\


then I guess it was 'to that was changed?  Well either way it doesn't 
matter, at least now I know lol
Sunanda
3-Jul-2005
[872]
to-time {hi} has returned 'none at least as far back as 1.2.1.
Maybe that is a bug :-)
Gabriele
3-Jul-2005
[873]
#3832: why? it's normal that SIGINT interrupts apps.
Ladislav
3-Jul-2005
[874x2]
it looks to me, that the initial-vector is not taken into account 
by the encryption ports?
nevermind, problem solved
Anton
4-Jul-2005
[876]
TO-TIME with rubbish input, already reported, see -> http://www.rebol.net/cgi-bin/rambo.r?id=3643&
Izkata
4-Jul-2005
[877]
Yeah, thanks... I was confused because I was certain I had gotten 
if error? try [to-time Whatever][..] to work before
Gabriele
4-Jul-2005
[878]
maybe you used to-date
DideC
4-Jul-2005
[879]
I don't find in RAMBO the bug about View crash when you change screen 
resolution (almost under XP) !
Is it already there or not ?
Graham
4-Jul-2005
[880]
Perhaps it is fixed?  I submitted it in Feb 2004

http://www.rebol.net/cgi-bin/rambo.r?id=3382&
DideC
4-Jul-2005
[881]
Ah ok. Thanks
Oldes
6-Jul-2005
[882]
my most hated bug in Rebol: Invalid data type during recycle
sqlab
7-Jul-2005
[883x3]
Regarding Carl's last blog, I guess rebcmd25125 is the pre-release 
version.
I am testing the Win version with my scripts since a few days.
Recently I saw  some error messages I saw never before.


The script is reading periodically from a remote drive via UNC with 
	load join work.dir [isodate work-date ".log"]
where 
	work.dir:  %/REMOTE/D$/DATA/
and 
	isodate: func [x] [..]  
producing something like "20050705".

Before I saw error messages like 
	Access Error: Cannot open /REMOTE/D$/DATA/20050705.log
	Where ...
	Near: load join work.dir [isodate work-date ".log"] 
 , if the file was not accessible.


This time the error messages were different after running for some 
time ,  e.g.
	Near: load join work.dir [ isodate 5-Jul-2005 ".log"]
or 
	Near: load join wor[isodate work-date ".log"] 

Has anyone seen something simlar ?
Forget the message above.
I guess I can it explain, as probably two instances of my script 
where running at the same time and writing to the same log file and 
thereby overwriting their mesages.
Henrik
10-Jul-2005
[886]
I found a rather peculiar bug in rebol/core for OSX under Tiger:
start rebol/core and type:

>> launch "test"
(new process starts)
>> quit
** Script Error: pitqi has no value
** Near: pitqi
>> quit
** Script Error: pitqi has no value
** Near: pitqi
>> quit
** Script Error: utqi has no value
** Near: utqi

Any command is mangled semi-randomly. Can anyone confirm?
Volker
10-Jul-2005
[887]
thats typical for rebol under linux, and os/x is a unix. two processes 
want to read from the same console and get it alternating. may be 
more of an unix-issue. (but i did never see "pitqi")
Ashley
10-Jul-2005
[888]
Any reason why help no longer works with objects?

	>> system/version
	== 1.3.1.3.1
	>> help system
	SYSTEM is an object of value: >>

compared to:

	>> system/version
	== 1.2.10.3.1
	>> help system
	SYSTEM is an object of value:
		version         tuple!    1.2.10.3.1
		build           date!     30-May-2003/0:59:35-7:00
		product         word!     View
		...
Anton
10-Jul-2005
[889x2]
I don't see that Ashley. It still works for me. I think you blew 
away dump-obj or something like that.
Gabriele, can you add an extra bit to the details here http://www.rebol.net/cgi-bin/rambo.r?id=3837&

A reason for wanting this is to be able to generate an image of what 
the style looks like without opening a window, eg. for documentation.

(It's good to see what the original reasons are for each bug report. 
Should make fixing them more satisfying too.)
Henrik
10-Jul-2005
[891x2]
volker, well I didn't get any trouble under Linux with GNUstep's 
Terminal.app so it may be a terminal issue
If I ssh to a linux box from the terminal where I saw the problem 
originally, there is no problem either
Anton
13-Jul-2005
[893x2]
Gabriele, I have some additional information for a ticket:
http://www.rebol.net/cgi-bin/rambo.r?id=3314&


Memory usage climbs, but there is no longer any crash on View 1.3.1

i: 0 until [
	attempt [
		view layout [
		button feel [
		redraw: func [face action pos][
		;if action = 'draw [show face] ; memory use climbs very high
		if action = 'show [show face]  ; memory use looks quite stable
		]
		]
		]
	]
	1000 <= i: i + 1
]
unview
Gabriele
13-Jul-2005
[895]
hmm, need to check all tickets with undetermined importance. otherwise 
they get overlooked.
Anton
14-Jul-2005
[896]
view/new win: layout [] win/changes: reduce [:+] show win  ; crash
Henrik
14-Jul-2005
[897]
anton: confirmed
Anton
14-Jul-2005
[898x3]
Thanks Henrik. You can also try putting different functions, natives, 
ops, in there for the same result. (I haven't tried them all, though.)
none does not cause a crash, though.
I have searched for "changes" in rambo and I did not find a similar 
ticket.
Gabriele
14-Jul-2005
[901]
add it :)
Anton
14-Jul-2005
[902]
OK done. :)
Ladislav
17-Jul-2005
[903x2]
Hi, #3545 is marked as High importance. Actually, it is underestimated, 
because such problems are critical even for pre-alpha Rebol programs 
e.g. when trying to send keep-alive type messages to a port using 
Romano's ATCP scheme. I  wonder what is an optimal work-around for 
the current (Core 2.6 - based) scripts? (see #3465 too, marked - 
underestimatedly - as Medium importance) .
(I know, that we can use Timers for View scripts, but that does not 
solve the Core case)
Gabriele
18-Jul-2005
[905x3]
timeouts are a problem for normal (non-async) core, but should work 
fine on async core.
the "solution" (a trick, with its own problems...) i use for the 
detective is http://www.colellachiara.com/soft/Libs/timers.r
anyway - this is something we *need* for /services... so i guess 
there will be a real solution very soon.
sqlab
18-Jul-2005
[908]
just a few weeks ago I wrote that with the new rebcmd for Win my 
problems with odbc and catch were gone.

Now I encountered a "Crash, should not happen" with a script doing 
not more than receiving data from tcp sockets, parsing the data, 
writing to files and sending a response back.

Some almost identical scripts were working with the old cmd for months 
without interruption.
JaimeVargas
18-Jul-2005
[909]
Can you isolate the problem?
sqlab
18-Jul-2005
[910]
I will try, but I am not very optimistic
sqlab
20-Jul-2005
[911]
It's reproducible
Crash (should not happen) invalid string width 16: type 41
sqlab
21-Jul-2005
[912]
Now I get the crash every second day
JaimeVargas
21-Jul-2005
[913]
Isolation is key to fix the problem. If you can't isolated it, please 
post the full script.
sqlab
21-Jul-2005
[914x3]
I can see where the crash happens.

It happens in or just before an awake function, when the peer closes 
the socket.


On_Data: func [port] [action-time: now con: port msg: copy: copy 
port 
	if any [none? msg empty? msg] [print ... 

and the print is not evaluated.
The script alone will probably not help you, as you will need the 
data too.
Maybe there is data also coming from a second port, as I have sometimes 
seen a crosstalk of events, if there is heavy traffic on the pc.
Gabriele
21-Jul-2005
[917]
does it have a GUI too?
sqlab
21-Jul-2005
[918]
no, just a plain console application accepting tcp socket connections 
and data
Gabriele
21-Jul-2005
[919]
is it doing anything woth noting during the awake? creating objects, 
or something like that?
sqlab
22-Jul-2005
[920]
When accepting a new connection, a new object is created.

After accepting new data there is mainly parsing, block and string 
creating, writing to the console and to files and sending a reply 
back