www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Unmanaged - a D framework on github

reply "D-ratiseur" <ThisAdressDoesntExist nowhere.fr> writes:
Hello, I'd like to introduce the "Unmanaged" framework.
It's a OOP library, strongly inspired by the Delphi/Pascal RTL.

Its main concept is to bypass the GC. From this statement, the 
library feaures:
- main unmanaged object and memory routines
- a parameterized list
- an ownership system (used to automate the destroying of object)
- a parentship system
- a serialization system...
- etc work in progress.

This library is developped in the same time I learn D, but 
comming from Delphi, it's inspired by its class system  (but it's 
not a copy at all).
Unmanaged is tested under win32 an linux64. Basic build scripts 
are provided for both systems and code review are welcome.

you can track the project on github:

https://github.com/BBasile/Unmanaged

Hey.
Mar 13 2013
next sibling parent "alex" <info alexanderbothe.com> writes:
On Wednesday, 13 March 2013 at 16:20:08 UTC, D-ratiseur wrote:

 Hello, I'd like to introduce the "Unmanaged" framework.
 It's a OOP library, strongly inspired by the Delphi/Pascal RTL.

 Its main concept is to bypass the GC. From this statement, the 
 library feaures:
 - main unmanaged object and memory routines
 - a parameterized list
 - an ownership system (used to automate the destroying of 
 object)
 - a parentship system
 - a serialization system...
 - etc work in progress.

 This library is developped in the same time I learn D, but 
 comming from Delphi, it's inspired by its class system  (but 
 it's not a copy at all).
 Unmanaged is tested under win32 an linux64. Basic build scripts 
 are provided for both systems and code review are welcome.

 you can track the project on github:

 https://github.com/BBasile/Unmanaged

 Hey.


Pascal case identifiers <3 - Looks great!
Mar 13 2013
prev sibling next sibling parent "Martin" <martinbbjerregaard gmail.com> writes:
On Wednesday, 13 March 2013 at 16:20:08 UTC, D-ratiseur wrote:

 Hello, I'd like to introduce the "Unmanaged" framework.
 It's a OOP library, strongly inspired by the Delphi/Pascal RTL.

 Its main concept is to bypass the GC. From this statement, the 
 library feaures:
 - main unmanaged object and memory routines
 - a parameterized list
 - an ownership system (used to automate the destroying of 
 object)
 - a parentship system
 - a serialization system...
 - etc work in progress.

 This library is developped in the same time I learn D, but 
 comming from Delphi, it's inspired by its class system  (but 
 it's not a copy at all).
 Unmanaged is tested under win32 an linux64. Basic build scripts 
 are provided for both systems and code review are welcome.

 you can track the project on github:

 https://github.com/BBasile/Unmanaged

 Hey.


This looks nice. Like really, really nice. Much more appealing to
me than the std library to be honest.
Mar 13 2013
prev sibling next sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
On Wednesday, 13 March 2013 at 16:20:08 UTC, D-ratiseur wrote:

 Hello, I'd like to introduce the "Unmanaged" framework.
 It's a OOP library, strongly inspired by the Delphi/Pascal RTL.

 Its main concept is to bypass the GC. From this statement, the 
 library feaures:
 - main unmanaged object and memory routines
 - a parameterized list
 - an ownership system (used to automate the destroying of 
 object)
 - a parentship system
 - a serialization system...
 - etc work in progress.

 This library is developped in the same time I learn D, but 
 comming from Delphi, it's inspired by its class system  (but 
 it's not a copy at all).
 Unmanaged is tested under win32 an linux64. Basic build scripts 
 are provided for both systems and code review are welcome.

 you can track the project on github:

 https://github.com/BBasile/Unmanaged

 Hey.


Can you give some code sample so we can have an idea of what it
is ?
Mar 13 2013
parent reply "D-ratiseur" <ThisAdressDoesntExist nowhere.fr> writes:
On Wednesday, 13 March 2013 at 18:01:20 UTC, deadalnix wrote:

 On Wednesday, 13 March 2013 at 16:20:08 UTC, D-ratiseur wrote:

 Hello, I'd like to introduce the "Unmanaged" framework.
 It's a OOP library, strongly inspired by the Delphi/Pascal RTL.

 Its main concept is to bypass the GC. From this statement, the 
 library feaures:
 - main unmanaged object and memory routines
 - a parameterized list
 - an ownership system (used to automate the destroying of 
 object)
 - a parentship system
 - a serialization system...
 - etc work in progress.

 This library is developped in the same time I learn D, but 
 comming from Delphi, it's inspired by its class system  (but 
 it's not a copy at all).
 Unmanaged is tested under win32 an linux64. Basic build 
 scripts are provided for both systems and code review are 
 welcome.

 you can track the project on github:

 https://github.com/BBasile/Unmanaged

 Hey.


 Can you give some code sample so we can have an idea of what it
 is ?


Not really, a sample woulds look like one of the unittest. But 
looking at the previous answer, it's not like the D runtime, it's 
more a "framework" based on the minimal dmd distribution (so some 
std functions are used, some strings stuff,some error 
suff,...).It's not a RTL (run time library, such as phobos), it's 
a framework which provides a way to make trees, to serialize and 
uppon everything to bypass the garbage collector. It's more 
focused on the structure and it's definitively not a replacement 
to something.
Mar 13 2013
parent reply Ellery Newcomer <ellery-newcomer utulsa.edu> writes:
On 03/13/2013 11:30 AM, D-ratiseur wrote:


 uppon everything to bypass the garbage
 collector.


In that case, I call foul.

FAddr.length = FAddr.length + 1;

types.d#L281

Wait, what? You're using classes everywhere and.. ohhhhhhh. you're 
overriding new. Nifty. Don't know if that's been deprecated or not, but 
I'm pretty sure Andrei hates it and wants it to die.

The delete statement is deprecated in favor of object.destroy or something.

For struct ULongRec, shouldn't some of your twiddly stuff be wrapped in 
version(LittleEndian) ?
Mar 13 2013
next sibling parent reply David <d dav1d.de> writes:
Am 14.03.2013 03:03, schrieb Ellery Newcomer:

 On 03/13/2013 11:30 AM, D-ratiseur wrote:
 

 uppon everything to bypass the garbage
 collector.


 
 In that case, I call foul.
 
 FAddr.length = FAddr.length + 1;
 
 types.d#L281
 
 Wait, what? You're using classes everywhere and.. ohhhhhhh. you're
 overriding new. Nifty. Don't know if that's been deprecated or not, but
 I'm pretty sure Andrei hates it and wants it to die.


Afaik it is deprecated which really sucks imo.


 The delete statement is deprecated in favor of object.destroy or something.


object.destroy()(UFCS) and clib.free(object) (If it was allocated with
malloc/calloc and friends)
Mar 15 2013
parent reply "Jakob Ovrum" <jakobovrum gmail.com> writes:
On Friday, 15 March 2013 at 10:23:05 UTC, David wrote:

 Afaik it is deprecated which really sucks imo.


I don't know why the new operator is so important to some people. 
If templates had been in C++ before classes, this operator would 
probably never have existed.


 object.destroy()(UFCS) and clib.free(object) (If it was 
 allocated with
 malloc/calloc and friends)


A pair of templated functions dealing with C++ style new/delete 
can be trivially composed using malloc-emplace and destroy-free.
Mar 15 2013
parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Fri, 15 Mar 2013 13:11:13 +0100
"Jakob Ovrum" <jakobovrum gmail.com> wrote:


 On Friday, 15 March 2013 at 10:23:05 UTC, David wrote:

 Afaik it is deprecated which really sucks imo.


 
 I don't know why the new operator is so important to some people. 
 If templates had been in C++ before classes, this operator would 
 probably never have existed.
 


I'm not so sure that it's "new is important" so much as:

1. The custom allocator stuff isn't ready yet.

2. "Meh, 'new' never hurt me, what's with all the hate?"
Mar 15 2013
prev sibling parent reply "D-ratiseur " <ThisAdressDoesntExist nowhere.fr> writes:
On Thursday, 14 March 2013 at 02:03:56 UTC, Ellery Newcomer wrote:

 On 03/13/2013 11:30 AM, D-ratiseur wrote:


 uppon everything to bypass the garbage
 collector.


 In that case, I call foul.

 FAddr.length = FAddr.length + 1;

 types.d#L281

 Wait, what? You're using classes everywhere and.. ohhhhhhh. 
 you're overriding new. Nifty. Don't know if that's been 
 deprecated or not, but I'm pretty sure Andrei hates it and 
 wants it to die.

 The delete statement is deprecated in favor of object.destroy 
 or something.

 For struct ULongRec, shouldn't some of your twiddly stuff be 
 wrapped in version(LittleEndian) ?


new is overriden in TUObject because the purpose of the library 
is to bypass the garbage collector and  to bypass the GC you have 
to override new and delete.(at least according to the manual: 
articles,mem managment).

And yes, classes are used everywhere. I've read in the D 
guidlines that interdependent classes should be avoid (IIRC the 
reason for this is to make the maintenance easyer)...but it's 
just like that, by design. The classes hold some data and some 
methods usefull for their descendants...don't they ?

About the ULongRec, yes maybe...

But I recognize that I've been a bit "overenthusiastic" in this 
announce, I should have waited a few weeks...Anyway I'll finish 
this lib, everything is here, the class structure is clear.
Mar 16 2013
parent reply "Jakob Ovrum" <jakobovrum gmail.com> writes:
On Saturday, 16 March 2013 at 14:40:58 UTC, D-ratiseur wrote:

 new is overriden in TUObject because the purpose of the library 
 is to bypass the garbage collector and  to bypass the GC you 
 have to override new and delete.(at least according to the 
 manual: articles,mem managment).


The documentation on this is old and misleading.

Overloading of new and delete is deprecated (the delete operator 
in its entirety is deprecated).

Having them overloadable was not a very good idea. The current 
approach is to have "new" always mean GC memory, which is why 
there is no need for delete. This way, code that uses 'new' won't 
break horribly or leak depending on the type involved, important 
for generic code. Code that doesn't use the GC has to be designed 
for it; you can't just remove the GC under everyone's noses and 
expect things to work.

For different kinds of memory, you should simply use a different 
allocator. For example, here's a rough approximation of a pair of 
functions using malloc/free for class allocation:

T alloc(T)() if(is(T == class))
{
	enum size = __traits(classInstanceSize, T);
	auto p = enforceEx!OutOfMemoryError(malloc(size));
	return emplace!T(p[0 .. size]);
}

void dealloc(T)(ref T obj) if(is(T == class))
{
     free(cast(void*)obj);
     obj = null;
}

It can easily be overloaded to support all types.

In the future, Phobos will have a custom memory allocator 
library, which modules like std.container will use, though to 
which extent is not clear (for example, will it also use the 
custom allocator for exception objects?). Nevertheless it will 
probably be a good base for other libraries to easily support 
non-GC allocators.
Mar 17 2013
next sibling parent "D-ratiseur " <ThisAdressDoesntExist nowhere.fr> writes:
On Sunday, 17 March 2013 at 15:20:04 UTC, Jakob Ovrum wrote:

 On Saturday, 16 March 2013 at 14:40:58 UTC, D-ratiseur wrote:

 new is overriden in TUObject because the purpose of the 
 library is to bypass the garbage collector and  to bypass the 
 GC you have to override new and delete.(at least according to 
 the manual: articles,mem managment).


 The documentation on this is old and misleading.

 Overloading of new and delete is deprecated (the delete 
 operator in its entirety is deprecated).

 Having them overloadable was not a very good idea. The current 
 approach is to have "new" always mean GC memory, which is why 
 there is no need for delete. This way, code that uses 'new' 
 won't break horribly or leak depending on the type involved, 
 important for generic code. Code that doesn't use the GC has to 
 be designed for it; you can't just remove the GC under 
 everyone's noses and expect things to work.

 For different kinds of memory, you should simply use a 
 different allocator. For example, here's a rough approximation 
 of a pair of functions using malloc/free for class allocation:

 T alloc(T)() if(is(T == class))
 {
 	enum size = __traits(classInstanceSize, T);
 	auto p = enforceEx!OutOfMemoryError(malloc(size));
 	return emplace!T(p[0 .. size]);
 }

 void dealloc(T)(ref T obj) if(is(T == class))
 {
     free(cast(void*)obj);
     obj = null;
 }

 It can easily be overloaded to support all types.

 In the future, Phobos will have a custom memory allocator 
 library, which modules like std.container will use, though to 
 which extent is not clear (for example, will it also use the 
 custom allocator for exception objects?). Nevertheless it will 
 probably be a good base for other libraries to easily support 
 non-GC allocators.


Thx, that's some very usefull info...however curently "Unmanaged"
have its own leak tracer, basically it's a compiler switch that
allows to record every call to alloc(), realloc() and free().
Once again there must be a kind of misunderstanding about the
lib. It's made to bypass the GC...and it's not under everybody
nose ! I clearly state about this and the code is made for that
purpose.
Anyway, it's possible that I've been, until now, a bit naive
about the manual...For example in the win chm, object classinfo
pretends to have this member:
---
const(MemberInfo[]) getMembers(in char[] name);
Search for all members with the name 'name'. If name[] is null,
return all members".
---
Which is the most mysterious method ever...since it seems not
exist at all... ;)
Mar 18 2013
prev sibling next sibling parent "Lars T. Kyllingstad" <public kyllingen.net> writes:
On Sunday, 17 March 2013 at 15:20:04 UTC, Jakob Ovrum wrote:

 For different kinds of memory, you should simply use a 
 different allocator. For example, here's a rough approximation 
 of a pair of functions using malloc/free for class allocation:

 T alloc(T)() if(is(T == class))
 {
 	enum size = __traits(classInstanceSize, T);
 	auto p = enforceEx!OutOfMemoryError(malloc(size));
 	return emplace!T(p[0 .. size]);
 }


I know this was just a rough example, but I just wanted to point 
this out:  It is not a good idea to use enforceEx() here, since 
a) it uses new to allocate memory for the exception, and b) you 
shouldn't try to allocate at all when you're out of memory.  :)

Use core.exception.onOutOfMemory() to signal an allocation 
failure instead.  It throws a pre-allocated OutOfMemoryError.

Lars
Mar 19 2013
prev sibling parent reply Benjamin Thaut <code benjamin-thaut.de> writes:
Am 17.03.2013 16:20, schrieb Jakob Ovrum:

 On Saturday, 16 March 2013 at 14:40:58 UTC, D-ratiseur wrote:

 new is overriden in TUObject because the purpose of the library is to
 bypass the garbage collector and  to bypass the GC you have to
 override new and delete.(at least according to the manual:
 articles,mem managment).


 The documentation on this is old and misleading.

 Overloading of new and delete is deprecated (the delete operator in its
 entirety is deprecated).

 Having them overloadable was not a very good idea. The current approach
 is to have "new" always mean GC memory, which is why there is no need
 for delete. This way, code that uses 'new' won't break horribly or leak
 depending on the type involved, important for generic code. Code that
 doesn't use the GC has to be designed for it; you can't just remove the
 GC under everyone's noses and expect things to work.

 For different kinds of memory, you should simply use a different
 allocator. For example, here's a rough approximation of a pair of
 functions using malloc/free for class allocation:

 T alloc(T)() if(is(T == class))
 {
      enum size = __traits(classInstanceSize, T);
      auto p = enforceEx!OutOfMemoryError(malloc(size));
      return emplace!T(p[0 .. size]);
 }

 void dealloc(T)(ref T obj) if(is(T == class))
 {
      free(cast(void*)obj);
      obj = null;
 }

 It can easily be overloaded to support all types.

 In the future, Phobos will have a custom memory allocator library, which
 modules like std.container will use, though to which extent is not clear
 (for example, will it also use the custom allocator for exception
 objects?). Nevertheless it will probably be a good base for other
 libraries to easily support non-GC allocators.


You still can't replace evertything with custom alloc templates and have 
nice syntax. There are at least two cases where it does not work nicely:

1) Arrays (no new T [size] syntax)
2) Inner classes (a template can't automatically capture the outer class)

So I think overloading new and delete actually has its place. But the 
way it is currently implemented in D is useless in my eyes.

Kind Regards
Benjamin Thaut
Mar 20 2013
next sibling parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Wednesday, 20 March 2013 at 07:57:13 UTC, Benjamin Thaut wrote:

 Am 17.03.2013 16:20, schrieb Jakob Ovrum:

 On Saturday, 16 March 2013 at 14:40:58 UTC, D-ratiseur wrote:

 new is overriden in TUObject because the purpose of the 
 library is to
 bypass the garbage collector and  to bypass the GC you have to
 override new and delete.(at least according to the manual:
 articles,mem managment).


 The documentation on this is old and misleading.

 Overloading of new and delete is deprecated (the delete 
 operator in its
 entirety is deprecated).

 Having them overloadable was not a very good idea. The current 
 approach
 is to have "new" always mean GC memory, which is why there is 
 no need
 for delete. This way, code that uses 'new' won't break 
 horribly or leak
 depending on the type involved, important for generic code. 
 Code that
 doesn't use the GC has to be designed for it; you can't just 
 remove the
 GC under everyone's noses and expect things to work.

 For different kinds of memory, you should simply use a 
 different
 allocator. For example, here's a rough approximation of a pair 
 of
 functions using malloc/free for class allocation:

 T alloc(T)() if(is(T == class))
 {
     enum size = __traits(classInstanceSize, T);
     auto p = enforceEx!OutOfMemoryError(malloc(size));
     return emplace!T(p[0 .. size]);
 }

 void dealloc(T)(ref T obj) if(is(T == class))
 {
     free(cast(void*)obj);
     obj = null;
 }

 It can easily be overloaded to support all types.

 In the future, Phobos will have a custom memory allocator 
 library, which
 modules like std.container will use, though to which extent is 
 not clear
 (for example, will it also use the custom allocator for 
 exception
 objects?). Nevertheless it will probably be a good base for 
 other
 libraries to easily support non-GC allocators.


 You still can't replace evertything with custom alloc templates 
 and have nice syntax. There are at least two cases where it 
 does not work nicely:

 1) Arrays (no new T [size] syntax)
 2) Inner classes (a template can't automatically capture the 
 outer class)

 So I think overloading new and delete actually has its place. 
 But the way it is currently implemented in D is useless in my 
 eyes.

 Kind Regards
 Benjamin Thaut


The solution could be like in Turbo Pascal/Delphi, provide an API 
to set the memory manager for the runtime.

--
Paulo
Mar 20 2013
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-03-20 08:57, Benjamin Thaut wrote:


 You still can't replace evertything with custom alloc templates and have
 nice syntax. There are at least two cases where it does not work nicely:

 1) Arrays (no new T [size] syntax)
 2) Inner classes (a template can't automatically capture the outer class)

 So I think overloading new and delete actually has its place. But the
 way it is currently implemented in D is useless in my eyes.


Instead of having a special keyword like we have now. We could have, as 
has been suggested before, a regular function or method.

With a class, there's also the possibility to return a different type or 
a singleton:

class Foo
{
    Foo new ()
    {
        return Bar.new();
    }
}

class Bar : Foo {}

-- 
/Jacob Carlborg
Mar 20 2013
parent reply Benjamin Thaut <code benjamin-thaut.de> writes:
Am 20.03.2013 13:42, schrieb Jacob Carlborg:

 On 2013-03-20 08:57, Benjamin Thaut wrote:


 You still can't replace evertything with custom alloc templates and have
 nice syntax. There are at least two cases where it does not work nicely:

 1) Arrays (no new T [size] syntax)
 2) Inner classes (a template can't automatically capture the outer class)

 So I think overloading new and delete actually has its place. But the
 way it is currently implemented in D is useless in my eyes.


 Instead of having a special keyword like we have now. We could have, as
 has been suggested before, a regular function or method.

 With a class, there's also the possibility to return a different type or
 a singleton:

 class Foo
 {
     Foo new ()
     {
         return Bar.new();
     }
 }

 class Bar : Foo {}


But with a regular function you always have the problem that you need to 
pass the constructor argumnets along. If there are implict conversion 
form literals to constructor arguments neccessary this will fail as soon 
as you pass them through a function.

Kind Regards
Benjamin Thaut

-- 
Kind Regards
Benjamin Thaut
Mar 20 2013
parent reply "D-Ratisueur" <qskjlkqdj sjhds.fr> writes:
On Wednesday, 20 March 2013 at 15:50:27 UTC, Benjamin Thaut wrote:

 Am 20.03.2013 13:42, schrieb Jacob Carlborg:

 On 2013-03-20 08:57, Benjamin Thaut wrote:


 You still can't replace evertything with custom alloc 
 templates and have
 nice syntax. There are at least two cases where it does not 
 work nicely:

 1) Arrays (no new T [size] syntax)
 2) Inner classes (a template can't automatically capture the 
 outer class)

 So I think overloading new and delete actually has its place. 
 But the
 way it is currently implemented in D is useless in my eyes.


 Instead of having a special keyword like we have now. We could 
 have, as
 has been suggested before, a regular function or method.

 With a class, there's also the possibility to return a 
 different type or
 a singleton:

 class Foo
 {
    Foo new ()
    {
        return Bar.new();
    }
 }

 class Bar : Foo {}


 But with a regular function you always have the problem that 
 you need to pass the constructor argumnets along. If there are 
 implict conversion form literals to constructor arguments 
 neccessary this will fail as soon as you pass them through a 
 function.

 Kind Regards
 Benjamin Thaut


Its too late...errors are made,anyway you got the stuff:
http://www.youtube.com/watch?v=KZKAVl_qX_Y. I Should wait a few
weeks before announcing "Unmanaged"...I feel quite shamefull
right now...
Mar 30 2013
next sibling parent Alexandr Druzhinin <drug2004 bk.ru> writes:
30.03.2013 22:38, D-Ratisueur пишет:

 Its too late...errors are made,anyway you got the stuff:
 http://www.youtube.com/watch?v=KZKAVl_qX_Y. I Should wait a few
 weeks before announcing "Unmanaged"...I feel quite shamefull
 right now...


Don't feel, you're good!
Mar 31 2013
prev sibling parent Benjamin Thaut <code benjamin-thaut.de> writes:
Am 30.03.2013 16:38, schrieb D-Ratisueur:

 Its too late...errors are made,anyway you got the stuff:
 http://www.youtube.com/watch?v=KZKAVl_qX_Y. I Should wait a few
 weeks before announcing "Unmanaged"...I feel quite shamefull
 right now...


This was no criticism on your project. I'm only pointing out issues in 
the language you can't really do anything about.

Kind Regards
Benjamin Thaut
Apr 02 2013
prev sibling parent "Baz." <burg.basile yahoo.com> writes:
On Wednesday, 13 March 2013 at 16:20:08 UTC, D-ratiseur wrote:

 Hello, I'd like to introduce the "Unmanaged" framework.
 It's a OOP library, strongly inspired by the Delphi/Pascal RTL.

 Its main concept is to bypass the GC. From this statement, the 
 library feaures:
 - main unmanaged object and memory routines
 - a parameterized list
 - an ownership system (used to automate the destroying of 
 object)
 - a parentship system
 - a serialization system...
 - etc work in progress.

 This library is developped in the same time I learn D, but 
 comming from Delphi, it's inspired by its class system  (but 
 it's not a copy at all).
 Unmanaged is tested under win32 an linux64. Basic build scripts 
 are provided for both systems and code review are welcome.

 you can track the project on github:

 https://github.com/BBasile/Unmanaged

 Hey.


Hello, I've re-written it. Now It's called LLClasses (low level 
classes).

https://github.com/BBasile/LLClasses

The serialization is more powerfull :
- it's able to store reference to an object via an ID
- an object can be serialized if it implements an interface

The concept is still the same: KIS (keep it simple).
Aug 03 2013