Re: [AD] END_OF_MAIN removal patch for msvc

[ Thread Index | Date Index | More lists.liballeg.org/allegro-developers Archives ]


On November 19, 2008, Thomas Fjellstrom wrote:
> On November 19, 2008, Peter Wang wrote:
> > On 2008-11-19, Stefanos A. <stapostol@xxxxxxxxxx> wrote:
> > > On Wed, 2008-11-19 at 19:11 +1100, Peter Wang wrote:
> > > > On 2008-11-19, Thomas Fjellstrom <tfjellstrom@xxxxxxxxxx> wrote:
> > > > > On November 18, 2008, Peter Wang wrote:
> > > > > > No.  I may want to use Allegro in an environment where my code is
> > > > > > not allowed to block in al_run().  I know it might not work on
> > > > > > certain platforms, but that's my choice to make.
> > > > >
> > > > > All I really care about is making the api consistent. Meaning the
> > > > > actual code the user has to write is identical on all supported
> > > > > platforms. None of this "I don't have to do it here, so I won't,
> > > > > even if it isn't compatible with other supported platforms".
> > > >
> > > > So you want to artificially prevent me from using Allegro in some
> > > > situations because it might not be portable to some brain dead
> > > > platform that I don't care about?  Right.
> > >
> > > Concrete example of such a situation where "my code is not allowed to
> > > block in al_run()"?
> >
> > Say, running in a language interpreter which provides a foreign function
> > interface where I can make calls into C function, but I can't call back
> > into the other language.
> >
> > Or maybe I'm writing plugin for a web browser.
> >
> > > Any reason why you can't just fork before calling
> > > al_init &  al_run?
> >
> > Why should I?  I'm not distributing my program to anyone, and I don't
> > have a Mac.
> >
> > > I'm not saying al_run is the best or even a good
> > > design, although I do believe it's better than the END_OF_MAIN macro.
> >
> > I know it's a better design, I proposed it.  But why enforce it
> > where it's unnecessary?
> >
> > > What about the alternative, i.e. calling al_process_events
> > > periodically? It has minimal impact to the API, it does not tie you to
> > > a paradigm you may not care about, it does not block. Any downsides?
> >
> > To me, that's a huge impact.
>
> A few (at most) functions calls is "huge"? more so than an inconsistent api
> that encourages making platform specific code?
>
> > Thomas, the END_OF_MAIN() in A4 did cause trouble for people trying to
> > dlopen() the Allegro .so file, because the .so file expects a
> > _mangled_main_address symbol.  It is possible to hack around it on Linux
> > by defining it manually but I'm not sure it works everywhere.
>
> I know, I've loaded allegro as a plugin in things before. Its annoying, and
> unnecessary. But I really don't want to see the api be inconsistent. Even
> though I prefer to be flexible, flexibility is for power users. Allegro
> isn't really targeted at power users.

I normally hate forcing things on a user, but I'd much prefer making it easier 
on people trying to get apps running on different platforms, than be super 
flexible for few users.

> > Peter
> >
> >
> > -------------------------------------------------------------------------
> > This SF.Net email is sponsored by the Moblin Your Move Developer's
> > challenge Build the coolest Linux based applications with Moblin SDK &
> > win great prizes Grand prize is a trip for two to an Open Source event
> > anywhere in the world
> > http://moblin-contest.org/redirect.php?banner_id=100&url=/
>
> --
> Thomas Fjellstrom
> tfjellstrom@xxxxxxxxxx
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge Build the coolest Linux based applications with Moblin SDK & win
> great prizes Grand prize is a trip for two to an Open Source event anywhere
> in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/


-- 
Thomas Fjellstrom
tfjellstrom@xxxxxxxxxx




Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/