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

Benjamin
16-Aug-2005
[1039]
write-net ? i need my callback on writing operations too ! just like 
read can i've this cookie ?
Volker
17-Aug-2005
[1040]
The only callbacks i know are by using async. Gabriele and Romano 
have protocolls to do that.
Pekr
17-Aug-2005
[1041]
all 'read based functions are weak - they are not async ...
Volker
18-Aug-2005
[1042]
using link and 1.3 on linux, workaround: export HOME=/home/volker/ios 
. solves the .rebol-nameclash and works.
Ladislav
19-Aug-2005
[1043x14]
I found one GC problem:
g: does [o/f: does [recycle print "o/f"] o/f]
o: make object! [f: does [g print mold disarm try [1 / 0]]]
now doing:

    o/f

reliably crashes the interpreter
posted under name: "GC Crash - Object&Function"
simplification:
o: make object! [f: does [g print "version 1"]]
g: does [o/f: does [print "version 2"] recycle]
o/f
this looks like being enough too:
f: does [g print "version 1"]
g: does [f: does [print "version 2"] recycle]
f
or shorter:
f: does [g print "version 1"]
g: does [unset 'f recycle]
f
the crash observed in Linux View 1.3 too
...and under OpenBSD
the problem can be "circumvented" as follows:
f: does [g print "version 1"]
g: does [unset 'f recycle]

doer: func [f [function!]] [f]
doer :f
Anton
19-Aug-2005
[1057]
Nice work Ladislav.
Volker
19-Aug-2005
[1058]
Cool reduced. I have that bug sometimes when redoing scriptsbut never 
nailed it really. Never thought to use recyle. my workaround:  f: 
func[][dont-gc-me: :f reload-me]
JaimeVargas
19-Aug-2005
[1059x2]
There is a problem with the issue! type. It doesn't accept the slash 
character as the example in the rebol core manual says.
>> value: #MG82/32-7
== /32-7
>> probe value
#MG82
== #MG82 ;; It droped the 32-7 part.
Ladislav
20-Aug-2005
[1061]
regarding the above GC crash (and to Volker): I think, that the best 
workaround is

    do :f

instead of just 

    f
Volker
20-Aug-2005
[1062x3]
Eeks. should this happen?
  echo -e "these are\nsome words" | rebol -q scratch.r
the script contains an error, an undefined word bang
** Script Error: bang has no value
** Near: bang
** Script Error: these has no value
** Near: these are
** Script Error: some has no value
** Near: some words
input is executed. its clear, there is an error, so go to console 
for input. but this time the console is data. maybe with pipes that 
should be changed?
workaround is: run as cgi, rebol -qc . but this is easy to overlook.
Anton
22-Aug-2005
[1065x2]
if you look in svv/vid-feel, you can see many of the 
OVER functions have arguments like:

	over: func [face action event] ...

but according to old feel doc, they should better be:

	over: func [face action position]

or according to new view system doc:

	over: func [face into position]


This is to avoid misleading error messages such as:   ** Script Error: 
over is missing its event argument
Should I post a report ?
Ashley
22-Aug-2005
[1067]
Yes please. These may not be "errors" in and of themselves, but such 
inconsistencies have a ripple effect as you've identified that make 
REBOL harder to use / understand (especially when compounded with 
other inconsistencies). BTW, the other inconsistency I've noted in 
the past in this area is the use of "face action" versus "face act" 
versus "f a" in some places. It would be nice (if not already so) 
if this was sorted out.
Anton
24-Aug-2005
[1068]
Ok, posted it. But on consideration of the issue of abbreviated argument 
names, I don't feel strongly enough that it's so bad. In some cases 
it looks justified to abbreviate FACE to F, like when there are a 
gazillion references to the face. In some cases, the arguments are 
only used once each so there's not much advantage in abbreviating 
them (but they are anyway).
Ingo
24-Aug-2005
[1069]
It depends ... if you know enough about Rebol, then "over is missing 
its 'p argument" may be enough. 

On the other hand, if you are just starting, then 'position may help 
you more ...
Volker
25-Aug-2005
[1070x2]
on linux:
!>load probe mold load "1e-50"
1E-50.0
** Syntax Error: Invalid decimal -- 1E-50.0
** Near: (line 1) 1E-50.0
makes problems with prebol and friends
Sunanda
25-Aug-2005
[1072]
Doesn't do that on windows -- so definitely a cross-platform problem.
Volker
25-Aug-2005
[1073]
posted it to rambo
JaimeVargas
25-Aug-2005
[1074x2]
;Rebol is gong into limbo with this code. I don't think it should 
happen.
parse {my infinte parse loop} [any [string!]]
The interpreter stops respondin and start consuming a lot of cpu 
cycles.
BrianW
25-Aug-2005
[1076x2]
Don't know about regular apps, but in the console I can interrupt 
that with the Escape key (as of 1.3)
whoa - doesn't let go of the memory, though. I ended up getting a 
Virtual Memory warning from Windows after doing that a few times. 
Memory consumption went down as soon as I quit the Rebol console.
Thorsten
27-Aug-2005
[1078]
Is there any knowledge when the Problem with open/direct will be 
fixed or what prio this has at RT? I already asked in the Mailinglist 
but got no answer. There was only mentioned that in one Beta it might 
be fixed.  The thing that i always don't understand with Software 
vendors of all kinds is that they always focus more on new features 
than on stability and perfectly working already built in features
Gregg
27-Aug-2005
[1079]
RT is re-prioritizing things as they go, because the community will 
get excited about certain things, so it's good go consider putting 
a little time in on those. Other tasks have larger implications and 
take a lot of time to design and code. The /direct issue is a good 
example because they don't want to break file handling code (which 
is used in *many* scripts), nor do they want to just dump in a quick 
change and make matters worse in the long run.
Volker
27-Aug-2005
[1080]
What about a new refinement /stream and keeping /direct for backward-compatibility? 
And the old protocols are source, one could add an option to enable 
them. Would then be a small change to get scripts running again, 
until the bigger one of some rewriting is done.
Thorsten
28-Aug-2005
[1081]
So, understanding you correctly , there was a time when open/direct 
worked?  I need this to get access to large files without the system 
trying to load it completely into memory/buffering it. Without this 
option there is no way for me to use REBOL for my problem. I don't 
understand where the compatibility problem should be. Open/direct 
is defined to get non buffered access to ports. Was this different 
in the past?  As you say there are scritps where this feature is 
used, so there must be a version where this worked or was it used 
with the wrong behaviour ?. If so, i understand why there is a discussion 
to change the behaviour. But then the definition of open/direct should 
be changed and a new refinement be implemented which gives you the 
possibility to take advantage of non buffered port access. 


I know the community needs new features, not only for marketing purposes, 
but often enough i really don't understand how a priority is set. 
I know, it is not my business to decide such things. I am only a 
person interested in REBOLS future.
Anton
28-Aug-2005
[1082]
Thorsten, I just quickly tested with

 port: open/direct/skip %user.r 3 probe copy/part port 20 close port

and found View beta versions 1.2.54.3.1 thru to 1.2.57.3.1e  do the 
skip correctly. Those versions are the ones with the async core, 
which was found not to be quite stable enough, and it was removed 
for the next beta version, View 1.2.100.3.1
Thorsten
28-Aug-2005
[1083]
I was just amazed the open/direct didn' t return anything in View 
1.3.1 not even an error. Thanks to this hint. I Think i try one of 
these to keep up development, hoping there will be a fix or new solution 
in one of next releases. Perhaps it will be in the near future ;-)
Anton
28-Aug-2005
[1084x2]
I hope so too. It's a good bet it will work the same way in future 
versions, when it will be added again.
I would try to get 1.2.57.3.1e, it being the last in that set of 
versions.
Gabriele
28-Aug-2005
[1086x2]
the alpha also has /seek.
also, it's not that /direct does not work; it does, always has, in 
that it does not buffer. the problem is that it does not allow seeking, 
i.e. it only allows sequential access. so you can open a 2GB file, 
as long as you read it sequentially.
Thorsten
28-Aug-2005
[1088]
Where does the 2GB limitationcomes from??