AltME groups: search

That release schedule sounds good to me. That way we can triage and 
schedule changes.

SSL and other protocols will come from the SDK too ?

Is there any difference between the free View now and Pro ??

that was part of /Pro and is now free

The only significant thing you can do now is release SSL and OBDC 
free

Terry - DLL and Shell were released long time ago.

And Oracle (does anyone use that?)

if SSL and ODBC would be released for free, it would make many folks 
happy ...

Of course, you could make some real headlines, and just BSD the whole 
thing.

No it won't take long - it's just a matter of removing the license 
code and doing a rebuild.

And if it does take long, we can do it right next month and do your 
approach now.

People need to nag me more if they contribute a fix, and it gets 
lost.

:-) I do remember - over 1200 lines of code ... but at least "it 
works", and in R3 'call is almost unusable ...

Using R2Beta should be fine for this week, but we need to switch 
over to using the R3 development infrastructure before the release 
next month. We won't have the time and effort available for monthly 
releases if we can't share resources. The rapid releases of R3 are 
only possible because of the R3 development infrastructure.

Yes. And fixing the installer is one of the top priorities for this 
release.

It hasn't worked at all for the 2.7 series, and worked incorrectly 
before then.

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.

And hotmail .. which is also ssl

We can't cover everything in this one thread here. And I think that 
ppl interested in further R2 development have no problem to log into 
R2-beta. It is also imo good to keep it isolated that way ...

Brian, yes we use Oracle and Sybase specifically in our enterprise.

Yes R2-Beta because it already has many of the accounts already setup. 
 For a 1 week release and feedback that will be best approach.

I was just at the R2-Beta world and it doesn't appear any discussion 
has moved there yet.

The 2.7 test release has been built. This is the base build for the 
next release. It contains SSL, ODBC, DES, etc., and no-license key 
is required.


In addition, I've added an install checkbox to the Prefs (User panel) 
and an Uninstall to the Help panel. These are just shortcuts to existing 
features.

The download is www.rebol.com/downloads/view277-test1.exe


Note that it's version # is 2.7.6, but it has a new system/build 
date. Don't mix it up with prior versions, as it's not at all tested.

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.

for hotmail, and gmail ...  download prot-spop.r from http://compkarori.no-ip.biz:8090/REBOL_stuff/REBOL_2/Secure_POP_and_SMTP

mbox: open compose [ scheme: 'spop host: "pop.gmail.com" user: [yournamegoeshere-:-gmail-:-com] 
pass: "password" ]

and then 

pick mbox 1

gives you your first email

sorry .. I cut and pasted that .. the 'compose is not needed

Awsome Graham...thank you for that (and Carl).

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.

If people can get on the R2-Beta world and start discussing things 
by end of Tuesday pacific time, we can use that, otherwise all discussions 
will have to be here in this group. If that turns out to be the case, 
please keep the discussion on topic. During the next release period 
we can properly switch to the community development infrastructure 
we use to make R3. Yes, that includes R3 chat.

One personal note: In Monday and Tuesday of this week (local time) 
I have a day job. Please accept my apologies for not being as active 
here during that time. By Tuesday evening I will be able to more 
actively participate in the development of 2.7.7, but for now I can 
only coordinate.

It's been broken for so long, I no longer have the computer where 
I originally wrote it back in 2000 and posted it to the mailing list. 
It's still in my head though, so I'll collect it by Tuesday evening 
and start working. In brief:

- I don't know about installation on platforms other than Windows. 
Someone else will have to chime in here. Too ambitious for 2.7.7.

- Windows 2000+ support is still broken. Multi-user support is broken 
(same thing, really).

- Folder usage was mostly fixed in 2.6.3, but the registry is still 
misused. Registry migration will be needed.

- Non-admin installation should be possible, including user-specific 
file associations.

- Installation was broken altogether in the 2.7.x series - it doesn't 
work at all, not even to 2.6.3 levels.

- No-install usage of View needs better support. This means UI support 
too, if need be. VIew should be able to be a portable app.

Keep in mind that portable app usage of directories is completely 
different than installed usage, and needs to be.

Fixing Windows 2000+ support will also enable Vista and Win7 - the 
rules are the same.

Yes, and the most recent release is already in R3 chat. The installer 
can be fixed in an evening at most.

As for installer, me, as a fan of copy&run principle, I would like 
simple option as Altme client has - on first screen, please allow 
"run from current location", and never ask again ...

Which I've already thought through. I've written installers for R2 
before and other apps.

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

So, rebol has to go to <program files>\rebol ?  And it has to write 
in user documents somewhere?

and when you start a rebol console .. you end up deep in user documents 
somewhere ...

File placement is easy, and mostly handled by 2.6.3 - the real trick 
is registry usage.

BrianH: so where can users (not admin) safely put his rebol scripts, 
so that rebol executalbe can write and read from such a directory? 
We can't do it in program files, but can we do in somewhere on C:\REBOL?

Pekr, it's not abot where the user can pt their user scripts, it's 
about the desktop files and such. File associations manage the user 
script issue.

And how then will it cope with Windows 64?

BrianH - but when user script is run, REBOL changes current dir to 
that of the script placement, no? And the script might require to 
create some file at that destination. I know that temp files will 
go to some deep cache dir, but what if script wants to write to the 
dir of the script placement?

For R2, all that matters for install is the View desktop and file 
associations.

I can only SAY WOOOW on this release, I am still a strong R2 user 
and this is much more than appreciated!

Brian, I would like to see prot-http.r extended ... since googledoc, 
and amazon are big topics for some of us

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

Graham, once we switch to the community development infrastructure 
next month such changes will be more possible. Yes, that means the 
R3 chat vcs too, so get your account and start learning to use it. 
If you think it sucks, write your own client - it's not hard.

BrianH: how can you write your own client to R3 Chat? Can you actually 
use its command set? I mean - create a gui, and "send" command like 
"n", "lm", etc. to console in the background?

Pekr, you'd be surprised how much we can fix in mezzanine. Nonetheless, 
it is our job (well, mine) to minimize the impact that R2 development 
has on Carl's R3 work. We're keeping the native changes to a minimum, 
but the big part is testing and coordination.

Own client to R3 chat: The interface between the client and server 
is simple RPC. The UI is split out already.

Fix memory leak, fix installer, update http, back port some r3 mezzanines 
... and parse improvements, and we're done.

Henrik, your VID extension kit is really cool and we'll definitely 
want to look at it for ideas for future VID improvements :)

Oh .. my bug report is for linux, and I'm not using linux so can 
forget about it :)

Quick question: If I have the time, should I update the FUNCT backport 
and include it in 2.7.7?

#4371 is a couple of lines of code and necessary to avoid crashes 
with DUMP-FACE on iterated faces. it should be simple to add.

Pekr, the memory leak affects View ... and open ports

Pekr, Maarten and I found the leak years ago with rugby.

The main problem is that I will be hard-pressed to understand the 
implications of VID changes in the next 2 days. I don't currently 
understand the DUMP-FACE issue. If you can be sure of it and it can't 
wait a month, it can go in.

and Maarten also posted the same bug in 2005 http://www.rebol.net/cgi-bin/rambo.r?id=3593&

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.

Bobik greets you, welcomes R2 continued support, and suggest new 
naming scheme - we should rename R2 to R2D2 :-)

That's one of the cases for producing distinct packages for different 
Linux and BSD systems: that you can specify dependencies

Other than that, you'd have to include the libraries, and that is 
also problematic unless you link them statically

Carl, the crash Henrik reports is from one of our commercial apps. 
So the code is somehow big. We can provide you with a version of 
the code, or even better it would help us, if we can get an instrumented 
R2 version and than provide the output.

And that means?

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.

It's a full rewrite of a lot of the R2 mezzanines, making them less 
buggy and more R3 compatible.

It's a separate .r file, but its functions can be swapped into the 
SDK source and a new .exe built. And that is my task for the evening: 
to swap in the more R2-compatible functions in R2/Forward into the 
mezzanine source.

10 feet tall and blue?

Graham, I'm looking over your http scheme changes now. They won't 
maker the cut this release but should make the next release once 
it's been through the REBOL optimizer. The installer revamp didn't 
make this release either, though in theory the current installer 
might be working again. The 2.7.7 release has been mostly the licensing 
changes, a few native fixes, and the integration of a lot of R2/Forward 
backports and fixes.

You get SSL, ODBC and encryption for free in 2.7.7.

By the way, the backports include FUNCT, closures (faked), typesets 
(faked), the REFLECT and *-OF functions, APPLY, MAP-EACH, ...

Carl might even add the missing operators != and !== :)

R2 builds with the new changes! Yay! Time to go out and party!

wow, cool !! thanks to Brian and Carl for this !

I ohpe there is a base with ssl and all the stripped out view stuff.

Many thanks to BrianH and Carl !! 8-)

I guess people need to test the new builds and report any issues 
before other ones are built

The R2/Forward code is licensed (MIT), not donated. From now on, 
the aim of the R2/Forward project has changed. Now its main goal 
is to provide forward compatibility to old R2 versions. I'll be reorganizing 
the code accordingly, and trying to push support as far back as 2.5.0, 
the last version that is supported on the deprecated platforms.

The registry functions are unset before runtime in /Core and /View, 
for security reasons. They are available to SDK apps if necessary.

in my case, windows loads acrobat and loads demo.pdf

Since Reichart hasn't come back and said such and such deleted x 
groups .. I am presuming it is something quite different

Thank you Carl, Brian for updating the Rebol/View. SSL/TSL has become 
such key module of any serious internet trafic during last decade 
that it's important to be part of the widely available version. I'm 
sure there are plenty of other important Fixes and new features on 
this release, but at this point  with my  limited knowledge of Rebol 
variants (still trying to learn all there is at the 2.7... ) it's 
the thing for me.

For R3, we can get TLS, because the code would be in the open source 
portion. For R2 only the mezzanine changes are open source. This 
means that you'd have to ask Carl about TLS support - and he'll probably 
point you to REBOL Consulting :)

Release announcement: http://www.rebol.com/article/0447.html
Simple change notes: http://www.rebol.com/docs/v2-7.html


I'm trying to post the more detailed release notes in the comments 
of the announcement blog, but I'm getting caught by the blogger limits. 
One more message and I'll be done.

And incomplete - I'm waiting for it to let me post again,

The CLOSURE in 2.7.7 supercedes Ladislav's one, and is derived from 
it. Go Ladislav go!

The R3 manual is web accessible. R2/Forward itself is only useful 
to programmers, and they can and should use DevBase.

I went to the wiki .. and searched on funct ... didn't find the docs

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.

Right. The manual is the official docs (which need some work still), 
and the rebol.net wiki is for community stuff.

If you want to contribute to R2 development, get on R3 chat. The 
client is R3-only for now, but the server and message store will 
be the same when accessed from any other R3 or R2 clients, or web 
clients if we really want them.

For simplicity people refer to it as chat, but the server and message 
store is really DevBase 3. CHAT is just the name of the function 
built into R3 (and later R2) that calls a DevBase client script from 
some web server.

I put a full list of my changed and added features in the comments 
here: http://www.rebol.com/cgi-bin/blog.r?view=0447#comments

Once someone tells me where to put it I will put that information 
on the web.

Hmm..  Kinda creepy.. but then there is word   first+ and not first++ 
which would be logical..

FIRST+ was made first, a few years ago. ++ and -- were added months 
later. The prior vale is returned rather than the new value because 
it is the most useful thing to return. We're aware of the difference 
from C, but since postfix operations are impossible in REBOL we rather 
quickly remembered that C compatibility makes no difference to us 
whatsoever :)