AltME groups: search

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

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

hmm, need to check all tickets with undetermined importance. otherwise 
they get overlooked.

Now I get the crash every second day

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 think then detect should get both faces? also, isn't the source-face 
somewhere in the event? (asking, i am no expert there)

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

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.

I would try to get 1.2.57.3.1e, it being the last in that set of 
versions.

to the VALUE? crash: the following code crashes too:


    x: bind make block! {error? try [any-type? get/any 'variable]} 'system
    do x

While playing with this REBOL I got a "** CRASH (should not happen)" 
 and spewed a bunch of garbage on the console.  Unfortunately I haven't 
been able to reproduce this.  I did get a screenshot of the console, 
 however, if you're interested...

get-face on a field with hide returns asterisks instead of the text.

I know, but the get-face accessor function is supposed to help newbies 
avoid having to know these differences

I just think get-face and set-face are not complete, e.g. AFAIK they 
only work properly on textfields, radio and checkboxes

I've been testing #3403. I can't get it to crash now in the latest 
beta

Graham: get-face on hidden fields is a know bug : http://www.rebol.net/cgi-bin/rambo.r?id=3445&

ups, sorry! Read to fast, it's clear-face not get-face :-/

so, we need to submit get-face as well then ?

yes that's execly what im doing ;-) i send a number to C it read 
n data from the pointer and then passes to rebol as a string the 
i use Romanos's wraper to cast that into a structure; but i get ocational 
crashes when reading fron a crazy pointer :-) i consider this a hack, 
but still may work ...

well realy the thing is... did you remember that windows sometimes 
adresses structures in window messages like lparam or wparam, so 
i get the nasty number, and i've to buil a structure back from this 
*pointer*,..... because i do drugs :-)

yes i know what you mean i put = in rebol and : in C also i get lots 
of sintax error mising semicolon.... wrapers stink

c has a verry strong type checking thats cool for some cross over 
plattaform but wen it comes to rebol interface you get mad ...

but using Rebol, you can't get this new url..  as you could using 
page: open http://www1.folha.uol.com.br/fsp/opiniao/fz1010200501.htm

RFC 2616
10.3.8 307 Temporary Redirect


   The requested resource resides temporarily under a different URI.

   Since the redirection MAY be altered on occasion, the client SHOULD

   continue to use the Request-URI for future requests.  This response

   is only cacheable if indicated by a Cache-Control or Expires header
   field.

   The temporary URI SHOULD be given by the Location field in the

   response. Unless the request method was HEAD, the entity of the

   response SHOULD contain a short hypertext note with a hyperlink to
   the new URI(s) , since many pre-HTTP/1.1 user agents do not

   understand the 307 status. Therefore, the note SHOULD contain the

   information necessary for a user to repeat the original request on
   the new URI.


   If the 307 status code is received in response to a request other

   than GET or HEAD, the user agent MUST NOT automatically redirect 
   the

   request unless it can be confirmed by the user, since this might
   change the conditions under which the request was issued.

(Not tested.)

>> code: second get in system/schemes/http/handler 'open
== [
    port/locals: make object! [list: copy [] headers: none]

    generic-proxy?: all [port/proxy/type = 'generic not none? por...
>> actions: select code [response-actions:]
== [
    100 continue-post
    200 success
    201 success
    204 success
    206 success
    300 forward
    301 forward
 ...
>> insert tail actions reduce [307 select actions 300]
== []

Integer operations:
- conversions between integers and binary and back
- bswap opcode for endian conversion

- picki and pokei, like pick and poke but for bytewise access to 
integers

- perhaps allow tuples to be treated like integers for opcode purposes, 
or to-tup/to-int for conversions between them
Word operations:
- set indirect for things like forall, 'a parameters, other uses

- for objects/contexts:  bind ["Bind a variable to a context" word! 
word!]
Struct operations:
- sets ["Set a field value of a struct" word! word! word!]
- gets ["Get a field value of a struct" word! word! word!]
- copys/changes or picks/pokes (see other group for details)

There was also some mention of a lack of orthogonality with get/set 
and copy/change (see group for details), but that may not be as important.

What about picki/pokei? I can see putting off struct access until 
structs are put into /Core independent of libraries, but since that 
has been promised it might be better to get support for them in while 
we can.

rebservices would probably be considered a major change, so maybe 
that won't get in until 1.4.0

; for example if you do the following improper statement of the alias 
function
alias print "blah"

'; you will get an error message but then after you get the error 
message you will see that it still created 'blah in system/words

Nope. I get a simple error.
>> load "():"
** Syntax Error: Invalid word-get -- :
** Near: (line 1) ():

nice! So we make networking layer better and better. Maybe then Gabriele 
will be able to get his Chord to work properly, as it uses UDP too?

I believe the new/unreviewed submissions have a temporary sequence 
number and it is negative.

Once the submission been checked manually and found not to be spam, 
it'll get a more permanent sequence number.

load/all is very useful if you are loading a block of values from 
a file, eg.

	1 2 3 "Bob"


and you don't want to code for the case where the file only has one 
value in it. For example, with a file containing a single value in 
it I get:

>> load %a.txt
== 1
>> load/all %a.txt
== [1]


but in all other cases (zero or more than one value), I always get 
a block. I asked about this ages ago and the answer at the time was 
that beginners expected to be able to "load" a value without worrying 
about unwanted block creation (and those who wanted it would use 
load/all).

Yes, it all seemed to make sense at the time SAVE/ALL and LOAD/ALL 
were implemented. I remember the discussions about it. But trying 
to get a consistent method for saving/loading my data the other night 
proved very confusing. I spent a couple of hours testing different 
cases and I still haven't finished thinking about the issue.

If I have to make a custom function to get consistent behaviour then 
I might as well just use WRITE. :-)

Well after the make I get errors.

Why don't I get back FALSE in the 2nd and 3rd case?

How about returning than either FALSE or NONE which every was hit? 
That makes sense to me. So I can ensure that my app returns FALSE 
and that this value is returned. But now I return FALSE and get back 
NONE.

I reported that the interpreter doesn't accept get-wrods startting 
with < (#3641)

get-words !!

Use and get-word:

>> same? 'a first use [:a] [['a]]
== true

Use and get-word:

>> same? 'a use [:a] ['a]
== true

I get 0 under OSX

Ladislav, while it nice to see APPLY being put on the front burner 
(RAMBO 3575), I have a problem with Carl's proposal. His examples 
clearly do not evaluate their function argument (like HELP or SOURCE), 
but this would prevent using APPLY with anonymous functions. It would 
be preferable to require the function to be specified with a get-word 
like this:
    f: func [a b] [a + b]
    a: [1 2]
    apply :f a

I remember that I was able to get the same issues using only VID, 
so GLayout was not the source cause... it was only amplifying a VID/View 
bug.

(its possible the 400MB GC slow-down is system specific, and people 
with newer/better machine with more ram will get the bottleneck further 
away.

not anymore... I'm not setup for this anymore... unfortunately, I 
don't have a lot of time tonight... I have to test cheyenne and start 
putting my web site back online in order to get slim, glayout and 
liquid  "out in the open".

One has to be careful reloading scripts in the same console multiple 
times as this will also eat up hundreds of MB's of memory. I'm sure 
that I'm doing something "wrong" in those scripts, but have no time 
to investigate what it is. I wanted to ask earlier on a memory usage 
group and that we don't have one. Wouldn't it be nice to get laid 
out what techniques are useful in order to converve memory? Maybe 
the experts can put in a word or two on that. View does indeed also 
eat lots of memory, as well as image creation with to-image.

rebolek, the process should be built -> tested -> done. if noone 
is testing, they never get to tested. :) (we eventually assume that 
no news means good news and mark them.)

#4124 "set-modes doesn't work on file directories" - maybe add a 
note to Paul here that "the filesystem may not support setting all 
of the modes that are gettable by get-modes. For instance you can't 
set modification-date, but you can set the owner-write flag." Maybe 
there should be a more informative access error type, not just "Cannot 
open ...".

I accidentally put a string in the font size, like this:

view layout [area font [size: "m"]]


Windows gives me a small font, which seems right. On OSX I either 
get screen trashing inside the text area, hanging or a segmentation 
fault.

Except that I don't get the error you get on the second example.

(again, just thinking out loud.. I am deep in my head resolving a 
get_username OS call, to get proper logon user on windows) hehe

REBOL is very old.  although R1 code might have been finished quickly, 
it tool many months to get view, draw, and other goodies.  and AFAIK 
Carl was not alone.  getting R3 at the level of R2 will definitely 
take time.  especially to a level where it is stable enough to be 
commercially viable.

btiffin ... I guess it's good to wrap an error handler around the 
whole program, and too often I don't. I just trap suspect areas, 
and then get caught when something happens in a region where I was 
not expecting the possibility of an error.

Is this a one fire mechanism?  When I do this, and get an error, 
and print it .. or whatever, and if I generate the same error again, 
it then drops to the standard error handler ignoring my error handler.

re #4143: as I mentioned elsewhere, I would prefer FIND/LITERAL or 
changed FIND/ONLY to get more expected result for datatypes

Rather than pushing for R3 inclusion, we should try to get revault 
up, and put things there. :-)

I get one row of cells, if I follow the syntax in the example docs

robert: the manual doesn't mention anything about || at the end of 
the line, which is why I couldn't get them working

Yes, the thing is to first agree on the markup to use. But we didn't 
make it to get the mentioned people to start working together towards 
one solution.

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?

My opinion is, we shold leave make-doc, bloggger and other topics 
for now, to get Carl's attraction where we really need it ;-) RIF, 
plug-ins, RebServices, Rebin,  AGG beta  are waiting in priority 
list :-)

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.

I was reacting to Geomol, just trying to clarify, not to your statement, 
Robert.  From RT perspective, Carl said he doesn't want to rewrite 
the thousands of documents already written.  I think for someone 
to get RT buy-in for new versions that RT would like, that is a major 
water test.

@Ashley

1) a <title> option for =table. Yes, I considered this. HTML has 
a caption option for tables and optional align (top|bottom). If align 
isn't there, it's up to the browser to deside. I found it a bit confusing, 
and by putting the title of the table yourself at the place, you 
want, you get the result as expected.

2) a right option for =image. Yes, good idea. I've also considered 
the situation, where text should go around images. But I haven't 
found a good way to specify that yet.

3) Is "/" needed in state off tags? Yes, I think so, because it's 
easier to understand, if you have e.g. several bolds after each other. 
Example:

This is some [b]text[/b], where there are [b]several examples [/b]of[b] 
bold[/b] words.
is easier to understand than:

This is some [b]text[b], where there are [b]several examples [b]of[b] 
bold[b] words.

Also if you make a style, that is bold, then you wan't to use [/b] 
to undo bold. Would be confusing, if you used [b] for that too.

It's difficult to judge finally, before I have a working formatter. 
Some things look good in theory, but fail in practical use. One thing 
is for sure, writers should be able to write anything, any combination 
of characters, and get the wanted output in an easy way.

The first pass generates a block structure that can be scanned by 
every emitter to get all headings etc. So, after scan-doc the info 
is there but not the build-up TOC.

Ammon sure and if we get a better featured widget engine I could 
make in it a flying dragon ;)

Graham her you get the patch for this proprlem that allows you to 
not redownload it :
add this code in config-pan: 

btn-cancel "Cancel" [
			either exists?  mdp-config-file [ 
				unview/only config-win 
				if not viewed? main-win [mdp-gui-init]

   ][ alert "It's my first run baby !! ^/ You need to fill properly 
   the config form !!!" ]
			
		]

graham for MD2 you get MD2IDE from ashley !!!

New version of NicomDoc is out. It's still not v.1.0, so things will 
change.


Specification: http://home.tiscali.dk/john.niclasen/nicomdoc/NicomDoc.html

Example: http://home.tiscali.dk/john.niclasen/nicomdoc/example.html

Example source: http://home.tiscali.dk/john.niclasen/nicomdoc/example.txt

Main script (this is the one, you should run. Works like makedoc2.r.): 
http://home.tiscali.dk/john.niclasen/nicomdoc/ndoc.r

NicomDoc to RebXML script: http://home.tiscali.dk/john.niclasen/nicomdoc/nicomdoc.r

RebXML to HTML 4.01 script: http://home.tiscali.dk/john.niclasen/nicomdoc/ndrebxml2html.r


Changes from previous version are: simpler tables, better magic mode 
(rich text), better handling of paragraph states like centered text 
(won't effect the inner of e.g. tables), better handling of faulty 
input, tables within tables, same with notes (not sure, if you could 
that in previous version) ... and probably some more, I can't remember.


You need atleast REBOL/Core 2.5.3, because of new break word within 
parse rules. So it won't work with official REBOL/View 1.2. Get a 
newer one!

I have not been watching this very close, so to get me up to speed....you 
are writing an emitter from Rebol to PS?

Well, the dialect doesn't take PS as input, it produces PS. A PS 
file can be printed from REBOL in a way, Graham showed. Like:
>> port: open/direct tcp://192.168.1.253:9100
>> insert port read %boys-0-36-length-weight.ps
>> close port


192.168.1.253 is the IP of the printer, 9100 is the port, where the 
printer get data.

Henrik, thanks, I will play with it.  I have this great Mac sitting 
on my desk, but I don't seem to use it enough.


NOTE: I'm still tied to my PC, and TRYING to get away....so far it 
seems I'm held to just a couple of issues....I have not had time 
to write up the "PC MAC LINUX" chart I want so I can figure out what 
it takes for me to move over.  But the first big one is still a thumbnailer. 
 I use ThumbPlus.  If they were on Mac and Linux, then I think the 
move would be a lot better.  I use this about 10 times every day. 
 We can move this chat if you want to engage me on the Mac issue.

Thinking of what John said, I suspect if you try and automate the 
newpath etc, you'll get into problems.

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

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.

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

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

to get the ps dialect matching the draw dialect, I need to make the 
text obey cr/lfs.

and where do you get the hint data from?  Is it read from the font 
somehow?

by inserting the code in postscript.r I can get the chars I want. 
works fine now, but you need to specify the fonts correctly from 
"HelveticaBold" to "HelveticaBold-ISOLatin1" instead.

Seems a bit complicated to get ISO-8859-1. What about other languages?

if I could test it... wasn't on my machine and I couldn't get console 
output

My aim is to get perfect postscript output .. and at least a rough 
approximation in draw.

TeX would have reshuffled the images around so that they wouldn't 
get cut in half.

yes, slow at zooming, but working .... will you be able to get any 
ps complicated doc be previewed in your viewer?

Some small progress .. I can now get floating text tables, and text 
that flows from one textbox on one page to the next page.  But not 
completely error free yet :(

Just got to get it working :)

looks like you need to parse AFM files to get the width information 
out of your font files to make proper font justification. so we need 
to build an AFM parser?

seems that it's not necessary, but I'm not sure when it's not necessary. 
there is a direct function to get the stringwidth precisely and through 
that create some simple PS code to center a string

Henrik, I haven't used postscript.r for anything other than test 
so far. We could upload it to the library with your additions. A 
problem then is, if the dialect change too much, and many has used 
it for real, it will maybe break their code. Another way forward 
would be, that you give me your extended postscript.r, and I upload 
it to my web-page, and we keep it there for now. When the dialect 
has evolved some more (, and we get rid of all the blocks, that I 
wrote about above), we can then upload it to the library.

postscript.r seems to work fine on HP printers, but I can't get it 
to work on certain OKI printers. guess the header needs some finetuning...

Very cool John! Now, if we can get a DisplayPostscript engine in 
R3....

but in a structure of 1 million how do i get from a -> z  quickly 
?

ah, my message did not get it thru :-) Is Carl's Concluding remarks 
following? Maybe a time for final questions?