Thanks Boriss! Indeed the URL is correct and thanks for the login and password. However, I had to struggle quite a bit after that to checkout the code in my computer. This is due to proxy setup at my work. I am just noting the following for future users.
If you are behind proxy and using svn to check out files from an external URL, you need to change the following in "servers" file from ../Application Data/Subversion directory: [groups] group1 = *gforge.info.ucl.ac.be # external URL # othergroup = repository.blarggitywhoomph.com # thirdgroup = *.example.com ### Information for the first group: [group1] http-proxy-host = proxy2.abc.com # your company proxy http-proxy-port = 80 http-proxy-username = http-proxy-password = http-timeout = 60 http-auth-types = basic;digest;negotiate neon-debug-mask = 130 Now though I am struggling to compile the checked out code. It seems something wrong in configure file and I am having hard time in compiling! Thanks, Ashis -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Boriss Mejias Sent: Thursday, January 07, 2010 6:13 AM To: Mozart users Subject: Re: Mozart Next Release Maity, Ashis K wrote: > Hi Torsten, > > Thanks for your response! Looks like our email filtering sometimes blocks > some messages > from Mozart/Oz user-group as I did not get this message in my email and only > found > later while browsing the messages in the web. Yes, indeed I did play with > recomputation and > it did solve the memory issues partially (by using bigger recomputation > distance). > But our demand for tackling larger problems continued to grow and the Oz > engine is crashing as soon > as we feed larger problem. Run time is also an issue for these as well. That > is why we are thinking of > switching to Gecode. But before complete switch we would like to play with > Geoz. > > I am having trouble to get the Geoz code to play with. Can you help me where > I can download the latest > mozart-gecode? Is it from here > (https://gforge.info.ucl.ac.be/svn/mozart/branches/mozart-gecode)? Hi Ashis, That's the correct address. The svn repository is hosted at GForge/UCL. You have two choices here. Either you create a gforge user for you, or you use our generic mozart user, which is simpler: svn checkout --username mozart \ https://gforge.info.ucl.ac.be/svn/mozart/branches/mozart-gecode And the password is mozart too. cheers Boriss > It is asking for some authentication and I am providing my Mozart group > username/password and that is not working. > Please let me know if there is another location where I can download this > from. > > Thanks, > > Ashis > >> Sorry for the late reply, but have you tried recomputation? With >> recomputation you can trade memory consumption for run time. A few >> variants exist (e.g., fixed recomputation and adaptive recomputation). >> Gecode and Geoz support batch recomputation, which considerably >> improves the efficiency. > >> Best >> Torsten > > On 18.12.2009, at 14:47, Maity, Ashis K wrote: > >> Hi, >> >> Currently we have a scheduling application using Mozart/Oz, but we >> are running into trouble as our application is crashing in need of >> more memory. Hence, we are planning to move to Gecode. However, >> seeing the email below about having a Mozart interface to access >> Gecode, I was wondering would that solve our memory issue? Or would >> it still have that 32 bit memory limitation since it will be >> initiated through Mozart/Oz? However, improved recomputation using >> Gecode functionalities might help? Any comment on this is >> appreciated! Also, when are we expecting this release (of Mozart- >> Gecode interface)-- in days, weeks or months? There is a project >> website called GeOz (seems defunct now) -- is it the same thing? >> >> Thanks, >> >> Ashis > > -----Original Message----- > From: [email protected] [mailto:[email protected]] On > Behalf Of Torsten Anders > Sent: Tuesday, December 22, 2009 4:12 PM > To: Mozart users > Subject: Re: Mozart Next Release > > Dear Alejandro and Gustavo, > > Thank you very much for clearing up this matters. > > Best > Torsten > > > On 21.12.2009, at 06:50, Gustavo Gutierrez wrote: > >> >> 2009/12/19 Torsten Anders <[email protected]> >> Dear Gustavo, >> >> Thanks for your detailed reply. >> >> >> On 19.12.2009, at 03:47, Gustavo Gutierrez wrote: >> 2009/12/18 Maity, Ashis K <[email protected]> >> However, improved recomputation using Gecode functionalities might >> help? >> >> The current design of the integration only consider constraint >> propagation in gecode and search is done in mozart. This means that >> we don't inherit neither the existing search engines in gecode nor >> the search stop objects. Allowing the direct use of the serch >> engines is not straight forward but we have some ideas on how to >> handle it. >> >> Ah, that is good to know. I assume that one of the advantages of >> this design is that Geoz (i.e. Mozart with Gecode interface) >> distributor strategies (branching strategies) can employ arbitrary >> Mozart code. >> >> Nevertheless, does that also mean that Gecode features like batch >> recomputation are not available? If not, could that be reimplemented >> on the Mozart side? >> >> >> As Alejandro already pointed, the design of the integration handles >> batch recomputation. From a simplistic point of view we transformed >> the default eager propagation approach into a lazy one. Existing >> distributors will continue working but *won't* take advantage of >> batch recomputation. New distributors are implemented in such a way >> that will take advantage of it. >> >> The main idea behind doing the search from mozart is two fold: the >> user can easily implement new distributors and search engines. This >> is basically the reason of why we don't inherit existing search >> engines in gecode (i.e. LDS). For the distributor implementation >> there is something special: even in the current design (mozart >> 1.4.0) it is possible for the user to implement distributors in oz >> but there are implementation of the most common distribution >> strategies directly in C++ for performance reasons. The current >> state of the mozart-gecode branch provides the same distributors as >> gecode and you can implement your ones in oz. >> >> <ATT00001..txt> > > Best wishes, > Torsten > > -- > Torsten Anders > Interdisciplinary Centre for Computer Music Research > University of Plymouth > Office: +44-1752-586219 > Private: +44-1752-558917 > http://strasheela.sourceforge.net > http://www.torsten-anders.de > > > > > > _________________________________________________________________________________ > mozart-users mailing list > [email protected] > http://www.mozart-oz.org/mailman/listinfo/mozart-users > > ail (2.936) > X-Mailman-Version: 2.1.5 > X-MessageGate-spam: 101 > X-MessageGate-virus: 6 > X-Original-To: [email protected] > X-OriginalArrivalTime: 22 Dec 2009 21:11:36.0300 (UTC) > FILETIME=[586FFAC0:01CA834B] > X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 > ipscore=0 phishscore=0 > bulkscore=1 adultscore=0 classifier=spam adjust=0 reason=mlx > engine=6.0.2-0911030000 definitions=main-0912220193 > X-SA-Exim-Connect-IP: 134.96.254.200 > X-SA-Exim-Mail-From: [email protected] > X-SA-Exim-Scanned: Yes (on mail.ps.uni-saarland.de) > X-SA-Exim-Version: 4.2.1 (built Tue, 09 Jan 2007 17:23:22 +0000) > X-SGSI-From: [email protected] > X-SGSI-MailScanner: Found to be clean, Found to be clean > X-SGSI-MailScanner-ID: 4F344EC9FC.00000 > X-SGSI-Spam-Status: No, No > X-SGSI-SpamCheck: n'est pas un polluriel, SpamAssassin (not cached, > score=-1.599, requis 5, autolearn=not spam, BAYES_00 -1.60), n'est pas > un polluriel, SpamAssassin (not cached, score=0, > requis 5) > X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on james.ps.uni-sb.de > X-Spam-Level: > X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham > version=3.2.3 > X-Virus-Scanned: clamav-milter 0.95.2 at smtp-2.sipr-dc.ucl.ac.be > X-Virus-Status: Clean > > Dear Alejandro and Gustavo, > > Thank you very much for clearing up this matters. > > Best > Torsten > > > On 21.12.2009, at 06:50, Gustavo Gutierrez wrote: > >> >> 2009/12/19 Torsten Anders <[email protected]> >> Dear Gustavo, >> >> Thanks for your detailed reply. >> >> >> On 19.12.2009, at 03:47, Gustavo Gutierrez wrote: >> 2009/12/18 Maity, Ashis K <[email protected]> >> However, improved recomputation using Gecode functionalities might >> help? >> >> The current design of the integration only consider constraint >> propagation in gecode and search is done in mozart. This means that >> we don't inherit neither the existing search engines in gecode nor >> the search stop objects. Allowing the direct use of the serch >> engines is not straight forward but we have some ideas on how to >> handle it. >> >> Ah, that is good to know. I assume that one of the advantages of >> this design is that Geoz (i.e. Mozart with Gecode interface) >> distributor strategies (branching strategies) can employ arbitrary >> Mozart code. >> >> Nevertheless, does that also mean that Gecode features like batch >> recomputation are not available? If not, could that be reimplemented >> on the Mozart side? >> >> >> As Alejandro already pointed, the design of the integration handles >> batch recomputation. From a simplistic point of view we transformed >> the default eager propagation approach into a lazy one. Existing >> distributors will continue working but *won't* take advantage of >> batch recomputation. New distributors are implemented in such a way >> that will take advantage of it. >> >> The main idea behind doing the search from mozart is two fold: the >> user can easily implement new distributors and search engines. This >> is basically the reason of why we don't inherit existing search >> engines in gecode (i.e. LDS). For the distributor implementation >> there is something special: even in the current design (mozart >> 1.4.0) it is possible > _________________________________________________________________________________ > mozart-users mailing list > [email protected] > http://www.mozart-oz.org/mailman/listinfo/mozart-users > _________________________________________________________________________________ mozart-users mailing list [email protected] http://www.mozart-oz.org/mailman/listinfo/mozart-users _________________________________________________________________________________ mozart-users mailing list [email protected] http://www.mozart-oz.org/mailman/listinfo/mozart-users
