LCB shell?

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

LCB shell?

mwieder
Is the shell command/function available in extensions? I'm getting
script parsing errors that seem like they might indicate that it's not,
and the dictionary isn't conclusive on that issue. If it's not available
for extensions, is there an alternative? I've got a script stack library
that I'm trying to make into an extension, and I'm tripping over the syntax.

Somewhere there should be a list of LCS-LCB translations. So far today
I've already found

LCS              LCB
the platform <-> the operating system

--
  Mark Wieder
  [hidden email]

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
--
 Mark Wieder
 ahsoftware@gmail.com
Reply | Threaded
Open this post in threaded view
|

Re: LCB shell?

Thierry Douez
Hi Mark,

Not sure if this will help you, but anyway
it's an interesting post.

http://blog.peter-b.co.uk/2015/09/using-c-library-functions-from-livecode.html

Regards,

Thierry


2016-06-10 3:37 GMT+02:00 Mark Wieder <[hidden email]>:

> Is the shell command/function available in extensions? I'm getting script
> parsing errors that seem like they might indicate that it's not, and the
> dictionary isn't conclusive on that issue. If it's not available for
> extensions, is there an alternative? I've got a script stack library that
> I'm trying to make into an extension, and I'm tripping over the syntax.
>
> Somewhere there should be a list of LCS-LCB translations. So far today
> I've already found
>
> LCS              LCB
> the platform <-> the operating system
>
> --
>  Mark Wieder
>  [hidden email]
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>



--
------------------------------------------------
Thierry Douez - http://sunny-tdz.com
sunnYrex - sunnYtext2speech - sunnYperl - sunnYmidi - sunnYmage
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

hasMemory

mwieder
On 06/09/2016 07:35 PM, Thierry Douez wrote:
> Hi Mark,
>
> Not sure if this will help you, but anyway
> it's an interesting post.

Fortunately you and I have similar definitions of "interesting" <g>

Unfortunately it's no real help for what I was trying. After spending
part of a day playing around with LCB, I'm concluding it's really not
worth the effort. I got all excited seeing some of what Dar's been
turning out, but I can't see there's anything to gain by turning a
working library into an extension, and a lot of wasted time to lose.

Here's a working cross-platform replacement for the flaky built-in
hasMemory function.

/**
* Return the number of free bytes
*/

on mouseUp
    put freeMemory() && "bytes" into field 1
    put cr & hasMem(2000000) after field 1
end mouseUp

function hasMem pDesiredBytes
    return freeMemory() > pDesiredBytes
end hasMem

function freeMemory
    local tPlatform
    local tFreeMem

    put the platform into tPlatform
    if "Mac" is in tPlatform then
       put availableMemOSX() into tFreeMem
    else if "Win" is in tPlatform then
       put availableMemWindows() into tFreeMem
    else
       put availableMemLinux() into tFreeMem
    end if
    return tFreeMem
end freeMemory

private function availableMemOSX
    local tFreeMem
    local tPageSize
    local tFreePages

    put shell ("vm_stat -c 1 1") into tFreeMem
    put word -2 of line 1 of tFreeMem into tPageSize
    put word 1 of line -1 of tFreeMem into tFreePages
    return tFreePages * tPageSize / 1024
end availableMemOSX

private function availableMemWindows
    local tFreeMem

    put shell ("wmic OS get FreePhysicalMemory /Value") into tFreeMem
    set the linedelimiter to "="
    return line -1 of tFreeMem * 1024
end availableMemWindows

private function availableMemLinux
    local tFreeMem

    put shell ("vmstat -s") into tFreeMem
    filter tFreeMem with "*free memory"
    return word 1 of tFreeMem * 1024
end availableMemLinux

--
  Mark Wieder
  [hidden email]

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
--
 Mark Wieder
 ahsoftware@gmail.com
Reply | Threaded
Open this post in threaded view
|

Re: hasMemory

Mark Waddingham-2
On 2016-06-10 06:14, Mark Wieder wrote:
> Here's a working cross-platform replacement for the flaky built-in
> hasMemory function.

The builtin 'hasMemory' function is not flaky - the question it asks
just has no meaning on modern operating systems (and should probably
actually be removed!).

For example, change your mouseUp to this:

on mouseUp
    put freeMemory() into tBytesAvailable

    repeat with i = 1 to tBytesAvailable * 4
       put "a" after tString
    end repeat

    put "apparently there were" && tBytesAvailable && \
        "bytes of memory available" & return after field 1
    put "but I managed to allocate a string which requires" && \
        the length of tString && "bytes" & return after field 1
end mouseUp

And try running it on a modern Mac (although I have no reason to suspect
it would be different on any other platform we support). In my case I
got:

    apparently there were 8894284 bytes of memory available
    but I managed to allocate a string which requires 35577136 bytes

The concept of 'free memory' on multi-user, pre-emptive, user/kernel
space split operating systems doesn't exist as the kernel allocates any
physical resources it has (including disk space to provide virtual
memory) to where it is needed at any point it wishes.

For example, a large amount of physical memory pages at any one time is
likely to be used to cache blocks on disks for files which are currently
in use. As the majority of these pages (those which have not been
modified in memory) can be dumped at any time, that measure does not
reflect how much memory any one process could allocate. Similarly,
processes which are inactive and consuming physical memory are likely to
have most of their memory usage paged to disk (i.e. into virtual memory)
when another active process needs more memory.

Warmest Regards,

Mark.

P.S. The 'hasMemory' function in LiveCode actually does the best it can
do - it sees if it can allocate a contiguous block of memory of the size
that has been requested (using malloc) and if that succeeds, it frees
the block and returns true. This should mean that (assuming nothing on
the system suddenly consumes all physical and virtual ram) you should be
able to do an action which requires that amount of memory immediately
after:

void MCLegacyEvalHasMemory(MCExecContext& ctxt, uinteger_t p_bytes,
bool& r_bool)
{
        char *t_buffer = nil;
        r_bool = nil != (t_buffer = (char*)malloc(p_bytes));
        free(t_buffer);
}

--
Mark Waddingham ~ [hidden email] ~ http://www.livecode.com/
LiveCode: Everyone can create apps

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: hasMemory

Mark Waddingham-2
On 2016-06-10 10:05, Mark Waddingham wrote:

> P.S. The 'hasMemory' function in LiveCode actually does the best it
> can do - it sees if it can allocate a contiguous block of memory of
> the size that has been requested (using malloc) and if that succeeds,
> it frees the block and returns true. This should mean that (assuming
> nothing on the system suddenly consumes all physical and virtual ram)
> you should be able to do an action which requires that amount of
> memory immediately after:
>
> void MCLegacyEvalHasMemory(MCExecContext& ctxt, uinteger_t p_bytes,
> bool& r_bool)
> {
>   char *t_buffer = nil;
>   r_bool = nil != (t_buffer = (char*)malloc(p_bytes));
>   free(t_buffer);
> }

As an addendum, Fraser just reminded that even this is entirely useless
on Linux.

When you request more memory to a process on Linux, the kernel will
happily grant *all* requests which will fit in the address space - it
allocates pages (whether they be physical or virtual) *lazily*. So you
can quite happily do malloc(2^46) and it will succeed... You'll just get
a SEGV at some point later when there are no pages anywhere left. (Linux
has an overcommit policy - i.e. it does not use the number of possibly
available pages to determine how much address space it will give each
process).

Warmest Regards,

Mark.

--
Mark Waddingham ~ [hidden email] ~ http://www.livecode.com/
LiveCode: Everyone can create apps


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: hasMemory

Richard Gaskin
In reply to this post by mwieder
Mark Wieder wrote:

 > After spending part of a day playing around with LCB, I'm concluding
 > it's really not worth the effort. I got all excited seeing some of
 > what Dar's been turning out, but I can't see there's anything to gain
 > by turning a working library into an extension, and a lot of wasted
 > time to lose.

LC Builder is very exciting for the things that distinguish it:
providing a means of encapsulating custom controls in Widgets far more
cleanly for the end-user than is currently possible with groups, and for
accessing binary APIs from system components.

But like Kevin says, of the three options we have for writing code that
can be executed in LC (externals written in C, LC Builder, and LC
Script), LC Script is the fastest to develop in, so it remains an
excellent choice.

After all, LC Builder is not here to replace LC Script, but to augment it.

What's working well in LC Script should for the most part remain working
going forward, getting only better and ever more capable where LC
Builder can add things that may be needed.  But where LC Builder isn't
necessary LC Script is fine by itself.

LC Script is, after all, the primary language of LiveCode and the reason
we're all here.  It isn't going away.  Continue to enjoy it.

--
  Richard Gaskin
  Fourth World Systems
  Software Design and Development for the Desktop, Mobile, and the Web
  ____________________________________________________________________
  [hidden email]                http://www.FourthWorld.com


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: hasMemory

Richard Gaskin
In reply to this post by Mark Waddingham-2
Mark Waddingham wrote:

 > On 2016-06-10 06:14, Mark Wieder wrote:
 >> Here's a working cross-platform replacement for the flaky built-in
 >> hasMemory function.
 >
 > The builtin 'hasMemory' function is not flaky - the question it asks
 > just has no meaning on modern operating systems (and should probably
 > actually be removed!).

For all the reasons you mentioned (thanks for the details; I love
learning from your longer posts) what you say here makes good sense.

But I would also suggest what Mark Wieder is after is also useful,
though perhaps very different.

 From time to time it's useful to know how much RAM may be available to
an application, to make decisions about loading data.

Wieder's script seems to handle that, though I agree that it does seem
to be solving a very different problem from the hasMemory function.

--
  Richard Gaskin
  Fourth World Systems
  Software Design and Development for the Desktop, Mobile, and the Web
  ____________________________________________________________________
  [hidden email]                http://www.FourthWorld.com


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: hasMemory

Peter TB Brett
On 10/06/2016 16:31, Richard Gaskin wrote:

> From time to time it's useful to know how much RAM may be available to
> an application, to make decisions about loading data.

No, it isn't useful.  Don't do this.

At the very best, you'll have a Time-of-check-to-time-of-use error (i.e.
you check a condition time X, and do something that assumes the
condition at time Y, but in the intervening time something happens
elsewhere in the system that invalidates the condition).  And on most
operating systems, the result will be total lies.

Just go ahead and load the data.  If it fails, then try a smaller chunk.

                                           Peter

--
Dr Peter Brett <[hidden email]>
LiveCode Technical Project Manager

LiveCode 2016 Conference: https://livecode.com/edinburgh-2016/

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: hasMemory

Richard Gaskin
Peter TB Brett wrote:

 > On 10/06/2016 16:31, Richard Gaskin wrote:
 >
 >> From time to time it's useful to know how much RAM may be available
 >> to an application, to make decisions about loading data.
 >
 > No, it isn't useful.  Don't do this.
 >
 > At the very best, you'll have a Time-of-check-to-time-of-use error
 > (i.e. you check a condition time X, and do something that assumes the
 > condition at time Y, but in the intervening time something happens
 > elsewhere in the system that invalidates the condition).  And on most
 > operating systems, the result will be total lies.
 >
 > Just go ahead and load the data.  If it fails, then try a smaller
 > chunk.

I once got the same advice from Mark Lucas, the lead engineer for
SuperCard, so it would be foolish for me to disregard the same guidance
so consistently offered.

The challenge, however, is that currently most xTalks, including
LiveCode, sometimes have difficulty reporting errors in low-memory
conditions.  When bad enough, it can sometimes cause a crash before
we're able to check "the result" and apply any remedy.

Any advice for working gracefully in potentially RAM-taxing routines?

--
  Richard Gaskin
  Fourth World Systems
  Software Design and Development for the Desktop, Mobile, and the Web
  ____________________________________________________________________
  [hidden email]                http://www.FourthWorld.com


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: hasMemory

mwieder
In reply to this post by Mark Waddingham-2
Mark Waddingham <mark@...> writes:

> As an addendum, Fraser just reminded that even this is entirely useless
> on Linux.

OK - 'flaky' was a bad choice of words here. Point taken.

And yes, the replacement for the hasMemory function was actually just
an afterthought. What I really was after is what the OS thinks is the amount
of free non-virtual ram, for use in error reporting.

Since all modern operating systems will happily dish out virtual memory
and swap things around, I agree that seeing if you can allocate a block of
memory of a given size is somewhat less useful. What might be more useful,
though, is determining whether swap space is being used, which could have
significant impact on program responsiveness.

--
 Mark Wieder
 [hidden email]





_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
--
 Mark Wieder
 ahsoftware@gmail.com
Reply | Threaded
Open this post in threaded view
|

Re: hasMemory

Mark Waddingham-2
On 2016-06-10 18:46, Mark Wieder wrote:
> Since all modern operating systems will happily dish out virtual memory
> and swap things around, I agree that seeing if you can allocate a block
> of
> memory of a given size is somewhat less useful. What might be more
> useful,
> though, is determining whether swap space is being used, which could
> have
> significant impact on program responsiveness.

The Mac OS X Activity Monitor on El Capitan has a 'memory pressure'
graph which is what it sounds like what you were looking for - I'm
guessing this is a measure for memory, a bit like the CPU load factor.

Of course, how Activity Monitor calculates this value is not clear - it
certainly isn't just a function of physical memory usage as I'm
currently using 10Gb/16Gb (i.e. 63%) and my memory pressure graph is as
low as it gets. I suspect it is some function of various factors (number
of paging requests, quantity of wired pages, free disk space etc.) which
increases more and more rapidly as the amount of virtual memory and
physical memory available approaches zero.

Warmest Regards,

Mark.

--
Mark Waddingham ~ [hidden email] ~ http://www.livecode.com/
LiveCode: Everyone can create apps


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: hasMemory

mwieder
In reply to this post by Richard Gaskin
Richard Gaskin <ambassador@...> writes:

> The challenge, however, is that currently most xTalks, including
> LiveCode, sometimes have difficulty reporting errors in low-memory
> conditions.  When bad enough, it can sometimes cause a crash before
> we're able to check "the result" and apply any remedy.

Yes, that is of course what I'm aiming for. There have been problems
in the past with LC (or at least RunRev) misbehaving under low physical
memory conditions, and that's difficult to catch an replicate. Of course,
this all depends on the engine still functioning well enough to handle the
memory reporting functions, so it may just be moot after all.

--
 Mark Wieder
 [hidden email]



_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
--
 Mark Wieder
 ahsoftware@gmail.com
Reply | Threaded
Open this post in threaded view
|

Re: hasMemory

mwieder
In reply to this post by Richard Gaskin
Richard Gaskin <ambassador@...> writes:

> What's working well in LC Script should for the most part remain working
> going forward, getting only better and ever more capable where LC
> Builder can add things that may be needed.  But where LC Builder isn't
> necessary LC Script is fine by itself.

My (somewhat faulty thinking) was that the script-only library stack might
make an interesting extension library (not widget), so with that small a code
base to work with I thought I'd experiment. LCB looks promising for other things,
but as you mentioned, it's for different purposes. I thought extension widgets
might be custom controls, but I see I'll have to narrow my definition.

--
 Mark Wieder
 [hidden email]




_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
--
 Mark Wieder
 ahsoftware@gmail.com