World: r3wp

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

That it is. We'll definitely be looking it over :)

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

Henrik, if your minimal code to replicate the problem is posted somewhere 
we'd like to see it.

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.

A code example that doesn't need %rugby.r to replicate woult be nice,

oops.. this was an altme bug ... I only highlighted the last paragraph!!

Sorry, I already typed that. Thanks.

BrianH, ok, Carl would know about it, so I'll discuss it with him. 
Regarding leak, it's in RAMBO, need to find the ID, hang on.