Re: [Factor-talk] manual memory management and STRUCT:

2014-03-19 Thread Bruce Breeanna Rennie
Good evening gentlefolks,


On 19/03/14 15:42, factor-talk-requ...@lists.sourceforge.net wrote:
 Message: 1
 Date: Tue, 18 Mar 2014 16:44:07 +0100
 From: Bj?rn Lindqvist bjou...@gmail.com
 Subject: Re: [Factor-talk] manual memory management and STRUCT:
 To: factor-talk@lists.sourceforge.net
 Message-ID:
 calg+76ern5tg6-3ug4u7mhgu5obpkkdsce4ub4fby81wmrp...@mail.gmail.com
 Content-Type: text/plain; charset=ISO-8859-1

 2014-03-18 14:12 GMT+01:00 Jon Harper jon.harpe...@gmail.com:
 In this case, it's more complicated then a single with-destructor scope,
 because I use the destructors to call libyaml's destroy function on the
 struct, so that the same memory can be reused between the calls to
libyaml
 for this struct. So I really need to destroy it right away before the
next
 call the libyaml, hence the nested with-destructors.

 I could allocate new memory for those structs every time and destroy them
 only at the end of the parsing. But in most cases, only one struct is
needed
 at a given time, so I thought reusing them was a good thing.
 Jon

 I think you're falling for the premature optimization trap
 here. Allocating memory is incredibly cheap so unless your code is
 memory constrained there is no need to save on it. It's always better to
 start with the simplest implementation you can get away with and then
 if you run into performance problems start to optimize it.


 --
 mvh/best regards Bj?rn Lindqvist


More subtle problem is creating a situation where the intent can get
lost. The intent is to use a single structure for the entire process. If
at a later stage, you need two or more, this may have ramifications to
the code you have already written. If you make the code agnostic to the
number of structs, you can at alter stage determine what your real
requirements are.

As mentioned above, this can be a premature optimisation trap or it can
be a case of being too clever when simpler code would be better. The
latter process makes future changes including optimisations harder to
do. I am not talking about algorithms here but interactions between
different parts of the code that can be lost (including things like
setting state in one place and using that state in another without there
being a clear logical sequence).

The KISS principle and OCCAM's RAZOR are both good principles to follow
in situations like this.

At any rate, my 5 cents worth (smaller currency unit we have in practise)

Bruce Rennie


--
Learn Graph Databases - Download FREE O'Reilly Book
Graph Databases is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/13534_NeoTech
___
Factor-talk mailing list
Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk


Re: [Factor-talk] manual memory management and STRUCT:

2014-03-18 Thread Björn Lindqvist
Hi Jon,

2014-03-17 21:57 GMT+01:00 Jon Harper jon.harpe...@gmail.com:
 Hi list,
 I am working with libyaml, a C library to parse yaml docs. Some libyaml
 functions give string results by malloc'ing memory and giving back pointers
 to those strings in a struct. They then require the caller to call a libyaml
 destroy function on the struct that frees the strings.

 I would like to make a deep copy of the manually managed struct to a garbage
 collected struct so that I can keep some data after I called the libyaml
 destroy function and not worry about freeing it. Does anyone know how to do
 this simply ?

Let me preface this by saying that I'm far from an expert neither on
libyaml or factor... But this is what I think I've figured out about
how alien memory management works.

What I think you are doing wrong is worrying to much about freeing the
memory you are allocating. The ?scalar-value word is only an
intermediate step in the doc parsing process. Since the yaml words
body already is wrapped in a with-destructors block, and it is the
main entry point for your parser, you don't need to call
with-destructors anywhere else.

Just remember to pair every allocation (or resource acquisition) with a
destructor word (which you already are doing) and factor should work
it out fine.


--
mvh/best regards Björn Lindqvist

--
Learn Graph Databases - Download FREE O'Reilly Book
Graph Databases is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/13534_NeoTech
___
Factor-talk mailing list
Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk


Re: [Factor-talk] manual memory management and STRUCT:

2014-03-18 Thread Jon Harper
In this case, it's more complicated then a single with-destructor scope,
because I use the destructors to call libyaml's destroy function on the
struct, so that the same memory can be reused between the calls to libyaml
for this struct. So I really need to destroy it right away before the next
call the libyaml, hence the nested with-destructors.

I could allocate new memory for those structs every time and destroy them
only at the end of the parsing. But in most cases, only one struct is
needed at a given time, so I thought reusing them was a good thing.
Jon

On Tue, Mar 18, 2014 at 12:21 PM, Björn Lindqvist bjou...@gmail.com wrote:

 Hi Jon,

 2014-03-17 21:57 GMT+01:00 Jon Harper jon.harpe...@gmail.com:
  Hi list,
  I am working with libyaml, a C library to parse yaml docs. Some libyaml
  functions give string results by malloc'ing memory and giving back
 pointers
  to those strings in a struct. They then require the caller to call a
 libyaml
  destroy function on the struct that frees the strings.
 
  I would like to make a deep copy of the manually managed struct to a
 garbage
  collected struct so that I can keep some data after I called the libyaml
  destroy function and not worry about freeing it. Does anyone know how to
 do
  this simply ?

 Let me preface this by saying that I'm far from an expert neither on
 libyaml or factor... But this is what I think I've figured out about
 how alien memory management works.

 What I think you are doing wrong is worrying to much about freeing the
 memory you are allocating. The ?scalar-value word is only an
 intermediate step in the doc parsing process. Since the yaml words
 body already is wrapped in a with-destructors block, and it is the
 main entry point for your parser, you don't need to call
 with-destructors anywhere else.

 Just remember to pair every allocation (or resource acquisition) with a
 destructor word (which you already are doing) and factor should work
 it out fine.


 --
 mvh/best regards Björn Lindqvist


 --
 Learn Graph Databases - Download FREE O'Reilly Book
 Graph Databases is the definitive new guide to graph databases and their
 applications. Written by three acclaimed leaders in the field,
 this first edition is now available. Download your free book today!
 http://p.sf.net/sfu/13534_NeoTech
 ___
 Factor-talk mailing list
 Factor-talk@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/factor-talk

--
Learn Graph Databases - Download FREE O'Reilly Book
Graph Databases is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/13534_NeoTech___
Factor-talk mailing list
Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk


Re: [Factor-talk] manual memory management and STRUCT:

2014-03-18 Thread Björn Lindqvist
2014-03-18 14:12 GMT+01:00 Jon Harper jon.harpe...@gmail.com:
 In this case, it's more complicated then a single with-destructor scope,
 because I use the destructors to call libyaml's destroy function on the
 struct, so that the same memory can be reused between the calls to libyaml
 for this struct. So I really need to destroy it right away before the next
 call the libyaml, hence the nested with-destructors.

 I could allocate new memory for those structs every time and destroy them
 only at the end of the parsing. But in most cases, only one struct is needed
 at a given time, so I thought reusing them was a good thing.
 Jon

I think you're falling for the premature optimization trap
here. Allocating memory is incredibly cheap so unless your code is
memory constrained there is no need to save on it. It's always better to
start with the simplest implementation you can get away with and then
if you run into performance problems start to optimize it.


--
mvh/best regards Björn Lindqvist

--
Learn Graph Databases - Download FREE O'Reilly Book
Graph Databases is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/13534_NeoTech
___
Factor-talk mailing list
Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk


[Factor-talk] manual memory management and STRUCT:

2014-03-17 Thread Jon Harper
Hi list,
I am working with libyaml, a C library to parse yaml docs. Some libyaml
functions give string results by malloc'ing memory and giving back pointers
to those strings in a struct. They then require the caller to call a
libyaml destroy function on the struct that frees the strings.

I would like to make a deep copy of the manually managed struct to a
garbage collected struct so that I can keep some data after I called the
libyaml destroy function and not worry about freeing it. Does anyone know
how to do this simply ?

For now, I'm using the following workaround:
https://github.com/jonenst/factor/commit/545287e377ecc4722155e42deaf8dcfa779f8358

cheers,
Jon
--
Learn Graph Databases - Download FREE O'Reilly Book
Graph Databases is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/13534_NeoTech___
Factor-talk mailing list
Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk