AltME groups: search

So you have this process-port function, and you need ALSO to not 
have an extra variable. I would just write:
... copy port
close port

without calling some function to do it.

It does really untie a small knot there and I've bumped into that 
quite often. It was discussed heavily a year ago in the r3-alpha 
world and Carl wanted it in. I remember the discussion was mostly 
what to name it. :-)

I learned a program structure more than 20 years ago called "program 
95%". It's a structure, you use 95% of the time when programming 
COBOL (and probably also in most other langauges). Maybe the need 
for ALSO is related to how we structure our programs?

and you really want functions like that to be simple.

What is the overhead for calling a function compared to not call 
it? And by having the close down in a function mean, it may not be 
on the same level as the open, which may be seen as bad programming 
style.

Geomol: I wonder why you have a problem with 'also now. It was discussed 
on 10-Aug-2007 on r3-alpha in new-functions group - and you were 
one of the people who were in this discussion

John, consider if you have a local variable in a function.  Then 
calling also can clear that local variable.  This is what I use 'ALSO 
for the most and why it is way cool.

And why do you want to clear it? To save resources? But what then 
with the version, you return?

If you want to load more MP3s, it would be a good idea to reuse the 
same memory area. An example:

>> f: func [/local blk] [blk: []]   
>> a: f
== []
>> insert a 42
== []
>> a
== [42]
>> source f
f: func [/local blk][blk: [42]]
>> clear a
== []
>> source f
f: func [/local blk][blk: []]


You see, A and BLK inside F points to the same memory. Next time 
you call F, you can put some more stuff in BLK (read another MP3).

If you want to be able to completely remove BLK, I would do that 
using an object. Build the MP3 player as an object, instead of just 
a function. Makes sense?

Of if between loading mp3s you have other functions that are operating 
and you want to ensure that your keeping memory use at optimal levels?

Yes, I understand that. What I don't understand, is how you call 
these functions, and what does on with the data, you get returned 
from your function. Do you have code examples online, I can look 
at?

Using ALSO returns some data. If your code look like this:

mp3-data: load-mp3-function


and that load-mp3-function ends with an ALSO, setting the local var 
to none, you still have a full copy in mp3-data. Actually you end 
up having 2 copies for some time, until the garbage collector frees 
the local version. Later in your code, you need to set mp3-data to 
none to free to memory (which the garbage collector does). Now, is 
this how you use ALSO and why you need it?

Does my version work the same as yours beside the timeout?

newPread: func [URL] [read/binary URL]

And can the timeout be set somewhere in the system object?

It seems hard to use, it often result in using twice the memory, 
that people expect. And it might even lead to pad program structure.

unfortunatly the same story...
does anybody knows why a replace on the second and third also
changes the first letter?  ^JKSE = %5E/KSE and  ^IKSE = %5E-KSE
but ^MERV = %5EMERV and therefore okay.

	probe load replace/all  mold "^MERV" #^ "%5E"
	probe load replace/all  mold "^JKSE" #^ "%5E"
	probe load replace/all  mold "^IKSE" #^ "%5E"

any advise is highly appreciated...
tom

Paul, in your last example with copy, the q memory is released, and 
the string after copy remains. So this actually is a version with 
something gained. Now I have to think, if I would do it this way.

Well, ^I is a control-i.. and in vim, that inserts a tab.  ^- is 
the tab character in Rebol

Paul, I would probably do:

o: context [q: "blahblah" f: does [insert q "more blah" q]]


And my that have full control over q. It depends on the application, 
I guess.

Anyway, I can now see, how you use ALSO with ports. By using a function 
approach, you choose to copy the data out to some further external 
computation. And it's up to the user of the function to free the 
data, when finished. I would take an object approach and store the 
data in the object. Then external computation can work on the data 
in the object. I feel, it's confusing using ALSO, but maybe it's 
just me.

Where I see a potential problem with ALSO, is if you in a function 
load a local var with a huge amount of data, say 1GB. And then to 
release that data ends your function with:
also copy local-data local-data: none


At that moment between the two arguments to ALSO, you have 2 GB of 
data allocated. The first 1 GB is freed, when the garbage collector 
comes to it.

Geomol: [Izkata, about the timeout. It seems here, that when the 
open/binary returns, the data is immediately available, so the timeout 
has no effect. I'm on OS X, maybe it's different under windows?]

I'm on Ubuntu  ;)  but yeah, now that I think about it, that's true. 
 Originally it was written differently, and the error appeared to 
be on the copy.  I added it when mininova was timing out on certain 
requests due to high load - it seemed to make a difference then, 
but I don't know if it was coincidence or not.

Geomol, your last "potential problem with ALSO" is not exclusive 
to ALSO. It's a potential problem anywhere COPY is abused by a programmer 
not knowing what's going on.

The way to return the large amount of data and to release the local 
from it is of course like this:

	also local-data local-data: none

In the load-mp3-data function above, a large binary series is loaded 
and contents set to refer to it. The ALSO line returns the binary 
series and unsets CONTENTS so that it no longer refers to the binary 
series. The usage code below the function definition takes the return 
value (the binary series) and sets DATA to it.

So effectively the variable referencing the binary series has been 
switched with another one.

If the contents var is not unset and then the load-mp3 function is 
not anymre called.

Then, the garbage collector can't free the serie because it stays 
handled by the local var contents.

I wonder if that would help with the problem I had before when I 
was doing OCR on image data .. and kept getting crashes

I use ASLO in R2-Forward for that reason - that was the original 
reason ALSO was suggested. You don't need ALSO for that in R3 since 
the locals unset themselves in the new function context model, but 
it is useful for closing ports and changing directories back.

Closures are different though - a whole new context is created with 
each call, words and values both.

Unlikely, since most tail recursion optimizations require an optimizer, 
or at least a compiler. Manual access to the stack is a security 
hole (unless the language is Cat). Accept that REBOL has real loops 
and that imperative programming is more efficient in an interpreted 
language :)

REBOL 1 had tail-recursion optimizarion. REBOL 2 got rid of it on 
purpose, and got 30 times faster as a result :)

There were some other tricks that contributed, like getting rid of 
continuations and ELSE.

I remember back then we had Holger, Jeff, and Sterling.

and he too has moved on

I think you are thinking of Joe Marshall who worked on an early REBOL, 
and has been critical of his continuations being removed from later 
versions.
http://ll1.ai.mit.edu/marshall.html

So, to continue my quest to understand ALSO, I'm now at:
1) It's useful to set locals to none in R2 (if done right).
2) It's used to close ports.
3) It's used to change directories back.

And 1) isn't an issue in R3.

Gabriele, I wasn't very clear with my port example. I didn't mean 
a local word. I'll use your TAKE example. Let's say, we have this 
code:

take: func [block] [also last block remove back tail block]
...
item: take my-block


Have TAKE makes the code smaller, but is it more readable? You have 
to know exactly, what take does, but you have to with many words. 
And is it worth the overhead? Let's compare it to this code, that 
does the same:

item: last my-block
remove back tail my-block


The first version has the overhead of a function call and use of 
ALSO. The last version produce more code, if TAKE is used many times 
through the program. Let's look at a version of TAKE without use 
of ALSO:


take: [block /local item] [item: last block remove back tail block 
item]


This last version has a local word, item. To me, it seems like a 
tricky way to just save a local word. But maybe it's just me, that 
need to see this some more.

Because their is limited room in the registers and the stack is the 
likely place for those operations.

I assume it just used the registers and memory without the stack.

Geomol, "just save a local word" - this is very useful !  I think 
ALSO just might take a bit of getting used to. It's like many other 
Rebol functions that we are now familiar with and use without thinking 
of its internal variable use. Do you think LOOP and REPEAT should 
not exist because they can be implemented with WHILE and a temporary 
variable? I reckon they are so cool to have in the language, because 
they make the code cleaner.

Yes, I like LOOP and REPEAT! :-)

No, R2 doesn't use registers. The context assigned to the function 
is reused, with the value block switched out on recursion. The original 
(non-recursive) value block is left alone when the function returns, 
and set to nones on function entry. This is where the memory leaks 
come from: unintentionally persistent references to local variables. 
R2 actually does have a stack (it's a block), but it is used differently.


R3 just has a second context type that does stack-indirect word dereferencing. 
When the function starts a block of values is pushed on the task-local 
stack and the references to those values do an additional indirection 
to get the stack frame before getting the values - this is why function! 
word dereferencing is 28% slower than object! or closure! word dereferencing.


R2 has two context types: object! and system/words (an expandable 
object!). R3 also has two context types: it doesn't have R2-style 
object! contexts - all are expandable like system/words - but it 
does add the stack-indirect type.

And a third context type is needed for microthreads?

John, I would prefer micro-processes and messaging (like Erlang), 
but there is no third type yet.

Paul, I have no idea, but REBOL function calling doesn't use stdcall 
- it has its own mechanism (to support gc stack frames).

imho the first one should be reported in CC and fixed.

Of course not. I just try to figure out, what ALSO is, and how I 
can use it. Some of my comments are to figure out, if it's worth 
it.

And I'm concerned about complexity (like Carl blogged about lately). 
I don't want REBOL to go down the complex road. There are so many 
examples, where that will lead to. To me, one word less can be a 
good thing, but it depends, if it's really needed.

I'm a tool maker. I want my tools to be simple and functionel.

So, question.  I know rebol has difference, intersect, and union 
- but is there a subtract for sets built in?

:-) rebol stays fresh for YEARS.  I've been using it since the betas 
for first view, and I still discover new things now and then.  :-)

Ask, and you shall receive.  Knock and the door will be opened.  
Thanks, Paul!

I wrote: " --1:23 should be of type url!, shouldn't it?"

Actually, it's not a valid url according to the definition:
http://en.wikipedia.org/wiki/URI_scheme

The scheme name consists of a letter followed by any combination 
of letters, digits, and the plus (

+"), period ("."), or hyphen ("-") characters; and is terminated 
by a colon (":")."

So it should probably just be an invalid time.

I wanted it for debugging and reporting purposes.. btw so I could 
get messages and see from which object they come from

I believe that since the extra information can so easily get out 
of sync with reality, that it will just end up causing problems for 
you. Better to accept that there is no "reverse lookup" (not a quick 
one, anyway) of objects to words, and just adjust your debugging 
method somehow.

more timezone issues.  Switched clocks back last night as daylight 
savings ended.  now still says we are at +13:00 even though we are 
now +12:00 ... and my PC clock is correct.

well, if anyone is on Vista, and wants to try, just set your timezone 
to New Zealand and set to automatic daylight savings adjustment.

I have one which converts iso-8859-1 to html and escapes characters 
where necessary.

if you can wait for it (release does not depend on me), i have any-charset 
to utf-8 and utf-8 to html (and vice-versa, with support for all 
known named entities as well)

Thanks, Gabriele. I'll probably go ahead and try to build something 
for use in the Library system but will happily stop work when your 
code is released.

file permissions are set to 755 (rwxr-xr-x) and I am running them 
at superuser level

And you can't see that file with list-dir inside REBOL?

>list-dir ;after the file crashes...aha, I could see the files before 
doing the main.r.
main.r  main.r  


My scripts work fine on Windoze.  I am now thinking from this...I 
do a change-directory to get the directory of where I am running 
and I write my data into the current directory.  In Windoze, the 
change-directory seemed needed to pick up the directory I am in. 
 I'll bet 'nix doesn't like that, and perhaps needs the full pathnamem 
from the root, or soemthing like that.

Good if you got it figured out! Often it helps to talk to others. 
All the time, I see the problem myself, the second I start telling 
others about it. :-) And then I get the looks. :-D

All my testing had been on Windows until yesterday.  Once I got the 
permissions and encap logic straight, it ran, on Redhat (crazy network 
stuff) so there was no Unix/Windows differences I had to deal with 
in the code.

Local Disk

 and "Removable Disk" are made up by Explorer when the drives have 
 no names.

I'm trying to auto update an exe.

My code worked for script version buy with the encapped version it 
seems to buzz through without executing some statements...

write/binary %NEW.exe read/binary http://website/client.exe
delete %captain.exe
rename %NEW.exe %client.exe
notify "Update Complete!"
call/show %client.exe


IT seems to start up the client before the new one has been dowmloaded 
and renamed..

'delete calls 'remove. The question is, if that native really waits 
for the result, or just submits the call to OS layer and returns. 
Then, especially with crappy sloppy Windows FS you might get some 
delay ...

I thought that was the problem  (too much delay with OS cleaing up 
deletes and writes etc...) but the waits and alerts seem to be ignored

I would expect
clear buffer
to be faster and use less memory than
buffer: copy {}

And it seems to be so.

eFistAnt, Ladislav has some timing functions here: http://www.fm.tul.cz/~ladislav/rebol/timblk.r
I just use:

time: func [:f /local t][
    t: now/time/precise 
    do f 
    now/time/precise - t
]

And then time many loops of some code, like:

>> time [loop 10000 [buffer: copy {}]]
== 0:00:00.245122

I have a long series of fixed width and need to extract starting 
from a current position backwad/forward the x-th value.

use throw and catch I guess

You could try to convert one of your loops to a function and do something 
like this:

>> y: func [] [             
[    forever [                
[        i: i + 1                 
[        print i                  
[        if i > 3 [return [break]]
[        ]
[    ]
>> i: 0
== 0
>> forever [do y]                                               
1
2
3
4

Graham, catch and throw

The only thing that blocks numbers to become word! values is the 
lexical scanner. When you type anything in console (or DO a file 
script), your input is first a string! value that gets LOADed (that's 
where the lexical scanner raises errors). TO-WORD allows to bypass 
the LOAD phase and force the conversion of any symbol to word! value.

I agree, TO-WORD should enforce word! syntax rules on argument and 
raise syntax errors accordingly. That would be a more logical behavior. 
Maybe Carl had some design issues to workaround by allowing this 
(or maybe it's just an implementation flaw).

Geomol <funny or strange>

It gets odder ( or less consistent) as '+ does seem to be given special 
handing......

What I really wanted to do to solve the puzzle was:
    -- set to-word "2" 5
    -- set to-word "+" none
The block then becomes (in effect)
   do [5 none 5]
   == 5
      

But DOing the gimmicked block in R2 fell found of '+ being both a 
native and some hardwired syntax in the interpreter:

    set to-word "2" 5
    set to-word "+" none
    blk: copy []
    blk: reduce [to-word "2" to-word "+" to-word "2"]
    probe blk
        == [2 + 2]
    do blk
        ** Script Error: Invalid operator: +
        ** Near: 2 + 2

maybe some other func provides this and we're not thinking about 
it.

Seem I'm always wanting this functionality and would be a very useful 
upgrade.

there is something like filter function I think (or you can make 
one that takes values and expression)

I think its a good idea to ahve find like that (so that it gives 
subset) but expression would have to be a block so you can put any 
code inthere and things are systematic

but even extract creates a new series, we just want to change the 
offset, its much more efficient in all cases... and yess I would 
have used that VERY often.

like /skip, maybe the /compare refinement could become more generalized. 
 this would be a logical complement to the flat record concept which 
/skip enables... 


wrt SQL, in some cases /compare is used as a where clause, other 
times its the argument to TOP, somethimes its used as the ORDER-BY, 
its very symmetric and much simpler to have the same refinement for 
all of these IMHO

It's related to COLLECT and I suppose "GATHER".

do any of you rebol gurus see a way to do something like coroutines 
/ yield / generators with rebol - so far a lot was possible to be 
done in rebol on a library level because it can change it's own code 
and because primitives aren't really primitives, but I don't see 
how this could be done ( there is magical do/next but it would block 
until loop exits so for something like this example it won't work). 
I am not sure I know the exact definition of coroutines so I will 
give an simple fictional example.. 

...
retvieve-time: func [ node /local msg ] [ 
	send-message node "get-time"
	while [ not msg: get-waiting-message ] [ yield ]
	print [ "the time is" msg ]
]

append *processes* :retrieve-time
retrieve-time *timer-node*

forever [ foreach p *processes* [ continue p ] ]


Yield returns controll from function, and next time continue is function 
continues at that point. I know the example isn't technically correct 
(for example when function exits it should be flagged and cleared 
from *processes* etc) , but just for illustration what I am asking

I made progress with my simple actors library few weeks back  but 
I still ahvent found time to make a blogpost about it.. it works 
nicely without something like yield and probably even has few advantages, 
but I am interested if somehow this can be made on top of rebol too

in the detective, i had the same problem (but with network events 
coming). i just clear the wait list and show the inform. maybe you 
could also add a custom event func that filters events except for 
those regarding the popup.

Henrik, maybe it's better to patch wake-event, then, which gets the 
events before they are sent to the window.
	probe get in system/view 'wake-event
Trap errors during DO EVENT like this:

	if error? set/any 'err try [
		do event
	][
		; stop more events and handle the error
	]

Henrik, maybe you can post us a cut-down example which shows the 
double-error bug, and we can try to handle it the best way. Sounds 
like it would be a useful technique in general.

if error? program-error: try [
  view layout [
    h3 "Avoid the console from popping up"

    box 500x100 "Hold down left mouse button and drag to create errors" 
    feel [
      engage: func [face act evt] [
        if find [over away] probe act [
          2 / 0 ; error!
        ]
      ]
    ]
  ] do-events
] [
  ; what to do here to block the events from the view window?
  error-obj: disarm program-error
  inform layout [
    h3 "Program Error!"
    area 300x200 mold error-obj
    button "Close"
  ]
]

rebol [title: "scratch"] 
if error? program-error: try [
    view lay: layout [
        h3 "Avoid the console from popping up" 

        box 500x100 {Hold down left mouse button and drag to create errors} 
        feel [
            engage: func [face act evt] [
                print ["engage" face/text]
                if find [over away] probe act [
                    2 / 0
                ]
            ]
        ]
    ]
] [
    print "error" 
    insert-event-func func [face event] [
        print ["event-func" event/face/text event/type] 
        either same? lay event/face [
            prin "mjam" 
            none
        ] [
            event
        ]
    ] 
    error-obj: disarm program-error 
    inform layout [
        h3 "Program Error!" 
        area 300x200 mold error-obj 
        button "Close"
    ] 
    print "inform done"
]

error-window: layout [
	h3 "Program Error!"
	area 300x200
	button "Close" [hide-popup]
]

inform-on-error: func [code [block!]][
	if error? set/any 'error try code [
    	error-obj: disarm error
    	?? error-obj
		error-window/pane/2/text: rejoin [
			mold disarm error 
			now/time/precise
		]
    	either viewed? error-window [
    		; subsequent errors
    		show error-window
		][
			; first error
			
			print "INFORM"		
			;inform error-window
			; Emulate INFORM but without WAIT
			error-window/text: "Dialog"
			error-window/feel: make system/view/window-feel []
			show-popup center-face error-window
		]
	]
]

system/view/wake-event: func [
	port 
	/local event no-btn error ; <-- added 'error
] bind [
    event: pick port 1
    if none? event [

        if debug [print "Event port awoke, but no event was present."]
        return false
    ]
    either pop-face [

        if in pop-face/feel 'pop-detect [event: pop-face/feel/pop-detect 
        pop-face event]
        inform-on-error [do event]
        found? all [
            pop-face <> pick pop-list length? pop-list
            (pop-face: pick pop-list length? pop-list true)
        ]
    ] [
    	inform-on-error [do event]
        empty? screen-face/pane
    ]
] system/view

view/title layout [
	h3 "Avoid the console from popping up"

 box 500x100 "Hold down left mouse button and drag to create errors" 
 feel [
		engage: func [face action event] [
			print ["ENGAGE:" event/time event/type mold event/face/text]
			if find [over away] action [
				2 / 0 ; error!
			]
		]
	]
] "Main Window"

Actually, I don't see the benefit in making the error window a modal 
popup. What would be cool would be to have a gadget to show multiple 
error messages stacked on top of each other, with a couple of arrow 
buttons to cycle through them and a button to discard the currently 
viewed one.

The goal of the error capture is to provide end users a means of 
reporting bugs to me over the internet in a uniform manner. Having 
them read me console output over the phone just doesn't work.

To reach that goal I defined some rules:


1. The user must know what is going on when that window is popping 
up. Therefore it has to be very simple and clear that the program 
they were working in, has failed.

2. When I use the program, the error window must be useful to me 
as well, so I output the error object in that window.

3. The error window must pop up in front of the other windows and 
be modal. I've had way too many user cases with hidden new windows 
to great confusion of users. That's why I use an INFORM.

4. The program must stop dead in its tracks, because of two things:

4.1. The program saves to disk very often. If the program continues 
operating despite this error, there could be a risk of data corruption, 
which could be saved to disk, overwriting good data.

4.2. If the program crashes during receiving events from a moving 
mouse, the error log would become very big in no time, if the logging 
functions are triggered because of this mouse movement. It's important 
to see the first point where it breaks.

I've got all bits working except the event blocking part.

There isnt much different to plain faces. There is a block /init 
which is called after all arguments are loaded by 'layout. Arguments 
are put in the appropriate facets, if there are some of the same 
type, they are put in a block instead. so two colors go into /colors. 
There is some magic with keywords, which needs more space to explain. 
but for quick things you can pass args in 'with. Styles have their 
own source in /facets, so you can look there. Best with deskop/tools/vid-style-tree. 
Start fresh things with 'image or 'box,  examine things by with[probe 
self]. The rest is the same as plain faces, and there are some docs 
now.

Henrik, are you wondering what stylize/master does or how to use 
it ? Or are you looking more for a style-creation guide ?


Usage of stylize/master itself is pretty simple, it takes a style 
spec and adds the new styles in it to system/view/vid/vid-styles, 
where all the default styles are kept, eg:
	stylize/master [my-box: box blue "hello"]
	view layout [my-box]


I often felt the need for an official document explaining all the 
things a style should satisfy to be "VID-compliant" and explaining 
each facet in detail, where and how facets are used by existing styles. 
But no such doc exists. I've been growing a pile of demos and text 
documents as I discover things.

If I am calling (loading) a layout  from web server script  with 
http://someurl?some=cgivarsand then displaying, than I cannot it 
unview:

								info-resp: read browseUrl
								reduce load info-resp

								either viewed? infowin [
									unview infowin ;Does not work!?
									view/options/title/new infowin [all-over] "Info:"
								][
									view/options/title/new infowin [all-over] "Info:"
								]

F.ex. I want that there does not appear  new windows. But I need 
to use /new refinement, because I need possibility for user to go 
back (activate) on another window.
Is it connected with Rebol scopes?
And how to avoid new window?

Ok, there is confusion between the layout spec block and the resulting 
window face.
A pattern I use very often:

infospec: [ area button ... ] 
infowin: layout infospec

either viewed? infowin [
	; bring the window to the front (or do the taskbar flash thing)
	infowin/changes: [restore activate]
	show infowin
][
	view/new infowin
]

Ok, so remote script looks like:
--------------------------
rebol []
info-win: layout [ ...]
--------------------------
Local script looks like:
--------------------------
rebol []
info-win: do remote-script-url
; Now info-win is a FACE object

; Only do the above line once, otherwise you will create a *new* 
face and set 'info-win to it, forgetting the old one !!

; The following code is done more than once:

either viewed? info-win [
	info-win/changes: [restore activate]
	show info-win
][
	view/new info-win
]

So, did I got idea right:
The remote script is treated as new scope.

Note: In may cases there are some differences remote script is without 
rebol header and is loaded with "reduce load"

There is no "scope" in rebol. When you read from a url, you create 
a new string. That is, READ returns a new string.

When you set a word to that new string, you "switch" the word away 
from its old value (if it had one.) Eg:


 At the beginning of this example, the word  'info-resp  has no value 
 (It is unset!).
	Now, we set its value to the string returned by READ:

		info-resp: read url

	Now,  'info-resp  points to a string  "[ text ... ]"
	Let's do it again:

		info-resp: read url


 We have re-set  'info-resp  to a new string!  (even though old string 
 and new string look exactly same.)

 The old string may still exist as a value somewhere, but  'info-resp 
  does not know about it anymore.
	Normally this is not a problem.
--
	However, look at this example:
	
	1)	window: layout [box red]
	2)	view/new window
	3)	window: layout [box red]
	4)	unview/only window


 On line 1, LAYOUT creates a face object which we assign to the word 
  'window . (So  'window  points to a face.)
	On line 2, VIEW opens the value of  'window  as a window.

 On line 3, LAYOUT creates a *new* face object which we assign to 
 the word  'window.

  So  'window  points to a *new* face, and it has forgotten about the 
  old face.
		However, the old face is **still open as a window**.

  So we have lost our reference to the old window face, and it is now 
  more difficult for us to close it.
		So line 3 has created a problem.

 On line 4, we try to close the new window face, but we are unsuccessful 
 because the new window face is not open.