www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Pause Self, Resume on Event

reply dsimcha <dsimcha yahoo.com> writes:
I'm trying to implement a low-overhead thread pool library that avoids busy
waiting, and the issue I keep running into is, if a thread is waiting on a job
in the pool queue, how to get the waiting thread to pause and then be resumed
by the worker thread when the job is finished, w/o creating any race hazards.
 Below is a simplified example:

class Task {
    bool isDone = false;
    Thread[] waitingThreads;  //Threads waiting for task to complete.

    //int delegate(), etc., etc.

    void wait() {
        if(isDone) return;
        Thread self = Thread.getThis;
        synchronized(this) {
            waitingThreads ~= self;
            self.pause;
        }
    }

    void resumeWaiting() {  //Called by worker function when done w/ task.
        isDone = true;
        foreach(waiting; waitingThreads) {
            waiting.resume;
        }
    }
}

This probably wouldn't work because, since resumeWaiting is not synchronized,
it could theoretically be called while a thread is in the process of adding
itself to waitingThreads.  In this case, resume would never get called for
this thread.

If I synchronize resumeWaiting, then the thread that called wait() goes to
pause inside a mutex, and nothing can get access to my instance of Task to
resume it.

The third option would be to synchronize only the append to waitingThreads and
not the call to pause(), and to synchronize resumeWaiting().  However, then it
seems theoretically possible that the thread calling wait() would be suspended
by the scheduler before it called pause(), and if resumeWaiting() were then
called before the thread calling wait() got another timeslice, I'd have a
resume-before-pause.  I'm fairly (read:  very) new to concurrent programming.
 Is there a standard solution to problems like this?
Jul 16 2008
next sibling parent reply downs <default_357-line yahoo.de> writes:
NO NO NO NO NO NO NO.


I tried this once, and _believe me_, you do _not_ want to go down this route.

Use proper threading primitives. By which I mean, tools.threads and its
POSIX/Win32 Semaphores and Mutexes.

It even already has a threadpool :)

 --downs

PS: The reason you don't want to go down this route is because you're
interfering with the GC's own pause/resume schemes and inviting a world of race
conditions and hard to find bugs.
Jul 16 2008
parent downs <default_357-line yahoo.de> writes:
Sorry, forgot to say.
Jul 16 2008
prev sibling next sibling parent BCS <ao pathlink.com> writes:
without reading the whole post:

Is there a good reason to not just take the thread that is supposed to be 
waiting and add it to the thread pool until it should awake?
Jul 16 2008
prev sibling parent reply Sean Kelly <sean invisibleduck.org> writes:
dsimcha wrote:
 I'm trying to implement a low-overhead thread pool library that avoids busy
 waiting, and the issue I keep running into is, if a thread is waiting on a job
 in the pool queue, how to get the waiting thread to pause and then be resumed
 by the worker thread when the job is finished, w/o creating any race hazards.

Assuming you're using Tango, you should use a Condition: class Task { alias void delegate() Dg; Mutex m; Condition c; Dg[] queue; this() { m = new Mutex; c = new Condition; auto t = new Thread( &run ); } void assignTask( Dg dg ) { synchronized( m ) { queue ~= dg; c.notify(); } } private: void run() { Dg dg; while( true ) { synchronized( m ) { while( queue.length < 1 ) c.wait(); dg = queue[$ - 1]; queue = queue[0 .. $ - 1]; } dg(); } } } The pool above contains only one thread and is pretty basic, but you get the idea. c.wait() above atomically unlocks the mutex and waits for c.notify() to be called, and then atomically re-locks the mutex before returning. This is a classic producer-consumer algorithm.
 If I synchronize resumeWaiting, then the thread that called wait() goes to
 pause inside a mutex, and nothing can get access to my instance of Task to
 resume it.

See above. Conditions are kind of a special case. Don't use pause/resume in Thread--they're a deadlock waiting to happen. They've been deprecated in Java for this reason, and I have no idea why they're exposed in Phobos. It's a major mistake IMO.
  Is there a standard solution to problems like this?

Condition variables. See above :-) Sean
Jul 17 2008
parent reply dsimcha <dsimcha yahoo.com> writes:
Thanks.  Unfortunately, I'm using Phobos right now because Tango is not
compatible
with D2, except the experimental branches, which seem *very* experimental at
this
point in that I couldn't get them to compile cleanly on DMD 2.017.  I actually
wrote the thing using "yield spinning," i.e. if(var != condition) self.yield. 
It
actually works reasonably well like that.  If/when Tango becomes 2.0 compatible
or
Phobos gets condition mutexes, I'll probably fix this.  However, I'm so
impressed
with the low latency of this thing that, for my purposes (futures and other
similar ways of exploiting very fine-grained parallelism), it might be better
this
way.  I ran some microbenchmarks to find the break even job size for running
jobs
in serial w/o thread pool overhead vs. running them in parallel on the thread
pool.  If the benchmarks are accurate, on my 2-core rig it's only about 3
microseconds/job.  This assumes you're queueing up a large number of jobs and
then
waiting for all of them to finish.

On another note, anyone have any idea when/if Tango for D2, and Tangobos for
Tango
for D2, will be available?  There are things I like and dislike about both Tango
and Phobos, and I really wish I could mix and match modules from them without
giving up my D2 features.  For example, I like Phobos's much simpler IO API,
less
"OO everywhere" look and feel and "simple operations should be simple"
mentality,
but I like Tango's extra math and threading stuff and richer feature set in
general.  Also, I've written a decent amount of Phobos code that I don't feel
like
porting.
Jul 17 2008
next sibling parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"dsimcha" <dsimcha yahoo.com> wrote in message 
news:g5o4g7$2f5i$1 digitalmars.com...

 On another note, anyone have any idea when/if Tango for D2, and Tangobos 
 for Tango
 for D2, will be available?  There are things I like and dislike about both 
 Tango
 and Phobos, and I really wish I could mix and match modules from them 
 without
 giving up my D2 features.  For example, I like Phobos's much simpler IO 
 API, less
 "OO everywhere" look and feel and "simple operations should be simple" 
 mentality,

Why does everyone say that Tango is "OO everywhere"? There are free functions (or static functions) that correspond to most free functions in Phobos. Please, please give me some examples of what you believe to be "OO everywhere."
Jul 17 2008
next sibling parent reply dsimcha <dsimcha yahoo.com> writes:
Reading in a file.  Yes, Phobos has streams for when you actually need serious
features, but it has the dead simple read() function that doesn't require
instantiating a class or anything like that just to read a file into an array of
bytes.  To be perfectly honest, the only parts of Tango I've really looked at
hard
are the threading and math stuff, since Tango is still basically for D1 only and
otherwise I haven't had a problem with Phobos, but AFAIK Tango is much more OO
and
verbose than Phobos.  This isn't really a knock against it, it's really just
personal preference, not that one is "better" than the other.  On the other
hand,
Phobos just doesn't have a lot of the features I'd like.

What I personally would like to see in the ideal world is for Phobos to become
analogous to the C++ standard lib, i.e. simple in both features and API, very
highly tested and optimized, "official", etc. and for Tango to become analogous
to
Boost, i.e. more complex, feature-rich, etc. and more of a "standard add-on lib"
than a second "*the*" standard lib.  However, IDK how much they've diverged and
whether using them together will grow more or less feasible with time.
Jul 17 2008
next sibling parent "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"dsimcha" <dsimcha yahoo.com> wrote in message 
news:g5oajj$2rfe$1 digitalmars.com...
 Reading in a file.  Yes, Phobos has streams for when you actually need 
 serious
 features, but it has the dead simple read() function that doesn't require
 instantiating a class or anything like that just to read a file into an 
 array of
 bytes.  To be perfectly honest, the only parts of Tango I've really looked 
 at hard
 are the threading and math stuff, since Tango is still basically for D1 
 only and
 otherwise I haven't had a problem with Phobos, but AFAIK Tango is much 
 more OO and
 verbose than Phobos.  This isn't really a knock against it, it's really 
 just
 personal preference, not that one is "better" than the other.  On the 
 other hand,
 Phobos just doesn't have a lot of the features I'd like.

I just don't know how to answer. I've never found "File("filename").read()" to be particularly awful. It's not really any more OO than Phobos in most places. More verbose -- that's improving. Much of the verbosity in some of the lower level functions is for performance (like passing buffers for output), and I can't tell you how often I've been thankful for those lower-level interfaces. There are an increasing number of "convenience" methods and functions. That's one nice thing about Tango: if you _don't like_ something, _let the developers know_ and _they will do something about it_. A cursory glance over the documents will also not give you what you need to decide whether or not you like the library. I didn't like Tango at first, but after a month of using it I came to realize how much better-designed and flexible it is. Not having to duplicate 800 lines worth of functionality in every one of my projects for such simple things as array manipulations and string functions that operate on types other than char[] was also a nice bonus. So I know what you'll reply with next, "oh, well it's _too big_ for me, I need a smaller library." Give it up. That's a horrid argument and you know it.
Jul 17 2008
prev sibling parent Sean Kelly <sean invisibleduck.org> writes:
dsimcha wrote:
 Reading in a file.  Yes, Phobos has streams for when you actually need serious
 features, but it has the dead simple read() function that doesn't require
 instantiating a class or anything like that just to read a file into an array
of
 bytes.

So use tango.stdc.stdio. Seriously. I know some Tango folks would probably not agree with this suggestion, but it's portable, fast function-based IO.
 What I personally would like to see in the ideal world is for Phobos to become
 analogous to the C++ standard lib, i.e. simple in both features and API, very
 highly tested and optimized, "official", etc. and for Tango to become
analogous to
 Boost, i.e. more complex, feature-rich, etc. and more of a "standard add-on
lib"
 than a second "*the*" standard lib.  However, IDK how much they've diverged and
 whether using them together will grow more or less feasible with time.

It's obviously a matter of opinion, but I think Tango has a better runtime and overall low-level support than Phobos, so I question the suggestion to make Phobos the core to build upon. Regarding Tango in particular--our goal was always to have Tango be modular and lightweight, and although Tango has grown a bit beyond this I think it's still a more lightweight library than Phobos insofar as executable size is concerned. Modules in Phobos tend to have far more dependencies than those in Tango, for example, so you'll often find that by importing something that seems pretty basic you'll end up pulling in a ton of other stuff as well. Worse, the runtime code pulls in this stuff as well because it calls various user packages for runtime-level work. Phobos is fine for everyday applications programming but I personally wouldn't choose it for a serious systems app (still obviously my own very biased opinion of course). Sean
Jul 17 2008
prev sibling parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Jarrett Billingsley wrote:
 "dsimcha" <dsimcha yahoo.com> wrote in message 
 news:g5o4g7$2f5i$1 digitalmars.com...
 
 On another note, anyone have any idea when/if Tango for D2, and Tangobos 
 for Tango
 for D2, will be available?  There are things I like and dislike about both 
 Tango
 and Phobos, and I really wish I could mix and match modules from them 
 without
 giving up my D2 features.  For example, I like Phobos's much simpler IO 
 API, less
 "OO everywhere" look and feel and "simple operations should be simple" 
 mentality,

Why does everyone say that Tango is "OO everywhere"? There are free functions (or static functions) that correspond to most free functions in Phobos. Please, please give me some examples of what you believe to be "OO everywhere."

One example: there are no stand-alone writefln/writef or readfln/readf functions in Tango. --bb
Jul 17 2008
next sibling parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Bill Baxter" <dnewsgroup billbaxter.com> wrote in message 
news:g5ocsa$2v3b$2 digitalmars.com...
 Jarrett Billingsley wrote:
 "dsimcha" <dsimcha yahoo.com> wrote in message 
 news:g5o4g7$2f5i$1 digitalmars.com...

 On another note, anyone have any idea when/if Tango for D2, and Tangobos 
 for Tango
 for D2, will be available?  There are things I like and dislike about 
 both Tango
 and Phobos, and I really wish I could mix and match modules from them 
 without
 giving up my D2 features.  For example, I like Phobos's much simpler IO 
 API, less
 "OO everywhere" look and feel and "simple operations should be simple" 
 mentality,

Why does everyone say that Tango is "OO everywhere"? There are free functions (or static functions) that correspond to most free functions in Phobos. Please, please give me some examples of what you believe to be "OO everywhere."

One example: there are no stand-alone writefln/writef or readfln/readf functions in Tango.

--! I mean ------ come on. You call a method of a statically allocated object. As if that's really different?
Jul 17 2008
next sibling parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Jarrett Billingsley wrote:
 "Bill Baxter" <dnewsgroup billbaxter.com> wrote in message 
 news:g5ocsa$2v3b$2 digitalmars.com...
 Jarrett Billingsley wrote:
 "dsimcha" <dsimcha yahoo.com> wrote in message 
 news:g5o4g7$2f5i$1 digitalmars.com...

 On another note, anyone have any idea when/if Tango for D2, and Tangobos 
 for Tango
 for D2, will be available?  There are things I like and dislike about 
 both Tango
 and Phobos, and I really wish I could mix and match modules from them 
 without
 giving up my D2 features.  For example, I like Phobos's much simpler IO 
 API, less
 "OO everywhere" look and feel and "simple operations should be simple" 
 mentality,

functions (or static functions) that correspond to most free functions in Phobos. Please, please give me some examples of what you believe to be "OO everywhere."

One example: there are no stand-alone writefln/writef or readfln/readf functions in Tango.

--! I mean ------ come on. You call a method of a statically allocated object. As if that's really different?

I have detailed in enhancement reports posted to the Tango tracker why it makes a difference, so I'm not going to repeat myself here. --bb
Jul 17 2008
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Bill Baxter wrote:
 Jarrett Billingsley wrote:
 "Bill Baxter" <dnewsgroup billbaxter.com> wrote in message 
 news:g5ocsa$2v3b$2 digitalmars.com...
 Jarrett Billingsley wrote:
 "dsimcha" <dsimcha yahoo.com> wrote in message 
 news:g5o4g7$2f5i$1 digitalmars.com...

 On another note, anyone have any idea when/if Tango for D2, and 
 Tangobos for Tango
 for D2, will be available?  There are things I like and dislike 
 about both Tango
 and Phobos, and I really wish I could mix and match modules from 
 them without
 giving up my D2 features.  For example, I like Phobos's much 
 simpler IO API, less
 "OO everywhere" look and feel and "simple operations should be 
 simple" mentality,

functions (or static functions) that correspond to most free functions in Phobos. Please, please give me some examples of what you believe to be "OO everywhere."

One example: there are no stand-alone writefln/writef or readfln/readf functions in Tango.

--! I mean ------ come on. You call a method of a statically allocated object. As if that's really different?

I have detailed in enhancement reports posted to the Tango tracker why it makes a difference, so I'm not going to repeat myself here.

Not meaning to sound too stand-offish there. Actually, I don't totally recall what the problems I had with it were, and I don't have time to go look it up now. But I do find it quite typical when dealing with several Tango folks, this pattern of: A: "oh come on -- tango is not really X! give me an example!" B: <example provided> A: "Pffft -- you're silly, go away." That is most definitely off-putting. --bb
Jul 17 2008
next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Bill Baxter" <dnewsgroup billbaxter.com> wrote in message 
news:g5ovgi$2dip$1 digitalmars.com...
 Bill Baxter wrote:
 Jarrett Billingsley wrote:
 "Bill Baxter" <dnewsgroup billbaxter.com> wrote in message 
 news:g5ocsa$2v3b$2 digitalmars.com...
 Jarrett Billingsley wrote:
 "dsimcha" <dsimcha yahoo.com> wrote in message 
 news:g5o4g7$2f5i$1 digitalmars.com...

 On another note, anyone have any idea when/if Tango for D2, and 
 Tangobos for Tango
 for D2, will be available?  There are things I like and dislike about 
 both Tango
 and Phobos, and I really wish I could mix and match modules from them 
 without
 giving up my D2 features.  For example, I like Phobos's much simpler 
 IO API, less
 "OO everywhere" look and feel and "simple operations should be 
 simple" mentality,

functions (or static functions) that correspond to most free functions in Phobos. Please, please give me some examples of what you believe to be "OO everywhere."

One example: there are no stand-alone writefln/writef or readfln/readf functions in Tango.

--! I mean ------ come on. You call a method of a statically allocated object. As if that's really different?

I have detailed in enhancement reports posted to the Tango tracker why it makes a difference, so I'm not going to repeat myself here.

Not meaning to sound too stand-offish there. Actually, I don't totally recall what the problems I had with it were, and I don't have time to go look it up now.

I believe the main functional complaint (not style-based) is that you cannot alias it. -Steve
Jul 17 2008
prev sibling parent "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Bill Baxter" <dnewsgroup billbaxter.com> wrote in message 
news:g5ovgi$2dip$1 digitalmars.com...

 I have detailed in enhancement reports posted to the Tango tracker why it 
 makes a difference, so I'm not going to repeat myself here.

Not meaning to sound too stand-offish there. Actually, I don't totally recall what the problems I had with it were, and I don't have time to go look it up now. But I do find it quite typical when dealing with several Tango folks, this pattern of: A: "oh come on -- tango is not really X! give me an example!" B: <example provided> A: "Pffft -- you're silly, go away." That is most definitely off-putting.

I'm sorry if it came across that way, but it's equally frustrating when people seem to find the tiniest reasons to _dis_like Tango when there are so many other reasons to like it. It's like complaining about a scratch on the dashboard of a Porsche, or a single stuck pixel on a 1680x1050 flatpanel with sub-5ms response time. <sarcasm no personal experience behind _that_ statement />
Jul 17 2008
prev sibling parent reply Don <nospam nospam.com.au> writes:
Jarrett Billingsley wrote:
 "Bill Baxter" <dnewsgroup billbaxter.com> wrote in message 
 news:g5ocsa$2v3b$2 digitalmars.com...
 Jarrett Billingsley wrote:
 "dsimcha" <dsimcha yahoo.com> wrote in message 
 news:g5o4g7$2f5i$1 digitalmars.com...

 On another note, anyone have any idea when/if Tango for D2, and Tangobos 
 for Tango
 for D2, will be available?  There are things I like and dislike about 
 both Tango
 and Phobos, and I really wish I could mix and match modules from them 
 without
 giving up my D2 features.  For example, I like Phobos's much simpler IO 
 API, less
 "OO everywhere" look and feel and "simple operations should be simple" 
 mentality,

functions (or static functions) that correspond to most free functions in Phobos. Please, please give me some examples of what you believe to be "OO everywhere."

One example: there are no stand-alone writefln/writef or readfln/readf functions in Tango.

--! I mean ------ come on. You call a method of a statically allocated object. As if that's really different?

I think it's a very important difference, actually. It makes it *feel* like as though Tango's been sucked into the ideology of putting free functions into a singleton object. And writefln() is the most visible function in Phobos. If someone says they prefer Phobos over Tango, most commonly, they mean they like writefln. Making a simple wrapper/alias that calls Stdout -- AND MAKING IT STANDARD would, I think, do a lot for Tango, especially for first impressions.
Jul 18 2008
parent reply Aarti_pl <aarti interia.pl> writes:
Don pisze:
 Jarrett Billingsley wrote:
 "Bill Baxter" <dnewsgroup billbaxter.com> wrote in message 
 news:g5ocsa$2v3b$2 digitalmars.com...
 Jarrett Billingsley wrote:
 "dsimcha" <dsimcha yahoo.com> wrote in message 
 news:g5o4g7$2f5i$1 digitalmars.com...

 On another note, anyone have any idea when/if Tango for D2, and 
 Tangobos for Tango
 for D2, will be available?  There are things I like and dislike 
 about both Tango
 and Phobos, and I really wish I could mix and match modules from 
 them without
 giving up my D2 features.  For example, I like Phobos's much 
 simpler IO API, less
 "OO everywhere" look and feel and "simple operations should be 
 simple" mentality,

functions (or static functions) that correspond to most free functions in Phobos. Please, please give me some examples of what you believe to be "OO everywhere."

One example: there are no stand-alone writefln/writef or readfln/readf functions in Tango.

--! I mean ------ come on. You call a method of a statically allocated object. As if that's really different?

I think it's a very important difference, actually. It makes it *feel* like as though Tango's been sucked into the ideology of putting free functions into a singleton object. And writefln() is the most visible function in Phobos. If someone says they prefer Phobos over Tango, most commonly, they mean they like writefln. Making a simple wrapper/alias that calls Stdout -- AND MAKING IT STANDARD would, I think, do a lot for Tango, especially for first impressions.

...and - when same identifiers writefln/writef would be chosen - it will also make easier writing programs which can work with Phobos *and* Tango. Also aliases string, wstring and dstring should be added to Tango for compatibility reasons. BR Marcin Kuszczak aarti_pl
Jul 18 2008
parent Don <nospam nospam.com.au> writes:
Aarti_pl wrote:
 Don pisze:
 Jarrett Billingsley wrote:
 "Bill Baxter" <dnewsgroup billbaxter.com> wrote in message 
 news:g5ocsa$2v3b$2 digitalmars.com...
 Jarrett Billingsley wrote:
 "dsimcha" <dsimcha yahoo.com> wrote in message 
 news:g5o4g7$2f5i$1 digitalmars.com...

 On another note, anyone have any idea when/if Tango for D2, and 
 Tangobos for Tango
 for D2, will be available?  There are things I like and dislike 
 about both Tango
 and Phobos, and I really wish I could mix and match modules from 
 them without
 giving up my D2 features.  For example, I like Phobos's much 
 simpler IO API, less
 "OO everywhere" look and feel and "simple operations should be 
 simple" mentality,

free functions (or static functions) that correspond to most free functions in Phobos. Please, please give me some examples of what you believe to be "OO everywhere."

One example: there are no stand-alone writefln/writef or readfln/readf functions in Tango.

--! I mean ------ come on. You call a method of a statically allocated object. As if that's really different?

I think it's a very important difference, actually. It makes it *feel* like as though Tango's been sucked into the ideology of putting free functions into a singleton object. And writefln() is the most visible function in Phobos. If someone says they prefer Phobos over Tango, most commonly, they mean they like writefln. Making a simple wrapper/alias that calls Stdout -- AND MAKING IT STANDARD would, I think, do a lot for Tango, especially for first impressions.

...and - when same identifiers writefln/writef would be chosen - it will also make easier writing programs which can work with Phobos *and* Tango.

Except that Tango is using .NET -style {1:x} formatting, instead of Phobos %x format. Otherwise I'd agree completely. It would be nice if 'Hello world'-style programs would work on both Tango and Phobos.
 Also aliases string, wstring and dstring should be added to Tango for 
 compatibility reasons.

Yes.
 
 BR
 Marcin Kuszczak
 aarti_pl

Jul 18 2008
prev sibling parent reply Sean Kelly <sean invisibleduck.org> writes:
Bill Baxter wrote:
 Jarrett Billingsley wrote:
 "dsimcha" <dsimcha yahoo.com> wrote in message 
 news:g5o4g7$2f5i$1 digitalmars.com...

 On another note, anyone have any idea when/if Tango for D2, and 
 Tangobos for Tango
 for D2, will be available?  There are things I like and dislike about 
 both Tango
 and Phobos, and I really wish I could mix and match modules from them 
 without
 giving up my D2 features.  For example, I like Phobos's much simpler 
 IO API, less
 "OO everywhere" look and feel and "simple operations should be 
 simple" mentality,

Why does everyone say that Tango is "OO everywhere"? There are free functions (or static functions) that correspond to most free functions in Phobos. Please, please give me some examples of what you believe to be "OO everywhere."

One example: there are no stand-alone writefln/writef or readfln/readf functions in Tango.

Is your issue here cosmetic or something else? The Tango IO package is largely class-based because it allows for a lot more flexibility. A function-based IO package couldn't easily support locales, for example. If this is a cosmetic issue then it would be trivial to alter the calling convention to look exactly like writef / readf, but if it has something to do with the involvement of objects at all then that would obviously require a lot more work and the result would be much more limited. For this level of work I still suggest simply using the C stdio routines. After all, C++ doesn't even have function-based IO--it simply wraps the C standard library as well. Sean
Jul 17 2008
parent Bill Baxter <dnewsgroup billbaxter.com> writes:
Sean Kelly wrote:
 Bill Baxter wrote:
 Jarrett Billingsley wrote:
 "dsimcha" <dsimcha yahoo.com> wrote in message 
 news:g5o4g7$2f5i$1 digitalmars.com...

 On another note, anyone have any idea when/if Tango for D2, and 
 Tangobos for Tango
 for D2, will be available?  There are things I like and dislike 
 about both Tango
 and Phobos, and I really wish I could mix and match modules from 
 them without
 giving up my D2 features.  For example, I like Phobos's much simpler 
 IO API, less
 "OO everywhere" look and feel and "simple operations should be 
 simple" mentality,

Why does everyone say that Tango is "OO everywhere"? There are free functions (or static functions) that correspond to most free functions in Phobos. Please, please give me some examples of what you believe to be "OO everywhere."

One example: there are no stand-alone writefln/writef or readfln/readf functions in Tango.

Is your issue here cosmetic or something else?

Ok, I looked them up. Here are my issues with the stdio stuff in Tango: http://www.dsource.org/projects/tango/ticket/903 http://www.dsource.org/projects/tango/ticket/908 http://www.dsource.org/projects/tango/ticket/1060
 The Tango IO package is 
 largely class-based because it allows for a lot more flexibility.  

That's great. I don't see how you'll lose that flexibility by wrapping a function around Stdout that uses Stdout under the hood. (Much like C's printf uses 'stdout' under the hood.)
 A function-based IO package couldn't easily support locales, for example. 
  If this is a cosmetic issue then it would be trivial to alter the 
 calling convention to look exactly like writef / readf, but if it has 
 something to do with the involvement of objects at all then that would 
 obviously require a lot more work and the result would be much more 
 limited.  For this level of work I still suggest simply using the C 
 stdio routines.  After all, C++ doesn't even have function-based IO--it 
 simply wraps the C standard library as well.

Jul 17 2008
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"dsimcha" wrote
 On another note, anyone have any idea when/if Tango for D2, and Tangobos 
 for Tango
 for D2, will be available?  There are things I like and dislike about both 
 Tango
 and Phobos, and I really wish I could mix and match modules from them 
 without
 giving up my D2 features.  For example, I like Phobos's much simpler IO 
 API, less
 "OO everywhere" look and feel and "simple operations should be simple" 
 mentality,
 but I like Tango's extra math and threading stuff and richer feature set 
 in
 general.  Also, I've written a decent amount of Phobos code that I don't 
 feel like
 porting.

The D2 branch of Tango currently doesn't compile, and won't compile until we have some enhancements from D2 that I believe are necessary for Tango to retain it's abilities. When this does happen, I'm sure tangobos will follow rather quickly. -Steve
Jul 17 2008
prev sibling parent reply Sean Kelly <sean invisibleduck.org> writes:
dsimcha wrote:
 
 On another note, anyone have any idea when/if Tango for D2, and Tangobos for
Tango
 for D2, will be available?  There are things I like and dislike about both
Tango
 and Phobos, and I really wish I could mix and match modules from them without
 giving up my D2 features.  For example, I like Phobos's much simpler IO API,
less
 "OO everywhere" look and feel and "simple operations should be simple"
mentality,
 but I like Tango's extra math and threading stuff and richer feature set in
 general.  Also, I've written a decent amount of Phobos code that I don't feel
like
 porting.

There's no timeframe for D2 support at the moment. I may look into at least having the runtime be cross-compatible, but porting the user code would require changes in structure / coding strategy that I can't see anyone wanting to make. Sean
Jul 17 2008
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Sean Kelly wrote:
 dsimcha wrote:
 On another note, anyone have any idea when/if Tango for D2, and 
 Tangobos for Tango
 for D2, will be available?  There are things I like and dislike about 
 both Tango
 and Phobos, and I really wish I could mix and match modules from them 
 without
 giving up my D2 features.  For example, I like Phobos's much simpler 
 IO API, less
 "OO everywhere" look and feel and "simple operations should be simple" 
 mentality,
 but I like Tango's extra math and threading stuff and richer feature 
 set in
 general.  Also, I've written a decent amount of Phobos code that I 
 don't feel like
 porting.

There's no timeframe for D2 support at the moment. I may look into at least having the runtime be cross-compatible, but porting the user code would require changes in structure / coding strategy that I can't see anyone wanting to make.

It seems to me that some people do actually like D2 and aren't using Tango precisely because there's no D2 support. So who knows, maybe you'll find there's a new crop of D2/Tango volunteers that show up once the ball gets rolling. Steven S. for one, perhaps. --bb
Jul 17 2008
next sibling parent reply Sean Kelly <sean invisibleduck.org> writes:
Bill Baxter wrote:
 Sean Kelly wrote:
 dsimcha wrote:
 On another note, anyone have any idea when/if Tango for D2, and 
 Tangobos for Tango
 for D2, will be available?  There are things I like and dislike about 
 both Tango
 and Phobos, and I really wish I could mix and match modules from them 
 without
 giving up my D2 features.  For example, I like Phobos's much simpler 
 IO API, less
 "OO everywhere" look and feel and "simple operations should be 
 simple" mentality,
 but I like Tango's extra math and threading stuff and richer feature 
 set in
 general.  Also, I've written a decent amount of Phobos code that I 
 don't feel like
 porting.

There's no timeframe for D2 support at the moment. I may look into at least having the runtime be cross-compatible, but porting the user code would require changes in structure / coding strategy that I can't see anyone wanting to make.

It seems to me that some people do actually like D2 and aren't using Tango precisely because there's no D2 support. So who knows, maybe you'll find there's a new crop of D2/Tango volunteers that show up once the ball gets rolling. Steven S. for one, perhaps.

Yup. There has been enough interest that I think it's worth getting the runtime working at least. The only real obstacle to that right now is time. The runtime uses the standard C, Posix, and Win32 packages for various things and none of these are D2 compatible at the moment. So the sticking point is really that I need to find the time to go through the standard C and Posix specs and add "in" to all the function parameters that are const in the C APIs. I should have left /*const*/ as a placeholder when I created the modules but... oh well. Live and learn. Sean
Jul 17 2008
parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Sean Kelly" wrote
 Bill Baxter wrote:
 Sean Kelly wrote:
 dsimcha wrote:
 On another note, anyone have any idea when/if Tango for D2, and 
 Tangobos for Tango
 for D2, will be available?  There are things I like and dislike about 
 both Tango
 and Phobos, and I really wish I could mix and match modules from them 
 without
 giving up my D2 features.  For example, I like Phobos's much simpler IO 
 API, less
 "OO everywhere" look and feel and "simple operations should be simple" 
 mentality,
 but I like Tango's extra math and threading stuff and richer feature 
 set in
 general.  Also, I've written a decent amount of Phobos code that I 
 don't feel like
 porting.

There's no timeframe for D2 support at the moment. I may look into at least having the runtime be cross-compatible, but porting the user code would require changes in structure / coding strategy that I can't see anyone wanting to make.

It seems to me that some people do actually like D2 and aren't using Tango precisely because there's no D2 support. So who knows, maybe you'll find there's a new crop of D2/Tango volunteers that show up once the ball gets rolling. Steven S. for one, perhaps.

Yup. There has been enough interest that I think it's worth getting the runtime working at least. The only real obstacle to that right now is time. The runtime uses the standard C, Posix, and Win32 packages for various things and none of these are D2 compatible at the moment. So the sticking point is really that I need to find the time to go through the standard C and Posix specs and add "in" to all the function parameters that are const in the C APIs. I should have left /*const*/ as a placeholder when I created the modules but... oh well. Live and learn.

The Win32 package I believe is already updated in the D2 branch. It was pretty easy, since Windows uses their funky type names for all parameters, I just had to add const to the type definitions, e.g. alias const(char) * LPCSTR; The Posix stuff, I don't remember if we updated. But it did compile with D 2.007. The latest compiler has some issues that make it impossible to use IFTI correctly with const variance, so for the moment, D2 is not an option for Tango. Hopefully these are fixed soon. My goal is to get Tango working on D2 for 2 reasons. 1, I like a lot of the new features, and would like to use them. 2, if Tango users are not using D2, it means that there are a lot of potential testers not finding problems in D2. For bugs, this doesn't concern me a lot, but for design decisions that would make it impossible for Tango to build, I want to get those fixed before D2 is official, as Walter is really really, um.. really really a stickler for not changing design in a 'stable' release :) In other words, I don't want to have to wait for D3 to come out in order to use Tango with it ;) -Steve
Jul 18 2008
prev sibling parent e-t172 <e-t172 akegroup.org> writes:
Bill Baxter a écrit :
 It seems to me that some people do actually like D2 and aren't using 
 Tango precisely because there's no D2 support.

Or the other way around. I don't use D2 because there's no Tango support.
Jul 18 2008