Re: DConf 2020 Early-Bird Registration & Submission Deadlines

[Rory McGuire via Digitalmars-d-announce]

On Mon, Jan 27, 2020 at 2:05 PM Mike Parker via Digitalmars-d-announce <
digitalmars-d-announce@puremagic.com> wrote:

> [snip]
> I'll open registration through PayPal once the official
> announcement goes out on the blog and social media. Both
> registration options will be available at dconf.org.
> [snip]


Hi Mike,

There is a typo at:
*while enhanching the D ecosystem   *

R

Re: DCompute - Native heterogeneous computing for D - is here!

[Rory McGuire via Digitalmars-d-announce]

On Sun, Feb 26, 2017 at 10:37 AM, Nicholas Wilson via
Digitalmars-d-announce  wrote:
> DCompute is an extension to LDC capable of generating code (with no language
> changes*) for NVIDIA's NVPTX for use with CUDA, SPIRV for use with the
> OpenCL runtime, and of course the host, all at the same time! It is also
> possible to share implementation of algorithms across the host and device.
> This will enable writing kernels in D utilising all of D's meta programming
> goodness across the device divide and will allow launching those kernels
> with a level of ease on par with CUDA's <<<...>>> syntax. I hope to be
> giving a talk at DConf2017 about this ;), what it enables us to do, what
> still needs to be done and future plans.
>

Awesome! Been wanting this feature since ldc started catching up to dmd.

Re: Android LDC in a Container

[Rory McGuire via Digitalmars-d-announce]

On Mon, Feb 20, 2017 at 1:16 AM, Nick Sabalausky (Abscissa) via
Digitalmars-d-announce  wrote:
> I haven't actually had a chance to try either this or Joakims's stuff by
> itself, although I am interested. Can you describe how this repo simplifies
> things?

Using the docker image just makes it so that you don't have to do the
builds yourself. The docker image works on multiple OS. I've built
Joakim's stuff myself and used the docker image and the docker image
saves time if you're just wanting to take a quick look.

>
> Also, using this stuff, is there a way for the D application to call into
> Android's API?

Regarding Android's API there is the NDK. NDK exposes a cut down
version of the Linux/posix APIs and JNI for interfacing with the VM,
the app still runs in its own sandbox and you can call Java code or
have Java call your code. DlangUI has some android code. Check out
native-activity [0] for accessing the screen and sensors natively (it
seems to be the most popular native example.

[0]: https://github.com/googlesamples/android-ndk/tree/master/native-activity

Re: Call for arms: Arch Linux D package maintenance

[Rory McGuire via Digitalmars-d-announce]

On Thu, Feb 16, 2017 at 6:47 PM, Vladimir Panteleev via
Digitalmars-d-announce  wrote:
> On Wednesday, 1 February 2017 at 12:47:51 UTC, Dicebot wrote:
>>
>> As I have previously announced
>> (http://forum.dlang.org/post/o6fbbu$1qli$1...@digitalmars.com), I am stepping
>> down from maintaining Arch Linux packages for D.
>
>
> Hi, wondering what the outcome of this was.
>
> Also, how big is the maintenance burden? Is there more to it than a version
> number bump & push on each release? Perhaps it could be automated or
> integrated into the release process.
>
> FWIW, I've got a few packages on AUR:
> https://aur.archlinux.org/packages/?SeB=m=CyberShadow

Hi,

I am planning on asking to become TU for the dlang packages in
community. I've been building and working with the current packages
and making my own packages to make sure I know what I'm getting in to.
LDC and GDC are matched with the system versions of llvm and gcc. If I
can get TU approval I will put time in to these packages and hopefully
make some Arch tools that use dlang to try and promote it more.
To learn makepkg and nampac etc I built this [0], it is a set of
PKGBUILD files that are loosely based on the way I use multiple
official dmd compilers on my dev box. Some of my customers use older
version of Vibe that do not build on current dmd. I actually normally
use /usr/local/ and not /usr/lib for my dmd installation. It also has
a little utility for switching between compilers versions, similar to
archlinux-java.

[0]: https://github.com/rjmcguire/archlinux-dmd

Re: Call for arms: Arch Linux D package maintenance

[Rory McGuire via Digitalmars-d-announce]

On Thu, Feb 2, 2017 at 1:29 PM, Dicebot via Digitalmars-d-announce <
digitalmars-d-announce@puremagic.com> wrote:

> On Wednesday, 1 February 2017 at 18:32:48 UTC, Rory McGuire wrote:
>
>> I use arch and D every day. I'm willing to volunteer. I keep up to date
>> with all releases and keep multiple dmd versions. If I'm maintaining the
>> packages I'd use them (if I can still switch versions of dmd).
>>
>
> Are you familiar with the PKGBUILD system? Please ping me via
> pub...@dicebot.lv
>

pinged.

Re: Call for arms: Arch Linux D package maintenance

[Rory McGuire via Digitalmars-d-announce]

On Wednesday, February 1, 2017, Dicebot via Digitalmars-d-announce <
digitalmars-d-announce@puremagic.com> wrote:

> As I have previously announced
> (http://forum.dlang.org/post/o6fbbu$1qli$1...@digitalmars.com), I am
> stepping down from maintaining Arch Linux packages for D.
>
> That means there are 3 possibilities:
>
> - No one will adopt them and all packages will be moved to AUR
> - Some existing Trusted User decided to adopt them
> - Someone from D community decides to become Trusted User and adopts them
>
> First option is definitely the worst one and I don't see any enthusiasm
> regarding second option from existing TUs. Is there anyone willing to
> volunteer for the option three?
>
> I promise all the guidance and help in submitting TU application and
> figuring out maintenance process but there does need to be a volunteer ;)
>
>
I use arch and D every day. I'm willing to volunteer. I keep up to date
with all releases and keep multiple dmd versions. If I'm maintaining the
packages I'd use them (if I can still switch versions of dmd).

Re: DIP 1003: remove `body` as a keyword

[Rory McGuire via Digitalmars-d-announce]

On Sat, Dec 10, 2016 at 4:43 PM, Basile B. via Digitalmars-d-announce <
digitalmars-d-announce@puremagic.com> wrote:

> On Saturday, 10 December 2016 at 13:49:09 UTC, Basile B. wrote:
>
>> On Monday, 28 November 2016 at 02:17:20 UTC, Dicebot wrote:
>>
>>> On 11/24/2016 05:29 PM, WM.H wrote:
>>>
 On Saturday, 19 November 2016 at 21:16:15 UTC, Dicebot wrote:

> DIP 1003 is merged to the queue and open for public informal feedback.
>
> PR: https://github.com/dlang/DIPs/pull/48
> Initial merged document:
> https://github.com/dlang/DIPs/blob/master/DIPs/DIP1003.md
>
> If you want the change to be approved and have ideas how to improve it
> to better match on https://github.com/dlang/DIPs/
> blob/master/GUIDELINES.md and existing published reviews - please
> submit new PR with editorial and ping original author.
>

 This DIP fixes the problem for "body" but not for the other keywords.
 After all the problem may exist for other keywords. Was a new pragma
 considered ? For example an identifier alias.

 pragma(idAlias, "body", "body_" )

>>>
>>> AFAIU, the point of this DIP is that "body" is standing out from other
>>> keywords being used only in one very specific context and being a very
>>> common english word at the same time. Your proposal has a completely
>>> different (and much more drastic) approach.
>>>
>>
>> Yes. But while it's clear that "body" is a keyword that's less related to
>> programming languages than the others (i.e more usable as identifier), it's
>> not actually that mad to imagine a generic approach. For example Object
>> Pascal has such a feature:
>>
>> http://wiki.freepascal.org/FPC_New_Features_2.6.0#Support_
>> for_.26-escaping_of_keywords
>>
>> which is not well known, as I've myself discovered this just 3 minutes
>> ago.
>> In D there would be the "#" token that's not really used, which could
>> serve to escape keywords, while still considering them as identifier when
>> it's needed, e.g
>>
>> struct Body{}
>> Body #body;
>> writeln("'", #body.stringof, "'");
>>
>> would output: 'body'
>>
>
> By the way a pragma was a bad idea. Pragmas are optionally supported by a
> compiler. An escape symbol is by far better. Whatever is the compiler we
> always want the same result.
>
> Any chance to get "Cauterite" thoughts on the option that is to have a
> token used to escape a keyword, so that the kw can be used as identifier ?
>
> The initial DIP is too specialized, however it shows a real problem:
>
> What if one day someone wants
>
> enum FlagsModifiedByAsmCmp {of, if, zf, cf} ?
> function Function;
>
> With an escape it would always work
>
> enum FlagsModifiedByAsmCmp {of, #if, zf, cf}
> #function Function;
>
> The problem of the suffix "_", as proposed in D style guide, is that it's
> also a valid identifier character, while "#" is not. And the best is that #
> role is already for special token sequences !
> - # = token for special token sequence
> - body = token
> => #body is a special token sequence.
>
> The only thing to change is that currently a special token sequence takes
> a full line...but seriously that's a minor change (since there's no special
> token sequence in D... #line is obsolete and not used anymore).
>

Why is #line obsolete? I use it a lot in string mixins to make the correct
line numbers show.

Thanks!

Re: Mir Random announce - Professional RNGs

[Rory McGuire via Digitalmars-d-announce]

On Sat, Nov 26, 2016 at 1:14 AM, Ilya Yaroshenko via
Digitalmars-d-announce  wrote:
>
> https://github.com/libmir/mir-random
> http://docs.random.dlang.io/latest/index.html


Like the betterC use case. Nice API.

first example from the docs:

import mir.random.engine.xorshift;
auto gen = Xorshift(1);
auto s = gen.rand!short;
auto n = gen.rand!ulong;

Re: Battle-plan for CTFE

[Rory McGuire via Digitalmars-d-announce]

On Mon, Oct 24, 2016 at 8:17 AM, Stefam Koch via Digitalmars-d-announce <
digitalmars-d-announce@puremagic.com> wrote:

> On Monday, 24 October 2016 at 05:57:42 UTC, Stefam Koch wrote:
>
>> On Sunday, 16 October 2016 at 00:27:50 UTC, Uplink_Coder wrote:
>>
>>>
>>> Little update here:
>>> The LLVM backend is almost on feature parity.
>>> Meaning that that soon the new CTFE engine is a real jit.
>>> In the process I discoverd quite a few horrible bugs and inconsistency
>>> in the API.
>>> I am quite astonished that it ever ran before :)
>>>
>>
>> Hey Guys,
>>
>> I am still dealing with the many bugs that have surfaced.
>> It is really crazy how something so broken could have worked that well.
>>
>
So true of computer programming. Particularly if the documentation for the
API is awol.


>
>> Originally I planned adding a ton of features, but that can only happen
>> If the fundamental issues are fixed.
>>
>
> However at the D Meetup in Berlin, I have gotten some positive feedback
> concerning my ByteCode-Layer.
> Once the bugs are fixed and the edges are smoothed over I can see finding
> it's way into other parts of the compiler.
>
>
Cool, thanks for the feedback.

Re: Battle-plan for CTFE

[Rory McGuire via Digitalmars-d-announce]

On 19 Oct 2016 17:46, "Stefan Koch via Digitalmars-d-announce" <
digitalmars-d-announce@puremagic.com> wrote:
>
> On Wednesday, 19 October 2016 at 07:11:24 UTC, Nordlöw wrote:
>>
>> On Sunday, 25 September 2016 at 20:47:41 UTC, Stefan Koch wrote:
>>>
>>> If all goes well there will be a separate nightly release build from
the newCTFE branch,  sometime in October.
>>>
>>> I hope to get alpha bug reports that way.
>>
>>
>> Have you benchmarked CTFE-heavy projects like Pegged?
>
>
> It is not yet able to handle pegged.
> And I suspect alot of slowness is caused by templates not by CTFE.

diet-ng is probably a better "complex" benchmark.

Re: code-d 0.12.0 - The user friendly release (code-d for noobs)

[Rory McGuire via Digitalmars-d-announce]

On Wed, Oct 5, 2016 at 3:22 PM, WebFreak001 via Digitalmars-d-announce <
digitalmars-d-announce@puremagic.com> wrote:

> On Wednesday, 5 October 2016 at 07:44:00 UTC, Rory McGuire wrote:
>
>> On Wed, Oct 5, 2016 at 7:53 AM, Suliman via Digitalmars-d-announce <
>> digitalmars-d-announce@puremagic.com> wrote:
>>
>> Please, add Sublime support
>>>
>>>
>> @WebFreak001: I too am curious as to why you chose to support two obscure
>> editors rather than Sublime as your first supported editors. (Obscure
>> compared to Sublime anyway).
>>
>> First thing that comes to mind is Sublime is closed source, then one
>> thinks why not limetext, then I realise that feels like a tip of the hat to
>> #golang which feels like betrayal in some ways :D.
>>
>> Really like what you are doing with workspace-d regardless of the Sublime
>> Text support.
>>
>> PS: is it because those two editors are JS based?
>> PS2: dml completion...nice! Really want to try that out since dlangui got
>> console support.
>>
>
> well having JS support is great because it means I don't need to port my
> code, but I didn't add support to sublime because I never used it.
> Especially the fact that you can buy it makes me wanna not get it becuase
> that means the free version has some disadvantages to the paid version. And
> its just a simple text editor, not really wanting to pay for that.
> Especially for that price.
>


I haven't used anything else since I started using Sublime because of
CTRL+d (multi select the next match of my current selection) and fuzzy
search of the available commands.

Re: Battle-plan for CTFE

[Rory McGuire via Digitalmars-d-announce]

On Sun, Sep 25, 2016 at 10:47 PM, Stefan Koch via Digitalmars-d-announce <
digitalmars-d-announce@puremagic.com> wrote:

> On Sunday, 25 September 2016 at 18:21:27 UTC, Rory McGuire wrote:
>
>>
>> :D congrats!
>>
>
> I appreciate it.
> If all goes well there will be a separate nightly release build from the
> newCTFE branch,  sometime in October.
>
> I hope to get alpha bug reports that way.
>
> Also I am now starting experimentation with actual JIT to make sure my API
> and ABI definitions are not bogus.
> (For the record an earlier design made slices impossible) Luckily I
> spotted this before I went to far with it.
>
> Unfortunately many basic features are still very brittle or completely
> dysfunctional.
> (Such as function calls or structs.)
> Again I apologize for the delay.
> My adventures in template-land, were quite time consuming.
> Although arguably with interesting results.
>
> If you have any questions regarding my work with the DMD, please ask away.
>
> Greetings,
> Stefan
>

No worries, I've been watching this space for over a decade. I really
believe you are working on one of the most important parts of IT for the
next decade. I am planning/making a library that uses CTFE extensively and
feel much more confident about it purely because of your work on getting
CTFE performance to be a non-issue.

R

Re: code-d 0.12.0 - The user friendly release (code-d for noobs)

[Rory McGuire via Digitalmars-d-announce]

On Wed, Oct 5, 2016 at 7:53 AM, Suliman via Digitalmars-d-announce <
digitalmars-d-announce@puremagic.com> wrote:

> Please, add Sublime support
>

@WebFreak001: I too am curious as to why you chose to support two obscure
editors rather than Sublime as your first supported editors. (Obscure
compared to Sublime anyway).

First thing that comes to mind is Sublime is closed source, then one thinks
why not limetext, then I realise that feels like a tip of the hat to
#golang which feels like betrayal in some ways :D.

Really like what you are doing with workspace-d regardless of the Sublime
Text support.

PS: is it because those two editors are JS based?
PS2: dml completion...nice! Really want to try that out since dlangui got
console support.

Re: Diet-NG 1.0.0 released

[Rory McGuire via Digitalmars-d-announce]

On Sun, Sep 25, 2016 at 10:46 AM, Sönke Ludwig via Digitalmars-d-announce <
digitalmars-d-announce@puremagic.com> wrote:

> Am 24.09.2016 um 15:04 schrieb WebFreak001:
>
>> On Friday, 23 September 2016 at 11:47:23 UTC, Sönke Ludwig wrote:
>>
>>> The Diet template language is aimed at providing a way to define
>>> procedurally generated HTML/XML pages (or other output formats), with
>>> minimal visual noise. Syntax and feature set are heavily inspired by
>>> pug , but instead of JavaScript, all expressions
>>> and statements are D statements, and everything that can be done at
>>> compile-time is done at compile-time.
>>>
>>
>> Cool, does it also work for generating diet -> html at runtime without
>> inline D code? Would be pretty neat to have for static pages.
>>
>
> Not included, but that would be relatively trivial to implement by taking
> the diet.html module and modifying it to output HTML instead of D code. It
> would actually be really easy to build a Jade/pug compiler that way.
>

If you just want to do runtime jade -> html right now you can use my Jade
implementation [0]. I don't think it has any users though so your mileage
may vary. Even I use Diet :)

R
[0] https://github.com/rjmcguire/jaded

Re: Release candidate vibe.d 0.7.30-rc.1

[Rory McGuire via Digitalmars-d-announce]

On Tue, Oct 4, 2016 at 12:01 AM, Jack Applegame via Digitalmars-d-announce <
digitalmars-d-announce@puremagic.com> wrote:

> On Thursday, 29 September 2016 at 13:44:53 UTC, Sönke Ludwig wrote:
>
>>
>> If no new issues come up, the 0.7.30 release is scheduled for the 9th of
>> October.
>>
>> Please consider https://github.com/rejectedsoftware/vibe.d/issues/1583
>
>
Would it be okay for us to merge [0] as an example?

[0] https://github.com/rejectedsoftware/vibe.d/issues/1561

Re: Battle-plan for CTFE

[Rory McGuire via Digitalmars-d-announce]

On Sun, Sep 25, 2016 at 4:47 PM, Stefan Koch via Digitalmars-d-announce <
digitalmars-d-announce@puremagic.com> wrote:

> On Tuesday, 20 September 2016 at 05:06:57 UTC, Nordlöw wrote:
>
>> On Monday, 19 September 2016 at 10:07:06 UTC, Stefan Koch wrote:
>>
>>> Compiling all of phobos does not crash my engine anymore!
>>>
>>
>> Great work! Keep up still!
>>
>
> I am proud to announce,
> (and slightly embarssed because it took to long)
>
> that the following code can now be executed using the new CTFE engine :
>
> string fn(bool b)
> {
> return b ? "true" : "false";
> }
> static assert(fn(true) == "true");
> static assert(fn(false) == "false");
>
> although this seems trivial it took me about 3 months to get to this point.
> I believe from here on the road will be less steep.
>
>

:D congrats!

Re: mysql-native v0.1.5

[Rory McGuire via Digitalmars-d-announce]

On Sat, Sep 17, 2016 at 3:00 PM, Nick Sabalausky via Digitalmars-d-announce
<digitalmars-d-announce@puremagic.com> wrote:

> On 09/16/2016 02:41 PM, Rory McGuire via Digitalmars-d-announce wrote:
>
>> On 11 Sep 2016 16:57, "Nick Sabalausky via Digitalmars-d-announce" <
>> digitalmars-d-announce@puremagic.com> wrote:
>>
>>> [snip]
>>> ... a top priority for mysqln-native at this point.
>>>
>>
>> Hi Nick is that a typo or are you working on a completely different
>> library? mysqln-native?
>>
>>
> Typo. Sometimes mysql-native is referred to shorthand as "mysqln", so I
> guess my fingers just stuttered ;)
>
>
:) cool thanks. Nice to know you are taking care of such an important part
of our language's ecosystem.

R

Re: mysql-native v0.1.5

[Rory McGuire via Digitalmars-d-announce]

On 11 Sep 2016 16:57, "Nick Sabalausky via Digitalmars-d-announce" <
digitalmars-d-announce@puremagic.com> wrote:
>[snip]
>... a top priority for mysqln-native at this point.

Hi Nick is that a typo or are you working on a completely different
library? mysqln-native?

Re: Beta D 2.071.2-b5

[Rory McGuire via Digitalmars-d-announce]

On Wed, Sep 14, 2016 at 4:04 PM, Ali Çehreli via Digitalmars-d-announce <
digitalmars-d-announce@puremagic.com> wrote:

> On 09/14/2016 05:58 AM, Johan Engelen wrote:
>
>> On Wednesday, 14 September 2016 at 12:16:51 UTC, Martin Nowak wrote:
>>
>>> Fifth and hopefully last beta for the 2.071.2 release.
>>>
>>> This comes with two more fixes for Issue 16031 and 16460.
>>>
>>
>> LDC master is up-to-date with 2.071.2-b5!
>>
>
> Wow! LDC is just 42 minutes behind dmd. I wonder when it will pass it. :p
>
> Ali
>
>
:D, this does make me wonder why the ddmd frontend is inside the compiler
repos.

Re: DlangUI 0.9.0: Console backend added

[Rory McGuire via Digitalmars-d-announce]

On Wed, Sep 14, 2016 at 3:11 PM, ketmar via Digitalmars-d-announce <
digitalmars-d-announce@puremagic.com> wrote:

> On Wednesday, 14 September 2016 at 13:08:18 UTC, Rory McGuire wrote:
>
>> Screenshots here are what can be done with terminal/ascii:
>> http://caca.zoy.org/wiki/libcaca
>>
>
> still, you can't use shading charaters to color text, so 16 colors for
> text output won't look that impressive. ;-)
>

:) true

Re: DlangUI 0.9.0: Console backend added

[Rory McGuire via Digitalmars-d-announce]

On Wed, Sep 14, 2016 at 3:04 PM, ketmar via Digitalmars-d-announce <
digitalmars-d-announce@puremagic.com> wrote:

> On Wednesday, 14 September 2016 at 05:58:51 UTC, Vadim Lopatin wrote:
>
>> Thank you!
>> Now dlangui terminal mode supports only 16 colors.
>> Some refactoring is required to support RGB colors.
>>
>
> in my editor i'm simply using rgb in [0..255] range, and mapping that to
> what terminal has. yet it is probably not the best way to make something
> nice looking when only 16 colors are available. heh, i should try and see
> how it will look like! ;-)
>

Screenshots here are what can be done with terminal/ascii:
http://caca.zoy.org/wiki/libcaca

Re: Beta D 2.071.2-b4

[Rory McGuire via Digitalmars-d-announce]

On Wed, Sep 14, 2016 at 9:30 AM, Ali Çehreli via Digitalmars-d-announce <
digitalmars-d-announce@puremagic.com> wrote:

> On 09/12/2016 12:47 AM, Martin Nowak wrote:
>
> > This comes with a different fix for Issue 15907 than 2.071.2-b3.
>
> Kisses and hugs! :)
>
> Ali
>
>
+1, this is _way_ better.

Re: DlangUI 0.9.0: Console backend added

[Rory McGuire via Digitalmars-d-announce]

On Tue, Sep 13, 2016 at 2:29 PM, Vadim Lopatin via Digitalmars-d-announce <
digitalmars-d-announce@puremagic.com> wrote:

> On Tuesday, 13 September 2016 at 12:18:19 UTC, Bauss wrote:
>
>> Good job, but why do people still use tinypic in 2016, when things like
>> imgur exist that are a 1000 times faster to use, no dirty ads and images
>> won't magically be taken down someday.
>>
>
> Screenshots on imgur: http://imgur.com/a/eaRiT
>


nice, much better image site..

Did you get my post about the keyboard thing?
You can test it by running dub --single filename.d

output looks like:
kp: [27, 91, 49, 59, 50, 68]
kp: [27, 91, 49, 59, 53, 68]
kp: [27, 91, 49, 59, 51, 68]
kp: [27, 91, 68]

if I press:
shift+Left
ctrl+Left
alt+left
left



BTW: love what you are doing with dlangui. Are you a one person team?

Re: DlangUI 0.9.0: Console backend added

[Rory McGuire via Digitalmars-d-announce]

On Fri, Sep 9, 2016 at 2:20 PM, Vadim Lopatin via Digitalmars-d-announce <
digitalmars-d-announce@puremagic.com> wrote:

> On Friday, 9 September 2016 at 11:56:11 UTC, Adam D. Ruppe wrote:
>
>> On Friday, 9 September 2016 at 11:21:07 UTC, Vadim Lopatin wrote:
>>
>>> Now it's possible to build DlangUI apps to run in console (Linux,
>>> Windows).
>>>
>>
>> Very nice.
>>
>> Part of key modifiers do not work in linux console.
>>> Mouse events working ok.
>>>
>>
>> Which parts are you having trouble with? I have implemented a lot of this
>> for my terminal.d and might be able to help.
>>
>
> Keyboard support on Linux terminals seems most difficult.
>

Hi Vadim, [0] is a short raw keyboard example, uses Jason's io, libasync
and termios:

https://gist.github.com/rjmcguire/58f3fd3d5f0934dc351cd143c1b0c880

It has quite a lot of comments, it is an experiment for keyboard io, so I
guess it might fit into dlangui nicely.

R

Re: [OT] LLVM 3.9 released - you can try the release already with LDC!

[Rory McGuire via Digitalmars-d-announce]

On Thu, Sep 8, 2016 at 10:46 PM, Kai Nacke via Digitalmars-d-announce <
digitalmars-d-announce@puremagic.com> wrote:

> On Tuesday, 6 September 2016 at 10:51:16 UTC, eugene wrote:
>
>> On Tuesday, 6 September 2016 at 09:42:11 UTC, Lodovico Giaretta wrote:
>>
>>>
>>> There are lot of projects using LLVM [1]. The fact that LDC if often
>>> cited in the release notes means that it's one of the best. This is free
>>> advertisement, as the LLVM release notes are read by PL people that may not
>>> know D. The fact that LDC is recognized as one of the most important LLVM
>>> projects also means that the LLVM folks will try to help the LDC folks when
>>> needed.
>>>
>>> [1] http://llvm.org/ProjectsWithLLVM/
>>>
>>
>> i dont think counting each time when ldc and d are mentioned in llvm
>> community will help ldc and d to become popular)))
>>
>
> News ticker often refer to the LLVM release notes. E.g. the Heise news
> ticker (http://www.heise.de/) always reports about a new LLVM release.
> But I never succeded to place a new LDC release into the ticker. It's
> simply a good way to more people and get some advertising.
>
> With every new LDC release I inform LLVM Weekly (http://llvmweekly.org/),
> too, which is a widely read news letter. From one of these source, news
> about LDC spread to other sites like phoronix (http://phoronix.com/).
>
> Maybe counting of each reference is a bit childish (but fun). The real
> question is:
>

Its not childish at all, if you could show a chart of visits and downloads
vs news announcements its likely there is a correlation. However I think
these days most of us that are researching alternatives only do so when
necessary, so there is a chance that your work now will only pay off later
when someone finds D and wants to check its pedigree.


>
> What do YOU do to advocate D?
>
> Regards,
> Kai
>
>

Re: [OT] LLVM 3.9 released - you can try the release already with LDC!

[Rory McGuire via Digitalmars-d-announce]

On Fri, Sep 9, 2016 at 9:31 AM, eugene via Digitalmars-d-announce <
digitalmars-d-announce@puremagic.com> wrote:

> On Thursday, 8 September 2016 at 20:46:57 UTC, Kai Nacke wrote:
>
>>
>> What do YOU do to advocate D?
>>
>>
> What i do to advocate D is nothing, as D is not to be advocated but to be
> useful as a programming language))) My idea is simple: if it is useful then
> people will use it.)))
>
>
>

:D if that logic worked there would be no governments.


Jokes aside, people do what they know, and are loath to change unless it
shows high probability of them being able to survive in their group, or
they believe they will be able to survive in another group.

Re: Battle-plan for CTFE

[Rory McGuire via Digitalmars-d-announce]

On Thu, Sep 8, 2016 at 3:11 PM, Stefan Koch via Digitalmars-d-announce <
digitalmars-d-announce@puremagic.com> wrote:

> On Thursday, 8 September 2016 at 10:44:55 UTC, Stefan Koch wrote:
>
>> compiling parts of phobos does no longer crash the new engine.
>> However it still produces incorrect byte-code :)
>>
>
> I think I have taken care of the incorrect bytecode.
> It was not an issue with the engine itself but rather with the way I
> plugged it in.
> The new engine is not supposed being called if the old one has already
> started to interpret the function, because the two do not and should not
> share state.
>
>
!! Does this mean I can start testing new ctfe and only some of my CT will
be faster?

Re: workspace-d 2.7.2 & code-d 0.10.14

[Rory McGuire via Digitalmars-d-announce]

On Thu, Sep 8, 2016 at 8:50 AM, Suliman via Digitalmars-d-announce <
digitalmars-d-announce@puremagic.com> wrote:

> On Wednesday, 7 September 2016 at 18:27:41 UTC, WebFreak001 wrote:
>
>> On Wednesday, 7 September 2016 at 18:14:29 UTC, Suliman wrote:
>>
>>> You could look my PC with TeamViewer
>>>
>>
>> Ok problem fixed. The config was invalid, it needs to look like this:
>>
>> {
>> "d.stdlibPath": [
>> "C:\\D\\dmd2\\src\\phobos",
>> "C:\\D\\dmd2\\src\\druntime\\import"
>> ]
>> }
>>
>> Just forgot these braces {} to make it valid json
>>
>
> It's possible to integrate workspace-d with Sublime?
>
+1

Re: Battle-plan for CTFE

[Rory McGuire via Digitalmars-d-announce]

On Mon, Sep 5, 2016 at 1:39 PM, Stefan Koch via Digitalmars-d-announce <
digitalmars-d-announce@puremagic.com> wrote:

> FunctionCall support is done. (with a lot of room for improvement)
> you can already return strings.
> now I just have to finish string-comparison and string-concat support to
> make it usable.
>
> And of course the correct translation of logical-expressions...
>


Great news! Any chance you post the commit link in your announcements?
Would be really interested in being able to do a quick scan of what changed.

For that latest commit I just see the below. Is this all the changes? :)
what does it mean? (you replaced the old ctfe for functions with your new
one?)

% git show 4ba35de160cdb82bb289ad2860cf5163e1636ab5
commit 4ba35de160cdb82bb289ad2860cf5163e1636ab5
Author: Stefan Koch 
Date:   Mon Sep 5 13:35:26 2016 +0200

hack in ability to do function calls

diff --git a/src/ctfe_bc.d b/src/ctfe_bc.d
index 2e9d0fa..a96d37c 100644
--- a/src/ctfe_bc.d
+++ b/src/ctfe_bc.d
@@ -143,6 +143,7 @@ else static if (UsePrinterBackend)
 else
 {
 import ddmd.ctfe.bc;
+import ddmd.dinterpret;

 alias BCGenT = BCGen;

@@ -2252,6 +2253,10 @@ public:
 IGaveUp = true;
 return;
 }
+import ddmd.dinterpret;
+ctfeInterpret(ce).accept(this);
+return ;
+/*
 auto fn = _sharedCtfeState.getFunctionIndex(ce.f);
 if (!fn)
 {
@@ -2296,6 +2301,8 @@ public:
 assert(0, "Could not gen Function: " ~ ce.f.toString);
 IGaveUp = true;
 }
+*/
+
 }

 override void visit(ReturnStatement rs)




BTW: thanks for all the work!

Re: Beta D 2.071.2-b3

[Rory McGuire via Digitalmars-d-announce]

On Fri, Sep 2, 2016 at 10:15 AM, ketmar via Digitalmars-d-announce <
digitalmars-d-announce@puremagic.com> wrote:

> On Friday, 2 September 2016 at 07:46:30 UTC, Rory McGuire wrote:
> actually, from my PoV solution is supereasy: just remove ALL visibility
> restrictions for traits. and i mean all. allMembers should return all
> members, getMember should allow to access *any* existing member without
> annoying messages. it is up to programmer to insert getProtection checks if
> he needs it.
>
> traits is a low-level feature by definition, and doesn't meant to be used
> directly (we have std.traits wrappers for that), so i want D devs to stop
> making our, low-level coders, life harder than it is now. ;-)
>
> D devs just should draw the line between __traits and std.traits. first
> sould be inherently unsafe, allow *everything* and impose as little
> restrictions as it is possible (note: *as* *possible*, not *as* *sane* --
> all kind of insanity should be allowed, if it is possible). then,
> std.traits wrappers should use __traits to build *safe* things (declaring
> that @trusted in the end).
>


May our benevolent dictators agree with you :D (I do).

If a developer is willing to research the language definition and discover
__traits, you should be ready for unprotected intimacy with the hardware of
your choice. And if someone just copy pastes code with __traits in it they
should know that "__" in a symbol is a "WARNING here be dragons"

Re: [GSoC] Precise GC

[Rory McGuire via Digitalmars-d-announce]

On Fri, Sep 2, 2016 at 9:46 AM, Jeremy DeHaan via Digitalmars-d-announce <
digitalmars-d-announce@puremagic.com> wrote:

> [snip]. Precisely scanning unions is tricky since they could mix pointer
> and non pointer types. [snip]
>

Can we rather just make a special tagged union that is scanned... rather
avoid trying to make something that should be minimal more and more
complex? The compiler already treats some parts of phobos as "special" as
far as I know.

Re: Beta D 2.071.2-b3

[Rory McGuire via Digitalmars-d-announce]

On Fri, Sep 2, 2016 at 8:47 AM, ketmar via Digitalmars-d-announce <
digitalmars-d-announce@puremagic.com> wrote:

> On Friday, 2 September 2016 at 06:27:11 UTC, Rory McGuire wrote:
>
>> Perhaps @system code should just completely ignore privacy?
>>
>
> it is uncontrollable. imagine attribute inference: today, your function
> was inferred @system, and it sees everything. and tomorrow you fixed some
> other things, and now your function inferred as @safe. BOOM! without
> warning, it doesn't do what it does before (but still works!), and you
> didn't even touched it's code. this is the worst kind of breakage.


I'm meaning if the dev marks the whole module as @system. I'm not convinced
that _any_ code should ever be inferred as @system. Its not okay for people
to accidentally make @system code.


>
>
> Could have a compiler option that changes the access errors into warnings?
>>
>
> each compiler option of this kind means "we failed our design task,
> brought you the feature that is so unusable that we even made it possible
> to turn it off globally. sorry, we giving up, now it is up to you to clean
> up the mess after us."
>

You may have a point there, even if its a bit excessive. I would like this
as a pragma, but then that leads us down the road of not even bothering to
change the compiler and just use a analysis tool.

mmm, even if we did make private access illegal we can still access
whatever we want if we have the source code so...

e.g. mixin(import(moduleName!exampleSymbol).replace("private", "public"));

not sure it would always work...

Re: Beta D 2.071.2-b3

[Rory McGuire via Digitalmars-d-announce]

On 02 Sep 2016 07:40, "ketmar via Digitalmars-d-announce" <
digitalmars-d-announce@puremagic.com> wrote:
>
> On Tuesday, 30 August 2016 at 23:54:45 UTC, Martin Nowak wrote:
>>
>> Allowing access to private members has a lot of implications, e.g.
breaks lots of optimizations b/c you can't know who accesses sth.
>
>
> i really HATE modern trend of turning tables. am i the only one who
thinks that the machine was designed to serve the human, not vice versa?
yet somehow we all trying to make our machines happy now, instead of using
'em.
>
> the most funny thing with it is that modern software is bloated, dog
slow, resource hungry and barely usable. so all this "please the machine"
movement is completely pointless!

Perhaps @system code should just completely ignore privacy? Could have a
compiler option that changes the access errors into warnings?

Then make a separate tool that we can use to do assertions on that code.
For example or company could have a policy that any @system code has 100%
test coverage.

Just thinking it loud.

R

Re: Battle-plan for CTFE

[Rory McGuire via Digitalmars-d-announce]

On Thu, Sep 1, 2016 at 11:26 PM, ag0aep6g via Digitalmars-d-announce <
digitalmars-d-announce@puremagic.com> wrote:

> On 09/01/2016 11:01 PM, Rory McGuire via Digitalmars-d-announce wrote:
>
>> I'm actually asking why we can't catch the ctfe error.
>>
>
> There is no CTFE error in your example. It doesn't compile in the first
> place, even without attempting any CTFE.
>
> [...]
>
>> Surely the ctfe engine could be changed to catch unsupported code
>> errors. (Not invalid, just unsupported at CT).
>>
>
> Maybe. It isn't obvious to me that it would be a good idea, but it's not
> obviously terrible either.
>
> The ctfe engine would have to "go past" the try anyway, right? This is
>> the part I don't understand. Is it because ctfe actually hasn't started
>> yet and some other analysis is freaking out?
>>
>
> It's just a compiler error. The snippet on its own fails compilation and
> there is no CTFE in there. Something like `static assert(_checkCTFE());`
> would involve CTFE. But that's not needed to trigger the error.
>



Yeah, I'm using an enum to force the evaluation during CT, and its dying
before CTFE from what I can tell. Here is another example:

void main() {
enum ret = ctfefunc();
mixin(ret);
}


string ctfefunc() {
static if (!assertCTFE!true) {
throw new Exception("Only during ctfe please...");
}
return `import std.stdio; writeln("ctfe generated this");`;
}

template assertCTFE(bool b) {
enum assertCTFE = __traits(compiles, _checkCTFE1());
}
void _checkCTFE1() {
static if (__ctfe) {

}
}

Re: Battle-plan for CTFE

[Rory McGuire via Digitalmars-d-announce]

On Thu, Sep 1, 2016 at 11:05 PM, David Nadlinger via Digitalmars-d-announce
 wrote:

> On Thursday, 1 September 2016 at 21:01:46 UTC, Rory McGuire wrote:
>
>> I'm actually asking why we can't catch the ctfe error.
>>
>
> You can, by using __traits(compiles, …).
>
> Surely the ctfe engine could be changed to catch unsupported code errors.
>> (Not invalid, just unsupported at CT).
>>
>
> It already does, see above. How is this related to try/catch?
>
>  — David
>

I was hoping that the error was coming from the CTFE engine as it ran the
code, but it comes up before ctfe execution I guess.

__traits(compiles, _some_function_that_calls_), thinks that the invalid
code compiles even when it doesn't compile, e.g.:

template assertCTFE(bool b) {
enum assertCTFE = __traits(compiles, _checkCTFE1());
}
void _checkCTFE1() {
static if (__ctfe) { // this still stops compilation (probably because this
is checked before __traits(compiled ...) is evaluated

}
}

Re: Battle-plan for CTFE

[Rory McGuire via Digitalmars-d-announce]

On 01 Sep 2016 21:36, "David Nadlinger via Digitalmars-d-announce" <
digitalmars-d-announce@puremagic.com> wrote:
>
> On Thursday, 1 September 2016 at 19:27:17 UTC, Rory McGuire wrote:
>>
>> So why can't we even catch the Error during CTFE, that would at least
help somewhat.
>
>
> You are mixing up runtime exceptions ("throw …") with compiler errors
(missing a semicolon). dm.D.learn should be able to help clear that up.
>
>  — David

I'm actually asking why we can't catch the ctfe error. It's quite obvious
that it is a temporary limitation of ctfe, there have been many limitations
removed over the years.

Surely the ctfe engine could be changed to catch unsupported code errors.
(Not invalid, just unsupported at CT).

The ctfe engine would have to "go past" the try anyway, right? This is the
part I don't understand. Is it because ctfe actually hasn't started yet and
some other analysis is freaking out?

Re: Battle-plan for CTFE

[Rory McGuire via Digitalmars-d-announce]

On Thu, Sep 1, 2016 at 9:09 PM, David Nadlinger via Digitalmars-d-announce <
digitalmars-d-announce@puremagic.com> wrote:

> On Thursday, 1 September 2016 at 16:43:53 UTC, Rory McGuire wrote:
>
>> is that in one of the "semantic" passes the compiler has?
>>
>
> For reference, I've laid out the reasons why this proposal couldn't work
> to Stefan here: https://github.com/dlang/dmd/p
> ull/6098#issuecomment-243375543
>
> The real reason is not so much in the pass structure of the compiler as in
> the fact that CTFE by definition executes the same function body that is
> also emitted to the runtime binary.
>
>  — David
>

okay thanks, I'll take a look at the link.

Question: if the function runs the same, why can't I catch the exception?
>From what Stefan said even if I could catch the exception static if still
wouldn't compile different code.

bool _checkCTFE() {
try {
import std.uuid;
enum id = new UUID("8AB3060E-2cba-4f23-b74c-b52db3bdfb46");
return false;
} catch (Throwable t) {
return true;
}
}

The above still fails during CTFE, compiler just exists with:
enforceCTFE.d(20): Error: variable enforceCTFE._checkCTFE.id : Unable to
initialize enum with class or pointer to struct. Use static const variable
instead.


So why can't we even catch the Error during CTFE, that would at least help
somewhat.

At the moment I just have a verbose logging mode with pragma(msg) for my
CTFE stuff.

Re: Battle-plan for CTFE

[Rory McGuire via Digitalmars-d-announce]

On Thu, Sep 1, 2016 at 6:29 PM, Stefan Koch via Digitalmars-d-announce <
digitalmars-d-announce@puremagic.com> wrote:

> On Thursday, 1 September 2016 at 13:18:18 UTC, Rory McGuire wrote:
>
>> the _checkCTFE() function is just a function that does something we're not
>> allowed to do at CTFE, but current implementation does not respect
>> __traits(compiles, );
>>
>>
>>
>> As far as I can tell that is a bug. Thoughts?
>>
>
> It is not a bug, because there is no way to mark something as CTFE-only.
> static ifs are not visible at the time where ctfe sees the function, they
> have already been resolved.
>
> getting a static if (__ctfe) to work would require significant changes to
> the semantic-analysis path for functions.
>


Ah, right, understood.


is that in one of the "semantic" passes the compiler has?

Re: Battle-plan for CTFE

[Rory McGuire via Digitalmars-d-announce]

On Wed, Aug 31, 2016 at 10:43 PM, Stefan Koch via Digitalmars-d-announce <
digitalmars-d-announce@puremagic.com> wrote:

> On Tuesday, 30 August 2016 at 22:01:45 UTC, tsbockman wrote:
>
>> On Monday, 29 August 2016 at 08:39:56 UTC, Stefan Koch wrote:
>>
>>> I just came up with a nifty little patch that makes it possible to
>>> ensure that a function is _only_ used at ctfe.
>>> Or the opposite.
>>>
>>> static assert(__ctfe, "This function is not supposed to be called
>>> outside of ctfe");
>>> and static assert(!__ctfe, "This function is not supposed to be called
>>> during ctfe");
>>>
>>> similarly you can use static if (__ctfe).
>>>
>>> Is it worth trying to get it into master ?
>>>
>>
>> Yes, please. I've often wished I could use `__ctfe` in a `static if`.
>>
>
> Sorry. It I overlooked a something rather important. static __ctfe is
> currently not possible and it's rather expensive to make it possible.
>


Surely changing the current implementation slightly could still work if we
made a library implementation like:


// ? module std.exception.enforce_ctfe;

void main() {
ctfefunc();
}


string ctfefunc() {
static if (assertCTFE!true) {
throw new Exception("asdf");
}
return `import std.stdio; writeln("ctfe generated this");`;
}

template assertCTFE(bool b) {
enum assertCTFE = __traits(compiles, _checkCTFE());
}
void _checkCTFE() {
import std.uuid;
enum id = new UUID("8AB3060E-2cba-4f23-b74c-b52db3bdfb46");
}


the _checkCTFE() function is just a function that does something we're not
allowed to do at CTFE, but current implementation does not respect
__traits(compiles, );



As far as I can tell that is a bug. Thoughts?

Re: Battle-plan for CTFE

[Rory McGuire via Digitalmars-d-announce]

On Tue, Aug 30, 2016 at 10:35 AM, Stefan Koch via Digitalmars-d-announce <
digitalmars-d-announce@puremagic.com> wrote:

> [snip]
> But yes you can circumvent the code-generation and pulling in the druntime
> dependency using a static if.
>

That will be awesome!

Re: Battle-plan for CTFE

[Rory McGuire via Digitalmars-d-announce]

On Mon, Aug 29, 2016 at 9:51 AM, Dominikus Dittes Scherkl via
Digitalmars-d-announce  wrote:

> On Monday, 29 August 2016 at 00:24:01 UTC, Stefan Koch wrote:
>
>> I feel that this can have a positive impact on the whole of dmd, since
>> that will allow better frontend-optimisations.
>>
>> I am happy for all comments or suggestions.
>>
>
> The work you are doing is just awesome!
> Many thanks.
>

+1 your work is key for our success as a community.

R

Re: Aedi - a dependency injection library

[Rory McGuire via Digitalmars-d-announce]

On Thu, Aug 18, 2016 at 8:56 PM, Alexandru Ermicioi via
Digitalmars-d-announce  wrote:

> On Tuesday, 16 August 2016 at 19:24:22 UTC, Rory McGuire wrote:
>
>> On 16 Aug 2016 20:45, "Alexandru Ermicioi via Digitalmars-d-announce" <
>> digitalmars-d-announce@puremagic.com> wrote:
>>
>>>
>>> On Tuesday, 16 August 2016 at 14:25:10 UTC, Jacob Carlborg wrote:
>>>

 On 2016-08-16 11:41, Alexandru Ermicioi wrote:

 https://github.com/aermicioi/aedi
>


 If you use:

 ```d
 ```

 For the code block you'll get syntax highlighting for D.

>>>
>>>
>>> Thx, for info. Didn't know about such syntax. I'll update it with next
>>>
>> batch of modifications.
>>
>> Can this be used to do function
>> currying? http://stackoverflow.com/questions/36314/what-is-currying
>>
>> Seems like an interesting feature. I imagine it would use templates or a
>> wrapper struct instead of wrapped functions though.
>>
>
> Thank you, for sharing with an idea :)
>
> I'm not sure if I understand your proposition correctly.
>
> I assume that you meant the call of register function on container to
> register an object in it. If so, by applying currying, we would get
> something like:
>
> container.register!Type()("constructor")("setter", "setterArg"); // And
> so on.
>
> It's an interesting idea, but I'm not sure if it will allow an easy
> customization of register api :(.
>
> Could you please explain it in more detail?
>

No probs, example:
/
module m1;
/// this module contains standard functions / classes etc...
auto func1(Type1 v1, Type2 v2, Type3 v3) {
// do awesome stuff with all three instances
}

class A {
Type4 v4;
Type5 v5;
this(Type4 v4, Type5 v5) {
this.v4 =v4; this.v5=v5;
}
void changeMode(Type2 v2) {
v4.asdf(v2);
}
void opApply(...) {
/// do normal stuff with all these manually passed in instances
}
}

module auto_deps_m1;
/// this module has the curryied versions of the original functions and
classes from m1;
/// What I think would be cool, and I thinks its possible, would be to
automatically inject default instance parameters into classes (the Object),
and functions.
/// so func1 could for example be exposed in this module as:
auto func1(Type2 v2) {
   /// yeah, don't worry about passing the other stuff in, it was all setup
during dependency registration
}

class A {
Type4 v4; /// inject this
Type5 v5;
this(Type5 v5) {
this.v5 = v5; // we never registered a Type5 during dependency
registration
this.v4.changeMode(registered_v2); /// this got moved here due to
compile time dependency registration
}
void opApply(...) {
// do stuff, and all we had to supply in other modules that depend
on this one is the instance for v5
}
}

//


The function example is what I was thinking initially, but I don't see why
it couldn't be done with structs and classes as well.

I guess in m2 the code the programmer writes would be similar to:
mixin(registrationService.ct_register!(func1));

etc..

If its not possible right now I'd imagine its fairly close to possible.


disclaimer: I'm not very familiar with dependency injection in anything but
Javascript with AngularJS.

Re: Berlin D Meetup August 2016

[Rory McGuire via Digitalmars-d-announce]

Man I wish I was in Berlin. Will be awesome if we get to see a video of
this.

R

On Thu, Aug 18, 2016 at 11:09 AM, Ben Palmer via Digitalmars-d-announce <
digitalmars-d-announce@puremagic.com> wrote:

> Hi All,
>
> The August Berlin D Meetup will be happening at 20:00 on Friday the 26th
> of August at Berlin Co-Op (http://co-up.de/) on the fifth floor. Note
> that this is the fourth Friday of the month rather than the standard third
> Friday.
>
> Stefan Koch is going to tell his war-stories about implementing CTFE.
> Expect juicy bits of dmd code and a few rants as well as a birds-eye-view
> of how the new engine is going to work.
>
> There likely won't be slides but instead a few live demos of what the new
> engine will be capable of.
>
> Sociomantic have come to the party once more and will be sponsoring food
> (including vegetarian options) and drinks (both alcoholic and
> non-alcoholic).
>
> More details are available on the meetup page here:
> http://www.meetup.com/Berlin-D-Programmers/events/233371803/
>
> Thanks,
> Ben.
>

Re: Battle-plan for CTFE

[Rory McGuire via Digitalmars-d-announce]

On 17 Aug 2016 18:50, "Stefan Koch via Digitalmars-d-announce" <
digitalmars-d-announce@puremagic.com> wrote:
>
> Just a small update today.
> if(__ctfe) and if(!__ctfe)
> now get special treatment.
> Also working on getting compiletime-parsers to run.
>

Nice tease with the "compile time parsers to run" aside.

We're salivating here. What exactly did you mean by that?

Which compile time parser are you using for testing?

PS: thanks for the updates!

Re: DIP1000: Scoped Pointers

[Rory McGuire via Digitalmars-d-announce]

On Wed, Aug 17, 2016 at 9:04 AM, Mike via Digitalmars-d-announce <
digitalmars-d-announce@puremagic.com> wrote:
>
>
> Or perhaps DIP1000 changes the current behavior of the `scope` storage
> class.
>
> My understanding is that the `scope` storage class currently allocates a
> class on the stack (though its usage for this purpose is deprecated in
> favor of std.typecons.scoped).


Correct. I believe the reason for the deprecation was that it was too easy
to use considering how easy it was to get it's usage wrong, and that a
library implementation would be just as good, which would also lessen the
number of reserved words D has, and make devs more likely to check the
documentation for its caveats.


>   If DIP1000 is implemented, it will change that behavior, so the
> allocation will instead be on the GC heap, but the compiler will do some
> flow-control analysis to prevent escaping references.  Is that right?
>
> Mike
>

Not correct, the class would still be on the stack so we can have reference
semantics during assignment etc, but the instance is on the stack so its
faster and the function the code is inside can optionally be nogc.

DIP1000 will just make the compiler check that a stack instance does not
escape its scope (though it doesn't cover all cases).

struct Astruct {} // - on stack by default
class Aclass  {} // - on heap by default
void main() {
Astruct a = new Astruct; // override, now Astruct is on the heap
(because of "new")
Aclass c = new Aclass; // on the heap as per-usual
scope Aclass c1 = new Aclass; // override, now class is on the stack
(most obvious use: to make all references use the same instance)
}

Re: DIP1000: Scoped Pointers

[Rory McGuire via Digitalmars-d-announce]

On 17 Aug 2016 04:00, "Mike via Digitalmars-d-announce" <
digitalmars-d-announce@puremagic.com> wrote:
>
> On Wednesday, 17 August 2016 at 01:42:00 UTC, Walter Bright wrote:
>
>>> Can you please clarify the current implementation `scope`, and what
DIP1000
>>> proposes to change with respect to the current implementation?
>>
>>
>> It just adds to the existing compiler implementation of 'scope'. It has
nothing to do with std.typecons.scoped.
>
>
> Ok, but the deprecations page [1] gives this example...
>
> class A
> {
> int x;
> this(int x) { this.x = x; }
> }
>
> void main()
> {
> A obj;
> {
> scope A a = new A(1);
> obj = a;
> }
> assert(obj.x == 1);  // fails, 'a' has been destroyed
> }
>
> ... as a deprecated pattern, and corrected with ...
>
> class A
> {
> this(int x) { }
> }
> void main()
> {
> auto a = std.typecons.scoped!A(1);
> }
>
> However, in DIP1000, the examples use the above deprecated pattern
extensively.  So what's the story?  Does the deprecations page [1] need an
update?
>
> [1]
http://dlang.org/deprecate.html#scope%20for%20allocating%20classes%20on%20the%20stack

Basically DIP1000 makes it so that:
> void main()
> {
> A obj;
> {
> scope A a = new A(1);
> obj = a;
> }
> assert(obj.x == 1);  // fails, 'a' has been destroyed
> }

Will not compile.

Re: Aedi - a dependency injection library

[Rory McGuire via Digitalmars-d-announce]

On 16 Aug 2016 20:45, "Alexandru Ermicioi via Digitalmars-d-announce" <
digitalmars-d-announce@puremagic.com> wrote:
>
> On Tuesday, 16 August 2016 at 14:25:10 UTC, Jacob Carlborg wrote:
>>
>> On 2016-08-16 11:41, Alexandru Ermicioi wrote:
>>
>>> https://github.com/aermicioi/aedi
>>
>>
>> If you use:
>>
>> ```d
>> ```
>>
>> For the code block you'll get syntax highlighting for D.
>
>
> Thx, for info. Didn't know about such syntax. I'll update it with next
batch of modifications.

Can this be used to do function
currying? http://stackoverflow.com/questions/36314/what-is-currying

Seems like an interesting feature. I imagine it would use templates or a
wrapper struct instead of wrapped functions though.

Re: DIP1000: Scoped Pointers

[Rory McGuire via Digitalmars-d-announce]

On 16 Aug 2016 21:01, "Dicebot via Digitalmars-d-announce" <
digitalmars-d-announce@puremagic.com> wrote:
>
> On Tuesday, 16 August 2016 at 18:55:40 UTC, Dicebot wrote:
>>
>> On Tuesday, 16 August 2016 at 18:25:42 UTC, Meta wrote:
>>>
>>> What about this?
>>>
>>> struct Rnd
>>> {
>>> int* state;
>>> }
>>>
>>> void test()
>>> {
>>> scope rnd = new Rnd();
>>> Rnd rnd2 = *rnd;
>>>
>>> saveGlobalState(rnd2);
>>> }
>>
>>
>> Same as far as I understand, because "from a lifetime analysis
viewpoint, a struct is considered a juxtaposition of its direct members" (
https://github.com/dlang/DIPs/blob/master/DIPs/DIP1000.md#aggregates). You
need to add one more level of indirection for things to start going
complicated.
>
>
> Ah no, sorry, I have missed that you allocate struct on heap. Yes, this
is simplified problem case indeed. Intention is that such struct can be
made @safe by making all pointer fields private and adding scope semantics
in getter methods but it is hard to reason about details at this point.

It will be nice to see a set of tests that are expected to pass, a set that
are expected to fail, and a set that segfault.

In my questions I was trying to make small examples, that could become
tests.

The examples in the DIP are quite simple actually. The pointer escaping
example is what I was missing.

Re: DIP1000: Scoped Pointers

[Rory McGuire via Digitalmars-d-announce]

On Mon, Aug 15, 2016 at 4:05 PM, Dicebot via Digitalmars-d-announce <
digitalmars-d-announce@puremagic.com> wrote:

> On 08/15/2016 04:54 PM, Rory McGuire via Digitalmars-d-announce wrote:
> > okay nice, so that code would not compile but code such as:
> > void test() {
> > scope rnd  = new Rnd; // reference semantic and stack allocated
> > auto rnd2 = rnd;
> > some_sneaky_function_that_saves_global_state(rnd);
> > }
> > would still not be checked. And would crash inexplicably at the point
> > the global was accessed?
>
> some_sneaky_function_that_saves_global_state would have to be declared
> as `some_sneaky_function_that_saves_global_state(scope Rnd rnd)` to be
> allowed to use rnd as argument which prevents escaping to globals.
>
> What would still be the problem is if `Rnd` contains reference to
> another class internally (which gets manually destroyed when Rnd is
> destroyed) and `some_sneaky_function_that_saves_global_state` saves it
> instead - because by current design `scope` is a storage class and not
> transitive.
>
>
Thanks! That is an excellent explanation. Is the below a test case for that?

import std.stdio;

class Rnd {
NormalRefSemantics inner; // protecting this is irrelevant in more complex
objects?
this() {
inner = new NormalRefSemantics();
writeln("created");
}
~this() {
delete inner;// this is what causes the segfault
writeln("destroyed");
}

int i;
}

void test() {
scope rnd  = new Rnd; // reference semantic and stack allocated
auto rnd2 = rnd;

rnd.i = 2;
assert(rnd2.i == 2);
sneaky_escape(rnd);
}

void main() {
writeln("start test");
test();
writeln("test exited", oops);
}

class NormalRefSemantics {
this() {
writeln("I'm alive");
}
~this() {
writeln("inner destruction");
}
}
NormalRefSemantics oops;
void sneaky_escape(Rnd r) {
oops = r.inner; // how can we protect this inner part of the class from
escaping?
// would we need to mark classes and functions as "scope safe"? (similar to
"thread safe")
}

==
This DIP is really interesting, reminds me of back when we were playing
around with "emplace".

R

Re: DIP1000: Scoped Pointers

[Rory McGuire via Digitalmars-d-announce]

On Mon, Aug 15, 2016 at 2:49 PM, Dicebot via Digitalmars-d-announce <
digitalmars-d-announce@puremagic.com> wrote:

> On 08/15/2016 03:41 PM, Rory McGuire via Digitalmars-d-announce wrote:
> > scope rnd  = new Rnd; // reference semantic and stack allocated
> > auto rnd2 = rnd;
> >
> > rnd.i = 2;
> > assert(rnd2.i == 2);
> > return rnd2;
>
> Point is that that would become illegal if DIP1000 is implemented thus
> giving scope class concept more justification. It would still have @safe
> holes though because proposed `scope` does not work through many
> indirection levels - but better than existing situation when nothing is
> checked.
>
>
okay nice, so that code would not compile but code such as:
void test() {
scope rnd  = new Rnd; // reference semantic and stack allocated
auto rnd2 = rnd;
some_sneaky_function_that_saves_global_state(rnd);
}
would still not be checked. And would crash inexplicably at the point the
global was accessed?

Re: DIP1000: Scoped Pointers

[Rory McGuire via Digitalmars-d-announce]

On Mon, Aug 15, 2016 at 1:57 PM, ZombineDev via Digitalmars-d-announce <
digitalmars-d-announce@puremagic.com> wrote:

> On Monday, 15 August 2016 at 10:27:00 UTC, Dicebot wrote:
>
>> On Monday, 15 August 2016 at 07:19:00 UTC, lobo wrote:
>>
>>> When was it deprecated? I use it a lot and DMD 2.071.1 gives no warning.
>>>
>>
>> It was planned for removal because it was very un-@safe (no escaping
>> checks whatsoever) and as such was not better than library implementation.
>>
>
import std.stdio;

class Rnd {
this() {
writeln("created");
}
~this() {
writeln("destroyed");
}

int i;
}

auto test() {
scope rnd  = new Rnd; // reference semantic and stack allocated
auto rnd2 = rnd;

rnd.i = 2;
assert(rnd2.i == 2);
return rnd2;
}

void main() {
writeln("start test");
auto v = test();
writeln("test exited", v);
}

Output:
start test
created
destroyed
segmentation fault (core dumped)  rdmd scoped_ref_class_semantics.d



> I suspected as much.
>
> Quite likely with DIP1000 implemented there will be no point in
>> deprecating it anymore.
>>
>
> +1 I think that would be great!
>
>
>
The above example should not compile after DIP1000? If so that will be
great!

Re: Battle-plan for CTFE

[Rory McGuire via Digitalmars-d-announce]

On Sun, Aug 14, 2016 at 5:21 AM, Stefan Koch via Digitalmars-d-announce <
digitalmars-d-announce@puremagic.com> wrote:

> Hi,
>
> I took a break from work on string operations and focused instead of
> improving the robustness of the engine.
> I.E. for it not to halt the compiler on unsupported expressions.
>
> right now,
> I can compile druntime without failures.
> Phobos should be working by the end of next week.
>
> Have a nice Sunday,
>
> Stefan
>
> PS. String foreach regressed.
> And Struct-handling regressed.
> Due to a change of memory-layout.
>
> I will fix this as soon as the engine does no longer abort.
>
>
Nice! thanks! Will be nice to be able to test newCTFE with our "normal"
code every now and then.

Re: Battle-plan for CTFE

[Rory McGuire via Digitalmars-d-announce]

On 06 Aug 2016 16:30, "Stefan Koch via Digitalmars-d-announce" <
digitalmars-d-announce@puremagic.com> wrote:
>
> Time for an update.
> (ASCII)-Strings work reasonably well.
>
> I am now working on supporting general Sliceing and Appending.
> The effort on function calls is also still ongoing.
>
> I added a switch to my version of dmd which allows to toggle the ctfe
engine.
> So now I can compare apples to apples when posting perf data.
>
> A nice weekend to all of you.

Hi Stefan,

Are you saying we can play around with ascii string slicing/appending
already?

The gist with the current state of ctfe support seems to have last been
changed 21 days ago? Am I reading that right? If so where could I find your
current tests, if I wanted to run the tests on my machine.

Cheers,
Rory

Re: LDC 1.1.0-beta2 has been released!

[Rory McGuire via Digitalmars-d-announce]

On Fri, Aug 5, 2016 at 11:36 AM, Temtaime via Digitalmars-d-announce <
digitalmars-d-announce@puremagic.com> wrote:

> On Friday, 5 August 2016 at 06:13:54 UTC, Rory McGuire wrote:
>
>> On Fri, Aug 5, 2016 at 3:28 AM, Emre Temelkuran via
>> Digitalmars-d-announce < digitalmars-d-announce@puremagic.com> wrote:
>>
>> On Wednesday, 3 August 2016 at 20:12:59 UTC, Kai Nacke wrote:
>>>
>>> Hi everyone,

 LDC 1.1.0-beta2, the LLVM-based D compiler, is available for download!
 This BETA release is based on the 2.071.1 frontend and standard library and
 supports LLVM 3.5-3.9.

 We provide binaries for Linux, OX X, FreeBSD, Win32 & Win64, Linux/ARM
 (armv7hf), now bundled with DUB. :-)

 As usual, you can find links to the changelog and the binary packages
 over at digitalmars.D.ldc: http://forum.dlang.org/post/ns
 kepdckljprrxsjb...@forum.dlang.org

 Regards,
 Kai


>>> It should definitely be the reference compiler. Why they're wasting
>>> power with parallel compilers. :(
>>>
>>>
>> Its not wasting, diversity is important. The fact that the three "real" D
>> compilers have pretty much the same language implementation is an important
>> message to the world about our language. GDC is lagging because of
>> man-power yes, but that does not mean we're wasting, it just means Ian
>> could do with some more help :).
>>
>> R
>>
>
> Definitely wasting. Have Rust and Go multiple compilers ?
>

I disagree that it is wasting, however if I'm wrong then wasting is
important. Freedom to disagree and fork and the knowledge that there are
many LLVM developers, and many GCC developers etc, creates a sense of
stability and diversity in licensing and creativity.
Right now, you could go find some obscure gcc backend and start working on
getting gdc working with it. Or you could get LDC to work with some obscure
LLVM backend.

This creates opportunities for student thesis  (plural?)  and personal
experimentation. They all have different implementations with different
concepts and ideologies underlying them. Not everyone thinks the same way
or processes information the same.

Programming is an art, having only one paint brush or one paint brush
supplier would be weird for painters. The same goes for compilers and
software devs.

R

Re: LDC 1.1.0-beta2 has been released!

[Rory McGuire via Digitalmars-d-announce]

On Fri, Aug 5, 2016 at 3:28 AM, Emre Temelkuran via Digitalmars-d-announce <
digitalmars-d-announce@puremagic.com> wrote:

> On Wednesday, 3 August 2016 at 20:12:59 UTC, Kai Nacke wrote:
>
>> Hi everyone,
>>
>> LDC 1.1.0-beta2, the LLVM-based D compiler, is available for download!
>> This BETA release is based on the 2.071.1 frontend and standard library
>> and supports LLVM 3.5-3.9.
>>
>> We provide binaries for Linux, OX X, FreeBSD, Win32 & Win64, Linux/ARM
>> (armv7hf), now bundled with DUB. :-)
>>
>> As usual, you can find links to the changelog and the binary packages
>> over at digitalmars.D.ldc:
>> http://forum.dlang.org/post/nskepdckljprrxsjb...@forum.dlang.org
>>
>> Regards,
>> Kai
>>
>
> It should definitely be the reference compiler. Why they're wasting power
> with parallel compilers. :(
>

Its not wasting, diversity is important. The fact that the three "real" D
compilers have pretty much the same language implementation is an important
message to the world about our language. GDC is lagging because of
man-power yes, but that does not mean we're wasting, it just means Ian
could do with some more help :).

R

Re: New Diet template engine almost complete, ready for comments

[Rory McGuire via Digitalmars-d-announce]

On Thu, Jul 28, 2016 at 3:26 PM, Chris via Digitalmars-d-announce <
digitalmars-d-announce@puremagic.com> wrote:
>
> Great stuff! Very much appreciated. Btw, the link to jade-lang.org (don't
> click!) leads to a dodgy business homepage atm. The right address is
>
> http://jade-lang.com/
>

Also:

Renaming jade -> pug #2184
https://github.com/pugjs/pug/issues/2184

Re: New Diet template engine almost complete, ready for comments

[Rory McGuire via Digitalmars-d-announce]

On Tue, Jul 26, 2016 at 7:54 AM, Sönke Ludwig <
digitalmars-d-announce@puremagic.com> wrote:

> [snip]
>
and on Linux the Gold linker should be used for speed, but then it should
> be almost as good as a runtime solution.
>

Note on using Gold on linux. You can use lflags "-fuse-ld=gold", to get dub
to link your project using gold if you are using dmd.

Re: New Diet template engine almost complete, ready for comments

[Rory McGuire via Digitalmars-d-announce]

On Tue, Jul 26, 2016 at 7:54 AM, Sönke Ludwig <
digitalmars-d-announce@puremagic.com> wrote:

> Am 26.07.2016 um 05:22 schrieb Puming:
>
>> On Monday, 25 July 2016 at 09:29:38 UTC, Sönke Ludwig wrote:
>>
>>> The Diet template language is aimed at providing a way to define
>>> procedurally generated HTML/XML pages (or other output formats), with
>>> minimal visual noise. Syntax and feature set are heavily inspired by
>>> Jade , but instead of JavaScript, all
>>> expressions and statements are D statements, and everything that can
>>> be done at compile-time is done at compile-time.
>>>
>>> [...]
>>>
>>
>> A feature I want the most for Diet is the ability to parse Diet
>> templates at RUNTIME instead of compile time with a switch, similar to
>> Regex/CtRegex.
>>
>> In this way one can do quick turnarounds in dev mode, tweaking little
>> corners of the pages, and then when a page is finished, it can be
>> switched to compile mode for faster render time.
>>
>> Do you think this is feasible?
>>
>
> A real runtime solution would require a D runtime interpreter or JIT
> compiler. There would be an alternative solution based on compiling each
> template to a shared library and then dynamically recompiling/reloading
> those as required, but that currently doesn't work due to the alias
> parameter based interface of render!(...).
>
> However, what should work well is a combination of
> https://github.com/dlang/dub/pull/446 and
> https://github.com/rejectedsoftware/vibe.d/pull/1385 - I'll merge the
> latter one into vibe.d master today. It will require to store session
> information and similar things in an external store, and on Linux the Gold
> linker should be used for speed, but then it should be almost as good as a
> runtime solution.
>

!! nice, this is going to make my work life so much easier.

Thanks Sönke!

Re: New Diet template engine almost complete, ready for comments

[Rory McGuire via Digitalmars-d-announce]

On Tue, Jul 26, 2016 at 5:22 AM, Puming via Digitalmars-d-announce <
digitalmars-d-announce@puremagic.com> wrote:

> On Monday, 25 July 2016 at 09:29:38 UTC, Sönke Ludwig wrote:
>
>> The Diet template language is aimed at providing a way to define
>> procedurally generated HTML/XML pages (or other output formats), with
>> minimal visual noise. Syntax and feature set are heavily inspired by Jade <
>> http://jade-lang.org/>, but instead of JavaScript, all expressions and
>> statements are D statements, and everything that can be done at
>> compile-time is done at compile-time.
>>
>> [...]
>>
>
> A feature I want the most for Diet is the ability to parse Diet templates
> at RUNTIME instead of compile time with a switch, similar to Regex/CtRegex.
>
> In this way one can do quick turnarounds in dev mode, tweaking little
> corners of the pages, and then when a page is finished, it can be switched
> to compile mode for faster render time.
>
> Do you think this is feasible?
>

Hi Puming,

You could use some sort of dialect of JS that is close to D, and then alter
the diet template engine so that is doesn't evaluate the code sections with
some sort of CT switch.
Or you could use my Jaded templates which is basically the same but runs at
compile time or runtime (at runtime you would again have to use a language
with an interpreter.)

I think if you took, vibe.d/diet-ng + arsd/jsvar as your compile time
stack, you could find a common denominator so that you could use (node.js +
webpack + pug) to do the fast (live) edits of the templates.

Re: Battle-plan for CTFE

[Rory McGuire via Digitalmars-d-announce]

On Sun, Jul 17, 2016 at 6:08 PM, Stefan Koch via Digitalmars-d-announce <
digitalmars-d-announce@puremagic.com> wrote:

> On Sunday, 17 July 2016 at 15:57:28 UTC, Rory McGuire wrote:
>
>>
>> Thanks that would be great, however I think its a while off before it can
>> work on your ctfe implementation. It uses Pegged, so getting the Pegged
>> JSON parser or pegged.peg working would be a first step.
>>
>
> pegged uses templates.
> There is an intersection on which it can profit from CTFE improvments. But
> for the most part, it's a different sub-system in the compiler.
>
> That said, templates are next on my TODO list.
>

Nice, so I'll be able to see separate improvements in my CTFE stuff vs the
pegged template stuff once structs,  classes, etc.. are handled in your new
ctfe.

Re: Battle-plan for CTFE

[Rory McGuire via Digitalmars-d-announce]

On Sun, Jul 17, 2016 at 3:28 PM, Stefan Koch via Digitalmars-d-announce <
digitalmars-d-announce@puremagic.com> wrote:

> On Sunday, 17 July 2016 at 13:04:33 UTC, Rory McGuire wrote:
>
>> On Sun, Jul 17, 2016 at 2:41 PM, Stefan Koch via Digitalmars-d-announce <
>> digitalmars-d-announce@puremagic.com> wrote:
>>
>> [...]
>>>
>>
>> A commit does pretty much the same thing. Tags/Branches just make UIs show
>> a "menu" for selecting a change, not important really. I had just wondered
>> if you were marking these milestones.
>> Someone could always branch off of any of your commits, it they wanted to
>> try an alternative approach (or learn from you).
>>
>> Thanks for all the work you are doing. I love CTFE. I have a lot of big
>> vibe (diet) templates, and my own Jade ctfe implementation, really looking
>> forward to faster compile times.
>>
>> R
>>
>
> If you let me have a look at your jade-impl. I can probably work on
> speeding up it up. Vibed is still going to take a while. I need to figure
> all this UTF stuff out to make string handling robust.
>

Thanks that would be great, however I think its a while off before it can
work on your ctfe implementation. It uses Pegged, so getting the Pegged
JSON parser or pegged.peg working would be a first step.

If you were just meaning to show me any improvements I could make, the
source code is at:
https://github.com/rjmcguire/jaded


Cheers,
R

Re: Battle-plan for CTFE

[Rory McGuire via Digitalmars-d-announce]

On Sun, Jul 17, 2016 at 2:41 PM, Stefan Koch via Digitalmars-d-announce <
digitalmars-d-announce@puremagic.com> wrote:

> On Sunday, 17 July 2016 at 12:12:17 UTC, Rory McGuire wrote:
>
>> Nice! how are you keeping track of changes? Are you tagging / branching
>> each time you get something new working?
>>
>
> I just push a new commit.
> And add code to the gist.
>
> Why would I branch ?
> It all goes towards the same goal.
>

A commit does pretty much the same thing. Tags/Branches just make UIs show
a "menu" for selecting a change, not important really. I had just wondered
if you were marking these milestones.
Someone could always branch off of any of your commits, it they wanted to
try an alternative approach (or learn from you).

Thanks for all the work you are doing. I love CTFE. I have a lot of big
vibe (diet) templates, and my own Jade ctfe implementation, really looking
forward to faster compile times.

R

Re: Battle-plan for CTFE

[Rory McGuire via Digitalmars-d-announce]

Nice! how are you keeping track of changes? Are you tagging / branching
each time you get something new working?

On Sun, Jul 17, 2016 at 12:12 PM, Stefan Koch via Digitalmars-d-announce <
digitalmars-d-announce@puremagic.com> wrote:

> On Friday, 15 July 2016 at 20:36:46 UTC, Stefan Koch wrote:
>
>> I decided to keep a gist updated to represent the current state the new
>> engine can handle.
>> https://gist.github.com/UplinkCoder/89faa06311e417aa93ea99bc92934d3e
>>
>
> Internal changes to the bytecode engine make the manipulation of values on
> the ctfe stack possible.
>
> this allows the following code to properly compile now.
>
> struct V3 {int x; int y; int z;}
> int fn() {
>
> auto b = V3(1,2,3);
> b.y += 19;
> return b.y;
> }
>
> static assert(fn() == 21);
>

Re: Battle-plan for CTFE

[Rory McGuire via Digitalmars-d-announce]

On Wed, Jul 6, 2016 at 8:09 AM, ketmar via Digitalmars-d-announce <
digitalmars-d-announce@puremagic.com> wrote:

> On Wednesday, 6 July 2016 at 05:54:48 UTC, Rory McGuire wrote:
>
>> Are you sharing this code
>>
>
> yes. we are chatting with Stefan in IRC, and the repository is public (i
> mean, the link was there ;-). yet it won't compile with "vanilla" dmd
> anyway -- i require my dmd fork ("aliced"). and i don't really want to make
> it more public, as i have no intentions to turn that into full-blown engine.
>
Nice! Sounds like fun.


>
> also, not only our codebases are completely different, but our designs and
> approaches are drastically different. we just can't share/reuse the code,
> those projects are as compatible as WLIV and Z80. ;-)

Thought as much, wondered if the ideas about how they work were being
shared; often one idea sparks another.


>
> how you did it with the GSOC intern?
>>
> Stefan in not GSOC intern. ;-)
>
doh! my bad.

Re: Battle-plan for CTFE

[Rory McGuire via Digitalmars-d-announce]

On Tue, Jul 5, 2016 at 11:54 PM, ketmar via Digitalmars-d-announce <
digitalmars-d-announce@puremagic.com> wrote:

> and just to make sure that my approach is working: bytecode compiler now
> compiles simple free functions without args and returning int (yep, there
> are some in phobos! ;-), while passing everything other to old interpreter.
> it works, and all phobos unittests are passed (and some functions were
> actually executed with VM).
>
> that's where i should stop, i think, until it comes too far. ;-)
>

Are you sharing this code / how you did it with the GSOC intern?

Re: daffodil, a D image processing library

[Rory McGuire via Digitalmars-d-announce]

On Fri, Jul 1, 2016 at 10:11 AM, Benjamin Schaaf via Digitalmars-d-announce
 wrote:

> On Friday, 1 July 2016 at 01:24:55 UTC, rikki cattermole wrote:
>
>> On 01/07/2016 9:35 AM, Benjamin Schaaf wrote:
>>
>>> daffodil is a image processing library inspired by python's Pillow
>>> (https://pillow.readthedocs.org/). It is an attempt at designing a
>>> clean, extensible and transparent API.
>>>
>>> https://github.com/BenjaminSchaaf/daffodil
>>> https://benjaminschaaf.github.io/daffodil/
>>>
>>> The library makes full use out of D's templates and metaprogramming. The
>>> internal storage mechanism is entirely configurable from almost every
>>> endpoint. File headers are directly loaded into structs defining them,
>>> removing most of the difficulties in reading them according to spec. The
>>> image type and loading API is entirely extensible, making extra image
>>> formats entirely self-contained.
>>>
>>> Currently only loading and saving of simple BMP images is supported,
>>> with convolution and Gaussian Blur filters and flip transformations. Its
>>> still early in development, but I'd love to get some feedback on it.
>>>
>>> Example:
>>> ---
>>> import daffodil;
>>> import daffodil.filter;
>>> import daffodil.transform;
>>>
>>> void main() {
>>> auto image = load!32("daffodil.bmp");
>>>
>>> image.gaussianBlurred(1.4).save("blurry_daffodil.bmp");
>>>
>>> image.flipped!"y".save("upside_down_daffodil.bmp");
>>> }
>>> ---
>>>
>>> The license is MIT, so feel free to do whatever you want with the code.
>>> Issues and pull requests are of course welcome ;)
>>>
>>> Alongside I've also written (an admittedly hacky) sphinx
>>> (http://www.sphinx-doc.org/en/stable/) extension that provides a domain
>>> and autodocumenter for D, using libdparse and pyd.
>>>
>>
>> Doesn't use allocators or Manu's color work, yup yup not interested.
>>
>
> In terms of std.experimental.color, one of the things I focused on was
> extensibility. What if someone came along and had their own color space
> they needed to implement? With std.experimental.color, the only option you
> currently have is editing the library. If it gets included into phobos,
> then suddenly your "I want to implement my own color space" has turned into
> editing the standard library.
> Albeit currently rough around the edges, all you have to do to implement
> your own color space in daffodil, is to implement the ColorSpace interface.
>
> I haven't looked into using allocators yet, but I've put it on the horizon.
>

Yeah, good choice.

I lean more towards the standard library defining a set if inspection
templates (to avoid forcing use of classes/interfaces)  and a default
implementation rather than tying us so close to the standard library, D is
better than that.

Re: Button: A fast, correct, and elegantly simple build system.

[Rory McGuire via Digitalmars-d-announce]

On Mon, Jun 27, 2016 at 2:23 AM, Jason White via Digitalmars-d-announce <
digitalmars-d-announce@puremagic.com> wrote:

> On Monday, 20 June 2016 at 08:21:29 UTC, Dicebot wrote:
>
>> On Monday, 20 June 2016 at 02:46:13 UTC, Jason White wrote:
>>
>>> This actually sounds nice. Main problem that comes to my mind is that
 there is no cross-platform shell script. Even if it is list of plain
 unconditional commands there are always differences like normalized path
 form. Of course, one can always generate `build.d` as a shell script, but
 that would only work for D projects and Button is supposed to be a generic
 solution.

>>>
>>> I'd make it so it could either produce a Bash or Batch script. Possibly
>>> also a PowerShell script because error handling in Batch is awful. That
>>> should cover any platform it might be needed on. Normalizing paths
>>> shouldn't be a problem either.
>>>
>>> This should actually be pretty easy to implement.
>>>
>>
>> Will plain sh script script also work for MacOS / BSD flavors? Committing
>> just two scripts is fine but I wonder how it scales.
>>
>
> FYI, I implemented this feature today (no Batch/PowerShell output yet
> though):
>
> http://jasonwhite.github.io/button/docs/commands/convert
>
> I think Bash should work on most Unix-like platforms.
>

And there is this[0] for windows, if you wanted to try bash on windows:


[0]: https://msdn.microsoft.com/en-us/commandline/wsl/about

Re: Button: A fast, correct, and elegantly simple build system.

[Rory McGuire via Digitalmars-d-announce]

On Mon, Jun 20, 2016 at 10:21 AM, Dicebot via Digitalmars-d-announce <
digitalmars-d-announce@puremagic.com> wrote:

> On Monday, 20 June 2016 at 02:46:13 UTC, Jason White wrote:
>
>> This actually sounds nice. Main problem that comes to my mind is that
>>> there is no cross-platform shell script. Even if it is list of plain
>>> unconditional commands there are always differences like normalized path
>>> form. Of course, one can always generate `build.d` as a shell script, but
>>> that would only work for D projects and Button is supposed to be a generic
>>> solution.
>>>
>>
>> I'd make it so it could either produce a Bash or Batch script. Possibly
>> also a PowerShell script because error handling in Batch is awful. That
>> should cover any platform it might be needed on. Normalizing paths
>> shouldn't be a problem either.
>>
>> This should actually be pretty easy to implement.
>>
>
> Will plain sh script script also work for MacOS / BSD flavors? Committing
> just two scripts is fine but I wonder how it scales.
>

Bash script should work with all. I also read that Microsoft is making bash
for windows[1].

[1]
http://www.theverge.com/2016/3/30/11331014/microsoft-windows-linux-ubuntu-bash

Re: pure D JPEG decoder, with progressive JPEG support, public domain

[Rory McGuire via Digitalmars-d-announce]

On Fri, Jun 17, 2016 at 3:35 PM, John Colvin via Digitalmars-d-announce <
digitalmars-d-announce@puremagic.com> wrote:

> On Friday, 17 June 2016 at 13:05:47 UTC, ketmar wrote:
>
>> finally, the thing you all waited for years is here! pure D no-frills
>> JPEG decoder with progressive JPEG support! Public Domain! one file! no
>> Phobos or other external dependecies! it even has some DDoc! grab it[1] now
>> while it's hot!
>>
>> [1] http://repo.or.cz/iv.d.git/blob_plain/HEAD:/jpegd.d
>>
>
> awesome.
>
> Without wanting to start a huge thing about this, see
> http://linuxmafia.com/faq/Licensing_and_Law/public-domain.html and
> http://www.rosenlaw.com/lj16.htm and please at least add an optional
> licencing under a traditional permissive open-source license (boost would
> be nice, who knows, maybe phobos should have jpeg support?).
>

Thanks for that info. I don't think it would help if ketmar made it MIT /
Boost licensed or any other, if the original authors relatives chose to
dispute the license it the fact that the code is based on the PD code would
make it hard to protect.

I think that source code under PD might get exception to the laws in those
articles because of the way PD is used globally and what its intent is, and
what our common understanding of it is. However that would probably go to
court to settle.

Re: Work in Amsterdam

[Rory McGuire via Digitalmars-d-announce]

On Tue, Jun 14, 2016 at 1:50 AM, Ali Çehreli
 wrote:
> On 06/13/2016 04:48 PM, Walter Bright wrote:
>>
>> On 6/13/2016 4:00 PM, Ali Çehreli wrote:
>>>
>>> On 06/13/2016 03:45 PM, Márcio Martins wrote:

 Forgive me if this is not the best place for this sort of posts, but we
 are looking for experienced developers willing to learn D to join our
 development team in Amsterdam. We are a fast-growing travel e-commerce
 startup focused on themed vacation packages.

 You'll be part of our small and agile development team, working with
 D/vibe.d on a daily basis, with the occasional javascript for the
 client-side of things.

 Learn more on https://www.linkedin.com/jobs2/view/140710158
>>>
>>>
>>> Just a reminder to everybody else that we have the following page:
>>>
>>>   http://dlang.org/orgs-using-d.html
>>>
>>> (Tripaneer is already there with a "Hiring" link.)
>>>
>>> Ali
>>>
>>
>> An announcement here is still ok, with a followup to that page.
>
>
> Of course! I didn't mean otherwise. Just making that relatively-recent page
> known by more people. :)
>
> Ali
>


For everyone not in the EU:

Important: Currently only accepting applicants from Europe or with
valid work permit for the Netherlands

Re: Beta release DUB 1.0.0-beta.1

[Rory McGuire via Digitalmars-d-announce]

hmm, actually thats not quite the issue, I made a mock set of projects
and it works with both versions.
With 0.9.25 I get:
Sub package onyx-config: doesn't exist.

Whereas with 0.9.24 my package compiles. I'll see if I can figure out
why, sorry for the noise.

On Fri, Jun 10, 2016 at 11:53 AM, Rory McGuire <rjmcgu...@gmail.com> wrote:
> BTW: One other question, do you know of a bug where relative paths in
> dub packages have stopped working in recent versions?
>
> It seems like it always uses the path of the package being built
> rather than the dependencies own directory. I currently have to use
> 0.9.24.
>
> On Fri, Jun 10, 2016 at 11:00 AM, Sönke Ludwig
> <digitalmars-d-announce@puremagic.com> wrote:
>> Am 10.06.2016 um 10:02 schrieb Rory McGuire via Digitalmars-d-announce:
>>>
>>> I made a version that ignores comment like characters in strings.
>>> I've also made a version that requires the recipe to be on the second
>>> line.
>>>
>>> Both are in my fork of dub. I can fix my pull request to which ever
>>> one you guys prefer.
>>>
>>> The one that handles recipe anywhere has a flaw where it will still
>>> recognize a dub recipe even
>>> if the recipe is inside a nested comment (one would expect that to be
>>> commented out.
>>>
>>> (...)
>>
>>
>> My preference would be to use the one that requires the recipe to be at the
>> top for 1.0.0 and to get the generic version flawless for 1.1.0.

Re: Beta release DUB 1.0.0-beta.1

[Rory McGuire via Digitalmars-d-announce]

On Fri, Jun 10, 2016 at 8:30 AM, Rory McGuire  wrote:
> On Thu, Jun 9, 2016 at 10:48 PM, Steven Schveighoffer via
> Digitalmars-d-announce  wrote:
>> On 6/9/16 4:37 PM, Sönke Ludwig wrote:
>>>
>>> Am 09.06.2016 um 15:06 schrieb Steven Schveighoffer:

 On 6/8/16 2:45 PM, Sönke Ludwig wrote:
 (...)
>
> Apart from what I've already mentioned in my first reply to Jacob, I
> think there is nothing else that couldn't be solved in either case.


 "It's still possible to put something else in front of it"

 I didn't get this. How is /+ different from /*? I thought the only issue
 was the nesting.
>>>
>>>
>>> I mean together with the restriction that it has to be the first /+ +/
>>> comment, it is possible to put // and /* style comments in front of it
>>> without interference.
>>
>>
>> Oh, didn't see that aspect. I'll answer this with your last point.
>>
>>>
> Okay, so at least 3 people favor supporting other comment styles, while
> I'm not convinced that supporting all comment styles is necessarily
> better, I wouldn't mind pulling an update. The relevant code section is
> here:
>
> https://github.com/dlang/dub/blob/b02c18991b0cb4627eb0c943efd6ca3e69192751/source/dub/dub.d#L288
>
>

 Thanks. Perhaps more debate is fruitless until someone steps up with an
 implementation :)
>>>
>>>
>>> Rory has started an implementation: https://github.com/dlang/dub/pull/872
>>>
>>> But this has brought up another issue. The idea was to allow the recipe
>>> comment to be anywhere in the file and be of any comment style. However,
>>> that basically almost requires a full D lexer (at least string literals
>>> need to be parsed in addition to the comment styles).
>>>
>>> I'm reluctant to include this in the current state, because the results
>>> for a program such as the following will be very confusing:
>>>
>>> bool foo(string str)
>>> {
>>> return str.startsWith("/*");
>>> }
>>>
>>> /* dub.sdl: ... */
>>> void main()
>>> {
>>> }
>>>
>>> The string literal will be recognized as the start of a comment and thus
>>> the real comment below will not be recognized. So I think we should
>>> either have a generic and correct version, or one that is restricted
>>> similar to the current one to sidestep such issues.
>>
>>
>> I think the idea to include it anywhere in the file is not worth the
>> trouble. I also wouldn't want to scroll through an entire file for such a
>> thing.
>>
>> But it also brings up the point, what if the first /+ comes after:
>>
>> return str.startsWith("/+");
>>
>>>
> 1.0.0-rc.1 is scheduled for Monday morning, so it should ready by then
> to avoid stretching the release schedule (it's technically a breaking
> change!).


 How would this be a breaking change? It seems an additive feature, and
 I'm not sure it's required to be there before the first 1.0 release.
>>>
>>>
>>> There could be a /* */ comment before the /+ dub.*: +/ one, which is now
>>> not considered as a recipe comment candidate. Depending on its contents,
>>> the behavior could change once /* */ is also recognized. However, that
>>> case would be easily detectable and a warning could be emitted instead,
>>> while falling back to the old behavior. So it's not really an issue
>>> after all.
>>>
>>
>> Yeah, comments are not hard to parse, if they are the first thing you are
>> expecting.
>>
>> I would say it doesn't have to be the first comment, but it has to be one of
>> the first things in the file. You can simply throw away other comments.
>>
>> You may want to just tell the user: look, this isn't perfect, it's not a D
>> parser. Expect reasonable results for reasonable situations :) If you have a
>> line of code that looks like it could match the sdl file, then put the true
>> sdl file above it.
>>
>> -Steve
>
>
>
> Could we not just make it a requirement that if the file starts with
> #!... on the first line then the second line _must_ be a comment with
> the dub file definition?
>
> It will be frustrating to try find the dub definition if its not near
> the top and if the definition starts to be complicated so that you
> can't see the copyright or whatever would usually be in the first
> comment then you probably shouldn't be using a single file dub project
> anyway.
>
> If that is released with dub 1.0 then the restriction can always be
> loosened up if there is enough demand.

I made a version that ignores comment like characters in strings.
I've also made a version that requires the recipe to be on the second line.

Both are in my fork of dub. I can fix my pull request to which ever
one you guys prefer.

The one that handles recipe anywhere has a flaw where it will still
recognize a dub recipe even
if the recipe is inside a nested comment (one would expect that to be
commented out.

The one that handles recipe on second line only 

Re: Beta release DUB 1.0.0-beta.1

[Rory McGuire via Digitalmars-d-announce]

On Thu, Jun 9, 2016 at 10:48 PM, Steven Schveighoffer via
Digitalmars-d-announce  wrote:
> On 6/9/16 4:37 PM, Sönke Ludwig wrote:
>>
>> Am 09.06.2016 um 15:06 schrieb Steven Schveighoffer:
>>>
>>> On 6/8/16 2:45 PM, Sönke Ludwig wrote:
>>> (...)

 Apart from what I've already mentioned in my first reply to Jacob, I
 think there is nothing else that couldn't be solved in either case.
>>>
>>>
>>> "It's still possible to put something else in front of it"
>>>
>>> I didn't get this. How is /+ different from /*? I thought the only issue
>>> was the nesting.
>>
>>
>> I mean together with the restriction that it has to be the first /+ +/
>> comment, it is possible to put // and /* style comments in front of it
>> without interference.
>
>
> Oh, didn't see that aspect. I'll answer this with your last point.
>
>>
 Okay, so at least 3 people favor supporting other comment styles, while
 I'm not convinced that supporting all comment styles is necessarily
 better, I wouldn't mind pulling an update. The relevant code section is
 here:

 https://github.com/dlang/dub/blob/b02c18991b0cb4627eb0c943efd6ca3e69192751/source/dub/dub.d#L288


>>>
>>> Thanks. Perhaps more debate is fruitless until someone steps up with an
>>> implementation :)
>>
>>
>> Rory has started an implementation: https://github.com/dlang/dub/pull/872
>>
>> But this has brought up another issue. The idea was to allow the recipe
>> comment to be anywhere in the file and be of any comment style. However,
>> that basically almost requires a full D lexer (at least string literals
>> need to be parsed in addition to the comment styles).
>>
>> I'm reluctant to include this in the current state, because the results
>> for a program such as the following will be very confusing:
>>
>> bool foo(string str)
>> {
>> return str.startsWith("/*");
>> }
>>
>> /* dub.sdl: ... */
>> void main()
>> {
>> }
>>
>> The string literal will be recognized as the start of a comment and thus
>> the real comment below will not be recognized. So I think we should
>> either have a generic and correct version, or one that is restricted
>> similar to the current one to sidestep such issues.
>
>
> I think the idea to include it anywhere in the file is not worth the
> trouble. I also wouldn't want to scroll through an entire file for such a
> thing.
>
> But it also brings up the point, what if the first /+ comes after:
>
> return str.startsWith("/+");
>
>>
 1.0.0-rc.1 is scheduled for Monday morning, so it should ready by then
 to avoid stretching the release schedule (it's technically a breaking
 change!).
>>>
>>>
>>> How would this be a breaking change? It seems an additive feature, and
>>> I'm not sure it's required to be there before the first 1.0 release.
>>
>>
>> There could be a /* */ comment before the /+ dub.*: +/ one, which is now
>> not considered as a recipe comment candidate. Depending on its contents,
>> the behavior could change once /* */ is also recognized. However, that
>> case would be easily detectable and a warning could be emitted instead,
>> while falling back to the old behavior. So it's not really an issue
>> after all.
>>
>
> Yeah, comments are not hard to parse, if they are the first thing you are
> expecting.
>
> I would say it doesn't have to be the first comment, but it has to be one of
> the first things in the file. You can simply throw away other comments.
>
> You may want to just tell the user: look, this isn't perfect, it's not a D
> parser. Expect reasonable results for reasonable situations :) If you have a
> line of code that looks like it could match the sdl file, then put the true
> sdl file above it.
>
> -Steve



Could we not just make it a requirement that if the file starts with
#!... on the first line then the second line _must_ be a comment with
the dub file definition?

It will be frustrating to try find the dub definition if its not near
the top and if the definition starts to be complicated so that you
can't see the copyright or whatever would usually be in the first
comment then you probably shouldn't be using a single file dub project
anyway.

If that is released with dub 1.0 then the restriction can always be
loosened up if there is enough demand.

Re: Beta release DUB 1.0.0-beta.1

[Rory McGuire via Digitalmars-d-announce]

I made a little parser, it doesn't handle nested + comments (just
needs a depth check).
https://github.com/dlang/dub/pull/871


On Wed, Jun 8, 2016 at 9:44 PM, Rory McGuire  wrote:
> regex version pull request:
> https://github.com/dlang/dub/pull/869
>
> On Wed, Jun 8, 2016 at 8:50 PM, Rory McGuire  wrote:
>> On Wed, Jun 8, 2016 at 11:15 AM, Sönke Ludwig
>>  wrote:
>>> Am 08.06.2016 um 08:59 schrieb Jacob Carlborg:

 On 2016-06-07 20:42, Sönke Ludwig wrote:

> No, it has to be the "+" variant (the first /+ +/ comment is evaluated).


 That's unfortunate.
>>>
>>>
>>> I generally really do appreciate your critique, but without backing reasons
>>> it doesn't really have a constructive effect.
>>>
>>> Two good properties about restricting to /+ +/ is that it's still possible
>>> to put something else in front of it, and that it stands out from the usual
>>> /* */ comments. Sure arguments can be made for supporting all comment types,
>>> but it shouldn't be forgotten that in the end this is a question of
>>> absolutely minimal impact.
>>>
>>> Just to be clear: If anyone has a good argument for supporting more/all
>>> comment types and there are no equally good arguments against it, please go
>>> ahead and implement it and it will be included. Let's just make this a quick
>>> decision, because changing it later on will mean breakage no matter how it's
>>> done.
>>
>> The only thing I can think to change would be that it doesn't have to
>> be the _first_ '/+...' but rather the first regex:
>> \n\/\+\s*dub\.(sdl|json):?\n(.*)\n\+\/\n
>>
>> See [0] for regex in action on the code below.
>>
>> Sometimes we might want to put the dub config just above the main
>> function, and a lot of people like that to be at the bottom of the
>> file (who knows what comments might be above that and we wouldn't want
>> to break the way /+ ... +/ can be used anywhere to comment out code /
>> comments.
>>
>> concrete example:
>> #!/usr/bin/env dub
>> /**
>>  * Copyright (C) blah blah blah
>>  * Some long copyright notice
>>  * Some long copyright notice
>>  * Some long copyright notice
>>  * Some long copyright notice
>>  * Some long copyright notice
>>  * Some long copyright notice
>>  * Some long copyright notice
>>  * Some long copyright notice
>> */
>> /+
>> // Example and/or documentation on changing this program
>> Some codeSome codeSome codeSome code
>> Some codeSome codeSome codeSome code
>> /*
>>  * Note that when doing the below !not threadsafe!...
>>  * see next example for threadsafe version.
>>  */
>> Some codeSome codeSome codeSome code
>> Some codeSome codeSome codeSome code
>> Some codeSome codeSome codeSome code
>> Some codeSome codeSome codeSome code
>> /*
>>  * This is the threadsafe version of above both are provided.
>>  * threadsafe version is not quite as fast
>>  */
>> Some codeSome codeSome codeSome code
>> Some codeSome codeSome codeSome code // this line has to be here
>> Some codeSome codeSome codeSome code
>>
>> +/
>>
>> /+ dub.sdl:
>> name "colortest"
>> dependency "color" version="~>0.0.3"
>> +/
>>
>> // implementation of support functions
>>
>> void main(string[] args) {
>> ...
>> }
>>
>>
>> [0] https://regex101.com/r/dR7xY1/1

Re: Beta release DUB 1.0.0-beta.1

[Rory McGuire via Digitalmars-d-announce]

regex version pull request:
https://github.com/dlang/dub/pull/869

On Wed, Jun 8, 2016 at 8:50 PM, Rory McGuire  wrote:
> On Wed, Jun 8, 2016 at 11:15 AM, Sönke Ludwig
>  wrote:
>> Am 08.06.2016 um 08:59 schrieb Jacob Carlborg:
>>>
>>> On 2016-06-07 20:42, Sönke Ludwig wrote:
>>>
 No, it has to be the "+" variant (the first /+ +/ comment is evaluated).
>>>
>>>
>>> That's unfortunate.
>>
>>
>> I generally really do appreciate your critique, but without backing reasons
>> it doesn't really have a constructive effect.
>>
>> Two good properties about restricting to /+ +/ is that it's still possible
>> to put something else in front of it, and that it stands out from the usual
>> /* */ comments. Sure arguments can be made for supporting all comment types,
>> but it shouldn't be forgotten that in the end this is a question of
>> absolutely minimal impact.
>>
>> Just to be clear: If anyone has a good argument for supporting more/all
>> comment types and there are no equally good arguments against it, please go
>> ahead and implement it and it will be included. Let's just make this a quick
>> decision, because changing it later on will mean breakage no matter how it's
>> done.
>
> The only thing I can think to change would be that it doesn't have to
> be the _first_ '/+...' but rather the first regex:
> \n\/\+\s*dub\.(sdl|json):?\n(.*)\n\+\/\n
>
> See [0] for regex in action on the code below.
>
> Sometimes we might want to put the dub config just above the main
> function, and a lot of people like that to be at the bottom of the
> file (who knows what comments might be above that and we wouldn't want
> to break the way /+ ... +/ can be used anywhere to comment out code /
> comments.
>
> concrete example:
> #!/usr/bin/env dub
> /**
>  * Copyright (C) blah blah blah
>  * Some long copyright notice
>  * Some long copyright notice
>  * Some long copyright notice
>  * Some long copyright notice
>  * Some long copyright notice
>  * Some long copyright notice
>  * Some long copyright notice
>  * Some long copyright notice
> */
> /+
> // Example and/or documentation on changing this program
> Some codeSome codeSome codeSome code
> Some codeSome codeSome codeSome code
> /*
>  * Note that when doing the below !not threadsafe!...
>  * see next example for threadsafe version.
>  */
> Some codeSome codeSome codeSome code
> Some codeSome codeSome codeSome code
> Some codeSome codeSome codeSome code
> Some codeSome codeSome codeSome code
> /*
>  * This is the threadsafe version of above both are provided.
>  * threadsafe version is not quite as fast
>  */
> Some codeSome codeSome codeSome code
> Some codeSome codeSome codeSome code // this line has to be here
> Some codeSome codeSome codeSome code
>
> +/
>
> /+ dub.sdl:
> name "colortest"
> dependency "color" version="~>0.0.3"
> +/
>
> // implementation of support functions
>
> void main(string[] args) {
> ...
> }
>
>
> [0] https://regex101.com/r/dR7xY1/1

Re: Beta release DUB 1.0.0-beta.1

[Rory McGuire via Digitalmars-d-announce]

On Wed, Jun 8, 2016 at 11:15 AM, Sönke Ludwig
 wrote:
> Am 08.06.2016 um 08:59 schrieb Jacob Carlborg:
>>
>> On 2016-06-07 20:42, Sönke Ludwig wrote:
>>
>>> No, it has to be the "+" variant (the first /+ +/ comment is evaluated).
>>
>>
>> That's unfortunate.
>
>
> I generally really do appreciate your critique, but without backing reasons
> it doesn't really have a constructive effect.
>
> Two good properties about restricting to /+ +/ is that it's still possible
> to put something else in front of it, and that it stands out from the usual
> /* */ comments. Sure arguments can be made for supporting all comment types,
> but it shouldn't be forgotten that in the end this is a question of
> absolutely minimal impact.
>
> Just to be clear: If anyone has a good argument for supporting more/all
> comment types and there are no equally good arguments against it, please go
> ahead and implement it and it will be included. Let's just make this a quick
> decision, because changing it later on will mean breakage no matter how it's
> done.

The only thing I can think to change would be that it doesn't have to
be the _first_ '/+...' but rather the first regex:
\n\/\+\s*dub\.(sdl|json):?\n(.*)\n\+\/\n

See [0] for regex in action on the code below.

Sometimes we might want to put the dub config just above the main
function, and a lot of people like that to be at the bottom of the
file (who knows what comments might be above that and we wouldn't want
to break the way /+ ... +/ can be used anywhere to comment out code /
comments.

concrete example:
#!/usr/bin/env dub
/**
 * Copyright (C) blah blah blah
 * Some long copyright notice
 * Some long copyright notice
 * Some long copyright notice
 * Some long copyright notice
 * Some long copyright notice
 * Some long copyright notice
 * Some long copyright notice
 * Some long copyright notice
*/
/+
// Example and/or documentation on changing this program
Some codeSome codeSome codeSome code
Some codeSome codeSome codeSome code
/*
 * Note that when doing the below !not threadsafe!...
 * see next example for threadsafe version.
 */
Some codeSome codeSome codeSome code
Some codeSome codeSome codeSome code
Some codeSome codeSome codeSome code
Some codeSome codeSome codeSome code
/*
 * This is the threadsafe version of above both are provided.
 * threadsafe version is not quite as fast
 */
Some codeSome codeSome codeSome code
Some codeSome codeSome codeSome code // this line has to be here
Some codeSome codeSome codeSome code

+/

/+ dub.sdl:
name "colortest"
dependency "color" version="~>0.0.3"
+/

// implementation of support functions

void main(string[] args) {
...
}


[0] https://regex101.com/r/dR7xY1/1

Re: Beta release DUB 1.0.0-beta.1

[Rory McGuire via Digitalmars-d-announce]

On 07 Jun 2016 11:56, "Sönke Ludwig" 
wrote:
>
> DUB 1.0.0 is nearing completion. The new feature over 0.9.25 is support
for single-file packages, which can be used to write shebang-style scripts
on Posix systems:
>
> #!/usr/bin/env dub
> /++ dub.sdl:
> name "colortest"
> dependency "color" version="~>0.0.3"
> +/
>
> void main()
> {
> import std.stdio : writefln;
> import std.experimental.color.conv;
> import std.experimental.color.hsx;
> import std.experimental.color.rgb;
>
> auto yellow = RGB!("rgb", float)(1.0, 1.0, 0.0);
> writefln("Yellow in HSV: %s", yellow.convertColor!(HSV!()));
> }
>
> With "chmod +x" it can then simply be run as ./colortest.d.
>
> Apart from that, the release contains some bug fixes, most notably it
doesn't query the registry for each build any more.
>
> Full change log:
> https://github.com/D-Programming-Language/dub/blob/master/CHANGELOG.md
>
> Download (Latest Preview):
> http://code.dlang.org/download

Awesome! Now we can do quick vibe test snippets without  having to make a
dub project.

Re: The Official D Blog is Live

[Rory McGuire via Digitalmars-d-announce]

On 03 Jun 2016 22:35, "Jack Stouffer via Digitalmars-d-announce" <
digitalmars-d-announce@puremagic.com> wrote:
>
> On Friday, 3 June 2016 at 19:33:31 UTC, Mike Parker wrote:
>>
>> The D Blog was born at DConf this year. With help from Jack Stouffer, it
is now live at:
>>
>> http://dlang.org/blog/
>
>
> IMO we should disable the comment section. Right now we are just asking
for spam, and I don't think we want to be in the position of moderating
each of these sections. Plus, all of the D tech discussions happen on
reddit, HN, or on here, so I don't think we will be missing anything.

Would be nice if the comment section was an interface to a specific news
group here. Keeping things in one place.

Re: D's Auto Decoding and You

[Rory McGuire via Digitalmars-d-announce]

On Fri, Jun 3, 2016 at 8:58 AM, tsbockman via Digitalmars-d-announce
 wrote:
> On Friday, 3 June 2016 at 06:37:59 UTC, Rory McGuire wrote:
>>
>> This dpaste shows a couple of issues with combining chars in D.
>>
>> https://dpaste.dzfl.pl/4b006959c5c0
>>
>> The compiler actually can't handle a combining character literal either.
>> see line 10.
>
>
> Your paste behaves as expected: the "character" types in D are defined as
> single Unicode code units. By definition, the NFD form of "é" is not a
> single code unit. You would need to use a Grapheme or [w|d]string for that.
>
> (Of course, one might reasonably question how useful our built-in character
> types actually are compared to ubyte/ushort/uint.)

hmm, perhaps it behaves as documented, however I'm not certain that
its expected :).

Re: D's Auto Decoding and You

[Rory McGuire via Digitalmars-d-announce]

On Fri, Jun 3, 2016 at 5:16 AM, jmh530 via Digitalmars-d-announce
 wrote:
> On Thursday, 2 June 2016 at 21:33:02 UTC, Andrei Alexandrescu wrote:
>>
>>
>> Should I assume some normalization occurred on the way?
>>
>
> I'm just looking over std.uni's section on normalization and realizing that
> I had basically no idea what it is or what's going on. The wikipedia page on
> unicode equivalence is a bit clearer.
>
> I'm definitely nowhere near qualified to have an opinion on these issues.


This dpaste shows a couple of issues with combining chars in D.

https://dpaste.dzfl.pl/4b006959c5c0

The compiler actually can't handle a combining character literal
either. see line 10.

R

Re: My ACCU 2016 keynote video available online

[Rory McGuire via Digitalmars-d-announce]

On 18 May 2016 1:25 PM, "Bill Hicks via Digitalmars-d-announce" <
digitalmars-d-announce@puremagic.com> wrote:
>
> On Tuesday, 17 May 2016 at 09:34:53 UTC, Rory McGuire wrote:
>>
>>
>> As a South African, I can only say that you are talking nonsense
regarding the horse/zebra joke. If you've been to Africa you will
understand; there really are a lot more Zebra than horses. Although I must
admit I think of horses or Monty Python when I hear hoofbeats.
>>
>> Andrei: Really good talk, thanks for sharing!
>
>
> Don't get it twisted.
>
> There are whites living in South Africa, and they are certainly not
African.  'Africans' refers to the people, the black people, and not all
Africans live in the continent of Africa, because of things like the
slavery.  The fact that Andrei referred to the people is what makes it
racist.  What's the next joke, something about Africans enjoying fried
chicken?

And then what. That the English often enjoy soccer/football?

Stop trying to alienate us. While I'm "white" (more like brown) I'm so
African even my grand parents couldn't get ancestral visas. I also happen
to be Irish so don't even start the slavery BS unless you do your history
research first.

Re: D's Auto Decoding and You

[Rory McGuire via Digitalmars-d-announce]

On 17 May 2016 16:21, "Steven Schveighoffer via Digitalmars-d-announce" <
digitalmars-d-announce@puremagic.com> wrote:
>
> On 5/17/16 10:06 AM, Jack Stouffer wrote:
>>
>> http://jackstouffer.com/blog/d_auto_decoding_and_you.html
>>
>> Based on the recent thread in General, I wrote this blog post that's
>> designed to be part beginner tutorial, part objective record of the
>> debate over it, and finally my opinions on the matter.
>>
>> When I first learned about auto-decoding, I was kinda miffed that there
>> wasn't anything in the docs or on the website that went into more
>> detail. So I wrote this in order to introduce people who are getting
>> into D to the concept, it's benefits, and downsides. When people are
>> confused in Learn why typeof(s.front) == dchar then this can just be
>> linked to them.
>>
>> If you think there should be any more information included in the
>> article, please let me know so I can add it.
>
>
> Starting to read it, see errors in your examples:
>
> is(s[0] == immutable char) -> is(typeof(s[0]) == immutable(char))
> is(s.front == dchar) -> is(typeof(s.front()) == dchar)
>
> I'm not sure if you need the parens after front, but if it's not marked
as @property, then this returns a function.
>
> -Steve

If I remember correctly adding the brackets then goes against best
practices because you can't be sure the underlying implementation of a
range is using a function for .front.

Re: My ACCU 2016 keynote video available online

[Rory McGuire via Digitalmars-d-announce]

On Tue, May 17, 2016 at 10:42 AM, Bill Hicks via Digitalmars-d-announce <
digitalmars-d-announce@puremagic.com> wrote:

> On Monday, 16 May 2016 at 13:46:11 UTC, Andrei Alexandrescu wrote:
>
>> Uses D for examples, showcases Design by Introspection, and rediscovers a
>> fast partition routine. It was quite well received.
>> https://www.youtube.com/watch?v=AxnotgLql0k
>>
>> Andrei
>>
>
> Incidentally, 2_000_000 D users have been waiting 10 years for one guy,
> you, to complete the containers/allocators and many other things.
>
> Man, this sh*t writes itself.
>
> And here you go again with your borderline racist jokes.  Not very cool.
> If you honestly want to find out if it's "confusing to Africans", I suggest
> you go to a black neighborhood and ask them.
>
>
>

As a South African, I can only say that you are talking nonsense regarding
the horse/zebra joke. If you've been to Africa you will understand; there
really are a lot more Zebra than horses. Although I must admit I think of
horses or Monty Python when I hear hoofbeats.

Andrei: Really good talk, thanks for sharing!

Re: To all DConf speakers: please upload slides!

[Rory McGuire via Digitalmars-d-announce]

On Thu, May 12, 2016 at 10:55 PM, Steven Schveighoffer via
Digitalmars-d-announce  wrote:

> On 5/12/16 4:13 PM, Seb wrote:
>
>> On Wednesday, 11 May 2016 at 09:17:54 UTC, Dicebot wrote:
>>
>>> To do the editing of HD videos we need presentation slides which are
>>> currently scattered over different places. It would help a lot to have
>>> them all in github.com/dlang/dlang.org repo - please submit pull
>>> requests asap!
>>>
>>
>> Just a minor complaint - would it be possible for the next dconf to have
>> the slides (or a link to them) on dconf.org before the talk starts?
>> Thanks for the great work!
>>
>
> I think it's better to not have the slides available until the talk
> starts. There may be jokes/surprises in the slides that you don't want to
> give away before the talk happens :)
>
> -Steve
>

Surely we should make it a requirement that slides are uploaded on the
dconf site, then make sure they only show once the talk starts.

I'd imagine its easier to get most of the admin stuff done before the
conference, because those involved are already busy with it.

Re: Battle-plan for CTFE

[Rory McGuire via Digitalmars-d-announce]

On Tue, May 10, 2016 at 8:45 AM, Jacob Carlborg via
Digitalmars-d-announce  wrote:
>
> I was listening to a discussion Don and Daniel had about the current
> implementation of CTFE. They talked about using a byte code interpreter.
> Even implementing a really crappy byte code interpreter would be a huge
> improvement.
>
> --
> /Jacob Carlborg

Does anyone know whether it would be worth while keeping the LLVM JIT
in mind when writing this new CTFE engine?

Re: Battle-plan for CTFE

[Rory McGuire via Digitalmars-d-announce]

On 09 May 2016 19:01, "Stefan Koch via Digitalmars-d-announce" <
digitalmars-d-announce@puremagic.com> wrote:
>
> Hi Guys,
>
> I have been looking into the DMD now to see what I can do about CTFE.
> Unfortunately It is a pretty big mess to untangle.
> Code responsible for CTFE is in at least 3 files.
> [dinterpret.d, ctfeexpr.d, constfold.d]
> I was shocked to discover that the PowExpression actually depends on
phobos! (depending on the exact codePath it may or may not compile...)
> which let to me prematurely stating that it worked at ctfe [
http://forum.dlang.org/thread/ukcoibejffinknrbz...@forum.dlang.org]
>
> My Plan is as follows.
>
> Add a new file for my ctfe-interpreter and update it gradually to take
more and more of the cases the code in the files mentioned above was used
for.
>
> Do Dataflow analysis on the code that is to be ctfe'd so we can tell
beforehand if we need to store state in the ctfe stack or not.
>
> Or baring proper data-flow analysis: RefCouting the variables on the
ctfe-stack could also be a solution.
>
> I will post more details as soon as I dive deeper into the code.
>
>

Will be awesome. Particularly if you document the workings of ctfe, might
make a great set of articles for a blog.

Re: LDC 1.0.0-beta1 has been released! Please help testing!

[Rory McGuire via Digitalmars-d-announce]

>From the github issue it appears it was just a issue with the build script.

On Mon, May 9, 2016 at 9:31 AM, Guillaume Chatelet via
Digitalmars-d-announce  wrote:
> On Monday, 25 April 2016 at 06:42:02 UTC, Kai Nacke wrote:
>>
>> Hi everyone,
>>
>> LDC 1.0.0-beta1, the LLVM-based D compiler, is available for download!
>> This BETA release is based on the 2.070.2 frontend and standard library
>> and supports LLVM 3.5-3.8.
>>
>> The 1.0 release will be a major milestone. Please help testing to make it
>> the best release ever!
>> We provide binaries for Linux, OX X, Win32 & Win64, Linux/ARM (armv7hf).
>> :-)
>>
>> As usual, you can find links to the changelog and the binary packages over
>> at digitalmars.D.ldc:
>> http://forum.dlang.org/post/bwrnvztwkzhhwhzsk...@forum.dlang.org
>>
>> Regards,
>> Kai
>
>
> Why does it requires libconfig.so.8? Could you static link it?

Re: It's alive! D building D building D, all on Android

[Rory McGuire via Digitalmars-d-announce]

On 08 May 2016 02:21, "Joakim via Digitalmars-d-announce" <
digitalmars-d-announce@puremagic.com> wrote:
>
> On Saturday, 7 May 2016 at 09:58:14 UTC, Johan Engelen wrote:
>>
>> Fantastic news!
>>
>> I hope we can find a good way to integrate automated testing of github
branches/PRs for Android.
>
>
> There is beta support for Android on Travis, perhaps it can be used to
run the druntime and phobos tests in an emulator.
https://aws.amazon.com/device-farm/

Re: Proposed: start DConf days one hour later

[Rory McGuire via Digitalmars-d-announce]

On 28 Apr 2016 6:30 AM, "Mithun Hunsur via Digitalmars-d-announce" <
digitalmars-d-announce@puremagic.com> wrote:
>
> On Thursday, 28 April 2016 at 03:44:51 UTC, Mike Parker wrote:
>>
>> On Wednesday, 27 April 2016 at 18:36:54 UTC, Andrei Alexandrescu wrote:
>>>
>>> The folks at Sociomantic suggested to start at 10:00 AM instead of 9:00
AM, therefore shifting the end time by one as well. Please reply with
thoughts on this! We're particularly concerned about folks who need to take
off early on Friday. -- Andrei
>>
>>
>> +1
>
>
> Hmm; my talk's at 3:30pm on Friday (4:30pm after this change), which
means I'd leave at 5:30pm. My flight out of Berlin is at 9:30pm; how long
does it take to get from the venue to the airport? (I'll probably have to
skip the last talk of Friday, which is a shame.)

Check Google maps. Google maps can even guess how long it will take at the
time you specify.

Re: Ddb needs a maintainer

[Rory McGuire via Digitalmars-d-announce]

On Tue, Apr 12, 2016 at 11:30 AM, Suliman via Digitalmars-d-announce <
digitalmars-d-announce@puremagic.com> wrote:

> This code compile and run:
>
> try {
>auto result = cmd.executeQuery;
>
>foreach (row; result)
>{
> writeln(row[0]);
> x = row[1].get!(ubyte[]);
>}
>
> }
> catch (ServerErrorException e) {
> // Probably table does not exist - ignore
> }
>
>
>
>
> But I am getting error:
>
> core.exception.OutOfMemoryError@src\core\exception.d(679): Memory
> allocation failed
>
> Is there any hack that can prevent this error?
>

Would need to see the full exception stack trace that was printed out.
Could you perhaps have an infinite recursion bug in there somewhere?
You should be able to see if you are getting the right type out of the
Variant by using something like:
writeln(row[1].type);

Re: Ddb needs a maintainer

[Rory McGuire via Digitalmars-d-announce]

On Tue, Apr 12, 2016 at 10:31 AM, Suliman via Digitalmars-d-announce <
digitalmars-d-announce@puremagic.com> wrote:

> On Monday, 15 February 2016 at 22:50:56 UTC, Piotr Szturmaj wrote:
>
>> On 2016-02-14 20:48, Eugene Wissner wrote:
>>
>>> I think may be we should discuss if we can/should change something in
>>> ddb. I think there were some interesting and promising ideas in this
>>> discussion. Maybe split the PostgreSQL driver and develop it seperately
>>> and use an interface more similar to JDBC. Maybe some kind of coworking
>>> with ddbc is possible to get more developers together; maybe Suliman has
>>> some thoughts on it.
>>>
>>
>> I added you and Jacob as collaborators. Please do what you think is
>> right. Thanks.
>>
>
> Could anybody help me to understand how to get data as ubyte?
>
> I found this places in sources.
>
> https://github.com/pszturmaj/ddb/commit/29070ef90ba8f8d658be50a5da4aa3c96d0cdd5a
>
> https://github.com/pszturmaj/ddb/commit/a66ff5a6aa7008235f28cce167d0ae42cc4f4df3
>
> But I can't understand how to use it.
>
> My code is next:
>
> auto cmd = new PGCommand(conn);
>
> cmd.query = `SELECT name, userblob FROM "USERS" ;`;
>
> ubyte [] x;
>
> try {
>auto result = cmd.executeQuery;
>
>foreach (row; result)
>{
> writeln(row[0]);
> x = row[1].get!(ubyte);
>}
>
> }
> catch (ServerErrorException e) {
> // Probably table does not exist - ignore
> }
>
>
> But I am getting error:
>
> source\app.d(28,13): Error: cannot implicitly convert expression ((
> VariantN!20u __tmpfordtor3893 = row.opIndex(1u);
>  , __tmpfordtor3893).get()) of type ubyte to ubyte[]
> dmd failed with exit code 1.
>
>
>
>
>
Hi,

In your example x is a ubyte[] and you get!(ubyte).

x should be a ubyte, however from your sql query I'd assume you actually
mean to use .get!(ubyte[])

Re: Release D 2.071.0

[Rory McGuire via Digitalmars-d-announce]

Here is the exact link I used. It is the source and binaries together.
http://downloads.dlang.org/releases/2.x/2.071.0/dmd.2.071.0.linux.tar.xz

On Wed, Apr 6, 2016 at 3:49 PM, Cy Schubert via Digitalmars-d-announce
 wrote:
> On Wednesday, 6 April 2016 at 13:27:36 UTC, Rory McGuire wrote:
>>
>> .tar.xz works and its much smaller
>
>
> It also doesn't work.
>
> Looks like the source hasn't been posted, only binary images.
>
> BTW, the github site doesn't appear to be up to date (according to the
> VERSION file).
>
> ~cy
> 

Re: Release D 2.071.0

[Rory McGuire via Digitalmars-d-announce]

.tar.xz works and its much smaller

On Wed, Apr 6, 2016 at 3:19 PM, Cy Schubert via Digitalmars-d-announce
 wrote:
> On Tuesday, 5 April 2016 at 22:43:05 UTC, Martin Nowak wrote:
>>
>> Glad to announce D 2.071.0.
>>
>> http://dlang.org/download.html
>>
>> This release fixes many long-standing issues with imports and the module
>> system.
>> See the changelog for more details.
>>
>> http://dlang.org/changelog/2.071.0.html
>>
>> -Martin
>
>
> Is there a source URL published anywhere?
> http://ftp.digitalmars.com/dmd.2.071.0.zip doesn't appear to work.
>
> ~Cy
>

Re: Beta D 2.071.0-b2

[Rory McGuire via Digitalmars-d-announce]

On Sun, Apr 3, 2016 at 1:59 PM, tost via Digitalmars-d-announce <
digitalmars-d-announce@puremagic.com> wrote:

> On Wednesday, 30 March 2016 at 11:03:51 UTC, Martin Nowak wrote:
>
>> Second beta for the 2.071.0 release.
>>
>> http://dlang.org/download.html#dmd_beta
>> http://dlang.org/changelog/2.071.0.html
>>
>> Please report any bugs at https://issues.dlang.org
>>
>> -Martin
>>
>
> //foo.d
> module foo;
>
> void main() {}
>
> class A {
>
> void bar(int i) {}
>
> void baz() {
> import othermodule;
> bar("abc");
> }
> }
>
> // othermodule.d
> module othermodule;
>
> void bar(string s) {}
>
> compiled with
>
> dmd foo.d othermodule.d
>
> gives
>
> foo.d(11): Error: function foo.A.bar (int i) is not callable using
> argument types (string)
>
> is this a feature of the new name lookup algorithm or a bug? Adapting my
> codebase would be trivial :)
>

I think compiler is supposed to stop you from doing that to protect against
hijacking.
http://dlang.org/hijack.html

R

Re: code-debug 0.6.0 released (GDB & LLDB for vscode)

[Rory McGuire via Digitalmars-d-announce]

On Tue, Mar 8, 2016 at 2:23 AM, Manu via Digitalmars-d-announce
 wrote:
>
> On 6 March 2016 at 21:25, WebFreak001 via Digitalmars-d-announce
>  wrote:
> > I just released version 0.6.0 of my debug extension for visual studio code.
> > It works really well for debugging D code and I also use it everytime I
> > debug my D code. It's still not completely finished but it supports lots of
> > features now. If you want to debug your code in vscode just install the
> > extension with
> >
> > ext install gdb
> >
> > The name of the extension is "Debug" but "gdb" is more specific for finding
> > it
> >
> > LLDB is freshly added so be sure to report bugs to the github repository. :)
> >
> > github: https://github.com/WebFreak001/code-debug
> > vscode: https://marketplace.visualstudio.com/items?itemName=webfreak.debug
>
> Cool, I'll give this a crack.
>
> I've tried out code-d, but it only seems to do anything useful with dub.
> None of my projects use dub. Every project I have combines C/C++/D,
> and dub is an insufficient build system.
> I can configure vscode projects to invoke my builds, but code-d
> doesn't have any project metadata to work with in that context.
> Can you work code-d to get its necessary working state from explicit
> variables in the vscode project file?


Hi Manu,

Have you checked out these dub commands?
preBuildCommands string[] A list of shell commands that is executed
always before the project is built
postBuildCommands string[] A list of shell commands that is executed
always after the project is built

R

Re: Dconf gets a new logo

[Rory McGuire via Digitalmars-d-announce]

On Thu, Mar 3, 2016 at 12:29 AM, Bill Baxter via Digitalmars-d-announce <
digitalmars-d-announce@puremagic.com> wrote:

> The other one was classy, but this one is energetic and fun.  +1.
>
> --bb
>
> +1 for fun

Re: Better docs for D (WIP)

[Rory McGuire via Digitalmars-d-announce]

On Sun, Jan 31, 2016 at 7:54 PM, Chris Wright via
Digitalmars-d-announce <digitalmars-d-announce@puremagic.com> wrote:
>
> On Sun, 31 Jan 2016 13:14:08 +0200, Rory McGuire via
> Digitalmars-d-announce wrote:
>
> > If you don't get a cease and desist letter from the D Foundation soon
> > I'd be surprised.
>
> A cease and desist for making Boost-licensed documentation available in
> another medium. Kind of violates the spirit of being an open source
> project, no?
>
> The only grounds potentially available for a C letter are based in
> trademarks. For the D Foundation to succeed with this sort of thing in
> general, they'd need to start an explicit trademark licensing system and
> assiduously go after people who use the trademark without a license. (Non-
> enforcement is grounds for losing trademark status.) That's probably not
> going to happen. Too much work and too much negative publicity.
>
> And you appear to be recommending this as a punitive measure for comments
> in another forum. Can you imagine the reaction? Every time anyone posted
> an article about D, the comments would be full of "hope you don't get
> sued".


The problem is the D logo etc at the top of his docs mixed with Adam's
resentment. Your email validates
what I was suggesting he should avoid.

>
>
> You're issuing a threat that you have no standing to fulfill, where those
> who do have standing have every incentive not to fulfill it and no
> particular reason to listen to you.
>
> > Your matter of fact insulting of our official docs
> > (which are leaps and bounds better than the new stuff you are making) is
> > destructive to our community.
>
> I've seen far nastier comments than Adam Ruppe's on this forum (it's a
> huge stretch to call his "nasty"), and nastier than yours, and
> unproductive to boot, and nobody objected to them. Seeing a person
> threatening someone for trying to help and providing specific feedback,
> while worse goes unnoted, is demoralizing and probably worse for the
> community.
>
> > Having a different kind of search and having a different layout that is
> > more succinct is "Super Awesome" and you are doing it, but you have
> > absolutely no reason to constantly insult the work on the main site.
> >
> > _Creating division in such a small community is not helpful_.
>
> It's not a division. It's a documentation mirror with a different layout.


Did you read my mail at all?

>
>
> > Having
> > competing designs can be very helpful, (e.g. your layout could be nice
> > for Google search results), official docs are nice because you don't
> > have to constantly jump around the site while working.
>
> There's pretty much no advantage to having three hundred declarations on
> the same page with no cross-references and only top-level declarations
> indexed.


>
>
> Cross-references plus all-in-one-page might be okay, but then you'd be
> comparing Adam Ruppe's work with a hypothetical evolution of dlang.org
> docs.
>
> > On Sat,
>
> Please, disable HTML mail for this list.

Re: Better docs for D (WIP)

[Rory McGuire via Digitalmars-d-announce]

On Sun, Jan 31, 2016 at 9:06 PM, Adam D. Ruppe via
Digitalmars-d-announce  wrote:
> On Sunday, 31 January 2016 at 11:14:08 UTC, Rory McGuire wrote:
>>
>> If you don't get a cease and desist letter from the D Foundation soon I'd
>> be surprised.
>
>
> http://forum.dlang.org/post/n5sf7o$mu1$2...@digitalmars.com
>
>
> Andrei isn't exactly enthusiastic (though later on, he softens a bit), but
> I'm convinced we need to change course anyway.
>
> Of course, if they did try more harsh measures, I'd fight it, and then we'd
> see a far more problematic division in the community.
>
>> but you have absolutely no reason to constantly insult
>> the work on the main site.
>
>
> I see a distinction between insults and technical criticism. A navigation
> bar that is difficult to navigate is a technical problem - and there's a
> technical solution. Changing the color of template constraints is like
> shoving toys under the bed when your mother is about to inspect your room.
> It might fool her for about two seconds, but she's going to see it anyway
> and will not be pleased.
>
> And more importantly, it doesn't actually clean up the dust, or organize the
> toys, or discover the dirty laundry that got mixed in to the floor.
>
>
> It is an easy "solution" that you can quickly do without a lot of work, but
> it isn't actually fixing anything. It is solving the unreadable mess problem
> by shoving half of it under the rug instead of actually making it readable.
>
> (And putting the text "Constraint:" before is silly too. Anyone who knows
> what that means also knows what if() means in this context, and anybody who
> doesn't isn't going to learn anything from it.)
>
>
> If dlang.org fixed these problems, I'll set my site to redirect to their
> site again like it used to do. But, as I've described before, I don't think
> it will change in that direction without a major, multi-faceted overhaul.
>
> I'm doing that overhaul now. And my content changes are available for
> upstream: https://github.com/D-Programming-Language/phobos/pull/3895
>
> Minor content so far, but lots of cross referencing, fixing missing
> comments, organizing, etc.
>
> though some of it also relies on the generator changes, so it isn't
> something they can just merge and forget about...
>
>> _Creating division in such a small community is not helpful_.
>
>
> It might be such a small community because of the weakness in its
> documentation. I've interviewed a LOT of new and prospective D users over
> the last several months and every one of them, without exception, expressed
> difficulty to me in navigating the official site. Several of them just went
> elsewhere and didn't look back.

100% bro, I'm not referring to making a separate implementation or
anything like that I'm saying: "As a 'important user' in our community
your voice counts for something and be careful what you say".

Surely everyone can agree on that?

Re: Better docs for D (WIP)

[Rory McGuire via Digitalmars-d-announce]

On Mon, Feb 1, 2016 at 10:01 PM, Chris Wright via
Digitalmars-d-announce <digitalmars-d-announce@puremagic.com> wrote:
> On Mon, 01 Feb 2016 10:03:25 +0200, Rory McGuire via
> Digitalmars-d-announce wrote:
>
>> The problem is the D logo etc at the top of his docs mixed with Adam's
>> resentment. Your email validates what I was suggesting he should avoid.
>
> My newsreader's history doesn't support your memory of events.
>
> The problem you cited was "insulting our official docs" and (nonexistent)
> community splits resulting from the insults. Your predicted / recommended
> response to that problem was "a cease and desist letter from the D
> Foundation".
>
> There's no evidence that you considered trademark issues at all until I
> brought them up. If I'd cited copyright infringement instead, I'm betting
> you would have jumped on that, even though the docs are Boost-licensed.

Are you trying to understand me, or alienate me? I'm unsure what your
motivation is for undermining my trying to explain myself in more
words.

>
> What I would actually expect, instead of a C letter, is a set of
> guidelines for using the D logo and other trademarked material. That's
> pretty standard for open source projects. And if those guidelines forbad
> using the D logo for a documentation mirror, that would be a problem.
>
> An airtight set of guidelines probably requires a trademark lawyer, which
> probably costs more than the D Foundation has in its coffers. We might
> see a preliminary set of guidelines coming out in the next year or so.
>
> I don't see how a criticism of the official documentation (even one you
> believe is insulting) fragments the community. Most people around here
> think D's documentation is a problem. Adam Ruppe provided both specific
> feedback and an implemented alternative, which is much more constructive
> than average. He's got a pull request for content changes that he's made,
> too, which is the opposite of fragmentation.

Re: Better docs for D (WIP)

[Rory McGuire via Digitalmars-d-announce]

On Sat, Jan 30, 2016 at 10:58 PM, Adam D. Ruppe via Digitalmars-d-announce <
digitalmars-d-announce@puremagic.com> wrote:

> Just want to update y'all that my better docs continue to improve with
> each passing week.
>
> I just did a style facelift on the members section:
>
> http://dpldocs.info/experimental-docs/std.algorithm.setops.html
>
> (and yes, that's mostly css style! I did a minor change to the html, you
> can see the old here: http://dpldocs.info/experimental-docs/std.stdio.html
> (well, at least until I rebuild the docs of all of Phobos again), but the
> css is the big thing. It is nice having semantic markup.)
>
>
> So I hope that is more readable. The sidebar is also new over the last
> couple weeks, giving a sorted list of sibling names - including package
> listings.
>
> If you go into a thing:
> http://dpldocs.info/experimental-docs/std.stdio.write.html you can see
> how the sidebar shows the immediate siblings only, which makes the list a
> lot more managable than trying to cram everything everywhere. I find the
> Phobos official sidebar to be useless because there's just too much there.
>
> BTW the recent push that makes constraints small and grey, check this out
> for example:
>
> http://dlang.org/phobos/std_algorithm_sorting.html#completeSort
>
> I feel is no help. The readability is still poor and it doesn't help with
> navigation. In my new members thing, I used a small, hoverable prototype...
> but just on the index. Once you click through, I still have the full
> details, formatted for legibility.
>
> This reform is not appeasing my revolution
>
>
>
> Anyway, I feel that this is really starting to come together now... pretty
> soon, I'll promote it to "alpha" from its current state of "pre-alpha".
> Just gotta write the new search engine first!
>


If you don't get a cease and desist letter from the D Foundation soon I'd
be surprised. Your matter of fact insulting of our official docs (which are
leaps and bounds better than the new stuff you are making) is destructive
to our community.

Having a different kind of search and having a different layout that is
more succinct is "Super Awesome" and you are doing it, but you have
absolutely no reason to constantly insult the work on the main site.

_Creating division in such a small community is not helpful_. Having
competing designs can be very helpful, (e.g. your layout could be nice for
Google search results), official docs are nice because you don't have to
constantly jump around the site while working.