Re: [wxhaskell-users] wxHaskell 0.10.3: problems in Windows XP

[Conal Elliott]

As long as there's a single binary (per release per platform) I'm for opengl
being part of it.

On Sat, Mar 29, 2008 at 6:56 AM, Eric Y. Kow <[EMAIL PROTECTED]> wrote:

> Hi,
>
> Answering the one question I know an answer to.
>
> > In the meanwhile, I also found that the 0.10.3 binaries loose the
> > opengl support compared with 0.9.4 as pointed in
> > http://wxhaskell.sourceforge.net/download.html.
> > Is there some reason for this?
>
> There used to be a flag bug in wxWidgets/wxHaskell, where (1)
> wxWidgets/wxHaskell would include opengl support even if you did not
> ask for it and (2) you still needed to pass --with-opengl in order
> for the appropriate right set of linker flags to be used when building
> applications.  Otherwise, people got strange GL-related errors when
> compiling their apps, even if they weren't using OpenGL in any way.
>
> We have now fixed that error so that you can now compile it without that
> flag and still link your applications succesfully.
>
> That said, we have not established a policy on what extra batteries
> should be included with the default binaries.  I guess a good thing to
> aim for is the most extras we can get that also come with a vanilla
> wxWidgets on all platforms.  If you're willing to do research on that,
> we can go re-think what flags to use.  I'm guessing that since prior
> versions of wxHaskell had opengl support, this kind of thing is OK.
>
> I'm personally hoping that a future wxhaskell will allow to install
> extras separately (e.g., that you could download just a binary for
> opengl support), but we haven't really worked out the right way to
> do this right.
>
> So what does this mean for you?  Well, if you're willing to do so, you
> could recompile it yourself with flags.  Otherwise, we could think about
> making yet another release (0.10.3-1) with opengl and some minor fixes
> in the makefile/configure script.
>
> --
> Eric Kow 
> PGP Key ID: 08AC04F9
>
> -
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
>
> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
> ___
> wxhaskell-users mailing list
> wxhaskell-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wxhaskell-users
>
>
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace___
wxhaskell-users mailing list
wxhaskell-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxhaskell-users

Re: [wxhaskell-users] wxHaskell 0.10.3: problems in Windows XP

[José Miguel Vilaça]

Hi,

The Microsoft Visual C++ 2005 SP1 Redistributable Package solves the
problem. Just great! 

If anyone with access to wxHaskell webpage at sourceforge could add a note
in downloads page about this issue, could avoid others to have this problem.
Something like
You may need to install Microsoft Visual C++ 2005 SP1 Redistributable
Package
(http://www.microsoft.com/downloads/details.aspx?FamilyID=200b2fd9-ae1a-4a14
-984d-389c36f85647&DisplayLang=en) or else you may see the error message
"The applicattion failed to initialize properly (0xc0150002). Click OK to
terminate the application." when you compile your wxHaskell dependent code
and run those executables.

Many thanks!
Miguel Vilaça


-Mensagem original-
De: shelarcy [mailto:[EMAIL PROTECTED] 
Enviada: sábado, 29 de Março de 2008 14:34
Para: José Miguel Vilaça
Cc: wxhaskell-users
Assunto: Re: RE: wxHaskell 0.10.3: problems in Windows XP

Hi,

On Thu, 27 Mar 2008 07:55:50 +0900, José Miguel Vilaça
<[EMAIL PROTECTED]> wrote:
> I successfully installed Visual C++ 2005 Redistributable Package on
Windows
> XP but the same error remains. I even rebooted (for some reason this
usually
> solve many problems) the machine but no luck either.
>
> I'll take more time around this during the weekend, to see if I discover
the
> reason for this error.

Oops ... I found "SP1" Redistributable Package is different from non-SP
Redistributable Package.

Please try to use Microsoft Visual C++ 2005 SP1 Redistributable Package
(x86).

http://www.microsoft.com/downloads/details.aspx?FamilyID=200b2fd9-ae1a-4a14-
984d-389c36f85647&DisplayLang=en

-- 
shelarcy 
http://page.freett.com/shelarcy/


-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
___
wxhaskell-users mailing list
wxhaskell-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxhaskell-users

Re: [wxhaskell-users] Binding wxImage::Get/SetOption and InMemoryStream constructor

[shelarcy]

Hi,

On Sat, 29 Mar 2008 23:29:08 +0900, Eric Y. Kow <[EMAIL PROTECTED]> wrote:
>> What's the EXWXEXPORT() macro for? It didn't seem very useful to me...
>
> (snip)
>
> I get the impression that it's there for some kind of portability reasons.
> Will need to do research on this mysterious __declspec(dllexport), __cdecl and
> _cdecl business to understand better.  Anyone already know what these do?

__declspec(dllexport) is a calling convention to export functions in DLL,
on Windows platform (Visual Studio). This convention's advantage is efficiency.

http://msdn2.microsoft.com/en-us/library/3y1sfaz2(VS.80).aspx
http://msdn2.microsoft.com/en-us/library/9h658af8(VS.80).aspx

So, EXWXEXPORT is important for Windows user.


Best Regards,

-- 
shelarcy 
http://page.freett.com/shelarcy/

-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
___
wxhaskell-users mailing list
wxhaskell-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxhaskell-users

Re: [wxhaskell-users] wxHaskell 0.10.3: problems in Windows XP

[shelarcy]

On Sat, 29 Mar 2008 22:41:19 +0900, Miguel Vilaça <[EMAIL PROTECTED]> wrote:
> Some pratical, to find a solutions is pointed in
> http://www.tech-archive.net/Archive/VC/microsoft.public.vc.mfc/2006-09/msg02020.html:
> "To see dependent DLLs, open your application with the dependency
> viewer (depends.exe)."
>
> Can you please take a look on this and see if everything needed is
> going into the DLL?

Dependency Walker is free. So, I think you can look that yourself.

http://www.dependencywalker.com/

Anyway I saw that.

> Error: At least one required implicit or forwarded dependency was not found.
> Warning: At least one delay-load dependency module was not found.
> Warning: At least one module has an unresolved import due to a missing export 
> function in a delay-load dependent module.

This error come from MSVCR80.DLL.
And I found SP1's DLL is different from non-SP one today that I told you in 
previous mail.
So, please test SP1's DLL.


> In the meanwhile, I also found that the 0.10.3 binaries loose the
> opengl support compared with 0.9.4 as pointed in
> http://wxhaskell.sourceforge.net/download.html.
> Is there some reason for this?

I always enable opengl support to release Windows binary.
(Because previous version (include 0.9.4) is built by that policy.)

I think this difference is come from ghc's behavior change.
Please use -package OpenGL or --make to build executable files.

Best Regards,

-- 
shelarcy 
http://page.freett.com/shelarcy/

-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
___
wxhaskell-users mailing list
wxhaskell-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxhaskell-users

Re: [wxhaskell-users] wxHaskell 0.10.3: problems in Windows XP

[shelarcy]

Hi,

On Thu, 27 Mar 2008 07:55:50 +0900, José Miguel Vilaça <[EMAIL PROTECTED]> 
wrote:
> I successfully installed Visual C++ 2005 Redistributable Package on Windows
> XP but the same error remains. I even rebooted (for some reason this usually
> solve many problems) the machine but no luck either.
>
> I'll take more time around this during the weekend, to see if I discover the
> reason for this error.

Oops ... I found "SP1" Redistributable Package is different from non-SP
Redistributable Package.

Please try to use Microsoft Visual C++ 2005 SP1 Redistributable Package (x86).

http://www.microsoft.com/downloads/details.aspx?FamilyID=200b2fd9-ae1a-4a14-984d-389c36f85647&DisplayLang=en

-- 
shelarcy 
http://page.freett.com/shelarcy/

-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
___
wxhaskell-users mailing list
wxhaskell-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxhaskell-users

Re: [wxhaskell-users] Binding wxImage::Get/SetOption and InMemoryStream constructor

[Eric Y. Kow]

Hi,

By the way, if I haven't already mentioned this, there is a wxhaskell-devel
that you may prefer to discuss this on.  Personally, I'm happy either way.

> The code is so short that I embed it in this email. I'd be interested
> to hear any comments on the way I did this, and what you would want to
> change before committing it to wxhaskell.

Sorry, I can't offer much insight here.  Hoping somebody else pipes up.
Looking forward to your patch, in any case.

> Then a haskell stub file to wrap a Ptr version of this and two
> bytestring versions:

Note that wxhaskell doesn't currently use the bytestring package.  I
guess this would be a pretty safe thing to add, since if I understand
correctly, it's been around since GHC 6.6.  On the other hand, unless
we're willing to say that we only support GHC 6.8.2+, starting from
wxhaskell 0.11

> It works, anyhow. I am able to load images from bytestreams (as it
> happens, the cover art from an M4A file). The magic invocation to get
> ghc to link it correctly seems to be:
> 
> ghc --make main.hs cstub.o -lstdc++ `wx-config --libs` -optl -fexceptions

I think that by rights, it should be possible to modify wxcore, so that
the right linker flags get used when you use the wxcore package (e.g.
with ghc --make)

> For return types of type String, looking at the examples in elj*.cpp,
> why does it sometimes use copyStrToBuf to unpack the WxString on the
> C++ side in combination with withWStringResult on the haskell side,
> and other times just pass back the a freshly allocated WxString* from
> C++ in combination with withManagedStringResult?

Not sure.  In case you were curious, copyStrToBuf was something I
had introduced in my Unicode patches to replace

  if (_buf) memcpy (_buf, result.c_str(), result.Length());
  return result.Length();

The reason for doing it this way was quite simply that I had gotten
sick of repeating

  if (dst) wxStrcpy ((wxChar*) dst, src.c_str());
  return src.Length();

In any case, I guess it doesn't answer your question.  I just wanted to
point our that there isn't anything particularly special about this
helper, which you probably realise anyway.

> For arguments of object types, why do some bindings use withObjectPtr
> and some use withObjectRef?

I don't know.  Anybody else?

> What's the EXWXEXPORT() macro for? It didn't seem very useful to me...

You meant EWXWEXPORT :-D  Again, I do not know.  I guess that you have also had
a look at wxc/include/ewxw_def.h.  Looking at it...

#ifdef __WATCOMC__
  #include 
  #define EWXWEXPORT(TYPE,FUNC_NAME) TYPE __export __cdecl FUNC_NAME
#else
  #ifdef _WIN32
#define EWXWEXPORT(TYPE,FUNC_NAME) __declspec(dllexport) TYPE __cdecl 
FUNC_NAME
#undef EXPORT
#define EXPORT extern "C" __declspec(dllexport) 
  #else
#define EWXWEXPORT(TYPE,FUNC_NAME) TYPE FUNC_NAME
  #endif
  #ifndef _cdecl
#define _cdecl
  #endif
#endif

I get the impression that it's there for some kind of portability reasons.
Will need to do research on this mysterious __declspec(dllexport), __cdecl and
_cdecl business to understand better.  Anyone already know what these do?
 
I did not find any (relevant) instances of the string 'EWXW' in wxdirect, and
thus surmise that (unlike TSelf), it is not used for generating the Haskell
binding.  One possibility is that it's just some vestigal code from the
wxEiffel days, and isn't actually useful anymore.

Sorry to be unhelpful :-/

-- 
Eric Kow 
PGP Key ID: 08AC04F9


pgpj5wzguMPLP.pgp
Description: PGP signature
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace___
wxhaskell-users mailing list
wxhaskell-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxhaskell-users

Re: [wxhaskell-users] wxHaskell 0.10.3: problems in Windows XP

[Eric Y. Kow]

Hi,

Answering the one question I know an answer to.

> In the meanwhile, I also found that the 0.10.3 binaries loose the  
> opengl support compared with 0.9.4 as pointed in  
> http://wxhaskell.sourceforge.net/download.html.
> Is there some reason for this?

There used to be a flag bug in wxWidgets/wxHaskell, where (1)
wxWidgets/wxHaskell would include opengl support even if you did not
ask for it and (2) you still needed to pass --with-opengl in order
for the appropriate right set of linker flags to be used when building
applications.  Otherwise, people got strange GL-related errors when
compiling their apps, even if they weren't using OpenGL in any way.

We have now fixed that error so that you can now compile it without that
flag and still link your applications succesfully.

That said, we have not established a policy on what extra batteries
should be included with the default binaries.  I guess a good thing to
aim for is the most extras we can get that also come with a vanilla
wxWidgets on all platforms.  If you're willing to do research on that,
we can go re-think what flags to use.  I'm guessing that since prior
versions of wxHaskell had opengl support, this kind of thing is OK.

I'm personally hoping that a future wxhaskell will allow to install
extras separately (e.g., that you could download just a binary for
opengl support), but we haven't really worked out the right way to
do this right.

So what does this mean for you?  Well, if you're willing to do so, you
could recompile it yourself with flags.  Otherwise, we could think about
making yet another release (0.10.3-1) with opengl and some minor fixes
in the makefile/configure script.

-- 
Eric Kow 
PGP Key ID: 08AC04F9


pgp3arhgOAljH.pgp
Description: PGP signature
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace___
wxhaskell-users mailing list
wxhaskell-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxhaskell-users

Re: [wxhaskell-users] wxHaskell 0.10.3: problems in Windows XP

[Miguel Vilaça]

Hi again,

After several unsuccesseful tries, and some googling, I found out many  
complains   of people seeing the message "The applicattion failed to  
initialize properly (0xc0150002). Click OK to terminate the  
application." when they run their executables out of the devellopment  
machine.

The error also seems to be often related with:
* DXUT - related with images and DirectX SDK - (see  
http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1048802&SiteID=1)
* MS Office (see  
http://support.microsoft.com/search/default.aspx?mode=r&catalog=LCID%3d1033&1033comm=1&spid=global&query=0xc0150002
   
)

Some pratical, to find a solutions is pointed in  
http://www.tech-archive.net/Archive/VC/microsoft.public.vc.mfc/2006-09/msg02020.html:
"To see dependent DLLs, open your application with the dependency  
viewer (depends.exe)."

Can you please take a look on this and see if everything needed is  
going into the DLL?


In the meanwhile, I also found that the 0.10.3 binaries loose the  
opengl support compared with 0.9.4 as pointed in  
http://wxhaskell.sourceforge.net/download.html.
Is there some reason for this?

In my specific case that will also be a problem.
But the 0xc0150002 is not related to this since the simple (and not  
opengl related) HelloWorld.exe continues failling in my machine.

Since I found one machine that runs the code and one that doesn't, I  
comparing the software installed on them. Maybe I found a solution  
this way!!

best
Miguel Vilaça



Quoting José Miguel Vilaça <[EMAIL PROTECTED]>:

> Hi Shelarcy,
>
> Thanks for your quick help.
>
> I successfully installed Visual C++ 2005 Redistributable Package on Windows
> XP but the same error remains. I even rebooted (for some reason this usually
> solve many problems) the machine but no luck either.
>
> I'll take more time around this during the weekend, to see if I discover the
> reason for this error.
>
> In the meanwhile, I would appreciate any report of a successful installation
> of wxHaskell binary on Windows XP (without the development stuff). Anyone?
> Just to check if this is a specific error (of this machine) or a global one.
>
> Best
> Miguel Vilaça
>
>
> -Mensagem original-
> De: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Em nome de shelarcy
> Enviada: quarta-feira, 26 de Março de 2008 14:20
> Para: Miguel Vilaça
> Cc: wxhaskell-users
> Assunto: Re: [wxhaskell-users] wxHaskell 0.10.3: problems in Windows XP
>
> Hi Miguel,
>
> On Wed, 26 Mar 2008 21:21:47 +0900, Miguel Vilaça <[EMAIL PROTECTED]>
> wrote:
>> "The applicattion failed to initialize properly (0xc0150002). Click OK
>> to terminate the application."
>
> I searched this error using goole, then I found similar problem form
> websites
> and forums. Some of them advice to install Visual C++ 2005 Redistributable
> Package.
>
> http://www.issociate.de/board/post/474708/Xampp_Apache_Install_Problem.html
>
> How about install that?
> You can get that from below page.
>
> http://www.microsoft.com/Downloads/details.aspx?FamilyID=32bc1bee-a3f9-4c13-
> 9c99-220b62a191ee&displaylang=en
>
> Best Regards,
>
> --
> shelarcy 
> http://page.freett.com/shelarcy/
>
> -
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
> ___
> wxhaskell-users mailing list
> wxhaskell-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wxhaskell-users
>
>
> -
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
> ___
> wxhaskell-users mailing list
> wxhaskell-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wxhaskell-users
>




-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
___
wxhaskell-users mailing list
wxhaskell-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxhaskell-users

[wxhaskell-users] Binding wxImage::Get/SetOption and InMemoryStream constructor

[Jules Bean]

So, I have successfully added some of the missing bindings that I needed.

The code is so short that I embed it in this email. I'd be interested
to hear any comments on the way I did this, and what you would want to
change before committing it to wxhaskell.

1) Loading images from in-memory blocks

Stub C++ file to bind to the appropriate wxImage constructor:

#include "wx/wx.h"
#include "wx/image.h"
#include "wx/mstream.h"

extern "C"
{
   void * wxImage_CreateFromFileInMemory(void* data,int length,int type) {
 wxMemoryInputStream in(data,length);
 return (void*) new wxImage(in,type);
   }
}

You can compile this with "g++ -c `wx-config --cppflags` cstub.cpp"

Then a haskell stub file to wrap a Ptr version of this and two
bytestring versions:

{-# OPTIONS -fglasgow-exts #-}
module ImageExtras where

import qualified Data.ByteString.Lazy as LB
import qualified Data.ByteString as B
import Foreign
import Foreign.C
import Graphics.UI.WXCore.WxcTypes
import Graphics.UI.WXCore.WxcClassTypes

imageCreateFromPtrFile :: Ptr b -> Int -> Int -> IO (Image ())
imageCreateFromPtrFile ptr len typ
   = withManagedObjectResult $
 wxImage_CreateFromFileInMemory ptr (fromIntegral len) (fromIntegral 
typ)
foreign import ccall "wxImage_CreateFromFileInMemory"
   wxImage_CreateFromFileInMemory :: Ptr b -> CInt -> CInt -> IO (Ptr 
(TImage ()))
imageCreateFromLBytestringFile :: LB.ByteString -> Int -> IO (Image  ())
imageCreateFromLBytestringFile bs typ
   = withArray (LB.unpack bs) $ \ptr ->
   imageCreateFromPtrFile ptr (fromIntegral $ LB.length bs) typ

imageCreateFromBytestringFile :: B.ByteString -> Int -> IO (Image  ())
imageCreateFromBytestringFile bs typ
   = withArray (B.unpack bs) $ \ptr ->
   imageCreateFromPtrFile ptr (B.length bs) typ

I'm not sure if you can make these a bit more efficient by attacking
the underlying bytestring rep, but I didn't try.

It works, anyhow. I am able to load images from bytestreams (as it
happens, the cover art from an M4A file). The magic invocation to get
ghc to link it correctly seems to be:

ghc --make main.hs cstub.o -lstdc++ `wx-config --libs` -optl -fexceptions

2) GetOption / SetOption for Images

Slightly more fiddly. The C++ stub looks like this:

#include "wx/wx.h"
#include "wx/image.h"

extern "C"
{
   void wxImage_SetOption(void *_obj, void* key,void *value) {
 ((wxImage*)_obj)->SetOption((wxChar*)key,(wxChar*)value);
   }
   wxString* wxImage_GetOption(void *_obj, void* key) {
 return new wxString(((wxImage*)_obj)->GetOption((wxChar*)key));
   }
}

(it took me quite a while to understand why casting to wxChar* works
when the underlying type is WxString&; there is an implicit conversion
because of a constructor)

The haskell stub is this:

{-# OPTIONS -fglasgow-exts #-}
module ImageOptions where

import Graphics.UI.WXCore.WxcTypes
import Graphics.UI.WXCore.WxcClassTypes

imageSetOption :: Image a -> String -> String -> IO ()
imageSetOption _obj key value =
   withObjectRef "imageSetOption" _obj $ \cobj ->
   withCWString key $ \cstr_key ->
   withCWString value $ \cstr_value ->
   wxImage_SetOption cobj cstr_key cstr_value
foreign import ccall "wxImage_SetOption" wxImage_SetOption ::
   Ptr (TImage a) -> CWString -> CWString -> IO ()

imageGetOption :: Image a -> String -> IO String
imageGetOption _obj key =
   withManagedStringResult $
   withObjectRef "imageGetOption" _obj $ \cobj ->
   withCWString key $ \cstr_key ->
   wxImage_GetOption cobj cstr_key
foreign import ccall "wxImage_GetOption" wxImage_GetOption ::
   Ptr (TImage a) -> CWString -> IO (Ptr (TWxString ()))


3) Points of confusion:

For return types of type String, looking at the examples in elj*.cpp,
why does it sometimes use copyStrToBuf to unpack the WxString on the
C++ side in combination with withWStringResult on the haskell side,
and other times just pass back the a freshly allocated WxString* from
C++ in combination with withManagedStringResult?

For arguments of object types, why do some bindings use withObjectPtr
and some use withObjectRef?

What's the EXWXEXPORT() macro for? It didn't seem very useful to me...

Thanks,

Jules

-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
___
wxhaskell-users mailing list
wxhaskell-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxhaskell-users