World: r3wp

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

Henrik .. I just posted it.

Next month we'll be migrating RAMBO to CureCode, then retiring it. 
It's best to continue using it for now though.

Graham, where? Oddly, I can't find it now.

at the end of my long post

Ah, there it is. I thought I had put it in RAMBO.

Later, all!

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

is there ODBC equivalent for Linux REBOL?

well now.... I just had a crash in 2.7.6. Thought that would be a 
little on-topic:

---------------------------
REBOL Error
---------------------------
REBOL Internal Error: Invalid series width 1 was 16 (type 39)

Program terminated abnormally.
This should never happen.
Contact www.REBOL.com with details.
---------------------------
OK   
---------------------------

A string was a block.

  You will need to provide example code in order to track it down.

Pekr, R2D2... good one.


On ODBC in Linux, was problematic in the past due to no cross-distro 
standard lib for it. Perhaps that has changed in modern times?

There was always a de facto standard ODBC library for Linux, but 
as always, that doesn't mean it's installed on a system

Ok, thanks Kaj for clarifying it.

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.