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

Re: Parallel String Spitting (from Strange Loop)

Guy Steele — 2011-04-25T21:29:18

Sorry for delay in replying; I'm catching up on old email.

Thanks for reporting these very interesting results.

There are actually multiple implementations of List for
Fortress (that's one of the goals of Fortress: to support
multiple implementations of the same API).

If you look in the source-code repository in directory
Library, you will find both List.fss and PureList.fss .
The comments near the front may be of interest to you.
Briefly, List.fss uses an array-based implementation,
whereas PureList implements finger trees, a rather
complicated self-balancing tree structure.

--Guy

On Mar 1, 2011, at 11:32 AM, Michael Barker wrote:


_______________________________________________
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

Re: Project Fortress is moving to Java.net

Russel Winder — 2011-03-12T16:50:53

David,


Dispensing with keeping dependency  artefacts in the project filestore
in favour of pulling things in from the Maven repository is definitely a
good thing.

I would suggest investigating Gradle (http://www.gradle.org) to replace
Ant or at least switching to Maven.   Gradle and, but to a lesser
extent, Maven make handling dependencies from the Maven repository --
and indeed elsewhere -- easy.  You would then be able to dispense with
the jars from the project filestore.


An interim would be to use the Maven Ant task to handle the download
within an Ant context.  It's not as good as switching to Gradle or
Maven, but it can work.


No problem, a serendipitous adventure.

I tend to "hg pull -u" ;-)

Compiled successfully.

Re: Project Fortress is moving to Java.net

David Chase — 2011-03-12T14:23:52

Russel,

You're getting a little ahead of us, since my goal was Monday, but the cause of your problem is that I split out the 3rd party jar files from the repository because

- they change rarely
- they are large
- we hope to move to Maven, which I understand will make pass-by-value unnecessary

So on the one hand, you're a bit ahead of me, and on the other, I just tested my plan (separate download), and it doesn't work, because the URL is magic (using cookies and/or referrer, don't know which).

So I just now added them locally, tested a build, and committed.

Thank you very much for your unintentional beta-testing.
 "hg pull", "hg up", and it should work .
(and I just tested that, end-to-end).

David

On 2011-03-12, at 5:06 AM, Russel Winder wrote:


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

Re: Project Fortress is moving to Java.net

Russel Winder — 2011-03-12T10:06:28

David,

Nice that the repository is now Mercurial and not Subversion, though the
announcement didn't point this out ;-)

One slight problem.  I use the command line:

ANT_OPTS="-Xmx1024m -Xss64m" ./ant clean compile

on my AMD64 Ubuntu 10.10 box -- the default Ant settings lead to garbage
collection thrashing hence the increase in resources to the JVM.  This
works fine in the Subversion checkout, but fails with:

        |> ANT_OPTS="-Xmx1024m -Xss64m" ./ant clean compile
        Buildfile: /home/Checkouts/Mercurial/Fortress/build.xml
          [taskdef] Could not load definitions from resource scala/tools/ant/antlib.xml. It could not be found.
        
        BUILD FAILED
        /home/Checkouts/Mercurial/Fortress/build.xml:441: taskdef class edu.rice.cs.astgen.AntTask cannot be found
         using the classloader AntClassLoader[]
        
        Total time: 0 seconds

in the Mercurial clone.

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

Re: Fortress example of WMM2010

Guy Steele — 2011-02-18T21:45:44

Thank you!  This is very interesting code, and I will read it more
closely next week.  (It does make me even more enthusiastic
about getting the dimensions-and-units part of the language
implemented.)  It is very nice that you were able to work from
the math rather than the C code---that is one of our goals!

I notice that the comments are already making use of the
Wiki tabular markup; perhaps you would be willing also
to put markup around the URLs in the comments.  If you
enclose them in {{{ }}}, they will be treated verbatim and
set in the monospace font.  (Maybe eventually the fortify
tool will include special URL markup that will result in a
hot link.)

--Guy

On Feb 13, 2011, at 7:50 AM, Francois Retief wrote:


_______________________________________________
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

Re: nat parameters in variant structures

Sorin Zsejki — 2011-02-03T21:10:33

I know this is not very constructive, but I'll jump on the opportunity
to point out that this proposal regarding nat parameters can be
considered a special case that could be extended to type parameters,
making it similar to C++ partial template specialization. I think
someone on this list already had such a suggestion (for type
parameters).

Re: nat parameters in variant structures

Guy Steele — 2011-02-03T20:21:52

On Feb 3, 2011, at 2:59 PM, Diane Lee wrote:


Yep.  One approach would be to limit ourselves to linear equalities and inequalities, and then hit the problem with the sledgehammer of a general-purpose integer linear programming solver.  Two declarations exclude each other if, when you toss all their constraints into a single pot, there is no solution to the combined set of constraints.

One could also contemplate detecting when one declaration is more specific than another, but that might require a nonlinear solver (or worse).

Certainly simple cases could be supported easily.

--Guy

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

Re: nat parameters in variant structures

Diane Lee — 2011-02-03T19:59:28

On Jan 31, 2011, at 11:47 PM, Guy Steele wrote:


I guess I should have specified n > 0. What I meant here is that we want an object of type Cons[[S,n > 0]] to be allowed wherever List[[S,n > 0]] is required (and we have done that by declaring Cons[[S, n>0]] extends List[[S,n]]), but at line 10 we also want any object of type List[[S, n > 0]] to be usable as you would a Cons[[S, n]], i.e. to have the same methods. Simply put, we want List[[S,n > 0]] and Cons[[S, n>0]] to have the same interface, visible statically. Furthermore, we want dynamic method dispatch to behave the same for both types. 

(We also want the same of Empty[[S]] and List[[S,0]] but in this example Empty[[S]] didn't have any methods that List[[S,0]] didn't have so we didn't see any problems. )

I wanted to argue that with this kind of relationship, there isn't any reason that they can not go by the same name. 


I totally agree, that would be much nicer. I was just suggesting a ready-out-of-the-box solution -- we only need to check argume

Re: nat parameters in variant structures

Jan-Willem Maessen — 2011-02-02T19:25:02

On Tue, Feb 1, 2011 at 5:52 PM, Victor Luchangco
<victor.luchangco< at >oracle.com> wrote:

Agreed, the comprises clause is definitely preferable.  I did want to
note that with appropriate type declarations, lines 9-10 would
typecheck---it's just that they won't satisfy the abstract method
declaration in the superclass unless there's a comprises clause AND
the right set of comprises checking in place.


It looks like there may be a middle ground here between "full-on
conditional extension" and "no checking" that would permit the zip
example, but might make it tricky to type check stuff like the
declaration of adjacentPairs without inserting a dynamic check.  I did
also want to point out that falling back to dynamic checking is an
option in these cases---we can still hang on to *some* static checking
even if the type checker isn't powerful enough to catch *every*
possible static invariant.

-Jan

_______________________________________________
language mailing list
language< at >projectfortress.sun.com
http://projectfo

Re: nat parameters in variant structures

Victor Luchangco — 2011-02-01T22:52:37

On Feb 1, 2011, at 2:48 PM, Jan-Willem Maessen wrote:


Why should we want, however, to work around the absence of a comprises clause?  Wouldn't it be better to include the comprises clause?



Yes, I agree with this, and if we had where clauses to the full extent that we've considered (assuming we can get them to work), then we could do this.  But this involves something like the conditional extension that Guy has long suggested, and we have never, to my recollection, worked out the details that such expressivity would imply.

- Victor



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

Re: nat parameters in variant structures

Jan-Willem Maessen — 2011-02-01T19:48:28

I've been thinking about how this corresponds to other type systems
that let us encode the same kinds of invariants, and how I encoded the
invariants in PureList.  After whacking at it for about 5 minutes, I
realized that expressing "I take another argument that has the same
size as me" is difficult at best, and that I ended up throwing in
methods that could (statically) return bottom but which (dynamically)
never would, effectively moving some of the checking to run time when
it was too hard at compile time.  This basically meant I'd write a
declaration like:

8:  object Cons[[T, nat n > 0]](fst:T, rst:List[[T, n-1]]) extends List[[T, n]]
9:      zip[[S]](other: Cons[[S,n]]) :Cons[[(T,S), n]]
10:         = Cons[[(T,S), n]]((fst, other.fst), zip(rst, other.rst))
10a:   zip[[S]](other: List[[S,n]]): List[[(T,S), n]] = throw "Impossible!"
11: end

Effectively I'm working around the absence of a comprises clause by
using maximally-specific types and then inserting a catch-all
overloading.  (Note: I can't say fo

Re: nat parameters in variant structures

Victor Luchangco — 2011-02-01T06:09:28

On Jan 31, 2011, at 6:07 PM, Diane Lee wrote:


Assuming that List[\ T, nat n \] should really have a comprises { Empty[\T\], Cons[\T,n\] } clause, we could also avoid the type error by making using Cons[\T,n\] as the type of other in the Cons declaration.  This requires type checking to be a bit more sophisticated, because it must recognize that the only immediate subtype of List[\T,n\] when n > 0 is Cons[\T,n\], but I think we would want such sophistication in any case.

That said, it might be nice to allow the declaration with List[\T,n\] as you have it, and the idea of cutting out the "middle men" of Empty and Cons has some independent attraction.  (I agree with Guy's suggestion that the dispatch should be like method dispatch (i.e., without regard to order, but requiring the definitions to satisfy the overloading rules) rather than case/typecase.)

- Victor



_______________________________________________
language mailing list
language-EFxYrSp25jGFLKEeoBv638bH8sH8CGPj< at >public.gmane.org
http://projectf

Re: nat parameters in variant structures

Guy Steele — 2011-02-01T05:47:58

Thanks for explaining this exercise.  I followed it all except for  
once sentence (see below).

On Jan 31, 2011, at 6:07 PM, Diane Lee wrote:


Is this last sentence right?



Um, we've tried real hard in all parts of the language not to make the  
order of top-level declarations matter. Rather, it should be like  
method dispatch.

All the rest of this message makes sense and suggests an interesting  
direction.

--Guy


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