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

Gabriele, can you add an extra bit to the details here http://www.rebol.net/cgi-bin/rambo.r?id=3837&

A reason for wanting this is to be able to generate an image of what 
the style looks like without opening a window, eg. for documentation.

(It's good to see what the original reasons are for each bug report. 
Should make fixing them more satisfying too.)

volker, well I didn't get any trouble under Linux with GNUstep's 
Terminal.app so it may be a terminal issue

If I ssh to a linux box from the terminal where I saw the problem 
originally, there is no problem either

Gabriele, I have some additional information for a ticket:

none does not cause a crash, though.

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

Hi, #3545 is marked as High importance. Actually, it is underestimated, 
because such problems are critical even for pre-alpha Rebol programs 
e.g. when trying to send keep-alive type messages to a port using 
Romano's ATCP scheme. I  wonder what is an optimal work-around for 
the current (Core 2.6 - based) scripts? (see #3465 too, marked - 
underestimatedly - as Medium importance) .

timeouts are a problem for normal (non-async) core, but should work 
fine on async core.

the "solution" (a trick, with its own problems...) i use for the 
detective is http://www.colellachiara.com/soft/Libs/timers.r

anyway - this is something we *need* for /services... so i guess 
there will be a real solution very soon.

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.

Maybe there is data also coming from a second port, as I have sometimes 
seen a crosstalk of events, if there is heavy traffic on the pc.

does it have a GUI too?

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.

my guess is that this will be very hard to figure out. please post 
all the info you can in a rambo ticket, then let's hope Carl will 
guess where the problem is. :)

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

Right that does it. Feel/over is not always doing its documented 
job. "The over function is called whenever the mouse pointer passes 
over or off of a face."  (quote from http://www.rebol.com/docs/view-system.html
   )

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

So I will submit a bug report for that.

Also, I would like modifications to related ticket #3112 "How feel/over 
handles face vs subfaces":

- Type: should be changed from "Issue" -> "Bug"  (because I think 
it will be ignored otherwise)

- Importance: should be changed from "Undetermined" -> "Medium" at 
least.

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

Thanks Gabriele, I am going to investigate some more. Perhaps you 
can add a comment to the report to change the doc instead (or at 
least).

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

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

Anyway, now the doc is fixed I feel a lot better.

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

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.

So I'm just going to check, but there should be a bug tracker item 
for this bug.

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

Ok, submitted a ticket.

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

seems a bug to me.

since when was this make c2 c1 or make c1 c2 possible? (I thought 
that the second arg had to be a block?)

The 2nd arg is an integer when making many other datatypes (usually 
meaning the amount of space to allocate for it initially)

   make block! 2222    ;; block with reserved space for 2,222 entries.

3rd arg needed in some cases too:
f: make function! [a b] [print a + b]

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

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.

Good work! And a very fine alternative. This is the time to deside, 
how the dialect should be formed. Situation is, I had no experience 
with PostScript before starting this dialect, so I have no feeling 
about, how the dialect should look. If only there were an SGML definition 
for PostScript, but the closest we come to some rules is the DSC 
(Document Structure Conventions).

Maybe we can take a look at some examples of real PS output from 
different apps?

my output file is a little shorter than yours, but only because I 
didn't bother creating the prolog / epilog

I think to create those should be a refinement.

because you might only want to create a short postscript fragment 
rather than a script.

In my lates PS output, there is also a problem, where the box and 
the filled box is made. The box ends with a closepath and a stroke, 
but there is no newpath to start the next. I think, that's not 100% 
correct, but it seems to work.

Ok, definitely need to find out when a newpath command is needed.

maybe just make 'newpath a part of the dialect as well.

That is a problem, because we then leave it up to the user to make 
sure, the rules of PS holds. That's the same as writing PS directly, 
so not much is won.

A good dialect is one with some simple rules, and where it's difficult 
to produce something wrong.

We just need to know a little more, then we can make it almost perfect.

draws a box at 72x72 where origin is translated to 72x72

you can't use a postscript barcode font?

ok, there's a hex format for images as well as using eps, but I don't 
know how that works.

ah! I was using a pair! instead of two numbers

You'll be trying to write a better postscript than postscript .. 
.which may be possible!

I haven't been thinking of that yet.... but the ultimate goal should 
be to use postscript on a higher level

A higher level is that .. writing a better poscript.

well, is C a better assembler?

it's a bit harder but not much different

actually only the text was harder because in PS you point to a position 
and start writing, where you in PDF-maker need to define a text box 
before writing

works fine with barcode readers. have tested with both cheap and 
expensive ones. just need a good printer

do %postscript.r
do %ean13.r
ean13-ps ean13-create "123456789012" ; 12-digit code

will output a block to be inserted in the postscript block

a bit clunky

Luckily I have no need for a barcode at present.

you can take any 12 digit string, but the 13th digit is a checksum 
which must be correct or the barcode can't be read

this is a multipage postscript file

http://www.compkarori.com/reb/starburst.pdfis a starburst

if a print server has multiple printers attached, they are likely 
to be on different ports eg, 9101, 02 ...

newpath sets up a new line which can be drawn.  Stroke has the same 
effect as newpath

Does moveto always indicate a newpath?

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

unlikely to be a coincidence.

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.

how to convert a gray ( range 0 - 1 ) to a tuple! ?

nothing to stop you using parts of a point.

I don't know if it's a bug, but Text in Draw does not obey the rotate 
commands, or the scaling commands.

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.

graham, out of curiosity, can you scale as you want? could you implement 
a slider? I'd like to see how fast it is.

Yes, could implement a slider .. if I can remember how to do sliders!

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

a measly 324Kb.

has a slider now for Henrik :)

the fonts scale a little funny

Just uploaded a newer version that places the slider vertically.

For those without postscript printers, using the free version of 
rops.exe might be a solution for them.

there is a free version?

I got the impression that AGG draw is skewed a little to assist producing 
SVG graphics .. but there's a strong case to support postscript better 
instead.

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.

Sigh .. looks like I need a better way to map postscript points to 
the draw coordinate system.

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

so presumably I have to reduce them a little in the south-west direction

I'm not sure.  I guess I should try a scientific method of determing 
this.

ie. draw a grid and see what happens

when you click on the "print" button, it generates a test.ps file 
which is the postscript "equivalent" of the stuff on screen ... except 
for the rotated objects

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

an eps file is just a postscript file which obeys certain conventions.

got a bit of a makeshift preview now. maybe I'll use it for the next 
version for the other races I'm doing this for