From: Brother-Peter on
"claptonhendrix" <claptonhendrix(a)gmail.com> wrote in message
news:1133875114.741046.170440(a)g47g2000cwa.googlegroups.com...
> The most important reason is the memory managment of the calculator.
> A library will be stored in a port (0, 1, 2) since a variable will be
> stored in the ram memory directly.
> As you have 0 port with memory shared with te RAM, using it for storing
> a library is less convenient than using 1 port (127 kB) or 2 port
> (almost 900 kB).

You can't easily store into a variable inside a library
it's better to create tem in user RAM

Library programs are hided from average joe
(but not from Mean Joe ;)

a lot of libraries can fit into the port 2 (Flash)
and thus leave main RAM free

....


From: Joe Horn on
"claptonhendrix" writes:

> The most important reason is the memory managment of the calculator.
> A library will be stored in a port (0, 1, 2) since a variable will be
> stored in the ram memory directly.

Just in case it isn't obvious, regular programs in regular variables
can also be saved in a port and run from there, thus also freeing up
main memory. Although it will be copied to temporary memory when run,
so are library programs, so there's no benefit with libraries on that
account.

Example: If you have two large programs called 'FOO' and 'BAR' in main
memory, move them to Port 3 and then create the following "stub"
programs in main memory:

<< :3:FOO EVAL >> 'FOO' STO
<< :3:BAR EVAL >> 'BAR' STO

FOO and BAR will now work like they did before, but they're no longer
taking up permanent space in main memory. Even programs that call FOO
and BAR will run as they did before.

-jkh-

From: Brother-Peter on
"Joe Horn" <joehorn(a)holyjoe.net> wrote in message
news:1133909676.896053.82290(a)g44g2000cwa.googlegroups.com...
> "claptonhendrix" writes:
>
>> The most important reason is the memory managment of the calculator.
>> A library will be stored in a port (0, 1, 2) since a variable will be
>> stored in the ram memory directly.
>
> Just in case it isn't obvious, regular programs in regular variables
> can also be saved in a port and run from there, thus also freeing up
> main memory. Although it will be copied to temporary memory when run,
> so are library programs, so there's no benefit with libraries on that
> account.
>
> Example: If you have two large programs called 'FOO' and 'BAR' in main
> memory, move them to Port 3 and then create the following "stub"
> programs in main memory:
>
> << :3:FOO EVAL >> 'FOO' STO
> << :3:BAR EVAL >> 'BAR' STO
>
> FOO and BAR will now work like they did before, but they're no longer
> taking up permanent space in main memory. Even programs that call FOO
> and BAR will run as they did before.

Nice!
I wonder if the good old :&:FOO still works as it used to be
or was it so that it now seeks from 0 to 3 instead of 2 to 0
user RAM should be the last place to check
Anyway with that syntax you have more freedom


From: Joe Horn on
Brother-Peter writes:

> I wonder if the good old :&:FOO still works as it used to be
> or was it so that it now seeks from 0 to 3 instead of 2 to 0
> user RAM should be the last place to check

The 49g+ searches in this order: Port 0, 1, 2, 3, then main memory.

Strangely, :n:FOO does not only refer to FOO in port n; it will resolve
to FOO in main memory if FOO does not exist in port n. Whether that's a
misfeature or a misbug is unclear.

-jkh-

From: Brother-Peter on
"Joe Horn" <joehorn(a)holyjoe.net> wrote in message
news:1133994235.485589.275770(a)g49g2000cwa.googlegroups.com...
> Brother-Peter writes:
>
>> I wonder if the good old :&:FOO still works as it used to be
>> or was it so that it now seeks from 0 to 3 instead of 2 to 0
>> user RAM should be the last place to check
>
> The 49g+ searches in this order: Port 0, 1, 2, 3, then main memory.
>
> Strangely, :n:FOO does not only refer to FOO in port n; it will resolve
> to FOO in main memory if FOO does not exist in port n. Whether that's a
> misfeature or a misbug is unclear.

I like this new feature
Naturally, if we could have more than 128 flags....