[9fans] speaking of kenc - Plan9

This is a discussion on [9fans] speaking of kenc - Plan9 ; There's Fortress being developed by Guy Steele at Sun, and others (IBM has one as well). http://fortress.sunsource.net/ Its certainly interesting. Whether it's good or not remains to be seen. []'s Rodrigo On 4/28/07, Charles Forsyth wrote: > This discussion made ...

+ Reply to Thread
Page 2 of 7 FirstFirst 1 2 3 4 ... LastLast
Results 21 to 40 of 121

Thread: [9fans] speaking of kenc

  1. Re: [9fans] speaking of kenc

    There's Fortress being developed by Guy Steele at Sun, and others (IBM
    has one as well).

    http://fortress.sunsource.net/

    Its certainly interesting. Whether it's good or not remains to be seen.

    []'s

    Rodrigo

    On 4/28/07, Charles Forsyth wrote:
    > This discussion made me curious whether good high-level languages are being developed for scientific computing.
    >


  2. Re: [9fans] speaking of kenc

    I'm working a bit on scalpl.
    I think it's a very nice idea. But there is almost no implementation.
    I'm working on a simple one... but I mostly have test code now.

    I wrote a list of links nice to read on it. Mainly for my own notes, but it may
    interest someone.
    http://vicerveza.homeunix.net/vicerw.../ScalPL_linker

    (Mostly, I want to write some kind of scheduler, even if not too fast, for
    running ScalPL plans)

    Je la Sat, Apr 28, 2007 at 04:45:56PM +0100, Charles Forsyth skribis:
    > This discussion made me curious whether good high-level languages are being developed for scientific computing.


  3. Re: [9fans] speaking of kenc

    On 4/28/07, Rodrigo Miranda wrote:
    > There's Fortress being developed by Guy Steele at Sun, and others (IBM
    > has one as well).
    >
    > http://fortress.sunsource.net/
    >


    IBM's is X10 (http://domino.research.ibm.com/comm/...x10.index.html)
    -- but like Fortress, its so new that there isn't much of an existing
    install base and it remains to be seen if there ever will be.

    Cray also has been working on a new langauge called Chapel
    (http://chapel.cs.washington.edu/)

    All three (Chapel, Fortress and X10) were developed for the DARPA HPCS program.

    -eric

  4. Re: [9fans] speaking of kenc

    On Sat, 2007-04-28 at 15:12 -0500, Eric Van Hensbergen wrote:
    > On 4/28/07, Rodrigo Miranda wrote:
    > > There's Fortress being developed by Guy Steele at Sun, and others (IBM
    > > has one as well).
    > >
    > > http://fortress.sunsource.net/
    > >

    >
    > IBM's is X10 (http://domino.research.ibm.com/comm/...x10.index.html)
    > -- but like Fortress, its so new that there isn't much of an existing
    > install base and it remains to be seen if there ever will be.
    >
    > Cray also has been working on a new langauge called Chapel
    > (http://chapel.cs.washington.edu/)
    >
    > All three (Chapel, Fortress and X10) were developed for the DARPA HPCS program.


    And the biggest issue all these languages will have to address would
    be -- scalability. How do you make it easier for compiler to generate
    code for 128+ core CPUs and 1000+ nodes cluster. That's a [multi]million
    dollar question, not how assignments and such are encoded in the source
    file.

    Thanks,
    Roman.


  5. Re: [9fans] speaking of kenc

    On Sat, 2007-04-28 at 02:09 -0700, ron minnich wrote:
    > On 4/26/07, Joel C. Salomon wrote:
    >
    > > That'd be a question for the HPC people; ron, do you miss complex types in 9c?

    >
    > No, but you're not going to like the reason. AFAIK nobody misses it,
    > because there may not be a single HPC app in widespread use that could
    > be run on Plan 9 today. We've been looking. Roman knows more than I do
    > on this issue.


    True. Although HPC seems to be changing these days. Ron, I'm just
    curious -- what's your definition of an HPC application, or even
    HPC market?

    Thanks,
    Roman.


  6. Re: [9fans] speaking of kenc

    good point. except, dennis was mostly ignored.
    why should mortals expect different results?

    i also don't understand your defence of _Bool. why
    add a type that behaves in a nonstandard manner?
    i see two disadvantages with this approach.
    1. the compiler must have special rules for a type
    with irregular rules.
    2. programmers must remember these special rules,
    increasing the chance of error.

    why would a typedef- or enum-based boolean type
    fail to serve this purpose, assuming one is convinced
    of the need for a boolean type.

    - erik

    On Fri Apr 27 12:23:36 EDT 2007, DAGwyn@null.net wrote:
    > If you guys really care about this stuff, you should participate
    > in the process, rather than sit on the sidelines and carp about
    > what others have done.


  7. Re: [9fans] speaking of kenc

    On 4/28/07, Charles Forsyth wrote:
    > This discussion made me curious whether good high-level languages are being developed for scientific computing.


    On the D newsgroups, there was some discussion of their (super
    powerful but also incredibly easy -- and buzzword compliant!) template
    mechanism being used to generate near optimal x87 code for linear
    algebra stuff.

    --Joel

  8. Re: [9fans] speaking of kenc

    > good point. except, dennis was mostly ignored.
    > why should mortals expect different results?


    perhaps we just need to speak lounder.


  9. Re: [9fans] speaking of kenc

    Or give up and go work for Google on AJAX.

    On 4/29/07, Tim Wiess wrote:
    > > good point. except, dennis was mostly ignored.
    > > why should mortals expect different results?

    >
    > perhaps we just need to speak lounder.
    >
    >


  10. Re: [9fans] speaking of kenc

    isn't mmx much faster tha x87 instructions these days?
    iirc, the latest intel chips can execute an mmx
    instruction in a single clock.

    - erik

    On Sat Apr 28 22:39:30 EDT 2007, joelcsalomon@gmail.com wrote:
    > On 4/28/07, Charles Forsyth wrote:
    > > This discussion made me curious whether good high-level languages are being developed for scientific computing.

    >
    > On the D newsgroups, there was some discussion of their (super
    > powerful but also incredibly easy -- and buzzword compliant!) template
    > mechanism being used to generate near optimal x87 code for linear
    > algebra stuff.
    >
    > --Joel


  11. Re: [9fans] speaking of kenc

    > > > This discussion made me curious whether good high-level languages are being
    > > > developed for scientific computing.

    > >
    > > On the D newsgroups, there was some discussion of their template
    > > mechanism being used to generate near optimal x87 code for linear
    > > algebra stuff.

    >
    > isn't mmx much faster tha x87 instructions these days?


    It was a proof-of-concept of the power of D's template and macro
    system; see .

    --Joel

    --
    It reverses the normal flow of conversation.
    > What's wrong with top-posting?
    > > Top-posting.
    > > > What's the biggest scourge on plain text email discussions?


  12. Re: [9fans] speaking of kenc

    >why would a typedef- or enum-based boolean type
    >fail to serve this purpose, assuming one is convinced
    >of the need for a boolean type.


    that's easy, and that's why one reason i picked on _Bool:
    it has a special new conversion rule (added
    to `the usual arithmetic conversions') that can't
    be done using typedefs or enums, namely that any
    non-zero value converts to 1. that is needed to
    work with the existing conditional structure.
    it's all done to satisfy all earlier right-thinking people,
    who thought that languages without a boolean type
    were clearly depraved, that this zero/non-zero stuff
    was just perverse, and therefore added boolean themselves (differently) using
    typedefs and enums; which didn't work correctly.
    they couldn't get that right, but they could fill in
    the right documents and do the political work to change
    the standard.

  13. Re: [9fans] speaking of kenc

    "erik quanstrom" wrote in message
    news:9ce51c75b076ab51a54e2c0352417143@coraid.com.. .
    > good point. except, dennis was mostly ignored.
    > why should mortals expect different results?


    To the extent that Dennis provided input to the C standards effort,
    he was certainly not ignored! Indeed, sizeof(char)==1 and
    restrict instead of noalias were both direct responses to his input.

    > i also don't understand your defence of _Bool. why
    > add a type that behaves in a nonstandard manner?


    It is just an arithmetic type with width at least 1, and
    conversion rules aimed at maximizing its Boolean nature.

    It is a pity that the result of relational expressions (for
    example) cannot be Boolean, for reasons of historical
    compatibility, but that's not the fault of _Bool (or plain
    "bool" as it is meant to be used via ).

    > why would a typedef- or enum-based boolean type
    > fail to serve this purpose, assuming one is convinced
    > of the need for a boolean type.


    There are a number of possible solutions. _Bool and
    were selected as the best proposal under
    the existing constraints (don't break all the existing code
    already using typedef int bool, allow C++ compatibility,
    etc.).

  14. Re: [9fans] speaking of kenc

    > There are a number of possible solutions. _Bool and
    > were selected as the best proposal under
    > the existing constraints (don't break all the existing code
    > already using typedef int bool, allow C++ compatibility,
    > etc.).


    What about the "don't add any more junk to the standard" solution? Or
    what about finding out if there is any problem that needs 'fixing'
    before looking for a solution?

    % grep 'Brian Reid' /sys/games/lib/fortunes
    Geez, you'd think standards were a continental disease or something. -
    Brian Reid

    To me they look like an 'incontinental' disease.

    uriel

  15. Re: [9fans] speaking of kenc

    > It is just an arithmetic type with width at least 1, and
    > conversion rules aimed at maximizing its Boolean nature.
    >
    > It is a pity that the result of relational expressions (for
    > example) cannot be Boolean, for reasons of historical
    > compatibility, but that's not the fault of _Bool (or plain
    > "bool" as it is meant to be used via ).


    this is different from how c has traditionally done types.
    c types mapped to what the hardware provides. unless
    you're working on a hc6508 or similar, you probablly don't
    have bit-wide memory access.

    it's more in the spirit of oberon, or pascal which have
    had more formally defined and machine independent
    types.

    - erik

  16. Re: [9fans] speaking of kenc

    On Mon, Apr 30, 2007 at 08:22:56PM -0400, erik quanstrom wrote:
    >
    > it's more in the spirit of oberon, or pascal which have
    > had more formally defined and machine independent
    > types.
    >


    Indeed. This (_Bool) does seem to be a solution in search of a
    problem. Is there anyone (other than a few refugees from Pascal)
    who believes that C suffers from its lack of a formal boolean
    type?

    jcs

  17. Re: [9fans] speaking of kenc

    2007/5/1, Jon Snader :
    > On Mon, Apr 30, 2007 at 08:22:56PM -0400, erik quanstrom wrote:
    > >
    > > it's more in the spirit of oberon, or pascal which have
    > > had more formally defined and machine independent
    > > types.
    > >

    >
    > Indeed. This (_Bool) does seem to be a solution in search of a
    > problem. Is there anyone (other than a few refugees from Pascal)
    > who believes that C suffers from its lack of a formal boolean
    > type?


    I've seen more than my fair share of tf = !!value; out there, which is
    just awful to read. It is very useful to have a defined way of
    determining the binary success or failure of an operation without
    having to understand whether -1, 1, 0, 38, or -129125 is success,
    failure, or indication of an error condition.

    > jcs


    --dho

  18. Re: [9fans] speaking of kenc

    >
    > I've seen more than my fair share of tf = !!value; out there, which is
    > just awful to read. It is very useful to have a defined way of
    > determining the binary success or failure of an operation without
    > having to understand whether -1, 1, 0, 38, or -129125 is success,
    > failure, or indication of an error condition.


    i'm not sure why a boolean type fixes this problem. using _Bool
    in this case shoves some implicit magic into '=' that wasn't there
    before and doesn't map at all to how the machine really works.

    what's wrong with this?

    if(tf != 0)
    return 0;
    return -1;

    - erik

  19. Re: [9fans] speaking of kenc

    2007/5/1, erik quanstrom :
    > >
    > > I've seen more than my fair share of tf = !!value; out there, which is
    > > just awful to read. It is very useful to have a defined way of
    > > determining the binary success or failure of an operation without
    > > having to understand whether -1, 1, 0, 38, or -129125 is success,
    > > failure, or indication of an error condition.

    >
    > i'm not sure why a boolean type fixes this problem. using _Bool
    > in this case shoves some implicit magic into '=' that wasn't there
    > before and doesn't map at all to how the machine really works.
    >
    > what's wrong with this?
    >
    > if(tf != 0)
    > return 0;
    > return -1;


    Nothing is wrong with that, but the point is that it isn't always that
    simple. UNIX in general has different meanings in different places.
    This isn't C's fault, but not having a boolean type has contributed to
    this (ab)use of the meaning of magic integers. Sometimes non-zero is
    true and zero is false. Sometimes 0 is true and non-zero is false.
    Sometimes 0 is true and non-zero indicate differing levels of
    falseness.

    It doesn't fix these problems but it discourages them from happening
    in the future.

    Anyway, indeed, this is a C language discussion, so to not be
    completely off topic, what I typically do in Plan 9 is:

    enum {
    true,
    false,
    };

    (Yes, I know this still has nothing to do with Plan 9, but I tried )

    > - erik


    I'll digress from this thread, because I'm certainly not the best
    person to determine what parts of C are good nor bad. Just to bitch
    about my own use. I think boolean types are a good thing. But I won't
    pollute this list further (and sorry for the current level of
    pollution)

    --dho

  20. Re: [9fans] speaking of kenc

    On 5/1/07, Jon Snader wrote:

    > Is there anyone (other than a few refugees from Pascal)
    > who believes that C suffers from its lack of a formal boolean
    > type?


    i think that's the wrong question. i know plenty of people who believe
    C suffers from its lack of a formal boolean type, but the correct
    question for folks like standards bodies (and the peanut gallery here,
    for whatever we matter) is whether adding it (in any particular form)
    justifies the cost (in terms of added complexity, architectural
    mismatch, monetary cost of implementation, or whatever criteria one
    chooses) of adding it to the standard.

    personally, i think any advantages of _Bool over the plethora of
    ad-hoc implementations are not worth the oddities and discongruity
    that go with this implementation. as i'm not a C compiler implementor
    and don't generally miss boolean types myself, i'm not going to
    complain too much.

+ Reply to Thread
Page 2 of 7 FirstFirst 1 2 3 4 ... LastLast