BaH.DateTime module problem...

BlitzMax Forums/Brucey's Modules/BaH.DateTime module problem...

Michel R.(Posted 2013) [#1]
Hi Brucey (and all of you...),

I would like to use your datetime module but I've a problem to use it:
I've downloaded some of your modules and installed them in
C:/BlitzMax/mod/bah.mod/
I've installed boost.mod, locale.mod, box2d.mod and datetime.mod
I've compiled them with mingW v 4.7.2 (windows 7)
(I've tried using prompt command " bmk makemods namespace.modulename"
and with "Build all modules" in Blide plus)
When I try the program samples, locale end box2d works perfectly but none of the sample programs for datetime module seems to work.
The compilation doesn't generate any error: here is an example of the output:

Building executable...
Compiling:date_period_calc.bmx

flat assembler version 1.69.14 (1461873 kilobytes memory)
3 passes, 4035 bytes.
Linking:date_period_calc.debug.exe

I see on the screen that a program is running and after a few seconds the program stops without any message on the console output.

Can you help me ? Thanks


Michel R.(Posted 2013) [#2]
Is there anybody to help me ?

One more thing:
If I just add the line
Import BaH.DateTime
in a program, this one doesn't work after compilation.

Thanks


xlsior(Posted 2013) [#3]
Try this:

bmk makemods -a bah.datetime
bmk makemods -a -h bah.datetime


(Without the -a, bmk won't actually recompile if it doesn't see the need)


Michel R.(Posted 2013) [#4]
Thank you xlsior, but...
it doesn't solve my problem...
The module compilation works (or seems to work); this is the output:
(sorry, I don't know how to separate the text in a box)
...
Compiling:date_generators.cpp
Compiling:greg_month.cpp
Compiling:greg_weekday.cpp
Compiling:gregorian_types.cpp
Compiling:glue.cpp
Compiling:source.bmx
flat assembler version 1.69.14 (1572863 kilobytes memory)
3 passes, 8517 bytes.
Compiling:datetime.bmx
flat assembler version 1.69.14 (1572863 kilobytes memory)
3 passes, 141228 bytes.
Archiving:datetime.debug.win32.x86.a
Compiling:date_generators.cpp
Compiling:greg_month.cpp
Compiling:greg_weekday.cpp
Compiling:gregorian_types.cpp
Compiling:glue.cpp
Compiling:source.bmx
flat assembler version 1.69.14 (1572863 kilobytes memory)
3 passes, 1757 bytes.
Compiling:datetime.bmx
flat assembler version 1.69.14 (1572863 kilobytes memory)
3 passes, 66054 bytes.
Archiving:datetime.release.win32.x86.a
...
after that, I've compiled my program (both in debug mode and relase mode) and the problem is the same...
I've seen that datetime module needs boost module so I've compiled thie module in the same way (bmk makemods -a bah.boost) but this is not the solution...

Have you another idea ?


Michel R.(Posted 2013) [#5]
Well, I'm back again with my module problem...
I've deleted the boost.mod and datetime.mod directories. I've downloaded the zip file from Brucey's BlitzMax Module collection site; extracted boost and datetime in
c:\blitzmax\mod\bah.mod\
(the same directory where I've put locale.mod, format.mod,...)
then I've compiled them:

bmk makemods -a bah.boost
bmk makemods -a -h bah.boost
bmk makemods -a bah.datetime
bmk makemods -a -h bah.datetime

and finally, I try this program:
...
SuperStrict

' calculates the number of days till new years.
' Provides a simple example of using a date generator, and simple
' mathematical operations, to calculate the days since
' New Years day of this year, and days until next New Years day.

Framework BaH.DateTime
Import BRL.StandardIO


Local today:TDate = TDate.localDay()

Local newYearsDay:TPartialDate = TPartialDate.Create(1, Jan)

' Subtract two dates to get a duration
Local daysSinceYearStart:Int = today.subtractDate(newYearsDay.getDate(today.year()))

Print "Days since Jan 1: " + daysSinceYearStart

Local daysUntilYearStart:Int = newYearsDay.getDate(today.year() + 1).subtractDate(today)

Print "Days until next Jan 1: " + daysUntilYearStart
...
(in fact days_between_new_years.bmx example) and it's always the same thing!...
the compilation is ok:
...
Building executable...
Compiling:days_between_new_years.bmx

flat assembler version 1.69.14 (1572863 kilobytes memory)
3 passes, 2222 bytes.
Linking:days_between_new_years.debug.exe
...
and at the execution, my computer 'hangs' (or halts) for approx. 5/6 seconds and nothing appears on the screen...

What can I do ?


Henri(Posted 2013) [#6]
Hello,

there is nothing wrong with your example, it works here so there is something wrong with your setup. What MinGW distro you have ?


-Henri


Michel R.(Posted 2013) [#7]
Henri:
it's the standard version from mingw.org:
gcc version 4.7.2


Henri(Posted 2013) [#8]
I think there lies your problem. Blitzmax folder has 2 subfolders named "lib" and "bin" which contain MinGW-libraries, linker (ld.exe) and GNU-archive tool (ar.exe). Everytime you choose MinGW distro that is different than the one that these files were compiled from (default distro is Nuwen 7.2) you also have to copy these files from MinGW-folder(usually C:\MinGW) to Blitzmax-folder replacing existing files (if you have already done so I apologize the lecture :-) ). There is also other differences between distros so I would recommend tried&tested Nuwen distro Link instead of the official and after everything do a complete rebuild of modules.


-Henri


xlsior(Posted 2013) [#9]
Also, you can't mix and match libraries compiled with different MinGW versions, so after you do what Henri stated above, you'll have to recompile -all- modules for them to be consistent:

bmk makemods -a
bmk makemods -a -h


Michel R.(Posted 2013) [#10]
@Henri:
I've lost half of my hair...
1/ I've uninstalled MinGW
2/ I've loaded MinGW Nuwen distro with your link
3/ I've installed it as explained on the site.
3/ I've copied c:\MinGW\bin and c:\MinGW\lib directories in blitzmax
4/ With Blide Plus, I click on "Build all modules" and voilà:
...
bah.datetime was scheduled to next iteration
ar: creating C:/BlitzMax/mod/bah.mod/boost.mod/boost.debug.win32.x86.a
ar: creating C:/BlitzMax/mod/bah.mod/boost.mod/boost.release.win32.x86.a
C:/BlitzMax/mod/bah.mod/boost.mod/src/libs/date_time/src/gregorian/greg_month.cpp: In static member function 'static boost::gregorian::greg_month::month_map_ptr_type boost::gregorian::greg_month::get_month_map_ptr()':
C:/BlitzMax/mod/bah.mod/boost.mod/src/libs/date_time/src/gregorian/greg_month.cpp:51:12: error: use of deleted function 'boost::shared_ptr<std::map<std::basic_string<char>, short unsigned int> >::shared_ptr(const boost::shared_ptr<std::map<std::basic_string<char>, short unsigned int> >&)'
return month_map_ptr;
^
In file included from C:/BlitzMax/mod/bah.mod/boost.mod/src/boost/shared_ptr.hpp:17:0,
from C:/BlitzMax/mod/bah.mod/boost.mod/src/boost/date_time/gregorian/greg_month.hpp:14,
from C:/BlitzMax/mod/bah.mod/boost.mod/src/libs/date_time/src/gregorian/greg_month.cpp:14:
C:/BlitzMax/mod/bah.mod/boost.mod/src/boost/smart_ptr/shared_ptr.hpp:168:25: note: 'boost::shared_ptr<std::map<std::basic_string<char>, short unsigned int> >::shared_ptr(const boost::shared_ptr<std::map<std::basic_string<char>, short unsigned int> >&)' is implicitly declared as deleted because 'boost::shared_ptr<std::map<std::basic_string<char>, short unsigned int> >' declares a move constructor or move assignment operator
template<class T> class shared_ptr
^
Build Error: failed to compile C:/BlitzMax/mod/bah.mod/boost.mod/src/libs/date_time/src/gregorian/greg_month.cpp
&#9658;&#9658;&#9658;&#9658;bah.datetime was not built. See error information on latest attempt.
...

I've tried also with bmk makemods; same error....

Have you a solution ?
Note: I've compiled before boost.mod without error.

Thanks
Michel


xlsior(Posted 2013) [#11]
did you also copy ar.exe and ld.exe from MinGW to the blitzmax/bin folder?


Henri(Posted 2013) [#12]
From MinGW\bin directory you need to copy only ld.exe and ar.exe to Blitzmax\bin.
From MinGW\lib directory you need to copy only lib-files with a same name as in Blitzmax\lib folder (with the exception of unicows file which isn't part of MinGW distribution).
After this both Blitzmax and MinGW operate with same files to avoid mismatch problems (like errors seen above).

If you look inside Blitzmax\mod folder and it's subfolders you might see hidden folders named ".bmx" and files named like *.win32.x86.a/*.win32.x86.i . When you build modules, Blitzmax use's MinGW to compile and link all object/library files needed into these files. And when you try to run a program example, it references to these files (searching it's functions) and libraries that are in Blitzmax\lib folder, so you can see it creates a problem when something was compiled essentially from different set of bits and Blitzmax tries to put them together.

-Henri


Michel R.(Posted 2013) [#13]
@Henri and xlsior
Thank you to try to help me
Hope I've understood your explanations:

1/ I've (re)installed Blitzmax;
2/ I've copied only ld.exe and ar.exe from MinGW\bin to Blitzmax\bin
3/ I've copied only 25 lib files from MinGW\lib to Blitzmax\lib (there are 4 files in Blitzmax which don't exist in MinGW: crtbegin.a, crtend.a, libgcc.a and libunicows.a)
4/ in Blide Plus, I've tried "Build all modules" and... 96 modules compile well and 1 module gererates an error: bah.datetime (same error as before)
Well, now I've no more hair...


Henri(Posted 2013) [#14]
crtbegin.a, crtend.a and libgcc.a can be found in MinGW\lib\gcc\<something>\<version>\ -folder . These files are essential.


-Henri


Michel R.(Posted 2013) [#15]
@Henri
I've copied the 3 files from MinGW\lib\gcc\-686-pc-mingw32\4.8.0 to Blitzmax\lib.
I've tried to compile datetime and... always the same error... arghh!


Henri(Posted 2013) [#16]
In addition:

I don't know if it makes difference, but if it still fails, try to get new libunicows.a - file from this website <link>


-Henri


Michel R.(Posted 2013) [#17]
@Henri:
No difference :(


Michel R.(Posted 2013) [#18]
Well; if I can't compile THIS module, can someone send me the compiled files (or tell me if I can found them on the web) and tell me where I must copy them.
If I just copy them, will I have the documentation ?
Thanks

Michel


Henri(Posted 2013) [#19]
Next stop: Modules:

If you aqcuired them from Brucey's website they might be outdated. SVN-repository hold newest versions of all modules.

You need SVN-tool like Tortoise to be able to access the repository.

1. Install Tortoise
2.Goto Blitzmax\mod -folder
3. Press right mousekey and select Tortoise SVN/Repo-browser
4. Enter repository address: http://maxmods.googlecode.com/svn/trunk
5. Export all needed modules from here
6. Build all modules


-Henri


Henri(Posted 2013) [#20]
Just a note:

All Bruceys modules need to be located in Blitmax/mod/bah.mod/<modules>

-Henri


Michel R.(Posted 2013) [#21]
@Henri:

HURRAY !!!

I've installed TortoiseSVN and downloaded ALL the modules (160MBytes !!! because I don't know for now how to use this prog...) in a directory and transferred boost.mod and datetime.mod in bah folder.
After compilation, ther was a new error saying that the compiler couldn't find boostlocale. I've seen a module with this name in the ones I've downloaded and put it in bah; compilation and ...YES, the examples in datetime folder work fine !. I think that now I have to build all the modules. I have one or two more questions:

1/ well not really a question but... I thought that if I wanted the last vesion of a module (and particurlaly Brucey's module) I could find it on his website...

2/ Thank you for making me discover this site (maxmods.goo....trunk) and tortoiseSVN. but how can I know in which folder (bah, brl, maxgui, etc...) I can transfer the modules I've downloaded ?

Michel


Henri(Posted 2013) [#22]
Nice to hear :-)

1. No, all the latest updates go to SVN first (...and some modules you can find only here)

2. It depends. Folders that you see under mod/ are essentially namespaces and some are reserved (means don't put anything there) like pub.mod, brl.mod and maxgui.mod. Usually any third party modules reside in their own folder named after their author (like Bruceys mods are in bah.mod).
All modules that you find in repository address that I gave you are Bruceys modules.


-Henri


Michel R.(Posted 2013) [#23]
Thanks Henri !

..and Thanks also to Bruceys for all of his work for newbies like me...

160MBytes of source code... That leaves me dreamy..


xlsior(Posted 2013) [#24]
Anyway, I'd strongly recommend that you still recompile all your modules, including the stock ones, just to make sure that everything is compiled against the same libraries. Mixing & matching can be a bad idea.

Just run:

bmk makemods -a
bmk makemods -a -h

which will force-recompile all the modules on your system.


Brucey(Posted 2013) [#25]
Apologies. I've been meaning to update all the Boost related downloads to the latest versions (from SVN).

In the meantime, Boost was bumped to 1.53, so it all needs another update at some point… yay.