I'd object to your implication that Haskell is completely ready for
use in general soft real-time systems. I was unable to implement a
multi-threaded application which does a some IO-work in background
threads in a way so that its GUI won't die. Worker threads simply
starve the GUI, because
On Tue, Feb 5, 2013 at 1:56 PM, kudah kudahkuka...@gmail.com wrote:
I'd object to your implication that Haskell is completely ready for
use in general soft real-time systems. I was unable to implement a
multi-threaded application which does a some IO-work in background
threads in a way so
kudah kudahkuka...@gmail.com wrote:
I'd object to your implication that Haskell is completely ready for
use in general soft real-time systems. I was unable to implement a
multi-threaded application which does a some IO-work in background
threads in a way so that its GUI won't die. Worker
I used gtk2hs, because I couldn't find a free software design tool that was
at least as good as glade3. Last time I tried to compile wxHaskell, wxc
produced an enormous dynamic library which also linked to every
wxWidgets library out there(e.g. wxwebkit), so that the resulting mess
couldn't be
I followed dmwit's guide on threaded gtk2hs, all GUI interaction is in the
main thread, which is always bounded. This shouldn't really impact the
lag, as soon as gtk2hs calls back to haskell, nothing stops the RTS
from delaying main thread's peaceful return to C-land for arbitrary amount
of time.
Casey Basichis caseybasic...@gmail.com wrote:
I'm not entirely sure what you mean.
I'm intending on using Ogre for GUI - for which there is the Hogre
bindings, but after emailing the DEV about it, I didn't get the
impression from his advice that I should be using it for production
code.
Quoth Casey Basichis caseybasic...@gmail.com,
...
I am using several other C++ libraries for which there are no existing
bindings and no Haskell alternative packages that are even remotely
close.
Are you suggesting it would be better to write all my own FFI bindings
for all the needed
Hi Ertugrul,
Thank you for the detailed reply. From what you wrote, partial FFI still
seems like the way to go.
Unfortunately Ogre isn't the only large library I'm using, so difficult
several times over sounds like a good way to handicap the project early on.
I'm perfectly happy to use Haskell
From my experience, these things are needed to get solid (i.e. not flaky
software) results.
This is not what normal Haskell bindings look like though:
1. Create an interface over the Haskell RTS if you are going to use any of
it from C++, and use dependency injection to choose between mock and
On Thu, Jan 31, 2013 at 11:11 AM, Casey Basichis caseybasic...@gmail.comwrote:
Hi,
I'm working on a project in Haskell and C++ where the former is the brains
and the latter is for UI, interaction etc.
I've read this
http://www.altdevblogaday.com/2012/04/26/functional-programming-in-c/ and
Hi,
I'm working on a project in Haskell and C++ where the former is the brains
and the latter is for UI, interaction etc.
I've read this
http://www.altdevblogaday.com/2012/04/26/functional-programming-in-c/ and a
number of other haskell posts suggesting the OOP is not the way to go.
Without
Casey Basichis caseybasic...@gmail.com wrote:
I'm working on a project in Haskell and C++ where the former is the
brains and the latter is for UI, interaction etc.
That's a rather odd choice. Not exactly answering your question, but
questioning your project decisions, why would you do UI and
Hi Ertugrul,
I'm not entirely sure what you mean.
I'm intending on using Ogre for GUI - for which there is the Hogre
bindings, but after emailing the DEV about it, I didn't get the
impression from his advice that I should be using it for production
code. Here is what he suggested:
It depends,
13 matches
Mail list logo
