AltME groups: search

I'm not sure if this helps but I sometimes make a wrapper function 
which calls the actual recursive function. The wrapper could take 
the refinements and set some flags in a context shared by all calls 
to the inner recursion function.

Seriously though, it should be simple to just write a loop that flags 
all scripts in a directory that have missing or incorrect File: headers.

I don't know what the port flags or the port/state/misc counters 
are used for.

There's no official way. I think DocKimbel had a value in flags or 
state that he said worked. If he doesn't jump in, I'll dig for it.

For checking if a port! value is "opened", you can use this function 
: open?: func [port][zero? port/state/flags and 1024]. But that just 
checks for the "close" flag, it doesn't check the real TCP connection 
state.

Hmmn, I am running a script, but not as CGI, on a remote 'nix box. 
 This script uses other scripts by 'do


The main script runs, but at the first use of parse rules from a 
do script, it fails.  Is there a magic setting of usage flags or 
file permissions to accomplish this?

$rebol -s main.r

runs main, but doesn't do the do %blah.r script from inside

>> flags: []
== []
>> swap flags 'resize
== true
>> flags
== [resize]
>> swap flags 'maximize
== true
>> flags
== [resize maximize]
>> swap flags 'resize
== false
>> flags
== [maximize]

ALTER is still in R3, though its usefulness is so limited it may 
be moved to R3/Plus. The enhanced logic flags that were supposed 
to replace it were removed in the latest release - they were never 
refined or documented to the point of being useful.

I guess additional refinements to a function as fundamental as INSERT 
are a no-go for performance reasons. Probably ALTER/INSERT or ALTER/ONCE 
though:

	>> alter/once [] flag
	== [flag]
	>> alter/once [flag] flag
	== [flag]


See the dance REBOL/View's FLAG-FACE is doing to achieve something 
like that (and a little bit more):

	flag-face: func [
	    "Sets a flag in a VID face."
	    face [object!]
	    'flag
	][
	    if none? face/flags [face/flags: copy [flags]]

     if not find face/flags 'flags [face/flags: copy face/flags insert 
     face/flags 'flags]
	    append face/flags flag
	]

Yeah, it is a common idiom. But some symmetry to REMOVE FIND FLAGS 
FLAG would be nice, and I don't expect Carl or anyone to be willing 
to replace REMOVE FIND by another native or mezzanine. That wouldn't 
be worth it.

For now, I've decided to go with 

	>> union package/changes [weight]
	>> exclude package/changes [address]

since speed is really nothing to worry about in my case now.

The new or changed mezzanines in R2 2.7.7+ that use the lit-word 
calling convention explicitly evaluate parens to be more like the 
R3 version of the functions. However, since the evaluation is explicit 
within the function rather than performed by DO at the call location, 
op! evaluation isn't triggered:
>> a (w) + 2
** Script Error: Cannot use add on paren! value
** Where: halt-view
** Near: a (w) + 2


Since the lit-word calling convention is only really appropriate 
for functions that act like syntax (like FOR), interactive functions 
that work on files (like CD) or functions that use word values as 
flags (like SECURE), they are never used with functions that take 
as arguments the types of values that are returned by op! expressions 
(numbers, binaries, true or false). So this is never an issue in 
practice, only in bad code that should never work.

Not that I've noticed, but I seem to recall that VID flags is what 
ALTER was originally for.

REBOL []

do %../library-dialect/lib-dialect.r

make-routines [
    lib %kernel32.dll
    def-rtn-type long
    ; returns available drive flags as a bitset (in a long)
    get-logical-drives "GetLogicalDrives"
    get-logical-drive-strings "GetLogicalDriveStringsA" [
        buff-len [integer!]
        buffer   [string!]
    ]
    get-drive-type [drive [string!]] "GetDriveTypeA"
]


drive-types: [
    Unknown     ; 0 We don't know what kind of drive it is
    NoRootDir   ; 1 Probably not a valid drive if there's no
                ;   root directory
    Removable   ; 2 It's a removable drive
    Fixed       ; 3 It's a fixed disk
    Remote      ; 4 It's out there on the network somewhere
    CDROM       ; 5 It's a CD ROM drive
    RAMDisk     ; 6 It's not a real drive, but a RAM drive.
]

drive-type?: func [drive /word /local res] [
    res: get-drive-type join first trim/with form drive "/" ":"
    either word [pick drive-types add res 1] [res]
]

get-drive-strings: func [
    /trim "Return only the drive letters, no extra chars"
    /local len buff res
][

    ; Call it once, with 0, to find out how much space we need in our 
    buffer
    len: get-logical-drive-strings 0 "^@"
    ; Init our buffer to the required length
    buff: head insert/dup copy "" #"^@" len
    ; Make the call for real, to get the data
    len: get-logical-drive-strings length? buff buff
    res: parse/all copy/part buff len "^@"
    if trim [foreach item res [clear at item 2]]
    res
]

;print enbase/base to binary! get-logical-drives 2
foreach id [a b "C" 'c "D" d: %E %F %/F] [
    print [mold :id tab drive-type? :id tab drive-type?/word :id]
]
print mold get-drive-strings
print mold get-drive-strings/trim
print read %/

a lot of the APIs have changed in Windows vista/7 (not sure about 
Clipboard).  

the kind of changes I would expect...  if its not using the latest 
apis, newer features in the OS could simply be preventing REBOL from 
accessing this device.

just like how these new OS prevent you from writing within the program 
files folders.


some things which had defaults, maybe now require explicit flags... 
etc...

Pekr, then they would work as flags. You should be able to access 
from within the code block, which qualifier keys are pressed. Binding 
the code automatically to the feel object would let you access the 
variables and events in the feel object.

yes, setting flags .... nice ...

1. You have direct event handling with on-XYZ [do-program-code]

2. Then you have dynamic flags for, say, qualifier keys inside that 
program code, from the event system

3. Then you have face flags. Some things like size limiting a field 
should be simple. It can _probably_ be mapped to 1.

Experts;  What are the implications of removing  on-unfocus  from 
a face's flags block?  It has to do with a login panel firing on 
Enter (only) for the password field with a login button and some 
other fields that can cause an unfocus of the password (which by 
default fires the action...which can be inappropriate).

It's ON-UNFOCUS in face flags.  Compare:
	view layout [f: field [print "action"] text-list]
	print mold f/flags

 view layout [f: field [print "action"] with [deflag-face self on-unfocus] 
 text-list]
	print mold f/flags

alternately I would add a single redraw check at the top level and 
scan children for a 'lock value in a predefined field / flags.

the alternative is to use global values / flags. the modal (popup) 
system in VID does exactly that.

its possible that the window stores its active state in the flags 
block, if this is the case could also tl

OK, but you wouldn't need NO-CASE to end a CASE. It would be another 
modifier, not a mode. Modes like that don't work with backtracking 
very well. So it would be like this:
	case ["a" no-case "b" "c"]
not like this:
	case "a" no-case "b" case "c" no-case
The two directives would be implemented as flags, like NOT.

yes, i get event/key: #"^-" and event/flags: [control]

In theory the new logic! for R3 will solve the same problem that 
EVALS solves, but logic! flags doesn't work too well yet.

SAME? meaning same bits should include the type flags too - otherwise 
same bits is meaningless or cooincidental.

Hmm, more on evoke:

>> evoke '?
Flags: crash-dump delect watch-recycle watch-obj-copy crash

ooops ...

19/9-23:06:04.537-## Error in [OS-API] : OpenSCManager failed : Access 
is denied. !
19/9-23:06:04.539-[boot] Cmdline args : -vvv
19/9-23:06:04.540-[boot] Processed    : [verbosity 4]
19/9-23:06:04.541-[boot] Boot flags   : [no-screen verbose]
19/9-23:06:04.542-[boot] Data folder  : %./
19/9-23:06:04.545-[uniserve] Async Protocol FastCGI loaded
19/9-23:06:04.546-[uniserve] Async Protocol SMTP loaded
19/9-23:06:04.577-## Error in [dig] : DNS server not found !

Cheyenne binaries are encapped with [secure none] header to avoid 
such issues. I wonder if the LAUNCH native used to fork worker processes 
is correctly transmitting boot flags to child processes.

and no exec flags either

svn can only assign exec flags in a post-hook, right?

I'm getting a *very* weird problem launching cheyenne from win7.


using a clean download of the latest build sources, if I try to start 
up the cheyenne.r by double-clicking on it in windows, it fails. 
 

no tray icon appears, the rebol process is running buts its dead 
(no pages are served, and no workers are launched).


if I try to run it a second time, I get the console which tells me 
it can't open the rconsole and logger ports (so cheyenne actually 
did start)., but the "no response" flag appears on the window title 
and its as dead as the first instance (I even get the busy mouse 
cursor treatment). 


but if I start it from the command-line, using the exact same command-line 
that I see in the task manager, I have no problem!


to make this even more strange, dragging the cheyenne.r script icon 
on the rebol.exe icon, launches cheyenne without any issues!

launching it from my editor's automated script launching setups also 
works without issues.

all of these show the exact same command-line in the task-manager 
(which includes the -qs rebol flags).

note, I am *not* running cheyenne as a service.

Questions:
1) can any one else replicate this (am I going mad ?  ;-)
2) why does this happen?
2) can this be solved?

2.7.7 release

Call
dockimbel:

About CALL console window issue, the CreateProcess( ) win32 call 
has flags to hide the window. There just need to be set.

In the STARTUPINFO used by CreateProcess( ), just set in dwFlags, 
the STARTF_USESHOWWINDOW flag and set wShowWindow to SW_HIDE.

maybe add a new refinement and let the users decide when they want 
to see the console window ?
or maybe just /show

Paul:
Run is not enabled

Graham

Is anyone concerned that shell windows opened in Encap do not contain 
the correct window title?
Rambo #3660 ( reported march 2005 )

Brian

For me, the big question is what kind of release we will be doing:

- 2.7.7: Patching glaring bugs in a few natives, VID fixes, and continuing 
the backports and mezzanine fixes.

- 2.8.0: Backporting some of the R3 native changes (function, not 
infrastructre), and the above.

I think that the decision a long time ago was to focus on R3 as a 
priority, and just patch up R2 as necessary.

At the very least, I would want a 2.7.7 to have a version that fixes 
post-2.7.6 mezzanine bugs, and 2.7 series regressions vs. 2.6.3.

Henrik
We also need to implement BrianH's new window resize scheme.

Ashley,Anton, Brian, etc ... VID fixes

Graham
Fixes to prot-http to support put etc.

BrianH

SQL_FLOAT and SQL_REAL are converted the same way, just with different 
sizes. And yet SQL_REAL works and SQL_FLOAT doesn't, at least with 
SQL Native Client (an ODBC 3.5 driver). Perhaps that difference can 
point you in the right direction.

Henrik
view/new make face []
a: open/binary/direct/no-wait tcp://:9000
forever [wait reduce [ a 0.001]]


This produces a 16 byte leak when started. And when I move the window 
and click in it, I get a lot of 64 byte leaks.

2.7.7 release

Call
dockimbel:

About CALL console window issue, the CreateProcess( ) win32 call 
has flags to hide the window. There just need to be set.

In the STARTUPINFO used by CreateProcess( ), just set in dwFlags, 
the STARTF_USESHOWWINDOW flag and set wShowWindow to SW_HIDE.

maybe add a new refinement and let the users decide when they want 
to see the console window ?
or maybe just /show

Paul:
Run is not enabled

Graham

Is anyone concerned that shell windows opened in Encap do not contain 
the correct window title?
Rambo #3660 ( reported march 2005 )

Brian

For me, the big question is what kind of release we will be doing:

- 2.7.7: Patching glaring bugs in a few natives, VID fixes, and continuing 
the backports and mezzanine fixes.

- 2.8.0: Backporting some of the R3 native changes (function, not 
infrastructre), and the above.

I think that the decision a long time ago was to focus on R3 as a 
priority, and just patch up R2 as necessary.

At the very least, I would want a 2.7.7 to have a version that fixes 
post-2.7.6 mezzanine bugs, and 2.7 series regressions vs. 2.6.3.

Henrik
We also need to implement BrianH's new window resize scheme.

Ashley,Anton, Brian, etc ... VID fixes

Graham
Fixes to prot-http to support put etc.

BrianH

SQL_FLOAT and SQL_REAL are converted the same way, just with different 
sizes. And yet SQL_REAL works and SQL_FLOAT doesn't, at least with 
SQL Native Client (an ODBC 3.5 driver). Perhaps that difference can 
point you in the right direction.

Henrik
view/new make face []
a: open/binary/direct/no-wait tcp://:9000
forever [wait reduce [ a 0.001]]


This produces a 16 byte leak when started. And when I move the window 
and click in it, I get a lot of 64 byte leaks.

The connection flags are likely specifying 32bit data modes, so the 
ODBC server is rejecting it.

but I kept on unchecking the read only prop, applying the change 
which asked to apply to all children and I said yes, it looked like 
it was recursing and setting the flags - then I exited the dialog, 
and upon re-checking, the settings seemed to be the same as before

I don't parse any of the message flags etc.

Getting a window plus event handler up and running only using View 
(no load-gui) is pretty simple. The code, for those interested, is:

	system/view/event-port: open [scheme: 'event]

 system/view/event-port/awake: make function! [[event][print event/type]]
	f: make system/standard/font [size: 36]

 d: make gob! [text: "Title" offset: 50x50 size: 300x200 flags: [resize]]
	append d make gob! [text: [font f "Text"]]
	append system/view/screen-gob d
	show system/view/screen-gob
	wait system/view/event-port

It's important to lift the UI out of the domain of appearance and 
into the domain of meaning. When your UI intelligently finds the 
default window close button or the first field in a form automatically, 
and automatically assigns correct keyboard navigation shortcuts, 
because of the underlying architecture's emphasis on meaning, there's 
no need to write any code to handle that at all. It's just there. 
You build your styles to adhere to the meaning that was setup by 
the GUI system. In the VID extension kit, this is done through flags 
and powerful face handling features. You don't need to add any code 
for that in the dialect.

ah, forget it, it was "flags" ... but that is something different 
...

I think an hidden item should not be disabled by default (allowing 
"ghost" validation).
I you want both, then add the both flags HIDDEN + DISABLED

try this:

screen: system/view/screen-gob
event-port: system/view/event-port: open event://
event-queue: system/ports/system/state
push-event: func [event][append event-queue event]
push-event time-event: make event! [type: 'time port: event-port]
process-timers: does [
	push-event time-event
	forskip timers 2 [
		case [
			not integer? timers/1 []
			positive? timers/1 [timers/1: timers/1 - 1]
			zero? timers/1 [timers/1: do :timers/2]
		]
	]
]
event-port/awake: func [event][
	switch/default event/type [
		time [process-timers]
		close [halt]
	][
		print [event/type event/offset now/time/precise]
	]
]
timers: [
	1000 [print ["1000 ticks" now/time/precise] 1000]
	4500 [print ["4500 ticks" now/time/precise] 4500]
]
show append screen make gob! [
	offset: 50x50
	size: 100x100
	flags: [resize]
]
do-events

and in the richtext proposition of Carl made 2 years ago (times flyes..) 
we find again this block concept wich is related to the way MakeDoc 
format handle things ...  like in HTML  for example you have flags 
that defines a rendering style. But the things betwin the flags can't 
evolve... they are not supposed to change font style or font size 
or font color. See that's what i would call a we treat text as block 
and not as single element able to singularly evolve on their own 
without affecting the surrounding elements.

and then if you want to have an atomical approach then MakeDoc dialect 
becomes too verbous to be efficient... like in HTML more you want 
stylised things more you pile up flags and more you have problems 
debuging and having a direct acces to your raw document content... 
So it's clear that a real design have to be set for this richtext 
even if in the end rendering html or MAkeDoc or makeDocPro  with 
that dialect means a conversion stage.

what about having another field in the style, called 'depends-upon: 
[other styles here] .... then, upon such flags, you might be able 
to kind of automate it ...

REBOL [
    title: "Untitled"
    build-date: 24-Sep-2010/8:46:56+1:00
    build-flags: [console log]
    revision: 0
    release-type: release
    language: en
]

It is often about the clash of how we are used to think, and use 
some functionality, about our workflows. If everything is gluable, 
well then. I would not just like to see, that each style has tonnes 
of fields, to support upper layer frameworks. I hope you keep it 
streamlined to some flags, and custom data fields ...

is there anything like 'flags item in new VID? I find tagging very 
usefull technique. That way you could simply add a tag, e.g. 'internal, 
and such style would not appear int he list of styles for something 
like get-styles function. Simply put - only styles/widgets which 
are able to function on their own, would be shown ...

Late to the game, but


as for A) - don't we have already tags? It could all be in the tags 
block, not in the new field. And if tags block is just flat, and 
those for states could collide with another flag names, we could 
use nested blocks flags: [ show? [visible]]. I see no reason why 
to introduce new field, unless from the speed reasons

Generally I like B) more, but:


I definitely don't like being dependant upon the size of 0x0? That 
seems really strange to me. Visibility state in the gob-tree should 
be imo independent from the size? E.g. look at Cyphre's code example:

button 0x0 "test" options [resizes?: true]

Do you really want to see code like that in the VID level?

I would prefer 'resizes, 'floats or other fields, which would take 
care of it internally. But not sure. That is why I asked where other 
valueas as HIDDEN (that one I remember) are set? Are that flags/tags?

ad 1. I have a feeling, that we incorrectly mixed two things. TAGs, 
in my vocabulary or understanding, are "categorisation" elements. 
As for "state", there should be FLAGs, no? :-)

Cyphre:

box-model:
---------------


Few notes. Certain systems use FLAGs, which could be thought about 
as kind of switches, or representing certains states, etc., used 
in binary masks for e.g. Then we have TAGs. Even R3 GUI uses tagging 
- it is used mostly to mark particular face as behaving some way, 
belonging to some area, etc. And in that regard, I wonder if box-model 
type could be done just by using TAGs? 


What I think about TAGs in GUI in general is, that we don't use the 
concept to the max. I mean - if tags were not be flat block, but 
block of blocks, it could be used even more, e.g.:


tags: [box-model [tag1 tag2 tag3] style [internal] draw-mode [normal] 
resizing-mode [.....] ....]


Of course that might not work for us in all cases, because as you 
could see in above example, it would be difficult to distinguish, 
if something should be a facet, or a tag. E.g. if we would move DRAW-MODE 
into TAGS, then why not moving MATERIAL there too, etc. My question 
is - is there any rule for me to remember - what should be a facet, 
and what could be a TAG? (I expect the difference in how you work 
with them underneath)


My general problem is, that FACETS block is becoming long and messy, 
so what to do about it? There were following suggestions to think 
about:


1) close particular settings in subobjects/maps (whatever). There 
are settings belonging to the areas of resizing, colors, box-moderl, 
others, etc. The question is, if we want to refer to such values 
by face/color/bg-color for e.g.?


2) the simplest solution is to at least use some source code conventions. 
E.g. Carl introduced comments to particular ACTORS, desribing what 
arguments are supported for the function. So my idea is:

facets: [

   ; colors
   bg-color:
   other-color:

   ;resizing
    resizes: 
    init-hint:
...
]

ALIGNment:
----------------


It is probably not wise to change all subsequent areas to halign, 
valign. But anyway, we are a bit chaotic here, unless someone tells 
me, what's the rule here - to stay compatible to html/css, or to 
be consistent REBOL wise? I mean - if various areas use ALIGN/VALIGN, 
then my logical question is - why HPANEL/VPANEL, and not PANEL/VPANEL?


My comment is just food for thought, not a claim to change anything.

When I run the latest build for windows I get the following error:

Evaluating: /C/Users/Paul/Desktop/R3DBMS/r3dbms.r3
** Script error: cannot access words in path system/words
** Where: catch either either do begin do
** Near: catch/quit intern code if flags/halt [sys/halt]

Are there flags or other things that need to be reset or what is 
the issue?

AFAIK 96 bits are reserved for immediate values with the 32 bits 
left for flags and stuff.

Strangely enough, if ops were implemented using the R2 method - DO 
swaps the op keyword for its prefix equivalent, instead if the op 
itself redirecting - then unary postfix and ternary ops would be 
possible right now with the current op! type, no new internal flags 
needed. Prefix functions can have infix keywords already, as long 
as they are not optional - the arity of the function needs to stay 
the same, but there's nothing illegal about infix keyword parameters 
in REBOL.

As for value slots, not all datatypes use all 128 bits. 32 bits are 
used for flags, and the payload could be 32 bits (as in char!), 64 
bits (series, integer, decimal) or up to 96 bits. The rest is wasted 
space. The value slots need to be the same size so you can set one 
of them to a different value without moving the rest in the block 
if that value is of a different type.

Well, the value slots would need to be bigger if we want to have 
both 64bit pointers and 64bit series sizes. If we just had 32bit 
series sizes then 128bit would be plenty (remember the 32bit flags 
means that we only have 96 bits for the payload). We could also have 
32bit handles to series, adding a layer of indirection, and then 
have a limit on the number of series, not the size. We already have 
64bit integers.

This works: if (GET_FLAG(cbi->flags, RXC_DONE)) {

So, on R3 INVALID-UTF? flags overlong encodings? Sorry I missed that. 
Better fix the R2/Forward version accordingly.

No, I'm just saying that for those set of command line flags, your 
linker behaves strange.

Settable system-wide flags that affect MOLD are a bad idea, since 
they mean that you have to put wrapper code around every call to 
MOLD to make sure that it matches what your code expects. This makes 
very call to MOLD more complex and less task-safe.

p: open tcp://

i: get-modes p  'interfaces
 probe i

 probe i
[make object! [
        name: "if16"
        addr: 91.121.*.*
        netmask: 255.255.255.0
        broadcast: 91.121.*.*
        dest-addr: none
        flags: [broadcast multicast]
    ] make object! [
        name: "lo0"
        addr: 127.0.0.1
        netmask: 255.0.0.0
        broadcast: none
        dest-addr: none
        flags: [multicast loopback]
    ] make object! [
        name: "if16"
        addr: 188.165.*.*
        netmask: 255.255.255.255
        broadcast: 188.165.*.*
        dest-addr: none
        flags: [broadcast multicast]
    ]]

Yes, but that's the charset kind of bitset. I guess, other kinds 
of bitsets (other lengths than 256) can be used just to hold a bunch 
of flags or something. I haven't seen them used like that.

Kaj: thanks for the report. I thought we were cleanly separating 
RO and RW sections in two different LOAD segments...maybe the flags 
are not correctly set in sections (or in section headers). I'll give 
it a look this weekend if Andreas has not the time to fix it before.

send: func [  ; Send message.
	socket		[pointer!]
	data		[pointer!]
	size		[integer!]
	flags		[integer!]
	return: 	[logic!]
;	/local		message [pointer!]
][
	either zero? as-message message data size none none [
		either zero? send-message socket message flags [
			zero? end-message message
		][
			end-message message
			no
		]
	][
		no
	]
]

Compiling /users/administrator/Red/Red-ZeroMQ-binding/examples/reply-server.reds 
...
*** Compilation Error: invalid struct syntax: [pointer!]

*** in: %/users/administrator/Red/Red-ZeroMQ-binding/examples/../ZeroMQ-binding.reds
*** at:  [struct [
        content [pointer!]
        flags [byte!]

*** Compilation Error: invalid definition for function send: [
    socket [pointer!] 
    data [pointer!] 
    size [integer!] 
    flags [integer!] 
    return: [logic!]
]

*** in: %/users/administrator/Red/Red-ZeroMQ-binding/examples/../ZeroMQ-binding.reds 
*** at:  [func [
        socket [pointer!]

message!: alias struct! [
	content		[handle!]
	flags		[byte!]  ; unsigned char
	vsm-size	[byte!]  ; unsigned char

 vsm-data1	[integer!]  ; unsigned char [ZMQ_MAX_VSM_SIZE] (default 
 30)
	vsm-data2	[integer!]
	vsm-data3	[integer!]
	vsm-data4	[integer!]
	vsm-data5	[integer!]
	vsm-data6	[integer!]
	vsm-data7	[integer!]
	vsm-data8	[integer!]
]

Exception Information/Code: 0xc000005  /Flags 0x0000000

Jerry: values needs space to store various flags, and type information. 
Also, payload access needs to be 32-bit aligned at least.

Kaj: I will see if I can quickly add support for `system/fpu/flags` 
so users can set it as they want/need.

Kaj, in any case, you can just replace #{037B} by #{037F} in IA-32.r 
at line 20: 

    fpu-flags: to integer! #{037B}