World: r3wp

I repeat: I find the technical arguments very hard to believe

That's your perogative, since you haven't seen the code, and haven't 
discussed the code with Carl.

I'm not going to defend RT against trolls anymore, because they are 
proven right this way

I don't need to see the code, because it's very simple: there's Pro, 
and you only have to disable some parts of it

I agree.

rebview278 still fails when run in a non-X environment. So `Change 
"bad face in screen pane" issue on non-X env boot` was not done.

That seemed to be a business consideration a year ago, so I was hoping 
it carried some weight

Andreas, the changes doc wasn't updated yet. Most of the native changes 
that didn't have checkmarks next to them weren't done. This was a 
minimal release, so some stuff got put off to 2.7.9. Give me a moment 
and I will try to list the changes in that list that were in this 
release.

Nevermind. Prompted by Kaj mentioning it previously, I was just checking 
if this was fixed in 2.7.8 and found it it wasn't.

Instead of access-os there are also new natives list-env and set-env

BrianH: what are you talking about? Wasn't /shell and /library released 
for the /Core for free already?

talking any "revenue" in regards to RT and business, is quite funny 
imo ...

Not Library

yes, it was IIRC ...

No, it doesn't work on my systems, and I've discussed it extensively 
a year ago

or was it released for View?

Yes, View, which doesn't work on headless servers - game over

ah,now I finally understand, thanks ...

Isn't it just a cut&past of code then? Max few hours work?

I would think so

Kaj - still no option to switch to R3 + Extensions then? Or are we 
referring any existing product, which would need to be ported, e.g. 
Cheyenne itself?

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

Petr, it's not even a concrete problem for me anymore if Cheyenne 
now works properly. What keeps getting to me are the broken promises 
that destroy my planning and my trust

There are likely also other changes I don't know about.

I hope that the "Command boot problem" will be fixed in 2.7.8, it 
was one of the biggest regression in 2.7.7 (IIRC, it was causing 
scripts encapped with a /Command kernel to crash on start).

Kaj - now you start being negative ... like I was several weeks ago. 
Well, don't even ask me, what I think about the situation - it is 
no more funny. No matter what, SCRUM or not, Carl is still not predictable, 
which has side effects on some of you ...

Yes, that's what bothers me most, that my limit has also been reached 
several times

I know I'm crazy, so if my limit is reached, most everyone else is 
long gone

Well, 14 years ago I said I am going to be the last one, turning 
off the lights :-) So once I find out I am the last one logging here 
for more than 3 months, I delete all rebol related stuff :-)

Doc, was that on Linux or on all platforms? If the problem arises 
on Windows, do you have an example script that I can test? Then again, 
this might be the reason for the SDK delay.

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

Well, we should probably move to advocacy, sooner than guys will 
kick-us off from here :-)

Um, I wasn't going to say anything, but yeah, Advocacy.

Well, I've already switched channels for this

That was when we thought you were discussing R2 releases, not losing 
faith.

Advocay doesn't sound like the right term for my current sentiment, 
either

True, you aren't advocating negativity - that's Shadwolf's domain 
:)

BrianH: the problem was seen on Windows, not sure about Linux 2.7.7, 
but I can confirm that the problem hasn't showed up on Linux 2.7.8. 
For the script, I have one from a customer showing up the problem, 
I need to shrink it and test if again first.

BrianH: the problem happens with any script encapped with encmd and 
enpro 2.7.7.3.1. I just tried with: REBOL [ ] print "hello". The 
error pops up when the encapped exe is launched. An alert window 
displays: REBOL Internal Error: Boot error: 316.

Strangely, encmdview is not affected by this issue.

I tested this script for all the encappers of 2.7.8 (not officially 
released yet) with this script:
REBOL [] print "hello" halt
All succeeded, and all apps worked.

Thanks, glad to hear that.

continued from REBOL3! group.


they where not listed in RAMBO... I was just lucky to be online with 
Carl and it got fixed in a beta version of 2.7.7 in one afternoon 
with cyphre giving a more robust fix the day after.


 He also had the fix to another annoying issue which makes first item 
 to follow a space in a text to affect the transparency.  the more 
 spaces the darker it gets.  his even affects other items in a text 
 ends with spaces ! 

though I wonder if that ended up in the 2.7.8 release ' :-/

they = AGG fixes (mainly one which crashes AGG if using several gradients 
in the same block).

Cyphre had the second fix, but Carl disapeared then and it never 
got included AFAIK, so it may be in 2.7.8 though Cyphre would have 
to confirm this.

oops... "his even affects other items in a text ends with spaces 
!"


== this even affects other items (like a box) if it follows a text 
which ends with spaces!

I discovered the bug while typing in a text field and the color of 
the field changed whenever I typed in a space!


It took me a while to realize it was a problem in AGG and not in 
my code... :-)

I am still arguing for US date inputs as an option ... sure we can 
fake it, but it would be nice to have

We don't have to fake it, we can make addon functions to handle this. 
That's what community libraries are for.

eh??