emmanuel | 1 Aug 2009 08:58

Re: [openZIM dev-l] Windows portability feedback

Hi Tommi,

Thank you to have integrated the diff and clean it a little bite.
It works now almost, and only almost because you do not modify the bunzip2stream.cc like indicated in the diff.

I give you now the whol log of the compilation, you will see expect the error on bunzip2strea.cc there are
alos a few warnings, maybe you will have ideas to avoid them.

------ Neues Erstellen gestartet: Projekt: zimlib, Konfiguration: Debug Win32 ------
Die Zwischen- und Ausgabedateien für das Projekt "zimlib" mit der Konfiguration "Debug|Win32" werden gelöscht.
Kompilieren...
article.cpp
zintstream.cpp
..\src\zintstream.cpp(40) : warning C4554: '<<': Prüfen Sie Operatorrangfolge auf mögliche Fehler;
verwenden Sie runde Klammern, um den Vorrang zu verdeutlichen
uuid.cpp
unicode.cpp
c:\code\moulinkiwix\dependences\win\zimlib\include\zim/unicode.h(33) : warning C4800: 'int':
Variable wird auf booleschen Wert ('True' oder 'False') gesetzt (Auswirkungen auf Leistungsverhalten möglich)
c:\code\moulinkiwix\dependences\win\zimlib\include\zim/unicode.h(39) : warning C4800: 'int':
Variable wird auf booleschen Wert ('True' oder 'False') gesetzt (Auswirkungen auf Leistungsverhalten möglich)
c:\code\moulinkiwix\dependences\win\zimlib\include\zim/unicode.h(45) : warning C4800: 'int':
Variable wird auf booleschen Wert ('True' oder 'False') gesetzt (Auswirkungen auf Leistungsverhalten möglich)
c:\code\moulinkiwix\dependences\win\zimlib\include\zim/unicode.h(51) : warning C4800: 'int':
Variable wird auf booleschen Wert ('True' oder 'False') gesetzt (Auswirkungen auf Leistungsverhalten möglich)
c:\code\moulinkiwix\dependences\win\zimlib\include\zim/unicode.h(57) : warning C4800: 'int':
Variable wird auf booleschen Wert ('True' oder 'False') gesetzt (Auswirkungen auf Leistungsverhalten möglich)
c:\code\moulinkiwix\dependences\win\zimlib\include\zim/unicode.h(63) : warning C4800: 'int':
Variable wird auf booleschen Wert ('True' oder 'False') gesetzt (Auswirkungen auf Leistungsverhalten möglich)
c:\code\moulinkiwix\dependences\win\zimlib\include\zim/unicode.h(68) : warning C4800: 'int':
(Continue reading)

Tommi Mäkitalo | 2 Aug 2009 15:51

Re: [openZIM dev-l] Windows portability feedback

Hi,

it was not that I did not apply your patch in bunzip2stream.cpp but because I 
tried (and failed) to do it better.

I use std::min from <algorithm>, but this header was not included. So I added 
it and assumed, it would fix the missing template in VC++. But no I found this: 
http://www.devx.com/tips/Tip/14540. It tells us, that VC++ do not define this 
std::min at all but std::_cpp_min. But of course gcc and other standard 
conformant C++ compilers do not define std::_cpp_min. The suggested solution is 
stupid, since this bounds the code to a non-standard behaviour of VC++.

So the question is, how to convince VC++ to be standard conformant since 
std::min is perfectly that.

I try to prevent #ifdef's, but prefer always to use standard conformant c++. 
But here I currently see no alternative.

Tommi
Tommi Mäkitalo | 2 Aug 2009 22:32

Re: [openZIM dev-l] Windows portability feedback

>
> Unfortunately, the issue seems to be worth now:
> ..\src\bunzip2stream.cpp(47) : error C2226: Syntaxfehler: Typ 'T' nicht
> erwartet ..\src\bunzip2stream.cpp(47) : error C2988: Unerkannte
> Vorlagendeklaration/-definition ..\src\bunzip2stream.cpp(47) : error C2059:
> Syntaxfehler: '<cv-qualifer>' ..\src\bunzip2stream.cpp(47) : error C2059:
> Syntaxfehler: ')'
> ..\src\bunzip2stream.cpp(49) : error C2143: Syntaxfehler: Es fehlt ';' vor
> '}' ..\src\bunzip2stream.cpp(85) : error C2065: 'ret': nichtdeklarierter
> Bezeichner ..\src\bunzip2stream.cpp(86) : error C2065: 'ret':
> nichtdeklarierter Bezeichner ..\src\bunzip2stream.cpp(94) : error C2065:
> 'ret': nichtdeklarierter Bezeichner ..\src\bunzip2stream.cpp(122) : error
> C2589: '(': Ungültiges Token auf der rechten Seite von '::'
> ..\src\bunzip2stream.cpp(122) : error C2988: Unerkannte
> Vorlagendeklaration/-definition ..\src\bunzip2stream.cpp(122) : error
> C2059: Syntaxfehler: '::'
>
> Emmanuel
Strange. I tried to solve the issue by defining my own min template function. 
The problem is, that min is defined as a macro somewhere in windows.h I think. 
This can be prevented by #define NOMINMAX. But I wonder, where windows.h is 
included. Maybe in bzlib.h.

I renamed my min-function now.

Tommi
_______________________________________________
dev-l mailing list
dev-l <at> openzim.org
https://intern.openzim.org/mailman/listinfo/dev-l
(Continue reading)

Manuel Schneider | 3 Aug 2009 07:44
Picon

Re: [openZIM dev-l] ZimReader for Openmoko

Hi Marc,

please excuse my late reply. 

I am very happy to see that porting is going on on new volunteered projects.

Now I am interested if your patches went into the openZIM trunk. Then I would 
like to see a package from you which we can put on our download page for 
other users.

Are you interested to work on that with us? If so I suggest to you to sign up 
for our developers meeting:
http://openzim.org/Developer_Meetings/2009-2

The vote for the best date is still open:
http://www.doodle.com/xaf4tzpuwk2xf59h

Greets,

Manuel

Am Montag, 20. Juli 2009 19:46:13 schrieb Marc Bantle:
> Hi all!
>
> Since an offline  encyclopedia is most valuable on mobile
> devices, I worked on building ZimReader for the Openmoko
> Neo.
>
> As a start I did a native build on a Debian (hackable:1 [3])
> driven Openmoko Freerunner. After fixing some minor build
(Continue reading)

Manuel Schneider | 3 Aug 2009 07:47
Picon

Re: [openZIM dev-l] Windows portability feedback

Hi Emmanuel!

These are great news! I wonder when we will be able to build native Windows 
application from trunk.

Could you also try to compile zimreader.exe? It would be great to have it 
until Wikimania - we should have something like a DVD with spanish Wikipedia.
As far as I remember you have a dump including images?

Greets,

Manuel

Am Mittwoch, 29. Juli 2009 20:54:41 schrieb Emmanuel Engelhart:
> Hi,
>
> I have achieved to compile a first version of a zimlib.lib (static
> library under Windows). I do not really know if I can use it... but at
> least it compiles.
>
> I want to give you here the modifications I have done to achieve that.
> Tommi, it would be great to include them (or others with the same
> purpose) into the SVN.
>
> Index: include/zim/zim.h
> ===================================================================
> --- include/zim/zim.h	(revision 236)
> +++ include/zim/zim.h	(working copy)
>  <at>  <at>  -22,6 +22,12  <at>  <at> 
>
(Continue reading)

Tommi Mäkitalo | 3 Aug 2009 21:45

Re: [openZIM dev-l] Windows portability feedback

Hi,

it is still a long way to go until tntnet and zimreader run on windows. It 
won't work soon. Sorry.

Tommi

On Montag, 3. August 2009 08:25:59 Emmanuel Engelhart wrote:
> Hi,
>
> So now the C++ code of the zimlib is compatible with cl.exe (MS compiler).
>
> But, that does not mean that the zimreader compiles also... as far as I
> know zimreader depends on tntnet and cxxtools which were never compiled
> under Windows.
>
> I'm trying now to port Kiwix... this is currently my top priority.
>
> Emmanuel
>
> Manuel Schneider wrote:
> > Hi Emmanuel!
> >
> > These are great news! I wonder when we will be able to build native
> > Windows application from trunk.
> >
> > Could you also try to compile zimreader.exe? It would be great to have it
> > until Wikimania - we should have something like a DVD with spanish
> > Wikipedia. As far as I remember you have a dump including images?
> >
(Continue reading)

Mirko Lindner | 3 Aug 2009 14:08

Re: [openZIM dev-l] OpenZim

Hi,

great to hear from you.

On Fri, Jul 31, 2009 at 9:48 PM, Tommi Mäkitalo <tommi-+ciCUjOJn3Ednm+yROfE0A@public.gmane.org> wrote:
Hi,

sorry for my late answer. I was on holiday.

No problem at all. I am not pushing the limit these days either :)
 


we are very interested in adopting openzim wherever possible. A nice handheld
device or phone would be a great showcase and of.

Sound great :)
 


The ZimReader actually was once compiled on a openmoko device and it worked.

How can we help?

We are planning to use OWrt to build our images. Currently we are at an early stage but hope to increase the number of people that are working towards a reliable and userland-application ready image.

I just got a few prototypes sent, which will go to different developers and if you find the project interesting, one would go to you :)

I think we should do something like the following:

- get the ZimReader into the OWrt image for the Freerunner to get the basics working

- meanwhile the image on the NanoNote should move forward

- once this is completed we can work directly on the NanoNote

I cc'ed Mirko Voigt from OWrt as he is the person to talk to when it comes to OWrt integration and such.

A few question to help me understand the process:

What software requirements does the ZimReader have? (languages, libs, tools etc)

Where are you based? ( for potential meeting in person )

What information do you need or how can we help you?

Regards,

/mirko



Tommi

On Mittwoch, 22. Juli 2009 17:49:42 you wrote:
> Hi Tommi,
>
> Sorry for using your tntnet address for an OpenZim related mail :)
>
> I am Mirko and part of the Qi Hardware Team.
>
> This Monday we launched our company [1] and announced our first product
> "Ben NanoNote", a fully opened multifunction device [3].
>
> As you can see on the product page the Ben NanoNote does not have a
> build-in RF chip. We therefore think it would be ideal for a project such
> as OpenZim and as a device for an offline version of Wikipedia.
>
> We are very interested to hear what you thoughts are. We have a mailing
> list dedicated for development [3].
>
> We see an OpenZim client as a possibility for one of the standard
> applications shipping in our image, but would need guidance. If you think
> this would be doable and something you would be interested in, let me know.
>
> Regards,
> /Mirko
>
>
> [1]
> http://linux.com/news/embedded-mobile/mids/29263-openmoko-layoffs-lead-to-n
>ew-open-hardware-venture [2]
> http://www.qi-hardware.com/products/ben-nanonote/
> [3] http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer


_______________________________________________
dev-l mailing list
dev-l@...
https://intern.openzim.org/mailman/listinfo/dev-l
Marc Bantle | 4 Aug 2009 23:02
Picon

Re: [openZIM dev-l] ZimReader for Openmoko

Hi Manuel,

Manuel Schneider schrieb:
> Now I am interested if your patches went into the openZIM trunk. 

I saw matching commits both for the build issue
in cxxtools and for the alignment bug in zimlib.
I will soon do some testing.

> Then I would 
> like to see a package from you which we can put on our download page for 
> other users.
>   

Sofar I only wrapped up some tarballs. I want to
have a look at packaging for debian and
openembedded platforms to supply some
decent packages. Haven't found the time yet,
though.

> Are you interested to work on that with us? 
>   

I'll be pleased to help, if I can :-)

> If so I suggest to you to sign up 
> for our developers meeting:
> http://openzim.org/Developer_Meetings/2009-2
>
> The vote for the best date is still open:
> http://www.doodle.com/xaf4tzpuwk2xf59h
>
>   

Thanks for the invitation! I can't promiss anything now, but
I'll follow the list closely and when I see a chance to attend,
I'll let  you know in time.

Cheers,
Marc
Manuel Schneider | 5 Aug 2009 09:05
Picon

Re: [openZIM dev-l] OpenZim

Hi Mirko,

I propose to you to subscribe to dev-l <at> openzim.org - see 
http://openzim.org/Mailinglist.
This is a quite low-volume mailing list.

Am Montag, 3. August 2009 14:08:31 schrieb Mirko Lindner:
> I think we should do something like the following:
>
> - get the ZimReader into the OWrt image for the Freerunner to get the
> basics working

have you seen that there is a package of the zimlib and zimreader for 
openmoko?
https://intern.openzim.org/pipermail/dev-l/2009-July/000122.html
http://www.gut-informierte-kreise.de/openmoko/openzim/

Maybe this gives you at least some fixes to be able to build your binary for 
the Freerunner. As far as Marc wrote yesterday on dev-l his patches were 
integrated into openZIM trunk, so compiling should work now on openmoko.

What is missing are packages - and I think that's exactly your point ;-)
I hope that way the diverse efforts on openmoko can work hand-in-hand.

> A few question to help me understand the process:
>
> What software requirements does the ZimReader have? (languages, libs, tools
> etc)

As far as I know the zimlib has only libbz2 as dependancy, cxxtools should 
have been removed already.

The zimreader needs cxxtools and tntnet, tntnet tries to include gnutls or 
openssl and database backends (via tntdb), but those things can be disabled 
using configure.

> Where are you based? ( for potential meeting in person )

* Zürich (CH, Kiwix)
* Frankfurt/Main (D, tntnet)
* San Francisco (US, Wikimedia Foundation)
* Israel (Wikimedia Israel)
* Lörrach (D, near Basel, Troll)

The next developers meeting will take place this autumn, most likely on 
November 5th - see our poll: http://www.doodle.com/xaf4tzpuwk2xf59h

I would be happy if you like to subscribe: 
http://openzim.org/Developer_Meetings/2009-2

Greets,

Manuel

--

-- 
Regards
Manuel Schneider

Wikimedia CH - Verein zur Förderung Freien Wissens
Wikimedia CH - Association for the advancement of free knowledge
www.wikimedia.ch
_______________________________________________
dev-l mailing list
dev-l <at> openzim.org
https://intern.openzim.org/mailman/listinfo/dev-l
Manuel Schneider | 5 Aug 2009 09:11
Picon

Re: [openZIM dev-l] OpenZim

Sorry:

Am Mittwoch, 5. August 2009 09:05:56 schrieb Manuel Schneider:
> The next developers meeting will take place this autumn, most likely on
> November 5th - see our poll: http://www.doodle.com/xaf4tzpuwk2xf59h

most likely on November 14th, I mean.

--

-- 
Regards
Manuel Schneider

Wikimedia CH - Verein zur Förderung Freien Wissens
Wikimedia CH - Association for the advancement of free knowledge
www.wikimedia.ch
_______________________________________________
dev-l mailing list
dev-l <at> openzim.org
https://intern.openzim.org/mailman/listinfo/dev-l

Gmane