Kris wrote:

>>>
>> I can attest to this working great on Windows.  I use Mango with Ares on most of my projects now.  There are still a few things I'm missing, though, like std.string with all the toString methods.
> 
> 
> Au contraire, my friend :)
> 
> Take a look at convert.Double, convert.Integer, and convert.Rfc1123 ... they handle formatting and parsing of floating point, integer and (internet) dates. Each one operates with char/wchar/dchar, just like the rest of the mango.convert package.
> 


My mistake was including Mango and Ares in the same breath.  Mango is by far feature complete.  I believe it is fairly close to lacking nothing, for my needs: I love it.  Ares, on the other hand, could use a couple of useful string functions as per discussion on dsource.


> I think Mango needs some better documentation <g>


Yes, Mango needs a strong tutorial to reveal it's deep, dark secrets to the world, but the examples do nicely in the meantime.  I believe that concurrent to the publication of the /D Programming Language/ there should be a /Plucking the Mango Tree/ released as well.  ;)


>> But it's easy enough to customize that solution until Ares eventually provides its own.  Mango easily fills in all other needs.  I'm satisfied to ride the Mango/Ares combination as they continue to grow.
>>
>> Note, though, that Ares does not appear to be working completely on Linux ATM.  Or maybe it has been updated to work again recently?
> 
> 
> I think there's still some work to do with Ares threading on linux, but I believe Mango operates fine on linux when using Phobos? 
> 
> 

I spoke to soon, perhaps.  I'll give it a try again.  Thousand pardons. :)

-JJR

John Reimer wrote:
> 
> Note, though, that Ares does not appear to be working completely on Linux ATM.  Or maybe it has been updated to work again recently?

It isn't.  At some point Ares began requiring more Posix stuff that was included in Phobos and I haven't had access to enough headers to fill in the gaps.  If someone wants to just zip up their include directory from a Linux install and send it my way, I'll see about improving Posix support in the near future.  This should get things working on Linux, or at least to the state where stuff can be debugged.  That said, I suppose I should really create a Linux partition to play with.  Perhaps I'll ask around today and see if IT would have fits if I did this on my work laptop ;-)


Sean

John Reimer wrote:
> 
> I can attest to this working great on Windows.  I use Mango with Ares on most of my projects now.  There are still a few things I'm missing, though, like std.string with all the toString methods.

For what it's worth, I've begun thinking it might be nice to add toUtfX functions to the global object module, as well as to Object itself. Thus, UTF conversions for strings should be a matter of:

"blah blah".toUtf32();
myObject.toUtf8(); // equivalent to myObject.toString();

This leaves out atoi-like functions, but I believe some of those are provided with Mango?


Sean

John Reimer wrote:
> 
> My mistake was including Mango and Ares in the same breath.  Mango is by far feature complete.  I believe it is fairly close to lacking nothing, for my needs: I love it.  Ares, on the other hand, could use a couple of useful string functions as per discussion on dsource.

Aye.  I'm thinking this may all sort itself out rather nicely if Mango.io is submitted to Ares (which I may do quite soon).  Though I suppose my idea of adding the toUtf functions to the object module may be problematic when building against Ares and Mango... hrm... I suppose I'll jump off that bridge when I come to it.


Sean

"James Dunne" <james.jdunne@gmail.com> wrote ...
> [snippity snip]
>
> Charles wrote:
>>
>>>Thus, I'm trying to support both object-oriented programming and C-like procedural programming whenever doing so doesn't compromise
>>
>> I still think it should be two teired,  the stdlib of free functions, and
>> an
>> OO lib build on top, but Im pretty sure im alone in that opinion :S.
>>
>
> If going this route, please templatize every method such that it is guaranteed that the OO is not simply calling the flat functions in a wrapper, but instead inlining them directly with the templates.
>
> How will you maintain state across functions with this approach that supports both flat functions and OO?  Something to chew on...


I'll toss in a small anecdote:

There was a fair bit of back-and-forth on this topic when Ares first got started,which didn't reach a resolution (read the posts at dsource.org). It's actually a very hard problem to resolve in the general sense (standing with a foot in both camps). Thus, the Mango library went the 'encapsulated' route, where any static-functions and their ilk are wrapped in a struct ~ simply to give them an isolated namespace, and to avoid the problems that still crop up with phobos modules/functions bumping into each other.

When Mango started getting a slew of unicode support, the namespace encapsulation turned out to be a blessing ~ it was trivial to convert the encapsulation approach to a template instead, with char/wchar/dchar variations, and none of the existing usage was broken (an alias was made available to handle common cases). This would have been a royal mess with freeform C-like functions.

Take that for what it's worth, but for me there's certain value in explicitly managing the namespace. Heck, it can make the code more readable too (look at a reasonable chunk of the Mango source).

There are some who think that it requires too much typing. Well, consider the benefits instead (or get an IDE with code-completion <g>). There are others who worry about heap-usage ~ "using encapsulated functionality means allocating classes everywhere!". I've found that to be a complete fallacy. For example, the Mango http/servlet engine happily serves requests without a single heap allocation. There's not one C-like freeform function within that server ~ it uses classes (and a few encapsulating structs) throughout.

Being "old school" I still tend to think a lot about performance and overhead on a device ~ yet have not found issue with going the encapsulation route. You might consider these points when discussing one approach versus the other?

Kris wrote:
> "James Dunne" <james.jdunne@gmail.com> wrote ...
>> [snippity snip]
>>
>> Charles wrote:
>>>> Thus, I'm trying to support both object-oriented programming and C-like procedural programming whenever doing so doesn't compromise
>>> I still think it should be two teired,  the stdlib of free functions, and an
>>> OO lib build on top, but Im pretty sure im alone in that opinion :S.
>>>
>> If going this route, please templatize every method such that it is guaranteed that the OO is not simply calling the flat functions in a wrapper, but instead inlining them directly with the templates.
>>
>> How will you maintain state across functions with this approach that supports both flat functions and OO?  Something to chew on...
> 
> I'll toss in a small anecdote:
> 
> There was a fair bit of back-and-forth on this topic when Ares first got started,which didn't reach a resolution (read the posts at dsource.org). It's actually a very hard problem to resolve in the general sense (standing with a foot in both camps). Thus, the Mango library went the 'encapsulated' route, where any static-functions and their ilk are wrapped in a struct ~ simply to give them an isolated namespace, and to avoid the problems that still crop up with phobos modules/functions bumping into each other.

Aye.  Which is why I qualified my original statement with "whenever doing so doesn't compromise the overall design" :-).  The attempt to support both schemes has been one reason why I added thread-local storage and allow Thread to be initialized with a delegate or function pointer parameter, but I haven't gone much farther than that.  I suppose the important distinction to me is that, in general, I don't want to *require* derivation if composition can achieve the same goal in a sufficiently elegant manner.

> When Mango started getting a slew of unicode support, the namespace encapsulation turned out to be a blessing ~ it was trivial to convert the encapsulation approach to a template instead, with char/wchar/dchar variations, and none of the existing usage was broken (an alias was made available to handle common cases). This would have been a royal mess with freeform C-like functions.

I occasionally wish module namespace qualifiers were required by default, as it seems odd to do this:

module Atomic;

struct Atomic {
    // the whole module lives here
}

But this isn't a problem I've had to deal with much yet.  Though I suppose that will change soon enough :-).

> Take that for what it's worth, but for me there's certain value in explicitly managing the namespace. Heck, it can make the code more readable too (look at a reasonable chunk of the Mango source).

I did try a sort of grouping approach with std.atomic in Ares, but the attempt failed miserably:

CC:\code\d>type test.d
enum msync
{
    acq,
    rel
}

struct Atomic( T )
{
    template load( msync ms ) {
        static T load( inout T val ) { return val; }
    }

    template load( msync ms ) {
        T load() { return Atomic.load!(ms)( m_val ); }
    }

    private T m_val;
}

int main()
{
    int x;
    int y = Atomic!(int).load!(msync.acq)( x );
    Atomic!(int) s;
    x = s.load!(msync.acq)();
    return 0;
}
C:\code\d>dmd test
test.d(23): template instance matches more than one template declaration
test.d(23): function expected before (), not load!(cast(msync)0) of type void
test.d(24): Atomic!(int) is used as a type
test.d(24): variable test.main.s voids have no value
test.d(25): template load!(msync.acq) is not a member of s
test.d(25): function expected before (), not 0 of type int

C:\code\d>

(note that the last error can be addressed by removing the empty parens from "x = s.load!(msync.acq)();", though it seems silly that the property syntax is required in this case)

I haven't tried this with DMD .143 yet.  And I suppose the current method is arguably more clear:

int y = atomicLoad!(int,msync.acq)( x );


Sean

"John Reimer" <terminal.node@gmail.com> wrote ...
> Kris wrote:
> Yes, Mango needs a strong tutorial to reveal it's deep, dark secrets to
> the world, but the examples do nicely in the meantime.  I believe that
> concurrent to the publication of the /D Programming Language/ there should
> be a /Plucking the Mango Tree/ released as well.  ;)

Funny!

I do wish I were a better writer. I don't suppose there's anyone here who'd be interested in writing some high-level documentation for a suite of library components? I imagine that would be asking for too much <g>


>> I think there's still some work to do with Ares threading on linux, but I believe Mango operates fine on linux when using Phobos?
>
> I spoke to soon, perhaps.  I'll give it a try again.  Thousand pardons. :)

Please do!

if (broken)
    kris.fix (issue);

Kris wrote:
> "John Reimer" <terminal.node@gmail.com> wrote ...
>> Kris wrote:
>> Yes, Mango needs a strong tutorial to reveal it's deep, dark secrets to the world, but the examples do nicely in the meantime.  I believe that concurrent to the publication of the /D Programming Language/ there should be a /Plucking the Mango Tree/ released as well.  ;)
> 
> Funny!
> 
> I do wish I were a better writer. I don't suppose there's anyone here who'd be interested in writing some high-level documentation for a suite of library components? I imagine that would be asking for too much <g>
> 
> 


Ha ha... you're even funnier.  You wish you were a better writer? Hogwash.  I won't lavish you with any useless flattery, but I will say that I think you are more than adequately equipped for any such task.

I have considered doing some tutorial stuff myself for Mango, but have no time for that, at the moment (original excuse, no?).  I've already jumped into more things than I can handle at this time.


>>> I think there's still some work to do with Ares threading on linux, but I believe Mango operates fine on linux when using Phobos?
>> I spoke to soon, perhaps.  I'll give it a try again.  Thousand pardons. :)
> 
> Please do!
> 
> if (broken)
>     kris.fix (issue); 


I will.  Just got to get some higher priority things done over the next few days.  For some reason, everything is piling up on me recently, both work and home. *sigh*

-JJR

Sean Kelly wrote:
> John Reimer wrote:
>>
>> My mistake was including Mango and Ares in the same breath.  Mango is by far feature complete.  I believe it is fairly close to lacking nothing, for my needs: I love it.  Ares, on the other hand, could use a couple of useful string functions as per discussion on dsource.
> 
> Aye.  I'm thinking this may all sort itself out rather nicely if Mango.io is submitted to Ares (which I may do quite soon).  Though I suppose my idea of adding the toUtf functions to the object module may be problematic when building against Ares and Mango... hrm... I suppose I'll jump off that bridge when I come to it.
> 
> 
> Sean


Hey Sean,

I read your thoughts on adding Mango.io or the UTF functions.  I'm really not certain what the correct approach is either.  Mango.io is tremendously useful, but does take the OO approach to things.

This is definitely a topic for further discussion... perhaps on dsource.org.

BTW, I /really/ appreciate all you've done in Ares.  It's worked very well for me so far.  It just needs to be slowly built up.

Thanks again,

John

Sean Kelly wrote:
> John Reimer wrote:
>>
>> Note, though, that Ares does not appear to be working completely on Linux ATM.  Or maybe it has been updated to work again recently?
> 
> It isn't.  At some point Ares began requiring more Posix stuff that was included in Phobos and I haven't had access to enough headers to fill in the gaps.  If someone wants to just zip up their include directory from a Linux install and send it my way, I'll see about improving Posix support in the near future.  This should get things working on Linux, or at least to the state where stuff can be debugged.  That said, I suppose I should really create a Linux partition to play with.  Perhaps I'll ask around today and see if IT would have fits if I did this on my work laptop ;-)
> 
> 
> Sean

I could do the zip up some headers for you, but maybe you could also download one of the many linux-header packages that are distributed with linux systems -- some of these distributions have this package available on the internet for separate download.  I'm not sure how complete they are, however.  I'll try to get back to you on this.

Another option, Sean, is to use the vmplayer, available free from vmware.  Then all you need is to download a Linux virtual machine/drive from somewhere.

-JJR