New test runner to test DMD

2019-02-12 Thread Jacob Carlborg via Digitalmars-d-announce

This post is mostly directed to DMD contributors.

Currently most of the tests for DMD are end-to-end like tests. The test 
invokes the compiler as a new process and the test asserts the exit code 
and/or error messages outputted by the compiler. This means that 
basically for each test file a new process is created which runs the 
compiler. There are two problems with this: a lot of processes need to 
be started and executed and since the compiler runs in a separate 
process from the test, it's not possible to access the internals of the 
compiler.


DMD also contains a few more of traditional unit tests (using the 
`unittest` blocks) which tests individual functions. Mostly utility 
functions.


I would like to announce that a new test runner has recently been added 
for testing DMD. It's like a mix of both of the existing tests types. It 
uses the `unittest` blocks and uses the compiler as a library. It runs 
the test and the compiler in the same process. It allows to compile code 
without starting a new process, then the test is free to assert whatever 
it likes. For example, the structure of internal data that are only 
available in the same process as the compiler.


The test runner compiles all files of this test type into a single 
executable. This should hopefully speed up running the tests because 
only a single executable is compiled and run, instead of hundreds.


This type of tests lives in the `test/unit` directory [1]. They're using 
the `unittest` block to declare a test. It supports attaching a UDA to 
filter tests. It also supports before and after hooks that are executed 
before each `unittest` block within the same module and after each 
`unittest` block (regardless of the test failed or passed). The test 
runner will print a report at the end of which tests that failed.


The tests are executed by default when `make -C test` or `./test/run.d` 
is executed. The runner supports a more finer grained control of running 
the tests:


* To run all the unit test (without running the other tests), run: 
`./test/run.d -u`


* To only run the unit tests in one or more specific files:
`./test/run.d -u test/unit/self_test.d`

* To only run a subset of the unit tests in a single file:
./test/run.d -u test/unit/self_test.d --filter "self test"

In the above example, the `--filter` flag will filter to only run the 
tests with a UDA matching the given value, in this case `self test`.


An example can look like this [2]:

module self_test;

import support : afterEach, beforeEach, defaultImportPaths;

@beforeEach initializeFrontend()
{
import dmd.frontend : initDMD;
initDMD();
}

@afterEach deinitializeFrontend()
{
import dmd.frontend : deinitializeDMD;
deinitializeDMD();
}

@("self test")
unittest
{
import std.algorithm : each;
import dmd.frontend;

defaultImportPaths.each!addImport;

auto t = parseModule("test.d", q{
int a = 3;
});

assert(!t.diagnostics.hasErrors);
assert(!t.diagnostics.hasWarnings);
}

You're free to test whatever you like inside the `unittest` block, the 
`parseModule` function is not required to use. Here's another example 
that does not use it [3].


I highly recommend splitting up the `unittest` blocks to only test one 
thing per `unittest` block.


I encourage all DMD contributors to give this a try. Using this kind of 
test will hopefully speed up the DMD test suite and make it possible to 
test things that are not tested today.


[1] https://github.com/dlang/dmd/tree/master/test/unit
[2] https://github.com/dlang/dmd/blob/master/test/unit/self_test.d
[3] https://github.com/dlang/dmd/blob/master/test/unit/deinitialization.d

--
/Jacob Carlborg


Re: DConf 2019 Early-Bird Registration Now Open

2019-01-30 Thread Jacob Carlborg via Digitalmars-d-announce

On 2019-01-28 15:07, Mike Parker wrote:
I've published a post on the blog with updates about DConf 2019 
registrations, the invited keynote speaker, the Symmetry Autumn of Code 
finalist, and the previously announced fundraiser for a new forum server.


Early-bird registrations are $340 again this year and will remain 
available until March 17, 24:00 AOE. This time around, we have to factor 
in a 20% VAT for all registrations, so the actual price will be $408.


Has a hotel for post-conference gathering* been picked?



* We all know this actually means Beer Conf :D

--
/Jacob Carlborg


Re: GtkD Blog Now Up and Running

2019-01-30 Thread Jacob Carlborg via Digitalmars-d-announce

On 2019-01-30 11:35, Ron Tarrant wrote:

You said you're on OSX, right? Is it possible that dub just isn't as 
cooperative on Windows 10? Of course, if you can see something in this 
output that hints at a fix, please let me know.


It's Optlink being stupid as always. If you want to figure out what's 
wrong you can invoke Dub with the "--verbose" flag to have it print the 
commands it's running, i.e. how it's invoking the compiler and the 
linker. You can do the same thing when invoking the compiler manually by 
adding "-v" to see how it links the application and compare that with Dub.


Or, you can try compiling as COFF instead of OMF which will not use 
Optlink. Add the flag "--arch=x86mscoff" when invoking Dub.


--
/Jacob Carlborg


Re: GtkD Blog Now Up and Running

2019-01-30 Thread Jacob Carlborg via Digitalmars-d-announce

On 2019-01-30 03:00, Neia Neutuladh wrote:


Might I recommend instead:

 dependency "gtk-d" version="3.8.5"

This depends on gtk-d 3.8.5 and only that version. If there is a breaking
change in 3.8.6 despite semantic versioning, your code keeps working.

In libraries, I prefer using ~> to give more freedom to people depending
on my code. But in applications, that isn't a concern. May as well only
allow the code to be built with the versions of your dependencies that
you've actually tested.


That's what the dub.selections.json file is for. It will lock down the 
version of all dependencies, direct and indirect dependencies.


For applications the dub.selections.json should be under version 
control, while for libraries it should be ignored.


--
/Jacob Carlborg


Re: D-lighted, I'm Sure

2019-01-20 Thread Jacob Carlborg via Digitalmars-d-announce

On 2019-01-19 23:13, Ron Tarrant wrote:

Wow. That's a lot to think about. Thanks, Jacob. Looks like I've got my 
weekend reading all lined up. :)


:)

--
/Jacob Carlborg


Re: D-lighted, I'm Sure

2019-01-18 Thread Jacob Carlborg via Digitalmars-d-announce

On 2019-01-18 21:23, H. S. Teoh wrote:


Haha, that's just an old example from back in the bad ole days where NTP
syncing is rare, and everyone's PC is slightly off anywhere from seconds
to minutes (or if it's really badly-managed, hours, or maybe the wrong
timezone or whatever).


I had one of those issues at work. One day when I came in to work it was 
suddenly not possible to SSH into a remote machine. It worked the day 
before. Turns out the ntpd daemon was not running on the remote machine 
(for some reason) and we're using Kerberos with SSH, that means if the 
clocks are too much out of sync it will not be able to login. That was a 
... fun, debugging experience.


--
/Jacob Carlborg


Re: D-lighted, I'm Sure

2019-01-18 Thread Jacob Carlborg via Digitalmars-d-announce

On 2019-01-18 15:29, Mike Parker wrote:
Not long ago, in my retrospective on the D Blog in 2018, I invited folks 
to write about their first impressions of D. Ron Tarrant, who you may 
have seen in the Lear forum, answered the call. The result is the latest 
post on the blog, the first guest post of 2019. Thanks, Ron!


The blog:
https://dlang.org/blog/2019/01/18/d-lighted-im-sure/


Regarding Dub. If you only have a project without any dependencies or 
perhaps only system dependencies already available on the system it 
might not add that much. But as soon as you want to use someone else D 
code it helps tremendously. Dub both acts as a build tool and a package 
manager. It will automatically download the source code for the 
dependencies, build them and handle the imports paths. As for JSON 
files, it's possible to use the alternative format SDL. One extremely 
valuable feature this has over JSON is that it supports comments.


To address some of the direct questions in the blog post:

"information about how I would go about packaging a D app (with GtkD) 
for distribution".


When it comes to distribution D applications there isn't much that is 
specific to D. Most of the approaches and documentation that applies to 
any native language would apply to D as well. There are two D specific 
things (that I can think of for now) that are worth mentioning:


* When you compile a release build for distribution, use the LDC [1] 
compiler. It produces better code. You can also add things like LTO 
(Link Time Optimization) and possibly PGO (Profile Guided Optimization).


* If you have any static assets for you application, like images, sound 
videos, config files or similar, it's possible to embed those directly 
in the executable using the "import expression" [2] feature. This will 
read a file, at compile time, into a string literal inside the code.


Some more general things about distribution. I think it's more platform 
specific than language specific. I can only speak for macOS (since 
that's the main platform I use). There it's expected to have the 
application distributed as a disk image (DMG). This image would contain 
an application bundle. An application bundle is a regular directory with 
the ".app" extension with a specific directory and file structure. Some 
applications in the OS treats these bundles specially. For example, 
double clicking on this bundle in the file browser will launch the 
application. The bundle will contain the actual executable and and 
resources like libraries and assets like images and audio. In your case, 
don't expect a Mac user to have GTK installed, bundle that in the 
application bundle.


Then there's the issue of which versions of the platforms you want to 
support. For macOS it's possible to specify a minimum deployment target 
using the "MACOSX_DEPLOYMENT_TARGET" environment variable. This allows 
to build the application on the latest version of the OS but still have 
the application work on older versions.


On *BSD and Linux it's not that easy and Linux has the additional axis 
of distros which adds another level of issues. The best is to compile 
for each distro and version you want to support, but that's a lot of 
work. I would provide fully statically linked binaries, including 
statically linked to the C standard library. This way to can provide one 
binary for all version of and distros of Linux and you know it will 
always work.


"how to build on one platform for distribution on another (if that’s 
even possible)"


I can say that it's possible, but unless you're targeting a platform 
that doesn't provide a compiler, like mobile or an embedded platform, I 
think it's rare to need to cross-compile. I'll tell you way:


When building an application that targets multiple platforms you would 
need to test it at some point. That means running the application on all 
the supported platforms. That means you need to have access to these 
platforms. Usually a lot in the beginning when developing the 
application and in the end when doing final verification before a release.


Having said that, I'm all for automating as much as possible. That means 
automatically running all the tests and building the final release build 
and packing for distribution. For that I recommend hooking up you're 
project to one of the publicly available and free CI services. Travis CI 
[3] is one of them that supports Linux, macOS and Windows (early release 
[4]). AppVeyor is an alternative that has a much more mature support for 
Windows.


If you really want to cross-compile, it's possible if you use LDC. DMD 
can compile for the same platform for either 32 bit or 64 bit, but not 
for a different platform. I think it's simplest to use Docker. I have 
two Docker files for a container containing LDC setup for 
cross-compiling to macOS [6] and for Windows [7]. Unfortunately these 
Docker files pulls down the SDKs from someones (not mine) Dropbox account.


[1] 

Re: B Revzin - if const expr isn't broken (was Re: My Meeting C++ Keynote video is now available)

2019-01-18 Thread Jacob Carlborg via Digitalmars-d-announce

On 2019-01-18 20:28, Stefan Koch wrote:

The only difference that type-functions have from what you describe is 
that it does not need to occupy a keyword 'type'.


You're using "alias" instead of my "type" keyword?

--
/Jacob Carlborg


Re: B Revzin - if const expr isn't broken (was Re: My Meeting C++ Keynote video is now available)

2019-01-18 Thread Jacob Carlborg via Digitalmars-d-announce

On 2019-01-17 23:44, H. S. Teoh wrote:


Interesting.  Is it possible to assign a "fake" mangle to type functions
that never actually gets emitted into the object code, but just enough
to make various internal compiler stuff that needs to know the mangle
work properly?


Not sure that would be possible. I tries to a support for pragma(mangle) 
on alias declarations. That opened a can of worms. It turns out that the 
compiler is using the mangling of a type to compare types internally.


--
/Jacob Carlborg


Re: B Revzin - if const expr isn't broken (was Re: My Meeting C++ Keynote video is now available)

2019-01-18 Thread Jacob Carlborg via Digitalmars-d-announce

On 2019-01-17 23:44, H. S. Teoh wrote:


YES!  This is the way it should be.  Type-tuples become first class
citizens, and you can pass them around to functions and return them from
functions
No no no, not only type-tuples, you want types to be first class 
citizens. This makes it possible to store a type in a variable, pass it 
to and return from functions. Instead of a type-tuple, you want a 
regular array of types. Then it would be possible to use the algorithms 
in std.algorithm to manipulate the arrays. I really hate that today one 
needs to resort to things like staticMap and staticIndexOf.


Of course, if we both get tuples and types as first class citizens it 
would be possible to store types in these tuples as well. But a tuple is 
usually immutable and I'm not sure if it would be possible to use 
std.algorithm on that.


It would be awesome to be able to do things like this:

type foo = int;

type bar(type t)
{
return t;
}

auto u = [byte, short, int, long].map!(t => t.unsigned).array;
assert(u == [ubyte, ushort, uint, ulong];

--
/Jacob Carlborg


Re: My Meeting C++ Keynote video is now available

2019-01-16 Thread Jacob Carlborg via Digitalmars-d-announce

On 2019-01-16 06:32, Walter Bright wrote:

You deliberately wrote that, and I'm confident you'd never try to pass 
that off as good work.


Yes. I'm showing it's possible to write bad code in all programming 
languages with all (most) features. Macros are not required for that.


With macros, however, programmers are convinced they are creating models 
of clarity. I've seen programmers truly believe:


     #define BEGIN {
     #define END }

improves their C code. Fortunately, that was ridiculed out of existence 
in the 1980s, but the more subtle abuses persist with their ardent 
defenders. I used to use a lot of macros in my C code, and a few years 
back made an effort to remove them all from the dmd source code. The 
result was very satisfactory.


I've seen entire code bases abandoned because of macros after the 
original developer left.


D has done a great job of replacing the C preprocessor with alternative 
features. These include: "import", "debug" and "version". These features 
are great and don't need much improvement. They take care of the stuff 
that is really difficult to avoid the preprocessor in C for.


Then we have the other stuff: macros. To insert code at the 
instantiation point. For this, D has string mixins and template mixins. 
This is where D is lacking some features. For example, it's not possible 
to insert a symbol with a string mixin that the surrounding scope at the 
instantiation point cannot access. For example, you want to insert two 
symbols, but the surrounding code should only have access to one of the 
symbols, the other one is a helper symbol to the first one. This is not 
possible today. Unfortunately that doesn't stop anyone from trying to 
come up with there own workarounds and solutions, like generating some 
obfuscated symbol name. It's not gonna make it less accessible, just 
less likely to collide with an existing symbol.


It's also not possible to insert a symbol that refers to another symbol 
in another module without risking a symbol conflict in the local scope.


There's a word for this, mixins are not hygienic.

While D improves a lot on the C preprocessor it didn't reach all the way 
to cross the finish line.


--
/Jacob Carlborg


Re: My Meeting C++ Keynote video is now available

2019-01-16 Thread Jacob Carlborg via Digitalmars-d-announce

On 2019-01-16 08:08, Nicholas Wilson wrote:

I'm pretty sure Jacob is talking about a completely different type of 
macro (i.e. not textual substitution), AST macros.


Yeah, I should come up with a new name than "macro". A soon as Walter 
sees the word "macro", regardless of its meaning in the context, he will 
throw his hands in the air and run the other way.


--
/Jacob Carlborg


Re: My Meeting C++ Keynote video is now available

2019-01-15 Thread Jacob Carlborg via Digitalmars-d-announce

On 2019-01-15 12:53, Walter Bright wrote:

Template expressions can't, either, but what they do is hijack the 
syntax for completely different purposes. The poor reader will be 
looking at code, and it will behave nothing like the syntax suggests.


Ah, you mean like this:

struct MyInt
{
private int value;

MyInt add(MyInt other)
{
return MyInt(value - other.value);
}
}

Perhaps we shouldn't support user defined types or functions either ;)

--
/Jacob Carlborg


Re: My Meeting C++ Keynote video is now available

2019-01-15 Thread Jacob Carlborg via Digitalmars-d-announce

On 2019-01-14 23:52, Walter Bright wrote:

On 1/14/2019 10:49 AM, Jacob Carlborg wrote:

But Ddoc has macros ;)


Indeed it does. But the macros cannot be used to create syntax, and 
there is no token concatenation. Macros cannot define other macros.




The AST macros I've been talking about have never been able to create 
new syntax.


--
/Jacob Carlborg


Re: My Meeting C++ Keynote video is now available

2019-01-14 Thread Jacob Carlborg via Digitalmars-d-announce

On 2019-01-14 15:42, Steven Schveighoffer wrote:

That's a bad example :) The clear answer is mysql-native, which is what 
vibe.d recommends.


Exactly, and I don't need five minutes for that. Five seconds is enough :)

--
/Jacob Carlborg


Re: My Meeting C++ Keynote video is now available

2019-01-14 Thread Jacob Carlborg via Digitalmars-d-announce

On 2019-01-14 08:50, Walter Bright wrote:

Interesting cites, which provide a basis for why I've opposed AST 
macros, and why Ddoc and unittest are builtin (and a few other things).


But Ddoc has macros ;)

--
/Jacob Carlborg


Re: LDC "nightly" or latest CI build

2018-12-25 Thread Jacob Carlborg via Digitalmars-d-announce

On 2018-12-23 19:54, Johan Engelen wrote:

Hi all,
   The dlang.org install.sh script is now able to install the latest
successful CI build of LDC master, called "ldc-latest-ci" !

That should make it easier for you to test the newest of the newest of
LDC master.
On Travis, you can use "d: ldc-latest-ci" to test your project with it.
On d.godbolt.org, you can find it as ldc latest CI (dmd nightly is there
too).


That's great.

--
/Jacob Carlborg


Re: Fuzzed - a program to find DMDFE parser crash

2018-12-16 Thread Jacob Carlborg via Digitalmars-d-announce

On 2018-12-15 12:29, Basile B. wrote:

While the D front end is not yet used to make tools

I've used it to make a tool, DLP [1].

[1] http://github.com/jacob-carlborg/dlp

--
/Jacob Carlborg


Re: Fuzzed - a program to find DMDFE parser crash

2018-12-16 Thread Jacob Carlborg via Digitalmars-d-announce

On 2018-12-15 16:37, Basile B. wrote:

This poisoning kills the interest of using a fuzzer. 99% of the crashes 
will be in hdrgen.


Does that matter as long as the bug is found?

--
/Jacob Carlborg


Re: OFFTOPIC Re: I've just released Vasaro

2018-12-13 Thread Jacob Carlborg via Digitalmars-d-announce

On 2018-12-13 00:36, Adam D. Ruppe wrote:


So I got out my code that (with your help about a year ago) was doing a
hello world window and menu, but now it doesn't compile, complaining
about a hidden Class clashing with my Class.


Hmm, it was not my intention for that to be exposed yet.

You don't need that hack with an extra interface called "Class" anymore. 
It's now possible to declare static/class methods directly, which wasn't 
possible before.


Technically in Objective-C static methods are instance methods on the 
metaclass. All classes in Objective-C are objects, they're instance of 
the metaclass. Each class has a corresponding metaclass. The 
class/interface you have implemented called "Class" was the metaclass, 
manually declared. This metaclass is normally not visible in the source 
code in Objective-C. What we did was we declared instance methods on the 
metaclass, this is now handled behind the scenes when you're declaring a 
method with "static" in the normal class/interface.


If you're code is looking like this:

extern (Objective-C) interface Foo
{
extern (Objective-C) interface Class
{
Foo alloc() @selector("alloc");
}
}

You can now replace it with this code:

extern (Objective-C) interface Foo
{
static Foo alloc() @selector("alloc");
}

And you can directly call "Foo.alloc()".

It was not my intention to break existing code. I think if you rename 
your "Class" to something else it will continue to work.



What is the current state and roadmap for this support?


There's no roadmap. It's whenever I got time to work on the Objective-C 
integration. Lately I've been prioritizing other work. But it would be 
the next thing on the list of Objective-C features to implement.



The stuff described here seems wrong: https://dlang.org/spec/objc_interface.html


No, that's correct. The example at the bottom compiles and runs 
correctly using DMD 2.083.0.



and this apparently hasn't been edited for years:
https://wiki.dlang.org/DIP43 but SEEMS to be what closest matches up.


I'm not sure if DIP43 needs to be changed. It's what I'm following when 
implementing, more or less. It's just that not everything in DIP43 has 
been implemented yet.


--
/Jacob Carlborg


Re: OFFTOPIC Re: I've just released Vasaro

2018-12-13 Thread Jacob Carlborg via Digitalmars-d-announce

On 2018-12-12 15:52, Adam D. Ruppe wrote:

On Tuesday, 11 December 2018 at 10:19:38 UTC, Jacob Carlborg wrote:

Which year is the machine from? It should say that after the model.


Oh, I had to click "more info".

MacBook Air
11-inch, Mid 2011

So I guess it is quite old. I have tried to do the OS update several
times before and it consistently just freezes (usually the progress bar
stops, the system keeps working, but one time it did outright restart
itself), this probably explains why.



Yes, it's too old for Mojave. But it looks like you can run High Sierra 
[1]. It's just one version old.


[1] https://support.apple.com/kb/SP765?locale=en_US

--
/Jacob Carlborg


Re: MORE OFFTOPIC Re: I've just released Vasaro

2018-12-11 Thread Jacob Carlborg via Digitalmars-d-announce

On 2018-12-11 13:23, Iain Buclaw wrote:


Dwarf data is emitted on OSX. The section where to find all debug
symbols is prefixed by "__DWARF".  Even DMD does this on OSX. ;-)


Yes, but the linker strips any sections with the "S_ATTR_DEBUG" flag, 
which includes the everything in the "__DWARF" segment. Here's my commit 
message for convenience:


The linker on macOS will remove any debug info, i.e. every section
with the `S_ATTR_DEBUG` flag, this includes everything in the
`__DWARF` section. By using the `S_REGULAR` flag the linker will not
remove this section. This allows to get the filenames and line numbers
for backtraces from the executable.

Normally the linker removes all the debug info but adds a reference to
the object files. The debugger can then read the object files to get
filename and line number information. It's also possible to use an
additional tool that generates a separate `.dSYM` file. This file can
then later be deployed with the application if debug info is needed
when the application is deployed.

--
/Jacob Carlborg


Re: MORE OFFTOPIC Re: I've just released Vasaro

2018-12-11 Thread Jacob Carlborg via Digitalmars-d-announce

On 2018-12-11 12:13, Iain Buclaw wrote:


We're covered by libbacktrace, rather than tthe druntime implementation.

https://github.com/gcc-mirror/gcc/blob/master/libbacktrace/README


Looks like Mach-O is not supported. It looks like it uses DWARF, but I 
don't know how you plan to have that working when the executable doesn't 
contain any DWARF data ;).


Besides, it will only work for newer OSX releases, not ~10.5 which is 
roughly the base version aimed to support.


I still don't see any point in supporting these old version that Apple 
has dropped support for since many years ago.


--
/Jacob Carlborg


Re: MORE OFFTOPIC Re: I've just released Vasaro

2018-12-11 Thread Jacob Carlborg via Digitalmars-d-announce

On 2018-12-10 12:26, Iain Buclaw wrote:

Is there any consideration apart from section/tls support? 


There's the backtrace implementation for exceptions as well, 
"rt.backtrace". I had to slight modify the DMD backend to get that to 
work the same as it does on Linux and FreeBSD. I've documented how it's 
implemented in the commit message [1].


I'm just going to fork the current rt.sections stuff (I.e: 
gcc.sections.{elf,macho,pef,x off}) as apart from linux/elf, the rest is 
not of any use or is specific to dmd object format. 


You should be able to reuse most parts of rt.sections_osx_x86. I don't 
think there's anything in that file that won't work on x86-64. But you 
would need to adjust it for the TLS implementation you're using.



As for tls, well  there is still no native support in gcc if I understand 
correctly.


It was pretty straight forward (once I figured it out :) ) to implement 
in DMD and it's pretty well documented you want to implement it in GCC.


[1] 
https://github.com/dlang/dmd/commit/2bf7d0db29416eacbb01a91e6502140e354ee0ef


--
/Jacob Carlborg


Re: OFFTOPIC Re: I've just released Vasaro

2018-12-11 Thread Jacob Carlborg via Digitalmars-d-announce

On 2018-12-10 14:55, Adam D. Ruppe wrote:

Ah, there it is: 10.9.5, 1.6 GhZ Core i5, 2 GB. (c) 2016. Actually not 
that old.


Which year is the machine from? It should say that after the model. For 
me it says: "MacBook (Retina, 12-inch, Early 2015)". If it's from mid 
2012 or newer you can upgrade to the latest version of macOS, if you 
want to [1].


Well, I still want to add the support to my library anyway. At least the 
minimal stuff - create window, create opengl context, dispatch events, 
so it can serve as a base for other users to PR the other functions if 
they use it. I am also very slowly working on some objc helper functions 
(though I wish the headers were at least in druntime like win32 is now)


That's why I got this and it is still on my list, it is just somewhat 
far down on my list.


I would recommend waiting until more of the Objective-C support is 
implemented. Creating a subclass is a pain in the ass currently.


[1] https://support.apple.com/kb/SP777?locale=en_US

--
/Jacob Carlborg


Re: OFFTOPIC Re: I've just released Vasaro

2018-12-10 Thread Jacob Carlborg via Digitalmars-d-announce

On 2018-12-08 18:01, Adam D. Ruppe wrote:

The one I have is a macbook air with a broken, but usable screen (I got 
it for free yay). I don't know how old it is, I *think* it is a 2013 
model.


If you click on the Apple menu in the top left corner and choose "About 
This Mac", it will say which model and which year in the window that 
appears. It will also specify which version of the OS it's running.


I know it won't take the new OS update from Apple, but it was 
able to run dmd on it last time I tried (which was like 9 months ago lol).


DMD will run on Mavericks (10.9) or later.

If you don't want to keep it you could always donate it as a testing 
machine, if the Dlang foundation will accept it.


--
/Jacob Carlborg


Re: I've just released Vasaro

2018-12-08 Thread Jacob Carlborg via Digitalmars-d-announce

On 2018-12-07 09:05, Andrea Fontana wrote:

Simpledisplay works fine for me (and it works better than sdl for mouse 
input) but it requires X11 on macOS if i'm right: macOS' users don't 
like X11 (and this force users to install a big dependency)


Yes, X11 is definitively not acceptable on macOS.

--
/Jacob Carlborg


Re: DLP identify leaf functions

2018-12-04 Thread Jacob Carlborg via Digitalmars-d-announce

On 2018-12-02 17:57, welkam wrote:

What a timing. I am working on (slowly) on a tool that would get all 
struct and class declarations and for each of them get functions in 
which they are used. Then combine them with profiling data to find data 
structures that are hot and how changing them affects performance. The 
only code that is written is partially parsing perf.data file and the 
rest is missing. It would be wonderful if your tool could emit such 
functions then my job would be easy. Parsing would have been done if 
perf.data format was fully documented.


Something like "find all references"?

--
/Jacob Carlborg


Re: DLP identify leaf functions

2018-12-02 Thread Jacob Carlborg via Digitalmars-d-announce

On 2018-12-01 13:31, Anonymouse wrote:


Looks interesting.

My project requires a bunch of version identifiers to actually compile. 
Is there a way to pass these, or ideally a way to make it parse them 
from dub.{json,sdl}?


No, there's currently no way. The next step would be to allow to pass 
all the same flags as the DMD compiler allows.


--
/Jacob Carlborg


Re: DLP identify leaf functions

2018-12-01 Thread Jacob Carlborg via Digitalmars-d-announce

On 2018-12-01 11:13, Sebastiaan Koppe wrote:

Really nice! I have some ideas about data-flow analysis and this allows 
some easy experimenting without forking the compiler.


Thanks. I've been thinking the same about experimenting with the compiler.

--
/Jacob Carlborg


DLP identify leaf functions

2018-11-30 Thread Jacob Carlborg via Digitalmars-d-announce
I would like to announce a new project I've started, called DLP (D 
Language Processing). Currently it's quite experimental but the idea is 
that it would contain a collection of commands for inspecting D code in 
various ways. It uses the DMD frontend as a library (the Dub package) to 
process D code.


This first release only contains one command, "leaf-functions". It will 
print out all leaf functions to standard out. A "leaf function" is 
considered a function that doesn't call any other functions or doesn't 
have a body. The use case for this is if you have a code base that you 
would like to add attributes to. Since most attributes causes the 
function they're attached to be constraint in which other functions they 
can call, "@nogc" functions can only call other "@nogc" functions, 
"pure" functions can only call other "pure" functions and so on. 
Therefore it makes most sense when starting to add attributes to a code 
base to start with the leaf functions, the functions that don't call any 
other functions.


Pre-compiled binaries are available for macOS, Linux and Windows.

https://github.com/jacob-carlborg/dlp

--
/Jacob Carlborg


Re: LDC 1.13.0-beta2

2018-11-23 Thread Jacob Carlborg via Digitalmars-d-announce

On 2018-11-21 11:43, kinke wrote:

Glad to announce the second beta for LDC 1.13:

* Based on D 2.083.0+ (yesterday's DMD stable).
* The Windows packages are now fully self-sufficient, i.e., a Visual 
Studio/C++ Build Tools installation isn't required anymore.

* Substantial debug info improvements.
* New command-line option `-fvisibility=hidden` to hide 
functions/globals not marked as export, to reduce the size of shared 
libraries.


Full release log and downloads: 
https://github.com/ldc-developers/ldc/releases/tag/v1.13.0-beta2


I see that the bundled Dub has been updated to the latest version. 
Awesome, thanks.


--
/Jacob Carlborg


Re: D compilation is too slow and I am forking the compiler

2018-11-23 Thread Jacob Carlborg via Digitalmars-d-announce

On 2018-11-21 11:56, Walter Bright wrote:

Wouldn't it be awesome to have the lexing/parsing of the imports all 
done in parallel? The main difficulty in getting that to work is dealing 
with the shared string table.


Would it be possible to have one string table per thread and merge them 
to one single shared string table before continuing with the next phase?


--
/Jacob Carlborg


Re: DIP 1015--Deprecation of Implicit Conversion of Int. & Char. Literals to bool--Formal Assement

2018-11-14 Thread Jacob Carlborg via Digitalmars-d-announce

On 2018-11-14 03:45, Walter Bright wrote:

On 11/13/2018 3:29 PM, Rubn wrote:

enum : int { a = 127 }


To reiterate, this does not create an anonymous enum type. 'a' is typed
as 'int'. Technically,

`a` is a manifest constant of type `int` with a value of `127`.

 > enum A : int { a = 127 }

`a` is a manifest constant of type `A` with a value of `127`.

Remember that `A` is not an `int`.


What is ": int" doing, only specifying the size?

--
/Jacob Carlborg


Re: DMD backend now in D

2018-11-12 Thread Jacob Carlborg via Digitalmars-d-announce

On 2018-11-12 00:40, Walter Bright wrote:

As:

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

removes the header files for the old C++ code!


BTW, this is great news :)

--
/Jacob Carlborg


Re: DMD backend now in D

2018-11-12 Thread Jacob Carlborg via Digitalmars-d-announce

On 2018-11-12 03:37, Walter Bright wrote:

On 11/11/2018 3:58 PM, Mike Franklin wrote:

This is a significant milestone.  Congratulations, Walter!


Many people helped out with this, too.


There are still a few .c files in
https://github.com/dlang/dmd/tree/master/src/dmd/backend, so what's
the significance of those?


tk.c
fp.c
os.c
strtold.c
tk/mem.c

These could be converted too, but are independent from everything else
and hardly seem worth the bother. Sebastian has a PR for os.cd.


dmd/root/ctfloat.d depends on the "strtold_dm" function defined in 
strtold.c [2] when compiling using Visual Studio. That means that the 
Dub package cannot be compile using Visual Studio without this file.


[1] 
https://github.com/dlang/dmd/blob/4df5d6a6e8775754148939beb6de827fe4b0b9ab/src/dmd/root/ctfloat.d#L167-L170


[2] 
https://github.com/dlang/dmd/blob/4df5d6a6e8775754148939beb6de827fe4b0b9ab/src/dmd/backend/strtold.c#L138


--
/Jacob Carlborg


Re: DIP 1015--Deprecation of Implicit Conversion of Int. & Char. Literals to bool--Formal Assement

2018-11-12 Thread Jacob Carlborg via Digitalmars-d-announce

On 2018-11-12 10:45, Mike Parker wrote:

DIP 1015, "Deprecation and removal of implicit conversion from integer
and character literals to bool, has been rejected, primarily on the
grounds that it is factually incorrect in treating bool as a type
distinct from other integral types.

The TL;DR is that the DIP is trying to change behavior that is working
as intended.

 From Example A in the DIP:

 bool b = 1;

This works because bool is a "small integral" with a range of 0..1. The
current behavior is consistent with all other integrals.

 From Example B in the DIP:

```
int f(bool b) { return 1; }
int f(int i) { return 2; }

enum E : int
{
 a = 0,
 b = 1,
 c = 2,
}
```

Here, f(a) and f(b) call the bool overload, while f(c) calls the int
version. This works because D selects the overload with the tightest
conversion.


Why is that? Is it because "a" and "b" are enum members? I mean, "E" is 
typed as an int. If I pass an integer literal directly to the function 
it doesn't behave like that. Example:


import std.stdio;

void foo(int a)
{
writeln("int");
}

void foo(bool a)
{
writeln("bool");
}

void main()
{
foo(0);
foo(1);
foo(2);
}

The above example prints "int" three times. The bool overload is not 
called. Seems like the enum is treated specially.


--
/Jacob Carlborg


Re: Profiling DMD's Compilation Time with dmdprof

2018-11-08 Thread Jacob Carlborg via Digitalmars-d-announce

On 2018-11-08 18:25, Jacob Carlborg wrote:


This is my result on macOS:

$ $ make -f posix.mak clean
$ time make -f posix.mak -j 16
real    0m3.127s
user    0m5.478s
sys    0m1.686s


21 seconds on a Windows 10 virtual machine compiling using the win32.mak 
file.


--
/Jacob Carlborg


Re: Profiling DMD's Compilation Time with dmdprof

2018-11-08 Thread Jacob Carlborg via Digitalmars-d-announce

On 2018-11-08 05:16, Manu wrote:


4 seconds? That's just untrue. D is actually kinda slow these days...
In my experience it's slower than modern C++ compilers by quite a lot.


This is my result on macOS:

$ $ make -f posix.mak clean
$ time make -f posix.mak -j 16
real0m3.127s
user0m5.478s
sys 0m1.686s

--
/Jacob Carlborg


Re: Backend nearly entirely converted to D

2018-11-08 Thread Jacob Carlborg via Digitalmars-d-announce

On 2018-11-08 18:23, welkam wrote:


but you are not against 
changing for loops to foreach that add almost nothing to code 
readability and only look better.


Changing to a foreach loop definitely adds to readability and to be able 
to better understand the code. If you read the "foreach" keyword you 
know that to a 99% possibility the code that follows is a loop that will 
iterate a collection from start to end. If you read the keyword "for" 
you basically know nothing. It can mean iterating a collection, copy 
some random memory or whatever.


--
/Jacob Carlborg


Re: Backend nearly entirely converted to D

2018-11-08 Thread Jacob Carlborg via Digitalmars-d-announce

On 2018-11-07 23:58, Walter Bright wrote:

Slides and video link:

  http://nwcpp.org/october-2018.html

On 11/7/2018 2:08 PM, H. S. Teoh wrote:

I don't speak for the compiler devs, but IMO, one-letter variables are
OK if they are local, and cover a relatively small scope.  Java-style
verbosity IMO makes code *harder* to read because the verbosity gets in
your face, crowding out the more interesting (and important) larger
picture of code structure.

As Walter said in his recent talk, the length of variable names (or
identifiers in general, really) should roughly correspond to their
scope: local variable names ought to be concise, but global variables
ought to be verbose (both to avoid identifier collision when a larger
amount of code is concerned, and also to serve as a convenient visual
indication that yes it's a global).


Yes, exactly.



I guess we have very different ideas on what "small scope" is. For me it 
means around 10 lines. Here's an example in the DMD code base, the 
method for doing the semantic analyze on a call expression [1]. It's 902 
lines long and has a parameter called "exp". Another example, the 
semantic analyze for an is expression [2], 310 lines long. It has a 
parameter called "e".


Someone familiar with the code base might know that the convention is 
that a variable of a type inheriting from the Expression class is 
usually called "e". Someone new to the code base will most likely not. I 
cannot see how starting to call the variable "expression" or 
"callExpression" would be disrupt. Currently when someone familiar with 
the code base reads the code and sees a variable named "e" the developer 
will think "hey, I know by convention that is usual an expression". If 
the variable was renamed to "expression" then both the one familiar and 
unfamiliar with the code base can immediately read that this variable 
holds an expression.


[1] 
https://github.com/dlang/dmd/blob/c3dcc76327cdd1cebd9767d9ce738bcbc4db2beb/src/dmd/expressionsem.d#L3812-L4713


[2] 
https://github.com/dlang/dmd/blob/c3dcc76327cdd1cebd9767d9ce738bcbc4db2beb/src/dmd/expressionsem.d#L4924-L5233


--
/Jacob Carlborg


Re: LDC 1.13.0-beta1

2018-11-08 Thread Jacob Carlborg via Digitalmars-d-announce

On 2018-11-07 16:45, kinke wrote:

I upgraded it one day after releasing beta1, as I sadly forgot to check 
for a newer dub version before publishing. I.e., the CI builds already 
feature dub v1.12.


Cool, thanks.

--
/Jacob Carlborg


Re: Backend nearly entirely converted to D

2018-11-07 Thread Jacob Carlborg via Digitalmars-d-announce

On 2018-11-06 23:12, Walter Bright wrote:

The more immediate benefit is to get rid of all the parallel .h files, 
which were a constant source of bugs when they didn't match the .d 
versions.


Still need some of those for GDC and LDC. Until we have a tool that can 
automatically generate them.


--
/Jacob Carlborg


Re: LDC 1.13.0-beta1

2018-11-07 Thread Jacob Carlborg via Digitalmars-d-announce

On 2018-11-02 22:04, kinke wrote:

Glad to announce the first beta for LDC 1.13:

* Based on D 2.083.0.
* The Windows packages are now fully self-sufficient, i.e., a Visual 
Studio/C++ Build Tools installation isn't required anymore.

* Substantial debug info improvements for GDB.

Full release log and downloads: 
https://github.com/ldc-developers/ldc/releases/tag/v1.13.0-beta1


Thanks to all contributors!


It's awesome to see that you have a version based on DMD 2.083.0 already.

Are there any plans on updating the bundled Dub version? It has a 
regression that was fixed in 1.12.0.


--
/Jacob Carlborg


Re: Wed Oct 7 - Avoiding Code Smells by Walter Bright

2018-10-16 Thread Jacob Carlborg via Digitalmars-d-announce

On 2018-10-15 23:23, Walter Bright wrote:

I'm giving a presentation at:

http://nwcpp.org/

See you there!


Hmm, it doesn't mention your name until the speaker bio.

--
/Jacob Carlborg


Re: RFC: initial release of dtoh

2018-08-25 Thread Jacob Carlborg via Digitalmars-d-announce

On 2018-08-24 12:09, Uknown wrote:

This is all very nice. I agree that this kind of thing should be a part 
of the compiler, but I think it should be a compiler plugin. If dmd had 
compiler plugins, I think stuff like this and `dpp` would be much nicer 
to use.


We have the front end available as a library, but not support for plugins.

--
/Jacob Carlborg


Re: RFC: initial release of dtoh

2018-08-22 Thread Jacob Carlborg via Digitalmars-d-announce

On 2018-08-22 13:01, Mihails wrote:

https://gitlab.com/mihails.strasuns/dtoh

Tool to grab all `extern(C)` declarations in a D module and generate C 
header file based on it. Partially addresses 
https://issues.dlang.org/show_bug.cgi?id=9285 but is intended to be much 
more simple (no C++, no human-readable emphasis).


Main differences from version written by Adam some years ago:

- Uses DMD frontend as a library directly
- Has tests

Former is quite intentional decision though I do expect it to be 
controversial. Using json output requires parsing information that is 
already present in DMD FE in a strongly typed way - and the only benefit 
is that the tool becomes more decoupled from compiler. In my opinion, 
this functionality _should_ be part of compiler itself, similar to .di 
generation.


Sadly can't put it on code.dlang.org right now because there are no 
tagged versions of http://code.dlang.org/packages/dmd to depend on, thus 
have to resort to submodule.


Iain has a PR in DMD for generating C++ headers from extern(C++) 
declarations [1]. Perhaps join forces on this.


[1] https://github.com/dlang/dmd/pull/8591

--
/Jacob Carlborg


Re: DVM - D Version Manager 0.4.4

2018-07-04 Thread Jacob Carlborg via Digitalmars-d-announce

On 2018-07-03 03:34, Tony wrote:


Thanks, that worked!

It doesn't announce where it put the compiler, which turns out to be:

C:\Users\\AppData\Roaming\dvm\


You're not supposed to know where it puts the compiler. You're 
activating it with "dvm use " where "" is the version 
you want to activate. This will persist for the end of the shell 
session. To set a default compiler use "dvm use  -d". This 
allows to use separate versions simultaneously in different shell 
sessions. See the usage information [1].


[1] https://github.com/jacob-carlborg/dvm#use-a-compiler

--
/Jacob Carlborg


Re: iopipe v0.1.0 - now with Windows support!

2018-06-21 Thread Jacob Carlborg via Digitalmars-d-announce

On 2018-06-19 15:04, Steven Schveighoffer wrote:


I just set up travis to do the Linux/mac testing. I need to add appveyor
as well, but haven't gotten to it. I'm a complete CI noob, so I'm
learning slowly :)


To save you some trouble, AppVeyor supports both a YAML, like Travis, 
and a web UI to configure the CI system. If you're not including some 
parts of the YAML file, like "build_script", it will use the default, 
which is preforming some Visual Studio specific task. You also need to 
download the D compiler manually since AppVeyor doesn't have built-in 
support for D the same way as Travis.


--
/Jacob Carlborg


Re: iopipe v0.1.0 - now with Windows support!

2018-06-19 Thread Jacob Carlborg via Digitalmars-d-announce

On 2018-06-11 16:45, Steven Schveighoffer wrote:


I just pushed v0.1.1 -- I realized that I never *actually* compiled on
windows, and there were a couple things that didn't work.

Note: the examples still don't work as they rely on openDev, which is
only available on Posix systems now.

I need to figure out a good way to open stdin/stdout in a cross platform
way with std.io.


You should setup AppVeyor [1] to make it works on Windows (when it works).

[1] https://www.appveyor.com

--
/Jacob Carlborg


Re: Looks like Digital Mars C++ is on the front page of HN at the moment!

2018-05-25 Thread Jacob Carlborg via Digitalmars-d-announce

On 2018-05-24 22:06, Basile B. wrote:


Ahhh i was forgetting, the linker...


The LLVM linker, LLD, works pretty well on Windows.


--
/Jacob Carlborg


Re: unit-threaded v0.7.45 - now with more fluency

2018-05-09 Thread Jacob Carlborg via Digitalmars-d-announce

On 2018-05-08 09:07, Nick Sabalausky (Abscissa) wrote:

The question is: Why "should.equal" instead of "shouldEqual"? The dot 
only seems there to be cute.


It scales better. This way only one "should" function is needed and one 
"not" function. Otherwise there would be a lot of duplication, i.e. 
"shouldEqual" and "shouldNotEqual". Hopefully the library can have a one 
generic implementation of "not", where it doesn't if the assertion is 
"equal", "be" or some other assertion.


--
/Jacob Carlborg


Re: The dlang-community releases DCD 0.9.3 and D-Scanner 0.5.2

2018-04-27 Thread Jacob Carlborg via Digitalmars-d-announce

On 2018-04-27 09:43, baz@dlang-community wrote:


DCD 0.9.4 is available now. Same link.


How come there are no binaries for macOS? Seems to be a release script 
and Travis CI configuration for macOS.


--
/Jacob Carlborg


Re: Pre-DConf Meetup on May 1

2018-04-27 Thread Jacob Carlborg via Digitalmars-d-announce

On 2018-04-25 16:13, Seb wrote:

Hi all,

I hope you are all looking forward to DConf.

We (Stefan, Dragos and I) have very good news for you.
Our next D Munich Meetup will coincide with DConf to give our local 
community who can't join DConf an opportunity to meetup all the 
rockstars from the D community.


Count me in as well.

--
/Jacob Carlborg


Re: LDC 1.9.0 beta

2018-04-26 Thread Jacob Carlborg via Digitalmars-d-announce

On Wednesday, 25 April 2018 at 13:36:50 UTC, Rel wrote:

This is nice to hear, but just to make it clear, what steps do 
I need to take to for example build a Mac OSX binary on Windows 
or Linux? Can I just download libs from prebuilt LDC for Mac 
OSX, put them somewhere in my current LDC installation and it 
will work?


In theory yes, in practice unfortunately no, see [1]. You would 
also need the macOS SDK. In short, the LLD linker does not 
support some magic linker symbols that LDC is dependent on.


I've created a Dockerfile that uses LDC to cross-compile 
targeting macOS. It does not use the LLD linker. Note, the base 
Docker image pulls the macOS SDK from a Dropbox account. I've 
compiled this [3] repositories using that image.


I'm also waiting so much for LDC to be independent of MS Visual 
Studio libs, and ship MinGW libs with the installation or 
something. I thought you had some troubles getting LLVM to work 
with MinGW libs, is it still true?


Apparently the MinGW libraries are too old. LDC requires the 
libraries from Visual Studio 2015 (I think) or later.


[1] https://github.com/ldc-developers/ldc/issues/2662
[2] 
https://github.com/jacob-carlborg/docker-ldc-darwin/blob/master/Dockerfile

[3] https://github.com/jacob-carlborg/d_webkit_test

--
/Jacob Carlborg


Re: #include C headers in D code

2018-04-16 Thread Jacob Carlborg via Digitalmars-d-announce

On Monday, 16 April 2018 at 11:20:51 UTC, Atila Neves wrote:

You can use the C macros in the headers that you #include in 
your dpp file.


dstep has a lot of code for translating macros. I don't want to 
translate macros at all, but it's deeply intertwined with 
translating everything else.


There's a command line switch to disable that, 
`--translate-macros=false`. Or, alternatively, run the 
preprocessor first.


I can't remember the specifics, but dstep by default ignores 
declarations from other headers because the idea is to 
translate this one particular header.


That's a simple change: replace these lines [1] with `return 
false;`. If that's something you need we can make it configurable.


[1] 
https://github.com/jacob-carlborg/dstep/blob/97870ac5167f09e8acf17f8754c32636492b237f/dstep/translator/Translator.d#L326-L329


--
/Jacob Carlborg



Re: #include C headers in D code

2018-04-13 Thread Jacob Carlborg via Digitalmars-d-announce

On 2018-04-13 12:33, Atila Neves wrote:

I'll have to take a look at Jacob's configure.d to find out where 
libclang is installed on Windows.


Unfortunately the configuration script is only for Posix.

--
/Jacob Carlborg


Re: #include C headers in D code

2018-04-11 Thread Jacob Carlborg via Digitalmars-d-announce

On Monday, 9 April 2018 at 11:03:48 UTC, Atila Neves wrote:
Here's my blog post about my project that allows directly 
#including C headers in D*


I don't know the exact details of your project but can't you just:

1. Copy the includes
2. Paste them into a C file
3. Run DStep on the C file
4. Replace the includes in the first file with the result from 
DStep


This would require changing DStep to always return `false` here 
[1]. Or perhaps run the preprocessor to expand the includes and 
then run DStep.


[1] 
https://github.com/jacob-carlborg/dstep/blob/master/dstep/translator/Translator.d#L326


--
/Jacob Carlborg


Re: #include C headers in D code

2018-04-11 Thread Jacob Carlborg via Digitalmars-d-announce

On Monday, 9 April 2018 at 11:03:48 UTC, Atila Neves wrote:
Here's my blog post about my project that allows directly 
#including C headers in D*


BTW, you can steal the config script [1] from DStep to help 
detect locations of LLVM/libclang. It also supports static 
linking. Supports manually specifying the path to LLVM if needed.


[1] 
https://github.com/jacob-carlborg/dstep/blob/master/configure.d


--
/Jacob Carlborg



Re: #include C headers in D code

2018-04-11 Thread Jacob Carlborg via Digitalmars-d-announce

On Monday, 9 April 2018 at 11:03:48 UTC, Atila Neves wrote:
Here's my blog post about my project that allows directly 
#including C headers in D*


https://atilanevesoncode.wordpress.com/2018/04/09/include-c-headers-in-d-code/


How do you deal with macros containing invalid D code, i.e. 
`#define foo(T) sizeof(T)`?


--
/Jacob Carlborg



Re: #include C headers in D code

2018-04-11 Thread Jacob Carlborg via Digitalmars-d-announce

On Tuesday, 10 April 2018 at 23:44:46 UTC, Atila Neves wrote:

The beauty of using libclang is that name mangling issues don't 
exist. :)


How is that not going to be an issue? Are you adding 
`pragma(mangle)` everywhere?


--
/Jacob Carlborg


Re: DIP 1009 (Add Expression-Based Contract Syntax) Accepted

2018-04-07 Thread Jacob Carlborg via Digitalmars-d-announce

On 2018-04-06 14:26, Mike Parker wrote:
Congratulations to Zach Tollen and everyone who worked on DIP 1009. It 
took a painful amount of time to get it through the process, but it had 
finally come out of the other side with an approval. The proposal itself 
was approved early on, but it needed quite a bit of revision to get to 
an acceptable final draft. The DIP in its final form:



https://github.com/dlang/DIPs/blob/master/DIPs/accepted/DIP1009.md

Though I will not retroactively apply review summaries to all previously 
approved DIPs, I will do so with those currently working through the 
process. I've started with this one. Note that I kept the 'Preliminary 
Review' name instead of using the new 'Community Review' so that it 
would match the review thread title.


I would like to remind everyone that DIP 1013, "The Deprecation 
Process", is currently under Community Review, with very little feedback 
so far. I encourage everyone to take a look at it and speak up if any 
flaws or potential enhancements are seen.


https://forum.dlang.org/thread/rxlbdijkbhanwvbks...@forum.dlang.org


What's the philosophy around accepted DIPs containing multiple 
suggestions/alternatives. For example, this DIP mentions three 
alternatives for the "out" syntax [1], it's not crystal clear which one 
was actually accepted.


When a DIP is accepted and it contains multiple alternatives, can we 
move the non-accepted alternatives to a separate section, use a strike 
through font style or similar?


[1] 
https://github.com/dlang/DIPs/blob/master/DIPs/accepted/DIP1009.md#new-out-syntax


--
/Jacob Carlborg


Re: Dockerfile with cross-compiler targeting Windows x64

2018-04-05 Thread Jacob Carlborg via Digitalmars-d-announce

On 2018-04-05 17:22, Joakim wrote:

Nice, rather than downloading the pre-built ldc for Windows and 
extracting its runtime, you may be interested in cross-compiling the 
stdlib yourself.  The only obstacle may be that the build requires a C 
cross-compiler for one or two C files, but clang may be good enough to 
do that now.


I'm not sure why that would be better.

If you go that route, the ldc devs would appreciate a PR filling out 
this preset configuration stub to cross-compile for Windows, with the 
info you use:


https://github.com/ldc-developers/ldc/blob/master/runtime/PresetRuntimeConfiguration.cmake#L46 


This was mostly a quick proof of concept. I don't think I can spend any 
more time on this right now.


--
/Jacob Carlborg


Dockerfile with cross-compiler targeting Windows x64

2018-04-05 Thread Jacob Carlborg via Digitalmars-d-announce
I've created a Dockerfile [1] containing LDC, configured for 
cross-compiling targeting Windows x64.


It's based on the instructions provided by kinke here [2].

Note, it downloads the MSVC libs from Dropbox.

[1] 
https://github.com/jacob-carlborg/docker-ldc-windows/blob/master/Dockerfile
[2] 
https://github.com/ldc-developers/ldc/pull/2142#issuecomment-304472412


--
/Jacob Carlborg


Re: D_vs_nim: git repo to compare features of D vs nim and help migrating code bw them. PRs welcome

2018-04-01 Thread Jacob Carlborg via Digitalmars-d-announce

On 2018-03-30 08:53, Dmitry Olshansky wrote:

With the frame of mind prevalent in our Industry I really want to have 
compiler includibg codegen as a bunch of library components.


Then there is no problem innovating while people argue over things 
“allowed” for a compiler, or a linker, or a build tool. None of these 
actually have to be apps talking via files.


If I look closely every program I see is a graph database, with nodes 
sometimes being code, types, sometimes data, other meta-data such as ABI 
attributes or conditional compilation flags, documentation, external 
tools, specs and databases are also part of this. Code that produces 
code is also part of such graph, and CTFE/macroses would just be finer 
grained approach.


Why process graphs piece-wise in a frentic dance of command-line tools 
that try to fit all to a tree of files (multiple ones, in many location, 
and part in some CMS) and then have editors/IDEs integrate? Was easier I 
believe + inertia, easy != simple though.


I completely agree. I was quite surprised when I started to use libclang 
and the only way to pass options to the library (which are usually 
command line flags) was to pass it as an array of command line options. 
This is the C API, the C++ API is more advanced.


--
/Jacob Carlborg


Re: D_vs_nim: git repo to compare features of D vs nim and help migrating code bw them. PRs welcome

2018-03-29 Thread Jacob Carlborg via Digitalmars-d-announce

On Wednesday, 28 March 2018 at 23:25:09 UTC, Walter Bright wrote:


It's expected with a build tool. Not a compiler.


It depends. The compilers are doing more and more work these 
days. Initially, DMD could not build libraries, now it can. DMD 
does not output assembly files and runs an assembler to produce 
object files, some compilers do. Clang can do this but is moving 
the same direction as DMD: having the complier do it. It think 
they're looking into having the compiler do the linking as well.


So what's expected is subjective.

--
/Jacob Carlborg


Re: D_vs_nim: git repo to compare features of D vs nim and help migrating code bw them. PRs welcome

2018-03-28 Thread Jacob Carlborg via Digitalmars-d-announce

On 2018-03-27 23:49, Walter Bright wrote:

The act of compiling a buggy program not influence the global state of 
the computer. It should not be necessary to vet code downloaded from the 
internet before even compiling it to ensure it doesn't mess up the system.


There's usually nothing that prevents the build tool to write files at 
build time. Dub can do this.


--
/Jacob Carlborg


Re: Why think unit tests should be in their own source code hierarchy instead of side-by-side

2018-03-24 Thread Jacob Carlborg via Digitalmars-d-announce

On 2018-03-23 21:43, H. S. Teoh wrote:


Yep.  As I mentioned elsewhere, recently I've had to resort to external
testing for one of my projects, and I'm still working on that right now.
And already, I'm seeing a liability: rather than quickly locating a
unittest immediately following a particular function, now I have to
remember "oh which subdirectory was it that the tests were put in? and
which file was it that a particular test of this function was done?".


Put the tests in a directory called "tests" and follow the same file and 
directory structure as the regular code.


It's just a matter of configuring a command in an editor that will find 
the corresponding test file and navigate to it. Or dump your editor if 
it doesn't support custom commands 'cos it sux and you deserve better. 
:-D  I mean, this is 2018, not 1995, we shouldn't have to be stuck with 
the handicap of clicking through files and directories to find the right 
test file anymore.


:D

--
/Jacob Carlborg


Re: Why think unit tests should be in their own source code hierarchy instead of side-by-side

2018-03-22 Thread Jacob Carlborg via Digitalmars-d-announce

On Thursday, 22 March 2018 at 11:00:31 UTC, Atila Neves wrote:


Direct link:

https://atilanevesoncode.wordpress.com/2018/03/22/keep-d-unittests-separated-from-production-code/


I completely agree. Although my reason is mostly because there 
will be too much code in a single file if the regular code and 
unit tests are mixed in the same file. Also, having 
utilities/helpers only used by the tests is easier, or easier to 
find a location for.


--
/Jacob Carlborg


Re: Release D 2.079.0

2018-03-09 Thread Jacob Carlborg via Digitalmars-d-announce

On 2018-03-08 19:21, Martin Nowak wrote:


Also this offer still stands
https://forum.dlang.org/post/drcekmxvfszpwifbu...@forum.dlang.org


Who will decide if semver can/will be used?

--
/Jacob Carlborg


Re: DWT API Documentation now on dpldocs.info

2018-03-08 Thread Jacob Carlborg via Digitalmars-d-announce

On 2018-03-08 14:51, Adam D. Ruppe wrote:

You need to go all to the way to the top level by clicking the topmost 
link on the left nav:


http://dwt.dpldocs.info/org.html
http://dwt.dpldocs.info/java.html


Aha, I see.


* No inheritance chain
* No implemented interfaces


They are in the prototype block

http://dwt.dpldocs.info/org.eclipse.swt.graphics.Image.Image.html

final
class Image : Resource , Drawable {

and notice those are links so you can click up to walk the chain.


That's quite easy to miss.


Though I didn't follow the chain all the way to the top because:


* Only one level of inherited members
* I think it's a bit too much to show the documentation of inherited 
members, I would just have links to them



These two are related. It did seem a bit silly to me to list EVERYTHING, 
but I also figured most cases of inheritance do have at least one layer 
of important methods.


So I compromised by showing the one, then letting you click on the links 
in the main thing to follow the chain up.



I'm open to changing that though. Like maybe it could just show 
non-overridden members. It could walk the chain. It could skip the 
listing and just show links all the way up to Object, perhaps under a 
"Inheritance Chain" header so it is easier to see than the prototype.


What do you think would be best?


In general I like the what the Javadoc renders [1]:

* Separate inheritances chain
* Separate interface implementations
* Inherited members are listed as only links and the whole inheritances 
chain is included


[1] 
http://help.eclipse.org/luna/index.jsp?topic=%2Forg.eclipse.platform.doc.isv%2Freference%2Fapi%2Forg%2Feclipse%2Fswt%2Fwidgets%2Fpackage-summary.html


--
/Jacob Carlborg


Re: Official Dub package for DWT

2018-03-08 Thread Jacob Carlborg via Digitalmars-d-announce

On Thursday, 8 March 2018 at 09:17:53 UTC, IM wrote:


This is great, thanks!
Any plans to make it link with gtk3 instead of 2? I remember 
gtk2 had issues with HiDPI support.


DWT is a port of the Java library SWT. This particular version, 
3.4, of SWT only supports GTK2. Later versions of SWT do support 
GTK3. The current port is a manual port, but I'm working on a 
tool to automate porting the code. I will not update DWT until it 
can be automated.


--
/Jacob Carlborg


Re: DWT API Documentation now on dpldocs.info

2018-03-08 Thread Jacob Carlborg via Digitalmars-d-announce

On Thursday, 8 March 2018 at 01:21:44 UTC, Adam D. Ruppe wrote:
As some of you might know, DWT is a D port of Java's SWT. It is 
as thus nearly identical and you can use Java's documentation 
with very little effort - copy/paste of Java examples almost 
just work as D too.


But, the eclipse docs are meh and besides, it is nice to have 
the D docs anyway.


Thankfully, there's plenty of documentation comments in the dwt 
source. Alas, they are javadoc comments. Well, now adrdox knows 
how to read javadoc (if specifically told to).


I don't have a great entry point to the docs, so it will just 
go to the Display class... but take a look:


http://dwt.dpldocs.info/index.html

As you click around, you can navigate, see the inheritance 
trees, and might even notice some of the java.lang namespace in 
there!


http://dwt.dpldocs.info/java.lang.String.html

Well, I made a mistake generating these and there's a broken 
image and link in the header... but the text body looks pretty 
good!



Any DWT users who can give me feedback on the quality?


This is pretty cool :)

A few comments and comparing with the Javadocs there are a few 
things missing:


* It doesn't seem to be possible to navigate between the top 
level packages, i.e. "java" and "org"

* No inheritance chain
* No implemented interfaces
* Only one level of inherited members
* I think it's a bit too much to show the documentation of 
inherited members, I would just have links to them


--
/Jacob Carlborg


Re: DWT API Documentation now on dpldocs.info

2018-03-08 Thread Jacob Carlborg via Digitalmars-d-announce

On Thursday, 8 March 2018 at 01:21:44 UTC, Adam D. Ruppe wrote:

I don't have a great entry point to the docs, so it will just 
go to the Display class... but take a look:


I would recommend the "swt" package [1] as an entry point. Or we 
could add some documentation to the "all" or "std" modules [2] 
[3] and use one of those.


[1] http://dwt.dpldocs.info/org.eclipse.swt.html

[2] 
https://github.com/d-widget-toolkit/dwt/blob/master/org.eclipse.swt.gtk.linux.x86/src/org/eclipse/swt/all.d


[3] 
https://github.com/d-widget-toolkit/dwt/blob/master/org.eclipse.swt.gtk.linux.x86/src/org/eclipse/swt/std.d


--
/Jacob Carlborg


Re: Beta 2.079.0

2018-02-23 Thread Jacob Carlborg via Digitalmars-d-announce

On 2018-02-19 11:49, Martin Nowak wrote:


Glad to announce the first beta for the 2.079.0 release, ♥ to the 77
contributors for this release.


The following is a regression that breaks DWT:

extern (C) void foo(int) { }
extern (C) void foo(double) { }

The above used to compile but now results in:

main.d(2): Error: function main.foo(double) cannot be overloaded with 
another extern(C) function at main.d(1)


Was reported before the beta was released [1].

[1] https://issues.dlang.org/show_bug.cgi?id=18385

--
/Jacob Carlborg


Re: Official Dub package for DWT

2018-02-22 Thread Jacob Carlborg via Digitalmars-d-announce

On 2018-02-22 20:26, Jesse Phillips wrote:

This is awesome. I don't use GUI too much with my D programs, but I've 
had one lingering with DFL for a while now.


It took a little bit to get familiar with this framework again, but I 
think the conversion has been totally worth it (even seems to have made 
my application faster).


I'll point out that this is definitely a lower level library than I 
usually see/use.


I also hit only one documentation issue due to this being 3.4 and not 
3.7 or later, but that didn't look like it would be a normal hiccup.


Anyway, thank you for getting this to work with DUB as that simplifies 
my build.


Thanks.

--
/Jacob Carlborg


Re: The Expressive C++17 Coding Challenge in D

2018-02-14 Thread Jacob Carlborg via Digitalmars-d-announce

On 2018-02-14 19:00, Ola Fosheim Grøstad wrote:

For instance, Swift drags in all of Os-X on the default platform, so 
writing an audio/video loader would be relatively short in comparison to 
other languages. Would that be fair or instructive? Of course not. The 
Os-X libraries are quite massive.


For a fair comparison Swift should only use libraries that are available 
both on macOS and Linux.


--
/Jacob Carlborg


Re: dxml 0.2.0 released

2018-02-12 Thread Jacob Carlborg via Digitalmars-d-announce

On 2018-02-12 21:19, Chris wrote:

A few lines of code that could be replaced easily once something better 
is available?


Fairly easy because it's so small. I'm actually using the SAX interface 
from std.xml and it quite nicely fits my needs.


--
/Jacob Carlborg


Re: dxml 0.2.0 released

2018-02-12 Thread Jacob Carlborg via Digitalmars-d-announce

On 2018-02-12 17:49, Chris wrote:


How could it possibly make the situation any worse than it is now? Atm,
nobody will ever use std.xml, because it is sub-standard and has no future.


I'm using std.xml in a new project right now. It's a really small 
private project that just need to extracts some data from an XML 
document. I started it a couple of days before dxml was announced.


--
/Jacob Carlborg


Re: dxml 0.1.0 released

2018-02-11 Thread Jacob Carlborg via Digitalmars-d-announce

On 2018-02-10 19:57, Jonathan M Davis wrote:


Kind of. I did some benchmarking to see if some code changes would improve
performance, but I haven't tried benchmarking it against any other XML
libraries.


Ok, I see.


That would take a fair bit of time and effort, and IMHO, that
would be better spent finishing the library first.

Fair enough.

--
/Jacob Carlborg


Re: dxml 0.1.0 released

2018-02-10 Thread Jacob Carlborg via Digitalmars-d-announce

On 2018-02-09 22:15, Jonathan M Davis wrote:


Currently, dxml contains only a range-based StAX / pull parser and related
helper functions, but the plan is to add a DOM parser as well as two writers
- one which is the writer equivalent of a StaX parser, and one which is
DOM-based. However, in theory, the StAX parser is complete and quite useable
as-is - though I expect that I'll be adding more helper functions to make it
easier to use, and if you find that you're doing a particular operation with
it frequently and that that operation is overly verbose, please point it out
so that maybe a helper function can be added to improve that use case - e.g.


This is great news! Have you run any benchmarks to see how it performs?

--
/Jacob Carlborg


Re: Official Dub package for DWT

2018-02-09 Thread Jacob Carlborg via Digitalmars-d-announce

On 2018-02-09 04:48, Brian wrote:

Thanks!

But, How to use x64?


On Linux it should just work if you have a 64bit system. On Windows I 
guess you would run Dub with "dub --arch=x86_64", if it doesn't already 
default to 64bit.


--
/Jacob Carlborg


Re: Official Dub package for DWT

2018-02-08 Thread Jacob Carlborg via Digitalmars-d-announce

On 2018-02-08 00:22, lobo wrote:

Thanks for this effort. I looked at DWT a while back but settled on GtkD 
because it was easier to build. Either way, I will have to revisit this 
library and give it another go in my new project.


Looking at the examples I imagine it wouldn't be too difficult to use 
WindowBuilder for SWT and port the generate Java code across to DWT.

Yeah, I don't think that would be too difficult.

--
/Jacob Carlborg


Official Dub package for DWT

2018-02-07 Thread Jacob Carlborg via Digitalmars-d-announce
This has been long overdue but I would like to announce that I've just 
released an official Dub package for the DWT library [1]. For a usage 
example, please see the GitHub page [2].


For those not familiar with DWT, it's a library for creating 
cross-platform GUI applications. It's uses the native drawing operations 
of the operating system. It's originally a port of the SWT Java library, 
it's a complete port and contains no Java or JNI code.


A couple of other changes are:

* All the previous Git submodules have now been inlined in the 
main/super repository [3]

* Proper testing on both Linux and Windows has been added
* Separate tool for building all the snippets
* Bumped the minimum requirement of the compiler to DMD 2.078.1 (I'll 
probably add support for LDC soon)

* Officially removeed any support for building with D1

[1] http://code.dlang.org/packages/dwt
[2] https://github.com/d-widget-toolkit/dwt#usage
[3] https://github.com/d-widget-toolkit/dwt

--
/Jacob Carlborg


Re: [howto] Serve ddox documentation on github.io deployed by Travis CI

2018-01-13 Thread Jacob Carlborg via Digitalmars-d-announce

On 2018-01-13 05:59, Martin Nowak wrote:

On Wednesday, 10 January 2018 at 08:50:37 UTC, Bastiaan Veelo wrote:
Maybe worthwile to add this scaffolding to dub or some other tool? 
Anyone volunteering?


This could be a good idea. Probably even better is to let 
code.dlang.org take care of it, which would make the whole token issue 
and setup obsolete.


What do you mean with "taking care of it"?


Perhaps to automatically generate documentation for all packages on 
code.dlang.org and publish it there as well.


--
/Jacob Carlborg


Re: Blog post: using dynamic libraries in dub

2017-12-25 Thread Jacob Carlborg via Digitalmars-d-announce

On 2017-12-23 21:59, Walter Bright wrote:


It'd be nice to collect information on what needs to be done and file a
bugzilla issue on it. Otherwise it's just generic "doesn't work on
macOS" which contains no useful information.


If I knew exactly what would need to be done I would most likely have 
done it already :). Perhaps Martin that implemented the support on Linux 
or David that, I think, implemented it for LDC on macOS would be better 
suited for such a bugzilla issue.


--
/Jacob Carlborg


Re: Blog post: using dynamic libraries in dub

2017-12-23 Thread Jacob Carlborg via Digitalmars-d-announce

On 2017-12-23 00:18, Walter Bright wrote:

Is there a bugzilla issue with just what is wrong with the TLS code 
generation on macOS?


There's nothing wrong with TLS on macOS. It's just that there are 
additional work that needs to be done. Just the same as TLS worked 
before dynamic libraries worked on Linux.


--
/Jacob Carlborg


Re: Blog post: using dynamic libraries in dub

2017-12-22 Thread Jacob Carlborg via Digitalmars-d-announce

On 2017-12-21 14:30, David Nadlinger wrote:

Just to clarify, that's true for for DMD only – TLS should work just 
fine on macOS with LDC.


Right.

--
/Jacob Carlborg


Re: Blog post: using dynamic libraries in dub

2017-12-21 Thread Jacob Carlborg via Digitalmars-d-announce

On 2017-12-20 11:31, Benjamin Thaut wrote:

Would this work in all cases? Do tls variables work across Linux shared 
libraries? 


As far as I know it works on Linux and FreeBSD, but it doesn't work on 
macOS. I don't know about windows.


Do we expect all dub libraries to have correct export 
annotations once export goes live?


No.

--
/Jacob Carlborg


Re: mysql-native v1.2.0: Housekeeping: Deprecations, Cleanup and Doc Improvements

2017-12-16 Thread Jacob Carlborg via Digitalmars-d-announce

On 2017-12-16 06:37, Nick Sabalausky (Abscissa) wrote:

Oh, I'd thought it was the middle one for that. Right-most for 
non-breaking changes, Middle for all breaking changes, and Left-most for 
major changes. Guess I remembered it wrong :/


My mistake, the left most for breaking changes, regardless if they're 
major or not.


--
/Jacob Carlborg


Re: mysql-native v1.2.0: Housekeeping: Deprecations, Cleanup and Doc Improvements

2017-12-15 Thread Jacob Carlborg via Digitalmars-d-announce

On 2017-12-15 08:31, Nick Sabalausky (Abscissa) wrote:

- The deperecated symbols have been removed (ie, the the outdated 
pre-v1.0.0 interfaces).


If you have removed symbols that's a breaking API changes which should 
bump the right most digit in the version according to Semantic 
Versioning [1].


[1] https://semver.org/

--
/Jacob Carlborg


Re: run.dlang.io - a modern way to run D code

2017-12-14 Thread Jacob Carlborg via Digitalmars-d-announce

On 2017-12-13 02:14, Seb wrote:

Also the storage on the machine is limited and we can't drop an 
unlimited amount of Docker images there.


There could be a job that cleans up the local Docker images. If a Docker 
image is needed it will be pulled down again automatically. Of course 
there can be a few common images that are never cleaned up to reduce the 
waiting time for pulling down an image.


--
/Jacob Carlborg


Re: LDC 1.7.0-beta1

2017-12-13 Thread Jacob Carlborg via Digitalmars-d-announce

On 2017-12-13 09:42, Suliman wrote:

Could you explain hot to do it? Install LLVM? And than how I could 
specify what linker should be used?


with the "-linker=" flag.

--
/Jacob Carlborg


Re: LDC 1.6.0-beta1

2017-12-03 Thread Jacob Carlborg via Digitalmars-d-announce

On 2017-12-03 12:52, kinke wrote:

Working on that. It's not that simple though; we use a custom LLVM, 
which Travis doesn't manage to build alone in a dedicated job (only ~66% 
before timing out).


Hmm, I would need to do that as well for DStep :(. That's disappointing. 
Would caching help [1]? I've also though about using Docker, which could 
contain a pre-built, perhaps that's more complicated.


Luckily, there's AppVeyor and CircleCI which manage. 
So I need to finish automating the LLVM release before automating the 
LDC release.


I see.

[1] https://docs.travis-ci.com/user/caching/

--
/Jacob Carlborg


Re: LDC 1.6.0-beta1

2017-12-03 Thread Jacob Carlborg via Digitalmars-d-announce

On 2017-12-03 00:08, David Nadlinger wrote:

That would be a good idea. Also, I uploaded the OS X package just now. 
(Didn't realise it wasn't built yet…). —David


Here's the Travis CI script for one of my projects [1] that uploads to a 
GitHub release, both for Linux and macOS.


[1] https://github.com/jacob-carlborg/remarkify/blob/master/.travis.yml

--
/Jacob Carlborg


Re: LDC 1.6.0-beta1

2017-12-02 Thread Jacob Carlborg via Digitalmars-d-announce

On 2017-12-02 13:41, kinke wrote:

Nope, unfortunately still waiting for one of my compadres to create and 
upload the OSX package.


Have you thought of automatically build and upload packages using Travis CI?

--
/Jacob Carlborg


Re: D User Survey

2017-12-02 Thread Jacob Carlborg via Digitalmars-d-announce

On 2017-12-02 10:30, WebFreak001 wrote:

On Saturday, 2 December 2017 at 09:16:55 UTC, Jacob Carlborg wrote:

On 2017-12-01 19:56, WebFreak001 wrote:

Hi everyone,

I made a public survey (everyone can look at the responses) and it 
would be great if you took some time and answered it. I think it will 
greatly benefit D as a whole if we had more anonymous data on users. 
I'm also open for changing some questions if there is confusion.


https://docs.google.com/forms/d/e/1FAIpQLSdPFx9ebHJ05QSW1VypBsQPw-1RbZ1v8FMgo1su6NvN6VErBw/viewform 





"How many of your colleagues used D before?"

Before what?

For the questions about OS/distro, I think you should add "FreeBSD" as 
an alternative. It's one of the officially supported platforms.


I used that like "did you use D before?" as in "did you ever use D?"


Then I would phrase that as "How many of your colleagues have used D 
before?" or "How many of your colleagues have tried D".


--
/Jacob Carlborg


Re: D User Survey

2017-12-02 Thread Jacob Carlborg via Digitalmars-d-announce

On 2017-12-01 19:56, WebFreak001 wrote:

Hi everyone,

I made a public survey (everyone can look at the responses) and it would 
be great if you took some time and answered it. I think it will greatly 
benefit D as a whole if we had more anonymous data on users. I'm also 
open for changing some questions if there is confusion.


https://docs.google.com/forms/d/e/1FAIpQLSdPFx9ebHJ05QSW1VypBsQPw-1RbZ1v8FMgo1su6NvN6VErBw/viewform 


I think the questions about how easy it was and the quality of the 
learning material were a bit difficult to answer. For someone like me 
that learned D 10+ years ago, how should I answer those questions? How 
it was back then, or how I think it's now? For the former it might not 
be very useful because the landscape was very different back then. For 
the latter it's difficult to answer because I already now D and how to 
find the resources.


--
/Jacob Carlborg


Re: D User Survey

2017-12-02 Thread Jacob Carlborg via Digitalmars-d-announce

On 2017-12-01 19:56, WebFreak001 wrote:

Hi everyone,

I made a public survey (everyone can look at the responses) and it would 
be great if you took some time and answered it. I think it will greatly 
benefit D as a whole if we had more anonymous data on users. I'm also 
open for changing some questions if there is confusion.


https://docs.google.com/forms/d/e/1FAIpQLSdPFx9ebHJ05QSW1VypBsQPw-1RbZ1v8FMgo1su6NvN6VErBw/viewform 



"How many of your colleagues used D before?"

Before what?

For the questions about OS/distro, I think you should add "FreeBSD" as 
an alternative. It's one of the officially supported platforms.


--
/Jacob Carlborg


Re: Reorganization and list of D libraries (300+)

2017-11-04 Thread Jacob Carlborg via Digitalmars-d-announce

On 2017-11-04 01:12, Fra Mecca wrote:

Hi all.

Lurking in this forum I had the feeling that lots of D developers tend 
to rewrite lots of code that could be found in libraries. This is not 
bad per se but I thought that one of the reason could have been the 
current process of library discovery.


For this reason I have edited a list of libraries that could aid in this 
process.


I also considered that the following features could be of importance to 
you:

- License
- Garbage collector
- last modification (automated)

The list is of course not complete and I could not test all of the 
libraries I included.


I welcome you to modify it, open PRs or issues on github.

https://github.com/FraMecca/D_Libraries_Registry

I hope it could lead to a better ecosystem for the whole D community.


DWT is using the EPL, Eclipse Public License, license.
I'm missing the ddb [1] and mysql-native [2] database libraries.
There are many list like this for other languages, they're usually 
called "awesome-" where  is the language.


[1] https://github.com/pszturmaj/ddb
[2] https://github.com/mysql-d/mysql-native

--
/Jacob Carlborg


  1   2   3   4   5   6   >