AltME groups: search

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.

OK, I'm going to do more preparation so I have the clearest example 
ever. :)

Linux 1.3 Beta -> I need to give an extra do-events for view actions 
to make a face...

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!

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.

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

    do :f

instead of just 

    f

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.

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

That should certainly work Volker. If I had the need under Windows, 
that's what I would do. So far I've been able to live without it.

Robert, as you say, the mentioned people didn't get to develop the 
standard further, I think, Carl should have the information discussed 
here in this group. What do you think is the best way to contact 
Carl on this? With the feedback link on his blog?

Great spec Geomol (Specifikation -> Specification), that's the best 
doc I've seen on MakeDoc (any version) to date! ;) It got me thinking 
about a few things; firstly, which of the following is valid:

*One
*Two
*Three

or

* One
* Two
* Three


and, do we *really* need to insist upon a blank line between each 
MakeDoc element? Isn't 'newline more than adequate?


Also, it [the standard] should make it clear that the EOF tag "###" 
is *optional* - I don't want to be told that "you need it to make 
your document work".

No problem with that. That would probably be the way to do it in 
a 2-pass formatter. It's only a problem in a 1-pass formatter, because 
you have to do some work anyway after first pass to make end final 
output (incl. TOC).

Carl made MakeDoc and started a project some months ago to define 
MakeDoc2, but it seems, the group fail to make progress, so Carl 
wrote something about it lately and published some scripts. As I 
see it, MakeDoc has some bad ideas around commands like \note /note 
\table /table and so. Those things should be strictly based on the 
hierarchical datamodel, else users of the format WILL make errors, 
as we see it with HTML, XML and the like. And MakeDoc2 also miss 
bold, italic and the like, which is done as HTML tags. I need to 
make a lot of specifikation and documentation for my projects, so 
I desided to make my own format, that suit my needs. I don't know 
yet, what I should do with it yet, but I'm going to do it. :-)

as I said earlier, there are thousands of products which the core 
of make-doc from RT will generate.  It is pretty easy code to extend, 
once you get the hang of it.  Make-doc2 gives us a much better springboard 
to do things right, with a better user experience out of the box.

Maybe I wasn't that clear. MDP uses the same approach as makedoc2. 
Parser and output-generator are seperated. I really don't see any 
advantage in a next fork. IMO it makes more sense to change what 
we have. Feel free to do so with MDP and submit your changes back 
to me. I will integrate them.

I think, for the way Geomol is thinking, that his best approach would 
be to enforce his heirarchical structure on the writer, he might 
need to make his rigor as a pre-make-doc dialect that would feed 
to make-doc dialect.  Not hard to do, or he can bypass altogether. 
 Lots of room for experimentation, since the source is there.  Tremendous 
advances can be made by good experiments.

Yes, I know make-doc-pro, but I haven't looked at it in depth. I'll 
do that. I've also started to write a comparison of MakeDoc2 and 
my new NicomDoc format - what thoughts, that made me start work on 
an expansion (as I see it) of MakeDoc2.


About other formats already there, I plan to make conversion scripts, 
so you can go from one format to the other. Of course I hope, we 
can all agree on one final format, that'll suit us all.

Robert, MDP is very close to what I'm looking for. Only major problem 
(as I see it after a quick view) is, that MDP uses \<tag> /<tag> 
tags like MakeDoc2 do too. I'll explain in my NicomDoc vs. MakeDoc2 
comparison, why this is a big problem. I'll post here, when my comparison 
is done.

I like *bold*, ~italic~, _underline_ and -strike- notation too, but 
I'm afraid, it will give problems for some users. What if you want 
to have a part of a word in bold? How will you write a mathematical 
expression with - and *? You could of course use the escape character 
(\) for that, but then you'll have to do that every time, you use 
- and *. What shall the rules be with bullet points and *bold*? No, 
I think, we need something else in the document format, and then 
let users have the option to use *bold*, ~italic~ and so notation 
in a word processor, which can be based on the new document format 
anyway.

I'm a bit in two minds about alternative ways of doing things. Maybe 
it IS a good idea to be able to also put left and right on =image? 
Is it general a good thing to be able to do the same thing in more 
than one way in a standard like this, or is it just more confusing 
then?

Yes, tools like MakeDoc are about focusing on content, not style. 
It's great if we have a *way* to do more complex things (extension, 
manual tag insertion, etc.), but they shouldn't be a priority.

(and not hard to do at that)

I never like to do to many arguments in Make-Doc, but what of Alt 
Text...

Argh! You was faster than me !! 

I wanted to do a things like that. I have a style to render inline 
formating if you want.

I have also an editor with some funcs to help inserting tagswith 
key shortcut.

Do you bother if I do a fork of it with my own idea ?

I have a style to render inline formating if you want
 ... yes please!

Do you bother if I do a fork of it with my own idea?
 Not at all, the code is really QAD though ;)

Hi ashley !! I see your MD2IDE it seems you have open the competition 
with my MDP-GUI hahahaha. Well I like the redering window on right 
of the Window. The bad point is that the previsualisation of the 
texte is not updated until the save action. Updating it dynamicaly 
could be a good thing. There is no button to short cut the insertion 
of the balise like in MDP GUI (feel free to retake from MDP-GUI evry 
thing you need). Personnally Im waiting for the new rebol/view version 
that will speed the drawing engine and be able to use AGG based styles 
like Cyphre showed us to do. what about integrating to your product 
MD2IDE the net releasing support (for example to update quickly a 
blog based   on carl's REBOL script)

I'm adding some °7° function to MD2 that will parse °7° tags.. this 
would add a global DB for adding links, addresses, bit's of MD code 
etc.   update the °7°, and you instantly update any future MDs.  
You can run the latest MD2 from Carl with this.. 

do load http://powerofq.com/start
°run° {°Make Doc 2°}

Graham if you make it the to inhinitate it why t do it ??

whay to spent time on things you know 99% of the time you will need 
to shut down in the previewer ... there is yet so mutch to do

Color Text (Rich Text). One week ago I talked to Carl here about 
various topics and reminded him of rich text, he said it is important, 
so I put together few notes we produced in the past and he noted 
that he has something slightly different in mind and that he may 
say publicly something to it, so let's hope he will do so ...

Thanks! I'll have to do that.

I'm going on skivacation for a week, but I desided to put my work 
so far on the NicomDoc document format up on my website. It's NOT 
version 1.0 yet, so some features are not supported. I'll write a 
short specification in a moment.


Parsing a NicomDoc document to HTML goes in two passes, first the 
raw document is converted to RebXML format. This is done by this 
script:
http://home.tiscali.dk/john.niclasen/nicomdoc/nicomdoc.r


Next the RebXML version is converted to HTML. This is done with this 
script:
http://home.tiscali.dk/john.niclasen/nicomdoc/rebxml2html.r


I've also made a little script, that will do the whole conversion 
in one go by calling the other scripts. It works much like calling 
makedoc2.r, and it can be found here:
http://home.tiscali.dk/john.niclasen/nicomdoc/ndoc.r


Those of you, who want to work with this format, e.g. make VID output, 
should work from the RebXML version of the document (after first 
parsing from raw document to RebXML with the first script), because 
this script handle all the complicated rules, so the RebXML version 
is much easier to work with.

It's tricky to make tables easy to produce for the writer, and at 
the same time give opportunities to have colspan and rowspan. And 
do we have the need to have tables within tables? That'll just make 
it even more complicated. I guess, learning by doing is a good way 
to figure it out. (That's one idea behind my NicomDoc format. To 
try things out.)

how do to exchange on document html rebol ?

2) the idea is to visit anything we can do in one day on that line. 
maybe i'll spend a day on that line before september so that i can 
have an idea of the time we have and so on.

Ok, missed this group -- Carl, just a thought (and see what others 
think) -- it's a little odd looking at the messages with newest on 
top.  Another suggestion would be to do newest at bottom and put 
an anchor at the end so that incoming links start reading the page 
at the bottom to mirror the AltME view...

Ingo -- I sent Carl some code (based on some off Andrew's) to do 
that.

all you need to do is insert <br> as you parse each conversation 
and limit each line to some reasonable length

but now I have another question to brainstorm - I wanted to popularise 
rebol a bit on OSNews.com - they are very open and their site is 
being visited some 100K hits a month. I wanted to post View 1.3.2. 
news, but asked for advice here on AltME, as OS-X port may not be 
ready for public adoption. On the other hand, other products get 
posted even with much smaller updates. So the question is - should 
we post REBOL 3.0 news? Some may say - pots, once there is some product 
to download. But - REBOL 3.0 is also about documentation, and the 
announcement Carl posted asks also for C coders and other kind of 
help. As a side note, we could point ppl to try View 1.3.2 - at least 
Windows and Linux users could be attracted. What do others think? 
Should we wait further? But that way we will not get any publicity 
ever ....

I have added some funcionality to the imap handler. I guess I will 
have to rework this?

(So far it is in no way in a state to be released. I've added some 
way to handle mailboxes, but I want to do access by uid, too.)

After sort of reverse-engineering DO EVENT to try to make some nifty 
things work, I don't want to have to do all that again. I'd like 
to be able to hook into the system. I think the min-face idea is 
really good.

I remember what I was trying to do: event transparency. That requires 
hooking into the event system.

This probably belongs to Tech news channel, but - SkyOS got new rendering, 
buffered, which much improved performance. It was done by one man 
in a short period of time. I do hope we get more advanced compositing 
for new View too :-) http://www.skyos.org/?q=node/508

what do you say to this?

the question is, if users want to have the additional (actually second) 
block for the initialization purposes of do not mind to have everything 
initialized to NONE

you do not have to know anything about closure, you may imagine the 
same question for FUNC case: would you appreciate to be able to specify 
the initial values for locals?

Ladislav - I will read it tomorrow, as now I go to sleep - travelling 
to Prague tomorrow, so I better get some sleep ... but I do remember 
there were other goodies, which even I understood. Not sure now, 
if it was 'default ... I need to go via your materials once again 
...

I wonder how much closures will be used. For some apps, probably 
a lot. But we do pretty well everything with FUNCs right now. Therefore 
I suggest CLOSURE to take three block arguments, as it will not be 
used as much in general.

Nice one! Ladislav, does it makes sense to add /static to FUNC, or 
does CLOSURE do something more?

c: closure [/local a] [a: 0] [a: a + 1] ... so - do I understand 
it right, that we would have ability to e.g. set initial value for 
words which are local to functions? Currently it is not possible, 
is it? The only chance is to use 'a as a global word currently, no?

without the init block, you need to do:

I do understand closure for ability to initialise local words, which 
we currently are not able, are we? I have a bit trouble with the 
name of the function though - "closure" - how do I translate it to 
myself? Is the name chosen because other languages use it too?

...that is why CLOSURES need to do more work and will be slower than 
FUNCs

Pekr, the point is, that it's practically imopssible to catch all 
"vars" [*]to make them local, think about

	func [][do compose [(to set-word! "abc") 10]]


So it's better to have all "vars" defaulting to global. At least 
it's consistent that way (and faster).

[*] at least I guess it would mean a real big overhead.

values defined as default arguments are just like /local variables 
in rebol, they are only defined once and persist from one function 
call to another.  thus blocks get re-used.  We get used to this in 
rebol and do our own copy []   and   return first reduce [val val:none]

maybe 2 cent of mine:

to me it looks pretty confusing, reading all the above - if I get 
the intention right I would separate it like this

1) how to (or do we want) initialization - no matter if with closures 
or just normal rebol funcs

2) how will closures be in rebol3, by default (breaks a lot as Ladislav 
told) or not
3) the static thing Ladislav began with

@ 1) 

- to me this doesn't belong to the whole closure discussion (if it 
deeply does I don't get right now why) 

- one possibility would be to add an refinement to func or closure 
also - no? - makes the order of the optional third block a bit awkward, 
but on the other side that's what refinements are for - no ?

@ 2)

- we should have closures and propagate them as the default version 
for normal people or newcomers if rebol3 is out - they are safer 
IMO and don't make too much trouble with unexpected effects, especially 
for people from other languages (especially from the current dynamic 
kind)
- so closure should be separate

- with hopefully more asynch behavior by default build in, in rebol3, 
closures are anyway a must 

- if somebody got the concept of normal funcs - people can use it 
for speed reasons easily

- from Gabriele or Ladislav (or somebody else) it sounded a bit like 
one of the thoughts around closures involved the binding capabilities 
- I don't overlook this right now, but it still would be possible 
to change funcs like today, wouldn't it ? I mean there might be something 
like changing a function or rebinding it's body (or parts of it) 
can cause problems if local vars of a closure should be protected 
by this - on the other side who would do this, who doesn't know what 
he does ?


@ 3) maybe some of the static capabilities would be nice to have 
for closures then too, don't know - right now it's easy to build 
- how would it be done (in the language) with closures ?

And just some questions:

what function attributes will be added ? and what will they do, what 
purpose for .... :-)

will they be kind of dynamic or user extendable - so that own attributes 
could be defined - even if not too useful with rebol in some sense 
(or maybe it is - i'm not sure) - so some design by contract could 
be added without hacks for some needs (just mean it as an example)

will function get more similar to objects/contexts (or the other 
way around) - I mean that the concepts get closer ?

closure allows you to do things that you can't do with funcs

Yes, that's the basic idea. I'd say it's rare for people to use literal 
values in specs, but they *can* do it today. And, yes, parens conflict 
with COMPOSE but, again, how much code COMPOSEs func specs?

I think either one of these last two options we've come up with could 
work. I want to think about it a bit more, and others may chime in 
as well. I'm wondering if the extra block approach as easy to do, 
and had good performance, where this may have a bigger impact, but 
I like this line of thinking much better.

as easy to do = was easy to do

I'm not sure. At a glance I like it, but then I think about other 
things that we may want to do in the future, e.g. constraints.

It's the REBOL problem of being able to do anything, and we need 
to think about how we really want to write functions IF (and that's 
a big IF) it's something that affects R3.

we dont have to do nested if / then within rebol.. so checking all 
the args can be done in one simple line using all [ () () () ]

but what I like about the approach of design by contract and the 
like, is the separation of who is responsible to do what - I think 
this counts not only in OO programming (eiffel like)

e.g. if you know that you function has to do a certain job, then 
the function shouldn't be necessarily responsible to do all the checking 
in can think about, but the sourrounding code should call it like 
it is  supposed to do

I'm turning against packing more into the func spec. Constraints 
can be easily coded with an extra function that builds functions, 
eg:
	constrained-func: func [spec constraints body][
		func spec compose [
			(constraints)
			(body)
		]
	]

That's really simple to do, separates the constraints from the rest 
of the code, and results in a normal rebol function. Furthermore, 
the constraints can be any rebol code, not just some restrictive 
dialect.

I think it had to do with pair! being used in draw, offset, etc. 
to indicate pixels

PostScript normally uses units of "points" for placing graphics on 
the page. I find it more convenient to work with centimeters. I got 
the following snippet of PostScript code from a public domain program 
called "GLE" which I believe is available at any large ftp site; 
I recommend this graphics program. By examining the PostScript output 
of that program I collected the following piece of PostScript code:


matrix currentmatrix /originmat exch def /umatrix {originmat matrix 
concatmatrix setmatrix} def [28.3465 0 0 28.3465 10.5 100.0] umatrix


What this basically does is rescale the page so that now all following 
commands will work as if the centimeter is the basic unit of length. 
This places (0,0) near the bottom left of the page and (21,24) near 
the top right of the page.


If you don't do this, then (0,0) is the bottom left corner of the 
page and (612,792) is the top right corner of the page (if you are 
using an 8 1/2 inch by 11 inch sheet of paper). These are the default 
PostScript units; 72 of these to an inch. 28.3465 to a centimeter, 
thus the numbers above in the last line of PostScript code.

setcm seems to influence font size. Try:
do http://home.tiscali.dk/john.niclasen/postscript/postscript.r

write %test.ps postscript [page [font [Times-Roman 1] setcm linewidth 
0.5 path [setgray 0.5 at 2.5 2 box 8 12] path [at 5x8 rotate 45 "Hello 
World!"]]]

I managed to switch y-axis, try:
do http://home.tiscali.dk/john.niclasen/postscript/postscript.r

write %test.ps postscript [page [switchy setcm linewidth 0.1 path 
[setgray 0.8 line 1x1 5x5]]]

New version! PostScript is default set to DeviceGray with no colours. 
To set it to DeviceRGB, I made a command in the dialect for that. 
Try:
do http://home.tiscali.dk/john.niclasen/postscript/postscript.r

write %test.ps postscript [DeviceRGB page [switchy linewidth 5 path 
[setcolor 255.0.0 line 50x50 50x100 setcolor 0.255.0 line 50x100 
100x100 setcolor 0.0.255 line 100x100 100x50 setcolor 255.0.255 line 
100x50 50x50]]]

louis, the one on rebol.org seems to be a bit old. the one I have 
locally can generate bitmaps as image! in 1x, 2x, 4x and 8x size 
and vectors for PDF Maker. it can generate an EAN13 code with the 
correct checksum. it doesn't save to file, but it's only a couple 
of lines of code to do that

I think the most common scenario for those of us wanting to do printing 
is to to compose a page, preview it and then print it.  This way, 
we have the one dialect that covers both bases.

New version of postscript.r uploaded! I've add the prolog %! and 
epilog %%EOF as Graham suggested. I also wrapped paths in the postscripts 
commands gsave and grestore, so transformations give less trouble. 
Try this:

do http://home.tiscali.dk/john.niclasen/postscript/postscript.r

write %test.ps postscript load http://home.tiscali.dk/john.niclasen/postscript/test.txt


You now have a postscript file "test.ps" produced by the dialect. 
It's content looks like this:
http://home.tiscali.dk/john.niclasen/postscript/test.png

To see, how using the dialect look in use, see the "test.txt" file.

that's true... maybe it would be better to approach it through DRAW 
and let postscript.r do the dirty work

Hmm still some work to do.

test: form ps [
	font Times-Roman 40
	linewidth 0
	at 72x720 "REBOL PostScript Dialect"
	at 72x716 line 520x716	
	font Times-Roman 16

 at 96x680 "With this dialect it's possible to easily produce PostScript 
 output."
	font Courier 24
	at 96x600 "You can use different fonts."
	font Times-Roman 16
	gsave
	at 120x550 rotate -30 
	"Make"
	grestore
	gsave
	at 160x450 rotate 30 scale 2 4 "transformations"
	grestore
	at 96x400 "And do graphics:"
	at 100x320 box 200x40 stroke
	gsave
	at 180x240 rotate 20 
	setgray .6 
	box 100x80 fill
	grestore
	at 150x250 line 200x290 180x305 194x340
	font Helvetica-Oblique 12
	at 72x72 "Postscript is copyright Adobe."
]

Do we need to do that?

I take it that was much harder to do in pdf-maker.r ??

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

So the unit of measure doesn't have anything to do with the actual 
size of pixel or (dot).

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

but this is basically what I need to do

I don't want to insert CD into my Windows PC, and see Rebol blocked. 
In fact Rebol could run in highest priority and do own tasking :-)

Pekr, rebol would not have any control over that. The OS decides 
when it's time to do REBOL stuff

well AGG still has to do the rasterizing and its CPU based... so 
not million times faster.. but less REBOL collision trying to MANAGE 
the internal C data.

pekr, copies the body.  so we don't need to do val: copy [] all the 
time.

I hope I can do a good enough job on the actual site to keep REBOL 
is a nice light :)

Doc - do you think that Rebollers will now turn to bad habbit = we 
start using 1 thread for 1 connection? I wonder how much more expensive 
is that in comparison to current multiplexing aproach, using just 
ports?

Reichart..... do you want me to explain Anton how Quilt works?

All you have to do is ask though and you will be invited.

Do you sell Qtask to Operators?

please? do [ zoom cam to beam ]

has anyone made Carl drunk enough to reveal how to do server side 
SSL yet ??

what is there to do if you believe water is only for drinking?

No, IMO it's a product consolidation step. Whereas I don't know what 
/View has to do with this.

do they have trouble confinsing the french taxi driver to stop driver 
around the eiffel tower?