AltME groups: search

My save-vars just pushes the temp variable values onto a stack, and 
restore-vars pops them.

The use operation above would be a good semantic model for parse 
rule closures with recursion-safe temporaries. Imagine a new datatype 
called rule!, a parse rule block bundled with a recursion-safe context 
for local variables. You would create one with a mezzanine like this:


parse-rule: func [locals [block!] rule [block!]] [make rule! reduce 
[locals rule]]


It would be the equivalent of a function made by the HAS mezzanine 
- local variables, no parameters. The rule would be prebound to the 
context and the context would be fixed up on recursion just like 
function contexts are. Any time parse would accept a rule block! 
it would also accept a rule! value.

Using a stack as I have is faster, because we are not creating new 
objects (or values if they are the same), but it's not quite as elegant 
as your parse-rule above.

The trick is the addition of a new data type. It would allow the 
context to be fixed up internally. The rule! datatype would be a 
lot faster than even your stack model, and safer too. The use operation 
above would be a lot slower than your stacks though.

Gabriele's need to delimit the rules with '| brings up another old 
mezzanine thought: rejoin/with. I created a separate mezz, called 
DELIMIT, but this is a fairly common need IME. Should we start another 
ML thread? :-)

start another RAMBO thread :-) ... add it as a wish - I think it 
is the only channel RT actually scans, but of course not sure ...

Brian, yes, that's because earlier i had :mk2 after the paren, but 
I changed it to :mk1 because it's faster when you want to iteratively 
apply a rule.

The match functiion has a line
    parse block recurse
near the end that should be
    parse data recurse

Here is a suggestion for match - add /any and /case refinements like 
the parse refinements, and then change the line:
    parse data recurse
to this line, indented properly if needed:

    do pick pick [[parse parse/case] [parse/all parse/all/case]] none? 
    all none? case data recurse


It's the quickest way to pass along refinements I've figured out 
yet, short of rebcode apply.

Once rebcode is in REBOL, it would be a quicker way to implement 
match. That apply operation is nice.

After going nuts for some while now, I'll ask the community maybe 
someoe has a good tip for me:

I need an application that can do two things with more than 2 persons 
at the same time:
- video conferencing

- application sharing (or at least having one exporting his desktop 
to a number of users)


I thought that netmeeting might be good but it's quite old and doesn't 
seem to be further developed.

Who should use UltraVNC?


Anyone who needs to support local or remote Windows users will find 
UltraVNC a must-have tool. It was specifically designed to answer 
the needs of:

    * Help desk (Internal & External)
    * IT departments

    * Home users that wants to help their relatives and friends or access 
    their home PC from work or cybercafés

skype can only handle 1:1 video conferencing and I din't find a good 
app-sharing module yet.

I have finde some stuff:
- MS Research portrait (not tested)

- ivisit (seems to be a cool approach, P2P based, interesting app-sharing 
concept: just define an area of your screen to share)
- feestoon (skype plugin, not yet tested)
- good old netmeeting

Need a second pair of eyes to review some code...

Anyone done any work on rebol and LDAP?  Only stuff I've seen is 
the first couple hits on google such as http://softinnov.org/rebol/ldap.shtml
that haven't been updated in a long while

Yes, Qtask Enterprise is designed to be dropped right into a server 
farm and start working.  We are working on WebDAV soon as well.

So it's good to hear that you have developed a REBOL LDAP interface 
for QTask

If there is anyone like myself who just scratched their head and 
said what in the blazes is LDAP? http://raleigh.pm.org/ldap-talk.html
 is a nicely done   page. Of course now I want it!

The softinnov link to the LDAP solution above might be the wrong 
one ... I think you want to look at http://softinnov.org/rebol/ntlm.shtml
instead i.e. how does a rebol script authenticate in the microsoft 
nltm world ... which uses ActiveDirectory.   NTLM has been rebranded 
as Integrated Windows Authentication.   

These links may also be useful 

http://en.wikipedia.org/wiki/LDAP
http://en.wikipedia.org/wiki/NTLM


My view is that without easy NTLM support we will be very handicapped 
using rebol scripts ....


If running a REBOL script as CGI under IIS, the user information 
is available in the script after IIS has taken care of the challenge. 
 Such support is not available (AFAIK) in Xitami and many other servers.

there was a ML group, but  I don't see it, has it been deleted?

ah, i see the messages went thru. so maybe it was a temporary problem.

must be your email playing up again Ladislav .. it did this a couple 
of years ago as I remember

hmm, there might be some misconfiguration on your provider's side, 
and hence your mail being regarded a spam for e.g.?

Using found? select .. can be problem anyway as the selected value 
can be 'none (you found 'none) :-)) I'm not using found? much often 
i prefere none? and not none? (found? is a shortcut anyway)

>> to logic! select [a b 0] 'b
== false

maybe someone subscribed to the list is bouncing? although the error 
message refers to a mail loop.

select reduce [1 none] 1 is the same problem as pick reduce [none] 
1 and so on... the problem with switch can be considered a bug, however 
switch expects a block after the value so this is debatable.

switch expects a block after the value so this is debatable.
 - how about switch/default 1 [1 #[none]] [2] then?

sorry, forget about it, I just want to say, that SWITCH doesn't check 
the value is followed by a block

yes, i agree it's a problem, it's just not a problem in practice 
:)

a possible implementation:

switch1: func [
    "Selects a choice and evaluates what follows it."
    [throw]
    value "Value to search for."
    cases [block!] "Block of cases to search."
    /default case [block!] "Default case if no others are found."
    /local blk
][
	value: find cases value
	if value [value: find next value block!]
    either value [do first value] [if default [do case]]
]

I like that behaviour. I planned to write something similar for a 
long time... :)

How much effort is a switch in c?

switch2: func [

    "Selects a choice and evaluates the first block that follows it."
    [throw]
    value "Value to search for."
    cases [block!] "Block of cases to search."
    /default case [block!] "Default case if no others are found."
    /local rule
][
	rule: [
		1 1 () ; <-- value
		to block! set value block! (return do value) 
		to end
		| skip to () ; <-- type? value
	]
	rule/3: value
	change back tail rule type? value
	any [
		parse cases [some rule]
		do case
	]
]

;test
repeat n 10 [
	print [
		n

  switch2/default n [2 4 6 ['even] 1 3 5 ['odd]] [mold "--default--"]
	]
]
switch2 1 []
switch2/default 1 [] ["--default--"]

I think it's fixed, but I'm also working on a version which evaluates 
the action block for every value and following block found.

switch2: func [

    "Selects a choice and evaluates the first block that follows it."
    [throw]
    value "Value to search for."
    cases [block!] "Block of cases to search."
    /default case [block!] "Default case if no others are found."
    /local rule
][
	rule: [
		1 1 () ; <-- value
		to block! set case block! ; <- re-use the 'case variable
		to end
		| skip to () ; <-- type? value
	]
	rule/3: value
	change back tail rule type? value
	parse cases [some rule]
	do case
]

{switch2: func [

    "Selects a choice and evaluates the first block that follows it. 
    This occurs for every matching value and following block found."
    [throw]
    value "Value to search for."
    cases [block!] "Block of cases to search."
    /default case [block!] "Default case if no others are found."
    /local rule
][
	rule: [
		1 1 () ; <-- value

  to block! set case block! (case: do case) ; <- re-use the 'case variable, 
  twice...
		| [skip to ()] ; <-- type? value
		| skip
	]
	rule/3: value
	rule/11/3: type? value
	any [
		all [
			parse cases [some rule]
			case
		]
		do case
	]
]}

;test
repeat n 10 [
	print [
		n

  switch2/default n [2 4 6 ['even] 1 3 5 ['odd]] [mold "--default--"]
	]
]
switch2 1 []
switch2/default 1 [] [probe "--default, ok--"]
switch2 1 [1 [probe "ok"]]
switch2 2 [1 [probe "bad"]]
switch2 1 [1 2 [probe "ok"]]
switch2 2 [1 2 [probe "ok"]]
switch2 3 [1 2 [probe "bad"]]

; multiple action blocks
switch2 1 [1 2 [probe "ok"] 1 3 4 [probe "ok#2"]] ; <-- 
switch2 2 [1 2 [probe "ok"] 1 3 4 [probe "bad"]]
switch2 3 [1 2 [probe "bad"] 1 3 4 [probe "ok"]]
switch2 4 [1 2 [probe "bad"] 1 3 4 [probe "ok"]]
switch2 5 [1 2 [probe "bad"] 1 3 4 [probe "bad"]]


switch2/default 5 [1 2 [probe "bad"] 1 3 4 [probe "bad"]] [probe 
"--default, ok--"]

Ladislav. Hmm.. that's a bit disappointing, although understandable. 
It's a complex parse rule with some time spent in setup.

I'm enamoured with the multiple action block version, so I'll see 
if I can make a nice FIND-based version of that.

Uncomment my second switch2 and have a look at the first test under 
"multiple action blocks".

it would be interesting to know how many users would want this feature 
- I am afraid it can help to hide a programming error

I have a small problem regarding event handling in TOOLBAR: Each 
icon consists of an icon frame face with a pane that contains the 
icon image and a text face.


The icon frame face has an ENGAGE event set for highlighting, doing 
the action of the button, etc. The containing faces both have their 
feel set to NONE.


Now when clicking on either the text and the image, the event seems 
to correctly bubble up to the icon-frame face, but OVER and AWAY 
events correspond to the face in which the event occurs, which can 
be for example the text face. So if you click on the text face and 
then drag away, the click is no longer valid, even if the mouse is 
still over the icon-frame face, because it detects OVER and AWAY 
for the face, I'm clicking and not the parent face.


This causes some clicks to be lost if you are clicking at the edge 
of the text face and accidentally moving the mouse away from the 
text face, say, the space between the icon and the text which is 
a natural place to click.


I've tried using DETECT, but this is greatly inefficient, because 
it processes all events.


I've noticed that the standard ICON face in VID behaves the same 
way. which I think is incorrect. Is there a way to transfer OVER 
and AWAY information from the parent face?

You're right, that's a confusing aspect of over and away events in 
the engage function.

I am quite positive I solved this before using a combination of feels 
somehow....

Have a play with that and see if you can capture all the state changes 
you need.

making it possible to see where an OVER or AWAY came from would make 
this a whole lot easier.

Are you sure you need subfaces ? Is the text really essential as 
a separate face ? You might avoid all this confusion with feels by 
using a single face, which can show both an image and text natively, 
or use the draw dialect.

(I suspect you are aiming for a simple specification using existing 
VID styles icon and text. Is that true?)

I've just been doing that whilst making a tab-bar the last couple 
of days.

I've redone some feel code so it responds much better now, but there 
are still problems. this is a different problem now with being unable 
to use the 'over function to determine whether the mouse is over 
the icon frame or not while the left mouse button is pressed.

so if you are clicking on top of the icon frame and move the mouse 
away, you can't cancel a click.

The question I tried to answer for a long time was "how do I know 
if the mouse is in this rectangle or not ?"

hmm.. that would mean the main toolbar might need a feel as well. 
this is getting messy.

don't worry, just filter it using a state flag.

I'm quitting... it works a tiny bit better than before, but it's 
still odd. Don't wiggle the mouse too much while pressing the button 
:-)

Changed it to a combination of detect and engage. I think it's working 
now (crossing all my limbs, fingers and toes)

DId not read the thread, only the problem. The trick is to put a 
transparent face over all the others, 'sensor in vid. Then you dont 
get  clicks in your faces, but all is nicely captured by the sensor.

Means put a full-sized face at the end of face/pane

the detect thing seems to work fine and it shaves off 33% of the 
needed faces. :-) thanks for your help


Anton, the event program is a great demo. don't you want to put it 
some where more visible?

Quick question, how do you force a resize event?

Do you to inject a resize event into View's event handler?

Isn't a resize event without a resize just a repaint?

Yes, to-image always produces a new image. There's no way to render 
into an existing image, as far as I know. (Would like that.)

because I have quite a lot of variables

well the thing is how variables are initialized when doing an object. 
I've discussed this before, but it would be nice to keep the list 
shown at the top of that example in the docs as a dynamic list. this 
prevents me from having to maintain that list and the layout words 
when doing changes. I guess I need to approach how to make the object 
block differently.

well, that's a local variable alright, but this is for an object. 
I think I have a different solution though, so I think you should 
wait with wasting more time on it.

I know what I want :-) I just need to find out a solid way to solve 
the problem permanently

the way I see it, I need to create the object block with layout blocks 
first. then analyze those layout blocks for set words and finally 
create a new block with the set words set to none and append the 
object block afterwards

CFOR function does it for a block, LFUNC does it for a function, 
it is quite easy actually

Lad, when you shadow a variable how do you access the top level one? 
In the CFOR example i showdows any system i.

I am using e.g. use [a] [print system/words/a]

Anyone remember a way to change the appearance of the caret ?

I've figured out a way to avoid showing the caret for you custom 
styles. It requires patching FOCUS and using insert-event-func to 
install a handler that sends key events to the focal-face when there 
is no caret.  (DO EVENT won't do that, so we have to.)
See http://anton.wildit.net.au/rebol/patch/focus-system-patch.r

I'm getting hard crashes when closing an 'inform window sometimes. 
If I change the windows to view/new they no longer happen, but I 
lose the always-on-top functionality.


I was wondering if anyone has experienced similar crashes and know 
a precise cause? Perhaps some events are blocked?

It's a little difficult, because it's a rather big VID application, 
but it happens very often and always when the window is closed. Unfortunately 
I can't spread this app. I can't reproduce it accurately every time, 
but it seems that a certain amount of keyboard input in that window 
must be involved before it happens.

Anton, I simply click the close button [X] on the window.

Also when you use "hide-popup"? Else maybe the auto-close has a bug, 
does a 'unview only?

haven't tested with that yet. I have a custom event function for 
closing the main window:

insert-event-func func [face event] [
  if event/type = 'resize [
    help-window-resize
    main-resize
  ]
  either event/type = 'close [
    either event/face/text = main-window-title [
      if request/confirm "Afslut programmet?" [quit event]
    ][
      event
    ]
  ][
    event
  ]
]

hmm... this is something that goes on in my toolbar code, so it should 
not happen with VID in general. it's still a strange error however. 
a face simply disappears from a PANE block :-)

does SHOW set the parent-face automatically in subfaces of a pane?

it's when I do a SHOW on the toolbar that it crashes, but I'm still 
miles away from what exactly is going on...

Actually, the opposite can be a problem - expecting parent-face to 
be set before the face has been SHOWed. eg. you have LAYOUT a window, 
but not VIEWed it yet.

that would just cause a crash to console, wouldn't it?

trying to create a separate applicaton and torture toolbar that way. 
it happens if I update toolbar and recreate its contents exactly 
19 times.

uhmm... not sure about weirdest :-) but I build the toolbar layout 
from a block that is parsed, appending faces and their attributes 
as it gets parsed. when that's done, I show it..

can't remember if it's the latest version... it has a few extras

I would make a "debug" copy of the complex application, then cut 
out chunks until the bug no longer appears.

but I'm not sure about the relation between that inform and a toolbar 
update.

Just looking at the toolbar code, I suspect the DRAW dialect, perhaps 
it is the use of FILL-PEN LINEAR ? I seem to remember a bug there...

Well, the best idea is to start with a copy of the full app, as I 
suggested above. I've done the same thing as you, trying to track 
down bugs, trying to guess what it is.

Ok, so my first guess has removed a small amount of code. (wouldn't 
it be better if it was 50% of the code ? :-)

the thing is, what if it's a buffer overflow? that will be really 
hard to fix, because you might run into the bug randomly.

It could be. But never miss a chance to find a deterministic View 
bug. :)

err... that's if a 100x100 bitmap is allocated for each of them..

is this just a recursive crash ?

does anyone have a fix for SCROLLER, so that scroller buttons don't 
move the scroller only one pixel at a time when the scrollbar is 
only slightly smaller than max size?

I've studied the problem now, and it's the same algorithm as I use 
in LIST-VIEW, but it's defective and causes the scroller only to 
move 1-2 pixels at a time, when the list is only slightly larger 
than the visible area. I found a different solution which was not 
to trust the step at all and use LIST-VIEW's own function to move 
the list and scroller separately, i.e. the list position is not derived 
from the scroller anymore.

I found an interesting scenario, that I'd like to know if it will 
be possible to fix. Maybe it's the wrong approach, but here goes:


I've wrapped an entire app in a TRY. Theoretically, then if the app 
crashes to console, it will be handled and the error disarmed. The 
error object is then sent to an INFORM window which displays a nice 
crash requester which offers you to send an error log and a description 
of what you were doing at the time of the crash to me via the internet.


This works fine for the most cases, but I noticed an error that was 
caused during a mouse drag operation. When dragging, the requester 
will pop up, but events are still flowing in the window that caused 
the error. When I release the mouse button, it then crashes one more 
time and this time brings up the console, ruining the purpose of 
my nice crash requester.


What should have happened was that the INFORM window should have 
blocked all events from other windows, so the application would stop 
to a controlled state. Is there a way to block events like this or 
is there another way around this?

is there a guarantee that it will eventually return none?

well.... by using a VIEW instead of INFORM, the window which catches 
the events is closed thereby not bringing up the console. it looks 
rather abrupt, but better than nothing.