Hi Aroon --
From memory (i.e., I may not have this exactly right, but I think it's
close):
The current Chapel implementation makes parallelism illegal within all
iterators other than leader iterators, due to the fact that all other
iterator types are intended to support zippering and we did
Hi Chapel Developers --
Twice in the past month, someone has been caught by the following issue.
They write code like this:
for i in [1..10] do
foo(i);
thinking that they are iterating over the values 1..10 and i will be an
integer, when in fact they've created a 1-element ar
Hi Chapel Community --
Highlights of this year's Chapel-related events at SC13 include:
* the annual Chapel Lightning Talks BoF, featuring five-minute talks by
members of the broad Chapel community on Chapel's relationship to
education, MPI-3, HDFS, autotuning, futures, and MiniMD (Wed 12:
I've been working in this part of the code a lot lately (relatively to the rest
of the group), and so would be a logical reviewer, and am definitely interested
in reviewing it, but am not certain that I'll have time to before the end of
Thanksgiving week (and then will have some digging out from
Hi Chapel Developers --
There's been a sharp uptick (from close to zero ever to something like one
per day or two) in spam messages being sent to chapel-developers (and
being caught because we only permit posts by on-list subscribers without
administrative approval). I wanted to check and see
Related to Michael's commmit:
FWIW, I have a long-standing TODO to look in general for extern functions
with 'inout' intents that could/should be updated to 'ref' now that we
have it, in the standard modules and test suite. I'd be happy to have
anyone with more time on their hands to steal th
Hi Brandon --
It's fine to touch any of the code and submit patches for consideration as
you've done here. We're conferring internally to determine who should
review this patch.
As you may have read in other threads, Chapel's handling of strings is
currently fairly impoverished though we're
> Hmm, what if getaddrinfo was used directly as an extern proc in the Net
> module code instead of through a wrapper in sys.c? Though that would be
> an issue on systems without a getaddrinfo. We'd be able to handle that
> if it was possible to have conditional compilation of Chapel code
> dependi
> Also, you have removed an optimization that calls the simpler string_select
> routine when stride == 1. It would be OK with me if string_strided_select
> included that optimization, but I think it's important.
I haven't reviewed this patch in detail, but based on this comment wanted
to note th
> But either
> way, the Net module would not be a standard module, and so that
> Chapel code would only be compiled if the program said 'use Net;'.
Terminology check: It *would* be a standard module (forming part of the
standard library); it would not be an internal / automatically-used
module.
> Thanks for your feedback. I'll work on this. I still need to figure out
> how to run all the tests, but I'm sure there's a README somewhere if I look.
If you run util/start_test from anywhere under the test/ directory, it'll
walk and test the entire directory tree under there, printing a summa
Hi Chris --
There's a longstanding feature idea to reduce this duplication of function
definitions, similar to what you are proposing here, yet also different. It
would also be useful in other cases unrelated to function duplication like
this. We've typically viewed this capability as a query
> Hi Brad,
>
> (3) is a very good point. While I don't see (1) and (2) as a major
> objection, they do point out that for "undefined" to be useful in the
> common case, an undefined variable should be assignable. This essentially
> means that a variable may have two values (it's actual value and
Hi Chris --
> New things are not l-values --- I just tried this and the compiler agrees.
>
> AFAICT the only way you can currently give ref parameters default values is
> something along these lines:
>
> var err = new errorstate();
> proc foo(ref err = err) { ... }
My apologies for not trying my
Oh, good! Now we just need someone to implement the behavior for ref
intents and document the old and new behavior... :) I'm hoping that the
implementation will be a fairly simple matter of finding and duplicating
the logic that's used for 'inout' intents.
-Brad
On Mon, 9 Dec 2013, Chris
Hi Chapel Community --
SC13
Thanks to everyone who came to one or more Chapel events at SC13! It was
a busy week, the major highlights being:
* our emerging technologies exhibit which gave Chapel a home base
on the show floor where potential users/developers could find
ll promote to some(int)
> // but you would write foo(new some(err) if not.
> A problem with this solution is that the value in some has to be
> a reference to the original err argument, which seems to be asking
> more of the language than the other options. However, if the
> '
>> foo(err); // hopefully the int argument will promote to some(int)
>> // but you would write foo(new some(err) if not.
>> A problem with this solution is that the value in some has to be
>> a reference to the original err argument, which seems to be asking
>>
2 (adding
> also
> the symmetric "return value used"). For 3, compile time vs. run time - I'm a
> little
> bit worried about code size, but am OK with it being compile time.
>
> Cheers,
>
> -michael
>
>
> On 12/11/2013 11:45 AM, Brad Chamberlain wrot
Hi Chris --
I'll give you my take on your main question (should we use
autoconf/cmake?), with the caveat that it's just my opinion. Others may
disagree (and should if I'm wrong). But this probably explains why we are
where we are:
* generally, as a user, I don't like installing autoconf-ori
> I believe that there are other places besides bswap.h that we could use the
> functionality provided by a configuration system. One example would be the
> enabling of C++11 features if a compiler is present that supports them.
> RValue references and move semantics not only make code easier to
> This might also allow Chapel
> to stop shipping so much 3rd party software along with it.
This too I view as a strength of the current system rather than a
weakness. There's nothing I like less when trying a new technology than
being required to download and install a bunch of dependent pack
I'm not following this in great depth, but popping in quickly:
> I would prefer to consolidate the error returns
> into optional arguments and a single return type. For
> example, instead of
> (socket, err) = listen("tcp, "", port)
> we could fold an error code into our 'socket' class,
> so tha
Hi Chapel Developers --
A user noticed that we don't replicate global constants across locales as
we do for integers and other scalar types (and advertise in the spec),
which seemed like, and was, a five-minute fix (TM). While here, I noticed
other scalar types that weren't being replicated
Hi Chris --
I think we've talked within the group about wanting to have cases like
this work, but (to my memory) haven't ever tackled it -- probably in part
for fear that the place where the varargs should stop matching might be
ambiguous/unclear (espcially in the face of implicit coercions an
Hi all --
This is a request for a review to simplify the implementation of standard
operations (+, -, *, etc.) on homogeneous tuple operations. It's pretty
straightforward. I thought I was seeing a bit of performance improvement
on my Mac last night, but on linux it seems to be a bit of a w
> 1) allow c_ptrTo to be passed a 1-D rectangular array or a tuple, and have it
>return a pointer to the first element == a pointer to the whole array.
>I've committed test cases in
> test/extern/ferguson/{tuple_to_pointer,array_to_pointer}.chpl
>Then the recommended way to pass an ar
I've spoken with Michael a bit about this off-list, and the summary of my
thoughts is:
* I don't necessarily feel beholden to the C operator precedence list (it
is what led to the current state of the affairs, not realizing that it
was considered flawed)
* my approach would be to see what
The comment in this test:
> [Error matching program output for expressions/bradc/bitopsVsEqualtyPrec]
shows that I'm more forgetful than I'd like to admit: I guess we did know
that C's precedence was broken at some point but decided to stick with it
anyway.
> [Error matching program output f
Hi Chapel Community --
As a quick reminder, the deadline to propose a talk for CHIUW (the Chapel
Implementers and Users Workshop) is coming up on January 17th. CHIUW
itself will be held on Friday, May 23rd as an IPDPS workshop.
The proposal process is intended to be short and sweet: Submit an
Hi Chapel Developers --
We've been working on improving the ability for an external developer to
more easily make contributions to the Chapel project, and have recently
introduced three changes in support of external developers:
1) Kicked off a #chapel-developers IRC channel. This chatroom i
Hi Chapel Developers --
[Attn: Michael, as a few people have suggested that they think you may
have done something like this in the past?]
Here's something that I was thinking about over the break, have discussed
with a few of you, and wanted feedback on:
As many developers know, often you wa
Hi Chapel Developers --
Here's a second opportunity for comment. A few of us have been frustrated
for awhile about the way references are represented in the Chapel
compiler, both in terms of making the IR more complex and making the code
harder to reason about.
In particular, for code like t
> The thing I would like to add here is that I found it very confusing
> (but am used to it now) that Class within the compiler means
> - reference
> - record
> - class
> - tuple
>
> I don't philosophically disagree with 'things with fields' being
> grouped into one AST element, but that AST e
Hi Michael --
> What I used for testing the LLVM code generation infrastructure is this flag:
>
> --[no-]ignore-internal-modules Enable [disable] skipping internal
> module initialization in generated code
> (for t
> Apparently it no longer works. It segfaults for me on cases that used to
> work with it. It was supposed to skip the module initialization phase
> for possibly all modules (or at least the internal ones). All the modules
> are still compiled - it's just that they are not run at program startup
I have two high-level notes on this, based on reading the description and
glancing at the code:
1) I'd be open to supporting c_ptrTo for any DefaultRectangular array
rather than limiting it to arrays of rank 1. (I.e., I'd say that
any array whose storage is contiguous in memory should b
e...
-Brad
On Thu, 2 Jan 2014, Michael Ferguson wrote:
> Hi -
>
> I recently wanted to compare two arrays, and I remembered
> this discussion but did not remember where we ended up.
>
> So, two questions:
> 2) Can we add a method, like A.equals(B) or something, that returns a
ch requests along to the steering
committee for consideration along with the summary of what we received.
Thanks,
-Brad
On Thu, 9 Jan 2014, Brad Chamberlain wrote:
>
> Hi Chapel Community --
>
> As a quick reminder, the deadline to propose a talk for CHIUW (the Chapel
> Impleme
Taking this part of this message to the developers list (so as not to bias
users prematurely... I don't mind trying to bias you guys :):
> A consequence of this change is that the error message issued when an
> attempt is made to supply a non-lvalue as the left operand of assignment
> will cha
es I list below,
but imagine the others aren't there.
-Brad
On Tue, 21 Jan 2014, Brad Chamberlain wrote:
>
> Hi all --
>
> This is a patch implementing the "minimal modules" compilation mode that I
> proposed a week or so ago which I'd like to request a re
> One way to take that out of the compiler might be to have a fall-back
> function (or two) in the module that would be resolved to when the
> actuals are non-lvalues or const lvalues. Those functions would throw a
> compilerError(). Maybe proc =(in a, b) and proc =(const ref a, b) ?
Personally,
a big diff) -- apply them and then surf the
modules manually).
-Brad
On Tue, 21 Jan 2014, Brad Chamberlain wrote:
>
> Hi all --
>
> This is a patch implementing the "minimal modules" compilation mode that I
> proposed a week or so ago which I'd like to request a r
I considered moving it under for similar (but less important to me) reasons,
but didn't
like (a) the implication that it was part of the normal modules setup and (b)
the lack
of symmetry. If others feel similarly about minimal-modules (or any other
combination
including the current) I'm open to
Hi Michael --
Just a note in case it feels useful/helpful/resonates: There's been some
discussion this week about whether the default choice for static/dynamic
linking should be established via a util/chplenv/ script and CHPL_
variable, ideally one linked to the current --static/--dynamic fla
Hi Chapel Devs --
This is a request for a proposed change to the interpretation of Chapel
programs, which anyone invested in the language should give a quick look
at and then respond to two questions below. There's also a patch to
implement the change (which I'll need a reviewer for as soon a
Oops, the Michael Ferguson bug bit me and I forgot the patch. Attached
now.
-Brad
On Fri, 24 Jan 2014, Brad Chamberlain wrote:
Hi Chapel Devs --
This is a request for a proposed change to the interpretation of Chapel
programs, which anyone invested in the language should give a quick
Here are some initial off-the-cuff thoughts:
> I'd really like to be able to say something like A.append("Hello"),
> when A is a 1-D rectangular array, and A.append(key, value) (for an
> associative array). This kind of array flexibility is one of the main
> productivity advantages Perl or Python
Hi Chapel Developers --
We've recently started exploring various ways for the compiler, runtime, and/or
user to squash task-based nested parallelism in Chapel. For example, imagine
the following:
config var n = 100;
var A: [1..n][1..3] real;
var res: [1..n] real;
forall i in 1..n do
re
FWIW, I'm still looking for responses to my original questions and am not
as personally interested in the side topic that has hijacked it for now.
-Brad
On Mon, 27 Jan 2014, Tom Hildebrandt wrote:
> Hi Lydia:
>
> By definition, a set can only contain one copy of each distinguishable
> elemen
> I think question 1 is a solid yes. {D} should be an associative domain of
> domains. Having a compiler warning for this for at least one release would
> be good.
That's a good idea and easy to implement. I've made the change and am
re-testing before committing and/or re-submitting for rev
ted this for me.
I'd be happy to convert all 'serial true' tests to just use 'serial' if that's
what people would like (seems like a good way to put our best foot forward, so
I'd vote "yes").
Thanks,
-Brad
From:
Lydia has reviewed this -- working toward committing it now.
-Brad
From: Brad Chamberlain
Sent: Monday, January 27, 2014 10:36 PM
To: Chapel Sourceforge Developers List
Subject: Request for review: 'serial do' (was: RE: Request for feedback: serial
do
Hi guys --
While I'm sorry about the time spent on this issue, I'm always glad when
we can pass the blame to something other than Chapel. :)
Something I'm wondering is whether, if GASNet is built with runtime checks
on (I think this is done using --enable-debug at GASNet configuration
time
Yeah, sorry for the confusion. CHPL_DEVELOPER is currently treated as
set/unset, primarily because of my personal laziness in not wanting to
distinguish between true/True/yes/Yes/Y/T, their negative correspondants,
and the grey area in-between in the Makefiles. If anyone has a cute/easy
tric
en I compile and run the program with GASNET_BACKTRACE=1, But i don't get
any message.
Some debug messages are supposed to be shown during program execution if we
configure GASNet with --enable-debug flag?
Please let me know if you have any suggestions.
Best,
Akihiro
On Jan 29, 2014, at
Hi Rafael and Akihiro --
It sounds as though there isn't a known issue w.r.t. large ibv conduit
messages (I didn't catch the importance of 'strided', so sent that along
in a second message, but don't expect it'll change the response). They
wrote:
> We don't have a known error with long messag
bug report.
which is here:
https://upc-bugs.lbl.gov/bugzilla/show_bug.cgi?id=495
-Brad
On Wed, 29 Jan 2014, Brad Chamberlain wrote:
>
> Hi Rafael and Akihiro --
>
> It sounds as though there isn't a known issue w.r.t. large ibv conduit
> messages (I didn't catch the im
One more note:
> The strided code allocates and frees buffers for pack/unpack which can
> trigger the bug.
>
> One additional work around is to disable the problematic pack/unpack
> implementation by setting env var GASNET_VIS_AMPIPE=0
-Brad
On Wed, 29 Jan 2014, Brad Ch
Thanks for clarifying this Rafa -- I haven't done a good job of keeping
this clear myself.
I think we're now in a position where we no longer need to generate a
C+GASNet test case since GASNet already knows about the problem (sorry if
I didn't make that clear in my previous mail).
But, we
Hi Rafael --
Thanks for your analysis and description.
I don't have any problem with changing the default segment for 'ibv' and
agree that it sounds like the right thing to do if it works around this
issue. It seems like 'fast' would be preferable to 'large' from a
performance perspective (
round is to configure GASNet with "--enable-pshm-sysv
--disable-pshm-posix".
Thanks,
-Brad
On Thu, 30 Jan 2014, Brad Chamberlain wrote:
Hi Rafael --
Thanks for your analysis and description.
I don't have any problem with changing the default segment for 'ibv'
-posix".
Yes, it works fine with those changes, sorry for the delay.
Greets,
Rafael
Thanks,
-Brad
On Thu, 30 Jan 2014, Brad Chamberlain wrote:
Hi Rafael --
Thanks for your analysis and description.
I don't have any problem with changing the default segment for 'ibv&#
Hi Chapel Developers --
The 1.9 release is coming up over the horizon. The current proposed dates
for freezing the code base are as follows:
Mar 25 : feature freeze
Apr 1 : code freeze
Apr 4 : doc freeze + cut branch
Apr 17 : release
Please give a shout if yo
Hi Chapel Developers --
A bug I ran into today made me realize the following for the first time:
Back in the dark ages when we didn't have array literals, we used tuple
literals as the means of initializing arrays, primarily because we had no
other recourse. Thus, you'd write:
var A
Chapel Developers --
While we're talking about array literals, we need a syntax for
multidimensional array literals. That is, how should I write the
conceptual 3x3 array of reals:
1.1 1.2 1.3
2.1 2.2 2.3
3.1 3.2 3.3
as Chapel source code?
Note that the following:
PM
To: Brad Chamberlain
Cc: Chapel Sourceforge Developers List
Subject: Re: [Chapel-developers] Retire tuple-to-array assignment?
One reason to keep such assignment is for performance. At least for as
long as we do not optimize away the extra array creation in "var A =
[1.2, 3.4, 5.6];"
> Half of Vass's argument is cogent: const in implies a copy while const ref
> does not.
I'm not disagreeing with that, but don't see what it has to do with the
question at hand.
I read Vass's reply as saying "you recently argued a point that was in
opposition to a proposal I
made on the basi
Hi Kenjiro --
Just to see if it gets the juices flowing, I believe that one suggestion
(which I don't get any credit for) was to use multiple consecutive
"dimensional" separators for higher-dimensional cases. So for example, a
2x2x2 array might appear as follows:
[ 1.11, 1.21;
I'll review the test changes.
-Brad
On Mon, 24 Feb 2014, Michael Ferguson wrote:
> Hi Tom (and everybody) -
>
> Great, thanks. I've committed the compiler changes with your review and
> am awaiting a review of the test/ changes.
>
> Cheers,
>
> -michael
>
> On 02/24/2014 02:33 PM, Tom Hildebra
This should be a pretty simple review -- mostly housecleaning...
While working in scalarReplace.cpp this week, I noticed that we sort
through cases that make for a legal scalar replacement, but then there's a
nested else if conditional that has no 'else' clause which suggests that
expressions
Hi Michael --
Just to make sure I'm tracking, when you ask:
> Why do we build Chapel+GASNet with --enable-pshm at all?
My impression is that we're not enabling pshm, it's just that it's enabled
by default and that we're not disabling it (other than in the cases you
cite). Is that right or di
on wrote:
> Yes, it's enabled by default in GASNet and we
> only disable it in specific cases. I'm wondering
> why we don't disable it all the time.
>
> -michael
>
> On 03/10/2014 04:24 PM, Brad Chamberlain wrote:
>>
>> Hi Michael --
>>
&g
Hi Chapel Developers --
This is a request for review.
Size of patch = 2 out of 7.
Complexity = 4 out of 7.
The attached patch makes the insertion of formals to represent variables
when de-nesting functions a little less conservative by strengthening the
check for const-ness and not making the
> I'm not sure that the test (for ref type) on line 153 of
> remoteValueForwarding.cpp is necessary for the sake of RVF itself. If
> it is declared to be 'const' and we respect that, then it seems
> reasonable to be able to forward the value. The machinery for
> implementing RVF may have to
> My concern with this patch's change to passByRef() is that flattening will
> pass large records by value. Which is exactly what our 'const' intent is
> intended to eliminate. Seems inconsistent to me.
I don't think that's right. We pass blank and const records by reference
at the C level; a
ding.cpp and updated the comment to reflect
the change.
Please give a shout if there are any reservations against committing this
(though I may wait until tomorrow anyway so that any performance impacts
will be better isolated from today's changes).
Thanks,
-Brad
On Fri, 14 Mar 2014, Brad Ch
> I do not claim to follow the "C vs. Chapel-level" paragraph above.
The point was important and is this: Just because a Chapel argument does
not have a 'ref' intent or type does not mean that an argument cannot/will
not be passed by ref/pointer in the generated C. In particular, all
records
Given that the intents have only just changed to bit vectors and (I
believe) have not been used as such yet, I'm guessing "not many". Though
an equivalent thinko could happen in other ways.
-Brad
On Fri, 14 Mar 2014, Vassily Litvinov wrote:
>> [...] I've switched from checking the 'const'
Hi Chapel Devs --
This is my long-awaited patch that removes formal temps. The heart of the
patch itself is pretty straightforward in functionResolution.cpp (and much
simpler than what was there before). The main work in getting the patch
to this point was dealing with other erroneous cases
: Saturday, March 15, 2014 5:58 PM
To: Brad Chamberlain; Chapel Sourceforge Developers List
Subject: RE: [Chapel-developers] [patch] extraneous formal temp elimination
All:
I will review this patch with an eye to the change in memory usage.
Even without opening the patch I can say that changes in me
> Ah yes. Here is an example of such a "thinko":
>
> bool ArgSymbol::isConstant(void) {
> if (intent == INTENT_CONST_IN || intent == INTENT_CONST_REF) {
>return true;
> }
Focusing on just the first half of this (for simplicity), whether or not
this is a thinko depends on what isConstant()
Hi Chapel Developers --
size of patch = 2 out of 7
complexity of patch = 5 out of 7 (just because Makefiles are so spaghetti
by nature)
The attached patch is morally Michael Ferguson's, but I'd be happy for a
review from whomever if it can come sooner.
Just
Michael and Greg -- Are you guys pretty confident that the
--disable-pshm-xpmem flag is no longer required for that final else
clause? (What does that final else clause pertain to? At a glance it
looks like neither gemini nor aries?)
-Brad
On Tue, 18 Mar 2014, m...@users.sourceforge.net wr
Chapel Devs --
This is a patch that logically falls into Vass's court though everyone
should read the description to raise objections, if any.
In breaking one of Vass's futures this week, it looked like (and was) a
candidate for a 5-minute fix (TM). The issue raised was that internal
fail
Hi Chapel Community --
We've just posted the Advance Program for CHIUW (the Chapel Implementers
and Users Workshop) to the Chapel website:
http://chapel.cray.com/CHIUW.html
It includes 8 contributed talks on a variety of Chapel-related topics from
the broad Chapel community, a keynote
ailure will result in:
>
> # developer mode
> internal failure error:
>
> # user mode
> internal failure error: CAL0123
>
> Brad - I can give you a hand adjusting your patch for that.
>
> Vass
>
> On 03/19/14 17:39, Brad Chamberlain wrote:
>>
>>
Hi Jens --
Without knowing much about the TSX interface, here's a very high-level
potential sketch:
* write some C macros that wrap the start/end transaction instructions and look
like function calls syntactically.
e.g.:
#define CHPL_TSX_START ()
#define CHPL_TSX_STOP()
* de
Hi Chris --
Speaking personally, I wouldn't have a problem with seeing this recoded,
though I also don't touch this part of the code often enough to suffer
from it either. I remember Steve wrestling with it in the early days,
getting it working, and I haven't thought about it much since then.
Hi Daniel --
Thanks for passing this along. After years of not encountering any cygwin
users with spaces in their name, you're the second to show up with this problem
within the week (see the chapel-bugs mailing list for a mention of the other).
I just committed a fix for this issue this afte
IIRC, a difference between the two approaches is that putting it in
the parent skips all recursive traversal below that directory as well,
whereas putting it within the directory just skips that directory, but
not its children?
-Brad
From: Lydia Duncan [ly
Hi Kyle, Sung, Michael (or whoever) --
I'm finding that GMP builds and tests fine on my Darwin (using GMP's tests),
but that I get a really weird link error when I try to compile Chapel GMP tests
(pidigits, chudnovsky) using it. It complains about a library being in the
wrong format for an unk
Hi Michael --
I think it's our intention to follow C99's lead here and that the lack of
mention of it in the spec is an oversight. If you want to contribute a patch
to update the spec before the doc freeze on Friday, that'd be great. Saw your
bug fix patch in the other mail, but haven't had a
I'm wondering if the fix would be similarly correct and more
straightforward/less fiddly at codegen time if you were to add the
following to ChapelBase.chpl:
inline proc _cast(type t, x: integral) where _isBooleanType(t)
return (x != 0);
Generally, I'd like to see us converting more of
hat a try
(most likely this evening).
Tom H.
_
From: Chris Wailes [chris.wai...@gmail.com]
Sent: Monday, March 31, 2014 3:34 PM
To: Tom Hildebrandt
Cc: Brad Chamberlain; Lydia Duncan; chapel-developers@lists.sourceforge.
Hi Danilo --
I don't personally have enough experience with GASNet over ibv to
immediately recognize this error, but am Cc:ing the public chapel-bugs
list and chapel-developers list in case someone else does (Rafael?).
[Note that your responses to chapel-developers will bounce unless you're
ing to find a solution so that we can use chapel locales
in our course.
I think the original suggestion still holds, but this behavior may be
familiar to others... It sounds vaguely familiar to me, but not enough
for the solution to leap into my hands.
-Brad
On Wed, 2 Apr 2014, Brad
N=S
export GASNET_SSH_SERVERS="ib-minta ib-mintb"
export SSH_CMD=ssh
export SSH_OPTIONS=-x
Thanks,
Danilo
Da: g...@cray.com [g...@cray.com]
Inviato: mercoledì 2 aprile 2014 18.05
A: Brad Chamberlain
Cc: Danilo Guerrera; Public Chapel Bugs list; Chapel So
Hi Chris --
We're currently in the process of freezing everything for the release, so
this shouldn't be committed until after the release branch is made
(ostensibly tomorrow unless it gets delayed). That shouldn't stop anyone
from picking this up for review now in order to commit once the fre
export GASNET_SSH_SERVERS="ib-minta ib-mintb"
export SSH_CMD=ssh
export SSH_OPTIONS=-x
Thanks,
Danilo
Da: g...@cray.com [g...@cray.com]
Inviato: mercoledì 2 aprile 2014 18.05
A: Brad Chamberlain
Cc: Danilo Guerrera; Public Chapel Bugs list; C
1 - 100 of 375 matches
Mail list logo
