AltME groups: search

REBOL [
	Comment: {
		Inspired by http://www.rebol.com/how-to/feel.html
	}
]

view/new layout [
	across
	tabs 120
    the-box: box 200x200 "Test Events Here" forest feel [
        engage: func [face action event] [
			ac/text: mold action show ac
			ty/text: mold event/type show ty
			of/text: mold event/offset show of
			co/data: event/control show co
			sh/data: event/shift show sh
			ke/text: mold event/key show ke
			kt/text: mold type? event/key show kt
			ti/text: mold event/time show ti
			dc/data: event/double-click show dc
        ]
    ] return
	lbl "action:" tab ac: info 100 return
	lbl "event/" return
	lbl "type:" tab ty: info 100 return
	lbl "offset:" tab of: info 100 return
	lbl "control:" tab co: led off return
	lbl "shift:" tab sh: led off return
	lbl "key:" tab ke: info 100 return
	lbl "type? key:" tab kt: info 100 return
	lbl "time:" tab ti: info 100 return
	lbl "double-click:" tab dc: led off
	key #"Q" [quit]
]
focus the-box
do-events

well, in a way they do. there is a ctrl, alt and cmd key. on PC keyboards, 
the ctrl key handles things that normally is assigned to the cmd 
key and the ctrl key. this makes it a bit confusing to copy (ctrl-c) 
things from a terminal on a PC keyboard, whereas the mac keyboard 
uses cmd-C to copy. in rebol this means that the ctrl functionality 
in windows should be mapped to cmd on the mac, but if this was to 
be done right, we'd need a /cmd refinement as well.

pekr, I could use stability updates. what if R3 won't be entirely 
stable until mid 2008? As far as we can see, the internal test period 
will only be 45 days. It's disheartening to tell customers that they 
have to deal with the crashes, because there's nothing to do about 
them.

do you need some experiments in 2.7? Or just what you need is as 
much stable branch of 2.x generation to live for some time?

4267, 4238, 4167 all seem reasonably easy to work around Henrik; 
not that I'm saying they aren't important, or shouldn't be fixed, 
but we don't know RT's internal development setup, so we can't really 
say what they should do. We all have different priorities. 


I would like to see a large set of public tests, to help RT nail 
bugs and catch them when they sneak in.

Were you allowed to do like this in previous versions of Rebol?

bl: ["block"]
print switch type?/word bl [ block! bl object! ["object"] ]

Thanks. That must also mean it is pretty hard to do.

If you can get them to upgrade to 2007 (the runtime is free), then 
you won't have to do as much VB for UI stuff.

Thanks Brian. I forgot about Express. If I can convince them to let 
me do a complete Rebol app I would do that. : )

Tomc, look here for the answer, though you might need to do some 
math: http://curecode.org/rebol3/ticket.rsp?id=879

Also I needed to have the ability to change a function in many objects 
like you do in other languages changing a single pointer to the destination 
fuction.

In R3 you have to DO the error! to trigger it.

Gregg,  I do not want to criticize the REBOL object model but the 
lack of in-depth documentation leave me in the blindness.

I have no answer for you. My skill level is too low but I whish to 
increase it.

Now I have learnt that REBOL object are Prototype Based and I have 
read the Wikipedia article about this kind of object orientation. 
I know domething more.

TomBon - unless someone writes enhanced DLL wrapper as a plug-in, 
there will be no such thing as struct!, routine! in R3. You better 
look into plug-in interface, where there is much more freedom to 
do wrapping, but otoh it requires greater skill to handle it (C IDE 
set-up, compiling, etc.)

1. I would like to release this week.
2. BrianH will set the priorities.

3. I can post any code needed to fix problems. But, if you make a 
change, be sure to test it really well. I do not have the time to 
test.
4. We can release again next month, and each month after that.

What is the reason to do R2 release in current time-frame, when we 
are supposed to be heading for R3 beta?

Believe me, I do not want to take extra time away from R3 beta, but 
also, I did not want to delay R2 this long.

simplest thing to do is just release a license ...

I don't know though if such a license would also be usable for the 
SDK ... which Carl may not want to do .

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.

Oh, and I almost forgot: This is a TEST. Use entirely at your own 
risk. Do not distribute. Do not use to operate nuclear reactors, 
missle defense systems, aircraft, heart-lung machines, etc. etc.

What do you mean? To send mail from the gmail account from within 
application.

I never needed to do that ..always have a smtp server around and 
just use the gmail account as the reply to address

Graham, thanks for copying over those priorities from R2-Beta to 
here. About how those choices were made and phrased:


The R2-Beta world was used when we still thought of REBOL being updated 
more rarely, in larger increments. This is no longer the case, we 
are adopting the rapid release model, though more regulary than the 
R3 alphas. We need to shift our thinking accordingly.


Rapid release means that each individual R2 release doesn't have 
to include fixes for every outstanding bug. We can and will triage 
and prioritize, and your favorite bug may be moved to the next release. 
Which won't be a problem because that's coming next month, or the 
month after. Minor point releases will not be a major deal from now 
on, they will be monthly occurances.


The overall plan for the R2 2.7.x series is to fix what we can in 
R2 in a way that doesn't break things. This won't be a ground-up 
rewrite, as we are doing one of those already. No major model changes, 
just tweaks. There is a lot we can tweak though, including natives. 
We are trying to avoid disruptive changes that affect scripts at 
runtime, except in cases where things just didn't work before. Almost 
all code that works on 2.7.6 should continue to work - that is our 
goal. Don't expect broken code to stay broken though :)


The 2.7.7 release will not be ambitious, we just don't have the time. 
The priorities are business model changes and low-hanging fruit. 
The one piece of major breakage from the 2.7.x series that needs 
fixing in this release is the installer. If you have other priority 
fixes that can't wait til next month, and you are willing to do the 
work in this week, please speak up.

In the long run I would prefer to make the installer configurable 
and encappable, but for now a View-specific one will do.

BrianH: you have access to sources? Who can do native changes? Only 
Carl? Because if so, I hope there is not much of changes. I wish 
Carl finish R3, not to spend much time on further R2 enhancements 
in native code ....

Here's my patches to http-prot.r .. http://rebol.wik.is/Protocols/Http

I have used it for a while and they do not break anything AFAIK ...

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.

I will be integrating changes starting this evening (Chicago time, 
starting 4 hours from now). If you want your fixes in, get them to 
me before I go to sleep (late) and I'll see what I can do. Code that 
patches memory should include a version of the function that is supposed 
to be the result of the patch; we're patching the source, not hotpatching 
the runtime.

Yes. And it looks like it might not make the cut for this version, 
instead doing just a simple fix to make the existing installer work 
again. To do a full installer revamp would require testing on every 
Windows platform, and I don't have time to set up all of the VMs 
required.

Core doesn't do anything like that, just View. I'm going to do a 
full review of the installer for the next version though.

Yeah, the SSL code is a little old. Holger wrote it, I think. We 
have to do a much better job with the R3 SSL.

OK, now that we have 2.7.7 released (even though there is more work 
to do, i.e. platforms and the SDK), it is time to look ahead to 2.7.8 
- which is scheduled for release in one month on February 1. The 
primary goal of this release is to migrate to REBOL's new development 
infrastructure. This means:

- Migrating the RAMBO database to a new CureCode project and retiring 
RAMBO.

- Using Carl's generation code for the manual to regenerate the R2 
manual, so we can start to get to work updating it.

- Porting the chat client to R2 using the new functions and building 
a CHAT function into R2 similar to the R3 version.


The R2 chat client might be limited to the ASCII character set, though 
support for the Latin-1 character set might be possible. Still text 
mode for now, though if anyone wants to write a GUI client (Henrik?) 
we can put it on the official RT reb site accessible from the View 
desktop. The server is accessed through a simple RPC protocol and 
is designed to be easily scriptable.


It turns out that Carl already rewrote the installer for 2.7.something, 
but it was turned off because of a couple minor bugs that we were 
able to fix in 2.7.7. With any luck, only minor fixes to the registry 
usage will be needed and we'll be good to go.


As for the rest, it's up to you. Graham seems to have a good tweak 
to the http protocol, and others may want to contribute their fixes.

Only take you a couple of mins to write the code to do that!

I know that the Source code is the most obvious place to look, but... 
  Luckily this ain't anything I'd mandatorly need to do since there 
are some (allmost) ok tools for the chip, but it would be good to 
know where to look.

There are two additional port fields that can't be set with a URL, 
but can be set in a port specification block or by manually changing 
them. The RTS-CTS field specifies whether hardware handshaking should 
be used on the port. The default is ON. To change the default, do:

ser-port/rts-cts: off
update ser-port

You can confirm that it does what it is supposed to do by looking 
at the http traces.

Doc in the Core group: "this could be a really great addition to 
R3 (or even R2)"


Policy: Additions of new globally defined functions to new R2 releases 
almost always must get put in R3 first, go through consensus, testing 
and the REBOL optimizer, then be backported to R2 (usually through 
R2/Forward). Enhancements of existing functions in comparable areas 
of the code (not ports, View or library) also go through the R3 gauntlet 
first. If you want R2 /Core enhanced, get to work on R3.


Change to the semantic model of R2 isn't going to happen: No new 
port model, no new View, no extensions or host code - use R3 if you 
need those. New (real) R2 datatypes are unlikely, though faked backports 
of R3 datatypes are OK and have already made it into 2.7.7, with 
more to come. Natives that can be fixed without changing the semantic 
model or adding new datatypes are fair game though.


Bug fixes will be done though as long as code (that we can't fix) 
doesn't depend on the bug (no fix to PICK, POKE and AT's off-by-one 
error, for instance), as will backwards-compatible enhancements to 
R2-specific areas, like the port model, View/VID and library support. 
Backwards-compatible means we also test it against existing code, 
so if you want to test it against your favorite code, please do so 
and tell us what you find.


These fixes are coming, at least in theory - someone has to do the 
work. If you have a favorite bug you need fixed or enhancement you 
need, do the work yourself or pay someone to do the work (REBOL Consulting, 
perhaps). Changes go in as they are made, and they are made by people 
with priorities. If you have priorities too, act on them :)

If anything we do breaks your code, *please tell us*. We really don't 
want that to happen. Backwards compatibility is a top priority.

what about   "dt"  function in Rebol 2.78?

dt: funct [
    {Delta-time - return the time it takes to evaluate a block.}
	block [block!]
][
    start: now/precise
    do block 
    difference now/precise start
]

Hmm... could be mistake there on export vs full. Will need to investigate 
that. Should be export by default. So, don't depend on full for anything 
until we can verify, which may not be easy to do.

We didn't do anything extra to test the TLS/SSL in 2.7.7.

Spent last night updating R2/Forward - it was about 6 months behind, 
due to various issues, but R3 for those six months hasn't been focused 
on new functions so there isn't much to do. I should be done by today, 
and they should be portable to 2.7.8.

Do we need to do aliases, or generate from a common set of data? 
Perhaps common pages for common functions, since R2 people might 
be interested in R3 compatibility notes.

>> help "thru"
Found these words:
   do-thru         function! Do a net file from the disk cache.

   exists-thru?    function! Checks if a file is in the disk cache. 
   Returns: no...

   launch-thru     function! Launch a net file from the disk cache.
   load-thru       function! Load a net file from the disk cache.

   path-thru       function! Return a path relative to the disk cache.

   read-thru       function! Read a net file from thru the disk cache. 
   Returns ...

I used latest R2 to do experiment something with rebol yesterday.. 
I saw the map-each function but I didn't find the accumulate . Is 
it under some other name maybe?

>> do %json.r
Script: "JSON to Rebol converter" (21-Apr-2008)
>> text: {print "hello"}
== {print "hello"}
>> a: rebol-to-json make object! [ t: text ]
== {{"t": "print \\"hello\\""}}
>> json-to-rebol a
** User Error: Invalid JSON string. Near: <end of input>
** Near: json-to-rebol a

Gregg??

I have a fixed version of %json.r. Do you want it Graham? I'll also 
send it to Douglas Crockford to post on JSON.org.


Thanks for catching that. The naive escaping has been there all along.

Any reason why I can't change this http://rebol.wik.is/Protocols/Secure_Smtp
from

			port/user: port/user
			port/pass: port/pass
			; do authn if needed

to
			; fix: only ask once if the user used set-net ask
			port/user: system/schemes/esmtp/user
			port/pass: system/schemes/esmtp/pass

so I don't have to fix set-net as well??

my vote would be to not have the option to to do >> foreach item 
block [ pring item ] .. it would make a language more uniform , although 
a little less cool :)

I wouldn't want to lose lit-words, but they do create issues at times.

The problem with ImageMagick was that the API was a moving target. 

So the script I submitted worked only for that specific version of 
ImageMagick.

Since Qtask is not currently using ImageMagick now, I don't know 
when I can get back to work on it again.

I suggest to do what Gregg is suggesting at this time.

Ok...I try to vote to...where do we do this voting?  :)

ok, I've got to go find some food... but will return in a while to 
do a trial build with most of this done.


BTW, still missing the fixes Graham made to HTTP. He mentioned it 
the other day.

Do you have access to any Windows 64 bit PCs?

Interbase have a developer release that is multicore aware.  I'd 
be interested to test this once you do the first release.  The developer 
release is same as the commercial one but stops receiving new connections 
after 48 hours.

Sounds good to me. Which services/variants do your changes work with?

It might be a good idea to have the standard pop:// protocol do the 
STLS negotiation, and have pops:// do POP3S like Gmail.

In that case you have a list of jobs a mile long to do ...

so to get a greater than we have to do

>> 10x0 = max 10x0 11x0
== false

Do you really want > and < to return none if they run into a ambiguous 
situation? Right now all of those functions return true or false.

I'm sorry, I don't want to be a jerk about this. This group is used 
as a reference when we do new R2 releases. It's of less value as 
a reference if off-topic stuff is overwhelming the release discussions. 
Please be nice to the R2 release manager :(

If I want to set something to the index of a series, or something 
else if it's not there I have to do this

b: either a: find series var [
	index? a
][ 	default ]

when I'd rather do

 b: any [ index? find series var default ]

So how about letting index? also take none as an argument ?

Use a local reference to the old function, then call through the 
reference. You can do this with a private variable, or composing 
the code block of the new function to have a direct reference to 
the old function value. That last method can be awkward with functions 
called with refinements, but it can be done; the private variable 
metod is less awkward.

Yes, but current R2 code would be depending on that error to trigger 
the code in the error handler, rather than just propagating the error 
to where it would do more damage. Error handling code is there for 
a reason.

I asked Cyphre about his demo from 2005. It might be possible to 
do, but it's a fair amount of work.

sounds good - im looking into a 'Quickfill' implementation at the 
moment which can do pattern, flood and bordered fill.  Once its working 
properly ill post to View or similar

This is something I do find annoying http://rebol.wik.is/IBM_Cloud/Extend-cloud.r

I have to patch http each time I do any REST stuff

ICarii, what I did, was studying DPaint filling the screen, and then 
figured out, how to do it. It's a scanline filling algorithm. In 
short, it goes like:


- Search left and right for other colors from the point clicked on 
screen. That defines the first scanline.

- Look at lines above and below starting from the end-points of the 
first line. This defines 4 new points to look at.

- Again search left and right for other colors. Make sure, the whole 
area between the end-points are searched.
- Put it all in some list, and continue, until the list is empty.

ah ok - i built my own installer back when i used to do R2 deployment 
for people

Imagine that you are a least-privileged user, but evil. Do you want 
to write to a directory that contains programs that are run by other 
users?

There are group policy settings that can make it so that programs 
can only be run from certain directories, and security settings to 
make it so only administrators can write to those directories. And 
the only reason that they have to do things so drastically is because 
of developers like you who insist on writing Win9x apps and trying 
to run them on Win2k+. Apps like AltME.

Sorry, there's no user-specific folders under the install path, not 
without separate user folder permissions maintenance for each application, 
or those aliases you mentioned. Is it really so hard to put user 
files in user folders? You have to do that on Linuc and Mac...

what do you mean by "so that it executes" - just tried it and it 
seems to start...

First, thanks to Brian for making sure this gets done right (or at 
least the best we can given the circumstances :-). Getting the installer 
right is part of the battle, but another part is making sure we, 
as  developers, do the right thing as well. The effort to identify 
system direcories, and provide mezzanines to make it easy to use 
them correctly, benefits everyone.


The old Roxy installer code is all BSD, and I'm happy to provide 
it, even if just for fodder.

That's nothing to do with an installer then, has it?

I really don't see what viewtop has to do with it.

and you cannot overide how IT wants to install in cases where you 
know exactly what YOU want it to do.  for rebol it wouldn't be too 
bad, but for scripts which are more than your little 100 line reblet, 
this gets VERY annoying real fast.

as a reboler, I don't want to write system specific and environment 
 resolving code.  


my script should be able to ply itself to whatever system its installed 
on and still read/write its files in proper OS expected places.


This is what we are talking about Andreas... viewtop specifically 
has nothing to do with this.  this is for ALL scripts to be compliant.


if I had a command which allowed me to build a system-compliant "application 
data path" then it would write stuff in ~/application/ on linux and 
whatever profile/app data/application   path is being used by your 
flavour of windows.


right now, I'd have to write a library which determines this and 
it probably will screw up on ubuntu, or Mac Or the latest windows.

not sure it was just a cosmetic thing, because in the end I managed 
to do whatever it was that I needed to do

That sounds like a good idea to me too, so when a new distro comes 
along which locates fonts in a different location, then at least 
you can do something about it without having to wait for rebol to 
be updated. It will also require less code in rebol compared to a 
full automatic font finder.

The scheme handler should have to do a dehex in some cases, but isn't 
because the dehex is being done in DECODE-URL first, when it shouldn't 
be.

Right. And once I figure out how to make it not do so in R3 (based 
on Gabriele's code) then I will port that to R2.

Or at least put off until it is appropriate to do.

Carl wrote:   I'm wrapping up R3 A107... so if we want to do some 
test builds for 2.7.8 on this, let me know.

A good look will be possible for R3 to do. It's simply a waste of 
time for R2 and you can't produce anything that resembles Aqua anyway 
in R2. In R3 that is possible. But focusing on look alone is a big 
mistake, which too many developers using GUI systems are suffering 
under.

nve - what is Henrik trying to point out imo, is the fact, that it 
is not that easy to change look of R2 VID and stay consistent. I 
think that with VID3 it is going to be easier, as the system is more 
and better abstracted. It might be easier to do the job for R3, than 
to R2. I believe R3 is going into beta sometimes ... when Carl re-appears 
 + 2-3 months :-)

Some of what is coming in 2.7.8:

- Bug fixes and enhancements to improve Cheyenne, and other apps 
that have to do similar stuff.

- Some native fixes for non-Windows platforms, particularly Linux.

- Environment variable stuff: GET-ENV expansion on Windows, SET-ENV, 
LIST-ENV

- Function fixes: RUN enabled, LIST-REG/values, possibly TO-LOCAL-FILE

- R2/Forward: FUNCT/extern, LAST?, COLLECT-WORDS, EXTRACT fixes, 
ASCII? fixes, LATIN1? fixes, INVALID-UTF?, CD, LS, MORE, PWD, RM

- (Still pending) Natives: ASSERT, APPLY, RESOLVE, FOREACH set-word 
support

One of the things we would like to do is easily detect all installed 
fonts in windows, and install new fonts

Have the registry bugs been reported? If not, do so here or in RAMBO. 
(I am a bit new to the RAMBO admin process.)

What is the plan for next release ?
Do we need to post bug/request on RAMBO ?

What we got in 2.7.8, that I know of:

- Bug fixes and enhancements to improve Cheyenne, and other apps 
that have to do similar stuff.

- Some native fixes for non-Windows platforms, particularly Linux. 
See ACCESS-OS.

- Environment variable stuff: GET-ENV expansion on Windows, SET-ENV, 
LIST-ENV

- Function fixes: SELECT object!, FIND object!, RUN enabled, LIST-REG/values

- R2/Forward: FUNCT/extern, LAST?, COLLECT-WORDS, RESOLVE, APPLY 
fixes, EXTRACT fixes, ASCII? fixes, LATIN1? fixes, INVALID-UTF?, 
CD, LS, MORE, PWD, RM

Diffs from the old preliminary changes doc to the actual 2.7.8 release 
(that I know about):

- No installer changes yet (my bad, I didn't have time to do them)
- SINGLE? is LAST? instead
- RESOLVE is a (slow) mezzanine for now, not native

- Don't know about what the Command boot problem was or whether it 
was fixed
- No HTTP fixes yet
- No X fixes yet

- ASSERT and APPLY are still mezzanine, and ASSERT is still rather 
bad
- No FOREACH setword support yet
- SET-ENV native (with limits)
- Delay sound subtask creation (whatever that means)
- RUN function uses 'shell access in SECURE
- FIND and SELECT on objects
- FUNCT /extern option, SPEED? and DT

- Some fixes to bugs in RAMBO that I don't know since RAMBO is down

Carl was glad with the compliments on 2.7.8, but likewise, I seem 
to be the one who will have to promote R3 on OSNews in the time to 
come, and I can't do that if I don't believe in it

one thing to look out for in view (in any face using the caret and 
standard focus mechanism) is that when windows are closed, they do 
not unfocus their fields.  this has bitten me quite a few times which 
made other key handlers seem like they where dead.


this is why you should always call unfocus when you open or close 
a window in view.

Well, this is interesting....


I don't have clipboard functionality in 2.7.8 while Prevx is running, 
but I do in 2.7.6.  Turn off Prevx monitoring and my 2.7.8 clipboard 
starts to work again.

What to do then?

got to slide 14 .. do the X mean you've completed those tasks?

I'm thinking about using Google Groups...I'll do a review of possible 
options in the next days to decide.

he never released it .. I think he said he had to do some rewriting.