objectivelib-discussion — Discussion of ObjectiveLib

[Objectivelib-discussion] Release 1.0.0

[Will M. <wil...@us...>]

ObjectiveLib 1.0.0 has just been released. The main addition to this release is the ability to use ObjectiveLib outside the context of GNUstep or Cocoa. ObjectiveLib can now be configured at build time to rely only on the existence of the Objective-C runtime.

Cheers,
Will

[Objectivelib-discussion] Apologies

[Will M. <wil...@us...>]

I apologize for the delay of the 1.0 release of ObjectiveLib. I've been distracted with other projects and with life. The code has been written but the unit tests and the documentation have not. I can't commit to a specific date, but I hope to release ObjectiveLib 1.0 soon. Anyone who would like to help out is more than welcome!

Thanks for the patience,
Will Mason

Re: [Objectivelib-discussion] Memory allocator removal?

[Will M. <wil...@us...>]

I still haven't made any decisions on this issue. If I remove OL memory
allocators, then I also remove any possibility of users being able to
control the internal memory management of OL containers. If I don't,
then I guarantee that the in-place memory management system will not do
what users expect on non-Cocoa/GNUstep systems.

Which is the lesser of the two bad things?

Thanks for any help,
Will

--- Will Mason <wil...@us...> wrote:

> Thanks very much for getting back to me on this issue, Daniel. I
> really
> appreciate your input.
> 
> I've been giving this a lot of thought. The upside is that I let
> everyone else worry about memory management. The downside is that
> users
> will no longer have any control over how collections manage their
> memory. Theoretically, I could make sure that under Cocoa/GNUstep
> every
> object would be copied with the zone indicated by copyWithZone:, but
> that sounds like a lot of not-very-productive work, especially since
> all of that would go out the window in a non-Cocoa/GNUstep
> environment.
> 
> It's hard to imagine a solution that uses ObjectiveLib memory
> allocators that isn't half-baked, but part of me wonders whether
> that's
> just because I'm not creative enough. The only reason I considered
> specialized memory allocators to begin with was because they were an
> integral part of STL, but how many people actually use custom
> allocators in STL? I've used STL professionally for years and never
> even considered them once. I'll bet more than 99% of users would
> report
> a similar usage pattern.
> 
> Anyway, having someone tell me what they think is really helpful. And
> in this case, Daniel, you were the primary motivator behind what I'm
> dealing with now, so you owe it to me to participate in the
> discussion.
> 
> Thanks very much,
> Will
> 
> --- Daniel Rasmussen <ra...@cs...> wrote:
> 
> > That sounds like a good solution. Although potentially useful,  
> > allocators aren't needed, and alloc/dealloc would be consistent
> with 
> > 
> > everything else. Better to leave allocators out than try to fudge  
> > around with half-baked solutions.
> > 
> > -Daniel
> > 
> > 
> > On Aug 1, 2005, at 4:27 PM, Will Mason wrote:
> > 
> > > I'm in the process of eliminating dependencies on Cocoa/GNUstep
> for
> > > ObjectiveLib. The memory allocator code barely works under
> > > Cocoa/GNUstep, but it completely fails in an Object-based system.
> > The
> > > reason is that instead of using retain/release to hang onto and
> un-
> > 
> > > hang
> > > onto objects, you have to copy the object and later free it.  
> > > There's no
> > > way to rely on a generic copy method for any given class that
> will 
> > 
> > > make
> > > use of a desired allocator, as the copy-related methods in Object
> > have
> > > no knowledge of ObjectiveLib memory allocators. This means that
> > > although an OLVector, for example, can allocate its memory cache
> > using
> > > a given allocator, it can't copy the objects that it manages
> using
> > a
> > > given allocator. This results in half-baked memory management.
> > >
> > > I'm considering eliminating memory allocators as they currently
> > exist
> > > in ObjectiveLib in favor of letting people fall back to
> overriding
> > > alloc and free/dealloc in order to get specialized memory
> > management
> > > for a given class. This will work equally well with all
> > ObjectiveLib
> > > classes and all other classes, too.
> > >
> > > I was hoping to get some feedback on this idea before I gut the  
> > > system.
> > >
> > > Thanks for any advice,
> > > Will
> > 
> > 
> > -------------------------------------------------------
> > SF.Net email is sponsored by: Discover Easy Linux Migration
> > Strategies
> > from IBM. Find simple to follow Roadmaps, straightforward articles,
> > informative Webcasts and more! Get everything you need to get up to
> > speed, fast.
> http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> > _______________________________________________
> > Objectivelib-discussion mailing list
> > Obj...@li...
> >
> https://lists.sourceforge.net/lists/listinfo/objectivelib-discussion
> > 
> 
> 
> 
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration
> Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> Objectivelib-discussion mailing list
> Obj...@li...
> https://lists.sourceforge.net/lists/listinfo/objectivelib-discussion
> 

Re: [Objectivelib-discussion] Memory allocator removal?

[Will M. <wil...@us...>]

Thanks very much for getting back to me on this issue, Daniel. I really
appreciate your input.

I've been giving this a lot of thought. The upside is that I let
everyone else worry about memory management. The downside is that users
will no longer have any control over how collections manage their
memory. Theoretically, I could make sure that under Cocoa/GNUstep every
object would be copied with the zone indicated by copyWithZone:, but
that sounds like a lot of not-very-productive work, especially since
all of that would go out the window in a non-Cocoa/GNUstep environment.

It's hard to imagine a solution that uses ObjectiveLib memory
allocators that isn't half-baked, but part of me wonders whether that's
just because I'm not creative enough. The only reason I considered
specialized memory allocators to begin with was because they were an
integral part of STL, but how many people actually use custom
allocators in STL? I've used STL professionally for years and never
even considered them once. I'll bet more than 99% of users would report
a similar usage pattern.

Anyway, having someone tell me what they think is really helpful. And
in this case, Daniel, you were the primary motivator behind what I'm
dealing with now, so you owe it to me to participate in the discussion.

Thanks very much,
Will

--- Daniel Rasmussen <ra...@cs...> wrote:

> That sounds like a good solution. Although potentially useful,  
> allocators aren't needed, and alloc/dealloc would be consistent with 
> 
> everything else. Better to leave allocators out than try to fudge  
> around with half-baked solutions.
> 
> -Daniel
> 
> 
> On Aug 1, 2005, at 4:27 PM, Will Mason wrote:
> 
> > I'm in the process of eliminating dependencies on Cocoa/GNUstep for
> > ObjectiveLib. The memory allocator code barely works under
> > Cocoa/GNUstep, but it completely fails in an Object-based system.
> The
> > reason is that instead of using retain/release to hang onto and un-
> 
> > hang
> > onto objects, you have to copy the object and later free it.  
> > There's no
> > way to rely on a generic copy method for any given class that will 
> 
> > make
> > use of a desired allocator, as the copy-related methods in Object
> have
> > no knowledge of ObjectiveLib memory allocators. This means that
> > although an OLVector, for example, can allocate its memory cache
> using
> > a given allocator, it can't copy the objects that it manages using
> a
> > given allocator. This results in half-baked memory management.
> >
> > I'm considering eliminating memory allocators as they currently
> exist
> > in ObjectiveLib in favor of letting people fall back to overriding
> > alloc and free/dealloc in order to get specialized memory
> management
> > for a given class. This will work equally well with all
> ObjectiveLib
> > classes and all other classes, too.
> >
> > I was hoping to get some feedback on this idea before I gut the  
> > system.
> >
> > Thanks for any advice,
> > Will
> 
> 
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration
> Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> Objectivelib-discussion mailing list
> Obj...@li...
> https://lists.sourceforge.net/lists/listinfo/objectivelib-discussion
> 

Re: [Objectivelib-discussion] Memory allocator removal?

[Daniel R. <ra...@cs...>]

That sounds like a good solution. Although potentially useful,  
allocators aren't needed, and alloc/dealloc would be consistent with  
everything else. Better to leave allocators out than try to fudge  
around with half-baked solutions.

-Daniel


On Aug 1, 2005, at 4:27 PM, Will Mason wrote:

> I'm in the process of eliminating dependencies on Cocoa/GNUstep for
> ObjectiveLib. The memory allocator code barely works under
> Cocoa/GNUstep, but it completely fails in an Object-based system. The
> reason is that instead of using retain/release to hang onto and un- 
> hang
> onto objects, you have to copy the object and later free it.  
> There's no
> way to rely on a generic copy method for any given class that will  
> make
> use of a desired allocator, as the copy-related methods in Object have
> no knowledge of ObjectiveLib memory allocators. This means that
> although an OLVector, for example, can allocate its memory cache using
> a given allocator, it can't copy the objects that it manages using a
> given allocator. This results in half-baked memory management.
>
> I'm considering eliminating memory allocators as they currently exist
> in ObjectiveLib in favor of letting people fall back to overriding
> alloc and free/dealloc in order to get specialized memory management
> for a given class. This will work equally well with all ObjectiveLib
> classes and all other classes, too.
>
> I was hoping to get some feedback on this idea before I gut the  
> system.
>
> Thanks for any advice,
> Will

[Objectivelib-discussion] Memory allocator removal?

[Will M. <wil...@us...>]

I'm in the process of eliminating dependencies on Cocoa/GNUstep for
ObjectiveLib. The memory allocator code barely works under
Cocoa/GNUstep, but it completely fails in an Object-based system. The
reason is that instead of using retain/release to hang onto and un-hang
onto objects, you have to copy the object and later free it. There's no
way to rely on a generic copy method for any given class that will make
use of a desired allocator, as the copy-related methods in Object have
no knowledge of ObjectiveLib memory allocators. This means that
although an OLVector, for example, can allocate its memory cache using
a given allocator, it can't copy the objects that it manages using a
given allocator. This results in half-baked memory management.

I'm considering eliminating memory allocators as they currently exist
in ObjectiveLib in favor of letting people fall back to overriding
alloc and free/dealloc in order to get specialized memory management
for a given class. This will work equally well with all ObjectiveLib
classes and all other classes, too.

I was hoping to get some feedback on this idea before I gut the system.

Thanks for any advice,
Will

Re: [Objectivelib-discussion] Looks like I might get to open the bidding :-)

[Daniel R. <ult...@gm...>]

On Jul 22, 2005, at 1:48 PM, Will Mason wrote:

> Hi, Rod,
> How could we not be kind in responding to the first actual question
> posted to the list. To answer your question, you can't put simple data
> types in containers, just objects. Fortunately, Cocoa and GNUstep
> provide a convenient wrapper for primitive data types, NSNumber. You
> can do this:
>
> OLVector* v = [OLVector vector];
> [v pushBack: [NSNumber numberWithDouble: 3.14]];
>
> Check the docs for NSNumber to see how it works. Let me know if you
> need anything else,
> Will
>

NSNumber presents one of those revealing aspects of the Objective-C  
philosophy. Rather than templates, which can get troublesome, it's  
nothing to create a class that can work with any object,  
unfortunately leaving out basic data types.

Additionally, if you're ever interested in wrapping other forms of  
non-object data (such as structs or pointers), take a look at  
NSNumber's super class, NSValue. It's incredibly useful and isn't  
advertised enough.

-Daniel

Re: [Objectivelib-discussion] Looks like I might get to open the bidding :-)

[Will M. <wil...@us...>]

Hi, Rod,
How could we not be kind in responding to the first actual question
posted to the list. To answer your question, you can't put simple data
types in containers, just objects. Fortunately, Cocoa and GNUstep
provide a convenient wrapper for primitive data types, NSNumber. You
can do this:

OLVector* v = [OLVector vector];
[v pushBack: [NSNumber numberWithDouble: 3.14]];

Check the docs for NSNumber to see how it works. Let me know if you
need anything else,
Will

--- rodkirkpatrick <rod...@op...> wrote:

>     Hi
> 
> Firstly a warning - newbie question coming - be kind :-)
> 
> Are the standard data types and limits still there when using  
> containers or am I missing the point - for instance are floats and  
> ints still the same size ?
> 
> Rod
> 
> 
> 
> 
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration
> Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> Objectivelib-discussion mailing list
> Obj...@li...
> https://lists.sourceforge.net/lists/listinfo/objectivelib-discussion
> 

[Objectivelib-discussion] Looks like I might get to open the bidding :-)

[rodkirkpatrick <rod...@op...>]

    Hi

Firstly a warning - newbie question coming - be kind :-)

Are the standard data types and limits still there when using  
containers or am I missing the point - for instance are floats and  
ints still the same size ?

Rod

[Objectivelib-discussion] ObjectiveLib version 0.10 released

[Will M. <wil...@us...>]

ObjectiveLib version 0.10 has just been released. New features include:

* A full set of binary streams which includes: file, memory buffer and
socket streams, as well as streams that can buffer and compress data.
Three different compression streams are provided. 
* A set of classes making creation and usage of BSD sockets easy and
painless.

Also, numerous bug fixes were done and some of the API that didn't
conform to Cocoa naming conventions was changed.

Have fun,
Will

[Objectivelib-discussion] ObjectiveLib version 0.9 released

[Will M. <wil...@us...>]

Version 0.9 of ObjectiveLib has been released. Please visit
http://sourceforge.net/projects/objectivelib/ to download the new
release. The new features included in version 0.9 are:
 
* Support for the GNUstep platform, which is tested on many different
systems. See the file Build.html in the source release for details. 
* All containers and function objects now support the NSCoding
protocol. 
* All containers and function objects now have class methods that are
convenience allocators. These methods allocate, initialize and
autorelease instances of the class before returning. 

Please write to the list with any questions are issues regarding this
new release. Thanks,
Will

[Objectivelib-discussion] Hey, y'all

[Will M. <wil...@us...>]

I figured it would be appropriate to use the word y'all with y'all.
Tom, Russell has joined the list. Now the three of us can finally
discuss containers and algorithms like we've wanted to do ever since
Russell and I were in 7th grade. Okay, maybe not.

Later,
Will

[Objectivelib-discussion] Testing

[Will M. <tor...@ya...>]

I'm just testing the list. Testing is good.

Will