gmane.comp.lang.fortress.general

Regions Explanation

Saliya Ekanayake — 2011-05-02T23:24:03

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< at >public.gmane.org
http://projectfortress.sun.com/mailman/listinfo/language

One last (?) Fortress-move announcement

David Chase — 2011-03-16T19:50:20

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 -> announce
implementation -> dev
      language -> 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 h

A reminder -- Fortress repository and mailing listsmoved to java.net

David Chase — 2011-03-15T19:19:19

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< at >public.gmane.org
http://projectfortress.sun.com/mailman/listinfo/language

Project Fortress is moving to Java.net

David Chase — 2011-03-12T02:12:39

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

Mailing lists, website,and svn may be intermittently offline in the next two weeks.

David Chase — 2011-03-08T21:51:53

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< at >public.gmane.org
http://projectfortress.sun.com/mailman/listinfo/language

Parallel String Spitting (from Strange Loop)

Michael Barker — 2011-03-01T16:32:06

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 implem

web-based fortify server?

Damon McCormick — 2011-02-19T00:36:09

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< at >public.gmane.org
http://projectfortress.sun.com/mailman/listinfo/language

Fortress example of WMM2010

Francois Retief — 2011-02-13T12:50:11

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
        pr

nat parameters in variant structures

Diane Lee — 2011-01-31T23:07:22

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 > 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 construc

Typecase expression: No binding in else clause?

Diane Lee — 2011-01-19T06:57:14

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

Tail call recursive in also do blocks

Francois Retief — 2011-01-13T19:51:46

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 < lmax <= 2700, |z| <= 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

How to return Vector from a function

Francois Retief — 2011-01-09T16:10:30

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 >= 0 AND |z| <= 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< at >public.gmane.org
http://projectfortress.sun.com/mailman/listinfo/language

proposition to replace "import" by a symbol

Dmitrey — 2011-01-07T09:26:47

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 = < at >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< at >public.gmane.org
http://projectfortress.sun.com/mailman/listinfo/language

interoperability with Java

Felix Breuer — 2010-12-22T09:28:41

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.

Has the fortress community server been moved?

Tom — 2010-09-23T13:43:38

_______________________________________________
language mailing list
language-EFxYrSp25jGFLKEeoBv638bH8sH8CGPj< at >public.gmane.org
http://projectfortress.sun.com/mailman/listinfo/language

Explicit static parameters

Eric Allen — 2010-09-21T18:37:46

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 exp

conjGrad example

Christopher Rinderspacher — 2010-08-05T01:37:30

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 <- seq(1#cgit_max) do
      q = A p
      alpha = rho

Matrix and NN64 unknown?

Christopher Rinderspacher — 2010-07-31T21:16:26

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< at >public.gmane.org
http://projectfortress.sun.com/mailman/listinfo/language

Emacs rendering mode

Christopher Rinderspacher — 2010-07-30T17:29:05

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< at >public.gmane.org
http://projectfortress.sun.com/mailman/listinfo/language

Compilation parameters

Russel Winder — 2010-07-28T13:57:40

_______________________________________________
language mailing list
language-EFxYrSp25jGFLKEeoBv638bH8sH8CGPj< at >public.gmane.org
http://projectfortress.sun.com/mailman/listinfo/language

Failed to build fortress - GC overhead limit exceeded

Dmitrey — 2010-07-20T08:55:23

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< at >public.gmane.org
http://projectfortress.sun.com/mailman/listinfo/language