Boston D Lang Meetup 10/29/2017

[Steven Schveighoffer via Digitalmars-d-announce]

Hi everyone,

I scheduled an informal meetup for Sunday, 10/29, to get together. 
Nothing special going on, except that Ali Çehreli, author of 
"Programming in D" will be in town, and has offered to join us, along 
with Andrei. That's 2/3 of the D Foundation! (Walter, when are you 
coming to Boston?)


Please RSVP on EventBrite if you are coming. See you then!

https://www.eventbrite.com/e/d-lang-boston-meetup-tickets-39127639824

-Steve

Re: iopipe alpha 0.0.1 version

[Steven Schveighoffer via Digitalmars-d-announce]

On 10/19/17 7:13 AM, Martin Nowak wrote:

On 10/13/2017 08:39 PM, Steven Schveighoffer wrote:

What would be nice is a mechanism to detect this situation, since the
above is both un-@safe and incorrect code.

Possibly you could instrument a window with a mechanism to check to see
if it's still correct on every access, to be used when compiled in
non-release mode for checking program correctness.

But in terms of @safe code in release mode, I think the only option is
really to rely on the GC or reference counting to allow the window to
still exist.


We should definitely find a @nogc solution to this, but it's a good
litmus test for the RC compiler support I'll work on.
Why do IOPipe have to hand over the window to the caller?
They could just implement the RandomAccessRange interface themselves.

Instead of
```d
auto w = f.window();
f.extend(random());
w[0];
```
you could only do
```d
f[0];
f.extend(random());
f[0]; // bug, but no memory corruption
```


So the idea here (If I understand correctly) is to encapsulate the 
window into the pipe, such that you don't need to access the buffer 
separately? I'm not quite sure because of that last comment. If f[0] is 
equivalent to previous code f.window[0], then the second f[0] is not a 
bug, it's valid, and accessing the first element of the window (which 
may have moved).


But let me assume that was just a misunderstanding...



This problem seems to be very similar to the Range vs. Iterators
difference, the former can perform bounds checks on indexing, the later
are inherently unsafe (with expensive runtime debug checks e.g. in VC++).


But ranges have this same problem.

For instance:
const(char[])[] lines = stdin.byLine.array;

Here, since byLine uses GC buffering, it's @safe (but wrong). If non-GC 
buffers are used, then it's not @safe.


I think as long as the windows are backed by GC data, it should be 
@safe. In this sense, your choice of buffering scheme can make something 
@safe or not @safe. I'm OK with that, as long as iopipes can be @safe in 
some way (and that happens to be the default).



Similarly always accessing the buffer through IOPipe would allow cheap
bounds checking, and sure you could still offer IOPipe.ptr for unsafe code.


It's an interesting idea to simply make the iopipe the window, not just 
for @safety reasons:


1. this means the iopipe itself *is* a random access range, allowing it 
to automatically fit into existing algorithms.
2. Existing random-access ranges can be easily shoehorned into being 
ranges (I already did it with arrays, and it's not much harder with 
popFrontN). Alternatively, code that uses iopipes can simply check for 
the existence of iopipe-like methods, and use them if they are present.
3. Less verbose usage, and more uniform access. For instance if an 
iopipe defines opIndex, then iopipe.window[0] and iopipe[0] are possibly 
different things, which would be confusing.


Some downsides however:

1. iopipes can be complex and windows are not. They were a fixed view of 
the current buffer. The idea that I can fetch a window of data from an 
iopipe and then deal simply with that part of the data was attractive.


2. The iopipe is generally not copyable once usage begins. In other 
words, the feature of ranges that you can copy them and they just work, 
would be difficult to replicate in iopipe.


A possible way forward could be:

* iopipe is a random-access range (not necessarily a forward range).
* iopipe.window returns a non-extendable window of the buffer itself, 
which is a forward/random-access range. If backed by the GC or some form 
of RC, everything is @safe.
* Functions which now take iopipes could be adjusted to take 
random-access ranges, and if they are also iopipes, could use the extend 
features to get more data.
* iopipe.release(size_t) could be hooked by popFrontN. I don't like the 
idea of supporting slicing on iopipes, for the non-forward aspect of 
iopipe. Much better to have an internal hook that modifies the range 
in-place.


This would make iopipes fit right into the range hierarchy, and 
therefore could be integrated easily into Phobos.


In fact, I can accomplish most of this by simply adding the appropriate 
range operations to iopipes. I have resisted this in the past but I 
can't see how it hurts.


For Phobos inclusion, however, I don't know how to reconcile 
auto-decoding. I absolutely need to treat buffers of char, wchar, and 
dchar data as normal buffers, and not something else. This one thing may 
keep it from getting accepted.


-Steve

Re: iopipe alpha 0.0.1 version

[Steven Schveighoffer via Digitalmars-d-announce]

On 10/16/17 4:56 PM, Martin Nowak wrote:

On Monday, 16 October 2017 at 19:36:20 UTC, Dmitry Olshansky wrote:
Dmitry hold off on this if you were going to do it. I have been 
looking at Jason White's io library, and think I'm going to just 
extract all the low-level types he has there as a basic io library, 
as they are fairly complete, and start from there. His library 
includes the ability to use Windows.



Meh, not that I had mich spare time to actually do anything ;)

Might help by reviewing what you have there.


Started to work on unbuffered I/O, had it in mind for quite a while 
already.

http://github.com/MartinNowak/io


Awesome!

Is the plan to put this into Phobos? If so, I would put it under 
std/experimental/io. However, if not, it should not be std/io.


Looks like it has all the stuff I had for my basic io type (and I see 
you have scatter read/write, that will help), so I will migrate iopipe 
to depend on it. I was thinking about using Jason White's io library, 
but I haven't seen him around in a while. Plus if this is going into 
Phobos, it would be the best thing for me to use.


Will pitch in when I can.

Thanks!

-Steve

Re: iopipe alpha 0.0.1 version

[Steven Schveighoffer via Digitalmars-d-announce]

On 10/12/17 8:41 AM, Steven Schveighoffer wrote:

On 10/12/17 1:48 AM, Dmitry Olshansky wrote:

On Thursday, 12 October 2017 at 04:22:01 UTC, Steven Schveighoffer wrote:
I added a tag for iopipe and added it to the dub registry so people 
can try it out.


I didn't want to add it until I had fully documented and unittested it.

http://code.dlang.org/packages/iopipe
https://github.com/schveiguy/iopipe

If you plan on using it, expect some API changes in the near future. 
I think the next step is really to add Windows support for the IODev 
type.


Might be able to help you on that using WinAPI for I/O. (I assume 
bypassing libc is one of goals).


That would be awesome! Yes, the idea is to avoid any "extra" buffering. 
So using CreateFile, ReadFile, etc.


Dmitry hold off on this if you were going to do it. I have been looking 
at Jason White's io library, and think I'm going to just extract all the 
low-level types he has there as a basic io library, as they are fairly 
complete, and start from there. His library includes the ability to use 
Windows.


-Steve

Re: iopipe alpha 0.0.1 version

[Steven Schveighoffer via Digitalmars-d-announce]

On 10/13/17 11:59 AM, Martin Nowak wrote:

On Thursday, 12 October 2017 at 04:22:01 UTC, Steven Schveighoffer wrote:
I added a tag for iopipe and added it to the dub registry so people 
can try it out.


I didn't want to add it until I had fully documented and unittested it.

http://code.dlang.org/packages/iopipe
https://github.com/schveiguy/iopipe


Great news to see continued work on this.

I'll just use this thread to get started on design discussions. If there 
is there a better place for that, let me know ;).


This is as good a place as any :) I may create some issue reports on 
github to track things better.



Questions/Ideas

- You can move docs out of the repo to fix search, e.g. by pushing them 
to a `gh-pages` branch of your repo.


When I tried the search it seemed to work...

See 
https://github.com/MartinNowak/bloom/blob/736dc7a7ffcd2bbca7997f273a09e272e0484596/travis.sh#L13 
for an automated setup using Travis-CI and ddox/scod.


I admit complete ignorance on this, I need to look into it, but at the 
moment, I'm OK with committing the generated docs directly as an ugly 
extra step. When I looked at the options under adding a "pages" piece 
for the project that if I put things under "docs" directory, it could 
use that, so that's what I went with.



- Standard device implementation?

   You library already has the notion of devices as thin abstractions 
over file/socket handles.
   Should we start with such an unbuffered IO library as foundation 
including support hooks for Fiber based event loops. Something along the 
lines of https://code.dlang.org/packages/io? Without a standard device 
lib, IOPipe could not be used in APIs.


I absolutely think this would be a great idea. In fact, you could use 
Jason White's io package with iopipes directly, as his low-level types 
have the necessary read function: 
https://github.com/jasonwhite/io/blob/master/source/io/file/stream.d#L335


Perhaps we could coax the basic types out of that library to provide a 
base for both iopipe and his high-level stuff. The stream portion of my 
library is really just a throwaway piece that is not a focus of the 
library. Indeed, I created it because unbuffered stream types didn't 
exist anywhere (the IODev type predates iopipe, as it was part of my 
original attempt to rewrite Phobos io).


- What's the plan for @safe buffer/window invalidation, right now you're 
handing out raw access to internal buffers with an inherent memory 
safety problem.


I don't plan to put any restrictions on this. In fact the core purpose 
of iopipe is to give raw buffer access to aid in writing higher-level 
routines around it. As I said here: 
https://github.com/schveiguy/iopipe/blob/master/source/iopipe/buffer.d#L217


If the Allocator supports deallocation I call it, but it may not be the 
correct thing to do. There is a sticky point in 
std.experiemental.allocator: the GC allocator defines deallocate, 
because it's available, but the *presence* of that member may be taken 
to mean you have to call it to deallocate. There is no member saying 
whether deallocation is optional.


In my wrapper GCNoPointerAllocator (which I needed to support allocating 
ubyte buffers without having to scan them), I leave out the deallocate 
function, so technically it's @safe with that allocator.


I will say though, at some point, I'm going to focus on making @safe as 
much as possible in iopipe. That may require using the GC for buffering.




   ```d
   auto w = f.window();
   f.extend(random());
   w[0]; // ⚡ dangling pointer ⚡
   ```

   I can see how the compiler could catch that if we'd go with 
compile-time enforced safety for RC and friends. But that's still 
unclear atm. and we might end up with a runtime RC/weak ptr mechanism 
instead, which wouldn't be too good a fit for that window mechanism.


What would be nice is a mechanism to detect this situation, since the 
above is both un-@safe and incorrect code.


Possibly you could instrument a window with a mechanism to check to see 
if it's still correct on every access, to be used when compiled in 
non-release mode for checking program correctness.


But in terms of @safe code in release mode, I think the only option is 
really to rely on the GC or reference counting to allow the window to 
still exist.




- What about the principle that the caller should choose 
allocation/ownership?


It can, BufferManager takes an Allocator compile-time option.

It's also possible to create your own ownership or allocation scheme as 
long as you implement the required iopipe methods.


   Having an extend methods means the IOPipe is responsible for 
growing/allocating buffers, so you'll end up with IOPipeMalloc, 
IOPipeGC, IOPipeAllocatorGrowExp (or their template alternatives), not 
very nice for APIs.


extend is a core part of the iopipe system. The point of the library is 
that you don't have to manage the buffering or allocation of your 
higher-level code in terms of memory ownership or 

Re: iopipe alpha 0.0.1 version

[Steven Schveighoffer via Digitalmars-d-announce]

On 10/13/17 12:49 PM, Martin Nowak wrote:

On Thursday, 12 October 2017 at 18:08:11 UTC, Steven Schveighoffer wrote:
Release 0.0.2 has fixes for the ddoc that I didn't notice before, 
there are no actual changes in the code.


May I recommend scod? It's just a ddox theme.
https://github.com/MartinNowak/scod

I keep https://github.com/MartinNowak/bloom also as example/scaffold 
repo, it's using an automated docs setup with gh-branches.


Just create a doc deployment token (https://github.com/settings/tokens) 
with public_repo access and store that encrypted in your .travis-ci.yml.


Martin, I would appreciate and I think many people would, a 
blog/tutorial on how to do this.


I'll look into your suggestions on the docs, thanks!

-Steve

Re: iopipe alpha 0.0.1 version

[Steven Schveighoffer via Digitalmars-d-announce]

On 10/12/17 3:05 AM, Jacob Carlborg wrote:

On 2017-10-12 06:22, Steven Schveighoffer wrote:

I also want to add generated documentation. Does anyone know of a good 
way to generate the ddoc (or ddox or whatever) and put it directly 
into the repository for github to serve? Would be an awesome tip for 
people making projects for code.dlang.org.


I would suggest using GitHub Pages [1] for storing it.

[1] https://pages.github.com



Thanks, I used dub -b ddox to generate the documentation, then committed 
the result, looks great!


http://schveiguy.github.io/iopipe

Release 0.0.2 has fixes for the ddoc that I didn't notice before, there 
are no actual changes in the code.


-Steve

Re: iopipe alpha 0.0.1 version

[Steven Schveighoffer via Digitalmars-d-announce]

On 10/12/17 1:48 AM, Dmitry Olshansky wrote:

On Thursday, 12 October 2017 at 04:22:01 UTC, Steven Schveighoffer wrote:
I added a tag for iopipe and added it to the dub registry so people 
can try it out.


I didn't want to add it until I had fully documented and unittested it.

http://code.dlang.org/packages/iopipe
https://github.com/schveiguy/iopipe

If you plan on using it, expect some API changes in the near future. I 
think the next step is really to add Windows support for the IODev type.


Might be able to help you on that using WinAPI for I/O. (I assume 
bypassing libc is one of goals).


That would be awesome! Yes, the idea is to avoid any "extra" buffering. 
So using CreateFile, ReadFile, etc.


-Steve

iopipe alpha 0.0.1 version

[Steven Schveighoffer via Digitalmars-d-announce]

I added a tag for iopipe and added it to the dub registry so people can 
try it out.


I didn't want to add it until I had fully documented and unittested it.

http://code.dlang.org/packages/iopipe
https://github.com/schveiguy/iopipe

If you plan on using it, expect some API changes in the near future. I 
think the next step is really to add Windows support for the IODev type.


Suggestions and ideas welcome and appreciated.

I also want to add generated documentation. Does anyone know of a good 
way to generate the ddoc (or ddox or whatever) and put it directly into 
the repository for github to serve? Would be an awesome tip for people 
making projects for code.dlang.org.


-Steve

Re: database 0.0.8 released

[Steven Schveighoffer via Digitalmars-d-announce]

On 9/12/17 1:14 PM, Brian wrote:
dlang database library: Database abstraction layer for D programing 
language, support PostgreSQL / MySQL / SQLite.


Project:
https://github.com/huntlabs/database

## Database
Database abstraction layer for D programing language, support PostgreSQL 
/ MySQL / SQLite.


I just wanted to point out that in order to bind against libmysqlclient, 
you must use an open-source license, or pay Oracle a license fee. This 
means the users of your library must use an open source license or pay 
the fee (not you), but your license makes it unclear that this is the 
case. More details here: 
https://www.mysql.com/about/legal/licensing/foss-exception/


Or you could instead use the mysql-native library that does not depend 
on Oracle's library: https://github.com/mysql-d/mysql-native


-Steve

Re: D as a Better C

[Steven Schveighoffer via Digitalmars-d-announce]

On 8/23/17 11:59 AM, Walter Bright wrote:

On 8/23/2017 7:37 AM, Steven Schveighoffer wrote:

How do dynamic closures work without the GC?


They don't allocate the closure on the GC heap. (Or do I have 
static/dynamic closures backwards?)


I thought "closure" means allocating the stack onto the heap so you can 
return the delegate with its context intact.


From https://en.wikipedia.org/wiki/Closure_(computer_programming) :

"A language implementation cannot easily support full closures if its 
run-time memory model allocates all automatic variables on a linear 
stack. In such languages, a function's automatic local variables are 
deallocated when the function returns. However, a closure requires that 
the free variables it references survive the enclosing function's 
execution. Therefore, those variables must be allocated so that they 
persist until no longer needed, typically via heap allocation, rather 
than on the stack, and their lifetime must be managed so they survive 
until all closures referencing them have are no longer in use."


-Steve

Re: D as a Better C

[Steven Schveighoffer via Digitalmars-d-announce]

On 8/23/17 11:52 AM, Walter Bright wrote:

On 8/23/2017 7:24 AM, Steven Schveighoffer wrote:
Looks like there are some outstanding requests to be fulfilled before 
it's pulled.


I don't agree that the requests improve matters.


You may want to mention that in the PR. Right now it just looks like you 
haven't seen or responded to the requests.


-Steve

Re: D as a Better C

[Steven Schveighoffer via Digitalmars-d-announce]

On 8/23/17 11:56 AM, Walter Bright wrote:

On 8/23/2017 7:10 AM, Steven Schveighoffer wrote:

Nope.


A ModuleInfo is generated, as well as FMB/FM/FME sections. Those 
sections may not work with the C runtime.


My point was simply that your small example doesn't cause any runtime or 
link time errors. You need something more complicated to require betterC.


Not sure if ModuleInfo is generated. IIRC, Martin made it so it's not if 
no usage of the ModuleInfo is apparent.


Yes, adding a struct causes link errors, but not because of ModuleInfo, 
it's because of the expected TypeInfo.


-Steve

Re: D as a Better C

[Steven Schveighoffer via Digitalmars-d-announce]

On 8/23/17 9:12 AM, Mike Parker wrote:
To coincide with the improvements to -betterC in the upcoming DMD 2.076, 
Walter has published a new article on the D blog about what it is and 
why to use it. A fun read. And I'm personally happy to see the love this 
feature is getting. I have a project I'd like to use it with if I can 
ever make the time for it!


The blog:

https://dlang.org/blog/2017/08/23/d-as-a-better-c/

Reddit:
https://www.reddit.com/r/programming/comments/6viswu/d_as_a_better_c/


How do dynamic closures work without the GC?

Nice article, BTW.

-Steve

Re: D as a Better C

[Steven Schveighoffer via Digitalmars-d-announce]

On 8/23/17 10:11 AM, Walter Bright wrote:

On 8/23/2017 7:01 AM, jmh530 wrote:
ModuleInfo isn't linked to at all (and I'm still a little unclear on 
what that does).


That's because ModuleInfo doesn't appear in the online documentation due 
to having a malformed Ddoc comment. I fixed it here:


   https://github.com/dlang/druntime/pull/1906

but nobody has pulled it.


Looks like there are some outstanding requests to be fulfilled before 
it's pulled.


-Steve

Re: D as a Better C

[Steven Schveighoffer via Digitalmars-d-announce]

On 8/23/17 10:00 AM, Walter Bright wrote:

On 8/23/2017 6:28 AM, Moritz Maxeiner wrote:

Interesting article, though one thing that I'm confused by is

Hence D libraries remain inaccessible to C programs, and chimera 
programs (a mix of C and D) are not practical. One cannot 
pragmatically “try out” D by add D modules to an existing C program.


I've been mixing C and full D for a while now (on Linux) by either 
having the main C program call rt_init/rt_term directly (if druntime 
is linked in when building a mixed C/D application), or have 
Runtime.initialize/Runtime.terminate be called from D via some 
plugin_load/plugin_unload functionality when using D shared libraries.

Why is this not considered practical?


Because in order to add a D function as trivial as:

int foo() { return 3; }

to a C program, now the C program has to link to druntime, and the 
program no longer has a small footprint. One of the reasons people use C 
is to get that small footprint. This has been a large barrier to C 
programs making use of D.




Nope.

Stevens-MacBook-Pro:testd steves$ cat testdfunc.d
extern(C) int foo() { return 3; }
Stevens-MacBook-Pro:testd steves$ cat testdfunc_c.c
#include 
extern int foo();

int main()
{
printf("%d\n", foo());
}
Stevens-MacBook-Pro:testd steves$ dmd -c testdfunc.d
Stevens-MacBook-Pro:testd steves$ gcc -o testdfunc testdfunc_c.c testdfunc.o
Stevens-MacBook-Pro:testd steves$ ./testdfunc
3


It's only if you do something that needs the runtime, such as static 
ctors, or use the GC.


-Steve

Re: Vectorflow: a neural network library for sparse data from Netflix

[Steven Schveighoffer via Digitalmars-d-announce]

On 8/2/17 1:40 PM, Benoit Rostykus wrote:

Netflix is happy to open-source its first D library.

Blog post: 
https://medium.com/@NetflixTechBlog/introducing-vectorflow-fe10d7f126b8

Repo: https://github.com/Netflix/vectorflow


Awesome! Can't say I understand most of the blog post, but it looks very 
impressive :)


-Steve

Re: SVD_to_D: Generate over 100k lines of highly-optimized microcontroller mmapped-IO code in the blink of an eye

[Steven Schveighoffer via Digitalmars-d-announce]

On 8/1/17 8:34 PM, Mike wrote:

On Tuesday, 1 August 2017 at 14:52:51 UTC, Steven Schveighoffer wrote:

Mike, I have to say still your talk in 2014 was one of my favorites. 
One of the things that was so impressive to me was the way you scraped 
the PDF to generate all the registers automatically. Having worked 
with STM chips (not ARM, but really basic 8-bit versions), I can 
definitely appreciate all the work this saves.


I'm not sure my work is worthy of such kind words, but thank you.


Sorry, it was awesome. You should own it. I think many people were 
impressed with what you were able to achieve, especially those who have 
dealt with embedded programming.


The PDF screen utility is here: 
https://github.com/JinShil/stm32_datasheet_to_d.  I'm not sure if it 
still compiles and works, but I might need to update it someday.


It generates much better code and more complete documentation than 
svd_to_d.  Most silicon vendors don't appear to invest much into their 
SVD files, so the SVD files are often incomplete and lacking the 
documentation that makes "good code + a good IDE = a substitute for the 
datasheet".

>
If I were creating a professional product, I'd probably prefer scraping 
the PDF over using the SVD files, or maybe some way to merge the two.




Yes, if the datasheet is wrong, they probably hear about it more, and 
fix it more readily than some xml files. Much harder to fix etch than it 
is to update some software.


In addition, I bet the software engineers take both into account and 
defer to the spec, meaning the bugs in the SVD may not get reported.


I would prefer the more accurate picture if it were me. In fact, you may 
be able to give them a better tool to generate the SVD file from the pdf :)


-Steve

Re: SVD_to_D: Generate over 100k lines of highly-optimized microcontroller mmapped-IO code in the blink of an eye

[Steven Schveighoffer via Digitalmars-d-announce]

On 7/31/17 4:51 AM, Mike wrote:

https://github.com/JinShil/svd_to_d

SVD_to_D is a command-line utility that generates D code from ARM 
Cortex-M SVD files.




Mike, I have to say still your talk in 2014 was one of my favorites. One 
of the things that was so impressive to me was the way you scraped the 
PDF to generate all the registers automatically. Having worked with STM 
chips (not ARM, but really basic 8-bit versions), I can definitely 
appreciate all the work this saves.


This seems like a natural extension, so awesome!

-Steve

Re: Boston D Meetup: Strawman Structs

[Steven Schveighoffer via Digitalmars-d-announce]

On 7/23/17 9:50 AM, Moritz Maxeiner wrote:

On Sunday, 23 July 2017 at 02:15:18 UTC, Steven Schveighoffer wrote:


struct StrawmanRange(T)
{
  ...
  void popFront() {}
}


How do you deal with ranges where `.popFront` returns the old front 
element (`.front` requires copying the front element if the caller wants 
to store it, `.popFront` can move it)?


As I said in the talk, there's not an actual library for this, it's just 
an idea. I would say you could probably return Any here, and infer that 
means the return type doesn't matter. Or you could have an attribute. 
The idea is to communicate in some way to the "implements" function how 
to create the right constraint.


-Steve

Re: static foreach is now in github master

[Steven Schveighoffer via Digitalmars-d-announce]

On 7/22/17 5:26 PM, Seb wrote:

On Saturday, 22 July 2017 at 21:13:47 UTC, Steven Schveighoffer wrote:

On Thursday, 20 July 2017 at 21:02:20 UTC, Seb wrote:


Oh because I thought run.dlang.io wasn't using `rdmd`.
However, there was a minor glitch today when I added support for 
flags and stdin to the docker images [2]. The good news is that it 
has been fixed [2] & everything should behave as usual.

Sorry for the inconvenience and continued happy hacking!

[1] https://github.com/dlang-tour/core-exec/pull/2
[2] https://github.com/dlang-tour/core-exec/pull/4



Now:
Compilation or running program took longer than 25 seconds. Aborted!

Hmm, seems to be a temporary error. It works fine for me. Are you still 
experiencing this?


Just tried again, now working (and displaying only one list of numbers) 
thanks.


-Steve

Re: Boston D Meetup: Strawman Structs

[Steven Schveighoffer via Digitalmars-d-announce]

On 7/2/17 6:35 AM, Steven Schveighoffer wrote:
I'll have a short presentation on a weird trick I discovered while 
writing some MySQL serialization code. Hope you can attend!


https://www.eventbrite.com/e/d-lang-presentation-strawman-structs-tickets-35120523431 


I've set up a live stream for this. No guarantees of the quality, it 
will be audio + slideshow.


Waiting for people to arrive, so probably won't start until at least 6:30.

https://www.youtube.com/watch?v=ZxzczSDaobw

-Steve

Re: static foreach is now in github master

[Steven Schveighoffer via Digitalmars-d-announce]

On 7/20/17 4:08 PM, Seb wrote:

On Thursday, 20 July 2017 at 19:53:46 UTC, Jack Stouffer wrote:

On Tuesday, 18 July 2017 at 15:46:04 UTC, Seb wrote:

https://is.gd/1TCQOh


Hmmm, that code is printing


0
1
2
3
0
1
2
3


for me. Shouldn't it just be printing once?


I bet you are using `rdmd`?
It runs dmd twice on your main file ;-)
See also:

https://issues.dlang.org/process_bug.cgi
https://github.com/dlang/tools/pull/191
https://github.com/dlang/tools/pull/194 (sadly this was reverted)


I'm just clicking on the run button on the web page you linked to. How 
do I not run rdmd there?


-Steve

Re: static foreach is now in github master

[Steven Schveighoffer via Digitalmars-d-announce]

On 7/20/17 3:53 PM, Jack Stouffer wrote:

On Tuesday, 18 July 2017 at 15:46:04 UTC, Seb wrote:

https://is.gd/1TCQOh


Hmmm, that code is printing


0
1
2
3
0
1
2
3


for me. Shouldn't it just be printing once?


I think it's because it's using rdmd, and that runs dmd once to generate 
dependencies, and one more time to compile.


It's not specific to static foreach or the new compiler:

https://is.gd/g6WPyv

-Steve

Re: DIP 1010--Static foreach--Accepted

[Steven Schveighoffer via Digitalmars-d-announce]

On 7/17/17 9:23 AM, Petar Kirov [ZombineDev] wrote:

On Monday, 17 July 2017 at 12:38:27 UTC, Steven Schveighoffer wrote:

On 7/16/17 1:04 PM, Andrei Alexandrescu wrote:

On 7/16/17 9:10 AM, Mike Parker wrote:
Congratulations to Timon Gehr. Not only was his "Static foreach" DIP 
accepted, it picked up a good deal of praise from Walter & Andrei.


Indeed. Kudos to Timon (and thanks Mike for driving the process). 
This is a well done DIP that many others could draw inspiration from. 
-- Andrei


What is the resolution of how break statements affect static 
foreach/foreach?


i.e. this section:

"As some consider this to be potentially confusing, it has been 
suggested that break and continue directly inside static foreach 
should instead be compiler errors and require explicit labels. This 
DIP leaves this decision to the language authors, but recommends the 
above semantics."




I think the only reliable way is to not use jumps (goto, break, 
continue) at all.

E.g. if you want to unroll the following loop:

foreach (x; someRange)
{
 if (x.isSpecial)
 break;

 x.writeln();
}

You would need to guard every statement/declaration:

static foreach (x; someRange)
 static if (!x.isSpecial)
 x.writeln();


My concern is that the proposal asked for break to apply to the runtime 
construct that surrounds the loop. So for instance, break would apply to 
the switch statement outside the static foreach.


This differs from current static looping (i.e. foreach over a tuple), 
where break applies to the foreach.


I'm not concerned with breaking out of the loop. I agree that the 
proposed behavior is the best choice. However, it's confusing given 
existing behavior that doesn't do that.


-Steve

Re: DIP 1010--Static foreach--Accepted

[Steven Schveighoffer via Digitalmars-d-announce]

On 7/16/17 9:10 AM, Mike Parker wrote:
Congratulations to Timon Gehr. Not only was his "Static foreach" DIP 
accepted, it picked up a good deal of praise from Walter & Andrei. I've 
added my summary to the Review section of the DIP, but I'll quote it 
here in full:


"This DIP was accepted by the language authors. Both Proposal 1 and 
Proposal 2 were accepted. Evaluation of the suggested future 
improvements has been put off until some future date when sufficient 
experience with the implementation has been accumulated.


Regarding Proposal 1, they find it integrates well with the rest of the 
language and falls within the spirit of D. They see it more as the 
removal of a limitation than the addition of a feature, and like that it 
reuses the syntax and semantics of existing language entities (`alias` 
and `enum`). They see Proposal 2 as the core of the DIP, finding that it 
is well-motivated and liking that it reuses elements of Proposal 1.


On the whole, they believe that this DIP obeys the rule of least 
astonishment in that most of the examples work as expected and are easy 
to understand by lowering to the pre-DIP language. They also say that 
the examples are a good sanity check to ensure that the feature fulfills 
its envisioned applications, and that the DIP is exceptionally well 
written. This should be read as a note to future DIP authors that they 
will not be wrong to use this DIP as a model."


https://github.com/dlang/DIPs/blob/master/DIPs/DIP1010.md


Awesome! Super glad and looking forward to this in 2.076? ;)

-Steve

Re: DIP 1010--Static foreach--Accepted

[Steven Schveighoffer via Digitalmars-d-announce]

On 7/16/17 1:04 PM, Andrei Alexandrescu wrote:

On 7/16/17 9:10 AM, Mike Parker wrote:
Congratulations to Timon Gehr. Not only was his "Static foreach" DIP 
accepted, it picked up a good deal of praise from Walter & Andrei.


Indeed. Kudos to Timon (and thanks Mike for driving the process). This 
is a well done DIP that many others could draw inspiration from. -- Andrei


What is the resolution of how break statements affect static 
foreach/foreach?


i.e. this section:

"As some consider this to be potentially confusing, it has been 
suggested that break and continue directly inside static foreach should 
instead be compiler errors and require explicit labels. This DIP leaves 
this decision to the language authors, but recommends the above semantics."


-Steve

Re: Hiring D programmers (with cryptography and blockchain knowledge are preferred)

[Steven Schveighoffer via Digitalmars-d-announce]

On 7/12/17 12:40 AM, Vitor Rozsas wrote:
* First of all, does Dlang.org have it's own website for hiring D 
programmers or offering D programming services? If not, it should!


Hello!
I need a project, and I want it done with D (please note that it will be 
open-sourced, but I'll pay for the first functioning version).
It is supposed to be useful for users of the project AND for learners of 
D (so lots of comments in the source code are actually encouraged!).


It's a social media. More specifically, an incensurable social media; 
all it's posts will be stored in a blockchain, and this will be copied 
and distributed through the world. I had the idea after seeing that many 
political posts were being removed from Facebook and Twitter. They are 
controlling people's opinions and I don't like it. People should be free 
to say whatever they want, this is freedom of speech.


Have you heard of https://gab.ai ? They are doing something similar (in 
terms of providing an uncensored platform).


-Steve

Re: Released vibe-core 1.0.0 and vibe.d 0.8.0

[Steven Schveighoffer via Digitalmars-d-announce]

On 7/10/17 8:11 AM, Sönke Ludwig wrote:

BTW, @CyberShadow, I originally sent this using a NG client, but the 
thread never appeared on forum.dlang.org


Even this one isn't there... Should be here: 
http://forum.dlang.org/post/mmfrsonxrfxwltkfv...@forum.dlang.org


-Steve

Re: Go Your Own Way (Part One: The Stack)

[Steven Schveighoffer via Digitalmars-d-announce]

On 7/7/17 9:51 PM, Mike Parker wrote:

On Saturday, 8 July 2017 at 01:28:59 UTC, Walter Bright wrote:

On 7/7/2017 4:35 PM, Nicholas Wilson wrote:
It's an intrinsic in LDC. We can certainly drop the per platform and 
move to a per compiler definition instead.


It's already there under:

version (DigitalMars)


I read this as CRuntime_DigitalMars, which prompted a search that led me 
to a page at MSDN on _alloca, which gave me a compiler error when I 
prototyped it, which led to my prototyping alloca for CRuntime_Microsoft 
and finding success, which has now confirmed my worry that publishing 
without a review was a bad idea. I've updated the post. Thanks!


Ha! as someone who doesn't regularly develop on Windows, I didn't even test.

I should have known better, as I've used alloca in druntime, and that 
wouldn't work if it didn't build on Win64.


-Steve

Re: Go Your Own Way (Part One: The Stack)

[Steven Schveighoffer via Digitalmars-d-announce]

On 7/7/17 4:10 PM, Walter Bright wrote:

On 7/7/2017 12:38 PM, Steven Schveighoffer wrote:
Which would mean that the lack of alloca prototype on Windows is a 
straight up bug (the fact that you can just add the declaration and it 
works is pretty good proof).


It's in core.stdc.stdlib



Since it's an intrinsic (as confirmed by you), maybe we can just drop 
the version conditions? The compiler will always generate it, regardless 
of C lib, right? I'll do the PR if you agree (just want to make sure I 
understand your statements about it).


-Steve

Re: Go Your Own Way (Part One: The Stack)

[Steven Schveighoffer via Digitalmars-d-announce]

On 7/7/17 3:36 PM, Steven Schveighoffer wrote:


I thought alloca was an intrinsic? Which means that the compiler 
generates inline code to add to the stack.


Which would mean that the lack of alloca prototype on Windows is a 
straight up bug (the fact that you can just add the declaration and it 
works is pretty good proof).


-Steve

Re: Go Your Own Way (Part One: The Stack)

[Steven Schveighoffer via Digitalmars-d-announce]

On 7/7/17 8:59 AM, Mike Parker wrote:
This is my latest post in the GC series. I had promised the next one 
would look at non-GC allocation strategies, but as it got longer and 
longer I decided to break it up into two parts. This part covers stack 
allocations. The next one will deal with non-GC heap allocations.


If my luck holds out, we're about to see a flurry of guest posts and 
collaborations over the next few weeks. If that pans out, I expect to 
publish the part two in mid-late August.


The blog:
https://dlang.org/blog/2017/07/07/go-your-own-way-part-one-the-stack/

Reddit:
https://www.reddit.com/r/programming/comments/6ltfwx/go_your_own_way_part_one_of_two_on_nongc/ 



I thought alloca was an intrinsic? Which means that the compiler 
generates inline code to add to the stack.


I would think it has to do this, since actually calling a function would 
generate a new stack frame.


-Steve

Re: Boston D Meetup: Strawman Structs

[Steven Schveighoffer via Digitalmars-d-announce]

On 7/2/17 6:35 AM, Steven Schveighoffer wrote:
I'll have a short presentation on a weird trick I discovered while 
writing some MySQL serialization code. Hope you can attend!


https://www.eventbrite.com/e/d-lang-presentation-strawman-structs-tickets-35120523431 


I've moved this to Friday to accommodate more people.

-Steve

Boston D Meetup: Strawman Structs

[Steven Schveighoffer via Digitalmars-d-announce]

I'll have a short presentation on a weird trick I discovered while 
writing some MySQL serialization code. Hope you can attend!


https://www.eventbrite.com/e/d-lang-presentation-strawman-structs-tickets-35120523431

-Steve

Re: daii - allocator-friendly closures and raii

[Steven Schveighoffer via Digitalmars-d-announce]

On 6/23/17 4:24 PM, Boris-Barboris wrote:

On Friday, 23 June 2017 at 20:13:07 UTC, ag0aep6g wrote:

You've got bad `@trusted`s:


Ty, I misunderstood the concept. I guess in a code like this it's mostly 
@system anyways, too many indirections to control safety level. I'm 
probably gonna remove most of the attributes.


The best advice is to leave @safe and @trusted and @system out of any 
templates. @safe will be inferred if everything is indeed safe. To prove 
that it's actually @safe, use a @safe unittest.


For places where things are safe, but the compiler can't prove it, then 
you pull out the @trusted attribute. But be very very careful -- as 
ag0aep6g says, there are often many hidden calls that can be @system, 
and in those cases you have just broken the guarantee. Only use @trusted 
where you know everything about every type that is used inside the call.


-Steve

Re: Inside D's GC blog article on hacker news front page

[Steven Schveighoffer via Digitalmars-d-announce]

On 6/20/17 7:59 AM, Gary Willoughby wrote:

Inside D's GC blog article currently No.3 on hacker news

Here's the article, visit hacker news to read the comments.

http://olshansky.me/gc/runtime/dlang/2017/06/14/inside-d-gc.html


Awesome. Dmitry, Martin, let me know if you need any help (especially 
with array runtime stuff), I would LOVE to see the GC get better.


-Steve

Re: Boston D Meetup for 6/9

[Steven Schveighoffer via Digitalmars-d-announce]

On 6/5/17 7:53 AM, Steven Schveighoffer wrote:

Hi fellow Boston D enthusiasts. We are going to have another meetup at
the Street in Chestnut Hill this Friday. Andrei and I will be there,
hope you can join us! Please RSVP on the eventbrite page:

https://www.eventbrite.com/e/monthly-boston-d-get-together-tickets-35120523431


This event is cancelled, I will try to reschedule for another day.

-Steve

Re: Compile-Time Sort in D

[Steven Schveighoffer via Digitalmars-d-announce]

On 6/9/17 10:49 AM, Stefan Koch wrote:

On Friday, 9 June 2017 at 12:15:50 UTC, Steven Schveighoffer wrote:

 [it] can use the *actual* i/o routines [at compile-time] you would
use at runtime is pretty impressive.

Stefan would have a field day with this power :)


Infact I think this would scale pretty badly.
I do not want to debug some ctfe which loads dlls and does god what to
the environment.
Even the restricted form of ctfe D supports is pretty hard to get right.
If I'd had to worry about an interface to runtime code I'd be a little
unhappy.


I kind of remember you saying at dconf2016 "If only CTFE could write to 
the filesystem, I could fully support sqlite at compile time!"


or something like that.

At least in terms of i/o printing to the console or whatnot, it would be 
cool to be able to do so at compile-time just directly with writeln. As 
of now, a CTFE function can't call writeln, and it also can't 
pragma(msg, ...) because it has to be written as a runtime function.


-Steve

Re: Compile-Time Sort in D

[Steven Schveighoffer via Digitalmars-d-announce]

On 6/7/17 5:47 PM, John Carter wrote:

On Monday, 5 June 2017 at 14:23:34 UTC, Mike Parker wrote:

https://dlang.org/blog/2017/06/05/compile-time-sort-in-d/


Seems like you have inspired people...

http://blog.zdsmith.com/posts/compiletime-sort-in-nim.html




That is kind of neat. While I can say that D can perform technically the 
same feat via pragma(msg, ...) and importing a file directly (would 
leave a comment on the blog, but there isn't a spot for it), the fact 
that you can execute arbitrary code in a block at compile time that can 
use the *actual* i/o routines you would use at runtime is pretty impressive.


Stefan would have a field day with this power :)

-Steve

Boston D Meetup for 6/9

[Steven Schveighoffer via Digitalmars-d-announce]

Hi fellow Boston D enthusiasts. We are going to have another meetup at 
the Street in Chestnut Hill this Friday. Andrei and I will be there, 
hope you can join us! Please RSVP on the eventbrite page:


https://www.eventbrite.com/e/monthly-boston-d-get-together-tickets-35120523431


-Steve

Re: Faster Command Line Tools in D

[Steven Schveighoffer via Digitalmars-d-announce]

On 5/31/17 1:09 AM, Patrick Schluter wrote:

In any case, you can download the dataset from [1] if you like. There
are several 100 Mb big zip files containing a collection of tmx files
(translation memory exchange) with European Legislation. The files
contain multi-alignment texts in up to 24 languages. The files are
encoded in UCS-2 little-endian. I know for a fact (because I compiled
the data) that they don't contain characters outside of the BMP. The
data is public and can be used freely (as in beer).
When I get some time, I will try to port the java app that is
distributed with it to D (partially done yet).

[1]:
https://ec.europa.eu/jrc/en/language-technologies/dgt-translation-memory


Thanks, I'll bookmark it for later use.

-Steve

Re: Faster Command Line Tools in D

[Steven Schveighoffer via Digitalmars-d-announce]

On 5/30/17 5:57 PM, Patrick Schluter wrote:

On Tuesday, 30 May 2017 at 21:18:42 UTC, Steven Schveighoffer wrote:

On 5/26/17 11:20 AM, John Colvin wrote:

On Friday, 26 May 2017 at 14:41:39 UTC, John Colvin wrote:

[...]


This version also has the advantage of being (discounting any bugs in
iopipe) correct for arbitrary unicode in all common UTF encodings.


I worked a lot on making sure this works properly. However, it's
possible that there are some lingering issues.

I also did not spend much time optimizing these paths (whereas I spent
a ton of time getting the utf8 line parsing as fast as it could be).
Partly because finding things other than utf8 in the wild is rare, and
partly because I have nothing to compare it with to know what is
possible :)


If you want UCS-2 (aka UTF-16 without surrogates) data I can give you
gigabytes of files in tmx format.


The data I can (and have) generated from UTF-8 data. I have tested my 
byLine parser to make sure it properly splits on "interesting" code 
points in all widths. UTF-16 data without surrogates should probably 
work fine. I haven't tuned it though like I tuned the UTF-8 version. Is 
there a memchr for wide characters? ;)


What I really haven't done is compared my line parsing code with 
multi-code-unit delimiters against one that can do the same thing. I 
know Phobos and C FILE * really can't do it. I haven't really looked at 
all in C++, so I should probably look there before giving up.


-Steve

Re: Faster Command Line Tools in D

[Steven Schveighoffer via Digitalmars-d-announce]

On 5/26/17 11:20 AM, John Colvin wrote:

On Friday, 26 May 2017 at 14:41:39 UTC, John Colvin wrote:

I spent some time fiddling with my own manual approaches to making
this as fast, wasn't satisfied and so decided to try using Steven's
iopipe (https://github.com/schveiguy/iopipe) instead. Results were
excellent.

https://gist.github.com/John-Colvin/980b11f2b7a7e23faf8dfb44bd9f1242


This version also has the advantage of being (discounting any bugs in
iopipe) correct for arbitrary unicode in all common UTF encodings.


I worked a lot on making sure this works properly. However, it's 
possible that there are some lingering issues.


I also did not spend much time optimizing these paths (whereas I spent a 
ton of time getting the utf8 line parsing as fast as it could be). 
Partly because finding things other than utf8 in the wild is rare, and 
partly because I have nothing to compare it with to know what is possible :)


-Steve

Re: Faster Command Line Tools in D

[Steven Schveighoffer via Digitalmars-d-announce]

On 5/26/17 10:41 AM, John Colvin wrote:

On Wednesday, 24 May 2017 at 13:39:57 UTC, Mike Parker wrote:

Some of you may remember Jon Degenhardt's talk from one of the Silicon
Valley D meetups, where he described the performance improvements he
saw when he rewrote some of eBay's command line tools in D. He has now
put the effort into crafting a blog post on the same topic, where he
takes D version of a command-line tool written in Python and
incrementally improves its performance.

The blog:
https://dlang.org/blog/2017/05/24/faster-command-line-tools-in-d/

Reddit:
https://www.reddit.com/r/programming/comments/6d25mg/faster_command_line_tools_in_d/



I spent some time fiddling with my own manual approaches to making this
as fast, wasn't satisfied and so decided to try using Steven's iopipe
(https://github.com/schveiguy/iopipe) instead. Results were excellent.

https://gist.github.com/John-Colvin/980b11f2b7a7e23faf8dfb44bd9f1242


nice! hm

/** something vaguely like this should be in iopipe, users shouldn't 
need to write it */
auto ref runWithEncoding(alias process, FileT, Args...)(FileT file, auto 
ref Args args)


stealing for iopipe, thanks :) I'll need to dedicate another slide to you...



On my machine:
python takes a little over 20s, pypy wobbles around 3.5s, v1 from the
blog takes about 3.9s, v4b took 1.45s, a version of my own that is
hideous* manages 0.78s at best, the above version with iopipe hits below
0.67s most runs.

Not bad for a process that most people would call "IO-bound" (code for
"I don't want to have to write fast code & it's all the disk's fault").

Obviously this version is a bit more code than is ideal, iopipe is
currently quite "barebones", but I don't see why with some clever
abstractions and wrappers it couldn't be the default thing that one does
even for small scripts.


The idea behind iopipe is to give you the building blocks to create 
exactly the pipeline you need, without a lot of effort. Once you have 
those blocks, then you make higher level functions out of it. Like you 
have above :)


BTW, there is a byLineRange function that handles slicing off the 
newline character inside iopipe.textpipe.


-Steve

Re: Thank you Sociomantic for hosting DConf!

[Steven Schveighoffer via Digitalmars-d-announce]

On 5/9/17 6:17 AM, Martin Tschierschke wrote:

On Tuesday, 9 May 2017 at 08:18:45 UTC, Walter Bright wrote:

http://dconf.org/2017/index.html

This was a huge success, from the full house, to the great talks, the
cameraderie, and to the tsunami of Pull Requests that resulted from
Sunday's hackathon!

(Definitely the post-conference hackathon will become a standard part
of the schedule!)

I hope everyone who attended had a pleasant journey back home.

And now, back to work! Looking forward to next year.

Yes, thank you everybody, who made this event happen.

Thank you, that it was in D. (short for Germany (Deutschland))
So it was easy to attend coming from Hamburg.

Specially, a big thank you to all the speakers, sharing their D experience.

Stay tuned for the announcement of the first great upcoming D Meet-up in
Hamburg :D

Last wish: Please change the text on the home page :)

  DConf 2017 is coming up: May 4-7 in Berlin, Germany.
  Secure your seat before it's sold out!


It's on github, where's your PR? ;)

Actually, Vladimir already obliged.

https://github.com/dlang/dconf.org/pull/201

-Steve

Re: Working code in an upcoming PR by Timon Gehr

[Steven Schveighoffer via Digitalmars-d-announce]

On 5/7/17 7:03 PM, Stanislav Blinov wrote:

On Sunday, 7 May 2017 at 16:57:58 UTC, Andrei Alexandrescu wrote:

Zoom in on the screen for a nice surprise! http://imgur.com/a/qjI4l --
Andrei


I see only unsurprising Jpeg artifacts and not much more :)
It's too low resolution to make anything out.


I think I know :) Timon was telling me about it.

It's a PR to add static foreach to dmd.

-Steve

iopipe on github

[Steven Schveighoffer via Digitalmars-d-announce]

For anyone interested in iopipe, I have updated my github repository for 
the iopipe[1] library. It's still not IMO ready for a dub link, as I 
want to polish some more. But at least the code shown in my 
presentation[2] will compile.


I also added the very incomplete and under-tested jsoniopipe[3] repository

-Steve

[1] https://github.com/schveiguy/iopipe
[2] http://dconf.org/2017/talks/schveighoffer.html
[3] https://github.com/schveiguy/jsoniopipe

Boston DLang Meetup Friday 4/21

[Steven Schveighoffer via Digitalmars-d-announce]

We will have one more meetup before the conference, hope you can attend!

https://www.eventbrite.com/e/monthly-boston-d-get-together-tickets-33731308251

-Steve

Re: dmd Backend converted to Boost License

[Steven Schveighoffer via Digitalmars-d-announce]

On 4/7/17 11:14 AM, Walter Bright wrote:

https://github.com/dlang/dmd/pull/6680

Yes, this is for real! Symantec has given their permission to relicense
it. Thank you, Symantec!


Awesome news!

As a compiler-writer no-nothing, does this have any implications on the 
various back-ends gaining ideas/code from each other? That is, is it 
possible we see LDC compile times go down, or DMD optimizations get better?


I hope you tell the story of how this came about at Dconf :)

-Steve

Re: Dlang Boston Meetup - Hack-a-thon

[Steven Schveighoffer via Digitalmars-d-announce]

On 3/24/17 2:20 PM, Steven Schveighoffer wrote:

For those D enthusiasts living in or around Boston, I've scheduled a
mini hack-a-thon for next Friday 3/31 in the Back Bay. Would be great to
see you all there!

Details here:
https://www.eventbrite.com/e/dlang-boston-hack-a-thon-tickets-33151627410



It seems mother nature doesn't like Boston D meetups! However, I'm still 
planning on having this, as despite NH getting over a foot of snow 
overnight, I think Boston is getting mostly rain. See you all there tonight!


-Steve

Dlang Boston Meetup - Hack-a-thon

[Steven Schveighoffer via Digitalmars-d-announce]

For those D enthusiasts living in or around Boston, I've scheduled a 
mini hack-a-thon for next Friday 3/31 in the Back Bay. Would be great to 
see you all there!


Details here: 
https://www.eventbrite.com/e/dlang-boston-hack-a-thon-tickets-33151627410


I will cross post to meetup.com in a bit.

-Steve

Re: excel-d v0.0.1 - D API to write functions callable from Excel

[Steven Schveighoffer via Digitalmars-d-announce]

On 3/20/17 4:09 PM, Atila Neves wrote:

http://code.dlang.org/packages/excel-d

This dub package allows D code to be called from Excel. It uses
compile-time reflection to register the user's code in an XLL (a DLL
loaded by Excel) so no boilerplate is necessary. Not even `DllMain`! It
works like this:


If I wanted to replace our horrifying web queries from Excel with this, 
I'm assuming I could? That would be awesome.


-Steve

Re: DConf 2017 Hotel - book now!

[Steven Schveighoffer via Digitalmars-d-announce]

On 3/14/17 12:39 PM, Bastiaan Veelo wrote:

On Saturday, 4 March 2017 at 20:08:39 UTC, Vladimir Panteleev wrote:

On Thursday, 2 March 2017 at 02:24:50 UTC, Walter Bright wrote:

http://www.ibis.com/gb/hotel-5694-ibis-berlin-neukoelln/index.shtml

Last year, some people booked late and it was full and they had to
stay at another hotel.


Aaand it's sold out. 2 months before the conference. Wow :)


I just booked Erlanger Hof. It too is filling up fast.


That was booked when I tried. Anyone else staying at the Hotel Ludwig 
Van Beethoven (just booked that one)?


-Steve

Re: DConf 2017 Hotel - book now!

[Steven Schveighoffer via Digitalmars-d-announce]

On 3/2/17 4:33 AM, Chris wrote:

On Thursday, 2 March 2017 at 02:24:50 UTC, Walter Bright wrote:

http://www.ibis.com/gb/hotel-5694-ibis-berlin-neukoelln/index.shtml

Last year, some people booked late and it was full and they had to
stay at another hotel.


Maybe someone could post a description of how to get there from the
airport. I remember last year there was a detailed description with
pictures etc. And beware of Berlin taxi drivers, you might get fleeced.
Make sure they have a taxometer and that the taxi license is on display.
If in doubt, get out!


I used the bus + train, it was quite easy. Don't remember the exact 
stops, but I just used google maps to tell me the info.


I recommend before you arrive, to go into google maps on your mobile 
device, and store the Berlin map as an offline area, especially if you 
do not have coverage. Also, you can pre-plan your trip if you know when 
your plane will arrive and figure out what the bus/train schedule is.


For those not used to the transportation system there, you buy your 
ticket, and then validate it. If you don't validate your ticket, it 
doesn't count. I was thrown off that nobody really ever checked my 
tickets, but I guess you get into trouble if you don't have a validated 
ticket.


The bus terminal had machines that allowed you to buy the ticket with 
cash or credit card I believe, and the same machines validate your 
ticket as well.


-Steve

Re: DConf 2017 speaking proposals due Feb 28

[Steven Schveighoffer via Digitalmars-d-announce]

On 2/22/17 6:24 PM, Walter Bright wrote:

Feb 28 is coming up fast!


Website says 2/26. Which is correct?

-Steve

Re: Boston D Meetup 2/9: `shared` Experiences

[Steven Schveighoffer via Digitalmars-d-announce]

On 1/30/17 4:48 PM, Steven Schveighoffer wrote:

Attention fellow Boston D enthusiasts: I have set up a meetup for
February, and Michael Coulombe will give a presentation on his
experiences with shared.

As before, this will be at the Capital One Cafe in the back bay (across
from Prudential center).

Hope to see you all there!

https://www.meetup.com/Boston-area-D-Programming-Language-Meetup/events/237324049/




Here is the live stream: https://www.youtube.com/user/kirsybuu/live

-Steve

Re: Release D 2.073.1

[Steven Schveighoffer via Digitalmars-d-announce]

On 2/16/17 12:35 PM, Martin Nowak wrote:

Glad to announce D 2.073.1.

http://dlang.org/download.html

This point release fixes a few issues over 2.073.0, see the changelog
for more details.

http://dlang.org/changelog/2.073.1.html


Sorry, I was late seeing the beta announcements. Can you look at 
https://github.com/dlang/druntime/pull/1764 ?


If there isn't going to be a 2.073.2 release, then this should be 
closed, and I'll just update the code to use the .abort option in the 
master branch.


-Steve

Re: Boston D Meetup 2/17: `shared` Experiences

[Steven Schveighoffer via Digitalmars-d-announce]

On 2/8/17 8:58 PM, Steven Schveighoffer wrote:

On 1/30/17 4:48 PM, Steven Schveighoffer wrote:

Attention fellow Boston D enthusiasts: I have set up a meetup for
February, and Michael Coulombe will give a presentation on his
experiences with shared.

As before, this will be at the Capital One Cafe in the back bay (across
from Prudential center).

Hope to see you all there!

https://www.meetup.com/Boston-area-D-Programming-Language-Meetup/events/237324049/



FYI, this has been postponed, we are supposed to get 8-12 inches of snow
lasting all day tomorrow.

I have rescheduled for next Friday, 2/17, which is the only day I could
book.


Hi all, I am switching from using Meetup to Eventbrite, which is free 
and accomplishes pretty much the same thing as meetup.


I will still post everything to the meetup group for the next few months 
(my subscription runs out in May), but will look to track pretty much 
everything on EventBrite.


Here is the cross post for tomorrow's event: 
https://www.eventbrite.com/e/d-lang-presentation-shared-experiences-tickets-32132598467


-Steve

Re: Boston D Meetup 2/17: `shared` Experiences

[Steven Schveighoffer via Digitalmars-d-announce]

On 1/30/17 4:48 PM, Steven Schveighoffer wrote:

Attention fellow Boston D enthusiasts: I have set up a meetup for
February, and Michael Coulombe will give a presentation on his
experiences with shared.

As before, this will be at the Capital One Cafe in the back bay (across
from Prudential center).

Hope to see you all there!

https://www.meetup.com/Boston-area-D-Programming-Language-Meetup/events/237324049/


FYI, this has been postponed, we are supposed to get 8-12 inches of snow 
lasting all day tomorrow.


I have rescheduled for next Friday, 2/17, which is the only day I could 
book.


-Steve

Re: mysql-native: preview2

[Steven Schveighoffer via Digitalmars-d-announce]

On 2/2/17 1:50 AM, Suliman wrote:

On Thursday, 2 February 2017 at 05:28:10 UTC, Nick Sabalausky wrote:

Made a couple more long-needed changes while I'm at it:

https://github.com/Abscissa/mysql-native-experimental
Tag: v0.2.0-preview2

- For better clarity, renamed `mysql.db.MysqlDB` to
`mysql.pool.MySqlPool`.

- Package mysql.connection no longer acts as a package.d, publicly
importing other modules. To import all of mysql-native, use `import
mysql;`


Thanks! Could you explain about pool. I googled about it, and still
can't understand when it up new connections?

How can I imagine what connection is? Because without it hard to
understand what difference between connections with and without pool.

Am I right understand that if I use pool I can create connection
instance one time in DB class constructor end every new connection will
be created on demand?


Just to answer some of this, because I had questions about the pool as well.

The ConnectionPool is a mechanism to allow a limited resource (or a 
resource you want to limit, depending how you look at it) to be pooled 
for use. It's basically a free-list. It also abstracts away the details 
of opening a connection (i.e. server ip, username, password). It's nice 
because it makes opening a connection cleaner and straightforward.


The resulting connection can only be used in one fiber at a time, and 
the connection pool itself can only be used in one thread ever (there is 
no sharing of connection pools between threads). The resulting 
connection struct is reference counted, so it automatically releases 
back to the pool when it goes out of scope.


One issue I had with MysqlDB (now MySqlPool) is that it doesn't allow 
you to actually put a limit on the connections. In other words, you 
can't say "only allow 50 simultaneous connections". The effect is that 
you save the connection initialization, but you can't put a hard cap on 
connections used in your thread. If you have 10,000 fibers running at 
once, then you may get 10,000 connections to the database that are left 
open. If each of those is a socket, you are consuming a lot of resources 
during down times.


Not to mention that the allocation of the 10,000th connection has to 
first go on a linear search through the 9,999 other connections to find 
an open one (this seems like it could be solved better with a 
linked-list freelist?).


See here: https://github.com/mysql-d/mysql-native/issues/74

BTW, I solved this by copying MysqlDB into my local project and adding 
the appropriate parameter to the constructor :)


-Steve

Boston D Meetup 2/9: `shared` Experiences

[Steven Schveighoffer via Digitalmars-d-announce]

Attention fellow Boston D enthusiasts: I have set up a meetup for 
February, and Michael Coulombe will give a presentation on his 
experiences with shared.


As before, this will be at the Capital One Cafe in the back bay (across 
from Prudential center).


Hope to see you all there!

https://www.meetup.com/Boston-area-D-Programming-Language-Meetup/events/237324049/

-Steve

Re: Beta D 2.072.2-b1

[Steven Schveighoffer via Digitalmars-d-announce]

On 12/27/16 9:39 AM, Dicebot wrote:

On Tuesday, 27 December 2016 at 14:24:11 UTC, Steven Schveighoffer wrote:

Missing from the changelog is the cycle detection deprecation path
that I added here: https://github.com/dlang/druntime/pull/1720

This should give people more breathing room to remove detected cycles
by next release.


My understanding is that there is still a lot of manual labor in
changelog generation thus making separate PR to adjust
https://github.com/dlang/dlang.org/blob/stable/changelog/2.072.2_pre.dd
may help.


Done: https://github.com/dlang/dlang.org/pull/1538

-Steve

Re: Beta D 2.072.2-b1

[Steven Schveighoffer via Digitalmars-d-announce]

On 12/26/16 11:36 PM, Martin Nowak wrote:

First beta for the 2.072.2 point release.

This version resolves a number of regressions and bugs in the 2.072.1
release. Most prominently scope classes work again in @safe code,
various rdmd bugs were fixed, and -fPIC became default for all linux
64-bit binaries and packages in order to support PIE (default on Ubuntu
16.10 and hardened Gentoo).

http://dlang.org/download.html#dmd_beta
http://dlang.org/changelog/2.072.2.html

Please report any bugs at https://issues.dlang.org


Missing from the changelog is the cycle detection deprecation path that 
I added here: https://github.com/dlang/druntime/pull/1720


This should give people more breathing room to remove detected cycles by 
next release.


-Steve

Re: Boston Dlang Meetup December 15th

[Steven Schveighoffer via Digitalmars-d-announce]

On 11/29/16 9:42 AM, Steven Schveighoffer wrote:

Going to be at the Capital One Cafe again in the back bay. I'll give a
talk on how druntime is constructed.

Details here:
https://www.meetup.com/Boston-area-D-Programming-Language-Meetup/events/235904059/


And here is where the live stream will be, so I don't forget this time!

https://www.youtube.com/watch?v=gR3q_B4-0u4

See you all then!

-Steve

Boston Dlang Meetup December 15th

[Steven Schveighoffer via Digitalmars-d-announce]

Going to be at the Capital One Cafe again in the back bay. I'll give a 
talk on how druntime is constructed.


Details here: 
https://www.meetup.com/Boston-area-D-Programming-Language-Meetup/events/235904059/


I will post live stream details (before the live stream this time!) at 
some point, probably the day of. However, I would like to see more 
people come in person!


-Steve

Re: Boston D Language Meetup in Back Bay

[Steven Schveighoffer via Digitalmars-d-announce]

On 11/17/16 12:42 PM, John Colvin wrote:

On Thursday, 17 November 2016 at 16:28:08 UTC, Steven Schveighoffer wrote:

On 11/17/16 10:38 AM, John Colvin wrote:

On Thursday, 17 November 2016 at 13:59:25 UTC, Steven Schveighoffer
wrote:

[...]


Can't you use a template lambda alias argument to pushTo instead, so
then you can instantiate it inside pushTo?

something like
nullStream!char
.bufferedInput
.pushTo!(_ => _
.arrayCastPipe!ubyte
.outputFile("output.txt")
);
maybe?


I could do that. But I don't like it ;)


I don't think it's so bad, but fair enough


I can say the part I don't like is the _ => _ thing. Ugly. Other than 
that, it's actually quite nice syntax-wise.



I'm also concerned that using a lambda is going to confuse or prevent
optimization.


Why would you think that? If we can't trust the optimiser (dmd aside) to
inline a template lambda argument then phobos is totally screwed!


I admit this isn't a rational fear ;) I just have had experience with 
lambdas where this does happen. The fear part of my brain is warning me, 
but the memory part can't remember the specifics of when this happened...


What happens when you use a local variable in your lambda expression?

-Steve

Re: Boston D Language Meetup in Back Bay

[Steven Schveighoffer via Digitalmars-d-announce]

On 11/17/16 10:38 AM, John Colvin wrote:

On Thursday, 17 November 2016 at 13:59:25 UTC, Steven Schveighoffer wrote:

nullStream!char
   .bufferedInput
   .pushTo(
  arrayCastPipe!ubyte
  .outputFile("output.txt")
   );

But then the parameters to the "pushTo" hypothetical function don't
know what the source type is before calling. By inserting valves, I
get the equivalent thing, but the types all are passed down the chain
properly.


Can't you use a template lambda alias argument to pushTo instead, so
then you can instantiate it inside pushTo?

something like
nullStream!char
.bufferedInput
.pushTo!(_ => _
.arrayCastPipe!ubyte
.outputFile("output.txt")
);
maybe?


I could do that. But I don't like it ;)

I will note that Adrian Matoga's flod library has a different solution 
that I think is similar to this, but I don't understand it very well.


I'm also concerned that using a lambda is going to confuse or prevent 
optimization.


I think with some better naming, the push feature will look better.

-Steve

Re: Boston D Language Meetup in Back Bay

[Steven Schveighoffer via Digitalmars-d-announce]

On 11/17/16 7:32 AM, qznc wrote:

On Thursday, 17 November 2016 at 02:55:46 UTC, Meta wrote:

Thanks for recording the presentation, your IOPipe library is pretty
interesting.


+1

Especially for any parser, this looks like a great solution!


Thanks! I agree, I hope to prove that with some example implementations.


The output (valves) looks meh, though. I hope, you discover something
more elegant.


Explaining valves is more complex then actually using them. The neat 
thing about them is that I do not have to implement a push mechanism or 
rewrite any existing transform iopipes. And in general, valves don't 
have to really be involved with pushing. They are simply control points 
along the pipeline (but doing output by simulating push via a pull was 
the impetus for valves).


I will note that an obvious different solution (and one that I 
considered) is to encapsulate the entire output pipe into one call, 
something like:


nullStream!char
   .bufferedInput
   .pushTo(
  arrayCastPipe!ubyte
  .outputFile("output.txt")
   );

But then the parameters to the "pushTo" hypothetical function don't know 
what the source type is before calling. By inserting valves, I get the 
equivalent thing, but the types all are passed down the chain properly.


I'm thinking I will rename the holdingValve and holdingLoop functions, 
so that it's more clear that this results in a push mechanism. I'm still 
playing with the naming.


Eventually, the valve concept I think will be more justified when I have 
more building blocks available that can be used any way you wish.


-Steve

Re: Boston D Language Meetup in Back Bay

[Steven Schveighoffer via Digitalmars-d-announce]

On 11/16/16 6:34 PM, Steven Schveighoffer wrote:

On 11/13/16 6:51 PM, Steven Schveighoffer wrote:

On 11/4/16 12:02 PM, Steven Schveighoffer wrote:

Just announced:
https://www.meetup.com/Boston-area-D-Programming-Language-Meetup/events/235353279/




We are going to try a freely available conference room to have a
presentation. No details on the presentation yet (I will figure that out
soon), and probably no streaming this time.


I got streaming to work. Will post a link later, in case anyone is
interested.


I had one job...

Forgot to post the link BEFORE the live stream. In any case, it was 
recorded and is here: https://www.youtube.com/watch?v=dVuPgbRIljA


Sorry, please accept my shameful apology.

-Steve

Re: Boston D Language Meetup in Back Bay

[Steven Schveighoffer via Digitalmars-d-announce]

On 11/13/16 6:51 PM, Steven Schveighoffer wrote:

On 11/4/16 12:02 PM, Steven Schveighoffer wrote:

Just announced:
https://www.meetup.com/Boston-area-D-Programming-Language-Meetup/events/235353279/



We are going to try a freely available conference room to have a
presentation. No details on the presentation yet (I will figure that out
soon), and probably no streaming this time.


I got streaming to work. Will post a link later, in case anyone is 
interested.


-Steve

Re: Boston D Language Meetup in Back Bay

[Steven Schveighoffer via Digitalmars-d-announce]

On 11/4/16 12:02 PM, Steven Schveighoffer wrote:

Just announced:
https://www.meetup.com/Boston-area-D-Programming-Language-Meetup/events/235353279/


We are going to try a freely available conference room to have a
presentation. No details on the presentation yet (I will figure that out
soon), and probably no streaming this time.


UPDATE: This Wednesday (the 16th), we will have a meetup at the Capital 
One Cafe conference room in the Back Bay. I'll present a short overview 
of my iopipe library. Hope you can join us!


If everyone's up to it, we can go out after for drinks and/or food.

-Steve

Re: SecureD - A simple cryptography library for D

[Steven Schveighoffer via Digitalmars-d-announce]

On 11/12/16 8:15 PM, Adam Wilson wrote:

Hello DLang,

I wanted to announce that I have completed the bulk of the work on my
Cryptography library for D, SecureD. I was inspired to do this project
by Stan Drapkin and his Inferno.NET project, however, the two projects
NOT compatible.


[snip]


Let me know what you think!


I'm not a crypto guru or even a casual user. But I think it's very 
important that we have something like this for D, thanks for your work!


I know vibe.d uses crypto for https usage. Any ideas/comparison with 
that? Would the code look better with your lib instead? Would it be more 
secure? Having vibe.d as a consumer would be a huge boost to testing/usage.


-Steve

Re: Release D 2.072.0

[Steven Schveighoffer via Digitalmars-d-announce]

On 11/11/16 3:02 PM, jmh530 wrote:

On Friday, 11 November 2016 at 19:36:59 UTC, Nick Sabalausky wrote:


I've gone through a lot of compiler upgrades on a lot of D projects,
and in my experience, this "investigate and fix for the new dmd" has
always been trivial (aside from one instance where Phobos's standard
function deprecation policy wasn't followed).

Some things should certainly have a smooth transition path (like
above, when replacing a Phobos function with a different one), but
really, not everything needs to be.



They've talked about an auto-checker for dub packages. I suspect that
will go a long way to reducing regressions.


Actually, in this case, we knew this was going to break builds, and also 
in this case, the fix for user code is not trivial. Breaking a cycle 
involves breaking a module into multiple pieces, or putting the 
initialization code elsewhere.


Unfortunately, there's not much ways to do this fix in a graceful 
manner. This is a tougher one to swallow, and I don't think it's a 
normal case. The DRT options were added to ease transition.


-Steve

Re: Release D 2.072.0

[Steven Schveighoffer via Digitalmars-d-announce]

On 11/11/16 9:02 AM, Dicebot wrote:

On 11/11/2016 03:46 PM, Steven Schveighoffer wrote:

... or one can spend one extra hour to implement deprecation path and
the issue disappears completely.


There is a misunderstanding that the new cycle detection is an "upgrade"
of some kind. It's a bug fix.


There is no difference between a bug fix and "upgrade" in context of
deprecation path expectations. It affects robustness of package
ecosystem in the same way.


There is a subtle difference -- you weren't exactly "depending" on the 
buggy behavior, you didn't actually notice that the bug was there. In 
fact, you were depending on the cycle detection to find the cycles for 
you, and it was failing.


It would be like finding a flaw in the AA hashing behavior that allowed 
2 identical keys to get stored. Fix that bug, and it necessarily changes 
behavior, it may even break some code. Should we go through deprecation 
cycle for that?



I am still going to look into keeping both algorithms for this release
but don't view it as blocking regression.


It's not going to be easy. The code had to be completely rewritten, 
since the flaw in the original code was a design problem. You will 
likely have to run both algorithms separately, and only fail if both do.


You can probably use the same cycle printing code, as I separated that 
out (and now use a shortest-path algorithm to minimize the cycle size).


-Steve

Re: Release D 2.072.0

[Steven Schveighoffer via Digitalmars-d-announce]

On 11/11/16 9:06 AM, Rainer Schuetze wrote:



On 11.11.2016 14:42, Steven Schveighoffer wrote:



The option to ignore the cycles is there, added to allow for people to
use the new DMD even if cycles exist. However, it is a runtime switch,
which means you have to run it that way.



You can also embed the option into the executable. See the bottom of
https://dlang.org/spec/garbage.html#gc_config.


I didn't know that! Very nice, and a good mechanism to help those with 
deprecation issues -- if you put the oncycle=print in that list of 
options, then the new code will still run when a cycle is present, and 
old runtime will simply ignore that. No need to add the option when running.



Is there another place where --DRT-options are listed?


I don't think so. Probably a good idea to list somewhere. As there is no 
central processing of options (they are parsed, but not handled until 
requested), it's less obvious where all the usages are. I only found the 
GC options and maybe one other.


-Steve

Re: Release D 2.072.0

[Steven Schveighoffer via Digitalmars-d-announce]

On 11/11/16 8:30 AM, Dicebot wrote:

On Friday, 11 November 2016 at 13:21:40 UTC, Nick Sabalausky wrote:

Run the new dmd. If it fails, either fix your code or go temporarily
go back to the old dmd until you can fix your code.


D will never be considered production ready as pong as this attiude
remaind. Your described scenario in practice works like this:

- You decide to delay fix until you have time to investigate
- Half of users of your library you (or your colleagues) complain that
they can't upgrade their projects because you areso slow
- You desperately find time to do required fix which proves bavkwards
incompatible
- Now the other half of your users (colleagues) complain that your rush
to upgrade forces them to switch to immature compiler



If you remove cycles in your code, it will not flag cycles in the old 
compiler ;)



... or one can spend one extra hour to implement deprecation path and
the issue disappears completely.


There is a misunderstanding that the new cycle detection is an "upgrade" 
of some kind. It's a bug fix.


There is a path to use new DMD with your buggy code, just use 
--DRT-oncycle=ignore. It's just not the default.


-Steve

Re: Release D 2.072.0

[Steven Schveighoffer via Digitalmars-d-announce]

On 11/11/16 8:21 AM, Nick Sabalausky wrote:

On 11/11/2016 04:54 AM, Kagamin wrote:

On Thursday, 10 November 2016 at 13:58:56 UTC, Steven Schveighoffer
wrote:

Only possibility is just to ignore ALL cycles, and print them if any
are detected.


Run the new detector and if it fails, run the old one, if it succeeds,
print a message.


Or:

Run the new dmd. If it fails, either fix your code or go temporarily go
back to the old dmd until you can fix your code.



The option to ignore the cycles is there, added to allow for people to 
use the new DMD even if cycles exist. However, it is a runtime switch, 
which means you have to run it that way.


-Steve

Re: Release D 2.072.0

[Steven Schveighoffer via Digitalmars-d-announce]

On 11/10/16 8:26 AM, Dicebot wrote:

On 11/03/2016 05:51 PM, Steven Schveighoffer wrote:

On 11/3/16 10:49 AM, Johan Engelen wrote:

On Wednesday, 2 November 2016 at 15:13:43 UTC, anonymous wrote:

On Wednesday, 2 November 2016 at 15:08:26 UTC, anonymous wrote:


I confirm, dmd 2.072 can't build dmd 2.071.2, same error, but boot
since master straping works there's probably something that's been
fixed in one or two of these ddmd modules, likely a static ctor...


Maybe after this:

https://github.com/dlang/dmd/commit/1d0ab8b9c136e46bf449c506ca25d2c8a784f7b9#diff-b4674e7b5d3a44178526afdefc9aa368



ddmd.attribs was removed

https://github.com/dlang/dmd/commit/1d0ab8b9c136e46bf449c506ca25d2c8a784f7b9#diff-b4674e7b5d3a44178526afdefc9aa368L15



and it was also part of the cycle.


Thanks for the detective work.
I wonder where the bug is: in 2.071 or in 2.072 :)


Any cycles that are "newly discovered" were already there. What was
happening is that the runtime did not detect the cycle, and was
arbitrarily choosing an order for initializing these modules.


It does not justify immediate breaking change.



What should have been
done instead:

- Keep old behavior by default by default but print non-fatal runtime
message that cycles are detected.


This is not possible. Old behavior DID detect some cycles. The new 
algorithm detects ALL cycles, and handles them all in the same way. What 
you are asking is for cycles detected by old algorithm to fail, but ones 
that wouldn't have been detected to pass. Not to mention that the order 
of ctor execution is not guaranteed to be the same (i.e. some latent bug 
may be hiding there).


Only possibility is just to ignore ALL cycles, and print them if any are 
detected.



I presume I have to look for commits that implement
http://dlang.org/changelog/2.072.0.html#drt-oncycle to fixup this?


The PR for this was here: https://github.com/dlang/druntime/pull/1668

-Steve

Re: Boston D Language Meetup in Back Bay

[Steven Schveighoffer via Digitalmars-d-announce]

On 11/4/16 12:02 PM, Steven Schveighoffer wrote:

Just announced:
https://www.meetup.com/Boston-area-D-Programming-Language-Meetup/events/235353279/


We are going to try a freely available conference room to have a
presentation. No details on the presentation yet (I will figure that out
soon), and probably no streaming this time.


Due to a scheduling conflict, I had to move this to Wednesday the 16th.

-Steve

Boston D Language Meetup in Back Bay

[Steven Schveighoffer via Digitalmars-d-announce]

Just announced: 
https://www.meetup.com/Boston-area-D-Programming-Language-Meetup/events/235353279/


We are going to try a freely available conference room to have a 
presentation. No details on the presentation yet (I will figure that out 
soon), and probably no streaming this time.


-Steve

Re: Release D 2.072.0

[Steven Schveighoffer via Digitalmars-d-announce]

On 11/2/16 8:36 AM, Johan Engelen wrote:

On Tuesday, 1 November 2016 at 16:40:42 UTC, Andrei Alexandrescu wrote:

On 11/01/2016 11:41 AM, Johan Engelen wrote:

On Monday, 31 October 2016 at 01:27:08 UTC, Martin Nowak wrote:

Glad to announce D 2.072.0.


DMD 2.072.0 miscompiles/uncovers a bug in LDC, so I switched back to DMD
2.071.2 for CI testing. :(


Is there somebody working on that bug? Thanks. -- Andrei


LDC built with DMD 2.072.0 gives the following error when run:
object.Error@src/rt/minfo.d(356): Cyclic dependency between module
ddmd.traits and ddmd.cond
ddmd.traits* ->
ddmd.attrib ->
ddmd.cond* ->
ddmd.expression ->
ddmd.traits*


The issue is that DDMD has cycles, always has. But the cycle detection 
was broken. This is now fixed in 2.072. An unfortunate side effect from 
having broken cycle detection since 2011 is that many projects will now 
detect cycles. 2.072 is going to break a lot of code that was already 
"broken". I use scare quotes because likely the code is just fine, but 
the cycle detection is so broad that it's easy to get caught in the net.


The best answer is to somehow do better cycle detection (e.g. determine 
if there really are dependencies that break with cycles). We have some 
ideas, but nothing has been fleshed out yet.


-Steve

Re: Ever want to compile D on your Android phone? Well, now you can!

[Steven Schveighoffer via Digitalmars-d-announce]

On 10/29/16 8:55 PM, rikki cattermole wrote:

On 30/10/2016 10:47 AM, Mergul wrote:

Application always crash when I'm using android_app.savedState.

if (state.savedState != null) {
// We are starting with a previous saved state; restore from it.
engine.state = *cast(saved_state*)state.savedState; //crash!
}



Don't compare against null using =, compare using is.

if (state.savedState !is null) {


android_app.savedState appears to be defined here:

https://github.com/joakim-noah/android/blob/polish/android_native_app_glue.d#L56

It's a void *. So comparing against null with != is identical to !is.

There are actually cases where comparing against null with != is valid, 
and what you want exactly (e.g. comparing a string to null to check for 
empty string).


In this case, fixing the comparison is not the answer. What is happening 
is one of several things:


1. I don't know what type `engine` is, so if it's a pointer, then 
dereferencing the state member may be the culprit if engine is invalid.
2. If state is a pointer, then you could be crashing at the if statement 
(unlikely).

3. state or state.savedState isn't being properly initialized.
4. Something else (e.g. code generation error). Hope it's not this one.

-Steve

Boston D Meetup

[Steven Schveighoffer via Digitalmars-d-announce]

Announced on meetup.com: 
https://www.meetup.com/Boston-area-D-Programming-Language-Meetup/events/234916038/


I'm hoping next month to have a meetup in a place where we can have more 
formal discussion/presentation.


-Steve

Re: Berlin D Meetup September 2016

[Steven Schveighoffer via Digitalmars-d-announce]

On 9/16/16 8:38 AM, Stefan Koch wrote:

On Monday, 12 September 2016 at 17:26:25 UTC, Ben Palmer wrote:

Hi All,

The September Berlin D Meetup will be happening at 20:00 on Friday the
16th of September at Berlin Co-Op (http://co-up.de/) on the fifth floor.

This month we will be having an open hackathon so feel free to bring
along anything you are currently working on.

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/234060672/

Thanks,
Ben.


Oh crap.
I missed it :(


You sure? It's still only Friday, well before 20:00 :)

-Steve

Re: D Boston September Meetup

[Steven Schveighoffer via Digitalmars-d-announce]

On 9/6/16 10:01 AM, Steven Schveighoffer wrote:

Posted here:
https://www.meetup.com/Boston-area-D-Programming-Language-Meetup/events/233871852/


A reminder that this is happening tonight!

See you there.

-Steve

D Boston September Meetup

[Steven Schveighoffer via Digitalmars-d-announce]

Posted here: 
https://www.meetup.com/Boston-area-D-Programming-Language-Meetup/events/233871852/


In general, I'm still looking to see if we can host meetups in a private 
setting. Anyone who has info on any companies in or around Boston that 
would be willing to host, or might know of a place for us to use for 
talks and discussion, please email me schvei...@yahoo.com


-Steve

Re: Beta D 2.071.2-b3

[Steven Schveighoffer via Digitalmars-d-announce]

On 8/31/16 5:56 AM, Johan Engelen 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.


"lots of optimizations"
Can you mention a few?


I'm not sure optimizations are had by private variables. Some 
optimizations can be had because the compiler can prove a variable could 
not have been changed. But I don't know that private suits that need, 
it's more due to const or immutable.



(I can only think of complicated stuff that requires pretty much
whole-program analysis to prove validity, and in that case adding
`private` doesn't help any more)


Where I see private helping is conceptual -- I know that if a variable 
is private, I can narrow to a given module all the places the variable 
might be read or written. If you just allow private access via anywhere, 
it defeats that analysis.


-Steve

Re: The D Language Foundation is now a tax exempt non-profit organization

[Steven Schveighoffer via Digitalmars-d-announce]

On 8/29/16 1:03 PM, Andrei Alexandrescu wrote:

We're happy to report that the D Language Foundation is now a public
charity operating under US Internal Revenue Code Section 501(c)(3). The
decision is retroactive to September 23, 2015.

This has wide-ranging implications, the most important being that
individuals and organizations may make tax deductible bequests, devises,
transfers, or gifts to the Foundation. We will mull over defining
donation and sponsorship packages in the near future. If interesting in
donating spontaneously, feel free to reach out to us via email at
foundat...@dlang.org.

Many thanks are due to the folks in this community who asked for and
supported this initiative.


Awesome!

-Steve

Re: Silicon Valley D Meetup August 25, 2016 - Fireside Chat with Andrei Alexandrescu

[Steven Schveighoffer via Digitalmars-d-announce]

On 8/27/16 12:34 AM, Bill Hicks wrote:

On Wednesday, 24 August 2016 at 19:17:19 UTC, Ali Çehreli wrote:

We will post a Google Hangouts link here at the start at 19:00 (7pm)
Pacific time:

  http://www.meetup.com/D-Lang-Silicon-Valley/events/232970396/

Please try to come in person for free food and maybe a free copy of
the book "Programming in D".

The venue:

  Innowest
  764 San Aleso Ave, Sunnyvale, CA



I'll be attending.  I would really like to bring some of my 'exotic'
female friends who have shown interest in D, but is D's gatherings still
white males only?  I haven't seen any posting regarding rule changes, so
I thought I ask.


Please bring your time machine as well. Does it run on D?

-Steve

Re: The Origins of the D Cookbook

[Steven Schveighoffer via Digitalmars-d-announce]

On 8/5/16 7:58 PM, H.Loom wrote:


sorry, I'm not English native speaker and i didn't know that it has a
bad connotation...I meant "famous".


No you see, he's IN-famous. IN-famous is when you're MORE than famous. 
This man, Adam Ruppe, he's not just famous, he's IN-famous.


-Steve

August Boston D users meetup

[Steven Schveighoffer via Digitalmars-d-announce]

I posted this a while ago, forgot to announce. Please join us if you are 
in the area! Already 5 going.


-Steve

http://www.meetup.com/Boston-area-D-Programming-Language-Meetup/events/232865668/

Re: std.experimental.xml available on DUB

[Steven Schveighoffer via Digitalmars-d-announce]

On 7/30/16 5:26 AM, Lodovico Giaretta wrote:

Hi,

I'm proud to announce that std.experimental.xml v0.1.0 is available on
DUB [1]!

This is the project I'm working on for GSoC 2016. It aims to become a
substitution for Phobos std.xml. Now you can easily try it and provide
some feedback. I will soon create a WIP PR on the Phobos repository.

I suggest you to depend on ~master instead of v0.1.0, as bugfixes and
enhancements are added on a daily basis (v0.1.0 is already one commit
behind!)

Current limitations:
1) The documentation [2] is very limited;
2) Some advanced DOM methods are not completely implemented;
3) Some advanced features (e.g. DTD validation, namespace checks) are
not yet available.

If you find any issue / have any suggestion, please file an issue on
Github [3].

Thank you.

[1] https://code.dlang.org/packages/std-experimental-xml
[2] https://lodo1995.github.io/experimental.xml/
[3] https://github.com/lodo1995/experimental.xml


Good to see this advancing!

I'm looking at the cursor API and like what I see.

A couple things:
1) I see struct Cursor is not tagged for documentation, yet all it's 
members are. Your docs are missing out on a lot of stuff here! This 
might be true elsewhere too, make sure you tag types for documentation 
or the members won't show up in the docs.
2) The function "exit", I don't like. This is bikeshedding, but I just 
don't like the possibility that to conflate with C exit. I don't have a 
good replacement name for enter/exit, so this comment is pretty minor.


-Steve

Re: July D Boston Meetup gathering

[Steven Schveighoffer via Digitalmars-d-announce]

On 6/14/16 12:00 PM, Steven Schveighoffer wrote:

Just announced. If you are in the area, come join us!

http://www.meetup.com/Boston-area-D-Programming-Language-Meetup/events/231887464/



Just a reminder for those who are procrastinating -- This is happening 
on Thursday of this week. Already 6 people coming, could always have more!


-Steve

Re: [Semi OT] About code review

[Steven Schveighoffer via Digitalmars-d-announce]

On 6/26/16 8:01 PM, deadalnix wrote:

Several people during DConf asked abut tips and tricks on code review.
So I wrote an article about it:

http://www.deadalnix.me/2016/06/27/on-code-review/


Very nice. One thing missing: Always remember to update documentation 
when submitting updates! Can probably be lumped together with tests section.


-Steve

July D Boston Meetup gathering

[Steven Schveighoffer via Digitalmars-d-announce]

Just announced. If you are in the area, come join us!

http://www.meetup.com/Boston-area-D-Programming-Language-Meetup/events/231887464/

-Steve

Re: Beta release DUB 1.0.0-beta.1

[Steven Schveighoffer via Digitalmars-d-announce]

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

Re: Beta release DUB 1.0.0-beta.1

[Steven Schveighoffer via Digitalmars-d-announce]

On 6/8/16 2:45 PM, Sönke Ludwig wrote:

Am 08.06.2016 um 16:58 schrieb Steven Schveighoffer:

I agree with Jacob. A comment is a comment.


Well, there are normal comments, doc comments and now DUB recipe
comments. But at least if doc comments serve as an analogy, those are
possible with all three comment styles, so that could be taken as a
consistency argument.


There is no reason one needs
to use specifically /+. In fact the only reason for the existence of /+
is to allow nesting of comments -- which doesn't apply here. I'd say you
should support // comments as well.


SDLang supports C and C++ style comments as well, so could in fact apply
here. But probably you'd usually use // style comments in that case.


So this is definitely something concerning for allowing all comment 
styles. If one wants to put comments in their sdl file, then one must 
use an alternate style of commenting inside their sdl file. This makes 
/+ much more attractive than the other styles.


But I think this is really just a documentation issue. The biggest 
problem I would see is if someone used /* style comments in their sdl 
file definition, but wanted to use /* style comments to include it, the 
parser would prematurely close the whole comment block.





There's another aspect here, in that most people (even core D
developers) use the /* comment style */. So someone seeing the /+
comment might think this is a specialized dub thing.


Would there be any harm? Looking it up in either DUB's or DMD's
documentation would clarify that.


Not "harm", but confusion. I can see someone never looking this up, 
because it may seem "obvious" the /+ is dub special. It's very minimal 
impact, but something I just thought of.



I will finally say this: if such an implementation update existed, what
would be the reason NOT to pull it? That is, I think literally the only
reason not to support /* for this purpose is that nobody has done the
work. If you can give no better reason, it should take away any barriers
for anyone wishing to create this improvement.


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.



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 :)



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.


-Steve

Re: Beta release DUB 1.0.0-beta.1

[Steven Schveighoffer via Digitalmars-d-announce]

On 6/8/16 8:21 AM, Jacob Carlborg wrote:

On 2016-06-08 11:15, Sönke Ludwig wrote:


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.


It's just that since the language support other styles of comments one
could think that all comments are supported and it will cause confusion
if only one style is supported. Otherwise it might be better to use a
UDA, if possible.

If one reads the documentation and copy pastes and example the user will
most likely get it right. But if you have a conversation saying
something like "it's possible to put the content of dub.json inline in
the source code, just put it in a comment" then someone will for sure
try using a comment style that is not supported.

The documentation needs to be very clear that only one type comments are
supported, if that's the conclusion.



I agree with Jacob. A comment is a comment. There is no reason one needs 
to use specifically /+. In fact the only reason for the existence of /+ 
is to allow nesting of comments -- which doesn't apply here. I'd say you 
should support // comments as well.


There's another aspect here, in that most people (even core D 
developers) use the /* comment style */. So someone seeing the /+ 
comment might think this is a specialized dub thing.


I will finally say this: if such an implementation update existed, what 
would be the reason NOT to pull it? That is, I think literally the only 
reason not to support /* for this purpose is that nobody has done the 
work. If you can give no better reason, it should take away any barriers 
for anyone wishing to create this improvement.


-Steve

Re: The Official D Blog is Live

[Steven Schveighoffer via Digitalmars-d-announce]

On 6/3/16 4:50 PM, Rory McGuire via Digitalmars-d-announce wrote:


On 03 Jun 2016 22:35, "Jack Stouffer via Digitalmars-d-announce"
> 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.



Yes. That would be cool if posting a blog post could be linked to the 
announcement, and then the comment section was a mini-dfeed instance 
that posted the result to the actual forum.


-Steve