Jump to page: 1 2
Thread overview
DConf 2013 Day 2 Talk 6: Higgs, an experimental JIT compiler written in D by Maxime Chevalier-Boisvert
Jun 07, 2013
Graham Fawcett
Jun 07, 2013
Nick Sabalausky
Jun 08, 2013
bearophile
Jun 08, 2013
Ali Çehreli
Jun 08, 2013
Walter Bright
Jun 08, 2013
bearophile
Jun 08, 2013
Andrej Mitrovic
Jun 09, 2013
Marco Leise
Jun 09, 2013
Walter Bright
Jun 09, 2013
Jonathan M Davis
Jun 09, 2013
Peter Williams
Jun 14, 2013
Rob T
Jun 13, 2013
bearophile
Jun 09, 2013
Jonathan M Davis
June 07, 2013
Reddit: http://www.reddit.com/r/programming/comments/1fv4zx/dconf_2013_day_2_talk_6_higgs_an_experimental_jit/

Hackernews: https://news.ycombinator.com/item?id=5839283

Twitter: https://twitter.com/D_Programming/status/343019685744369664

Facebook: http://facebook.com/dlang.org/posts/652988644714820

Youtube: http://youtube.com/watch?v=hJUNHX0vakI

Please drive discussions on the social channels, they help D a lot.


Andrei
June 07, 2013
On Friday, 7 June 2013 at 15:05:15 UTC, Andrei Alexandrescu wrote:
> Reddit: http://www.reddit.com/r/programming/comments/1fv4zx/dconf_2013_day_2_talk_6_higgs_an_experimental_jit/
>
> Hackernews: https://news.ycombinator.com/item?id=5839283
>
> Twitter: https://twitter.com/D_Programming/status/343019685744369664
>
> Facebook: http://facebook.com/dlang.org/posts/652988644714820
>
> Youtube: http://youtube.com/watch?v=hJUNHX0vakI
>
> Please drive discussions on the social channels, they help D a lot.
>
>
> Andrei

I've also cross-posted it to "/r/d_language": http://redd.it/1fv8y2

/r/programming is great for PR and engagement, but I like /r/d_language for its very high signal:noise (for one thing, it's easier to find past posts!).

/r/d_language currently has 857 subscribers (http://stattit.com/r/d_language/). Looking forward to some growth there, as all these videos attract interested newcomers.

Regards,
Graham
June 07, 2013
On Fri, 07 Jun 2013 11:05:14 -0400
Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:

> Reddit: http://www.reddit.com/r/programming/comments/1fv4zx/dconf_2013_day_2_talk_6_higgs_an_experimental_jit/
> 
> Hackernews: https://news.ycombinator.com/item?id=5839283
> 
> Twitter: https://twitter.com/D_Programming/status/343019685744369664
> 
> Facebook: http://facebook.com/dlang.org/posts/652988644714820
> 
> Youtube: http://youtube.com/watch?v=hJUNHX0vakI
> 
> Please drive discussions on the social channels, they help D a lot.
> 
> 
> Andrei

Torrents up, and list of links updated: http://semitwist.com/download/misc/dconf2013/

June 08, 2013
Andrei Alexandrescu:

> http://www.reddit.com/r/programming/comments/1fv4zx/dconf_2013_day_2_talk_6_higgs_an_experimental_jit/

A nice talk. Some comments on the slides:

------------------------

Slide 34:

> - If you know C++, you can write D code
> - Similar enough, easy adaptation
> - Slightly less verbose

If you write functional-style D code that uses UCFS a lot, the code is different from the usual C++ code and much shorter (and slower).

------------------------

Slide 53:

> Needed template with list of integer arguments

I agree that arrays as template arguments is a natural enhancement for D.

------------------------

Slide 57:

> Unit Tests Blocks
> - Don't support naming unit tests
> - Failing tests not reported at the end
> - The main function is still called normally
>   Higgs starts a REPL by default
> - No way to select which tests are run
> - Tempted to write our own framework

I agree that in the built-in unittests some essential features are missing.

------------------------

Slide 58:

static this()
{
    codeGenFns[&SET_TRUE]       = &gen_set_true;
    codeGenFns[&SET_FALSE]      = &gen_set_false;
    codeGenFns[&SET_UNDEF]      = &gen_set_undef;
    codeGenFns[&SET_MISSING]    = &gen_set_missing;
    codeGenFns[&SET_NULL]       = &gen_set_null;
...
}

==>

static this()
{
    codeGenFns = [&SET_TRUE:    &gen_set_true,
                  &SET_FALSE:   &gen_set_false,
                  &SET_UNDEF:   &gen_set_undef,
                  &SET_MISSING: &gen_set_missing,
                  &SET_NULL:    &gen_set_null,
    ...];
}

(That associative array can even be generated with a string mixin, if there's enough RAM).

------------------------

Slide 64:

> Precompile most library code used in CTFE

Where to put such compiled code?

------------------------

Slide 67:

- D integer types have guaranteed sizes, but
  they're not obvious from the name
- Why not have int8, uint8, int32, uint32, etc. in
  default namespace, encourage their use?

I agree. It's hard to guess the size and signedness of types as byte, ubyte, wchar, dchar. I prefer names that are more clear.

Bye,
bearophile
June 08, 2013
On 06/08/2013 02:23 PM, bearophile wrote:

> Slide 67:
>
> - D integer types have guaranteed sizes, but
>    they're not obvious from the name
> - Why not have int8, uint8, int32, uint32, etc. in
>    default namespace, encourage their use?
>
> I agree. It's hard to guess the size and signedness of types as byte,
> ubyte, wchar, dchar. I prefer names that are more clear.

There is std.stdint but it is not used much:

  http://dlang.org/phobos/std_stdint.html

Ali

June 08, 2013
On 6/8/2013 2:23 PM, bearophile wrote:
> - D integer types have guaranteed sizes, but
>    they're not obvious from the name
> - Why not have int8, uint8, int32, uint32, etc. in
>    default namespace, encourage their use?
>
> I agree. It's hard to guess the size and signedness of types as byte, ubyte,
> wchar, dchar. I prefer names that are more clear.

It would only be a trivial problem for 5 minutes, only for ex-C/C++ programmers who are used to suffering under variable sized ints, and will never be a problem again.

Is it really a problem to guess the size of 'byte'? Or that 'ubyte' is unsigned? Come on, bearophile!

And frankly, int32, long64, etc., have a large 'yech' factor for me.

Besides, if you really do want them,

    import core.stdc.stdint;


June 08, 2013
Walter Bright:

> It would only be a trivial problem for 5 minutes, only for ex-C/C++ programmers who are used to suffering under variable sized ints, and will never be a problem again.
>
> Is it really a problem to guess the size of 'byte'? Or that 'ubyte' is unsigned? Come on, bearophile!

The size of "byte" is easy, it's 1 byte, but if you ask me a byte is unsigned. I have learnt to be careful with byte/ubyte in D and now I think I don't use one for the other by mistake, but I have had some bugs caused by them.

It took me two or three years to to remember what's the length of dchar and wchar.

New D programmer should not be need to learn such arbitrary naming scheme, inherited from C++ :-)


> And frankly, int32, long64, etc., have a large 'yech' factor for me.

I think you meant to say int32 and int64 :-)

Bye,
bearophile
June 08, 2013
On 6/9/13, bearophile <bearophileHUGS@lycos.com> wrote:
> The size of "byte" is easy, it's 1 byte, but if you ask me a byte is unsigned. I have learnt to be careful with byte/ubyte in D

You, me, and Don, and probably others as well. It's easy to forget though that bytes are signed.
June 09, 2013
On 6/8/2013 4:08 PM, bearophile wrote:
> It took me two or three years to to remember what's the length of dchar and wchar.

I don't believe that!

> New D programmer should not be need to learn such arbitrary naming scheme,
> inherited from C++ :-)

It's also seen in other obscure languages like Java and C#.
June 09, 2013
On Saturday, June 08, 2013 15:55:17 Walter Bright wrote:
> On 6/8/2013 2:23 PM, bearophile wrote:
> > - D integer types have guaranteed sizes, but
> > 
> >    they're not obvious from the name
> > 
> > - Why not have int8, uint8, int32, uint32, etc. in
> > 
> >    default namespace, encourage their use?
> > 
> > I agree. It's hard to guess the size and signedness of types as byte, ubyte, wchar, dchar. I prefer names that are more clear.
> 
> It would only be a trivial problem for 5 minutes, only for ex-C/C++ programmers who are used to suffering under variable sized ints, and will never be a problem again.
> 
> Is it really a problem to guess the size of 'byte'? Or that 'ubyte' is unsigned? Come on, bearophile!
> 
> And frankly, int32, long64, etc., have a large 'yech' factor for me.
> 
> Besides, if you really do want them,
> 
>      import core.stdc.stdint;

If I had been designing the language, I might have gone for int8, uint8, int16, uint16, etc. (in which case, _all_ of them would have had sizes with no aliases without - it seems overkill to me to have both), but I also don't think that it's a big deal for them to not have the numbers either, and I don't understand why anyone would think that it's all that hard to learn and remember what the various sizes are - especially when Java did something very close to what we did, and programmers seem to be fine with that. And the signed vs unsigned integers should be generally clear given that all of the integral types which are unsigned start with u and all those that don't, don't. The only exception is size_t which is already a bit of an oddity among the others, since its size can vary.

So, while some people might find the sizes of the types to be a little confusing at first, I find it very hard to believe that anyone finds them to be confusing for long. It's all quite straightforward on the whole.

- Jonathan M Davis
« First   ‹ Prev
1 2