AltME groups: search

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 ?

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.

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?

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

I have searched for "changes" in rambo and I did not find a similar 
ticket.

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.

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.

no, just a plain console application accepting tcp socket connections 
and data

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

I did not see this with rebcmd2..55.3.1.alpha, but maybe I did not 
test with enough traffic from more than one sender at the same time.

I just remember that some of the interim releases were not stable 
enough regarding read/lines, so I was waiting for a (near) final 
release for intensive testing.


Now I am checking, if different behaviour of the sender has some 
influence.

Normally at least one sender establishes a permanent connection, 
but most sender open a connection, do their communication  and close 
the socket at the end.

That's the reason, why I know, that the crash happens after closing 
the socket.  The last message was always from one of the senders 
with a one time connection. He got his answer, but the receiver did 
not print the message, that the remote socket was closed.

Maybe it has to do with timing and or GC problems, as the crash happens 
mostly at a time, when there is more traffic, but never when there 
is always  continuous communication. When I play back the communication 
without interruption, there is no crash.

sqlab it will be good if you can do some pkt traces. Then later we 
can do some pkt replays to repeat the problem, and track it. We will 
need basically the server code. The client can be performed by the 
replay utility.

Server code and pkt capture. (pcap format is preferred this is done 
with ethereal).

Jaime: That will not be possible, as the data are subject to privacy.

i will try to narrow down the server and see if i can produce a crash 
with anonimized data.
sorry.(

The above example works but no longer works if you click and drag 
off the face.

sqlab "anonimized data could work". We need to isolate the problem, 
and we all want a very robust rebol.

click and drag off
 -> that's the away action for the engage function.

OK, so the above document needs to be changed to say something like: 
"... and not in the middle of a drag, whose events can be trapped 
with the engage function..."  ?

well, the new rebcommand finally crashed on me too though took much 
longer than previously.  Usage jumped to 50% as before and stayed 
there.  I guess on a non hyperthreaded cpu, it would have jumped 
to 100%.

It's looking like I need to ditch odbc and move to using doc's mysql 
instead.

Thanks again Gabriele. Even though I've read that document several 
times over the years, and styled many widgets, somehow I kept getting 
confused by OVER. It was that particular phrase "The over function 
is called whenever the mouse pointer passes over or off of a face." 
Every time I re-read it I believed it :)

Gabriele, #3112 shows a different issue and should not be dismissed. 
(I admit my last bug report was a little bit crazy, and I'm sorry 
about that.)

Jaime: Unfortunately I will not have so much access to the data and 
the time to anonymize it the next days for familial reasons.
When I am back, i will go on.

Thanks Gabriele! This is actually a burning issue for me!  I felt 
a bit ignored by that.
Anyway, I have been researching, and I found the bug note:
	http://www.rebol.com/docs/view-system.html

 "Bug Note: On current versions of REBOL, the event/face within the 
 detect function

 is not set to the proper value. It should indicate the target face 
 of the event, 
	not the face in which the detect event is used."


 If that is fixed, then it should be possible to filter conditionally 
 to face or subfaces,
	eg.

		detect: func [face event][

   if face = event/face [event] ; return event for this face, but none 
   for subfaces
		]


 and hopefully if a face does that, then it should get all 'over and 
 'away events, 

 regardless of subfaces. That is, to be able to know at any time whether 
 the mouse
	is in its rectangular area or not.

I searched for "detect" and did not find a ticket. So I will make 
one.

about #3112: "BTW, the reason I dismissed it is because his test 
example seems invalid. He needs to add an over feel to the face in 
the pane.


There may be one issue however... which is that when moving from 
blue back to red, a FALSE over action does not occur.  However, have 
him submit with short and precise description and an example that 
does not use VID. (He can cut and paste the similar over example 
from the doc then modify it.)"

Don't know when, but old. IIRC older than 'construct. in a way its 
the predecessor of construct/with . And as such, with only data, 
there is no problem anyway. but can be used to merge objects too, 
kind of multiple inheritance. i thought.. ;)

I used it primarily for data, to add default fields. 
 item: make context[ defaults ] load %item.r

there are no functions, so no problem. now thats construct/with, 
even no binding nowhere :)
But lately i did something obscure and it drove me made..

Rambo #3869 "** CRASH (Should not happen) - Invalid string width 
16 : type 41" 

sounds very similar to the problem I have with cmd. Just that I have 
to wait a few thousand messages and at least two days for one crash.

Linux 1.3 Beta -> http://www.rebol.com/view/tools/icon-maker.rDoes 
not what it tells it should..resizeing seems a problem and the image 
is not displayed correctly.. compared to the MS-Windows version 1.3

Linux 1.3 Beta -> here is probably the explanation of the Memory 
problem above ;-) 

----------------------------------------------------------------------------------------------

Seems the sessions are still here, I execute them from within DESKTOP 
and pressing [X] to close the window.


 3418 userx     10   0 17044  16m 2808 S  0.0  2.6   0:27.85 rebview1300142b 
                                                                  
    

 3419 userx      9   0  1456 1452 1376 S  0.0  0.2   0:00.02 rebview1300142b 
                                                                  
    

 3420 userx      9   0  1140 1132 1088 S  0.0  0.2   0:00.00 rebview1300142b 
                                                                  
    

 3465 userx      9   0  3388 3388 2116 S  0.0  0.5   0:01.00 xterm 
                                                                  
              

 3467 userx      9   0  1552 1552 1136 S  0.0  0.2   0:00.05 bash 
                                                                  
               

 3818 userx      9   0  6796 6796 2216 S  0.0  1.1   0:00.18 rebview1300142b 
                                                                  
    

 3819 userx      9   0  1468 1464 1388 S  0.0  0.2   0:00.00 rebview1300142b 
                                                                  
    

 3820 userx      9   0  1152 1144 1100 S  0.0  0.2   0:00.00 rebview1300142b 
                                                                  
    

 3898 userx      9   0  8500 8500 2284 S  0.0  1.3   0:00.77 rebview1300142b 
                                                                  
    

 3899 userx      9   0  1156 1148 1128 S  0.0  0.2   0:00.00 rebview1300142b 
                                                                  
    

 3900 userx      9   0  1152 1144 1124 S  0.0  0.2   0:00.00 rebview1300142b 
                                           

 3910 userx      9   0 12220  11m 2272 S  0.0  1.9   0:01.15 rebview1300142b 
                                                                  
    

 3911 userx      9   0  1156 1148 1128 S  0.0  0.2   0:00.00 rebview1300142b 
                                                                  
    

 3912 userx      9   0  1152 1144 1124 S  0.0  0.2   0:00.00 rebview1300142b

Linux 1.3 Beta -> executing logo-make.r it again reports and i have 
indeed only 50MB left from the 500MB i had befor starting it.. -> 
** Script Error: Not enough memory
** Where: wake-event
** Near: do event 
empty? screen-face/pane
>>

Linux 1.3 Beta -> Something is realy from with the terminal adjustement 
during view/console and after stopping view. The Console gets messed 
up like it has the wrong TermInfo values?  During a call/shell execution 
from the view/console also the console from Rebol/view is mixing 
up the call/shell "vi" ????????

It simply claims all the memory it can get, and to claim the  500MB 
my system has left is not very nice , swapping is very active and 
i have 5MB left for resources..

Linux 1.3 Beta -> problem with Offset inside a face where a unview 
- view changes the offset of the parent-face to a different offset. 
IM not sure if this is a feature in 1.3 but in 1.2 its not happening, 
the code below demonstrates the behaviour.. Click the window and 
the window will always move by face/offset/y
direction to a new position..
myface: make face [
    offset: 100x100
    size: 400x400
    feel: make feel [
        engage: func [face action event] [
            if action = 'down [ unview myface   view myface  ]
        ]
    ]
]
view myface

Linux 1.3 Beta -> When running this script and pressing the window 
im getting the following error ->
view make face [
    offset: 100x100
    size: 300x100
    edge: none
    pane: reduce [
        make face [
            offset: 0x0
            size: 300x100
            color: water
            edge: none
            text: "Modified Font Object Settings"
            font: make font [
                name: "times"
                size: 20
                style: 'bold
                color: white
                align: 'center
                valign: 'middle
                space: 4x4
                shadow: 2x2
            ]
        ]
    ]
]



--- ERROR --- although its not a displayed event i think that it 
still should not dropout..

** Script Error: Invalid path value: dirty?
** Where: evt-func
** Near: if all [
    system/view/focal-face 
    event/type = 'down 

    not within? event/offset win-offset? system/view/focal-face system/view/focal-face/size 
    system/view/focal-face/dirty?
] [
    fac: system/view/focal-face 
    unfocus 
    if flag-face? fac on-unfocus [
        do-face fac none 
        fac/dirty?: none
    ]
] 
event
>>

Today I had chance to show to my Lotus Notes fried small app. I took 
LN phone list, imported it into rebdb, used View 1.3 and Cyphre's 
grid and produced small cute tool ....

well, but I was at computer, which was never touched by Rebol and 
I have to say, that my annoyance is not over and that we better change 
some things sooner than later ...

Simply put - I don't want to use installer, the option of not installing 
rebol is no option for me, that is for eng user. We have -i or --noinstall, 
whose behavior can be regarded as being buggy and I want to submit 
it to RAMBO. I want to ask, if anyone else agree ...

Even if I use -i, Rebol tries to start Desktop. I did not ask it 
to do so. And it tries to connect to internet - if we are not able 
to do our homework to detect proxy automatically, nor are we able 
to produce non-blocking system buttons, we end-up with nearly ten 
or twenty seconds blocked desktop window, where even system close 
button does not work!

So - if most ppl agree, that starting desktop and trying to connect 
to internet directly is good thing (with auto proxy detection it 
could be, without it it simply is not), then I want -i and --noinstall 
to skip Desktop launch phase - and that is what I am about to submit 
as a request, or as a bug report ...

I think you could launch rebol with the -sqw switches and don't have 
the above problem.

Also - once Desktop launches, it tries to connect to internet. As 
most users are behind proxy, I can bet they will be annoyed, because 
Rebol is completly blocked and does not react to system buttons, 
you can't even shut down the app...

yes, maybe so, but I don't need to use --do, do I? At least according 
to what 'usage output shows me in console. Just try to uninstall 
rebol and try to type rebol.exe my-script.r in OS console .... desktop 
will pop-up.

it would not be so denerving, if I could imediatelly shut down desktop, 
but it blocks and it feels like hours ;-) We should do something 
about that too. Either we learn how to read proxy settings properly, 
or don't try to connect to internet by default!

The only callbacks i know are by using async. Gabriele and Romano 
have protocolls to do that.

using link and 1.3 on linux, workaround: export HOME=/home/volker/ios 
. solves the .rebol-nameclash and works.

...and under OpenBSD

regarding the above GC crash (and to Volker): I think, that the best 
workaround is

    do :f

instead of just 

    f

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.

makes problems with prebol and friends

The interpreter stops respondin and start consuming a lot of cpu 
cycles.

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

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.

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.

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.

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

Add EVENT/ENTRY-FACE (or EVENT/WINDOW), which will store

the top-level window face which is the entry point for host os events.
So EVENT/FACE is then free to be set to the face that is the
target of the event, as it was originally intended to be.


OR, instead of the above, and achieving backwards compatibility, 
you could:

Add EVENT/TARGET-FACE, which stores the target face.
(So EVENT/FACE stays as it is.)

Two new bugs discovered originally by Cyphre posted:

	load {#object! [...]} bug

and

    VALUE? crashes the interpreter

do you guys think someone could look into #3822 red-icons related 
bug? I think that we should close that issue once and for all. The 
test case is very clearly described. It is either bug in REBOL or 
in Windows, but if not solved, timestamping is not reliable with 
REBOL in any way ...

dunno, really - I tried that on linux and it did not appeared. The 
difference is only in one thing - you let os pass time-switch point, 
or you skip it. In linux, when you report time in console, you can 
see one other letter, which signals you if time shift is accounted 
for or not, but dunno how it is with Windows ...

#3885, #3895, #3896 and speed of 1.3.2 beta OK, passed all my tests

and don't even dare releasing new View without fixing rebol.exe -i 
script.r (launching desktop, ignoring -i) :-)) ... because then rebol.exe 
can't be used for batch processing on machines, where you simply 
don't go via manual installation process ....

Bug #3873 isn't a bug. REBOL does nesting of { and } when strings 
are specified with {}, and ignores { and } when strings are specified 
with "". The ^ is unnecessary in "{^}" because the } doesn't need 
escaping. The ^ is a syntax error in {{^}} because the } would already 
be escaped by the first { inside the string (the second overall), 
so escaping it again means that the string is never finished, as 
there must be one unescaped } after every unescaped { because of 
nesting. In both cases you either shouldn't put the ^ ( "{}" or {{}} 
), or should escape the ^ if you want it in the resulting string 
( "{^^}" or {{^^}} ). Sorry if that was a little confusing - I'm 
sure someone else can explain it better.

Well, what I meant to say on 2) if counting of braces frees me from 
escaping, fine with me. But escaping should obviously work. and it 
doesn't (at least not for opening brace)

Ladislav, I agree that since ^} is usable, so should be ^{. Counting 
of braces can be quite awkward without this. This should be submitted 
to RAMBO.


In any case, this behavior doesn't affect the ability to work with 
strings or limit the characters that they can contain. This only 
affects how strings are specified in REBOL source code. Once they 
are parsed by load, it doesn't matter where any ^ is in their contents. 
Try reading (READ native) data with arbitrary ^, { and } from a file 
and there will be no escaping performed. A load (LOAD native) of 
that same file will check REBOL data syntax and do any escaping it 
can.

Still, the behavior described in bug #3873 was actually intentional 
and documented.

Ladislav, as I said, you make a good point that I agree with. I find 
it more than annoying that {} nesting without being able to escape 
{ is awkward, often requiring joins with the string "{". They should 
definitely escape {. The REBOL User's Guide doesn't say how escaping 
works, really. I was left with the impression that ^ would always 
escape the next character and any special treatment thereof, but 
unless the next character (or characters for ^(00) style escaping) 
fits the subset that is handled by the current REBOL version, the 
^ is stripped and ignored. At this point the { character is the only 
one that I've found that has special treatment that isn't disabled, 
but I haven't done an exhaustive search.

So, the loader escapes { and } but the console reader doesn't, and 
thinks the string either isn't done yet when it should be, or is 
when it shouldn't, respectively. Weird.

Console has to to do this:
!>[
[    1
[    2
[    ]
== [1 
    2
]

So it cant use the default 'load. So either it was implemented a 
bit lazy, and/or compatible based on some old version. The early 
rebols had really problems with such bracket-things.

Volker, well then I guess I'd better check Core 2.5.0 to see how 
it behaves. I still use that version on WinCE - it is still the current 
version on many platforms.


It doesn't seem like it would be difficult to add escape processing 
to the console reader, especially since it would only have to do 
it with { and }, and even then only in {} delimited strings.

err, both S and L are the same, sorry, it is consistent in that sense

More errors with list. TAIL? and HEAD? throwing errors.

#3898 shows what I too reported as a critical - total annoyance of 
how View "works" in behind the firewall environment. I am glad I 
am not alone. Either rebol proxe detection code should be made smart 
(and I posted analysis how), or it should not try to connect to internet 
at all, gee! If it at least would be possible to shut the task down, 
but it isn't ;-)

If it does, the basic rule of the dialect might be: at <pos> <content>
And then we get rid of blocks.

my next step is to now convert the ps dialect to draw - so I can 
have a print preview ( confined to lines, boxes and text ).

I've looked at http://www.rebol.com/docs/draw-ref.htmland it doens't 
mention how the coordinate system is based.

If you have a 15" monitor showing say 1280x1024 and you have a 21" 
monitor with same resolution, you don't have 72 dots per inch on 
both.

Jaime, Postscript uses points for it's units and these are 72 per 
inch.

first pass at taking the same postscript dialect and rendering it 
to draw.

the shaded box is in the wrong place .. not sure why, and I had to 
shift the bottom text up so I could see it.

So, my aim is to preview a page on screen in this dialect and using 
a different parser on the same dialect, create postscript which I 
can send to the printer.

Graham, what I meant is that even to the unit is a *point* the fact 
is that you can more than 72 pixels in a inch. For example laserprinters 
have 300 to 1200. And there is some displays that 96dpi, and I have 
seem e-ink that gives you 150dpi(s).

Allows a preview in 50%, 75% and 100% mode.

SLIDER in the layout and then use /data to extract the position which 
is between 0 and 1

There's a free postscript viewer and allows you to print in windows 
here: http://www.rops.org/

It's http://www.rops.org/download/freescript53.exeand does only 
Level 1.

Uses windows installed fonts instead of postscript fonts to preview 
and print.

no it moves and rotates. maybe SCALE is working too well?

the versions that cost do level 2 and 3.

Looks good, Graham. I hope to get time one of the comming days to 
investigate PS a little more, so the dialect can be more complete. 
I like your idea about getting rid of blocks, and I hope to make 
a consistent version with few blocks, maybe only for font.

Can someone check these to see if they are correctly matched ?  The 
left hand is the postscript font, and the right hand is the true 
type font

so, you can install these and get pretty exact matching.  You'll 
have to change the lookup table above.

IIRC when I was trying to match linux fonts to windows... arial and 
helvetica where pretty different when applied over each other...

I need some fudge factor .. at present I am off by a little high 
and to the right.

I am previewing my draw doc, and when I generate the ps file, the 
coordinates are to the north-east in the ps file.

ie. draw a grid and see what happens

at present, I am keeping the x as is, and just reducing the y by 
the size of the page

I am a little confused about some of these ps fonts - sometime it's 
called BoldItalic, and other times it's called BoldOblique

You can create the barcode in John's as an eps image, and insert 
it into the postscript.

Anyways, I quite chuffed to get this preview and printing to postscript 
working ... after years of no way of printing from Rebol.