World: r3wp

Ok, very good.

Ok, submitted bug report to RAMBO.

get-modes s: open tcp://:87 'port-modes crashes new builds.
get-modes c: open tcp://localhost:87 crashes too.  
Probably similar to #3983, as copy get-modes .... works.

REBOL/View 2.7.4.3.1 27-Nov-2006
>> get-modes s: open tcp://:87 'port-modes
== [read write binary lines no-wait direct]

REBOL/View 2.7.4.3.1 27-Nov-2006
Copyright 2000-2006 REBOL Technologies.  All rights reserved.
REBOL is a trademark of REBOL Technologies. WWW.REBOL.COM


Licensed to:  .... (commercial) <....>
License ID: ...

Type desktop to start the Viewtop.
>> get-modes s: open tcp://:87 'port-modes


-----------------
Rebol Internal Error: Corrupt datatype: 176 at 201

I have same result as Cyphre. No user.r customizations ?

also - which version of windows is that?

XP Pro
5.1.2600 Service Pack 2 Build 2600
even with empty user.r

the crash does not happen if I read a web page or start e.g. the 
desktop beforehand

>> trace/net on 
crashes Rebol too and wants to send an error report to microsoft

trace/net - i have already reported it to carl.

The crash does not happen, if the license.key is not available.
I submitted it to RAMBO.

interesting. but i have a license.key too.

do you have IE 7?

It's reproducible with more than one installation.

BASE-TEXT/init assumes that font/colors is a series, which means 
that this makes an error:

>> view layout [text "Hello" font svv/vid-styles/FIELD/font]

** Script Error: change expected series argument of type: series 
port
** Where: forever
** Near: change font/colors font/color
if none?

It is the third line where the error occurs.
>> print mold svv/vid-styles/base-text/init
[

    if all [not flag-face? self as-is string? text] [trim/lines text]
    if none? text [text: copy ""]
    change font/colors font/color
...

( and various text styles inherit base-text's INIT )

so... what to do about it ?

Is it the fault of FIELD font not having a colors block, or is it 
the fault of the INIT not being able to handle the NONE case ?

I tend to blame INIT. Patching works well:
	if font/colors [change font/colors font/color]

I had issues with a license key file at one point. I think Cindy 
said things changed, so it could be an issue with a specific license 
key.

it' not my first license.key. I had also problems and got a new key 
some time ago.

i don't have ie 7. so there could be a change to the os that comes 
with ie 7?

hum, I seemed to have stumbled across a pretty mean VIEW bug... it 
seems openeing a popup within an even handler, will send off events 
to TWO feels !!

right now, I have a popup which receives events within its over function 
while the face which called the popup, still receives move (away) 
events within its engage func... funny thing is that I receive a 
steady stream of AWAY actions as I move the mouse!

obviously, since the events are triggered within a different WINDOW! 
  hehe  :-)

this illustrates well how strangely this code reacts:

engage: func [face action event][
	w: find-window face
	probe w/text
	w: find-window event/face
	probe w/text
]

these display different window titles!

anyone know if this has been reported ?

Please post a complete example which shows the buggy behaviour so 
we can check it.

Gabriele, I would like to raise the importance of 
http://www.rebol.net/cgi-bin/rambo.r?id=3571&


I patch functions quite often, and then I usually need to bind to 
the function context. If the original function was not written by 
me (or even if it was), then it's tricky to find a good technique 
to find a suitable word local to the function context. I have to 
look in the function body for a local word and write code to select 
it, which usually looks like spaghetti. I do my best, but if the 
function body changes for whatever reason, then my patch code is 
probably also broken. None of us likes to write code that is so brittle.

Anton, I'd actually prefer IN to work with functions; however, Carl 
says that he thinks accessing the context of a function is not that 
useful.

I second Anton's request, I do the same myself, and for example, 
am using it within VIEW stuff to modify some event handlers... its 
often easier than trying to re-bind the body which comes from several 
contexts...

There should be a way to vote for tickets, to help RT put a measure 
of weight on them. I also think the same person should be able to 
revote more than once, lets say once per month, this helps weed out 
issues which are long standing and are a big issue for one person. 
 otherwise, you cannot really differentiate what is continually causing 
concern for you over time.  persistent bugs are the most important 
ones IMHO.

Could someone with RAMBO access update 4063 ("Garbage characters 
appear in molded strings sent to SQLite via routine!") to note that 
the problem does not occur if a periodic recycle is performed (and 
that the referenced driver now does this, so the recycle must be 
removed to reproduce the problem). I think this narrows down a whole 
class of problems related to unexpected results when repeatedly calling 
a routine.

Gabriele, well, Carl is just wrong :) He probably just patches source 
directly, rather than indirectly, like we have to. And, of course, 
Romano thought it was useful enough to post the rambo ticket in the 
first place.

IN working with functions would be nice, but getting the function 
context is more fundamental and more useful for patching in the way 
I have described above.

Maxim, voting for tickets: I support that idea. I would like to add 
a moderation points system. Members names and moderation points are 
listed, eg:
	Romano  +3   ; <- total of Romano's mod points
	Gabriele  +2
	Ladislav   +1

 Clueless  -3   ; <- this person didn't like it but they have little 
 experience, so, if we like, we can filter their contributions out 
 by name, here.

Yeah, *Monkey Patching* is useful http://en.wikipedia.org/wiki/Monkey-Patch
specially when it is the only posibility to fix an outside problem 
to your code. The alternative of rewritting the whole function is 
to expensive.

Anyone else support the move to raise the importance of #3571 ?

Anton, i thought it was useful enough to ask Carl for it directly 
many times. :)

then we are 5 ! (IIRC Ladislav also thinks this is very usefull)

Gabriele, well then, I think we have a mandate to increase the importance. 
If Carl gets mad at you, you can point at me. :)

and me  :-)

does this deserve mentioning in RAMBO?

    block: next [1]
    copy/part block -2147483647 ; == [1]
    copy/part block -2147483648 ; == []

not sure... but one more ticket won't kill us :)

Hmm.. I've often considered whether to immediately submit a post 
of dubious importance. It would be nice to reliably delay my submission 
by six months or so. Maybe by that time the submission would become 
irrelevant because of a fix or new rebol version etc, and by not 
posting it I am keeping others free from distraction. But I am not 
using calendar software to remind me. (One of my goals this year 
is to start using calendar software.)

one of goals this year is to start using A calendar... period  ; 
-)

(Well, I currently use a paper-based diary.)

I used a mangled brain with continuous stack overflow...  ;-)

Stack overflow - same here. Not something to be proud of.