http://blog.gmane.org/gmane.comp.lang.fortress.general hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://comments.gmane.org/gmane.comp.lang.fortress.general/867 <pre>Hi All, I am surveying the features of Fortress with other HPCS languages as part of my research work. I got unclear with the idea of Regions as I thought it would be an abstraction to represent the place that the computation occur, but the Fortress language specification mentions a different idea than that. So I would appreciate if some clarification of this could be provided or some pointers to a good explanation. Thank you, Saliya _______________________________________________ language mailing list language-EFxYrSp25jGFLKEeoBv638bH8sH8CGPj&lt; at &gt;public.gmane.org http://projectfortress.sun.com/mailman/listinfo/language </pre> Saliya Ekanayake 2011-05-02T23:24:03 http://comments.gmane.org/gmane.comp.lang.fortress.general/865 <pre> Turns out, non-java.net-users can subscribe (or be subscribed) to java.net email lists, so I'll be automatically transferring according to the following mapping: announce -&gt; announce implementation -&gt; dev language -&gt; users I'll attempt to preserve digest settings, and not double-add anyone who was ambitious enough to move themselves. I hate it when I get autosubscribed to mailing lists, so if anyone is bent out of shape, I completely understand, but I hope this can be regarded as just a transfer. Contributing to the wiki will require some sort of registration, however. and again, the new home of Project Fortress is http://projectfortress.java.net . sources may be accessed read-only with the command hg --config 'web.cacerts=' clone https://www.java.net/hg/projectfortress~sources PF where PF is whatever you want to call the directory, locally. The --config 'web.cacerts=' option causes recent versions of Mercurial (which are very picky about certificates) to ignore the difference between hg.java.net and www.java.net yours, David Chase _______________________________________________ language mailing list language-EFxYrSp25jGFLKEeoBv638bH8sH8CGPj&lt; at &gt;public.gmane.org http://projectfortress.sun.com/mailman/listinfo/language </pre> David Chase 2011-03-16T19:50:20 http://comments.gmane.org/gmane.comp.lang.fortress.general/864 <pre> The machine hosting projectfortress.sun.com should go down at 5pm PDT on Wednesday, and may come back on line at 8am PDT on Friday (it's being moved to another building at the old Sun Menlo Park site; there is no plan for its long-term network connectivity). The source code and recent tickets have been moved, and mailing lists are available there for subscription. The Wiki still needs transferring, and we are working on a home for the blog. see our new home, at http://projectfortress.java.net David _______________________________________________ language mailing list language-EFxYrSp25jGFLKEeoBv638bH8sH8CGPj&lt; at &gt;public.gmane.org http://projectfortress.sun.com/mailman/listinfo/language </pre> David Chase 2011-03-15T19:19:19 http://comments.gmane.org/gmane.comp.lang.fortress.general/860 <pre>The new home is: http://projectfortress.java.net/ We're doing this for various reasons. The recent relocation of our facilities and IT equipment requires us to move and consolidate our servers. In the process, Oracle wants us to migrate as much as possible to standard platforms (such as java.net) that are approved and supported by our corporate IT. The fact that the building containing the server was recently sold to Facebook, made this a good time for the change. We are still populating the "project", but the mailing lists have been created and the source repository is in place. We intend for the old site to remain online, till it isn't, and the mailing lists remain active. Write access to the old repository has been disabled. If anyone has outstanding commits, contact me, I am sure I can fix it; the entire old Trac server has been archived in runnable form. NOTE: there's a glitch in the sidebar, probably my fault. If/when you hit missing links there from the Website page, try again from http://java.net/projects/projectfortress yours, David Chase the reluctant webmaster _______________________________________________ language mailing list language-EFxYrSp25jGFLKEeoBv638bH8sH8CGPj&lt; at &gt;public.gmane.org http://projectfortress.sun.com/mailman/listinfo/language </pre> David Chase 2011-03-12T02:12:39 http://comments.gmane.org/gmane.comp.lang.fortress.general/859 <pre>The server running all these things, along with several other servers, will be moved to another building in the near future, and the preparations for this may knock it off the web from time to time. yours, David Chase _______________________________________________ language mailing list language-EFxYrSp25jGFLKEeoBv638bH8sH8CGPj&lt; at &gt;public.gmane.org http://projectfortress.sun.com/mailman/listinfo/language </pre> David Chase 2011-03-08T21:51:53 http://comments.gmane.org/gmane.comp.lang.fortress.general/858 <pre>Apologies if this is the wrong fourm to discuss this. Hi, I watched the video from the strange loop conference that covered using algebraic properties to construct parallel algorithms, specifically using associativity to build a string splitting algorithm. During a coding dojo a couple of us teamed up to implement the algorithm in Scala as an exercise to explore Scala 2.9's parallel collections. The source code is up on github: https://github.com/mikeb01/jpr11-dojo/blob/master/src/steele/WordState.scala. We ran into some rather interesting results. We had 2 implementations of the algorithm, one that was sequential that used a fold right (the WordState.words method) on the collection of initial WordStates (either a Chunk containing a single character or an empty Segment) and a parallel one (the WordState.wordsParallel method) that uses Scala's wrapper around ParallelArray from the fork/join framework. The 'par' method converts an array into a ParallelArray. I also wrote a simple imperative Java implementation (BruteForce.words). Core 2 Duo laptop, 2 Cores &lt; at &gt; 2.40 GHz == Parallel - opsPerSecond: 6.891798759476223 Sequential - opsPerSecond: 49.813200498132005 Brute Force - opsPerSecond: 1388.888888888889 Intel Xeon Workstation, 8 Cores +HT (16 logical cores) &lt; at &gt; 2.40 GHz == Parallel - opsPerSecond: 120.48192771084338 Sequential - opsPerSecond: 73.26007326007326 Brute Force - opsPerSecond: 1886.7924528301887 I was initially quite surprised that I needed 16 cores to get the parallel implementation close to twice as fast as the sequential one. After some digging, the problem was obvious. My implementation of Segment.assoc(Segment) did not operate in constant time. Scala's default list implementation is immutable and the concatenation operator ':::' works using a copy, which will have O(n) with respect to the length of the list on the left hand side of the operator (the list that must copied). Where as the sequential version using a fold right would always be constant time as was associating a Chunk containing a single char or an empty Segment (on the left hand side) with a Segment (on the right). So the questions are, how does the list implementation in Fortress work? Is it immutable, therefore sharing the same complexity profile as the Scala implementation, unless the concatenation operator could produce a lazily evaluated structure? I.e. it returns a list of partial lists and flattens when evaluated. Is it mutable making the concatenation a simple constant time operation? How does the big (+) operation compare to Scala's 'par' method and use of fork/join ParallelArrays? Is it similar enough to work as a useful investigation of the algorithm? Regards, Michael Barker. _______________________________________________ language mailing list language-EFxYrSp25jGFLKEeoBv638bH8sH8CGPj&lt; at &gt;public.gmane.org http://projectfortress.sun.com/mailman/listinfo/language </pre> Michael Barker 2011-03-01T16:32:06 http://comments.gmane.org/gmane.comp.lang.fortress.general/857 <pre>Has anyone set up a web-based interface to fortify--a page where you can paste code and get back a LaTeX file? It would be useful when using a machine that doesn't have a local fortify install. I know there are web-based LaTeX servers that could go the rest of the way to a pdf or image. Thanks, Damon _______________________________________________ language mailing list language-EFxYrSp25jGFLKEeoBv638bH8sH8CGPj&lt; at &gt;public.gmane.org http://projectfortress.sun.com/mailman/listinfo/language </pre> Damon McCormick 2011-02-19T00:36:09 http://comments.gmane.org/gmane.comp.lang.fortress.general/855 <pre>Hello Fortress developers, I have written up a Fortress implementation of the World Magnetic Model for 2010-2015. (http://www.ngdc.noaa.gov/geomag/WMM). It calculates the field strength of the earth's magnetic field and is wildly used in navigation system. See attached file. This model was chosen because they provide a very nice numerical example which were used to check the results. Most of the formula was taken directly from the technical report, without looking at the C implementation. Only the PlmSchmidt_d1() function was extracted from C code. Fortify tool can process most the code. The urls in the comments seems to cause problems because it tries to create escape characters which later cause LaTeX to break. Anyway, thought you might like it. Feedback is welcome. Cheers Francois component geomag export Executable (* * This is an example of the World Magnetic Model for 2010-2015. * Reference: http://www.ngdc.noaa.gov/geomag/WMM/DoDWMM.shtml *) run() = do println "High-precision numerical example of the WMM2010 model ..." (* * Reference: * [1] "Section 1.5: MODEL EQUATIONS NUMERICAL EXAMPLE", * The US/UK World Magnetic Model for 2010-2015, Technical Report, * http://www.ngdc.noaa.gov/geomag/WMM/data/WMM2010/WMM2010_Report.pdf *) (* High-precision numerical example: * ||-------------------------------------------------|| * || Time || 2012.5000 0000 || yr || * || Height-above-Ellipsoid || 100.0000 0000 || km || * || Latitude || -80.0000 0000 || deg || * || Longitude || 240.0000 0000 || deg || * ||-------------------------------------------------|| *) date = 2012.5 (*) years lat = -80 (*) degrees lon = 240 (*) degrees alt = 100 (*) km geomagnetic(date,lat,lon,alt) (* * ||----------------------------------------------|| * || t || 2012.50000 00000 || yr || * || lambda || 4.18879 02048 || rad || * || phi || -1.39626 34016 || rad || * || h || 1 00000.00000 00000 || m || * || phi-prime || -1.39512 89589 || rad || * || r || 64 57402.34844 73705 || m || * || g(1,0,t) || -29467.60000 00000 || nT || * || g(1,1,t) || -1545.05000 00000 || nT || * || g(2,0,t) || -2426.85000 00000 || nT || * || g(2,1,t) || 3015.10000 00000 || nT || * || g(2,2,t) || 1673.35000 00000 || nT || * || h(1,0,t) || 0.00000 00000 || nT || * || h(1,1,t) || 4879.65000 00000 || nT || * || h(2,0,t) || 0.00000 00000 || nT || * || h(2,1,t) || -2763.95000 00000 || nT || * || h(2,2,t) || -605.60000 00000 || nT || * || Xprime || 5478.08914 74225 || nT || * || Yprime || 14765.37032 43050 || nT || * || Zprime || -50632.17770 56324 || nT || * || Xprime-dot || 20.58517 51801 || nT/yr || * || Yprime-dot || 1.02725 92716 || nT/yr || * || Zprime-dot || 83.50809 72670 || nT/yr || * || X || 5535.52491 48687 || nT || * || Y || 14765.37032 43050 || nT || * || Z || -50625.93054 78794 || nT || * || Xdot || 20.49042 68023 || nT/yr || * || Ydot || 1.02725 92716 || nT/yr || * || Zdot || 83.53139 62281 || nT/yr || * || F || 53024.92848 40226 || nT || * || H || 15768.89967 29956 || nT || * || D || 1.21211 40681 || rad || * || I || -1.26884 21543 || rad || * || Fdot || -77.32705 44552 || nT/yr || * || Hdot || 8.15485 76192 || nT/yr || * || Ddot || -0.00119 38570 || rad/yr || * || Idot || 0.00061 53148 || rad/yr || * ||----------------------------------------------|| *) println "Compare these values with the examples in the code comments." end geomagnetic(date:RR64, lat:RR64, lon:RR64, alt:RR64) = do (* * Reference: * [1] "Section 1.2: RELEVANT MODEL EQUATIONS", * The US/UK World Magnetic Model for 2010-2015, Technical Report, * http://www.ngdc.noaa.gov/geomag/WMM/data/WMM2010/WMM2010_Report.pdf *) (* input variables *) println (date,lat,lon,alt) (*) in years, degrees and kilometers (* (lat,lon,alt) is geodetic coordinates on WGS84 ellipsoid *) (* some useful constants *) pi = acos(-1.0) (* read the magnetic model coefficients from file *) (nmax,gnm,hnm,gnm_dot,hnm_dot,a,t0) = readMagneticModel() (* Set up functions that interpolate coefficients *) G_nm(n:ZZ32,m:ZZ32,t:RR64):RR64 requires { 0 &lt;= m &lt;= n &lt;= nmax } = do k = PlmIndex(n,m) gnm[k] + (t - t0) gnm_dot[k] end H_nm(n:ZZ32,m:ZZ32,t:RR64):RR64 requires { 0 &lt;= m &lt;= n &lt;= nmax } = do k = PlmIndex(n,m) hnm[k] + (t - t0) hnm_dot[k] end G_dot_nm(n:ZZ32,m:ZZ32,t:RR64):RR64 requires { 0 &lt;= m &lt;= n &lt;= nmax } = gnm_dot[PlmIndex(n,m)] H_dot_nm(n:ZZ32,m:ZZ32,t:RR64):RR64 requires { 0 &lt;= m &lt;= n &lt;= nmax } = hnm_dot[PlmIndex(n,m)] (* convert input variables to correct units *) (t, phi,lamda,h) = (date, lat pi/180, lon pi/180, alt 1000) (*) in years, radians, radians and meters (* (phi,lamda,h) is geodetic coordinates on WGS84 ellipsoid *) println "(t,lamda,phi,h) = "(t,lamda,phi,h) (* Step 1: convert to spherical geocentric coordinates *) (* semi-major axis (A) of the earth *) A = 6378137 (*) meters (* reciprocal flattening (1/f) of the earth *) f = 1/298.257223563 (* eccentricity squared (e^2) *) e2 = f(2-f) (* radius of East-West curvature (R_c) *) R_c = A/(SQRT(1 - e2 (sin phi)^2)) p = (R_c + h) cos phi z = (R_c(1 - e2) + h) sin phi r = SQRT(p^2 + z^2) phi_prime = asin(z/r) (* geodetic coordinates: (lamda, phi, h) = (longitude, latitude, altitude) *) (* spherical geocentric coordinates: (lamda, phi_prime, r) *) println "(lamda,phi-prime,r) = "(lamda,phi_prime,r) (* show some coefficients for comparison with example values *) println "Gnm: "(G_nm(1,0,t), G_nm(1,1,t), G_nm(2,0,t), G_nm(2,1,t), G_nm(2,2,t)) println "Hnm: "(H_nm(1,0,t), H_nm(1,1,t), H_nm(2,0,t), H_nm(2,1,t), H_nm(2,2,t)) (* Step 2: Calculate the Schmidt normalized associated Legendre values *) (pp,qq) = PlmSchmidt_d1(nmax, sin phi_prime) P_breve_nm(n:ZZ32,m:ZZ32,mu:RR64) requires { 0 &lt;= m &lt;= n &lt;= nmax, |mu| &lt;= 1.0 } = pp[PlmIndex(n,m)] dP_breve_nm(n:ZZ32,m:ZZ32,mu:RR64) requires { 0 &lt;= m &lt;= n &lt;= nmax, |mu| &lt;= 1.0 } = qq[PlmIndex(n,m)] (* Step 3: Compute the field vector components (equations 10,11,12) *) N = nmax X_prime = -(SUM[n&lt;-1:N]( (a/r)^(n+2) (SUM[m&lt;-0:n]( (G_nm(n,m,t) cos(m lamda) + H_nm(n,m,t) sin(m lamda)) dP_breve_nm(n,m,sin phi_prime) )))) Y_prime = (1/cos(phi_prime)) (SUM[n&lt;-1:N]( (a/r)^(n+2) (SUM[m&lt;-0:n](m((G_nm(n,m,t) sin(m lamda)) - (H_nm(n,m,t) cos(m lamda))) P_breve_nm(n,m,sin phi_prime) )))) Z_prime = -(SUM[n&lt;-1:N]( (n+1) (a/r)^(n+2) (SUM[m&lt;-0:n]( (G_nm(n,m,t) cos(m lamda) + H_nm(n,m,t) sin(m lamda)) P_breve_nm(n,m,sin phi_prime) )))) println "(Xprime,Yprime,Zprime) = "(X_prime, Y_prime, Z_prime) (* Compute the secular variation of the field components (equastions 13,14,15) *) X_dot_prime = -(SUM[n&lt;-1:N]( (a/r)^(n+2) (SUM[m&lt;-0:n]( (G_dot_nm(n,m,t) cos(m lamda) + H_dot_nm(n,m,t) sin(m lamda)) dP_breve_nm(n,m,sin phi_prime) )))) Y_dot_prime = 1/cos(phi_prime) (SUM[n&lt;-1:N]( (a/r)^(n+2) (SUM[m&lt;-0:n]( m (G_dot_nm(n,m,t) sin(m lamda) - H_dot_nm(n,m,t) cos(m lamda)) P_breve_nm(n,m,sin phi_prime) )))) Z_dot_prime = -(SUM[n&lt;-1:N]( (n+1) (a/r)^(n+2) (SUM[m&lt;-0:n]( (G_dot_nm(n,m,t) cos(m lamda) + H_dot_nm(n,m,t) sin(m lamda)) P_breve_nm(n,m,sin phi_prime) )))) println "(Xprime-dot,Yprime-dot,Zprime-dot) = "(X_dot_prime, Y_dot_prime, Z_dot_prime) (* Step 4: rotate geocentric magnetic field vector components into ellipsoidal reference frame *) X = X_prime cos(phi_prime - phi) - Z_prime sin(phi_prime - phi) (*) nT Y = Y_prime (*) nT Z = X_prime sin(phi_prime - phi) + Z_prime cos(phi_prime - phi) (*) nT println "(X,Y,Z) = "(X,Y,Z) X_dot = X_dot_prime cos(phi_prime - phi) - Z_dot_prime sin(phi_prime - phi) (*) nT per year Y_dot = Y_dot_prime (*) nT per year Z_dot = X_dot_prime sin(phi_prime - phi) + Z_dot_prime cos(phi_prime - phi) (*) nT per year println "(Xdot,Ydot,Zdot) = "(X_dot,Y_dot,Z_dot) (* Step 5: Compute magnetic elements H,F,I and D from orthogonal componants *) F = SQRT(X^2 + Y^2 + Z^2) (*) nT H = SQRT(X^2 + Y^2) (*) nT I = atan2(Z,H) (*) radians D = atan2(Y,X) (*) radians println "(F,H,D,I) = "(F,H,D,I) F_dot = (X DOT X_dot + Y DOT Y_dot + Z DOT Z_dot)/F (*) nT per year H_dot = (X DOT X_dot + Y DOT Y_dot)/H (*) nT per year I_dot = (H DOT Z_dot - Z DOT H_dot)/(F^2) (*) radians per year D_dot = (X DOT Y_dot - Y DOT X_dot)/(H^2) (*) radians per year println "(Fdot,Hdot,Ddot,Idot) = " (F_dot,H_dot,D_dot,I_dot) (X,Y,Z, H,I,D, F) end readMagneticModel(): (ZZ32,Array[\RR64,ZZ32\],Array[\RR64,ZZ32\],Array[\RR64,ZZ32\],Array[\RR64,ZZ32\],RR64) = do (* * Reference: * [1] "Section 1.3: THE WMM2010 COEFFICIENTS", * The US/UK World Magnetic Model for 2010-2015, Technical Report, * http://www.ngdc.noaa.gov/geomag/WMM/data/WMM2010/WMM2010_Report.pdf *) (*) Coefficients as read from WMM.COF file (* n m g h g_dot h_dot *) wmm2010data: RR64[90,6] = [ 1 0 -29496.6 0.0 11.6 0.0 1 1 -1586.3 4944.4 16.5 -25.9 2 0 -2396.6 0.0 -12.1 0.0 2 1 3026.1 -2707.7 -4.4 -22.5 2 2 1668.6 -576.1 1.9 -11.8 3 0 1340.1 0.0 0.4 0.0 3 1 -2326.2 -160.2 -4.1 7.3 3 2 1231.9 251.9 -2.9 -3.9 3 3 634.0 -536.6 -7.7 -2.6 4 0 912.6 0.0 -1.8 0.0 4 1 808.9 286.4 2.3 1.1 4 2 166.7 -211.2 -8.7 2.7 4 3 -357.1 164.3 4.6 3.9 4 4 89.4 -309.1 -2.1 -0.8 5 0 -230.9 0.0 -1.0 0.0 5 1 357.2 44.6 0.6 0.4 5 2 200.3 188.9 -1.8 1.8 5 3 -141.1 -118.2 -1.0 1.2 5 4 -163.0 0.0 0.9 4.0 5 5 -7.8 100.9 1.0 -0.6 6 0 72.8 0.0 -0.2 0.0 6 1 68.6 -20.8 -0.2 -0.2 6 2 76.0 44.1 -0.1 -2.1 6 3 -141.4 61.5 2.0 -0.4 6 4 -22.8 -66.3 -1.7 -0.6 6 5 13.2 3.1 -0.3 0.5 6 6 -77.9 55.0 1.7 0.9 7 0 80.5 0.0 0.1 0.0 7 1 -75.1 -57.9 -0.1 0.7 7 2 -4.7 -21.1 -0.6 0.3 7 3 45.3 6.5 1.3 -0.1 7 4 13.9 24.9 0.4 -0.1 7 5 10.4 7.0 0.3 -0.8 7 6 1.7 -27.7 -0.7 -0.3 7 7 4.9 -3.3 0.6 0.3 8 0 24.4 0.0 -0.1 0.0 8 1 8.1 11.0 0.1 -0.1 8 2 -14.5 -20.0 -0.6 0.2 8 3 -5.6 11.9 0.2 0.4 8 4 -19.3 -17.4 -0.2 0.4 8 5 11.5 16.7 0.3 0.1 8 6 10.9 7.0 0.3 -0.1 8 7 -14.1 -10.8 -0.6 0.4 8 8 -3.7 1.7 0.2 0.3 9 0 5.4 0.0 0.0 0.0 9 1 9.4 -20.5 -0.1 0.0 9 2 3.4 11.5 0.0 -0.2 9 3 -5.2 12.8 0.3 0.0 9 4 3.1 -7.2 -0.4 -0.1 9 5 -12.4 -7.4 -0.3 0.1 9 6 -0.7 8.0 0.1 0.0 9 7 8.4 2.1 -0.1 -0.2 9 8 -8.5 -6.1 -0.4 0.3 9 9 -10.1 7.0 -0.2 0.2 10 0 -2.0 0.0 0.0 0.0 10 1 -6.3 2.8 0.0 0.1 10 2 0.9 -0.1 -0.1 -0.1 10 3 -1.1 4.7 0.2 0.0 10 4 -0.2 4.4 0.0 -0.1 10 5 2.5 -7.2 -0.1 -0.1 10 6 -0.3 -1.0 -0.2 0.0 10 7 2.2 -3.9 0.0 -0.1 10 8 3.1 -2.0 -0.1 -0.2 10 9 -1.0 -2.0 -0.2 0.0 10 10 -2.8 -8.3 -0.2 -0.1 11 0 3.0 0.0 0.0 0.0 11 1 -1.5 0.2 0.0 0.0 11 2 -2.1 1.7 0.0 0.1 11 3 1.7 -0.6 0.1 0.0 11 4 -0.5 -1.8 0.0 0.1 11 5 0.5 0.9 0.0 0.0 11 6 -0.8 -0.4 0.0 0.1 11 7 0.4 -2.5 0.0 0.0 11 8 1.8 -1.3 0.0 -0.1 11 9 0.1 -2.1 0.0 -0.1 11 10 0.7 -1.9 -0.1 0.0 11 11 3.8 -1.8 0.0 -0.1 12 0 -2.2 0.0 0.0 0.0 12 1 -0.2 -0.9 0.0 0.0 12 2 0.3 0.3 0.1 0.0 12 3 1.0 2.1 0.1 0.0 12 4 -0.6 -2.5 -0.1 0.0 12 5 0.9 0.5 0.0 0.0 12 6 -0.1 0.6 0.0 0.1 12 7 0.5 0.0 0.0 0.0 12 8 -0.4 0.1 0.0 0.0 12 9 -0.4 0.3 0.0 0.0 12 10 0.2 -0.9 0.0 0.0 12 11 -0.8 -0.2 -0.1 0.0 12 12 0.0 0.9 0.1 0.0 ] (* Note: H and H_dot is undefined for m = 0 *) nmax = 12 sdim = PlmIndex(nmax+1,0) G = array[\RR64\](sdim) H = array[\RR64\](sdim) G_dot = array[\RR64\](sdim) H_dot = array[\RR64\](sdim) (* Not used, but there to fill our packed triangle matrix *) G[0] := 0.0 G[0] := 0.0 G_dot[0] := 0.0 H_dot[0] := 0.0 (* populate our packed triangle matrix *) for row &lt;- 0#90 do k = PlmIndex( wmm2010data[row,0], wmm2010data[row,1] ) G[k] := wmm2010data[row,2] H[k] := wmm2010data[row,3] G_dot[k] := wmm2010data[row,4] H_dot[k] := wmm2010data[row,5] end (* geomagnetic reference radius of the model *) a = 6371200 (*) meters (* base date of the model *) t0 = 2010.0 (*) years (nmax, G, H, G_dot, H_dot, a, t0) end PlmIndex(l: ZZ32, m: ZZ32): ZZ32 requires { 0 &lt;= m &lt;= l } = l(l+1)/2 + m PlmSchmidt_d1(l_max: ZZ32, z: RR64): (Array[\RR64,ZZ32\], Array[\RR64,ZZ32\]) requires { 0 &lt;= l_max &lt;= 16, |z| &lt;= 1 } = do p_size: ZZ32 = PlmIndex(l_max+1, 0) var p: Array[\RR64,ZZ32\] var dp: Array[\RR64,ZZ32\] var schmidtQuasiNorm: Array[\RR64,ZZ32\] do mu = SQRT((1.0-z)(1.0+z)) (* Compute the Gauss-normalized associated Legendre functions *) p := array[\RR64\](p_size) dp := array[\RR64\](p_size) p[0] := 1.0 dp[0] := 0.0 for n &lt;- seq(1:l_max), m &lt;- seq(0:n) do index = PlmIndex(n,m) if n = m then index1 = PlmIndex(n-1,m-1) p[index] := mu p[index1] dp[index] := mu dp[index1] + z p[index1] elif n = 1 AND m = 0 then index1 = PlmIndex(n-1,m) p[index] := z p[index1] dp[index] := z dp[index1] - mu p[index1] elif n &gt; 1 AND n =/= m then index2 = PlmIndex(n-1,m) if m &gt; (n-2) then p[index] := z p[index2] dp[index] := z dp[index2] - mu p[index2] else index1 = PlmIndex(n-2,m) k = ((n-1)^2 - m^2) / ((2 n - 1)(2 n - 3)) p[index] := z p[index2] - k p[index1] dp[index] := z dp[index2] - mu p[index2] - k dp[index1] end else fail "should never happen" end end also do schmidtQuasiNorm := array[\RR64\](p_size) (* * Compute the ration between the Gauss-normalized associated Legendre * functions and the Schmidt quasi-normalized version. This is equivalent * to SQRT((m==0?1:2)*(n-m)!/(n+m!))*(2n-1)!!/(n-m)! *) schmidtQuasiNorm[0] := 1.0 for n &lt;- seq(1:l_max), m &lt;- seq(0:n) do schmidtQuasiNorm[PlmIndex(n,m)] := if m = 0 then schmidtQuasiNorm[PlmIndex(n-1,0)] (2 n - 1) / n else schmidtQuasiNorm[PlmIndex(n,m-1)] (SQRT(((n - m + 1)(if m = 1 then 2 else 1 end)) / (n + m))) end end end (* * Converts the Gauss-normalized associated Legendre * functions to the Schmidt quasi-normalized version using pre-computed * relation stored in the variable schmidtQuasiNorm *) for n &lt;- 1:l_max, m &lt;- 0:n do index = PlmIndex(n,m) p[index] := schmidtQuasiNorm[index] p[index] dp[index] := - schmidtQuasiNorm[index] dp[index] (* The sign is changed since the new WMM routines * use derivative with respect to latitude instead * of co-latitude *) end (p,dp) end end (* component geomag *) _______________________________________________ language mailing list language-EFxYrSp25jGFLKEeoBv638bH8sH8CGPj&lt; at &gt;public.gmane.org http://projectfortress.sun.com/mailman/listinfo/language </pre> Francois Retief 2011-02-13T12:50:11 http://comments.gmane.org/gmane.comp.lang.fortress.general/845 <pre>There are some issues with defining nat parameters in variant types when the variants have different functions. I propose a (nontrivial) language change that would solve the problem. Take a look: Last week Eric and Victor introduced me to nat parameters, and as an exercise we implemented a cons list with a nat parameter for the length. At first glance this looked ok: 1: trait List[[T, nat n]] 2: zip[[S]](other: List[[S,n]]) :List[[(T,S), n]] 3: end 4: object Empty[[T]] extends List[[T,0]] 5: zip[[S]](other: List[[S,0]]) :List[[(T,S), n]] 6: = Empty[[(T,S)]] 7: end 8: object Cons[[T, nat n &gt; 0]](fst:T, rst:List[[T, n-1]]) extends List[[T, n]] 9: zip[[S]](other: List[[S,n]]) :List[[(T,S), n]] 10: = Cons[[(T,S), n]]((fst, other.fst), zip(rst, other.rst)) 11: end But this fails static checks at line 10 because it is not guaranteed that other:List[[S,n]] will have fst defined. Usually if we don't care to know statically that the argument to zip has the right constructor, we have a couple ways around this: - check dynamically with a typecase - cast other to type Cons[[S, n]] at line 10 We know that these won't actually ever result in dynamic errors, seeing that any object that passed the typecheck as List[[S, n]] when n&gt;0 can only have ilk Cons[[S, n]]. But the typechecker doesn't know this, so it kind of defeats the whole purpose of using nat parameters. We want to somehow share this knowledge with the typechecker, say with a comprises clause: trait List[[T, nat n]] comprises { Empty[[T]] where n=0, Cons[[T, n]] where n!=0} But, what we really want to say is that Cons[[S, n]] &lt;: List[[S, n]] and List &lt;: Cons[[S, n]]. Wouldn't it be nice to just cut out Cons and Empty then? It would be nice to write: object List[[T, nat n = 0]] zip[[S]] (other:List[[T, n]]) = ... object List[[T, nat n &gt; 0]] (fst: T, rst:List[[T, n-1]]) zip[[S]] (other: List[[T, n]]) = ... (This could work kind of like case expressions do, catching the first definition that matches, error if no matching case) We would probably need to be able to define the most general requirements of a list type like: ___ List[[T, nat n &gt;= 0]] zip[[S]] (other: List[[T, n]]) This is practically an interface. The difference is that we can select implementing objects depending on nat parameters, and resolve this statically. There is no issue with non-variant types like vectors, matrices, the supposed target of nat parameters. But something to consider. _______________________________________________ language mailing list language-EFxYrSp25jGFLKEeoBv638bH8sH8CGPj&lt; at &gt;public.gmane.org http://projectfortress.sun.com/mailman/listinfo/language </pre> Diane Lee 2011-01-31T23:07:22 http://comments.gmane.org/gmane.comp.lang.fortress.general/843 <pre>I'm getting a syntax error when I try to bind to an identifier in the else clause as such: ... typecase eval(t2, env) of v2:Value ⇒ eval(v1.abs.body, Env(v1.abs.x, v2, v1.env)) stuck:else ⇒ TmApp(v1, stuck) end ... I would argue in favor of supporting such syntax. Otherwise, the user is forced to work around this by binding outside the typecase. The only way I can get my code to compile: ... e2=eval(t2,env) ... typecase e2 of v2:Value ⇒ eval(v1.abs.body, Env(v1.abs.x, v2, v1.env)) else ⇒ TmApp(v1, e2) end ... Notice that other than introducing intermediate variables, in my case I also lost the opportunity to give my expression a meaningful name for the else case This wasn't an issue with the old typecase syntax (as in spec 1.0) when binding was done before "of"; it looks like support for binding in the else case got lost in the move. Cheers, Diane _______________________________________________ language mailing list language-EFxYrSp25jGFLKEeoBv638bH8sH8CGPj&lt; at &gt;public.gmane.org http://projectfortress.sun.com/mailman/listinfo/language </pre> Diane Lee 2011-01-19T06:57:14 http://comments.gmane.org/gmane.comp.lang.fortress.general/834 <pre>Hello everyone, I have been working on some code that I am trying to make as parallel as possible. It creates a triangular matrix. The each diagonal element is dependent on the previous column's diagonal value and each value in a column is only dependent on the value above it in the column. So the algorithm can be made parallel by splitting each column into a separate work unit. My result can be summarised in the pseudo Fortress code below. My problem is that I am assuming that recursing inside a "also do" block yields a tail call? Is this correct? If not, how efficient would this be at depths of up to 2700? PlmSchmidt(lmax: ZZ32, z: RR64): Array[\RR64,ZZ32\] requires { 0 &lt; lmax &lt;= 2700, |z| &lt;= 1.0 } = do (* pre-calculations here *) P: Array[\RR64,ZZ32\] := ... CalculateAndFillArray(a_in: RR64, m: ZZ32):() = do a = a_in + ... (* make use of previous column's value *) (* initial work on first element of column *) do (* more work on other elements of column *) also do if (m+1) &lt; lmax then (* recurse to next column *) CalculateAndFillArray(a, m+1) (* &lt;-- Is this a tail call? *) else (* work on last column *) end end end CalculateAndFillArray(1.0, 0) (* post-calculations here *) P end Cheers Francois _______________________________________________ language mailing list language-EFxYrSp25jGFLKEeoBv638bH8sH8CGPj&lt; at &gt;public.gmane.org http://projectfortress.sun.com/mailman/listinfo/language </pre> Francois Retief 2011-01-13T19:51:46 http://comments.gmane.org/gmane.comp.lang.fortress.general/831 <pre>Hello, How do one write this function so that it returns a Vector instead of Array? PlmSchmidt(l_max: ZZ32, z: RR64): Array[\RR64, ZZ32\] requires { l_max &gt;= 0 AND |z| &lt;= 1.0 } = do p_size = (l_max + 1)(l_max + 2)/2 p = array[\RR64\](p_size) (* do calculations using z and store in p *) p end The usage here is that the value l_max is read from a file and passed to this function. Thus the size is not known at compile-time. run() = do l_max: ZZ32 z: RR64 .. (* read l_max and z from file *) v = PlmSchmidt(l_max, z) .. end My understanding of Vector (and of the nat static parameter) is that the example above is not possible. Except where the size of the vector is known at compile time as a literal constant. Or is this just an limitation of the current Fortress interpreter? Cheers Francois _______________________________________________ language mailing list language-EFxYrSp25jGFLKEeoBv638bH8sH8CGPj&lt; at &gt;public.gmane.org http://projectfortress.sun.com/mailman/listinfo/language </pre> Francois Retief 2011-01-09T16:10:30 http://comments.gmane.org/gmane.comp.lang.fortress.general/830 <pre>hi all, I have proposed to replace "import" by a symbol in Python language and got mostly negative responses, yet I would consider it for Fortress language. E.g. instead of import myFunc1 from myModule1 ... r = myFunc1(...) one could use mere r = &lt; at &gt;myModule1.myFunc1(...) (or any other symbol) See the post for more details http://groups.google.com/group/comp.lang.python/browse_thread/thread/20b932b2e1e38748# Regards, Dmitrey. _______________________________________________ language mailing list language-EFxYrSp25jGFLKEeoBv638bH8sH8CGPj&lt; at &gt;public.gmane.org http://projectfortress.sun.com/mailman/listinfo/language </pre> Dmitrey 2011-01-07T09:26:47 http://comments.gmane.org/gmane.comp.lang.fortress.general/828 <pre>Hello! I am curious about the interoperability between Fortress and Java. From what I could gather by browsing the source, calling Java methods from Fortress requires 1) that the methods are static and 2) that they are members of a class derived from a suitable "glue" class. This means that to use a Java library from Fortress, bindings would have to be written specifically. There is a blog post from last May, saying that the situation should improve in the future. Maybe a tool would be written to automatically generate wrapper classes. How far along are these plans? I would be interested to start playing with Fortress if there is some means to use existing libraries. (Note that being able to call Java methods would be helpful already. No need to extend classes right from the start.) So I would like to know if this is a feature that is going to be added in the forseeable future? Or is this still a long way off? Thanks! Felix PS: The FAQ has a similar question that still awaits an answer. </pre> Felix Breuer 2010-12-22T09:28:41 http://comments.gmane.org/gmane.comp.lang.fortress.general/816 <pre>_______________________________________________ language mailing list language-EFxYrSp25jGFLKEeoBv638bH8sH8CGPj&lt; at &gt;public.gmane.org http://projectfortress.sun.com/mailman/listinfo/language </pre> Tom 2010-09-23T13:43:38 http://comments.gmane.org/gmane.comp.lang.fortress.general/814 <pre>We are currently tackling implementation of non-type static parameters in the compiler. This brings to light some issues we've had with static parameters for awhile. In particular, it would be nice if there were some way for the programmer to explicitly specify the instantiations of some static parameters at a function call without specifying all of them. And it might be nice if there were some way to require programmers to explicitly provide the instantiations of some static parameters. (For example, we might want to include static parameters that cannot be inferred from the arguments or function call context.) Proposal 1: Allow instantiations of static parameters to be provided using keyword notation. For example, given the function declaration: f[\nat m, bool b\](x: RR[m BY m]): T[\b\] a programmer could call f as follows: I = [1 0 0 0 1 0 0 0 1] f[\b = true\](I) Restriction: If the instantiation of one or more static parameters is provided explicitly using keyword notation, then all explicitly provided instantiations must use keyword notation. Note that there need not be instantiations for all static parameters, as the above example shows. Proposal 2: Allow programmers to require explicit instantiation of a static parameter using the modifier "explicit" (or some other sensible modifier we've already reserved). For example, a programmer might write the declaration: g[\nat m, explicit bool b\](x: RR[m BY m]): Object In that case, every call to f must explicitly provide an instantiation for b, either using the usual syntax for static parameter instantiation, or by using keyword notation. Proposal 3: If a function declaration includes a static parameter that cannot be inferred (in all cases) from either the arguments or the calling context at a call site, the program is statically rejected. For example, given the following function declaration, it is impossible to infer an instantiation of b at a call site: h[\nat m, bool b\](x: RR[m BY m]): Object (*) NOT ALLOWED The program containing this declaration would be statically rejected under this proposal. Comments? Thanks, </pre> Eric Allen 2010-09-21T18:37:46 http://comments.gmane.org/gmane.comp.lang.fortress.general/810 <pre>So I thought I'd try something simple: run_test.fss: component run_test import String.{...} export Executable import conjGrad.{...} run() = do var b: Matrix[\RR64,3,3\] := [ 1 2 3 2 4 5 3 5 6] (* testerf[\3,Matrix[\RR64,3,3\]\]() *) var c:Vector[\RR64, 3\] bb = b b print bb (a,d) = conjGrad(bb,c) print a " " d end end And then copied a part of the conjGrad demo into conjGrad.fss: component conjGrad export conjGrad (* conjGrad returns the approximate solution z to the linear equation: * A z = x * along with the approximate cartesian error of the solution. This * method is considered superior to LU decomposition when A is * sparse, symmetric, and positive-definite. *) conjGrad[\Elt extends Number, nat N, Vec extends Vector[\Elt,N\], Mat extends Matrix[\Elt,N,N\]\](A: Mat, x: Vec): (Vec, RR64) = do cgit_max = 25 z: Vec := x.replica[\Elt\]().fill(0) r: Vec := x p: Vec := r rho: Elt := r DOT r for j &lt;- seq(1#cgit_max) do q = A p alpha = rho / (p DOT q) z += alpha p rho0 = rho r -= alpha q rho := r DOT r beta = rho / rho0 p := r + beta p println("Iter " j " alpha = " alpha // "z" z) end (z, ||x - A z||) end (************************************************************) end with the api conjGrad.fsi: api conjGrad conjGrad[\Elt extends Number, nat N, Vec extends Vector[\Elt,N\], Mat extends Matrix[\Elt,N,N\]\] (A: Mat, x: Vec): (Vec, RR64) end But then I run fortress run_test.fss and the following output ensues: [ 14 25 31 25 45 56 31 56 70 ]Exception in thread "main" java.lang.NullPointerException at com.sun.fortress.interpreter.env.ReferenceCell.getValueNull(ReferenceCell.java:202) at com.sun.fortress.interpreter.evaluator.BaseEnv.getValueNullTail(BaseEnv.java:556) at com.sun.fortress.interpreter.evaluator.BaseEnv.getValueNullTail(BaseEnv.java:547) at com.sun.fortress.interpreter.evaluator.BaseEnv.getValueNull(BaseEnv.java:506) at com.sun.fortress.interpreter.evaluator.BaseEnv.getValueNull(BaseEnv.java:493) at com.sun.fortress.interpreter.evaluator.Evaluator.forVarRef(Evaluator.java:1499) at com.sun.fortress.interpreter.evaluator.Evaluator.forVarRef(Evaluator.java:50) at com.sun.fortress.nodes.VarRef.accept(VarRef.java:58) at com.sun.fortress.interpreter.evaluator.tasks.TupleTask.compute(TupleTask.java:44) at jsr166y.RecursiveAction.exec(RecursiveAction.java:146) at jsr166y.ForkJoinTask.tryQuietlyInvoke(ForkJoinTask.java:477) at jsr166y.ForkJoinTask.quietlyInvoke(ForkJoinTask.java:899) at jsr166y.ForkJoinTask.invokeAll(ForkJoinTask.java:681) at com.sun.fortress.interpreter.evaluator.Evaluator.evalExprListParallel(Evaluator.java:357) at com.sun.fortress.interpreter.evaluator.Evaluator.forTupleExpr(Evaluator.java:1452) at com.sun.fortress.interpreter.evaluator.Evaluator.forTupleExpr(Evaluator.java:50) at com.sun.fortress.nodes.TupleExpr.accept(TupleExpr.java:64) at com.sun.fortress.interpreter.evaluator.Evaluator.evalExprList(Evaluator.java:317) at com.sun.fortress.interpreter.evaluator.Evaluator.evalExprListParallel(Evaluator.java:348) at com.sun.fortress.interpreter.evaluator.Evaluator.evalInvocationArgs(Evaluator.java:1362) at com.sun.fortress.interpreter.evaluator.Evaluator.finishFunctionInvocation(Evaluator.java:1352) at com.sun.fortress.interpreter.evaluator.Evaluator.forTightJuxt(Evaluator.java:1309) at com.sun.fortress.interpreter.evaluator.Evaluator.forJuxt(Evaluator.java:761) at com.sun.fortress.interpreter.evaluator.Evaluator.forJuxt(Evaluator.java:50) at com.sun.fortress.nodes.Juxt.accept(Juxt.java:67) at com.sun.fortress.interpreter.evaluator.BuildLetEnvironments.forLocalVarDecl(BuildLetEnvironments.java:92) at com.sun.fortress.interpreter.evaluator.BuildLetEnvironments.forLocalVarDecl(BuildLetEnvironments.java:37) at com.sun.fortress.nodes.LocalVarDecl.accept(LocalVarDecl.java:55) at com.sun.fortress.interpreter.evaluator.BuildLetEnvironments.doLets(BuildLetEnvironments.java:133) at com.sun.fortress.interpreter.evaluator.Evaluator.evalExprList(Evaluator.java:334) at com.sun.fortress.interpreter.evaluator.Evaluator.forBlock(Evaluator.java:291) at com.sun.fortress.interpreter.evaluator.Evaluator.forBlock(Evaluator.java:50) at com.sun.fortress.nodes.Block.accept(Block.java:61) at com.sun.fortress.interpreter.evaluator.Evaluator.eval(Evaluator.java:54) at com.sun.fortress.interpreter.evaluator.BuildLetEnvironments.forLocalVarDecl(BuildLetEnvironments.java:129) at com.sun.fortress.interpreter.evaluator.BuildLetEnvironments.forLocalVarDecl(BuildLetEnvironments.java:37) at com.sun.fortress.nodes.LocalVarDecl.accept(LocalVarDecl.java:55) at com.sun.fortress.interpreter.evaluator.BuildLetEnvironments.doLets(BuildLetEnvironments.java:133) at com.sun.fortress.interpreter.evaluator.Evaluator.evalExprList(Evaluator.java:334) at com.sun.fortress.interpreter.evaluator.Evaluator.forBlock(Evaluator.java:291) at com.sun.fortress.interpreter.evaluator.Evaluator.forBlock(Evaluator.java:50) at com.sun.fortress.nodes.Block.accept(Block.java:61) at com.sun.fortress.interpreter.evaluator.Evaluator.eval(Evaluator.java:54) at com.sun.fortress.interpreter.evaluator.BuildLetEnvironments.forLocalVarDecl(BuildLetEnvironments.java:129) at com.sun.fortress.interpreter.evaluator.BuildLetEnvironments.forLocalVarDecl(BuildLetEnvironments.java:37) at com.sun.fortress.nodes.LocalVarDecl.accept(LocalVarDecl.java:55) at com.sun.fortress.interpreter.evaluator.BuildLetEnvironments.doLets(BuildLetEnvironments.java:133) at com.sun.fortress.interpreter.evaluator.Evaluator.evalExprList(Evaluator.java:334) at com.sun.fortress.interpreter.evaluator.Evaluator.forBlock(Evaluator.java:291) at com.sun.fortress.interpreter.evaluator.Evaluator.forBlock(Evaluator.java:50) at com.sun.fortress.nodes.Block.accept(Block.java:61) at com.sun.fortress.interpreter.evaluator.Evaluator.eval(Evaluator.java:54) at com.sun.fortress.interpreter.evaluator.BuildLetEnvironments.forLocalVarDecl(BuildLetEnvironments.java:129) at com.sun.fortress.interpreter.evaluator.BuildLetEnvironments.forLocalVarDecl(BuildLetEnvironments.java:37) at com.sun.fortress.nodes.LocalVarDecl.accept(LocalVarDecl.java:55) at com.sun.fortress.interpreter.evaluator.BuildLetEnvironments.doLets(BuildLetEnvironments.java:133) at com.sun.fortress.interpreter.evaluator.Evaluator.evalExprList(Evaluator.java:334) at com.sun.fortress.interpreter.evaluator.Evaluator.forBlock(Evaluator.java:291) at com.sun.fortress.interpreter.evaluator.Evaluator.forBlock(Evaluator.java:50) at com.sun.fortress.nodes.Block.accept(Block.java:61) at com.sun.fortress.interpreter.evaluator.Evaluator.forDo(Evaluator.java:259) at com.sun.fortress.interpreter.evaluator.Evaluator.forDo(Evaluator.java:50) at com.sun.fortress.nodes.Do.accept(Do.java:49) at com.sun.fortress.interpreter.evaluator.Evaluator.eval(Evaluator.java:54) at com.sun.fortress.interpreter.evaluator.values.FunctionClosure.applyInnerPossiblyGeneric(FunctionClosure.java:204) at com.sun.fortress.interpreter.evaluator.values.Fcn.applyToArgs(Fcn.java:107) at com.sun.fortress.interpreter.evaluator.values.Fcn.functionInvocation(Fcn.java:194) at com.sun.fortress.interpreter.Driver.runProgramTask(Driver.java:513) at com.sun.fortress.interpreter.evaluator.tasks.EvaluatorTask.compute(EvaluatorTask.java:52) at jsr166y.RecursiveAction.exec(RecursiveAction.java:146) at jsr166y.ForkJoinTask.quietlyExec(ForkJoinTask.java:459) at jsr166y.ForkJoinWorkerThread.mainLoop(ForkJoinWorkerThread.java:356) at jsr166y.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:341) What did I do wrong? Sincerely, Christopher _______________________________________________ language mailing list language-EFxYrSp25jGFLKEeoBv638bH8sH8CGPj&lt; at &gt;public.gmane.org http://projectfortress.sun.com/mailman/listinfo/language </pre> Christopher Rinderspacher 2010-08-05T01:37:30 http://comments.gmane.org/gmane.comp.lang.fortress.general/808 <pre>I must be misunderstanding the spec: I have a file testera.fsi: api testera testerf( a: NN64) : Matrix[\ RR64, a, a\] end And a file testerc.fss: component testerc export testera testerf(a: NN64) : Matrix[\ RR64, a, a\] = do println "testit" b: Matrix[\ RR64, a, a\] b end end upon "fortress compile testerc.fss" the following error message pops up: /home/crinders/projects/fortress_4337/testera.fsi:2:13-15: NN64 is undefined. /home/crinders/projects/fortress_4337/testera.fsi:2:21-25: Matrix is undefined. If I run "fortress run sudoku.fss" the program just runs. So what am I missing? Sincerely, Christopher _______________________________________________ language mailing list language-EFxYrSp25jGFLKEeoBv638bH8sH8CGPj&lt; at &gt;public.gmane.org http://projectfortress.sun.com/mailman/listinfo/language </pre> Christopher Rinderspacher 2010-07-31T21:16:26 http://comments.gmane.org/gmane.comp.lang.fortress.general/807 <pre>Dear all, I'm new to Fortress and this list and so I'm still working my way through the language and convenient editing options. I have a problem with emacs not rendering everything the way I would expect it. In particular, A[i] or A_i are not rendered as subscript. I know this is possible, because in LaTeX mode emacs will render A_i and A^i as sub- and superscript, respectively. This destroys my illusion of coding in "math." Is there a flag or a trick to make this work? Sincerely, Christopher _______________________________________________ language mailing list language-EFxYrSp25jGFLKEeoBv638bH8sH8CGPj&lt; at &gt;public.gmane.org http://projectfortress.sun.com/mailman/listinfo/language </pre> Christopher Rinderspacher 2010-07-30T17:29:05 http://comments.gmane.org/gmane.comp.lang.fortress.general/806 <pre>_______________________________________________ language mailing list language-EFxYrSp25jGFLKEeoBv638bH8sH8CGPj&lt; at &gt;public.gmane.org http://projectfortress.sun.com/mailman/listinfo/language </pre> Russel Winder 2010-07-28T13:57:40 http://comments.gmane.org/gmane.comp.lang.fortress.general/804 <pre>Hi all, I can't build fortress (latest svn snapshot), as well as about a week (before the term is worked ok). It yields /home/dmitrey/PFC/build.xml:504: Compile failed because of an internal compiler error (GC overhead limit exceeded); see the error output for details. if [ -z "$ANT_OPTS" ] ; then export ANT_OPTS="-Xmx512m -Xss32m" echo Using ANT_OPTS="\"$ANT_OPTS\"" fi all my .antrc files are default, so there is 512 MB mentioned. But 2 GB of my RAM is not enough, I see it occupies all free memory and then yields the error message I mentioned above. I have linux KUBUNTU 10.04, java-6-sun. D. _______________________________________________ language mailing list language-EFxYrSp25jGFLKEeoBv638bH8sH8CGPj&lt; at &gt;public.gmane.org http://projectfortress.sun.com/mailman/listinfo/language </pre> Dmitrey 2010-07-20T08:55:23 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.lang.fortress.general