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

Gregg
28-May-2005
[701]
Might as well submit it.
Anton
30-May-2005
[702x10]
Ammon, rebol sound system needs overhaul anyway. But rebol implements 
sound/volume by just setting the host os system volume. A bit naughty, 
perhaps.
sound/volume: 1.0  ;  is full volume
Gabriele #-258,  it doesn't look like it crashes View 1.2.114.3.1, 
even after more than 10 times engaging/disengaging the internet lock, 
just lots of rapid read errors, as you might expect.
Mmm.. I couldn't reproduce the bug on View 1.2.102.3.1, which is 
supposed to be the version just before the read/lines bug was fixed. 
I'll try an older one...
no crash on 1.2.100.3.1 either...
no crash 1.2.48.3.1
no crash 1.2.20.3.1
no crash 1.2.1.3.1   ; eh ?!  I can't reproduce this bug...
I'm also on WinXP.
I think I have a null-result, because I can't reproduce the bug even 
on View 1.2.1
and Giueseppe also previously posted this bug ~15 months ago, which 
is well after View 1.2.1 was released.  Hmm. Maybe there was a buggy 
set of betas that I skipped over...
I want more information from GIuseppe - what version of View did 
he test with ?
Gabriele
30-May-2005
[712]
he told me 1.2.114 doesn't give him the problem. he had that problem 
with 1.2.1.
Vincent
31-May-2005
[713]
#3737 (call and file! datatype) : same problem on Win2k. The error 
message is right, it's a path problem - but if it works with string!, 
it should work with file!. A workaround :
call clean-path %prog.exe
Gabriele
1-Jun-2005
[714]
it has been fixed. btw, the error actually came from to-local-file, 
i think.
Henrik
2-Jun-2005
[715]
>> layout [b: field hide]
>> set-face b "123"
>> get-face b
== "123"
>> view layout [b: field hide]
(enter "123" in the field, tab away and close window)
>> get-face b
== "***"

Is this intentional?
eFishAnt
2-Jun-2005
[716]
#3733 fixed...tested by me.  Thanks.
Ammon
2-Jun-2005
[717x2]
Cal found a fun little bug with Select/Skip when using it on a string. 
 Here's the shortest code snippet that we've come up with to reproduce 
the problem.  Only copy and paste this into a console session that 
you don't mind killing cause it is going to lock up...  Tested on 
Win2K with the latest stable release, Command and recent betas...

select/skip {"<a><mm></mmmmf>"} "foo" 2
We have been playing with changing the length of the string, the 
characters in the string, etc and haven't really been able to find 
any reason to this rhyme, perhaps some of you bug hunters could help 
us track down the actual cause of the lock up?  In the mean time, 
we'll keep playing with it as our schedules permit...
Volker
2-Jun-2005
[719]
hangs here. first guess is, /skip steps behing the array, and that 
is not checkt. the it starts looking through hole memory. length 
of string is odd, step 2. maybe rebol tests "index = length" instead 
of "index <=  length".
Anton
2-Jun-2005
[720x2]
I think it is related to a bug in FIND:
find/skip "abcdefghij" "azzzz" 5 ; locks up
find/skip "abcdefghij" "abczz" 5 ; locks up
find/skip "abcdefghij" "abcde" 5 ; == "abcdefghij"  OK
find/skip "abcdefghijkl" "zzzzz" 5 ; == none  OK
There are a couple of /skip bugs in RAMBO already... Search for "find/skip".
shadwolf
3-Jun-2005
[722x8]
For norman new submition bug about error (unrecognised symbol ) when 
loading libraries .so files I have maybe the solution or explanation 
to this problem.... When you look to the error message on loading 
libraries submitted by norman in his post we can see that the problem 
is related to external needed library for example libSDL, libncurse, 
libogg  do not need other libs But  GTK and gthread need previous 
load of glib, libgdk, libpango, libgmodule, libpng, libint, libgtrhread 
and the list is long ;)...
So before to start to will load htose things you need to know what 
is the library dependencies. On linux you can see the MAKEFILE file 
related to one of the tutorial program integred to the GTK  package 
for example and see the -l*.a entries to have a complete idea of 
the library needed and the order of library dependencies
I'm agree with the idea that loading complicated heavy splitted and 
many dependent library libs GTK  popup up that we have to seek a 
better library loading system. Dependencies of libraries is a very 
weak point. Think of it ... First you have to load the librariries 
in the dependence chain in the right order and make a rebol script 
file to be able to treat in rebol script code the calls of function 
of those libraries (for example GTK sofware unsed commonly lots of 
function that are builded into many different librairies in the dependencie 
chain (like g_malloc() instead of malloc(), gint type instead  int 
type, gchar type intead of char, g_thread**() instead of  thread**() 
etc...)
I make a discussion group on this world called DLL.SO to collect 
all the ideas and organise a working group around the loading library 
topic
the point is that making bridge  betwen rebol script and librari 
in the way it is actually done is good for tiny simple library but 
very a tremendous work when it touch to heavy complicated library 
that intent to abstract from the os consept and give the same way 
to code on any OS/material. Mostly Opengl and GTK for example. Both 
libraries are heavy (lot of libs lot of struct lot of types lot of 
dependencies that needs a bridge too). For OPENGL you have two way 
to work or you make a OS based I/O and windowing system example gdi32.dll 
user32.dll for windows or xlib.so for Linux and  then exploite gl* 
function that are stored in the openGL.so/dll  or you use the related 
to opengl portable set of libraries to handle window drawing and 
Mouse/Keyboard events glut.dll/so. The fact that a librarie portable 
must be a library the abstract from the OS dependencies make them 
very complicated to handle. AS we don't have the same coding effort 
on library bridge coding than other language because many reasons 
in witch the fact that library loading is a Pro functionnality and 
maybe too because the system is not enought developped. It's easier 
to make a library bridge for a language when this language allows 
type creation and have based type in this language that feets with 
the one in C/C++
making library bridges is a very complicated thing for rebol coders...
If this fonctionnality remains payant we at most need to rethink 
internally the way to work or build an intermediate library loading 
system script that allows people to load the library without the 
needs of wrtiting by their howns the bridge or a tools that take 
a makefile of a sample program and the include file and generate 
a rebol script bridge for any library that must be loaded to use 
the wanted libraries thos bridges script files must then be supplyed 
as the libraries and the program script in rebol that exploit those 
libraries
A sutch tool will makes easier the verson change in library handling
Sunanda
3-Jun-2005
[730]
Max was working on a generic Library loader..
But the project appears to be abandoned.
Last known URL is 404ing: www.rebol.it/~steel/libraries/
sqlab
3-Jun-2005
[731x2]
I found a very critical bug in the old and the new rebols
write/append does not give back an error when writing to a disk without 
enough space

just do this

insert/dup mem-st: make string! 100'000 "1" 100'000
counter: 0
forever [
    write/append %/A/mem-tst mem-st
    probe counter: counter + 1
]

then you will see that it runs without writing
Gabriele
3-Jun-2005
[733x2]
sqlab: please add to rambo
also, please add the find/skip bug to rambo as critical. thanks.
sqlab
3-Jun-2005
[735]
I did add the write/append problem.

This just caused me some big problems, as I had 
some Rebol programs running     
since Sept. 24 2004 without interruption 
on a Win2000 server .(
JaimeVargas
3-Jun-2005
[736]
I am not sure it is the reponsibility of write to check if there 
is available space, but it maybe nice to have it. This usually falls 
on the domain of the OS.
BrianH
3-Jun-2005
[737]
But OSes often signal the program of such an error after they detect 
it. Do the REBOL internals react to such a signal?
Graham
3-Jun-2005
[738]
IOS messenger used to happily write 0 byte length messages when it 
ran out of disk space, which crashed messenger when it tried to read 
them.
sqlab
5-Jun-2005
[739x2]
BrianH: Yes, I do not expect write to check for available disk space. 
But I expect an error, if an action is not successful. And this I 
do check and react according to the outcome.
Graham: That's similar to what happend to me.

The receiving process did not write data anymore, but informed some 
consecutive processes, that new data had arrived. And as he did not 
notice about the failures, he went on signalling, that he will accept 
new data.
These data were lost.(
shadwolf
6-Jun-2005
[741x2]
For rambo viewing I have one killer model ;) named Flyspray it's 
the best visual I ever see :) It could be fun to adapt Rambo to clone 
this visual ;)
http://bugs.splitbrain.org/index.php?project=1
Allen
6-Jun-2005
[743x2]
shadwolf. The bug tracker / "shared development tracker" plugin for 
Altme is pretty good.
Assuming you remember it from ealier betas, or have access to worlds 
where it is used.
Henrik
6-Jun-2005
[745]
I liked that bug tracker, why was it removed?
Ammon
6-Jun-2005
[746]
From what I can determine the bug where select/skip on a string locks 
up the interpreter is related to bug #3327  My guess is that because 
/skip isn't skipping properly then it sometimes finds itself in a 
forever loop trying skip at the same point repeatedly.  Shall I submit 
this as a new bug references the expected relationship between these 
two or do we want to extend the description of #3327 to include this 
information as well?
Vincent
6-Jun-2005
[747]
#3755 : not a bug - it's just a syntax problem: "file: read %//server/share/file" 
doesn't work but "file: read %/server/share/file" does. {to-local-file 
%/server/share} and {to-rebol-file "\\server\share"} gives the expected 
results.
Gabriele
6-Jun-2005
[748]
Ammon: i'd say submit a new one, and write that it may be related 
to 3327.
Ammon
6-Jun-2005
[749]
Kewl, will do.
shadwolf
6-Jun-2005
[750]
Allen no I don't see any thing like that in ALTME ..