World: r3wp

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.

I'll look at your patches :)

I also remember some patches to http by Oldes or someone else, I 
just don't remember details ...

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.

The UI should really be split out, if it's not already done in R3 
chat. But don't forget that we already have bots for R3 chat.

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

I think we're off topic

Yes, thank you.

Henrik ... is that memory leak still present?

Graham, I believe so.

I've avoided creating UIs with too much networking with open ports.

R2/Forward location: R3 chat 837 - Community/Libraries/R2-Forward

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

I read also that that Brian's vid resizing scheme works well too 
... does it break any old vid stuff?

No PARSE improvements this release unless Carl has a ready bugfix. 
Fixes to DECODE-URL are fair game though.

Resize doesn't break anything, however it's been re-used in the VID 
extension kit with some modifications, which I don't think are compatible.

The resizing scheme is too difficult to use yet - it needs better 
integration. Not going in this release.

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

'run should be easy to add?  It was present in IOS

BrianH: Thanks... I would like to make it more a collaborative effort 
eventually. There are many things that need to be done, but I'm going 
to dive heavily into R3 in 2010.

I think 'launch is broken at present ... dunno if there is time to 
fix that as well as it only affects the sdk

I can't answer about run, Graham. I've never used IOS.

LAUNCH affects the View desktop too. How is it broken? Is there a 
RAMBO bug report about this?

>> help run
USAGE:
    RUN file /as suffix

DESCRIPTION:
     Runs the system application associated with a file.
     RUN is a native value.

ARGUMENTS:

     file -- The file to open (file, URL) or command to run (string). 
     (Type: file url string)

REFINEMENTS:
     /as
         suffix -- (Type: string file)
>> run "screen.png"
** Script Error: Feature not available in this REBOL
** Near: run "screen.png"

I think I would have posted a bug report about 'launch ..

Oh, it's like CALL "start"

I am against parse enhancements being backported to R2, or ppl will 
have one less reason to move to R3 :-) Also - there are some changes 
to R3 Parse, which could cause R2 parse scripts stop to work ...

btw - what memory leak are we talking about here? Networking? It 
might be difficult to track in current timeframe, no?

http://www.rebol.net/cgi-bin/rambo.r?id=4205&

Pekr, there are PARSE bugs in R2, particularly with the BREAK operation. 
This kind of thing will eventually get fixed in R2.

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

This isn't a backport of the model - that kind of thing can be handled 
by a rule compiler.

dunno about anton's report http://www.rebol.net/cgi-bin/rambo.r?id=4245&

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

Graham - is the leak reported anywhere? I mean - do we have some 
code example, when it happens?

Of note: I would not easily have found that memory leak if it wasn't 
for Instruments on OSX. It's a really nice tool.

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

Henrik reduced the leak to the smallest example

Henrik, that #4371 fix sounds like a good candidate for 2.7.7.

It was one of the reasons I had to stop using rugby I think ...

BrianH, as long as the functionality is agreed with. It will dump 
the first face rendered in an iterated face. That's the only issue.

Graham, I noticed it, when I was wondering why a simple two-button 
UI program with a bit of rugby networking ate up 500 MB RAM.

I posted this report in 2004 http://www.rebol.net/cgi-bin/rambo.r?id=3557&

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.

that's half a decade ago

Graham, live in the now. We're switching to the rapid release model. 
The old complaints don't apply :)

I was just pointing out to Pekr that this problem is real