At 4:45 PM +0200 10/11/02, Tels wrote:
-BEGIN PGP SIGNED MESSAGE-
Moin,
On 11-Oct-02 H.Merijn Brand carved into stone:
On Wed 02 Oct 2002 13:50, "H.Merijn Brand" <[EMAIL PROTECTED]> wrote:
As a start for a `normal' interface to the interperters internals, this
time
no open hack, bu
-BEGIN PGP SIGNED MESSAGE-
Moin,
On 11-Oct-02 H.Merijn Brand carved into stone:
> On Wed 02 Oct 2002 13:50, "H.Merijn Brand" <[EMAIL PROTECTED]> wrote:
>> As a start for a `normal' interface to the interperters internals, this
>> time
>> no open hack, but a neat interface.
>>
>> Very op
On Wed 02 Oct 2002 13:50, "H.Merijn Brand" <[EMAIL PROTECTED]> wrote:
> As a start for a `normal' interface to the interperters internals, this time
> no open hack, but a neat interface.
>
> Very open to additions.
>
> Useful?
>
> Feedback please
Thank you Dan!
Devel::Size from Dan Sugalski i
H.Merijn Brand <[EMAIL PROTECTED]> writes:
>
>Ahh, someone on /my/ side.
>
>I guess most of the discussion boils down to
>
>- sbrk () being unknown to people not familiar with unix
>- Devel::Internals being to wide. [ Gimme another namespace proposal ]
>- MemUsed interface to polymorphistic
>
>So
Michael G Schwern <[EMAIL PROTECTED]> writes:
>
>But you're not. You're just exposing sbrk(), which is a gory detail. My
>sbrk man page describes sbrk as being used to find "the current location of
>the program break" which means nothing to me. Nor does "returns the current
>memory top".
>
>It'l
-BEGIN PGP SIGNED MESSAGE-
Moin,
On 05-Oct-02 Slaven Rezic carved into stone:
> Tels <[EMAIL PROTECTED]> writes:
>> But shouldn't that be just the same, or slightly more (if the memory is
>> used in chunks of, let's say 16 bytes, it might alloc up to 15 more).?
>
> The malloc system wi
On Sat, Oct 05, 2002 at 03:50:34PM +0200, Tels wrote:
> Nevertheless, making your data structures smaller will help, even if in
> some particulare case it doesn't reduce the heap usage directly.
Yes, I found this to be true, but on my hitlist of things that make your
perl script slow, it was numb
Tels <[EMAIL PROTECTED]> writes:
> Moin,
>
> On 05-Oct-02 Slaven Rezic carved into stone:
> > Tels <[EMAIL PROTECTED]> writes:
> >
> >> -BEGIN PGP SIGNED MESSAGE-
> >>
> >> Moin,
> >>
> >> On 05-Oct-02 [EMAIL PROTECTED] carved into stone:
> >> > En op 5 oktober 2002 sprak Ann Barcomb:
-BEGIN PGP SIGNED MESSAGE-
Moin,
On 05-Oct-02 Slaven Rezic carved into stone:
> Tels <[EMAIL PROTECTED]> writes:
>
>> -BEGIN PGP SIGNED MESSAGE-
>>
>> Moin,
>>
>> On 05-Oct-02 [EMAIL PROTECTED] carved into stone:
>> > En op 5 oktober 2002 sprak Ann Barcomb:
>> >> I hadn't look
[EMAIL PROTECTED] writes:
> On Fri, Oct 04, 2002 at 08:24:12PM +0200, Slaven Rezic wrote:
> > Not a module, but a function which should work on FreeBSD and Linux:
>
> Why not package this up and stick it on CPAN? Proc::Memory or
> something.
Because it'a another module to maintain :-) The fun
Tels <[EMAIL PROTECTED]> writes:
> -BEGIN PGP SIGNED MESSAGE-
>
> Moin,
>
> On 05-Oct-02 [EMAIL PROTECTED] carved into stone:
> > En op 5 oktober 2002 sprak Ann Barcomb:
> >> I hadn't looked in to how I could solve my question, and because
> >> it was given to me as a low priority task,
Nicholas Clark <[EMAIL PROTECTED]> writes:
> On Thu, Oct 03, 2002 at 02:35:14PM -0400, Benjamin Goldberg wrote:
>
> > If "what it does" is merely return the value of the C sbrk() function,
> > then IMHO, sbrk() is a perfectly good name.
> >
> > However, as to other possible names -- how about P
-BEGIN PGP SIGNED MESSAGE-
Moin,
On 05-Oct-02 [EMAIL PROTECTED] carved into stone:
> En op 5 oktober 2002 sprak Ann Barcomb:
>> I hadn't looked in to how I could solve my question, and because
>> it was given to me as a low priority task, I wasn't sure I was going
>> to have a chance to
En op 5 oktober 2002 sprak Ann Barcomb:
> I hadn't looked in to how I could solve my question, and because
> it was given to me as a low priority task, I wasn't sure I was going
> to have a chance to either. But you can count me as someone who will
> be very happy about the module :)
I noticed C
Merijn wrote:
> Wait a while. Ann Barcomb is working on this too. Let's collect all this into
> one module and not release twenty or so that try to do the same.
I'm not actually working on it...I just had need of such a module
Thursday, mentioned to Jos what I had been trying to work on, and he
s
On Fri, Oct 04, 2002 at 08:24:12PM +0200, Slaven Rezic wrote:
> Not a module, but a function which should work on FreeBSD and Linux:
Why not package this up and stick it on CPAN? Proc::Memory or
something. It's a good start though you'll probably want
to do it File::Spec style with Proc::Memory
On Sat 05 Oct 2002 01:45, [EMAIL PROTECTED] wrote:
> On Fri, Oct 04, 2002 at 08:24:12PM +0200, Slaven Rezic wrote:
> > Not a module, but a function which should work on FreeBSD and Linux:
>
> Why not package this up and stick it on CPAN? Proc::Memory or
Wait a while. Ann Barcomb is working on t
On Thu, Oct 03, 2002 at 02:35:14PM -0400, Benjamin Goldberg wrote:
> If "what it does" is merely return the value of the C sbrk() function,
> then IMHO, sbrk() is a perfectly good name.
>
> However, as to other possible names -- how about ProcessSize() ? I'm
> not sure if this is really a valid
[EMAIL PROTECTED] writes:
> En op 4 oktober 2002 sprak Michael G Schwern:
> > The problem is when you put those two next to each other, one
> > promising a friendly interface, one a bare-metal interface,
> > it confuses the intent of the module. Is it for Joe End User
> > or is it for Joe Core Ha
Michael G Schwern <[EMAIL PROTECTED]> writes:
> On Thu, Oct 03, 2002 at 10:43:43AM +0100, Nicholas Clark wrote:
> > The reason I'm saying it might not be much use to people unfamiliar with
> > the internals of unix is precisely because it does return a precisely defined
> > but not directly usefu
[EMAIL PROTECTED] wrote:
> For a more fine-grained view, you
> need hooks into Perl internals (such as the Perl malloc).
This sounds like Devel::Peek::mstat(). But I never looked at this before.
En op 4 oktober 2002 sprak Michael G Schwern:
> The problem is when you put those two next to each other, one
> promising a friendly interface, one a bare-metal interface,
> it confuses the intent of the module. Is it for Joe End User
> or is it for Joe Core Hacker?
A module to report memory usag
Michael G Schwern wrote:
>
> On Wed, Oct 02, 2002 at 01:50:56PM +0200, H.Merijn Brand wrote:
> > SYNOPSIS
> > use Devel::Internals;
>
> A little broad. Perhaps Devel::Memory?
>
> > my $end = sbrk ();
> >
> > my @array = (1..1);
> > print "The creation of th
On Thu, Oct 03, 2002 at 10:43:43AM +0100, Nicholas Clark wrote:
> The reason I'm saying it might not be much use to people unfamiliar with
> the internals of unix is precisely because it does return a precisely defined
> but not directly useful value - the highest address on the heap.
> If you rea
On Thu, Oct 03, 2002 at 11:39:42AM -0400, Green, Paul wrote:
> H.Merijn Brand [mailto:[EMAIL PROTECTED]] writes:
> > So far, all I got was criticism. I asked for it. But no-one said it was
> useful.
> > (Or I didn't read between the lines enough).
>
> In my experience, the phrase "I really liked
H.Merijn Brand [mailto:[EMAIL PROTECTED]] writes:
> So far, all I got was criticism. I asked for it. But no-one said it was
useful.
> (Or I didn't read between the lines enough).
In my experience, the phrase "I really liked your idea and I hope you won't
mind if I share a few ideas for improving
At 01:01 PM 10/3/02 +0200, H.Merijn Brand wrote:
>So far, all I got was criticism. I asked for it. But no-one said it was
>useful.
>(Or I didn't read between the lines enough).
Well, since I probably have been the person that set this off, I think I
should say something here.
Ideally, I think
On Thu 03 Oct 2002 15:19, "Green, Paul" <[EMAIL PROTECTED]> wrote:
> sbrk is very Unixish.
I know. I'm not targetting Win32 (memory shortage is not an option, but a
feature) or OS/2. I was targetting my own problem/curiousity and probing the
usefulness of making it public.
My initial sbrk probe
sbrk is very Unixish. It isn't in POSIX at all. Our system is highly POSIX
compliant but doesn't have a function that directly maps to sbrk. We do
have a way of determining heap max size and heap current usage, but it is a
functional (subroutine) interface. If you had a function that just
calcul
> On Thu, 03 Oct 2002 13:01:52 +0200, "H.Merijn Brand" <[EMAIL PROTECTED]> said:
>> If it only returns the value from sbrk(), damn well call it sbrk.
> Ahh, someone on /my/ side.
Mee too.
> So far, all I got was criticism. I asked for it. But no-one said it was useful.
> (Or I didn'
On Thu 03 Oct 2002 11:43, Nicholas Clark <[EMAIL PROTECTED]> wrote:
> On Wed, Oct 02, 2002 at 05:07:20PM -0400, Michael G Schwern wrote:
> > On Wed, Oct 02, 2002 at 10:26:32PM +0200, H.Merijn Brand wrote:
>
> > > > I realize that sbrk() is a familiar concept to deep C programmers on
> > > > BSD-s
On Wed, Oct 02, 2002 at 05:07:20PM -0400, Michael G Schwern wrote:
> On Wed, Oct 02, 2002 at 10:26:32PM +0200, H.Merijn Brand wrote:
> > > I realize that sbrk() is a familiar concept to deep C programmers on
> > > BSD-style systems, but in order for this to be useful to Perl programmers,
> > > or
On Wed, Oct 02, 2002 at 10:26:32PM +0200, H.Merijn Brand wrote:
> > > SYNOPSIS
> > > use Devel::Internals;
> >
> > A little broad. Perhaps Devel::Memory?
>
> My intent was to gather more internal states. Whatever useful.
That's a potentially very large number of exported functions and
On Wed 02 Oct 2002 22:11, Michael G Schwern <[EMAIL PROTECTED]> wrote:
> On Wed, Oct 02, 2002 at 01:50:56PM +0200, H.Merijn Brand wrote:
> > SYNOPSIS
> > use Devel::Internals;
>
> A little broad. Perhaps Devel::Memory?
My intent was to gather more internal states. Whatever useful.
> >
On Wed, Oct 02, 2002 at 01:50:56PM +0200, H.Merijn Brand wrote:
> SYNOPSIS
> use Devel::Internals;
A little broad. Perhaps Devel::Memory?
> my $end = sbrk ();
>
> my @array = (1..1);
> print "The creation of this array used ",
> sbrk () - $end,
-BEGIN PGP SIGNED MESSAGE-
Moin,
On 02-Oct-02 Nicholas Clark carved into stone:
> On Wed, Oct 02, 2002 at 05:06:53PM +0200, Tels wrote:
>
>> On 02-Oct-02 H.Merijn Brand carved into stone:
>
> Going to be a bit hard to change, then :-)
:-)
>> > As a start for a `normal' interface to t
On Wed, Oct 02, 2002 at 05:06:53PM +0200, Tels wrote:
> On 02-Oct-02 H.Merijn Brand carved into stone:
Going to be a bit hard to change, then :-)
> > As a start for a `normal' interface to the interperters internals, this
> > time no open hack, but a neat interface.
> > Very open to additions.
-BEGIN PGP SIGNED MESSAGE-
Moin,
On 02-Oct-02 H.Merijn Brand carved into stone:
> As a start for a `normal' interface to the interperters internals, this
> time no open hack, but a neat interface.
> Very open to additions.
> Useful?
Is it accurate?
> Feedback please
>
>
> NAME
>
> MemUsed ($msg)
> Used in void context reports the number of bytes used since the
> previous call to MemUsed with the message passed
>
> Used in scalar context returns the current sbrk value
>
> Used in list context returns the values saved on every call
Ugh, no, seems ver
As a start for a `normal' interface to the interperters internals, this time
no open hack, but a neat interface.
Very open to additions.
Useful?
Feedback please
NAME
Devel-Internals - Perl extension for internal interpreter statistics
SYNOPSIS
use Devel::Internals;
my
Michael G Schwern <[EMAIL PROTECTED]> writes:
> Giving read() semantics completely unrelated to reading a filehandle would
> be a bad choice of syntax.
I wonder what the people who implemented the GNU/Linux "procfs" think
about this.
-- Johan
At 10:28 AM 8/30/02 -0400, Bryan C. Warnock wrote:
>Why not a simple(!) magic hash, or an entire namespace?
>print $PROC{"memory used"};
>print $PROC::memory_used;
That would work for me... ;-)
Liz
On Fri, 2002-08-30 at 04:30, H.Merijn Brand wrote:
> I was thinking about highjacking a standard function: read ()
>
> read filehandle, $var, length [, offset]
>
> and use it like
>
> read [ \"PERL_status" ], $mem, "memory";
>
> which is very illegal at the moment :) but probably easy to catc
-BEGIN PGP SIGNED MESSAGE-
Moin,
On 30-Aug-02 H.Merijn Brand carved into stone:
> On Fri 30 Aug 2002 10:33, Elizabeth Mattijsen <[EMAIL PROTECTED]> wrote:
>> At 10:30 AM 8/30/02 +0200, H.Merijn Brand wrote:
>> > > Being able to do so at any point in Perl's execution would be
>> > great.
On Fri 30 Aug 2002 11:02, Michael G Schwern <[EMAIL PROTECTED]> wrote:
> On Fri, Aug 30, 2002 at 10:30:22AM +0200, H.Merijn Brand wrote:
> > I was thinking about highjacking a standard function: read ()
>
> Giving read() semantics completely unrelated to reading a filehandle would
> be a bad choi
On Fri, Aug 30, 2002 at 10:30:22AM +0200, H.Merijn Brand wrote:
> I was thinking about highjacking a standard function: read ()
Giving read() semantics completely unrelated to reading a filehandle would
be a bad choice of syntax. So would making it a keyword. Could you do it
(mostly) via XS?
On Fri 30 Aug 2002 10:33, Elizabeth Mattijsen <[EMAIL PROTECTED]> wrote:
> At 10:30 AM 8/30/02 +0200, H.Merijn Brand wrote:
> > > Being able to do so at any point in Perl's execution would be
> > great. Or is
> > > there such a thing already and I just don't know about it (and I'm not
> > > thin
At 10:30 AM 8/30/02 +0200, H.Merijn Brand wrote:
> > Being able to do so at any point in Perl's execution would be
> great. Or is
> > there such a thing already and I just don't know about it (and I'm not
> > thinking about GTop)...
>I was thinking about highjacking a standard function: read ()
On Fri 30 Aug 2002 10:15, Elizabeth Mattijsen <[EMAIL PROTECTED]> wrote:
> At 08:56 AM 8/30/02 +0200, H.Merijn Brand wrote:
> >Would it be a helpful indication to be able to have perl report the upper
> >memmory bound on exit? Or better, the memory used: upper- minus lower bound
>
> Being able to
At 08:56 AM 8/30/02 +0200, H.Merijn Brand wrote:
>Would it be a helpful indication to be able to have perl report the upper
>memmory bound on exit? Or better, the memory used: upper- minus lower bound
Being able to do so at any point in Perl's execution would be great. Or is
there such a thing
50 matches
Mail list logo
