World: r3wp

RAMBO Ticket #-257

Yes the system allocates a negative number when you first submit 
a ticket. It seems to get allocated a positive number when it is 
viewed by a human.

#3716: The problem still seems to exist in more unusual cases :

REBOL/View 1.2.114.3.1 26-May-2005 Core 2.6.1
parse "string with 2 semi-colons ;; " none
== ["string" "with" "2" "semi-colons" ""]
>> parse "string with 2 commas ,, " none
== ["string" "with" "2" "commas" ""]

and the very extreme :

>> print mold parse "this string includes more ,,,,,,,,,,, semi-white 
spaces ;;;;;;;;
; " none

["this" "string" "includes" "more" "" "" "" "" "" "" "" "" "" "" 
"semi-white" "spaces
 
 
 
 
 
 
 
 
]

Should I re-submit to RAMBO?

thanks for the draw command list - (time to experiment and crash-test 
draw/agg :-)

anyone can confirm -258? http://www.rebol.net/cgi-bin/rambo.r?id=-258&

I do not know, if this is comparable.

If I work with ODBC, pull out the network connector  and catch the 
error with try [], sooner or later I can observe a consecutive fault 
 either at a different part of the program doing something totally 
unconnected with  that  or a GC fault.
Either way the process is no longer able to work as expected.


In server processes I help myself in this case with automatic closing 
and starting a new instance of the program.

but, is it possible to confirm that on 1.2.114?

if the crash noted on -258 only happens on 1.2.1 then it's probably 
already fixed (a bug with read/lines was fixed), and the ticket should 
be dismissed.

Gabriele re http://www.rebol.net/cgi-bin/rambo.r?id=-258&, perhaps 
can you contact  Giuseppe Chillemi by email to retest with 1.2.114 
.. (looks like he hasn't logged into altme since last december)

Peter - I think, submit again for the new cases, since the original 
cases in the bug are fixed. but mention the original ticket number 
in the new post.

Most annoying bug:  When REBOL accesses the sound the port it drops 
the Wave Volume down to 25% of the volume on Windows 2k

please delete --> RAMBO Ticket #-262

problem fixed...

This looks like a bug in the AGG compositing engine:

view center-face layout [

    f: box 100x100 white edge [size: 10x10 color: none effect: none] 
    with [

        pane: make face [edge: none offset: 50x50 size: 50x50 color: yellow]
    ]
]

At least the black angle in the bottom right corner isn't what I 
would've expected from an uncolored edge ... Is this a known issue?

Looks the same under older releases.

Not what I would expect either though.

Oh, true, I should've checked that ... But this looks so strange 
that I likely was thinking I would've seen it earlier if it was the 
case with older releases and betas ;-)

Might as well submit it.

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 ?

he told me 1.2.114 doesn't give him the problem. he had that problem 
with 1.2.1.

#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

it has been fixed. btw, the error actually came from to-local-file, 
i think.

>> 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?

#3733 fixed...tested by me.  Thanks.

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...

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".

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".

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

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/